Что такое UML?
Если посмотреть картинки в поисковых системах, то станет понятно, что UML – это что-то про схемы, стрелочки и квадратики. Что важно, что UML переводится как Unified Modeling Language . Важно тут слово Unified. То есть наши картинки поймём не только мы, но и остальные, кто знает UML. Получается это такой международный язык рисования схем.
Как гласит Википедия
UML - это язык графического описания для объектного моделирования в области разработки программного обеспечения, моделирования бизнес-процессов, системного проектирования и отображения организационных структур.Самое интересное, о чём не все задумываются или догадываются, UML имеет спецификации. Причём даже есть спецификация UML2. Подробнее со спецификацией можно ознакомиться на сайте Object Management Group . Собственно, эта группа и занимается разработкой спецификаций UML. Интересно и то, что UML не ограничивается описанием структуры классов. Существует множество типов UML диаграмм. Краткое описание типов UML диаграмм можно увидеть в той же Википедии: UML - диаграммы или в видео Тимура Батыршинова Обзор UML диаграмм . UML так же широко применяется при описании различных процессов, например здесь: Единый вход с использованием JWT . Возвращаясь к использованию UML диаграмм классов, стоит отметить книгу Head First: Паттерны проектирования , в которой паттерны иллюстрируются теми самыми UML диаграммами. Выходит, что UML действительно используется. И выходит, что знание и понимание его применения довольно полезный навык.
Применение
Разберём, как с этим самым UML можно работать из IDE. В качестве IDE возьмём IntelliJ Idea . Если использовать IntelliJ Idea Ultimate , то у нас "из коробки" будет установлен плагин "UML Support ". Он позволяет автоматически генерировать красивые диаграммы классов. Например, через Ctrl+N или пункт меню "Navigate" -> "Class" перейдём в класс ArrayList . Теперь, через контекстное меню по имени класса выберем "Diagram" -> "Show diagram popup". В результате мы получим красивую диаграмму:
Но что, если хочется самому нарисовать, да ещё и нет Ultimate версии Idea? Если мы используем IntelliJ Idea Community Edition, то у нас нет другого выбора. Для этого нужно понять, как такая UML схема устроена. Для начала нам понадобится установить Graphviz . Это набор утилит для визуализации графов. Его использует плагин, который мы будем применять. После установки необходимо добавить каталог bin из каталога установленного Graphviz в переменную среды окружения PATH . После этого в IntelliJ Idea в меню выбрать File -> Settings. В окне "Settings" выбрать категорию "Plugins", нажать кнопку "Browse repositories" и установить плагин PlantUML integration . Чем так хорош этот PlantUML ? Он использует для описания UML язык описания графов под названием "dot " и это позволяет ему быть более универсальным, т.к. данный язык используется не только PlantUML. Более того, всё что мы ниже сделаем мы можем выполнить не только в IDE, но и в онлайн сервисе planttext.com . После установки плагина PlantUML у нас появится возможность через "File" -> "New" создавать UML диаграммы. Давайте выполним создание диаграммы типа "UML class". В ходе этого автоматически генерируется шаблон с примером. Удалим его содержимое и создадим своё, вооружившись статьёй с Хабра: Отношения классов - от UML к коду . А чтобы понять, как это изобразить в тексте, возьмём мануал по PlantUML: plantuml class-diagram . В нём в самом начале представлена табличка с тем, как нужно описывать связи:
Про сами же связи можем ещё подсматривать сюда: "Отношения между классами в UML. Примеры ". На основе этих материалов приступим к созданию нашей UML диаграммы. Добавим следующее содержимое, описывающее два класса: @startuml class ArrayList { } class LinkedList { } @enduml Чтобы увидеть результат в Idea, выберем "View" -> "Tool Windows" -> "PlantUML". Мы получим просто два квадрата, обозначающие классы. Как мы знаем, оба эти класса реализуют интерфейс List. Данное отношение классов так и называют - реализация (realization). Для изображения такой связи используют стрелку с пунктирной линией. Изобразим её: interface List List < | . . ArrayList List < | . . LinkedList List - один из дочерних классов Collection . То есть он наследуется от Collection. Эта связь называется обобщением (generalization). Выглядит как стрелка с обычной непрерывной линией. Изобразим её: interface Collection Collection < | -- List Для следующего типа связи добавим в описание класса ArrayList запись о package private массиве элементов: ~ Object elementData Теперь мы хотим показать, что ArrayList содержит какие-то объекты. В данном случае будет тип связи - агрегация (aggregation). Агрегатом в данном случае является ArrayList , т.к. он содержит другие объекты. Агрегацию мы выбираем потому, что объекты в списке могут жить и без списка: они не являются его неотъемлемыми частями. Их время жизни не привязано к времени жизни списка. Агрегат с латинского переводится как "собранный", то есть что-то, составленное из чего-то. Например, в жизни, есть насосный агрегат, который состоит из насоса и двигателя. Сам агрегат можно разобрать, оставив что-то из его составных частей. Например, чтоб продать или поставить в другой агрегат. Так и в списке. И выражается это в виде пустого ромбика у агрегата и непрерывной линии. Изобразим это следующим образом: class Object { } ArrayList o- Object Теперь мы хотим показать, что в отличие от ArrayList , класс LinkedList содержит в себе Node - контейнеры, ссылающиеся на хранимые данные. В данном случае Node являются частью самого LinkedList и не могут жить отдельно. Node не является непосредственнохранимым содержимым, а только содержит ссылку на него. Например, когда мы добавляем в LinkedList какую-нибудь строку, мы добавляем новый Node , который содержит ссылку на эту строку, а также ссылку на предыдущий и следующий Node . Такой тип связи называется композицией (Composition). Для отображения у композита (того, кто состоит из частей) рисуется закрашенный робмик, к нему ведёт непрерывная линия. Запишем теперь это в виде текстового отображения связи: class Node { } LinkedList * -- Node И теперь необходимо научиться отображать ещё один важный тип связи - зависимость (dependency relationship). Он используется тогда, когда один класс использует другой, при этом класс не содержит в себе используемый класс и не является его наследником. Например, LinkedList и ArrayList умеют создавать ListIterator . Отобразим это в виде стрелок с пунктирной линией: class ListIterator ListIterator < . . . ArrayList : create ListIterator < . . . LinkedList : create Выглядеть после всего это будет следующим образом:
Детализировать можно настолько, насколько это необходимо. Все обозначения указаны тут: "PlantUML - Диаграмма классов ". Кроме того, в рисовании такой схемы нет ничего сверхъестественного, и при работе над своими задачами её можно быстро рисовать от руки. Это позволит развить навыки продумывания архитектуры приложения и поможет выявить недостатки структуры классов на раннем этапе, а не когда вы уже потратите день на реализацию неправильной модели. Мне кажется, это неплохая причина для того, чтобы попробовать?)
Автоматизация
Есть различные способы автоматической генерации PlantUML диаграмм. Например, в Idea есть плагин SketchIT , но рисует он их не совсем правильно. Скажем, неправильно рисуется имплементация интерфейсов (отображается как наследование). Также в интернете есть примеры того, как это встроить в жизненный цикл сборки вашего проекта. Допустим, для Maven есть пример использования uml-java-docklet . Для того, чтобы показать как это, воспользуемся Maven Archetype для быстрого создания Maven проекта. Выполним команду: mvn archetype:generate На вопросе выбора фильтра (Choose a number or apply filter ) оставляем default, просто нажав Enter. Это всегда будет "maven-archetype-quickstart ". Выбираем самую последнюю версию. Далее отвечаем на вопросы и завершаем создание проекта:
Так как Maven не является целью данной статьи, ответы на свои вопросы по Maven можно найти в Maven Users Centre . В сгенерированном проекте откроем на редактирование файл описания проекта, pom.xml . В него скопируем содержимое из описания uml-java-docklet installing . Используемый в описании артефакт не удалось найти в репозитории Maven Central. Но у меня заработало с этим: https://mvnrepository.com/artifact/com.chfourie/uml-java-doclet/1.0.0 . То есть надо в том описании просто заменить groupId с "info.leadinglight " на "com.chfourie " и поставить версию "1.0.0 ". После этого можем выполнить в каталоге, где находится файл pom.xml эти комманды: mvn clean install и mvn javadoc:javadoc . Теперь, если открыть сгенерированную документацию (explorer target\site\apidocs\index.html), мы увидим UML схемы. Кстати, имплементация тут уже отображается верно)
Заключение
Как видно, UML позволяет визуализировать структуру вашего приложения. Кроме того, UML не ограничивается только этим. При помощи UML можно описывать различные процессы внутри вашей компании или описывать бизнес-процесс, в рамках которого работает функция, которую вы пишите. На сколько UML полезен лично для вас - решать вам, но найти время и ознакомиться более подробным будет в любом случае полезно. #Viacheslav English version of this post: UML diagram Java on CodeGymАннотация: Предметом этого курса является The UML - унифицированный язык моделирования. В предыдущей лекции было рассказано о том, что же такое UML, о его истории, назначении, способах использования языка, структуре его определения, терминологии и нотации. Было отмечено, что модель UML - это набор диаграмм. В этой лекции мы рассмотрим такие вопросы: почему нужно несколько видов диаграмм; виды диаграмм; ООП и последовательность построения диаграмм
Прежде чем перейти к обсуждению основного материала этой лекции, давайте поговорим о том, зачем вообще строить какие-то диаграммы. Разработка модели любой системы (не только программной) всегда предшествует ее созданию или обновлению. Это необходимо хотя бы для того, чтобы яснее представить себе решаемую задачу. Продуманные модели очень важны и для взаимодействия внутри команды разработчиков, и для взаимопонимания с заказчиком. В конце концов, это позволяет убедиться в "архитектурной согласованности" проекта до того, как он будет реализован в коде.
Мы строим модели сложных систем, потому что не можем описать их полностью, "окинуть одним взглядом". Поэтому мы выделяем лишь существенные для конкретной задачи свойства системы и строим ее модель, отображающую эти свойства. Метод объектно-ориентированного анализа позволяет описывать реальные сложные системы наиболее адекватным образом. Но с увеличением сложности систем возникает потребность в хорошей технологии моделирования. Как мы уже говорили в предыдущей лекции, в качестве такой "стандартной" технологии используется унифицированный язык моделирования ( Unified Modeling Language , UML ), который является графическим языком для спецификации, визуализации, проектирования и документирования систем. С помощью UML можно разработать подробную модель создаваемой системы, отображающую не только ее концепцию, но и конкретные особенности реализации. В рамках UML -модели все представления о системе фиксируются в виде специальных графических конструкций, получивших название диаграмм.
Примечание . Мы рассмотрим не все, а лишь некоторые из видов диаграмм. Например, диаграмма компонентов не рассматривается в этой лекции, которая является лишь кратким обзором видов диаграмм. Количество типов диаграмм для конкретной модели приложения никак не ограничивается. Для простых приложений нет необходимости строить диаграммы всех без исключения типов. Некоторые из них могут просто отсутствовать, и этот факт не будет считаться ошибкой. Важно понимать, что наличие диаграмм определенного вида зависит от специфики конкретного проекта. Информацию о других (не рассмотренных здесь) видах диаграмм можно найти в стандарте UML.
Почему нужно несколько видов диаграмм
Для начала определимся с терминологией. В предисловии к этой лекции мы неоднократно использовали понятия системы, модели и диаграммы. Автор уверен, что каждый из нас интуитивно понимает смысл этих понятий, но, чтобы внести полную ясность , снова заглянем в глоссарий и прочтем следующее:
Система - совокупность взаимосвязанных управляемых подсистем, объединенных общей целью функционирования.
Да, не слишком информативно. А что же такое тогда подсистема? Чтобы прояснить ситуацию, обратимся к классикам:
Системой называют набор подсистем, организованных для достижения определенной цели и описываемых с помощью совокупности моделей, возможно, с различных точек зрения.
Что ж, ничего не попишешь, придется искать определение подсистемы. Там же сказано, что подсистема - это совокупность элементов, часть из которых задает спецификацию поведения других элементов. Ян Соммервилл объясняет это понятие таким образом:
Подсистема - это система, функционирование которой не зависит от сервисов других подсистем. Программная система структурируется в виде совокупности относительно независимых подсистем. Также определяются взаимодействия между подсистемами.
Тоже не слишком понятно, но уже лучше. Говоря "человеческим" языком, система представляется в виде набора более простых сущностей, которые относительно самодостаточны. Это можно сравнить с тем, как в процессе разработки программы мы строим графический интерфейс из стандартных "кубиков" - визуальных компонентов, или как сам текст программы тоже разбивается на модули, которые содержат подпрограммы, объединенные по функциональному признаку, и их можно использовать повторно, в следующих программах.
С понятием системы разобрались. В процессе проектирования система рассматривается с разных точек зрения с помощью моделей, различные представления которых предстают в форме диаграмм. Опять-таки у читателя могут возникнуть вопросы о смысле понятий модели и диаграммы . Думаем, красивое, но не слишком понятное определение модели как семантически замкнутой абстракции системы вряд ли прояснит ситуацию, поэтому попробуем объяснить "своими словами".
Модель - это некий (материальный или нет) объект , отображающий лишь наиболее значимые для данной задачи характеристики системы. Модели бывают разные - материальные и нематериальные, искусственные и естественные, декоративные и математические...
Приведем несколько примеров. Знакомые всем нам пластмассовые игрушечные автомобильчики, которыми мы с таким азартом играли в детстве, это не что иное, как материальная искусственная декоративная модель реального автомобиля. Конечно, в таком "авто" нет двигателя, мы не заполняем его бак бензином, в нем не работает (более того, вообще отсутствует) коробка передач, но как модель эта игрушка свои функции вполне выполняет: она дает ребенку представление об автомобиле, поскольку отображает его характерные черты - наличие четырех колес, кузова, дверей, окон, способность ехать и т. д.
В ходе медицинских исследований опыты на животных часто предшествуют клиническим испытаниям медицинских препаратов на людях. В таком случае животное выступает в роли материальной естественной модели человека.
Уравнение, изображенное выше - тоже модель, но это модель математическая, и описывает она движение материальной точки под действием силы тяжести.
Осталось лишь сказать, что такое диаграмма . Диаграмма - это графическое представление множества элементов. Обычно изображается в виде графа с вершинами (сущностями) и ребрами (отношениями). Примеров диаграмм можно привести множество. Это и знакомая нам всем со школьных лет блок-схема , и схемы монтажа различного оборудования, которые мы можем видеть в руководствах пользователя, и дерево файлов и каталогов на диске, которое мы можем увидеть, выполнив в консоли Windows команду tree , и многое-многое другое. В повседневной жизни диаграммы окружают нас со всех сторон, ведь рисунок воспринимается нами легче, чем текст...
Но вернемся к проектированию ПО (и не только). В этой отрасли с помощью диаграмм можно визуализировать систему с различных точек зрения . Одна из диаграмм, например, может описывать взаимодействие пользователя с системой, другая - изменение состояний системы в процессе ее работы, третья - взаимодействие между собой элементов системы и т. д. Сложную систему можно и нужно представить в виде набора небольших и почти независимых моделей-диаграмм, причем ни одна из них не является достаточной для описания системы и получения полного представления о ней, поскольку каждая из них фокусируется на каком-то определенном аспекте функционирования системы и выражает разный уровень абстракции . Другими словами, каждая модель соответствует некоторой определенной, частной точке зрения на проектируемую систему.
Несмотря на то что в предыдущем абзаце мы весьма вольготно обошлись с понятием модели, следует понимать, что в контексте приведенных выше определений ни одна отдельная диаграмма не является моделью . Диаграммы - лишь средство визуализации модели, и эти два понятия следует различать. Лишь набор диаграмм составляет модель системы и наиболее полно ее описывает, но не одна диаграмма , вырванная из контекста.
Виды диаграмм
UML 1.5 определял двенадцать типов диаграмм , разделенных на три группы:
- четыре типа диаграмм представляют статическую структуру приложения;
- пять представляют поведенческие аспекты системы;
- три представляют физические аспекты функционирования системы (диаграммы реализации).
Текущая версия UML 2.1 внесла не слишком много изменений. Диаграммы слегка изменились внешне (появились фреймы и другие визуальные улучшения), немного усовершенствовалась нотация , некоторые диаграммы получили новые наименования.
Впрочем, точное число канонических диаграмм для нас абсолютно неважно, так как мы рассмотрим не все из них, а лишь некоторые - по той причине, что количество типов диаграмм для конкретной модели конкретного приложения не является строго фиксированным. Для простых приложений нет необходимости строить все без исключения диаграммы. Например, для локального приложения не обязательно строить диаграмму развертывания. Важно понимать, что перечень диаграмм зависит от специфики разрабатываемого проекта и определяется самим разработчиком. Если же любопытный читатель все-таки пожелает узнать обо всех диаграммах UML , мы отошлем его к стандарту UML (http://www.omg.org/technology/documents/modeling_spec_catalog.htm#UML). Напомним, что цель этого курса - не описать абсолютно все возможности UML , а лишь познакомить с этим языком, дать первоначальное представление об этой технологии.
Итак, мы кратко рассмотрим такие виды диаграмм, как:
- диаграмма прецедентов ;
- диаграмма классов;
- диаграмма объектов ;
- диаграмма последовательностей;
- диаграмма взаимодействия;
- диаграмма состояний;
- диаграмма активности ;
- диаграмма развертывания .
О некоторых из этих диаграмм мы будем говорить подробнее в следующих лекциях. Пока же мы не станем заострять внимание на подробностях, а зададимся целью научить читателя хотя бы визуально различать виды диаграмм, дать начальное представление о назначении основных видов диаграмм. Итак, начнем.
Диаграмма прецедентов (use case diagram)
Любые (в том числе и программные) системы проектируются с учетом того, что в процессе своей работы они будут использоваться людьми и/или взаимодействовать с другими системами. Сущности, с которыми взаимодействует система в процессе своей работы, называются экторами , причем каждый эктор ожидает, что система будет вести себя строго определенным, предсказуемым образом. Попробуем дать более строгое определение эктора. Для этого воспользуемся замечательным визуальным словарем по UML Zicom Mentor :
Эктор (actor) - это множество логически связанных ролей, исполняемых при взаимодействии с прецедентами или сущностями (система, подсистема или класс). Эктором может быть человек или другая система, подсистема или класс, которые представляют нечто вне сущности.
Графически эктор изображается либо " человечком ", подобным тем, которые мы рисовали в детстве, изображая членов своей семьи, либо символом класса с соответствующим стереотипом , как показано на рисунке. Обе формы представления имеют один и тот же смысл и могут использоваться в диаграммах. "Стереотипированная" форма чаще применяется для представления системных экторов или в случаях, когда эктор имеет свойства и их нужно отобразить (рис. 2.1).
Внимательный читатель сразу же может задать вопрос: а почему эктор, а не актер ? Согласны, слово "эктор" немного режет слух русского человека. Причина же, почему мы говорим именно так, проста - эктор образовано от слова action , что в переводе означает действие . Дословный же перевод слова "эктор" - действующее лицо - слишком длинный и неудобный для употребления. Поэтому мы будем и далее говорить именно так.
Рис. 2.1.
Тот же внимательный читатель мог заметить промелькнувшее в определении эктора слово "прецедент". Что же это такое? Этот вопрос заинтересует нас еще больше, если вспомнить, что сейчас мы говорим о диаграмме прецедентов . Итак,
Прецедент (use-case) - описание отдельного аспекта поведения системы с точки зрения пользователя (Буч).
Определение вполне понятное и исчерпывающее, но его можно еще немного уточнить, воспользовавшись тем же Zicom Mentor "ом:
Прецедент (use case) - описание множества последовательных событий (включая варианты), выполняемых системой, которые приводят к наблюдаемому эктором результату. Прецедент представляет поведение сущности, описывая взаимодействие между экторами и системой. Прецедент не показывает, "как" достигается некоторый результат, а только "что" именно выполняется.
Прецеденты обозначаются очень простым образом - в виде эллипса, внутри которого указано его название. Прецеденты и экторы соединяются с помощью линий . Часто на одном из концов линии изображают рис. 2.3
В настоящее время язык UML - это стандартная нотация визуального моделирования программных систем, принятая консорциумом Object Managing Group (OMG) осенью 1997 г., которая поддерживается многими объектно-ориентированными CASE-продуктами.
Стандарт UML предлагает следующий набор диаграмм для моделирования:
· диаграмма вариантов использования (use case diagram) – для моделирования бизнес-процессов организации или предприятия и определения требований к создаваемой информационной системе;
· диаграмма классов (class diagram) – для моделирования статической структуры классов системы и связей между ними;
· диаграмма поведения системы (behavior diagrams);
· диаграмма взаимодействия (interaction diagrams);
· диаграмма последовательности (sequence diagrams) – для моделирования процесса обмена сообщениями между объектами в рамках одного варианта использования;
· диаграмма кооперации (collaboration diagram) – для моделирования процесса обмена сообщениями между объектами в рамках одного варианта использования;
· диаграмма состояний (statechart diagram) – для моделирования поведения объектов системы при переходе из одного состояния в другое;
· диаграмма видов деятельности (activity diagram) – для моделирования поведения системы в рамках различных вариантов использования, или моделирования деятельностей;
· диаграмма реализации (implementation diagrams):
· диаграмма компонентов (component diagrams) – для моделирования иерархии компонентов (подсистем) информационной системы;
· диаграмма развертывания (deployment diagram) – для моделирования физической архитектуры спроектированной информационной системы.
На рис. 1.1 представлена интегрированная модель информационной системы, включающая основные диаграммы, которые должны быть разработаны в данном курсовом проекте.
Рис. 1. Интегрированная модель информационной системы в нотации языка UML
4.2. Диаграмма вариантов использования
Вариант использования представляет собой последовательность действий, выполняемых системой в ответ на событие, инициируемое некоторым внешним объектом (актером). Вариант использования описывает типичное взаимодействие между пользователем и системой. В простейшем случае вариант использования определяется в процессе обсуждения с пользователем тех функций, которые он хотел бы реализоватьв данной информационной системе. На языке UML вариант использования изображают следующим образом:
Рис.2. Вариант использования
Актер (actor) – это роль, которую пользователь играет по отношению к системе. Актеры представляют собой роли, а не конкретных людей или наименования работ. Несмотря на то, что на диаграммах вариантов использования они изображаются в виде стилизованных человеческих фигурок, актер может также быть внешней информационной системой, которой необходима некоторая информация от данной системы. Показывать на диаграмме актеров следует только в том случае, когда им действительно необходимы некоторые варианты использования. На языке UML актеры представляют в виде фигур:
Рис.3. Действующее лицо (актер)
Актеры делятся на три основных типа:
· пользователи;
· системы;
· другие системы, взаимодействующие с данной;
Время становится актером, если от него зависит запуск каких-либо событий в системе.
4.2.1. Связи между вариантами использования и актерами
В языке UML на диаграммах вариантов использования поддерживается несколько типов связей между элементами диаграммы:
· коммуникация (communication),
· включение (include),
· расширение (extend),
· обобщение (generalization).
Связь коммуникации – это связь между вариантом использования и актером. На языке UML связи коммуникации показывают с помощью однонаправленной ассоциации (сплошной линии).
Рис.4. Пример связи коммуникации
Связь включения применяется в тех ситуациях, когда имеется какой-либо фрагмент поведения системы, который повторяется более чем в одном варианте использования. С помощью таких связей обычно моделируют многократно используемую функцию.
Связь расширения применяется при описании изменений в нормальном поведении системы. Она позволяет одному варианту использования при необходимости использовать функциональные возможности другого варианта использования.
Рис.5. Пример связи включения и расширения
Связь обобщения показывает, что у нескольких актеров или классов имеются общие свойства.
Рис.6. Пример связи обобщения
4.3.
Диаграммы взаимодействия (interaction diagrams) описывают поведение взаимодействующих групп объектов. Как правило, диаграмма взаимодействия охватывает поведение объектов в рамках только одного варианта использования. На такой диаграмме отображается ряд объектов и те сообщения, которыми они обмениваются между собой.
Сообщение (message) – это средство, с помощью которого объект-отправитель запрашивает у объекта получателя выполнение одной из его операций.
Информационное (informative) сообщение – это сообщение, снабжающее объект-получатель некоторой информацией для обновления его состояния.
Сообщение-запрос (interrogative) – это сообщение, запрашивающее выдачу некоторой информации об объекте-получателе.
Императивное (imperative) сообщение – это сообщение, запрашивающее у объекта-получателя выполнение некоторых действий.
Существует два вида диаграмм взаимодействия: диаграммы последовательности (sequence diagrams) и диаграммы кооперац (collaboration diagrams).
4.3.1. Диаграмма последовательности (sequence diagrams)
Диаграмма последовательности отражает поток событий, происходящих в рамках одного варианта использования.
Все действующие лица (актеры, классы или объекты), участвующие в данном сценарии (варианте использования), показываются в верхней части диаграммы. Стрелки соответствуют сообщениям, передаваемым между актером и объектом или между объектами для выполнения требуемых функций.
На диаграмме последовательности объект изображается в виде прямоугольника, от которого вниз проведена пунктирная вертикальная линия. Эта линия называется линией жизни (lifeline) объекта . Она представляет собой фрагмент жизненного цикла объекта в процессе взаимодействия.
Каждое сообщение представляется в виде стрелки между линиями жизни двух объектов. Сообщения появляются в том порядке, как они показаны на странице сверху вниз. Каждое сообщение помечается как минимум именем сообщения. При желании можно добавить также аргументы и некоторую управляющую информацию. Можно показать самоделегирование (self-delegation) – сообщение, которое объект посылает самому себе, при этом стрелка сообщения указывает на ту же самую линию жизни.
Рис. 7. Пример диаграммы последовательности
4.3.2. Диаграмма кооперации (collaboration diagram)
Диаграммы кооперации отображают поток событий в рамках конкретного сценария (варианта использования). Сообщения упорядочены по времени, хотя диаграммы кооперации больше внимания заостряют на связях между объектами. На диаграмме кооперации представлена вся та информация, которая есть и на диаграмме последовательности, но диаграмма кооперации по-другому описывает поток событий. Из нее легче понять связи, существующие между объектами.
На диаграмме кооперации так же, как и на диаграмме последовательности, стрелки обозначают сообщения, обмен которыми осуществляется в рамках данного варианта использования. Их временная последовательность указывается путем нумерации сообщений.
Рис. 8. Пример диаграммы кооперации
4.4. Диаграмма классов
4.4.1. Общие сведения
Диаграмма классов определяет типы классов системы и различного рода статические связи, которые существуют между ними. На диаграммах классов изображаются также атрибуты классов, операции классов и ограничения, которые накладываются на связи между классами.
Диаграмма классов в языке UML - это граф, узлами которого являются элементы статической структуры проекта (классы, интерфейсы), а дугами - отношения между узлами (ассоциации, наследование, зависимости).
На диаграмме классов изображаются следующие элементы:
· Пакет (package) - набор элементов модели, логически связанных между собой;
· Класс (class) - описание общих свойств группы сходных объектов;
· Интерфейс (interface) - абстрактный класс, задающий набор операций, которые объект произвольного класса, связанного с данным интерфейсом, предоставляет другим объектам.
4.4.2. Класс
Класс - это группа сущностей (объектов), обладающих сходными свойствами, а именно, данными и поведением. Отдельный представитель некоторого класса называется объектом класса или просто объектом.
Под поведением объекта в UML понимаются любые правила взаимодействия объекта с внешним миром и с данными самого объекта.
На диаграммах класс изображается в виде прямоугольника со сплошной границей, разделенного горизонтальными линиями на 3 секции:
Верхняя секция (секция имени) содержит имя класса и другие общие свойства (в частности, стереотип).
В средней секции содержится список атрибутов
В нижней - список операций класса, отражающих его поведение (действия, выполняемые классом).
Любая из секций атрибутов и операций может не изображаться (а также обе сразу). Для отсутствующей секции не нужно рисовать разделительную линию и как-либо указывать на наличие или отсутствие элементов в ней.
На усмотрение конкретной реализации могут быть введены дополнительные секции, например, исключения (Exceptions).
Рис. 9. Пример диаграммы классов
4.4.2.1.Стереотипы классов
Стереотипы классов – это механизм, позволяющий разделять классы на категории.
В языке UML определены три основных стереотипа классов:
Boundary (граница);
Entity (сущность);
Control (управление).
4.4.2.2.Граничные классы
Граничными классами (boundary classes) называются такие классы, которые расположены на границе системы и всей окружающей среды. Это экранные формы, отчеты, интерфейсы с аппаратурой (такой как принтеры или сканеры) и интерфейсы с другими системами.
Чтобы найти граничные классы, надо исследовать диаграммы вариантов использования. Каждому взаимодействию между действующим лицом и вариантом использования должен соответствовать, по крайней мере, один граничный класс. Именно такой класс позволяет действующему лицу взаимодействовать с системой.
4.4.2.3.Классы-сущности
Классы-сущности (entity classes) содержат хранимую информацию. Они имеют наибольшее значение для пользователя, и потому в их названиях часто используют термины из предметной области. Обычно для каждого класса-сущности создают таблицу в базе данных.
4.4.2.4.Управляющие классы
Управляющие классы (control classes) отвечают за координацию действий других классов. Обычно у каждого варианта использования имеется один управляющий класс, контролирующий последовательность событий этого варианта использования. Управляющий класс отвечает за координацию, но сам не несет в себе никакой функциональности, так как остальные классы не посылают ему большого количества сообщений. Вместо этого он сам посылает множество сообщений. Управляющий класс просто делегирует ответственность другим классам, по этой причине его часто называют классом-менеджером.
В системе могут быть и другие управляющие классы, общие для нескольких вариантов использования. Например, может быть класс SecurityManager (менеджер безопасности), отвечающий за контроль событий, связанных с безопасностью. Класс TransactionManager (менеджер транзакций) занимается координацией сообщений, относящихся к транзакциям с базой данных. Могут быть и другие менеджеры для работы с другими элементами функционирования системы, такими как разделение ресурсов, распределенная обработка данных или обработка ошибок.
Помимо упомянутых выше стереотипов можно создавать и свои собственные.
4.4.2.5.Атрибуты
Атрибут – это элемент информации, связанный с классом. Атрибуты хранят инкапсулированные данные класса.
Так как атрибуты содержатся внутри класса, они скрыты от других классов. В связи с этим может понадобиться указать, какие классы имеют право читать и изменять атрибуты. Это свойство называется видимостью атрибута (attribute visibility).
У атрибута можно определить четыре возможных значения этого параметра:
Public (общий, открытый). Это значение видимости предполагает, что атрибут будет виден всеми остальными классами. Любой класс может просмотреть или изменить значение атрибута. В соответствии с нотацией UML общему атрибуту предшествует знак « + ».
Private (закрытый, секретный). Соответствующий атрибут не виден никаким другим классом. Закрытый атрибут обозначается знаком « – » в соответствии с нотацией UML.
Protected (защищенный). Такой атрибут доступен только самому классу и его потомкам. Нотация UML для защищенного атрибута – это знак « # ».
Package or Implementation (пакетный). Предполагает, что данный атрибут является общим, но только в пределах его пакета. Этот тип видимости не обозначается никаким специальным значком.
С помощью закрытости или защищенности удается избежать ситуации, когда значение атрибута изменяется всеми классами системы. Вместо этого логика изменения атрибута будет заключена в том же классе, что и сам этот атрибут. Задаваемые параметры видимости повлияют на генерируемый код.
4.4.2.6.Операции
Операции реализуют связанное с классом поведение. Операция включает три части – имя, параметры и тип возвращаемого значения.
Параметры – это аргументы, получаемые операцией «на входе». Тип возвращаемого значения относится к результату действия операции.
На диаграмме классов можно показывать как имена операций, так и имена операций вместе с их параметрами и типом возвращаемого значения. Чтобы уменьшить загруженность диаграммы, полезно бывает на некоторых из них показывать только имена операций, а на других их полную сигнатуру.
В языке UML операции имеют следующую нотацию:
Имя Операции (аргумент: тип данных аргумента, аргумент2:тип данных аргумента2,...): тип возвращаемого значения
Следует рассмотреть четыре различных типа операций:
Операции реализации;
Операции управления;
Операции доступа;
Вспомогательные операции.
Операции реализации
Операции реализации (implementor operations) реализуют некоторые бизнес-функции. Такие операции можно найти, исследуя диаграммы взаимодействия. Диаграммы этого типа фокусируются на бизнес-функциях, и каждое сообщение диаграммы, скорее всего, можно соотнести с операцией реализации.
Каждая операция реализации должна быть легко прослеживаема до соответствующего требования. Это достигается на различных этапах моделирования. Операция выводится из сообщения на диаграмме взаимодействия, сообщения исходят из подробного описания потока событий, который создается на основе варианта использования, а последний – на основе требований. Возможность проследить всю эту цепочку позволяет гарантировать, что каждое требование будет реализовано в коде, а каждый фрагмент кода реализует какое-то требование.
Операции управления
Операции управления (manager operations) управляют созданием и уничтожением объектов. В эту категорию попадают конструкторы и деструкторы классов.
Операции доступа
Атрибуты обычно бывают закрытыми или защищенными. Тем не менее, другие классы иногда должны просматривать или изменять их значения. Для этого существуют операции доступа (access operations). Такой подход дает возможность безопасно инкапсулировать атрибуты внутри класса, защитив их от других классов, но все же позволяет осуществить к ним контролируемый доступ. Создание операций Get и Set (получения и изменения значения) для каждого атрибута класса является стандартом.
Вспомогательные операции
Вспомогательными (helper operations) называются такие операции класса, которые необходимы ему для выполнения его ответственностей, но о которых другие классы не должны ничего знать. Это закрытые и защищенные операции класса.
Чтобы идентифицировать операции, выполните следующие действия:
1. Изучите диаграммы последовательности и кооперативные диаграммы. Большая часть сообщений на этих диаграммах является операциями реализации. Рефлексивные сообщения будут вспомогательными операциями.
2. Рассмотрите управляющие операции. Может потребоваться добавить конструкторы и деструкторы.
3. Рассмотрите операции доступа. Для каждого атрибута класса, с которым должны будут работать другие классы, надо создать операции Get и Set.
4.4.2.7.Связи
Связь представляет собой семантическую взаимосвязь между классами. Она дает классу возможность узнавать об атрибутах, операциях и связях другого класса. Иными словами, чтобы один класс мог послать сообщение другому на диаграмме последовательности или кооперативной диаграмме, между ними должна существовать связь.
Существуют четыре типа связей, которые могут быть установлены между классами: ассоциации, зависимости, агрегации и обобщения.
Связь ассоциация
Ассоциация (association) – это семантическая связь между классами. Их рисуют на диаграмме классов в виде обыкновенной линии.
Рис. 10. Связь ассоциация
Ассоциации могут быть двунаправленными, как в примере, или однонаправленными. На языке UML двунаправленные ассоциации рисуют в виде простой линии без стрелок или со стрелками с обеих ее сторон. На однонаправленной ассоциации изображают только одну стрелку, показывающую ее направление.
Направление ассоциации можно определить, изучая диаграммы последовательности и кооперативные диаграммы. Если все сообщения на них отправляются только одним классом и принимаются только другим классом, но не наоборот, между этими классами имеет место однонаправленная связь. Если хотя бы одно сообщение отправляется в обратную сторону, ассоциация должна быть двунаправленной.
Ассоциации могут быть рефлексивными. Рефлексивная ассоциация предполагает, что один экземпляр класса взаимодействует с другими экземплярами этого же класса.
Связь зависимость
Связи зависимости (dependency) также отражают связь между классами, но они всегда однонаправлены и показывают, что один класс зависит от определений, сделанных в другом. Например, класс A использует методы класса B. Тогда при изменении класса B необходимо произвести соответствующие изменения в классе A.
Зависимость изображается пунктирной линией, проведенной между двумя элементами диаграммы, и считается, что элемент, привязанный к концу стрелки, зависит от элемента, привязанного к началу этой стрелки.
Рис. 11. Связь зависимость
При генерации кода для этих классов к ним не будут добавляться новые атрибуты. Однако, будут созданы специфические для языка операторы, необходимые для поддержки связи.
Связь агрегация
Агрегации (aggregations) представляют собой более тесную форму ассоциации. Агрегация – это связь между целым и его частью. Например, у вас может быть класс Автомобиль, а также классы Двигатель, Покрышки и классы для других частей автомобиля. В результате объект класса Автомобиль будет состоять из объекта класса Двигатель, четырех объектов Покрышек и т. д. Агрегации визуализируют в виде линии с ромбиком у класса, являющегося целым:
Рис. 11. Связь агрегация
В дополнение к простой агрегации UML вводит более сильную разновидность агрегации, называемую композицией. Согласно композиции, объект-часть может принадлежать только единственному целому, и, кроме того, как правило, жизненный цикл частей совпадает с циклом целого: они живут и умирают вместе с ним. Любое удаление целого распространяется на его части.
Такое каскадное удаление нередко рассматривается как часть определения агрегации, однако оно всегда подразумевается в том случае, когда множественность роли составляет 1..1; например, если необходимо удалить Клиента, то это удаление должно распространиться и на Заказы (и, в свою очередь, на Строки заказа).
UML – это унифицированный графический язык моделирования для описания, визуализации, проектирования и документирования ОО систем. UML призван поддерживать процесс моделирования ПС на основе ОО подхода, организовывать взаимосвязь концептуальных и программных понятий, отражать проблемы масштабирования сложных систем. Модели на UML используются на всех этапах жизненного цикла ПС, начиная с бизнес-анализа и заканчивая сопровождением системы. Разные организации могут применять UML по своему усмотрению в зависимости от своих проблемных областей и используемых технологий.
Краткая история UML
К середине 90-х годов различными авторами было предложено несколько десятков методов ОО моделирования, каждый из которых использовал свою графическую нотацию. При этом любой их этих методов имел свои сильные стороны, но не позволял построить достаточно полную модель ПС, показать ее «со всех сторон», то есть, все необходимые проекции (См. статью 1). К тому же отсутствие стандарта ОО моделирования затрудняло для разработчиков выбор наиболее подходящего метода, что препятствовало широкому распространению ОО подхода к разработке ПС.
По запросу Object Management Group (OMG) – организации, ответственной за принятие стандартов в области объектных технологий и баз данных назревшая проблема унификации и стандартизации была решена авторами трех наиболее популярных ОО методов – Г.Бучем, Д.Рамбо и А.Джекобсоном, которые объединенными усилиями создали версию UML 1.1, утвержденную OMG в 1997 году в качестве стандарта.
UML – это язык
Любой язык состоит из словаря и правил комбинирования слов для получения осмысленных конструкций. Так, в частности, устроены языки программирования, таковым является и UML. Отличительной его особенностью является то, что словарь языка образуют графические элементы. Каждому графическому символу соответствует конкретная семантика, поэтому модель, созданная одним разработчиком, может однозначно быть понята другим, а также программным средством, интерпретирующим UML. Отсюда, в частности, следует, что модель ПС, представленная на UML, может автоматически быть переведена на ОО язык программирования (такой, как Java, C++, VisualBasic), то есть, при наличии хорошего инструментального средства визуального моделирования, поддерживающего UML, построив модель, мы получим и заготовку программного кода, соответствующего этой модели.
Следует подчеркнуть, что UML – это именно язык, а не метод. Он объясняет, из каких элементов создавать модели и как их читать, но ничего не говорит о том, какие модели и в каких случаях следует разрабатывать. Чтобы создать метод на базе UML, надо дополнить его описанием процесса разработки ПС. Примером такого процесса является Rational Unified Process, который будет рассматриваться в последующих статьях.
Словарь UML
Модель представляется в виде сущностей и отношений между ними, которые показываются на диаграммах.
Сущности – это абстракции, являющиеся основными элементами моделей. Имеется четыре типа сущностей – структурные (класс, интерфейс, компонент, вариант использования, кооперация, узел), поведенческие (взаимодействие, состояние), группирующие (пакеты) и аннотационные (комментарии). Каждый вид сущностей имеет свое графическое представление. Сущности будут подробно рассмотрены при изучении диаграмм.
Отношения показывают различные связи между сущностями. В UML определены следующие типы отношений:
- Зависимость показывает такую связь между двумя сущностями, когда изменение одной из них – независимой – может повлиять на семантику другой – зависимой. Зависимость изображается пунктирной стрелкой, направленной от зависимой сущности к независимой.
- Ассоциация – это структурное отношение, показывающее, что объекты одной сущности связаны с объектами другой. Графически ассоциация показывается в виде линии, соединяющей связываемые сущности. Ассоциации служат для осуществления навигации между объектами. Например, ассоциация между классами «Заказ» и «Товар» может быть использована для нахождения всех товаров, указанных в конкретном заказе – с одной стороны, или для нахождения всех заказов в которых есть данный товар, – с другой. Понятно, что в соответствующих программах должен быть реализован механизм, обеспечивающий такую навигацию. Если требуется навигация только в одном направлении, оно показывается стрелкой на конце ассоциации. Частным случаем ассоциации является агрегирование – отношение вида «целое» – «часть». Графически оно выделяется с помощью ромбика на конце около сущности-целого.
- Обобщение – это отношение между сущностью-родителем и сущностью-потомком. По существу, это отношение отражает свойство наследования для классов и объектов. Обобщение показывается в виде линии, заканчивающейся треугольничком направленным к родительской сущности. Потомок наследует структуру (атрибуты) и поведение (методы) родителя, но в то же время он может иметь новые элементы структуры и новые методы. UML допускает множественное наследование, когда сущность связана более чем с одной родительской сущностью.
- Реализация – отношение между сущностью, определяющей спецификацию поведения (интерфейс) с сущностью, определяющей реализацию этого поведения (класс, компонент). Это отношение обычно используется при моделировании компонент и будет подробнее описано в последующих статьях.
Диаграммы. В UML предусмотрены следующие диаграммы:
- Диаграммы, описывающие поведение системы:
- Диаграммы состояний (State diagrams),
- Диаграммы деятельностей (Activity diagrams),
- Диаграммы объектов (Object diagrams),
- Диаграммы последовательностей (Sequence diagrams),
- Диаграммы взаимодействия (Collaboration diagrams);
- Диаграммы, описывающие физическую реализацию системы:
- Диаграммы компонент (Component diagrams);
- Диаграммы развертывания (Deployment diagrams).
Представление управления моделью. Пакеты.
Мы уже говорили о том, что для того чтобы модель была хорошо понимаемой человеком необходимо организовать ее иерархически, оставляя на каждом уровне иерархии небольшое число сущностей. UML включает средство организации иерархического представления модели – пакеты. Любая модель состоит из набора пакетов, которые могут содержать классы, варианты использования и прочие сущности и диаграммы. Пакет может включать другие пакеты, что позволяет создавать иерархии. В UML не предусмотрено отдельных диаграмм пакетов, но они могут присутствовать на других диаграммах. Пакет изображается в виде прямоугольника с закладкой.
Что обеспечивает UML.
- иерархическое описание сложной системы путем выделения пакетов;
- формализацию функциональных требований к системе с помощью аппарата вариантов использования;
- детализацию требований к системе путем построения диаграмм деятельностей и сценариев;
- выделение классов данных и построение концептуальной модели данных в виде диаграмм классов;
- выделение классов, описывающих пользовательский интерфейс, и создание схемы навигации экранов;
- описание процессов взаимодействия объектов при выполнении системных функций;
- описание поведения объектов в виде диаграмм деятельностей и состояний;
- описание программных компонент и их взаимодействия через интерфейсы;
- описание физической архитектуры системы.
И последнее…
Несмотря на всю привлекательность UML, его было бы затруднительно использовать при реальном моделировании ПС без инструментальных средств визуального моделирования. Такие средства позволяют оперативно представлять диаграммы на экране дисплея, документировать их, генерировать заготовки программных кодов на различных ОО языках программирования, создавать схемы баз данных. Большинство из них включают возможности реинжиниринга программных кодов – восстановления определенных проекций модели ПС путем автоматического анализа исходных кодов программ, что очень важно для обеспечения соответствия модели и кодов и при проектировании систем, наследующих функциональность систем-предшественников.
UML (Unified Modeling Language - унифицированный язык моделирования) - язык графического описания для объектного моделирования в области разработки программного обеспечения. UML является языком широкого профиля, это открытый стандарт, использующий графические обозначения для создания абстрактной модели системы, называемой UML моделью. UML был создан для определения, визуализации, проектирования и документирования в основном программных систем. UML не является языком программирования, но в средствах выполнения UML-моделей как интерпретируемого кода возможна кодогенерация. Википедия
Коммерческие продукты
Microsoft Visio
Тип: коммерческое ПО
Популярный программный продукт от компании Microsoft, который позволяет рисовать богатые диаграммы, в том числе UML:
Начиная с 2010 версии появилась возможность публиковать диаграммы в вебе (SharePoint + Visio Services):
Visio Viewer - бесплатная программа, которая позволяет просматривать созданные ранее Visio диаграммы. Загрузить можно по %D1%81%D1%81%D1%8B%D0%BB%D0%BA%D0%B5%20.
%0A
Microsoft%20Visual%20Studio%202010
%0A%D0%A2%D0%B8%D0%BF:%20%D0%BA%D0%BE%D0%BC%D0%BC%D0%B5%D1%80%D1%87%D0%B5%D1%81%D0%BA%D0%BE%D0%B5%20%D0%9F%D0%9E%20(%D0%B5%D1%81%D1%82%D1%8C%20%D0%B1%D0%B5%D1%81%D0%BF%D0%BB%D0%B0%D1%82%D0%BD%D0%B0%D1%8F%20Express%20%D0%B2%D0%B5%D1%80%D1%81%D0%B8%D1%8F).
%0A
%D0%92%20%D0%BF%D0%BE%D1%81%D0%BB%D0%B5%D0%B4%D0%BD%D0%B5%D0%B9%20%D0%B2%D0%B5%D1%80%D1%81%D0%B8%D0%B8%20Microsoft%20Visual%20Studio%202010%20%D0%BF%D0%BE%D1%8F%D0%B2%D0%B8%D0%BB%D1%81%D1%8F%20%D0%BD%D0%BE%D0%B2%D1%8B%D0%B9%20%D1%82%D0%B8%D0%BF%20%D0%BF%D1%80%D0%BE%D0%B5%D0%BA%D1%82%D0%B0%20-%20Modelling,%20%D0%BA%D0%BE%D1%82%D0%BE%D1%80%D1%8B%D0%B9%20%D0%BF%D0%BE%D0%B7%D0%B2%D0%BE%D0%BB%D1%8F%D0%B5%D1%82%20%D1%80%D0%B8%D1%81%D0%BE%D0%B2%D0%B0%D1%82%D1%8C%20%D1%80%D0%B0%D0%B7%D0%BB%D0%B8%D1%87%D0%BD%D1%8B%D0%B5%20UML%20%D0%B4%D0%B8%D0%B0%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%B0%20%D0%B8%20%D0%BF%D1%80%D0%BE%D0%B2%D0%B5%D1%80%D1%8F%D1%82%D1%8C%20%D0%BD%D0%B0%D0%BF%D0%B8%D1%81%D0%B0%D0%BD%D0%BD%D1%8B%D0%B5%20%D1%80%D0%B5%D1%88%D0%B5%D0%BD%D0%B8%D1%8F%20%D0%BD%D0%B0%20%D1%81%D0%BE%D0%BE%D1%82%D0%B2%D0%B5%D1%82%D1%81%D1%82%D0%B2%D0%B8%D0%B5%20%D1%81%20%D0%BD%D0%B5%D0%BE%D0%B1%D1%85%D0%BE%D0%B4%D0%B8%D0%BC%D0%BE%20%D0%B0%D1%80%D1%85%D0%B8%D1%82%D0%B5%D0%BA%D1%82%D1%83%D1%80%D0%BE%D0%B9.
%0A
%D0%9F%D0%BE%D0%B7%D0%B2%D0%BE%D0%BB%D1%8F%D0%B5%D1%82%20%D0%B3%D0%B5%D0%BD%D0%B5%D1%80%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D1%82%D1%8C%20Sequence%20Diagram%20%D0%BD%D0%B0%20%D0%BE%D1%81%D0%BD%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B8%20%D0%BA%D0%BE%D0%B4%D0%B0,%20%D0%B2%D0%B8%D0%B7%D1%83%D0%B0%D0%BB%D0%B8%D0%B7%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D1%82%D1%8C%20%D1%81%D0%B2%D1%8F%D0%B7%D0%B8%20%D0%B2%20%D0%BF%D1%80%D0%BE%D0%B5%D0%BA%D1%82%D0%B5%20%D0%BC%D0%B5%D0%B6%D0%B4%D1%83%20%D0%BA%D0%BE%D0%BC%D0%BF%D0%BE%D0%BD%D0%B5%D0%BD%D1%82%D0%B0%D0%BC%D0%B8,%20%D1%81%D0%B1%D0%BE%D1%80%D0%BA%D0%B0%D0%BC%D0%B8%20%D0%B8%20%D1%81%D1%81%D1%8B%D0%BB%D0%BA%D0%B0%D0%BC%D0%B8%20%D0%B8%20%D1%82.%D0%B4.
%0A%D0%9F%D1%80%D0%B8%D0%BC%D0%B5%D1%80%20Use%20case%20%D0%B4%D0%B8%D0%B0%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D1%8B,%20%D0%BD%D0%B0%D1%80%D0%B8%D1%81%D0%BE%D0%B2%D0%B0%D0%BD%D0%BD%D0%BE%D0%B9%20%D0%B2%20Visual%20Studio%202010:
%0A%0A%D0%9A%D1%80%D0%BE%D0%BC%D0%B5%20%D1%82%D0%BE%D0%B3%D0%BE,%20%D0%B4%D0%BE%D1%81%D1%82%D1%83%D0%BF%D0%B5%D0%BD%20Visualization%20and%20Modeling%20Feature%20Pack%20(%D0%B4%D0%BB%D1%8F%20%D0%BF%D0%BE%D0%B4%D0%BF%D0%B8%D1%81%D1%87%D0%B8%D0%BA%D0%BE%D0%B2%20MSDN),%20%D0%BA%D0%BE%D1%82%D0%BE%D1%80%D1%8B%D0%B9%20%D0%BF%D0%BE%D0%B7%D0%B2%D0%BE%D0%BB%D1%8F%D0%B5%D1%82:
%0A- %D0%B3%D0%B5%D0%BD%D0%B5%D1%80%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D1%82%D1%8C%20%D0%BA%D0%BE%D0%B4%20%D0%BD%D0%B0%20%D0%B1%D0%B0%D0%B7%D0%B5%20UML%20%D0%B4%D0%B8%D0%B0%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%20%D0%BA%D0%BB%D0%B0%D1%81%D1%81%D0%BE%D0%B2 %0A
- %D1%81%D0%BE%D0%B7%D0%B4%D0%B0%D0%B2%D0%B0%D1%82%D1%8C%20UML%20%D0%B4%D0%B8%D0%B0%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D1%8B%20%D0%B8%D0%B7%20%D0%BA%D0%BE%D0%B4%D0%B0 %0A
- %D0%B8%D0%BC%D0%BF%D0%BE%D1%80%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D1%82%D1%8C%20UML%20%D0%B4%D0%B8%D0%B0%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D1%8B%20%D0%BA%D0%BB%D0%B0%D1%81%D1%81%D0%BE%D0%B2,%20%D0%B4%D0%B8%D0%B0%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D1%8B%20%D0%BF%D0%BE%D1%81%D0%BB%D0%B5%D0%B4%D0%BE%D0%B2%D0%B0%D1%82%D0%B5%D0%BB%D1%8C%D0%BD%D0%BE%D1%81%D1%82%D0%B5%D0%B9,%20%D0%B4%D0%B8%D0%B0%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D1%8B%20%D0%B2%D0%B0%D1%80%D0%B8%D0%B0%D0%BD%D1%82%D0%BE%D0%B2%20%D0%B8%D1%81%D0%BF%D0%BE%D0%BB%D1%8C%D0%B7%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D1%8F%20%D1%81%20XMI%202.1 %0A
- %D1%81%D0%BE%D0%B7%D0%B4%D0%B0%D0%B2%D0%B0%D1%82%D1%8C%20%D0%B4%D0%B8%D0%B0%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D1%8B%20%D0%B7%D0%B0%D0%B2%D0%B8%D1%81%D0%B8%D0%BC%D0%BE%D1%81%D1%82%D0%B5%D0%B9%20%D0%B4%D0%BB%D1%8F%20ASP.NET,%20C%20%D0%B8%20C++%20%D0%BF%D1%80%D0%BE%D0%B5%D0%BA%D1%82%D0%BE%D0%B2 %0A
- %D1%81%D0%BE%D0%B7%D0%B4%D0%B0%D0%B2%D0%B0%D1%82%D1%8C%20%D0%B8%20%D0%BF%D1%80%D0%BE%D0%B2%D0%B5%D1%80%D1%8F%D1%82%D1%8C%20layer%20diagrams%20%D0%B4%D0%BB%D1%8F%20C%20%D0%B8%20C++%20%D0%BF%D1%80%D0%BE%D0%B5%D0%BA%D1%82%D0%BE%D0%B2 %0A
- %D0%BF%D0%B8%D1%81%D0%B0%D1%82%D1%8C%20%D1%81%D0%BE%D0%B1%D1%81%D1%82%D0%B2%D0%B5%D0%BD%D0%BD%D1%8B%D0%B5%20%D0%BF%D1%80%D0%BE%D0%B2%D0%B5%D1%80%D0%BA%D0%B8%20%D0%B4%D0%BB%D1%8F%20layer%20diagrams %0A
%D0%A1%D0%BA%D0%B0%D1%87%D0%B0%D1%82%D1%8C%20Visualization%20and%20Modeling%20Feature%20Pack%20%D0%BC%D0%BE%D0%B6%D0%BD%D0%BE%20%D0%BF%D0%BE%20%D1%81%D1%81%D1%8B%D0%BB%D0%BA%D0%B5:%20
IBM Rational Rose
Возможности:
- Use case diagram (диаграммы прецедентов);
- Deployment diagram (диаграммы топологии);
- Statechart diagram (диаграммы состояний);
- Activity diagram (диаграммы активности);
- Interaction diagram (диаграммы взаимодействия);
- Sequence diagram (диаграммы последовательностей действий);
- Collaboration diagram (диаграммы сотрудничества);
- Class diagram (диаграммы классов);
- Component diagram (диаграммы компонент).
Скриншоты:
Open source программы
StarUML
Возможности:
- поддержка UML 2.0
- MDA (Model Driven Architecture)
- Plug-in Architecture (писать можно на COM совместимых языках: C++, Delphi, C#, VB, ...)
StarUML написана, в основном, на Delphi, но дописывать компоненты можно и на других языках, например C/C++, Java, Visual Basic, Delphi, JScript, VBScript, C#, VB.NET. Ниже показано несколько скриншотов.
Диаграмма классов:
Use case диаграмма:
ArgoUML
Поддерживаемые диаграммы:
- Class
- State
- Use case
- Activity
- Collaboration
- Deployment
- Sequence
Возможности:
- Поддержка девяти UML 1.4 диаграмм
- Платформонезависимая (Java 5+)
- Стандартная метамодель UML 1.4
- Поддержка XMI
- Экспорт в GIF, PNG, PS, EPS, PGML и SVG
- Языки: EN, EN-GB, DE, ES, IT, RU, FR, NB, PT, ZH
- Поддержка OCL
- Forward, Reverse Engineering
Скриншот:
