3.2. ОписаниеDfDмодели.

Диаграммы потоков данных моделируют систему как набор действий, соединенных друг с другом стрелками. В отличие от стрелок в IDEF0, которые иллюстрируют отношения, стрелки вDFDпоказывают, как объекты (включая и данные) реально перемещаются от одного действия к другому. Работы в моделируемойDFD-диаграмме связаны следующим образом:

А01. На этом этапе на основании приказов генерального директора , с учетом различных законодательных норм, предоставляется информация для формирования сметы проекта.

А1.1. Генеральный директор генерирует идею об открытии молодежного ночного клуба. Для начала финансовый отдел на основании правил бюджетирования формирует статьи бюджета проекта.

А1.2. Финансовый отдел собирает информацию о расходах. Эти данные ему предоставляют отделы снабжения, рекламы, бухгалтерия и сам финансовый отдел. Вся эта информация соответствует законам гражданского и налогового кодекса, а также положениям о бухгалтерском учете.

А1.3. Финансовый отдел собирает информацию о доходах. Эти данные ему предоставляют отдел маркетинга, бухгалтерия и сам финансовый отдел. Вся эта информация соответствует законам гражданского и налогового кодекса, а также положениям о бухгалтерском учете.

А1.4. Финансовый отдел на основании предоставленной информации о доходах и расходах, а также руководствуясь законами гражданского и налогового кодекса, составляет предварительную смету проекта.

А1.5. Финансовый отдел на основании предварительной сметы проекта, а также руководствуясь законами гражданского и налогового кодекса, анализирует предварительную смету проекта, при этом дает рекомендации по формированию статей бюджета и корректирует смету.

А1.6. Финансовый отдел на основании скорректированной сметы проекта, а также руководствуясь законами налогового кодекса и нормами финансовой отчетности, составляет окончательную смету проекта.

А02. На основании сметы проекта, с учетом законодательных норм, на основании приказов генерального директора, формируется план инвестирования.

А2.1. Поиском инвесторов занимается генеральный директор, руководствуясь гражданским кодексом, издавая необходимые для этого приказы.

А2.2. Инвесторы формируют критерии анализа проекта, совместно с генеральным директором и финансовым отделом, руководствуясь гражданским кодексом, анализируют смету проекта, результатом чего является проанализированная смета проекта.

А2.3. Руководствуясь гражданским кодексом, генеральный директор и финансовый отдел разрабатывают план инвестирования, исходя из проанализированной сметы и данных финансового отдела. Результат – план инвестирования.

А03. Исходя из плана инвестирования, руководствуясь налоговым кодексом, на основании приказов генерального директора, происходит реализация проекта сотрудниками на деньги, данные для проекта.

4.UmLмодель.

4.1. Технология созданияUmLмодели.

Объектно-ориентированные модели строятся на основе языка UML.UML– язык для определения, представления, проектирования и документирования программных систем, бизнес-систем и прочих систем не программного обеспечения.

Разработка и построение заданного бизнес-процесса в среде Enterprise Architect начинается с запуска программы из главного меню: Пуск – Все программы – EnterpriseArchitect6.0.

В стартовом окне программы выбрать команду настройки профиля MyProfile(Рис. 57).

Рис. 57 MyProfile

В данном окне необходимо заполнить поле Myname, которое будет указываться как имя автора проекта. Выбрать стандартUML2.0.

По щелчку по кнопке CustomizeInterfaceможно провести первичную настройку интерфейса. По щелчку по кнопкеShowKeyboardMapможно посмотреть комбинации клавиш для определенных команд.

Для инициации создания модели нужно в стартовом окне выбрать команду CreateanewProject(Рис. 58). По команде открывается диалоговое окно, в котором в строкеNewProjectнеобходимо ввести имя проекта и указать место расположения. В строкеModel Project указывается стартовый шаблон построения модели.

Рис. 58 Инициация создания новой модели

После подтверждения введенных данных (нажатие клавиши «CreateProject») появляется дерево модели (Рис. 59).

Рис. 59 Окно навигатора модели

Формирование модели начинается с построения Ролевой диаграммы, которая отображает функции участников и их взаимосвязи. Для построения ролевой диаграммы удобнее всего использовать два вида диаграмм в классе модели UseCaseView:BusinessProcessModelиUseCaseModel. ДаннаяUML-модель будет строиться на основеUseCaseModel. Для построения ролевой диаграммы необходимо в окне навигатора модели (Рис. 60) открыть группуUseCaseModelи дважды щелкнуть по пиктограммеUseCaseModel.

Рис. 60 Окно навигатора проекта

После этого появится окно модели (Рис. 61) и ярлык UseCaseModel.

Рис. 61 Окно модели

Далее необходимо установить из палитры Use Case (Рис. 62) нужные компоненты, задавая при их установке свойства и имя компонента в автоматически появляющейся панели (Рис. 63). Для редактирования свойств элемента нужно дважды щелкнуть на элементе.

Рис. 62 Палитры создания UML-диаграмм

Рис. 63 Свойства компонента

Далее нужно расставить связи. Для расстановки связей нужно:

выбрать тип связи в палитре

щелкнуть на исходном элементе

при зажатой клавише протащить курсор до целевого элемента

Типы связей (в палитре UseCase):

Generalize– генерализованные (Рис. 64) – таксономическое отношение (соподчиненность) между наиболее важными элементами модели и специфическими элементами, непосредственно содержащими, образующими дополнительную информацию или обрабатывающими поступающую информацию. Связь инициации действия или события.

Рис. 64 Связь Generalize

