МодСистЛЕКЦ / Унифицированный язык моделирования UML

8Основы унифицированного языка моделирования

Существует достаточно много методов формализованного представления результатов анализа и проектирования. В настоящее время широкое применение нашел Унифицированный язык моделирования (Unified Modeling Language).

UML объединяет средства трех наиболее распространенных методов: Буча, ОМТ (Object Modeling Language) и вариантов использования и дополняет их новыми средствами.

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

• модель требований к системе;

• модель статической структуры классов системы и отношений между классами;

• модели поведения системы;

• модель взаимодействия объектов;

• диаграммы состояний;

• диаграммы действий;

• модель реализации системы;

Все перечисленные модели взаимосвязаны. Так, например, объекты, определенные в модели статической структуры классов, входят в состав объектов других моделей.

Язык находится в процессе стандартизации. Благодаря своим достоинствам он стал стандартом де-факто для средств графического моделирования.

UML представляет собой систему элементов, между которыми устанавливаются отношения. Его элементами являются понятия объектной модели: классы, объекты, компоненты, атрибуты, связи. Нотация UML содержит стандартный набор диаграмм.

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

Язык можно использовать на всех стадиях анализа и проектирования искомой системы.

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

Модель статической структуры классов используется при моделировании предметной области и построении объектной модели системы. Она показывает статические отношения между классами: отношения наследования, включения и ассоциации. На диаграммах классы изображаются в виде прямоугольника, разделенного на три части, в которых записываются названия класса, его операции и атрибуты. Прямоугольники соединяются линиями, которые отражают тип отношения между классами.

Заказ

Дата

Оплачен

Отправить

Набор

Имя

Включить

Заказчик

Имя

Адрес

Кредит

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

Объект 1 Объект2 Объект3

открыть форму

проверить заказ

заказ выполнен

закрыть форму

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

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

Формы диаграмм состояний могут незначительно отличаться друг от друга их семантикой.

На рис. 1 приведен пример построения диаграммы состояний.

Начало

Проверка позиции Выдача заказа

заказа

Выполнить Выполнить

Рис. 1 Диаграмма состояний.

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

Ниже приведен пример диаграммы действий.

ПРИНЯТЬ

ЗАКАЗ

ПРОВЕРИТЬ

НАЛИЧИЕ

НАБОРА

ВЫПОЛНИТЬ

ЗАКАЗ

Рис. 2 Диаграмма действий.

Диаграммы действий обычно применяют для описания сложных методов. Их применяют и для описания вариантов использования.

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

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

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

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

Системы моделирования объектно-ориентированных программ.

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

UML является представителем объектно-ориентированных методов построения моделей прогрммного обеспечения ИС. Появление данного языка и его широкое распространение не означало прекращения применения других методов моделирования программных систем. К последним прежде всего следует отнести метод иерархического объектно- ориентированного проектирования ( HOOD – Hierarchical Object-Oriented Design), объектно-ориентированный анализ Коада-Иордана, метод Шлаер-Меллора.

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

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

-уровень субъектов;

-уровень объектов и классов;

-структурный уровень;

-уровень атрибутов;

-уровень операций.

Более низкий уровень является уточнением предыдущего.

Разработка модели начинается с анализа предметной области. Затем определяется состав основных понятий программной системы. Вторым шагом моделирования системы является определение объектов и классов.

Субъекты системы – это группы классов и объектов. Они служат для облегчения понимания системы в целом.

Метод Шлаера-Меллора предназначен для построения интегрированного набора моделей. Строятся три основные и пять вспомогательных (порожденных) моделей. Основными моделями служат информационная модель, модель состояний и модель спецификации действий. К вспомогательным моделям относятся:

• модель отношений подсистем, которая показывает, как объекты в разных подсистемах связаны между собой;

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

• модель связи объектов, которая показывает, как происходит асинхронная передача событий между объектами, включенными в модель состояний;

• модель доступа подсистем, описывающая синхронный доступ к данным, находящимся в разных подсистемах;

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

Информационная модель описывает объекты предметной области, а также отношения между ними.

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

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

Все модели взаимосвязаны. Взаимосвязь моделей показана на рис. 1.

Информационные Модели Модели

Состояние заказчика

Ссост.1

Сост.2

Наличие товара

Имеется

Отсутствует

Информационная

Модель

Заказчик

Отдел

Заказов

Дей твия при

Том или

Другом

состоянии

Модели состояний спецификаций действий

Рис. 1 Взаимосвязь моделей.

Метод Шлаера-Меллора включает в себя помимо языка моделирования и определение процесса моделирования. Процесс состоит из следующих этапов:

• разделение на домены;

• анализ доменов;

• проверка анализа через эмуляцию;

• определение трансляции моделей анализа;

• построение компонент трансляций;

• трансляция моделей доменов в исходный текст программ.

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

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

• диаграммы классов;

• диаграммы наследования, показывающие структуру наследования свойств классов;

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

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

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

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

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

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

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

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

Объектная декомпозиция позволяет существенно повысить уровень унификации разрабатываемых модулей системы, а значит, и их пригодность для многократного использования. Этим самым решается проблема ускорения создания ИС путем многократного использования ранее разработанного программного обеспечения. Безусловно, структурный подход предоставляет возможность многократного употребления готовых функциональных модулей. Но поскольку, во-первых, существует разделение процессов и данных на отдельные структуры, то не удается в полной мере использовать преимущество применения уже существующего программного обеспечения, а следовательно, и резко ускорить создание новых систем. Главная же причина этого лежит в том, что библиотеки классов принципиально отличаются от библиотек функций.

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

Применение библиотек классов позволяет существенно уменьшить трудоемкость создания ИС. Однако необходимость сопряжения языка программирования, на котором они написаны, с языком основной программы практически сводят на нет многие положительные свойства библиотеки. Например, классы созданные на разных языках программирования, не могут наследовать свои свойства.

Чтобы в полной мере использовать положительные стороны библиотек классов, применяют специальные модули, называемые компонентами. Компонента – это объект, объединяющий в себе и интерфейс и состояние. При этом состояние компоненты может быть изменено с помощью вызываемых методов. Компонента содержит два интерфейса: интерфейс времени проектирования и интерфейс времени выполнения. Первый предназначен для того, чтобы узнать, каков интерфейс выполнения. Он позволяет включать компоненту в конкретную среду программирования, опрашивать ее во время выполнения с целью определения ее методов. Управляет работой компоненты интерфейс выполнения.

Достоинством компонент является то, что совершенно не важно, на каком языке реализованы программы. Объектно-ориентированные языки программирования поддерживают применение компонент.

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

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

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