Информационное обеспечение дизайн проектирования


"Информационное обеспечение дизайн проектирования" диаграмма активнотсей

СЕВЕРО-КАВКАЗСКИЙ ГУМАНИТАРНО-ТЕХНИЧЕСКИЙ ИНСТИТУТ

Кафедра Информатики и вычислительной техники

Лекция № 9

по учебной дисциплине:

"Информационное обеспечение дизайн проектирования"

ДИАГРАММА АКТИВНОТСЕЙ

для студентов специальности:

"Прикладная информатика в дизайне".

г. Ставрополь 2010

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

Мы уже говорили, диаграммы активностей (Activity Diagrams) являются представлением алгоритмов неких действий (активностей), выполняющихся в системе. Мы уже знаем, что как нотация UML предлагает пять представлений системы:

  • Вид системы с точки зрения прецедентов.

  • Вид с точки зрения проектирования.

  • Вид с точки зрения процессов.

  • Вид с точки зрения развертывания.

  • Вид с точки зрения реализации.

И при этом каждый из перечисленных способов представления системы может содержать последовательности действий, которые могут быть описаны с помощью алгоритмов. Вот здесь-то и выходят на сцену диаграммы деятельностей. Вообще говоря, любой элемент модели, имеющий динамическое поведение, может быть дополнен диаграммой деятельности - именно для уточнения этой самой динамики. Как хорошо подходящий по контексту пример следует упомянуть возможность применения диаграмм активности для описания бизнес-процессов, существующих в компании (нотации Grapes-BM, BPML/BPMN и др.). Вот уж где самая что ни на есть динамика!

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

Именно на диаграмме деятельности представлены переходы потока управления от одной деятельности к другой. Это, по сути, разновидность диаграммы состояний, где все или большая часть состояний являются некоторыми деятельностями, а все или большая часть переходов срабатывают при завершении определенной деятельности и позволяют перейти к выполнению следующей. Как мы уже говорили (повторение - мать учения), диаграмма деятельности может быть присоединена к любому элементу модели, имеющему динамическое поведение. Кстати, исходя из вышесказанного, логичнее говорить не "диаграмма деятельности", а "диаграмма деятельностей" - во множественном числе. А еще мы предполагаем, что читатель понимает смысл понятий "деятельность", "переход" и "объект". Об объектах как об экземплярах классов мы уже говорили ранее. Понятия же деятельности (activity) как протяженного во времени составного (неатомарного) вычисления (действия, action) и перехода как передачи контроля, надеемся, понятны интуитивно, без дополнительных объяснений.

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

Как говорится, лучше один раз увидеть, чем сто раз услышать. Мы достаточно разрекламировали диаграммы деятельностей. Пора взглянуть на пример (рис. 1).

Рис. 1.

Эта диаграмма довольно точно описывает ежеутреннюю последовательность действий автора этих строк (до момента ухода на работу). Как видим, все очень просто и понятно. Действия показаны скругленными прямоугольниками, как в блок-схеме, - мы узнаем даже ромбик символа принятия решения с обозначениями условий возле переходов. Да, отличия от блок-схемы не так уж сильны. Более того, эти отличия выглядят как логичное расширение нотации блок-схем. Обратим внимание на то, что начало и конец уже не изображаются одинаковым безликим кружком. Начало теперь закрашено, а конец изображен в виде символа, напоминающего кошачий глаз (рис. 4.2) (кстати, это образное название - "кошачий глаз" - уже намертво въелось в жаргон архитекторов и аналитиков).

Рис. 2.

Без пояснений понятен также смысл символа, предшествующего принятию душа и пению и следующего за ними - он означает распараллеливание, а затем опять слияние воедино (синхронизацию) потоков управления, т. е. операции "пение" и "душ" выполняются одновременно. Нотация проста: несколько потоков управления сливаются в один или один поток разделяется на несколько. Третьего не дано (рис. 3).

Рис. 3.

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

Рис. 4.

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

Аналогия с дорожками действительно очень удачна. Именно таково официальное название элемента нотации UML, позволяющего указать распределение ролей на диаграмме активностей. Только дорожки это не беговые, а плавательные - они так и называются: swimlines. Более формально, дорожка - часть области диаграммы деятельности, на которой отображаются только те деятельности, за которые отвечает конкретный объект.

Рис. 5.

 

Предназначены они для разбиения диаграммы в соответствии с распределением ответственности за действия. Имя дорожки может означать роль или объект, которому она соответствует. При использовании дорожек нотация слегка изменяется. Вот как, к примеру, выглядит диаграмма из предыдущего примера, перерисованная с использованием дорожек (рис. 5).

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

Есть еще один нюанс нотации диаграмм активностей, о котором мы пока не говорили: это так называемая траектория объекта, или поток объекта (object flow). Суть его состоит в том, что на диаграмме деятельности можно изобразить и объекты, относящиеся к деятельности. С помощью символа зависимости (пунктирная стрелка, помните?) эти объекты можно соотнести с той деятельностью или переходом, где они создаются, изменяются или уничтожаются. Представим такую ситуацию из повседневной жизни: вы приходите в какой-нибудь фастфуд и заказываете гамбургер с колой. Что, знакомо? Во время приготовления завтрака повар создает новый объект - гамбургер. Пока вы нетерпеливо выпиваете колу, официант перемещает этот объект (подает ваш заказ). Естественно, во время завтрака вы уничтожаете этот объект. Вот как это выглядит на диаграмме (рис. 6).

Рис. 6.

На этом можно было бы и закончить наш разговор о нотации диаграмм активностей и их отличиях от блок-схем. Если бы не одно НО. Мы говорили, что деятельность - это протяженное по времени составное действие. Составное! То есть составленное из более простых действий. Вот эти-то самые простые (атомарные) действия, а вернее, последовательность их выполнения, частенько изображают внутри деятельности в виде маленькой диаграммы активностей. Это слегка напоминает матрешку - одна (а часто и не одна) диаграмма внутри другой. Мы не будем долго говорить об этом: нашей целью было просто обратить внимание читателя на подобную возможность "вложенных" диаграмм. Мы просто покажем пример, позаимствованный нами из Zicom Mentor (рис. 7).

Рис. 7.

Диаграмма описывает высадку пассажиров самолета, достигших пункта назначения, и посадку новых пассажиров. Предлагаем читателю самому внимательно рассмотреть эту диаграмму. Из нее, например, можно почерпнуть, что конечных состояний может быть больше одного. Кстати, кроме начального и конечного состояний есть еще конечное состояние потока (Flow final mode). От конечного состояния оно отличается вот чем: конечное состояние потока означает завершение одного потока управления, а конечное состояние говорит о завершении всех потоков управления внутри деятельности. Обозначается конечное состояние потока простым символом, напоминающим лампочку накаливания в схемах электрических цепей (рис. 8):

Рис. 8.

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

Примеры использования таких диаграмм

На практике диаграммы деятельности применяются в основном двумя способами:

  1. Для моделирования процессов

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

  1. Для моделирования операций

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

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

Моделируют бизнес-процессы в несколько этапов, первым из которых является разбиение их на подпроцессы. Подпроцессы, являющиеся "участками большого процесса", описать легче. А там, глядишь, и составится целое из частей. Дальше выделяют ключевые объекты (и создают для них дорожки), определяют предусловия и постусловия каждого процесса (т. е. его границы), описывают деятельности и переходы, отображают на диаграммах состояния ключевых объектов, в которые они переходят в ходе процесса. Все это звучит довольно сложно, а на практике происходит еще сложнее: ведь создается не какая-то абстрактная диаграмма, а модель реального бизнес-процесса в реальной компании, занимающейся реальным бизнесом, где цена ошибки может быть очень высока. Чтобы окончательно не запугать читателя, приведем просто пример использования диаграммы активностей для описания процесса разработки ПО в OpenUP (рис. 9):

Рис. 9.

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

А теперь перейдем к рассмотрению моделирования операций с помощью диаграмм активностей. Как мы уже говорили, в этом случае диаграмма активностей превращается в "продвинутую" блок-схему, предоставляющую дополнительные возможности, например, отображение параллельно выполняющихся операций. Возникает соблазн попытаться выполнить кодогенерацию такой диаграммы или даже откомпилировать ее и сразу получить выполняемый файл. Поспешим отметить, что вы не одиноки в таком желании - попыток создать пакет для генерации приложений непосредственно из диаграмм UML было предпринято множество. Некоторые даже оказались более-менее удачными - вспомним, например, Rational Rose Real Time. Таким образом, при моделировании операций UML становится языком визуального программирования!

Приведем пример моделирования одной из базовых алгоритмических конструкций, например, цикла с постусловием (рис. 10):

Рис. 10.

Ну что, почувствовали себя опять студентом?

Советы по построению диаграмм активностей

Процесс построения диаграммы активностей можно описать в виде последовательности таких действий:

  1. Составление перечня деятельностей в системе

Как исходные данные для этой операции хорошо подходит список прецедентов (или список операций - см. два способа использования диаграмм деятельности). Дополняться диаграммой активности может каждый сценарий использования. Можно также попытаться описать связь между ними.

  1. Принятие решения о необходимости построения диаграммы деятельностей

Несмотря на то что вы уже начали работу в этом направлении, вы все же можете решить отказаться от продолжения построения диаграммы деятельностей. Причины тому могут быть различными, например, система одномоментно меняет свои состояния (как светофор) или ее поведение достаточно очевидно. (Помните пример с циклом с постусловием? Наверняка многие читатели подумали: "Зачем моделировать такие простые и очевидные вещи?". Теперь вы знаете зачем - чтобы показать нецелесообразность этого.)

  1. Определение зависимостей между деятельностями

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

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

Выделите активности, имеющие общих предшественников. Зачем - думаем, и так понятно.

  1. Определение условий переходов

Сформулируйте выражения, которые могут принимать только два значения - "истинно" или "ложно", соответствующие альтернативным потокам управления. Теперь вы знаете, что писать рядом с символами принятия решений!

  1. Уточните сложные деятельности

Повторите пункты 1-6 для каждой из деятельностей (при необходимости). Помните пример с посадкой/высадкой пассажиров самолета? Присмотритесь внимательно, возможно, в проектируемой вами диаграмме тоже будет нелишним применить "принцип матрешки". А как это работает на практике? Да легко! Рассмотрим, например, моделирование пословицы "После драки кулаками не машут":

  1. Выделяем деятельности: драться, махать кулаками.

  2. Следует ли строить диаграмму в этом случае? Вообще-то нет. Но ведь это пример!

  3. Определяем зависимости между деятельностями: размахивание кулаками не происходит после драки.

  4. Определяем параллельные деятельности: вроде бы тут таких не наблюдается...

  5. Определяем условия переходов: драка состоялась? Если "нет", то машем кулаками, если "да", то нет.

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

Посмеялись? А теперь попробуйте все это смоделировать. Правда, легко? Ведь все уже разложено по полочкам - только рисуй! А что относительно процесса построения диаграмм активностей говорят классики? Тот же Буч, например, писал:

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

Выводы
  • Диаграммой деятельности можно дополнить любой элемент модели, имеющий динамическое поведение.

  • Диаграммы деятельности являются частным случаем диаграммы состояний.

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

  • На диаграммах активности можно использовать плавательные дорожки, распределяющие деятельности в соответствии с ролями (объектами), их выполняющими.

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

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

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

Контрольные вопросы
  1. Какие еще виды диаграмм (кроме диаграмм активностей) можно использовать для моделирования динамики системы?

  2. Чем диаграммы деятельности отличаются от блок-схем? Какие преимущества это сулит разработчикам?

  3. Что такое траектория объекта?

  4. Чем конечное состояние потока отличается от конечного состояния деятельности?

  5. Чем моделирование процессов отличается от моделирования операций?

  6. Применимы ли диаграммы деятельности безотносительно к ООП?

gigabaza.ru

Вдля студентов специальности:"Прикладная информатика в дизайне"

СЕВЕРО-КАВКАЗСКИЙ ГУМАНИТАРНО-ТЕХНИЧЕСКИЙ ИНСТИТУТ

Кафедра Информатики и вычислительной техники

Лекция № 6

по учебной дисциплине:"Информационное обеспечение дизайн проектирования"

ДИАГРАММА ПРЕЦЕНДЕНТОВ

для студентов специальности:

"Прикладная информатика в дизайне".

г. Ставрополь 2010

Цель лекции:

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

План лекции:
  1. Требования к диаграмме
  2. Диаграммы прецедентов и их нотация

Содержание лекции

1. Требования к диаграмме

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

Если обратиться к классикам, например, к той же "банде трех" (Якобсон, Буч, Рамбо), мы узнаем, что требование - это желаемая функциональность, свойство или поведение системы. Именно со сбора требований начинается процесс разработки ПО. Если изобразить процесс разработки ПО в виде "черного ящика" (уверены, читатель знает, что это такое, если нет - "Википедия" к вашим услугам), на выходе которого мы получаем программный продукт, то на вход этого "черного ящика" будет подаваться именно набор требований к программному продукту (рис. 1)!

Рис. 1.Кстати, какую диаграмму напоминает этот рисунок? Правильно, диаграмму активностей. И выбор именно этой диаграммы тут абсолютно оправдан - помните, мы говорили, что диаграммы активностей часто используют для описания бизнес-процессов? Единственный нюанс: обычно процесс разработки не заканчивается с выпуском программного продукта - грядет новая итерация, новые, уточненные требования, новая версия и т. д.

Кстати, вернемся к требованиям. Да, мы сказали, что на вход нашего "черного ящика" подается набор требований. Но в какой форме? Как их документируют, эти требования? Думаю, большинство читателей помнит, что такое техническое задание - основной документ, без составления которого не начинался в советские времена ни один проект. Документ это был большой, многостраничный, с четкой структурой, определяемой ГОСТами (государственными отраслевыми стандартами). И описывал он, по сути, не что иное, как требования к создаваемой системе!

Техническое задание - вещь по-своему хорошая. Но время шло, менялись стандарты, нотации, способы описания требований. И вот постепенно техническое задание уступило место набору артефактов, состоящему из документов двух видов:

  • диаграммы прецедентов;
  • нефункциональные требования.

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

Нефункциональные требования - это описание таких свойств системы, как особенности среды и реализации, производительность, расширяемость, надежность и т. д. Часто нефункциональные требования не привязаны к конкретному варианту использования и потому выносятся в отдельный список дополнительных требований к системе (рис. 6.2).

Рис. 2. Но вернемся же к прецедентам (вариантам использования). Идентифицировать прецеденты и действующие лица - обязанность системного аналитика. И делает он это для того, чтобы:

  • четко разграничить систему и ее окружение;
  • определить, какие действующие лица и как именно взаимодействуют с системой, какой функционал (варианты использования) ожидается от системы;
  • определить и описать в словаре предметной области (глоссарии) общие понятия, которые необходимы для детального описания функционала системы (прецедентов).
Подобный вид деятельности обычно выполняется в такой последовательности:
  1. Определение действующих лиц.
  2. Определение прецедентов.
  3. Составление описания каждого прецедента.
  4. Описание модели прецедентов в целом (этот этап включает в себя создание словаря предметной области).
Вначале требования оформляются в виде обычного текстового документа, который создается или самим пользователем, или пользователем и разработчиком вместе. Далее требования оформляют в виде таблицы. В левую колонку помещают прецеденты, а в правую - действующих лиц, участвующих в прецеденте.

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

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

Прецедент Действующее лицо
разместить меню секретарь
ознакомиться с меню сотрудник, секретарь, офис-менеджер
сделать заказ сотрудник, секретарь, офис-менеджер
сформировать счет офис-менеджер

оплатить счет

офис-менеджер

Здесь нигде не сказано о том, что система должна быть написана на ASP.NET. Почему - понятно: это ведь нефункциональное требование! И еще, очевидно, что секретарь и офис-менеджер тоже являются сотрудниками. Читатель, внимательно прочитавший предыдущие лекции, заподозрит, что в данном случае, создавая модель прецедентов, говоря о действующих лицах, можно бы применить генерализацию. Действительно, диаграмма прецедентов, построенная на основе этой таблицы, может быть, например, такой (рис. 3):

Рис. 3.

birmaga.ru

Йдля студентов специальности:"Прикладная информатика в дизайне"

СЕВЕРО-КАВКАЗСКИЙ ГУМАНИТАРНО-ТЕХНИЧЕСКИЙ ИНСТИТУТ

Кафедра Информатики и вычислительной техники

Лекция № 9

по учебной дисциплине:"Информационное обеспечение дизайн проектирования"

ДИАГРАММА АКТИВНОТСЕЙ для студентов специальности:

"Прикладная информатика в дизайне".

г. Ставрополь 2010

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

Мы уже говорили, диаграммы активностей (Activity Diagrams) являются представлением алгоритмов неких действий (активностей), выполняющихся в системе. Мы уже знаем, что как нотация UML предлагает пять представлений системы:

  • Вид системы с точки зрения прецедентов.
  • Вид с точки зрения проектирования.
  • Вид с точки зрения процессов.
  • Вид с точки зрения развертывания.
  • Вид с точки зрения реализации.
И при этом каждый из перечисленных способов представления системы может содержать последовательности действий, которые могут быть описаны с помощью алгоритмов. Вот здесь-то и выходят на сцену диаграммы деятельностей. Вообще говоря, любой элемент модели, имеющий динамическое поведение, может быть дополнен диаграммой деятельности - именно для уточнения этой самой динамики. Как хорошо подходящий по контексту пример следует упомянуть возможность применения диаграмм активности для описания бизнес-процессов, существующих в компании (нотации Grapes-BM, BPML/BPMN и др.). Вот уж где самая что ни на есть динамика!

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

Именно на диаграмме деятельности представлены переходы потока управления от одной деятельности к другой. Это, по сути, разновидность диаграммы состояний, где все или большая часть состояний являются некоторыми деятельностями, а все или большая часть переходов срабатывают при завершении определенной деятельности и позволяют перейти к выполнению следующей. Как мы уже говорили (повторение - мать учения), диаграмма деятельности может быть присоединена к любому элементу модели, имеющему динамическое поведение. Кстати, исходя из вышесказанного, логичнее говорить не "диаграмма деятельности", а "диаграмма деятельностей" - во множественном числе. А еще мы предполагаем, что читатель понимает смысл понятий "деятельность", "переход" и "объект". Об объектах как об экземплярах классов мы уже говорили ранее. Понятия же деятельности (activity) как протяженного во времени составного (неатомарного) вычисления (действия, action) и перехода как передачи контроля, надеемся, понятны интуитивно, без дополнительных объяснений.

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

Как говорится, лучше один раз увидеть, чем сто раз услышать. Мы достаточно разрекламировали диаграммы деятельностей. Пора взглянуть на пример (рис. 1).

Рис. 1. Эта диаграмма довольно точно описывает ежеутреннюю последовательность действий автора этих строк (до момента ухода на работу). Как видим, все очень просто и понятно. Действия показаны скругленными прямоугольниками, как в блок-схеме, - мы узнаем даже ромбик символа принятия решения с обозначениями условий возле переходов. Да, отличия от блок-схемы не так уж сильны. Более того, эти отличия выглядят как логичное расширение нотации блок-схем. Обратим внимание на то, что начало и конец уже не изображаются одинаковым безликим кружком. Начало теперь закрашено, а конец изображен в виде символа, напоминающего кошачий глаз (рис. 4.2) (кстати, это образное название - "кошачий глаз" - уже намертво въелось в жаргон архитекторов и аналитиков).

Рис. 2.

Без пояснений понятен также смысл символа, предшествующего принятию душа и пению и следующего за ними - он означает распараллеливание, а затем опять слияние воедино (синхронизацию) потоков управления, т. е. операции "пение" и "душ" выполняются одновременно. Нотация проста: несколько потоков управления сливаются в один или один поток разделяется на несколько. Третьего не дано (рис. 3).

Рис. 3.

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

Рис. 4. Смысл диаграммы вполне понятен и без дополнительных объяснений. Как вы уже, конечно, догадались, на ней показана работа с веб-приложением, которое решает некую задачу в удаленной базе данных. Привлекает внимание странное расположение активностей на этой диаграмме: они как бы разбросаны по трем беговым дорожкам, каждая из которых соответствует поведению одного из трех объектов - клиента, веб-сервера и сервера баз данных. Благодаря этому легко определить, каким из объектов выполняется каждая из активностей, и неожиданно приходит понимание того, что "странность" этой диаграммы, оказывается, очень упрощает ее восприятие.

Аналогия с дорожками действительно очень удачна. Именно таково официальное название элемента нотации UML, позволяющего указать распределение ролей на диаграмме активностей. Только дорожки это не беговые, а плавательные - они так и называются: swimlines. Более формально, дорожка - часть области диаграммы деятельности, на которой отображаются только те деятельности, за которые отвечает конкретный объект.

Рис. 5.

 

Предназначены они для разбиения диаграммы в соответствии с распределением ответственности за действия. Имя дорожки может означать роль или объект, которому она соответствует. При использовании дорожек нотация слегка изменяется. Вот как, к примеру, выглядит диаграмма из предыдущего примера, перерисованная с использованием дорожек (рис. 5).

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

Есть еще один нюанс нотации диаграмм активностей, о котором мы пока не говорили: это так называемая траектория объекта, или поток объекта (object flow). Суть его состоит в том, что на диаграмме деятельности можно изобразить и объекты, относящиеся к деятельности. С помощью символа зависимости (пунктирная стрелка, помните?) эти объекты можно соотнести с той деятельностью или переходом, где они создаются, изменяются или уничтожаются. Представим такую ситуацию из повседневной жизни: вы приходите в какой-нибудь фастфуд и заказываете гамбургер с колой. Что, знакомо? Во время приготовления завтрака повар создает новый объект - гамбургер. Пока вы нетерпеливо выпиваете колу, официант перемещает этот объект (подает ваш заказ). Естественно, во время завтрака вы уничтожаете этот объект. Вот как это выглядит на диаграмме (рис. 6).

Рис. 6. На этом можно было бы и закончить наш разговор о нотации диаграмм активностей и их отличиях от блок-схем. Если бы не одно НО. Мы говорили, что деятельность - это протяженное по времени составное действие. Составное! То есть составленное из более простых действий. Вот эти-то самые простые (атомарные) действия, а вернее, последовательность их выполнения, частенько изображают внутри деятельности в виде маленькой диаграммы активностей. Это слегка напоминает матрешку - одна (а часто и не одна) диаграмма внутри другой. Мы не будем долго говорить об этом: нашей целью было просто обратить внимание читателя на подобную возможность "вложенных" диаграмм. Мы просто покажем пример, позаимствованный нами из Zicom Mentor (рис. 7).

Рис. 7. Диаграмма описывает высадку пассажиров самолета, достигших пункта назначения, и посадку новых пассажиров. Предлагаем читателю самому внимательно рассмотреть эту диаграмму. Из нее, например, можно почерпнуть, что конечных состояний может быть больше одного. Кстати, кроме начального и конечного состояний есть еще конечное состояние потока (Flow final mode). От конечного состояния оно отличается вот чем: конечное состояние потока означает завершение одного потока управления, а конечное состояние говорит о завершении всех потоков управления внутри деятельности. Обозначается конечное состояние потока простым символом, напоминающим лампочку накаливания в схемах электрических цепей (рис. 8):

Рис. 8.

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

Примеры использования таких диаграмм

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

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

Моделируют бизнес-процессы в несколько этапов, первым из которых является разбиение их на подпроцессы. Подпроцессы, являющиеся "участками большого процесса", описать легче. А там, глядишь, и составится целое из частей. Дальше выделяют ключевые объекты (и создают для них дорожки), определяют предусловия и постусловия каждого процесса (т. е. его границы), описывают деятельности и переходы, отображают на диаграммах состояния ключевых объектов, в которые они переходят в ходе процесса. Все это звучит довольно сложно, а на практике происходит еще сложнее: ведь создается не какая-то абстрактная диаграмма, а модель реального бизнес-процесса в реальной компании, занимающейся реальным бизнесом, где цена ошибки может быть очень высока. Чтобы окончательно не запугать читателя, приведем просто пример использования диаграммы активностей для описания процесса разработки ПО в OpenUP (рис. 9):

Рис. 9. Выглядит, конечно, не совсем так, как мы привыкли, но все же, сомнений не остается - да, это именно диаграмма активностей. Нотация слегка отличается, но все понятно и без дополнительных пояснений.

А теперь перейдем к рассмотрению моделирования операций с помощью диаграмм активностей. Как мы уже говорили, в этом случае диаграмма активностей превращается в "продвинутую" блок-схему, предоставляющую дополнительные возможности, например, отображение параллельно выполняющихся операций. Возникает соблазн попытаться выполнить кодогенерацию такой диаграммы или даже откомпилировать ее и сразу получить выполняемый файл. Поспешим отметить, что вы не одиноки в таком желании - попыток создать пакет для генерации приложений непосредственно из диаграмм UML было предпринято множество. Некоторые даже оказались более-менее удачными - вспомним, например, Rational Rose Real Time. Таким образом, при моделировании операций UML становится языком визуального программирования!

Приведем пример моделирования одной из базовых алгоритмических конструкций, например, цикла с постусловием (рис. 10):

Рис. 10. Ну что, почувствовали себя опять студентом?

Советы по построению диаграмм активностей

Процесс построения диаграммы активностей можно описать в виде последовательности таких действий:
  1. Составление перечня деятельностей в системе
Как исходные данные для этой операции хорошо подходит список прецедентов (или список операций - см. два способа использования диаграмм деятельности). Дополняться диаграммой активности может каждый сценарий использования. Можно также попытаться описать связь между ними.
  1. Принятие решения о необходимости построения диаграммы деятельностей
Несмотря на то что вы уже начали работу в этом направлении, вы все же можете решить отказаться от продолжения построения диаграммы деятельностей. Причины тому могут быть различными, например, система одномоментно меняет свои состояния (как светофор) или ее поведение достаточно очевидно. (Помните пример с циклом с постусловием? Наверняка многие читатели подумали: "Зачем моделировать такие простые и очевидные вещи?". Теперь вы знаете зачем - чтобы показать нецелесообразность этого.)
  1. Определение зависимостей между деятельностями
Для каждой активности нужно найти активности, непосредственно предшествующие (и следующие за ней тоже), то есть активности, без выполнения которых поток управления не может перейти к данной деятельности.
  1. Выделение параллельных потоков деятельностей
Выделите активности, имеющие общих предшественников. Зачем - думаем, и так понятно.
  1. Определение условий переходов
Сформулируйте выражения, которые могут принимать только два значения - "истинно" или "ложно", соответствующие альтернативным потокам управления. Теперь вы знаете, что писать рядом с символами принятия решений!
  1. Уточните сложные деятельности
Повторите пункты 1-6 для каждой из деятельностей (при необходимости). Помните пример с посадкой/высадкой пассажиров самолета? Присмотритесь внимательно, возможно, в проектируемой вами диаграмме тоже будет нелишним применить "принцип матрешки". А как это работает на практике? Да легко! Рассмотрим, например, моделирование пословицы "После драки кулаками не машут":
  1. Выделяем деятельности: драться, махать кулаками.
  2. Следует ли строить диаграмму в этом случае? Вообще-то нет. Но ведь это пример!
  3. Определяем зависимости между деятельностями: размахивание кулаками не происходит после драки.

  4. Определяем параллельные деятельности: вроде бы тут таких не наблюдается...
  5. Определяем условия переходов: драка состоялась? Если "нет", то машем кулаками, если "да", то нет.
  6. Уточняем сложные деятельности: при драке машут не только кулаками, но и ногами. А еще можно пинаться головой и использовать подручные средства, мебель, например. Плюс можно выделить еще подготовительные деятельности (выбор места для нападения) и завершающие (вынос раненых).
Посмеялись? А теперь попробуйте все это смоделировать. Правда, легко? Ведь все уже разложено по полочкам - только рисуй! А что относительно процесса построения диаграмм активностей говорят классики? Тот же Буч, например, писал:

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

Выводы

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

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

  1. Какие еще виды диаграмм (кроме диаграмм активностей) можно использовать для моделирования динамики системы?
  2. Чем диаграммы деятельности отличаются от блок-схем? Какие преимущества это сулит разработчикам?
  3. Что такое траектория объекта?
  4. Чем конечное состояние потока отличается от конечного состояния деятельности?
  5. Чем моделирование процессов отличается от моделирования операций?
  6. Применимы ли диаграммы деятельности безотносительно к ООП?

birmaga.ru

Прикладная информатика в дизайне"

СЕВЕРО-КАВКАЗСКИЙ ГУМАНИТАРНО-ТЕХНИЧЕСКИЙ ИНСТИТУТ

Кафедра Информатики и вычислительной техники

Лекция № 5

по учебной дисциплине:"Информационное обеспечение дизайн проектирования"

ВИДЫ ДИАГРАММ UML

для студентов специальности:

"Прикладная информатика в дизайне".

г. Ставрополь 2010

Цель лекции:

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

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

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

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

  1. Терминология.
  2. Виды диаграмм.
  3. Диаграмма прецедентов (use case diagram).
  4. Диаграмма классов (class diagram).
  5. Диаграмма объектов (object diagram).
  6. Диаграмма последовательностей (sequence diagram).
  7. Диаграмма взаимодействия (кооперации, collaboration diagram).
  8. Диаграмма состояний (statechart diagram).
  9. Диаграмма активности (деятельности, activity diagram).
  10. Диаграмма развертывания (deployment diagram).
  11. Последовательность построения диаграмм.

Содержание лекции

1 ТЕРМИНОЛОГИЯ

Для начала определимся с терминологией. В предисловии к этой лекции мы неоднократно использовали понятия системы, модели и диаграммы.

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

Да, не слишком информативно. А что же такое тогда подсистема? Чтобы прояснить ситуацию, обратимся к классикам:

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

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

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

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

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

Модель - это некий (материальный или нет) объект, отображающий лишь наиболее значимые для данной задачи характеристики системы. Модели бывают разные - материальные и нематериальные, искусственные и естественные, декоративные и математические...

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

В ходе медицинских исследований опыты на животных часто предшествуют клиническим испытаниям медицинских препаратов на людях. В таком случае животное выступает в роли материальной естественной модели человека.

Уравнение, изображенное выше - тоже модель, но это модель математическая, и описывает она движение материальной точки под действием силы тяжести.

Осталось лишь сказать, что такое диаграмма. Диаграмма - это графическое представление множества элементов. Обычно изображается в виде графа с вершинами (сущностями) и ребрами (отношениями). Примеров диаграмм можно привести множество. Это и знакомая нам всем со школьных лет блок-схема, и схемы монтажа различного оборудования, которые мы можем видеть в руководствах пользователя, и дерево файлов и каталогов на диске, которое мы можем увидеть, выполнив в консоли Windows команду tree, и многое-многое другое. В повседневной жизни диаграммы окружают нас со всех сторон, ведь рисунок воспринимается нами легче, чем текст...

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

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

birmaga.ru

Йдля студентов специальности:"Прикладная информатика в дизайне"

СЕВЕРО-КАВКАЗСКИЙ ГУМАНИТАРНО-ТЕХНИЧЕСКИЙ ИНСТИТУТ

Кафедра Информатики и вычислительной техники

Лекция № 9

по учебной дисциплине:"Информационное обеспечение дизайн проектирования"

ДИАГРАММА АКТИВНОТСЕЙ для студентов специальности:

"Прикладная информатика в дизайне".

г. Ставрополь 2010

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

Мы уже говорили, диаграммы активностей (Activity Diagrams) являются представлением алгоритмов неких действий (активностей), выполняющихся в системе. Мы уже знаем, что как нотация UML предлагает пять представлений системы:

  • Вид системы с точки зрения прецедентов.
  • Вид с точки зрения проектирования.
  • Вид с точки зрения процессов.
  • Вид с точки зрения развертывания.
  • Вид с точки зрения реализации.
И при этом каждый из перечисленных способов представления системы может содержать последовательности действий, которые могут быть описаны с помощью алгоритмов. Вот здесь-то и выходят на сцену диаграммы деятельностей. Вообще говоря, любой элемент модели, имеющий динамическое поведение, может быть дополнен диаграммой деятельности - именно для уточнения этой самой динамики. Как хорошо подходящий по контексту пример следует упомянуть возможность применения диаграмм активности для описания бизнес-процессов, существующих в компании (нотации Grapes-BM, BPML/BPMN и др.). Вот уж где самая что ни на есть динамика!

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

Именно на диаграмме деятельности представлены переходы потока управления от одной деятельности к другой. Это, по сути, разновидность диаграммы состояний, где все или большая часть состояний являются некоторыми деятельностями, а все или большая часть переходов срабатывают при завершении определенной деятельности и позволяют перейти к выполнению следующей. Как мы уже говорили (повторение - мать учения), диаграмма деятельности может быть присоединена к любому элементу модели, имеющему динамическое поведение. Кстати, исходя из вышесказанного, логичнее говорить не "диаграмма деятельности", а "диаграмма деятельностей" - во множественном числе. А еще мы предполагаем, что читатель понимает смысл понятий "деятельность", "переход" и "объект". Об объектах как об экземплярах классов мы уже говорили ранее. Понятия же деятельности (activity) как протяженного во времени составного (неатомарного) вычисления (действия, action) и перехода как передачи контроля, надеемся, понятны интуитивно, без дополнительных объяснений.

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

Как говорится, лучше один раз увидеть, чем сто раз услышать. Мы достаточно разрекламировали диаграммы деятельностей. Пора взглянуть на пример (рис. 1).

Рис. 1. Эта диаграмма довольно точно описывает ежеутреннюю последовательность действий автора этих строк (до момента ухода на работу). Как видим, все очень просто и понятно. Действия показаны скругленными прямоугольниками, как в блок-схеме, - мы узнаем даже ромбик символа принятия решения с обозначениями условий возле переходов. Да, отличия от блок-схемы не так уж сильны. Более того, эти отличия выглядят как логичное расширение нотации блок-схем. Обратим внимание на то, что начало и конец уже не изображаются одинаковым безликим кружком. Начало теперь закрашено, а конец изображен в виде символа, напоминающего кошачий глаз (рис. 4.2) (кстати, это образное название - "кошачий глаз" - уже намертво въелось в жаргон архитекторов и аналитиков).

Рис. 2.

Без пояснений понятен также смысл символа, предшествующего принятию душа и пению и следующего за ними - он означает распараллеливание, а затем опять слияние воедино (синхронизацию) потоков управления, т. е. операции "пение" и "душ" выполняются одновременно. Нотация проста: несколько потоков управления сливаются в один или один поток разделяется на несколько. Третьего не дано (рис. 3).

Рис. 3.

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

Рис. 4. Смысл диаграммы вполне понятен и без дополнительных объяснений. Как вы уже, конечно, догадались, на ней показана работа с веб-приложением, которое решает некую задачу в удаленной базе данных. Привлекает внимание странное расположение активностей на этой диаграмме: они как бы разбросаны по трем беговым дорожкам, каждая из которых соответствует поведению одного из трех объектов - клиента, веб-сервера и сервера баз данных. Благодаря этому легко определить, каким из объектов выполняется каждая из активностей, и неожиданно приходит понимание того, что "странность" этой диаграммы, оказывается, очень упрощает ее восприятие.

Аналогия с дорожками действительно очень удачна. Именно таково официальное название элемента нотации UML, позволяющего указать распределение ролей на диаграмме активностей. Только дорожки это не беговые, а плавательные - они так и называются: swimlines. Более формально, дорожка - часть области диаграммы деятельности, на которой отображаются только те деятельности, за которые отвечает конкретный объект.

Рис. 5.

 

Предназначены они для разбиения диаграммы в соответствии с распределением ответственности за действия. Имя дорожки может означать роль или объект, которому она соответствует. При использовании дорожек нотация слегка изменяется. Вот как, к примеру, выглядит диаграмма из предыдущего примера, перерисованная с использованием дорожек (рис. 5).

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

Есть еще один нюанс нотации диаграмм активностей, о котором мы пока не говорили: это так называемая траектория объекта, или поток объекта (object flow). Суть его состоит в том, что на диаграмме деятельности можно изобразить и объекты, относящиеся к деятельности. С помощью символа зависимости (пунктирная стрелка, помните?) эти объекты можно соотнести с той деятельностью или переходом, где они создаются, изменяются или уничтожаются. Представим такую ситуацию из повседневной жизни: вы приходите в какой-нибудь фастфуд и заказываете гамбургер с колой. Что, знакомо? Во время приготовления завтрака повар создает новый объект - гамбургер. Пока вы нетерпеливо выпиваете колу, официант перемещает этот объект (подает ваш заказ). Естественно, во время завтрака вы уничтожаете этот объект. Вот как это выглядит на диаграмме (рис. 6).

Рис. 6. На этом можно было бы и закончить наш разговор о нотации диаграмм активностей и их отличиях от блок-схем. Если бы не одно НО. Мы говорили, что деятельность - это протяженное по времени составное действие. Составное! То есть составленное из более простых действий. Вот эти-то самые простые (атомарные) действия, а вернее, последовательность их выполнения, частенько изображают внутри деятельности в виде маленькой диаграммы активностей. Это слегка напоминает матрешку - одна (а часто и не одна) диаграмма внутри другой. Мы не будем долго говорить об этом: нашей целью было просто обратить внимание читателя на подобную возможность "вложенных" диаграмм. Мы просто покажем пример, позаимствованный нами из Zicom Mentor (рис. 7).

Рис. 7. Диаграмма описывает высадку пассажиров самолета, достигших пункта назначения, и посадку новых пассажиров. Предлагаем читателю самому внимательно рассмотреть эту диаграмму. Из нее, например, можно почерпнуть, что конечных состояний может быть больше одного. Кстати, кроме начального и конечного состояний есть еще конечное состояние потока (Flow final mode). От конечного состояния оно отличается вот чем: конечное состояние потока означает завершение одного потока управления, а конечное состояние говорит о завершении всех потоков управления внутри деятельности. Обозначается конечное состояние потока простым символом, напоминающим лампочку накаливания в схемах электрических цепей (рис. 8):

Рис. 8.

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

Примеры использования таких диаграмм

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

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

Моделируют бизнес-процессы в несколько этапов, первым из которых является разбиение их на подпроцессы. Подпроцессы, являющиеся "участками большого процесса", описать легче. А там, глядишь, и составится целое из частей. Дальше выделяют ключевые объекты (и создают для них дорожки), определяют предусловия и постусловия каждого процесса (т. е. его границы), описывают деятельности и переходы, отображают на диаграммах состояния ключевых объектов, в которые они переходят в ходе процесса. Все это звучит довольно сложно, а на практике происходит еще сложнее: ведь создается не какая-то абстрактная диаграмма, а модель реального бизнес-процесса в реальной компании, занимающейся реальным бизнесом, где цена ошибки может быть очень высока. Чтобы окончательно не запугать читателя, приведем просто пример использования диаграммы активностей для описания процесса разработки ПО в OpenUP (рис. 9):

Рис. 9. Выглядит, конечно, не совсем так, как мы привыкли, но все же, сомнений не остается - да, это именно диаграмма активностей. Нотация слегка отличается, но все понятно и без дополнительных пояснений.

А теперь перейдем к рассмотрению моделирования операций с помощью диаграмм активностей. Как мы уже говорили, в этом случае диаграмма активностей превращается в "продвинутую" блок-схему, предоставляющую дополнительные возможности, например, отображение параллельно выполняющихся операций. Возникает соблазн попытаться выполнить кодогенерацию такой диаграммы или даже откомпилировать ее и сразу получить выполняемый файл. Поспешим отметить, что вы не одиноки в таком желании - попыток создать пакет для генерации приложений непосредственно из диаграмм UML было предпринято множество. Некоторые даже оказались более-менее удачными - вспомним, например, Rational Rose Real Time. Таким образом, при моделировании операций UML становится языком визуального программирования!

Приведем пример моделирования одной из базовых алгоритмических конструкций, например, цикла с постусловием (рис. 10):

Рис. 10. Ну что, почувствовали себя опять студентом?

Советы по построению диаграмм активностей

Процесс построения диаграммы активностей можно описать в виде последовательности таких действий:
  1. Составление перечня деятельностей в системе
Как исходные данные для этой операции хорошо подходит список прецедентов (или список операций - см. два способа использования диаграмм деятельности). Дополняться диаграммой активности может каждый сценарий использования. Можно также попытаться описать связь между ними.
  1. Принятие решения о необходимости построения диаграммы деятельностей
Несмотря на то что вы уже начали работу в этом направлении, вы все же можете решить отказаться от продолжения построения диаграммы деятельностей. Причины тому могут быть различными, например, система одномоментно меняет свои состояния (как светофор) или ее поведение достаточно очевидно. (Помните пример с циклом с постусловием? Наверняка многие читатели подумали: "Зачем моделировать такие простые и очевидные вещи?". Теперь вы знаете зачем - чтобы показать нецелесообразность этого.)
  1. Определение зависимостей между деятельностями
Для каждой активности нужно найти активности, непосредственно предшествующие (и следующие за ней тоже), то есть активности, без выполнения которых поток управления не может перейти к данной деятельности.
  1. Выделение параллельных потоков деятельностей
Выделите активности, имеющие общих предшественников. Зачем - думаем, и так понятно.
  1. Определение условий переходов
Сформулируйте выражения, которые могут принимать только два значения - "истинно" или "ложно", соответствующие альтернативным потокам управления. Теперь вы знаете, что писать рядом с символами принятия решений!
  1. Уточните сложные деятельности
Повторите пункты 1-6 для каждой из деятельностей (при необходимости). Помните пример с посадкой/высадкой пассажиров самолета? Присмотритесь внимательно, возможно, в проектируемой вами диаграмме тоже будет нелишним применить "принцип матрешки". А как это работает на практике? Да легко! Рассмотрим, например, моделирование пословицы "После драки кулаками не машут":
  1. Выделяем деятельности: драться, махать кулаками.
  2. Следует ли строить диаграмму в этом случае? Вообще-то нет. Но ведь это пример!
  3. Определяем зависимости между деятельностями: размахивание кулаками не происходит после драки.

  4. Определяем параллельные деятельности: вроде бы тут таких не наблюдается...
  5. Определяем условия переходов: драка состоялась? Если "нет", то машем кулаками, если "да", то нет.
  6. Уточняем сложные деятельности: при драке машут не только кулаками, но и ногами. А еще можно пинаться головой и использовать подручные средства, мебель, например. Плюс можно выделить еще подготовительные деятельности (выбор места для нападения) и завершающие (вынос раненых).
Посмеялись? А теперь попробуйте все это смоделировать. Правда, легко? Ведь все уже разложено по полочкам - только рисуй! А что относительно процесса построения диаграмм активностей говорят классики? Тот же Буч, например, писал:

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

Выводы

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

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

  1. Какие еще виды диаграмм (кроме диаграмм активностей) можно использовать для моделирования динамики системы?
  2. Чем диаграммы деятельности отличаются от блок-схем? Какие преимущества это сулит разработчикам?
  3. Что такое траектория объекта?
  4. Чем конечное состояние потока отличается от конечного состояния деятельности?
  5. Чем моделирование процессов отличается от моделирования операций?
  6. Применимы ли диаграммы деятельности безотносительно к ООП?

www.birmaga.ru

Прикладная информатика в дизайне"

СЕВЕРО-КАВКАЗСКИЙ ГУМАНИТАРНО-ТЕХНИЧЕСКИЙ ИНСТИТУТ

Кафедра Информатики и вычислительной техники

Лекция № 5

по учебной дисциплине:"Информационное обеспечение дизайн проектирования"

ВИДЫ ДИАГРАММ UML

для студентов специальности:

"Прикладная информатика в дизайне".

г. Ставрополь 2010

Цель лекции:

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

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

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

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

  1. Терминология.
  2. Виды диаграмм.
  3. Диаграмма прецедентов (use case diagram).
  4. Диаграмма классов (class diagram).
  5. Диаграмма объектов (object diagram).
  6. Диаграмма последовательностей (sequence diagram).
  7. Диаграмма взаимодействия (кооперации, collaboration diagram).
  8. Диаграмма состояний (statechart diagram).
  9. Диаграмма активности (деятельности, activity diagram).
  10. Диаграмма развертывания (deployment diagram).
  11. Последовательность построения диаграмм.

Содержание лекции

1 ТЕРМИНОЛОГИЯ

Для начала определимся с терминологией. В предисловии к этой лекции мы неоднократно использовали понятия системы, модели и диаграммы.

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

Да, не слишком информативно. А что же такое тогда подсистема? Чтобы прояснить ситуацию, обратимся к классикам:

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

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

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

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

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

Модель - это некий (материальный или нет) объект, отображающий лишь наиболее значимые для данной задачи характеристики системы. Модели бывают разные - материальные и нематериальные, искусственные и естественные, декоративные и математические...

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

В ходе медицинских исследований опыты на животных часто предшествуют клиническим испытаниям медицинских препаратов на людях. В таком случае животное выступает в роли материальной естественной модели человека.

Уравнение, изображенное выше - тоже модель, но это модель математическая, и описывает она движение материальной точки под действием силы тяжести.

