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

Лекция 3

Обзор видов диаграмм UML

Зачем строить диаграммы

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

Модели сложных систем строятся потому, что невозможно описать их полностью, " окинуть одним взглядом". Поэтому необходимо выделить лишь существенные для конкретной задачи свойства системы и строим ее модель, отображающую эти свойства. Метод объектно-ориентированного анализа позволяет описывать реальные сложные системы наиболее адекватным образом. Но с увеличением сложности систем возникает потребность в хорошей технологии моделирования. В качестве такой " стандартной" технологии используется унифицированный язык моделирования (Unified Modeling Language, UML), который является графическим языком для спецификации, визуализации, проектирования и документирования систем. С помощью UML можно разработать подробную модель создаваемой системы, отображающую не только ее концепцию, но и конкретные особенности реализации.

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

Лишь набор диаграмм составляет модель системы и наиболее полно ее описывает, но не одна диаграмма, вырванная из контекста.

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

UML 1.5 определял двенадцать типов диаграмм, разделенных на три группы:

· четыре типа диаграмм представляют статическую структуру приложения;

· пять представляют поведенческие аспекты системы;

· три представляют физические аспекты функционирования системы (диаграммы реализации).

Текущая версия UML 2.1 внесла не слишком много изменений. Диаграммы слегка изменились внешне ( появились фреймы и другие визуальные улучшения ), немного усовершенствовалась нотация, некоторые диаграммы получили новые наименования.

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

Важно понимать, что перечень диаграмм зависит от специфики разрабатываемого проекта и определяется самим разработчиком. Стандарт UML описывает все виды диаграмм: ( http: //www.omg.org/technology/documents/modeling_spec_catalog.htm#UML ).

Задача на данном этапе - разобраться с первоначальными представлениями об этой технологии.

Итак, мы кратко рассмотрим такие виды диаграмм, как:

· диаграмма прецедентов;

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

· диаграмма объектов;

· диаграмма последовательностей;

· диаграмма взаимодействия;

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

· диаграмма активности;

· диаграмма развертывания.

Основная задача – воспринимать и различать диаграммы визуально.

 

Заключение - ООП и последовательности построения диаграмм

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

Можно дать множество рекомендаций относительно того, какие же именно диаграммы строить и как, но мы будем краткими. Прежде всего, вы должны ответить для себя на такие вопросы:

· Какие именно виды диаграмм лучше всего отражают архитектуру системы и возможные технические риски, связанные с проектом?

· Какие из диаграмм удобнее всего превратить в инструмент контроля над процессом (и прогрессом) разработки системы?

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

Диаграммы, как уже говорилось выше, можно и нужно строить в некоторой логической последовательности. Но как выработать эту последовательность, если у вас нет опыта моделирования? Как научиться этому? Вот несколько простых приемов, которые помогут вам (или вашей команде) выработать свой стиль проектирования.

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

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

3. Стройте модели предметной области задачи в виде диаграммы классов! Это хороший способ понять, как визуализировать множества взаимосвязанных абстракций. Таким же образом стройте модели статической части задач.

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

Всё вышеназванное относится, прежде всего, именно к объектно-ориентированным системам.

 

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

· диаграмма прецедентов,

· диаграмма классов,

· диаграмма объектов,

· диаграмма последовательностей,

· диаграмма кооперации,

· диаграмма состояний,

· диаграмма активности,

· диаграмма развертывания.

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

Еще несколько советов относительно использования UML:

§ Хорошее и полезное упражнение - строить модели классов и отношений между ними для уже написанного вами кода на С++ или Java.

§ Применяйте UML для того, чтобы прояснить неявные детали реализации существующей системы или использованные в ней " хитрые механизмы программирования".

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

§ Обратите особое внимание на средства UML для моделирования компонентов, параллельности, распределенности, паттернов проектирования. Большинство из этих вопросов мы рассмотрим далее.

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

§ Кроме прочего, важным моментом здесь является выбор пакета UML моделирования (CASE-средства), что тоже может повлиять на ваш индивидуальный стиль проектирования. Более подробно мы поговорим об этом в одной из последующих лекций, пока же отметим, что все диаграммы, виденные вами в этой лекции, построены с помощью TAU G2 от Telelogic.

Окончательные выводы:

· Диаграммы разных видов позволяют взглянуть на систему с разных точек зрения.

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

· Недостаточно читать об UML - им надо пользоваться!

 

Контрольные вопросы

Почему нужно строить разные диаграммы при моделировании системы?

· Какие диаграммы соответствуют статическому представлению о системе?

· Вы разрабатываете компьютерную программу для игры в шахматы. Какая диаграмма UML была бы полезной в этом случае? Почему?

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

 

Лекция 3

Обзор видов диаграмм UML

Зачем строить диаграммы

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

Модели сложных систем строятся потому, что невозможно описать их полностью, " окинуть одним взглядом". Поэтому необходимо выделить лишь существенные для конкретной задачи свойства системы и строим ее модель, отображающую эти свойства. Метод объектно-ориентированного анализа позволяет описывать реальные сложные системы наиболее адекватным образом. Но с увеличением сложности систем возникает потребность в хорошей технологии моделирования. В качестве такой " стандартной" технологии используется унифицированный язык моделирования (Unified Modeling Language, UML), который является графическим языком для спецификации, визуализации, проектирования и документирования систем. С помощью UML можно разработать подробную модель создаваемой системы, отображающую не только ее концепцию, но и конкретные особенности реализации.

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

123Следующая ⇒

Поделиться: