Файл: Применение объектно-ориентированного подхода при проектировании информационной системы.pdf

Диаграмма деятельности ‒ еще один способ описания поведения, который визуально напоминает старую добрую блок-схему алгоритма. Однако за счет модернизированных обозначений, согласованных с объектно-ориентированным подходом, а главное, за счет новой семантической составляющей (свободная интерпретация сетей Петри), диаграмма деятельности UML является мощным средством для описания поведения системы.

На диаграмме деятельности применяют один основной тип сущностей ‒ действие 1, и один тип отношений ‒ переходы 2 (передачи управления и данных). Также используются такие конструкции как развилки, слияния, соединения, ветвления 3, которые похожи на сущности, но таковыми на самом деле не являются, а представляют собой графический способ изображения некоторых частных случаев многоместных отношений. Основные элементы нотации, применяемые на диаграмме деятельности, показаны на рисунке 4.

Рисунок 4. Нотация диаграммы деятельности

Диаграмма последовательности (sequence diagram) ‒ это способ описания поведения системы на основе указания последовательности передаваемых сообщений.

Фактически, диаграмма последовательности ‒ это запись протокола конкретного сеанса работы системы (или фрагмента такого протокола). В объектно-ориентированном программировании самым существенным во время выполнения является пересылка сообщений между взаимодействующими объектами. Именно последовательность посылок сообщений отображается на данной диаграмме, отсюда и название.

На диаграмме последовательности применяют один основной тип сущностей ‒ экземпляры взаимодействующих классификаторов 1 (в основном классов, компонентов и действующих лиц), и один тип отношений ‒ связи 2, по которым происходит обмен сообщениями 3. Предусмотрено несколько способов посылки сообщений, которые в графической нотации различаются видом стрелки, соответствующей отношению.

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

На рисунке 5 показаны основные элементы нотации, применяемые на диаграмме последовательности. Для обозначения самих взаимодействующих объектов применяется стандартная нотация ‒ прямоугольник с именем экземпляра классификатора. Пунктирная линия, выходящая из него, называется линией жизни (lifeline) 4. Это не обозначение отношения в модели, а графический комментарий, призванный направить взгляд читателя диаграммы в правильном направлении. Фигуры в виде узких полосок, наложенных на линию жизни, также не являются изображениями моделируемых сущностей. Это графический комментарий, показывающий отрезки времени, в течении которых объект владеет потоком управления (execution occurrence) 5 или другими словами имеет место активация(activation) объекта. Составные шаги взаимодействия (combined fragment) 6 позволяют на диаграмме последовательности, отражать и алгоритмические аспекты протокола взаимодействия.

Рисунок 5. Нотация диаграммы последовательности

Диаграмма коммуникации (communication diagram) ‒ способ описания поведения, семантически эквивалентный диаграмме последовательности.

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

Таким образом, на диаграмме коммуникации также, как и на диаграмме последовательности, применяют один основной тип сущностей ‒ экземпляры взаимодействующих классификаторов 1 и один тип отношений ‒ связи 2. Однако здесь акцент делается не на времени, а на структуре связей между конкретными экземплярами.

На рисунке 6 показаны основные элементы нотации, применяемые на диаграмме коммуникации. Для обозначения самих взаимодействующих объектов применяется стандартная нотация ‒ прямоугольник с именем экземпляра классификатора. Взаимное положение элементов на диаграмме кооперации не имеет значения ‒ важны только связи (чаще всего экземпляры ассоциаций), вдоль которых передаются сообщения 3. Для отображения упорядоченности сообщений во времени применяется иерархическая десятичная нумерация.

Рисунок 6. Нотация диаграммы коммуникации

Диаграмма компонентов (component diagram) ‒ показывает взаимосвязи между модулями (логическими или физическими), из которых состоит моделируемая система.

Основной тип сущностей на диаграмме компонентов ‒ это сами компоненты 1, а также интерфейсы 2, посредством которых указывается взаимосвязь между компонентами. На диаграмме компонентов применяются следующие отношения:

1. реализации между компонентами и интерфейсами (компонент реализует интерфейс);
2. зависимости между компонентами и интерфейсами (компонент использует интерфейс) 3.

На рисунке 7 показаны основные элементы нотации, применяемые на диаграмме компонентов.

Рисунок 7. Нотация диаграммы компонентов

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

Таким образом, на диаграмме размещения, по сравнению с диаграммой компонентов, добавляется два типа сущностей: артефакт 1, который является реализацией компонента 2 и узел 3 (может быть, как классификатор, описывающий тип узла, так и конкретный экземпляр), а также отношение ассоциации между узлами 4, показывающее, что узлы физически связаны во время выполнения.

На рисунке 8 показаны основные элементы нотации, применяемые на диаграмме размещения. Для того чтобы показать, что одна сущность является частью другой, применяется либо отношение зависимости «deploy» 5, либо фигура одной сущности помещается внутрь фигуры другой сущности 6. [4]

Рисунок 8. Нотация диаграммы размещения

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

Диаграммы UML сравнительно просты для чтения после достаточно быстрого ознакомления с его синтаксисом. UML получил широкое распространение и динамично развивается.

Глава 2. Средства реализации объектно-ориентированного подхода при проектировании информационных систем

2.1 Sparx Systems Enterprise Architect

Enterprise Architect - это программа для UML-моделирования и проектирования, с возможностью многопользовательской работы и дружественным интерфейсом. Enterprise Architect работает на Windows и Linux.