Осталось лишь сказать, что такое диаграмма. Диаграмма - это графическое представление множества элементов. Обычно изображается в виде графа с вершинами (сущностями) и ребрами (отношениями). Примеров диаграмм можно привести множество. Это и знакомая нам всем со школьных лет блок-схема, и схемы монтажа различного оборудования, которые мы можем видеть в руководствах пользователя, и дерево файлов и каталогов на диске, которое мы можем увидеть, выполнив в консоли Windows команду tree, и многое-многое другое. В повседневной жизни диаграммы окружают нас со всех сторон, ведь рисунок воспринимается нами легче, чем текст...

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

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

www.birmaga.ru

Введение в UMLдля студентов специальности:"Прикладная информатика в дизайне"

СЕВЕРО-КАВКАЗСКИЙ ГУМАНИТАРНО-ТЕХНИЧЕСКИЙ ИНСТИТУТ

Кафедра Информатики и вычислительной техники

Лекция № 3

по учебной дисциплине:"Информационное обеспечение дизайн проектирования"

Введение в UML

для студентов специальности:

"Прикладная информатика в дизайне".

г. Ставрополь 2010

Вступительная часть:

Цель лекции:

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

План лекции:

  1. Назначение языка.
  2. Историческая справка
  3. Способы использования языка.
  4. Структура определения языка

Содержание лекции

1. НАЗНАЧЕНИЕ ЯЗЫКА

UML - унифицированный язык моделирования. Из этих трех слов главным является слово "язык". Что же такое язык? Не будем изобретать велосипед, а лучше заглянем в глоссарий, благо в Интернете их величайшее множество. Сделав это, мы скорее всего обнаружим определение, подобное приведенному ниже.

Язык - система знаков, служащая:

  • средством человеческого общения и мыслительной деятельности;
  • способом выражения самосознания личности;
  • средством хранения и передачи информации.
Язык включает в себя набор знаков (словарь) и правила их употребления и интерпретации (грамматику). К этому достаточно исчерпывающему определению нужно добавить, что языки бывают естественные и искусственные, формальные и неформальные. UML - язык формальный и искусственный, хотя, как мы увидим далее, этот ярлык к нему не совсем подходит. Искусственный он потому, что у него имеются авторы, о которых мы еще не раз упомянем в дальнейшем (в то же время, развитие UML непрерывно продолжается, что ставит его в один ряд с естественными языками). Формальным его можно назвать, поскольку имеются правила его употребления (правда, описание UML содержит и явно неформальные элементы, как мы, опять-таки, позже увидим). Еще один нюанс: UML - язык графический, что также немного путает ситуацию!

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

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

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

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

Подводя итоги, кратко можно сказать, что UML - искусственный язык, который имеет некоторые черты естественного языка, и формальный язык, который имеет черты неформального. Это звучит не очень понятно, но это действительно так!

2. Историческая справка

Откуда взялся The UML? Если говорить коротко, то UML вобрал в себя черты нотаций Грейди Буча (Grady Booch), Джима Румбаха (Jim Rumbaugh), Айвара Якобсона (Ivar Jacobson) и многих других.

В не такие уж и далекие 80-е годы было множество различных методологий моделирования. Каждая из них имела свои достоинства и недостатки, а также свою нотацию. То смутное время получило название "войны методов". Проблема в том, что разные люди использовали разные нотации, и для того чтобы понять, что описывает та или иная диаграмма, зачастую требовался "переводчик". Один и тот же символ мог означать в разных нотациях абсолютно разные вещи! На рисунке ниже можно увидеть лишь малую часть многообразия методов, которые существовали в то время и в какой-то мере повлияли на UML (рис. 1).

Рис. 1.

К тому же примерно в это же время (начало 80-х) стартовала "объектно-ориентированная эра". Все началось с появлением семейства языков программирования SmallTalk, которые применяли некоторые понятия языка Simula-67, использовавшегося в 60-х годах. Появление объектно-ориентированного подхода в первую очередь было обусловлено увеличением сложности задач. Объектно-ориентированный подход внес достаточно радикальные изменения в сами принципы создания и функционирования программ, но, в то же время, позволил существенно повысить производительность труда программистов, по-иному взглянуть на проблемы и методы их решения, сделать программы более компактными и легко расширяемыми. Как результат, языки, первоначально ориентированные на традиционный подход к программированию, получили ряд объектноориентированных расширений. Одной из первых, в середине 80-х, была фирма Apple со своим проектом Object Pascal. Кроме этого, объектно-ориентированный подход породил мощную волну и абсолютно новых программных технологий, вершинами которой стали такие общепризнанные сегодня платформы, как Microsoft .NET Framework и Sun Java.

Но самое главное, что появление ООП требовало удобного инструмента для моделирования, единой нотации для описания сложных программных систем. И вот "три амиго", три крупнейших специалиста, три автора наиболее популярных методов решили объединить свои разработки. В 1991-м каждый из "трех амиго" начал с написания книги, в которой изложил свой метод ООАП. Каждая методология была по-своему хороша, но каждая имела и недостатки. Так, метод Буча был хорош в проектировании, но слабоват в анализе. OMT Румбаха был, наоборот, отличным средством анализа, но плох в проектировании. И наконец, Objectory Якобсона был действительно хорош с точки зрения user experience, на который ни метод Буча, ни OMT не обращали особого внимания. Основной идеей Objectory было то, что анализ должен начинаться с прецедентов, а не с диаграммы классов, которые должны быть производными от них.

К 1994-му существовало 72 метода, или частные методики. Многие из них "перекрывались", т. е. использовали похожие идеи, нотации и т. д. Как уже говорилось выше, чувствовалась острая потребность, "социальный заказ" - закончить "войну методов" и объединить в одном унифицированном средстве все лучшее, что было создано в области моделирования.

А что сейчас? The UML живет и развивается. Сейчас мы имеем UML 2.0 и десятки CASE-средств, поддерживающих UML, о многих из которых будет рассказано в седьмой лекции. Вопреки популярному мнению, в наши дни Rational не владеет UML, но продолжает работать над ним. UML же принадлежит OMG, а сама Rational ныне является одним из подразделений IBM и фигурирует во всех документах как IBM Rational. UML же получил множество пакетов расширений, называемых профайлами и позволяющих использовать его для моделирования систем из специфических предметных областей.

Вот такая история!

3. СПОСОБЫ ИСПОЛЬЗОВАНИЯ ЯЗЫКА

И вот Румбах присоединился к Бучу в Rational Inc. Они объединили свои нотации и создали первую версию UML. В 1995 году на конференции OOPSLA они представили его как Unified Method, который потом и получил название UML. Чуть позже к ним присоединился Якобсон, который добавил к результатам их труда элементы Objectory и начал работу над Rational Unified Process (RUP). В 1997 году UML был отправлен в Object Management Group (OMG) для стандартизации. Кроме трех нотаций "трех амиго" UML вобрал в себя элементы многих других методологий, что опять-таки хорошо видно из рисунка, приведенного выше.

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

Рис. 2. Здесь мы видим все проблемы программной инженерии, в частности проблемы с коммуникацией и пониманием, вызванные отсутствием четкой спецификации создаваемого продукта. Так вот, авторы UML определяют его как графический язык моделирования общего назначения (т. е. его можно применять для проектирования чего угодно - от простой качели, как на рисунке, до сложного аппаратно-программного комплекса или даже космического корабля), предназначенный для спецификации, визуализации, проектирования и документирования всех артефактов, создаваемых в ходе разработки.

Итак, UML в первую очередь - это спецификации. Заглянем снова в глоссарий и обнаружим, что

Спецификация - подробное описание системы, которое полностью определяет ее цель и функциональные возможности. Различают:

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

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

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

Так вот, такие картинки с подписями наглядны и интуитивно понятны, причем почти однозначно понимаются любыми заинтересованными лицами, так что могут использоваться в качестве средства общения между людьми. UML позволяет создавать такие простые и понятные картинки (модели), описывающие систему с разных сторон, которые можно показать заказчику и обсудить с ним, т. е. служит средством коммуникации в команде. Посмотрите на рисунок ниже (рис. 3). Все ведь понятно, правда?

