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

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

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

Действия не могут быть подвергнуты декомпозиции. Более того, они атомарны – это означает, что события могут происходить, но внутреннее поведение действия невидимо. Невозможно выполнить только часть действия: оно либо выполняется целиком, либо не выполняется вообще. Наконец, часто предполагается, что время выполнения действий несущественно, хотя некоторые из них могут требовать ощутимых затрат времени.

Узел деятельности (activity node) – это организационная единица деятельности, которая представляет собой вложенную группу действий или других вложенных узлов. Более того, узлы деятельности имеют видимую подструктуру и, как правило, требуют некоторого времени на завершение. Действие можно представлять как частный случай узла деятельности. Точнее говоря, это такой узел деятельности, который не может быть подвергнут декомпозиции. Аналогичным образом узел деятельности можно рассматривать как композицию, поток управления которой состоит из других действий и узлов. Если погрузиться в детали внутреннего устройства узла деятельности, там можно обнаружить другую диаграмму деятельности. Нотация действия и узла деятельности одинакова, за исключением того, что последний может иметь дополнительные части, которые обычно поддерживаются инструментом редактирования за пределами диаграммы.

2.6. Диаграммы компонентов и диаграммы размещения

Диаграммы компонентов – это один из двух видов диаграмм, предназначенных для моделирования физических аспектов объектно-ориентированных систем. Диаграмма компонентов показывает организацию и зависимости между наборами компонентов.

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

Диаграммы компонентов важны не только для визуализации, специфицирования и документирования систем, основанных на компонентах, но также для конструирования исполняемых систем посредством прямого и обратного проектирования.

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

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

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

3. Для моделирования физических баз данных. Физическую базу данных можно представить как конкретную реализацию схемы, существующую на уровне битов. Схемы, по сути, описывают API (application programming interface, программный интерфейс приложения) для доступа к хранимой информации; модель же физической базы представляет способы хранения информации в таблицах реляционной базы или на страницах объектно-ориентированной базы данных. Для представления этих и иных физических баз данных можно использовать диаграммы компонентов.

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

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

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

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

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

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

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

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

2. Моделирование клиент-серверных (client/server) систем. Они представляют собой типичный пример архитектуры, в которой основное внимание уделяется четкому распределению обязанностей между интерфейсом пользователя, расположенном на клиенте, и хранимыми данными системы, размещаемыми на сервере. Клиент-серверные системы находятся на одном конце спектра распределенных систем и требуют от проектировщика принятия решений о том, как связать клиенты и серверы сетью, а также о том, как физически распределены программные компоненты между узлами. Диаграммы размещения позволяют моделировать топологию такой системы.

3. Моделирование полностью распределенных систем. На другом конце спектра распределенных систем находятся те из них, которые распределены широко или даже глобально (fully distributed) и охватывают серверы различных уровней. Нередко на таких системах устанавливаются разные версии программных компонентов, часть которых даже мигрирует с одного узла на другой. Проектирование подобной системы требует решений, которые допускают непрерывное изменение системной топологии. Диаграммы размещения можно использовать для визуализации текущей топологии и распределения компонентов системы, чтобы можно было аргументированно обсуждать влияние на нее различных изменений.

Раздел 3. Программные продукты, реализующие
объектно-ориентированный подход

Термином CASE-средства (аббревиатура от Computer Aided Software Engineering) обозначаются программные средства, которые поддерживают процессы создания и сопровождения информационных систем. Эти процессы включают (но не исчерпываются):

1. анализ и формулировку требований,
2. проектирование прикладного программного обеспечения (приложений) и баз данных,
3. тестирование генерацию кода,
4. обеспечение качества,
5. документирование,
6. конфигурационное управление и управление проектом.

Наиболее известен выпущенный фирмой Computer Associates (СА) интегральный пакет инструментальных средств, поддерживающих все этапы разработки информационных систем – AllFusion Modeling Suite. В этот пакет входит 5 продуктов:

1. AllFusion Process Modeler (прежнее наименование – BPwin).

2. AllFusion ERwin Data Modeler – инструмент создания моделей данных и генерации схем баз данных. Прежнее название – ERwin 4.1.

3. AllFusion Data Model Validator – система поиска и исправления ошибок модели данных. Прежнее название - ERwin Examiner.

4. AllFusion Model Manager – система организации коллективной работы, хранилище моделей BPwin и ERwin. Прежнее название – ModelMart 4.1.

5. AllFusion Component Modeler – инструмент создания объектных моделей. Прежнее название - Paradigm Plus.

AIIFusion Component Modeler является мощным объектно-ориентированным инструментальным средством, позволяющим эффективно генерировать код приложений.

AIIFusion Component Modeler поддерживает методологию CA Catalysis. Методология Catalysis основывается на стандарте объектного моделирования UML и специально ориентирована на технологию компонентной разработки. AIIFusion Component Modeler и Catalysis обеспечивают эффективные решения и минимальный риск при реализации крупномасштабных проектов, ориентированных на компонентную сборку.

AIIFusion Component Modeler 4.1 призван обеспечить полный технологический цикл разработки крупных ИС. С этой целью он интегрирован с целым рядом инструментальных средств СА и других фирм.

По умолчанию AIIFusion Component Modeler содержит несколько окон и инструментальных панелей:

• Workspace - навигатор модели.

• Property - окно (расположено слева внизу) отображает свойства элементов модели.

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

♦ Панель задач.

♦ Панель инструментов.

♦ Палитра инструментов (вид которой зависит от типа редактируемой диаграммы).

Каждое из окон можно переместить и скрыть (настройка видимости окон и панели инструментов производится в меню View).

Панель задач (task bar) по умолчанию расположена в левой верхней части основного окна AllFusion Component Modeler. Панель задач состоит из четырех разделов и позволяет организовать работу над проектом в соответствии с ролями разработчиков:

• Analyst (аналитик);

• Designer (дизайнер);

• Implementor (кодировщик);

• Reporting (создатель отчетов).

Для переключения на раздел панели задач следует щелкнуть по кнопке с названием раздела. Окно каждого раздела содержит список задач. Для создания новой задачи следует щелкнуть правой кнопкой мыши по окну панели задач и выбрать пункт меню Customize. Появляется диалог Task Ваг

Каждая задача представляет собой выполняемый скрипт, например на Visual Basic или Java. Для создания новой задачи необходимо щелкнуть по кнопке, внести в окно диалога Task Ваг имя задачи, затем щелкнуть по кнопке Browse и выбрать файл скрипта. Для включения задачи в раздел необходимо щелкнуть по Apply.

Окно Workspace имеет 3 вкладки – Models, Packages и Diagrams. Вкладка Models содержит древовидный список элементов модели, который является верхним уровнем представления модели. Вкладка Packages содержит список пакетов. Пакет является нижним уровнем модели и может включать задачи и другие модели, используемые в проекте. Вкладка Diagrams содержит список диаграмм модели.

Модель AIIFusion Component Modeler представляет собой совокупность диаграмм, описывающих различные аспекты структуры и поведения информационной системы. Для создания новой диаграммы следует перейти на вкладку Models окна Workspace Workspace и щелкнуть правой кнопкой мыши по модели, в которой создается новая диаграмма. В контекстном меню следует выбрать пункт New Diagram и затем тип диаграммы. AIIFusion Component Modeler позволяет создавать диаграммы восьми типов:

1. Activity (деятельности).

2. Class (классов).

3. Collaboration (кооперации).

4. Sequence (последовательности).

5. State (состояний).

6. UseCase (вариантов использования).

7. Component (компонентов).

8. Deployment (развертывания).

После выбора нужного типа в правой верхней части основного окна AIIFusion Component Modeler появляется окно редактора диаграмм (Diagram Editor).

AllFusion Component Modeler поддерживает генерацию кода приложения на основе диаграмм классов и создание классов на основе кода приложения, а именно прямое и обратное проектирования для четырех сред разработки: