- принципы использования - правила применения элементов в рамках построения тех или иных типов моделей ИС.

Построение визуальных моделей позволяет решить сразу несколько типичных проблем. Во-первых, технология визуального моделирования, позволяет работать со сложными и очень сложными системами и проектами. Во-вторых, визуальные модели позволяют содержательно организовать общение между заказчиками и разработчиками. Визуальное моделирование не является «серебряной пулей», способной раз и навсегда решить все проблемы, однако его использование существенно облегчает достижения таких целей как:

- повышение качества программного продукта,

- сокращение стоимости проекта,

- поставка системы в запланированные сроки.

Рис. 1. Пример диаграммы классов

При проектировании сложной ИС ее разбивают на части, каждая из которых затем рассматривается отдельно. Возможны два различных способа такого разбиения ИС на подсистемы: структурное (или функциональное) разбиение и объектная (компонентная) декомпозиция. Суть функционального разбиения хорошо отражена в известной формуле: “Программа=Данные + Алгоритмы”. При функциональной декомпозиции программной системы ее структура может быть описана блок-схемами, узлы которых представляют собой “обрабатывающие центры” (функции), а связи между узлами описывают движение данных. Объектное разбиение в последнее время называют компонентным, что нашло отражение в специальном термине: "разработка, основанная на компонентах" (Component Based Development - CBD). При этом используется иной принцип декомпозиции - система разбивается на “активные сущности” - объекты или компоненты, которые взаимодействуют друг с другом, обмениваясь сообщениями и выступая друг к другу в отношении “клиент/сервер”. Сообщения, которые может принимать объект, определены в его интерфейсе. В этом смысле посылка сообщения "объекту-серверу" эквивалентна вызову соответствующего метода объекта.

Так вот, если при проектировании информационная система разбивается на объекты (компоненты), то UML может быть использован для ее визуального моделирования. Если используется функциональная декомпозиция ИС, то UML не нужен, и следует использовать другие (структурные) нотации. С точки зрения визуального моделирования, UML можно охарактеризовать следующим образом. UML предоставляет выразительные средства для создания визуальных моделей, которые: единообразно понимаются всеми разработчиками, вовлеченными в проект и являются средством коммуникации в рамках проекта.

Унифицированный Язык Моделирования (UML): не зависит от объектно-ориентированных (ОО) языков программирования, не зависит от используемой методологии разработки проекта, может поддерживать любой ОО язык программирования. UML является открытым и обладает средствами расширения базового ядра. На UML можно содержательно описывать классы, объекты и компоненты в различных предметных областях, часто сильно отличающихся друг от друга.

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

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

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

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

При визуальном моделировании на UML используются восемь видов диаграмм, каждая из которых может содержать элементы определенного типа. Типы допустимых элементов и отношений между ними зависят от вида диаграммы. Рассмотрим некоторые диаграммы.

Диаграммы использования. Эти диаграммы описывают функциональность ИС, которая будет видна пользователям системы. "Каждая функциональность" изображается в виде "прецедентов использования" (use case) или просто прецедентов. Прецедент - это типичное взаимодействия пользователя с системой, которое при этом:

- описывает видимую пользователем функцию,

- может представлять различные уровни детализации,

- обеспечивает достижение конкретной цели, важной для пользователя.

Рис. 2. Элементы и отношения между ними на диаграмме классов

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

Диаграммы классов (class diagrams) описывают статическую структуру классов. Эти диаграммы могут описывать "словарь предметной области" на концептуальном уровне. С другой стороны, на детальном уровне (уровне спецификаций и уровне реализаций) диаграммы определяют структуру программных классов. Они используются для генерации каркасного программного кода на заданном языке программирования, а также для генерации SQL DDL предложений, определяющих логическую структуру реляционных таблиц БД.

Для описания динамики используются диаграммы поведения (behavior diagrams), которые подразделяются на диаграммы состояний (statechart diagrams), диаграммы активностей (activity diagrams) и диаграммы взаимодействия (interaction diagrams), состоящие из диаграмм последовательности (sequence diagrams), диаграмм взаимодействий (collaboration diagrams)

И, наконец, диаграммы реализации (implementation diagrams) состоят из компонентных диаграмм· (component diagrams) и диаграмм развертывания· (deployment diagrams). На рисунке 5 показаны элементы и отношения для диаграмм взаимодействий, диаграмм последовательности·и диаграмм состояний.

Рис. 3. Элементы и отношения для диаграмм взаимодействий, последовательности и состояний

Процесс проектирования с использованием той или иной визуальной нотации принято называть методологией проектирования, и все нотации, предшествующие UML, использовались в рамках соответствующей методологии. Методологию трудно стандартизировать, и UML - это только нотация, которая может использоваться в рамках разных методологий. Одной из таких методологий является Rational Unified Process (RUP) - методология фирмы Rational Software. RUP описывает успешно проверенные на практике подходы к созданию ИС и определяет организацию коллективной работы над проектом на основе следующих принципов:

- итерационная разработка проекта,

- управление требованиями,

- использование компонентной архитектуры,

- визуальное моделирование,

- тестирование качества ИС,

- контроль конфигураций и изменений в ИС.

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

1.3 Виды диаграмм UML

Графические изображения моделей системы в UML называются диаграммами. В терминах языка UML определены следующие их виды:

- диаграмма вариантов использования или прецедентов (use case diagram)

- диаграмма классов (class diagram)

- диаграммы поведения (behavior diagrams)

- диаграмма состояний (statechart diagram)

- диаграмма деятельности (activity diagram)

- диаграммы взаимодействия (interaction diagrams)

- диаграмма последовательности (sequence diagram)

- диаграмма кооперации (collaboration diagram)

- диаграммы реализации (implementation diagrams)

- диаграмма компонентов (component diagram)

- диаграмма развертывания (deployment diagram)

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

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

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

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

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

Графически состояние действия изображается прямоугольником с закругленными углами (рис. 5). Внутри этого изображения записывается выражение действия (action-expression), которое должно быть уникальным в пределах одной диаграммы деятельности.

Рис. 4. Изображение состояния действия

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

Иногда возникает необходимость представить на диаграмме деятельности некоторое сложное действие, которое, в свою очередь, состоит из нескольких более простых действий. В этом случае можно использовать специальное обозначение состояния под-деятельности (subactivity state). Такое состояние является графом деятельности и обозначается специальной пиктограммой в правом нижнем углу символа состояния действия (рис. 6). Эта конструкция может применяться к любому элементу языка UML, который поддерживает вложенность своей структуры. При этом пиктограмма может быть дополнительно помечена типом вложенной структуры.

Рис. 5. Изображение состояния под-деятельности

Страницы: 1, 2, 3, 4