Рис. 3. Перейдем к проектированию. Да, UML позволяет строить модели программных систем (вообще говоря - ЛЮБЫХ систем). По этим моделям потом может производиться генерация каркасного кода проектируемых приложений. Более того, возможен процесс, который часто называют "реверс-инжинирингом", - т. е. создание UML-модели из существующего кода приложения. Не будем сейчас обсуждать качество получающегося кода или моделей при реверс-инжиниринге. Пока оно весьма далеко от идеала, но ведь технологии и инструменты постоянно совершенствуются, так что можно надеяться, что когда-нибудь мы сможем создавать приложения визуально, не прибегая к языку программирования, а пользуясь лишь UML...

И последнее из этого набора слов - "документирование". По большому счету, UML-модели сами по себе уже являются документами (и весьма понятными, даже для неспециалиста, как мы уже могли убедиться, посмотрев на предыдущий рисунок; кроме этого, как мы еще упомянем далее, модели UML являются XML-документами). Причем любой элемент на любой диаграмме может быть снабжен ноутсом - текстовым комментарием. Т. е. построение набора диаграмм уже является процессом документирования будущей системы. Более того, большинство инструментов UML-проектирования умеют извлекать текстовую информацию из моделей и генерировать относительно удобочитаемые тексты.

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

Теперь о том, для чего UML использовать нельзя, вернее, чем он не является. Во-первых, UML не является языком программирования, хотя существуют средства выполнения UML-моделей как интерпретируемого кода (Unimod, FLORA и др.) и возможна, как уже говорилось выше, кодогенерация. Несмотря на это, UML - средство не программирования, а моделирования, т. е. создания не программ, а моделей любого уровня абстракции для систем из любой предметной области. Во-вторых, UML не является и спецификацией какого бы то ни было инструмента моделирования, хотя такие инструменты (и в больших количествах) имеются. Например, TAU G2 (с помощью которого создано большинство диаграмм в этом курсе), Borland Together, Poseidon, Enterprise Architect, IBM Rational Rose, Dia, Visio и др. Каким образом то или иное CASE-средство реализует UML-моделирование, никак не регламентируется и определяется самими разработчиками этих инструментов. И, наконец, в-третьих, UML не является и моделью какого-либо процесса разработки, даже Rational Unified Process (RUP), который был описан именно с помощью UML (а точнее, с помощью SPEM - профайла UML). UML можно использовать независимо от того, какую методологию разработки ПО вы используете, и даже если вы вообще не пользуетесь никакой методологией!

4. СТРУКТУРА ОПРЕДЕЛЕНИЯ ЯЗЫКА

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

Как же определен UML? Довольно часто компиляторы и IDE языков программирования написаны с использованием этих же языков (вспомните хотя бы Turbo Pascal!). Подобный метод применяется и при описании UML. Авторы использовали так называемое четырехуровневое мета-моделирование. Первый уровень - это сами данные. Второй - это их модель, т. е., например, описание их в программе. Третий - метамодель, т. е. описание языка построения модели. Четвертый - мета-метамодель, т. е. описание языка, на котором описана метамодель. Для примера - следующий рисунок, позаимствованный из стандарта UML, показывает применение этого подхода к простым записям о котировках акций (рис. 4).

Рис. 4. UML, как уже говорилось выше, описывается подобным образом. Метамодель - описание самого языка, мета-метамодель - описание формализма, с помощью которого производится описание языка. Все это сопровождается комментариями на естественном языке и примерами моделей. Организованное таким образом описание UML распространяется OMG абсолютно свободно и "лежит" на сайте OMG, по адресу http://www.omg.org/. Этот грандиозный документ насчитывает около тысячи страниц, и неподготовленному читателю имеет смысл ознакомиться в нем лишь с первым и последним разделами (краткий обзор и словарь терминов). Зато, если человек уже знаком с UML, изучение метамодели языка - весьма интересное и полезное занятие.

Терминология и нотация

Вопрос терминологии в программной инженерии, а тем более РУССКОЙ (не говоря уже об украинской) терминологии, - вопрос сложный. Дело в том, что оригинальная терминология UML не всегда последовательна и довольно запутана. Русская же терминология еще не успела сложиться, ведь UML как технология проектирования сама по себе очень молода, да и русскоязычная литература по нему стала появляться, как всегда, с некоторым опозданием. Некоторые авторы пытаются каждый термин передать "осмысленными", "хорошими русскими словами", что не всегда удается. С точки зрения автора, искать русские аналоги уже привычных английских терминов - занятие ненужное и даже вредное: вспомните, как трудно было вам найти нужную команду в меню русского MS Office, если вы привыкли пользоваться английским (в таких случаях родной язык сильно замедляет работу). Поэтому, наверное, проще использовать транскрипцию и не изобретать велосипед! В конце концов, хорошие английские слова (даже записанные русскими буквами) так же хороши, как и хорошие русские!

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

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

Вообще же, в UML используется четыре вида элементов нотации:

  1. фигуры,
  2. линии,
  3. значки,
  4. надписи.
Разберем все по порядку. Фигуры используются "плоские" - прямоугольники, эллипсы, ромбы и т. д. Но есть одно исключение - как мы увидим далее, на диаграмме развертывания для обозначения узлов инфраструктуры применяется "трехмерное" изображение параллелепипеда. Это единственное исключение из правил. Внутри любой фигуры могут помещаться другие элементы нотации.

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

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

Кстати об инструментах рисования. Мы уже упоминали, что такое ПО существует, и далее мы рассмотрим этот вопрос более подробно (проведя сравнительные исследования), пока же скажем лишь о нескольких наиболее заметных программах этого класса. К таким пакетам можно отнести:

  • IBM Rational Rose;
  • Borland Together;
  • Gentleware Poseidon;
  • Microsoft Visio;
  • Telelogic TAU G2
  • StarUML.
Наиболее известными из этой пятерки являются Rational Rose и Together. Это действительно средства для проектирования, а не рисования, как Visio. Долгое время автор этих строк использовал Poseidon, благо имеется бесплатная Community edition-версия этого продукта. Так было до тех пор, пока на одной из конференций по программной инженерии он не увидел TAU G2 от Telelogic. О TAU все слышали, но никто его не видел. Это легендарное средство моделирования, которое сочетает в себе мощь и простоту использования, предоставляя уникальную возможность начальной верификации моделей. И хотя интерфейс TAU выглядит несколько аскетично, его возможности и удобство работы просто потрясают. Все диаграммы в этом курсе созданы именно с использованием TAU, любезно предоставленным фирмой Telelogic (см. http://www.telelogic.com/). Сейчас немного не к месту об этом говорить, но хочется упомянуть еще об одном чудесном продукте, который очень помог нам в написании этого курса. Это Zicom Mentor от Sparx Systems, выпустившего Enterprise Architect (см. http://www.sparxsystems.com.au/). Zicom Mentor - это простая и понятная утилита, представляющая собой словарь/ассистент по UML 2.0. Zicom Mentor ответит на ваши вопросы, поможет получить и проверить ваши знания, начать новый проект. Zicom Mentor включает интерактивные курсы, электронные книги и тесты и множество другой справочной информации по UML.

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

Выводы

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

Само собой разумеется, что знание UML не гарантирует построения разумных и понятных моделей, хотя и является для этого необходимым.

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

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

  1. Как расшифровывается аббревиатура UML?
  2. Какая версия UML является текущей?
  3. Кто были авторами UML?
  4. Чем НЕ является UML?
  5. Какие программные средства, поддерживающие UML, вы знаете?
  6. Используются ли в UML "трехмерные" фигуры

birmaga.ru