Диаграмма синхронизации

Диаграмма синхронизации (Timing diagram) — альтернативное представление диаграммы последовательности, явным образом показывающее изменения состояния на линии жизни с заданной шкалой времени. Может быть полезна в приложениях реального времени.

6. Диаграмма последовательности. Диаграмма кооперации

Диаграмма последовательности (англ. sequence diagram) — диаграмма, на которой показаны взаимодействия объектов, упорядоченные по времени их проявления. Используется в языке UML.

Основными элементами диаграммы последовательности являются обозначения объектов (прямоугольники), вертикальные линии (англ. lifeline), отображающие течение времени при деятельности объекта, и стрелки, показывающие выполнение действий объектами. На данной диаграмме объекты располагаются слева направо. Ее недостатком является то, что она занимает много места.

Подвидом диаграмм композитной структуры являются диаграммы кооперации (Collaboration diagram, введены в UML 2.0), которые показывают роли и взаимодействие классов в рамках кооперации. Кооперации удобны при моделировании шаблонов проектирования.

7. Диаграмма компонентов. Диаграмма развертывания Диаграмма развёртывания

Диаграмма развёртывания (Deployment diagram, диаграмма размещения) — служит для моделирования работающих узлов (аппаратных средств, англ. node) и артефактов, развёрнутых на них. В UML 2 на узлах разворачиваются артефакты (англ. artifact), в то время как в UML 1 на узлах разворачивались компоненты. Между артефактом и логическим элементом (компонентом), который он реализует, устанавливается зависимость манифестации.

Диагра́мма компоне́нтов, Component diagram — статическая структурная диаграмма, показывает разбиение программной системы на структурные компоненты и связи (зависимости) между компонентами. В качестве физических компонентов могут выступать файлы, библиотеки, модули, исполняемые файлы, пакеты и т. п.

Основные сведения

Компоненты связываются через зависимости, когда соединяется требуемый интерфейс одного компонента с имеющимся интерфейсом другого компонента. Таким образом иллюстрируются отношения клиент-источникмежду двумя компонентами.

Зависимость показывает, что один компонент предоставляет сервис, необходимый другому компоненту.Зависимость изображается стрелкой от интерфейса или порта клиента к импортируемому интерфейсу.[1]

Когда диаграмма компонентов используется, чтобы показать внутреннюю структуру компонентов, предоставляемый и требуемый интерфейсы составного компонента могут делегироваться в соответствующие интерфейсы внутренних компонентов.

Делегация показывается связь внешнего контракта компонента с внутренней реализацией этого поведения внутренними компонентами.[1]

8. Языки и среды моделирования архитектуры предприятия. Языки моделирования предприятий. Idеf, dfd- технология, aris, bpml.

Основными этапами процесса построения архитектуры организации являются следующие:

1. осознание необходимости построения архитектуры;

2. формирование рабочей группы;

3. выбор среды моделирования, средств моделирования и репозитория;

4. наполнение среды фактическим материалом (формирование архитектуры);

5. использование;

6. расширение и сопровождение.

При этом на этапе формирования архитектуры, как наиболее трудоемком, решаются следующие задачи, собственно, относящиеся к моделированию:

1. определение бизнес-целей и требований;

2. моделирование бизнеса с позиции менеджера;

3. моделирование бизнес-процессов;

4. моделирование бизнес-функций;

5. моделирование оргструктуры, включая логические схемы принятия решений;

6. моделирование ресурсов;

7. преобразование бизнес-моделей в модели приложений и технологической архитектуры.

Отметим, что задача моделирования бизнеса с позиции менеджера, фактически, впервые идентифицируется в качестве самостоятельного элемента методологии. И хотя ряд инструментов "доархитектурного" периода обеспечивал построение так называемых "презентационных диаграмм", данный этап не декларировался практически ни одной из известных методологий бизнес-моделирования.