Ниже перечислены одни из возможностей программы для проектирования Enterprise Architect весьма многочисленны:

1. нотация UML 2.0 с поддержкой всех видов диаграмм;
2. поддержка C++, Java, C#, VB, VB.Net, Delphi, PHP, .NET;
3. моделирование БД, прямое проектирование в DDL и обратное проектирование из ODBC;
4. загружаемые UML-профили (например, SPEM), позволяющие создавать узкоспециализированные модели;
5. поддержка паттернов проектирования;
6. генерация документации в форматах HTML и RTF;
7. многопользовательская работа, утилиты для менеджера проекта, тестирование, глоссарий, другие ресурсы;
8. автоматизация интерфейса, поддержка макросов.

Enterprise Architect существует в трех редакциях:

а) EA Desktop Edition

Интуитивно понятная утилита для UML-моделирования, предназначенная для индивидуальных аналитиков и/или разработчиков. Простейший инструмент проектирования, имеющий некоторые ограничения. Отсутствуют многие, привычные для профессионалов, функции, которые, впрочем, абсолютно не нужны, если вы просто ищете инструмент для рисования UML-диаграмм. Не поддерживается, например, импорт/экспорт кода и DDL, Active X-интерфейс и совместный доступ к диаграммам.

б) EA Professional Edition

Полнофункциональная среда UML-моделирования, нацеленная на групповую разработку, поддерживает совместный доступ к созданным моделям, Active X, XMI, импорт/экспорт кода и DDL, извлечение схем БД Oracle, SQL Server и MS Access.

в) EA Corporate Edition

Наиболее полная редакция, включающая все возможности настольной и профессиональной версий плюс возможность соединения с MySQL, SQL Server, PostgreSQL, Sybase Adaptive Server Anywhere и Oracle9i. Также эта редакция поддерживает авторизацию пользователей, группы пользователей, блокировку элементов. Эта версия предназначена для больших команд.

На рисунке 9 представлен интерфейс программы Enterprise Architect.

Рисунок 9. Интерфейс программы Enterprise Architect

Существует версия EA Lite FREE read-only. Она позиционируется как решение, позволяющее зарегистрированным пользователям демонстрировать UML-диаграммы персоналу и заказчикам. EA Lite имеет все базовые функции Enterprise Architect, за исключением создания документации и сохранения. По сути, это вьюер файлов Enterprise Architect.

С EA отлично интегрируется другой продукт Sparx Systems - Zicom Mentor. Zicom Mentor - это ПО для обучения UML, которое поможет пользователям мгновенно получить ответы на свои вопросы, получить и проверить знание UML, начать новый UML-проект.

Zicom Mentor включает интерактивные курсы и тесты, документацию и справочные материалы по UML, а также визуальный словарь UML, справочник по диаграммам и символам и др. [5]

2.2 Visual paradigm

Visual Paradigm Suite - это набор средств для моделирования информационных систем и бизнес-процессов, генерации кода на базе построенных моделей, проектирования БД и решения многих других задач.

В пакет Visual Paradigm Suite 5.0 входят следующие инструменты:

1. Visual Paradigm for UML 8.0
2. Business Process Visual Architect 4.0
3. Visual Paradigm SDE
4. Agilian 3.0 
5. Database Visual Architect 6.0

VP for UML – это система управления требованиями, поддерживающая полный цикл разработки программного продукта – анализ, дизайн архитектуры, разработка программного кода, тестирование и размещение продукта на стороне заказчика.  VP также обеспечивает поддержку версионности и одновременной работы команды пользователей над одним проектом.

В целом, VP for UML является прямым конкурентом небезызвестного Enterprise Architect от компании Sparx Systems.

VP for UML предоставляет широкие возможности для создания и организации требований. Для создания моделей аналитик в рамках одного проекта может описывать требования, одновременно используя такие стандарты и нотации моделирования, как UML, BMPN, OMG, Mind Maps и ArchiMate. Это является большим плюсом, так как, используя VP for UML, не нужно переключаться между большим количеством программ для создания моделей в различных нотациях, а описание требований различными методами и нотациями должно лишь облегчить понимание проекта.

Функциональные возможности системы:

1. Построение диаграмм 

Моделирование диаграмм реализовано на довольно высоком уровне, и все элементы интуитивно находятся под рукой. Имеется панель инструментов, на которой располагаются элементы для выбранного типа диаграммы (Use Case, Activity, Mind Map и т.д.). Добавление новых элементов можно осуществлять из «всплывающего» меню, которое становится доступным при выборе любого элемента, уже добавленного на диаграмму, что значительно сокращает время, затрачиваемое на создание диаграммы. (см. рисунок 10)

Рисунок 10. Диаграмма вариантов использования в программе Visual Paradigm

Также необходимо отметить две дополнительные функции, которых не хватает в большинстве других системах для Use Case моделирования – Magnet и Sweeper. На рисунке 11 представлена часть инструментов ситсемы.

Рисунок 11. Инструменты Magnet и Sweeper

Sweeper раздвигает элементы, создавая тем самым больше рабочего пространства для добавления новых элементов на диаграмму. Magnet позволяет сократить пространство между элементами диаграммы, что является весьма удобным при экспорте диаграммы в текстовый документ.

Добавление спецификации к элементам диаграммы существенно напоминает Enterprise Architect, правда у актеров, выполняющих действие, отсутствует разделение по типам (Actor, System). (см. рисунок 12)