ВВедение в ИМЛ. Лекция 2 Что такое The uml

• Название: Лекция 2 Что такое The uml
• Анкор: ВВедение в ИМЛ
• Дата: 10.03.2023
• Размер: 2.99 Mb.
• Имя файла: vvedenie_v_UML (1).docx
• Тип: Лекция; #978338
• страница: 5 из 24

Диаграмма активности (деятельности, activity diagram)

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

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



Рис. 2.21.
Многие из нас именно так начинают свой день, не правда ли? Обратите внимание на то, как изображено параллельное пение и принятие душа, - на обычной блок-схеме это было бы невозможно! А вот еще пример():



Рис. 2.22.
И опять все понятно - это оформление заказа в интернет-магазине! Ну и напоследок еще одна диаграмма ().


Рис. 2.23.
Догадались, что она описывает? Сможете отличить этот тип диаграмм? Тогда пошли дальше!

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

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

операционной системы. Корпоративные приложения часто требуют для своей работы

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

неплохо бы иметь графическоепредставление инфраструктуры,накоторуюбудет

развернуто приложение. Вот для этого-то и нужны диаграммы развертывания, которые иногда называют диаграммами размещения.

Думаю, очевидно, что такиедиаграммыестьсмыслстроитьтолькодляаппаратно-

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

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

представление ИТ-инфраструктуры может помочь более рационально распределить компонентысистемыпо узламсети, от чего, как известно, зависит в том числе и производительность

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

Диаграммаразвертывания показывает топологию системы и распределение компонентов

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

приведем пример ():

Рис. 2.24.

Думаем, и без объяснений понятно, что описывает эта диаграмма. А вот диаграммаразвертывания с большим количеством узлов ().

Рис. 2.25.

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

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

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

примеров уже достаточно, чтобы вы научились распознавать этот вид диаграмм, ведь правда? Если да, то пойдем дальше.

ООП и последовательность построения диаграмм

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

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

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

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

• 
  Какие именно виды диаграмм лучше всего отражают архитектуру системы и возможные технические риски, связанные с проектом?
  
• 
  Какие из диаграмм удобнее всего превратить в инструмент контроля над процессом (и прогрессом) разработки системы?
  

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

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

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

В UML-проектировании, как и при создании любых других моделей, важно

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

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

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

стройте модели статической части задач.

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

Не забываем, что мы говорим, прежде всего, именно об объектноориентированных системах.

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

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

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

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

последовательность!

И напоследок еще несколько советов относительно использования UML.

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

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

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

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

UMLсодержит некоторые средства расширения. Подумайте, как можно приспособить язык

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

Кроме прочего, важным моментом здесь является выбор пакета UML-моделирования (CASE- средства), что тоже может повлиять на ваш индивидуальный стиль проектирования. Более

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

Выводы

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

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

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

Рис. 2.4.

Из всего сказанного выше становится понятно, что диаграммыпрецедентовотносятся к той

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

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

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

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