Associate– ассоциативные – семантическое отношение между двумя или больше компонентами, которые определяют связи среди принадлежащих им экземпляров или атрибутов. Связь внутреннего содержания. (Рис. 65)

Рис. 65 Связь Associate

Realize – реализация (Рис. 66) – исходный объект реализует объект расположения. Связь используется для трассировки модели процесса или требования, реализованных одним или более случаями использования, предназначенными для определенного компонента. Связь исполнения.

Рис. 66 Связь Realize

Dependency– зависимые (Рис. 67) – отношение между двумя элементами моделирования, в котором изменение в одном элементе моделирования, повлияет на другой элемент моделирования.

Рис. 67 Связь Dependency

Use– связь, указывающая на взаимодействие или использование. Вид отображения зависит от связываемых объектов.

После расстановки связей необходимо ввести описание ролевых функций. Для этого нужно добавить зависимые заметки (Рис. 68). Для этого необходимо вызвать контекстно-зависимое меню на ролевом объекте, выбирается команда ADD, из меню второго уровня выбираетсяAttachNote.

Рис. 68 Зависимая метка

После выбора команды AttachNoteпоявляется зависимая заметка. Чтобы ввести описание ролевых функций необходимо дважды щелкнуть на заметке и ввести текст в окнеNotes. Рекомендованная формулировка ролевых функций должна отвечать на вопрос: «Что делает ролевой объект?». Подтверждение введенного текста осуществляется нажатием клавиши «OK». После ввода текста появляется заметка с веденным текстом (Рис. 68).

Далее строится контекстная диаграмма. Так как в классе UseCaseуже построена ролевая диаграмма, то нужно добавить еще одну диаграмму этого класса. Для того чтобы добавить диаграмму необходимо в разделеProjectвыбрать командуAddDiagramи, в появившемся окне (Рис. 69) выбрать тип диаграммы, и ввести название диаграммы. Подтверждение осуществляется нажатием «OK».

Рис. 69 Добавление новой диаграммы

После добавления контекстной диаграммы необходимо из палитры UseCaseустановить все объекты, которые были на ролевой диаграмме, задавая при их установке свойства компонента в автоматически проявляющейся панели. В контекстную диаграмму устанавливаем дополнительно элементы из палитрыUseCase«UseCase» (Рис. 70).

Рис. 70 Элемент UseCase

После внесения всех элементов необходимо расставить связи по описанной выше технологии. Далее строится диаграмма декомпозиции. Наиболее общим способом перехода к декомпозирующей диаграмме является добавление новой диаграммы как составного элемента. Для этого следует:

Добавить нужный вид диаграммы

Для добавления декомпозирующей диаграммы на родительском элементе следует вызвать контекстно-зависимое меню выбрать команду ADD(Рис. 71) и в выпадающем меню выбратьActivityDiagram. Подтверждение осуществляется клавишей «OK».

Рис. 71 Добавление новой диаграммы

Отметить родительский элемент как составной

Для того чтобы отметить родительский элемент как составной следует вызвать контекстно-зависимое меню, выбрать команду AdvancedSettingsи включить переключательCompositeElement. На элементе после включения переключателя появляется отметка составного элемента (Рис. 72).

Рис. 72 Составной элемент

После создания дочерней диаграммы для перехода к ней достаточно дважды щелкнуть на родительском элементе.

Для наглядности классификации информации рекомендуется настроить так называемые «ролевые полосы» (Swimlanes), каждая из которой будет предназначена для размещения элементов определенного назначения:

Информация

Действия

Роли

Настройка проводится по команде ConfigureSwimlanesраздела Главного менюDiagrams. По этой команде открывается окно (Рис. 73), в котором настраиваются свойства ролевых полос: положение полос, параметры линий и текста, ввод новой полосы, изменений выбранной полосы, удаление полосы и изменение последовательности полос. Для создания полос нужно щелкнуть по кнопкеNewи ввести наименование.

Рис. 73 Добавление ролевых полос

В диаграммах Activityиспользуется два вида связей:

- ControlFlow– управляющий поток (Рис. 74) – связь между элементами действия в диаграмме.

Рис. 74 Вид связи ControlFlow

- ObjectFlow– поток данных (Рис. 75) – связь между элементами диаграммы при передаче каких-либо данных.

Рис. 75 Вид связи ObjectFlow

При построении диаграммы декомпозиции в полях информация и действия связи и элементы берутся из палитры Activity, а в поле роли – элементы и связи из палитрыUseCase.

В диаграмме Activityвсегда есть начало процесса и конец (Рис. 76). ЭлементыInitialиFinalдолжны подписываться.

Рис. 76 Элементы InitialиFinal

Для отображения инициации процесса используется связь Realizeиз палитрыUseCase.

Для построения диаграммы активности используются элемент Activity(Рис. 77) и элементDecision(Рис.4.1.24) (элемент условия) из палитрыActivity.

Рис. 77 Элемент Activity

Рис. 78 Элемент Decision

При помощи элемента Decisionсоздается ветвление процесса. Для указания элементов в ролевой полосе информация (сведения, данные, документы, оборудование и т.п.) используется элементObject(Рис. 79).

Рис. 79 Элемент Object

По описанной выше технологии далее строится следующая диаграмма декомпозиции.

Для подписи модели необходимо в Главном меню Diagram выбрать Insert Property Note. После чего в верхнем левом углу появляется поле (Рис. 80), при необходимости поле можно перемещать.

Рис. 80 Подпись модели

Полученный результат представлен в приложении 4.