Диаграммы потоков данных представляют собой иерархию функциональных процессов, связанных потоками данных. Цель такого представления - продемонстрировать, как каждый процесс преобразует свои входные данные в выходные, а также выявить отношения между этими процессами. Для построенияDFD традиционно используются две различные нотации, соответствующие методам Йордона-ДеМарко и Гейна-Сэрсона. Эти нотации незначительно отличаются друг от друга графическим изображением символов. В соответствии с данными методами модель системы определяется как иерархия диаграмм потоков данных, описывающих асинхронный процесс преобразования информации от ее ввода в систему до выдачи потребителю (при этом для описания функционирования процесса в случае отсутствия необходимости детализировать его с помощью DFD используется миниспецификация, фактически представляющая собой алгоритм описания задачи, выполняемой процессом, при этом множество всех миниспецификаций является полной спецификацией системы). Практически любой класс систем успешно моделируется при помощи DFD -ориентированных методов. Они с самого начала создавались как средство проектирования информационных систем (тогда как SADT - как средство моделирования систем вообще) и имеют более богатый набор элементов, адекватно отражающих специфику таких систем (например, хранилища данных являются прообразами файлов или баз данных, внешние сущности отражают взаимодействие моделируемой системы с внешним миром).

ARIS поддерживает четыре типа моделей, отражающих различные аспекты исследуемой системы:

1. организационные модели, представляющие структуру системы - иерархию организационных подразделений, должностей и конкретных лиц, связи между ними, а также территориальную привязку структурных подразделений;

2. функциональные модели, содержащие иерархию целей, стоящих перед аппаратом управления, с совокупностью деревьев функций, необходимых для достижения поставленных целей;

3. информационные модели, отражающие структуру информации, необходимой для реализации всей совокупности функций системы;

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

Все эти модели представляют собой диаграммы, элементами которых являются разнообразные объекты - "функция", "событие", "структурное подразделение", "документ" и т.п. Между объектами устанавливаются разнообразные связи. Каждому объекту соответствует определенный набор атрибутов, которые позволяют ввести дополнительную информацию о конкретном объекте. Значения атрибутов могут использоваться при имитационном моделировании или для проведениястоимостного анализа.

Для построения перечисленных типов моделей используются как собственные методы моделирования ARIS, так и различные известные методы и языки моделирования. В процессе моделирования каждый аспект деятельности организации сначала рассматривается отдельно, а после детальной проработки всех аспектов строится интегрированная модель, отражающая все связи между различными аспектами.

BusinessProcess Modeling Language, BPML (Язык моделирования бизнес-процессов, англ.) – это язык XML, предназначенный для определения формальной модели, выражающей выполнимые процессы, которые описывают все аспекты корпоративных бизнес-процессов. BPML определяет операции разного уровня сложности, транзакции и компенсации, управление данными, параллелизм, обработку исключений и операционную семантику. Грамматика BPML оформляется в виде XML-схемы, что обеспечивает постоянство определений и их обмен между разнородными системами и инструментами моделирования.

Язык BPML дополняет язык реализации бизнес-процессов (Business Process Execution Language, сокр. BPEL). BPML может использоваться для определения детальных бизнес-процессов, исполняемых при вызове каждого web-сервиса (взаимодействие которых описывает BPEL). BPML преобразует бизнес-операции в обменные сообщения. Этот язык может использоваться для определения корпоративных бизнес-процессов, комплексных web-сервисов и многостороннего сотрудничества.

IDEF — методологии семейства ICAM (Integrated Computer-Aided Manufacturing) для решения задач моделирования сложных систем, позволяет отображать и анализировать модели деятельности широкого спектра сложных систем в различных разрезах. При этом широта и глубина обследования процессов в системе определяется самим разработчиком, что позволяет не перегружать создаваемую модель излишними данными.

IDEF — методологии создавались в рамках предложенной ВВС США программы компьютеризации промышленности — ICAM, в ходе реализации которой выявилась потребность в разработке методов анализа процессов взаимодействия в производственных (промышленных) системах. Принципиальным требованием при разработке рассматриваемого семейства методологий была возможность эффективного обмена информацией между всеми специалистами — участниками программы ICAM (отсюда название: Icam DEFinition — IDEF другой вариант — Integrated DEFinition). После опубликования стандарта он был успешно применен в самых различных областях бизнеса, показав себя эффективным средством анализа, конструирования и отображения бизнес-процессов. Более того, собственно с широким применением IDEF (и предшествующей методолoгии — SADT) и связано возникновение основных идей популярного ныне понятия — BPR (бизнес-процесс реинжиниринг).