Лекция
Привет, сегодня поговорим про uml, обещаю рассказать все что знаю. Для того чтобы лучше понимать что такое uml, диаграммы классов, диаграммы состояний , настоятельно рекомендую прочитать все из категории Объектно-ориентированное программирование ООП.
UML (Unified Modeling Language) - унифицированный язык моделирования.
1. UML — это язык
UML - язык формальный и искусственный. Искусственный он потому, что у него имеются авторы: Гради Буч, Ивар Якобсон и Джеймс Рамбо(в то же время, развитие UML непрерывно продолжается, что ставит его в один ряд с естественными языками). Формальным его можно назвать, поскольку имеются правила его употребления (правда, описание UML содержит и явно неформальные элементы). Еще один нюанс: UML - графический язык моделироапния общего назначения (т. е. его можно применять для проектирования чего угодно - от простых качелей, до сложного аппаратно-программного комплекса или даже космического корабля), предназначенный для спецификации, визуализации, проектирования и документирования всех артефактов, создаваемых в ходе разработки.
Как и любой формальный искусственный язык, UML содержит следующие части:
2. UML — это язык моделирования
Причем объектно-ориентированного моделирования. В английском языке есть целых два слова - modeling и simulation, которые оба переводятся как "моделирование", хотя означают разные понятия. Modeling подразумевает создание модели, лишь описывающей объект, а simulation предполагает получение с помощью созданной модели некоторой дополнительной информации об объекте. UML в первую очередь - язык моделирования именно в первом смысле, то есть средство построения описательных моделей. Хотя как средство симулирования его тоже можно использовать.
3. UML — это унифицированный язык моделирования
UML является отнюдь не первым языком моделирования. К моменту его появления насчитывались десятки других, различающихся системой обозначений, степенью универсальности, способами применения. В литературе можно встретить описание эры "до UML" как "войны методов" моделирования, ни один из которых "не дотягивал" до уровня индустриального стандарта. В начале 90-х годов прошлого века три крупнейших специалиста в этой области, авторы наиболее популярных методов, решились объединить усилия именно с целью унификации своих (и не только своих) разработок в соответствии с социальным заказом. Авторы UML при поддержке и содействии всей международной программистской общественности смогли свести воедино (унифицировать) большую часть того, что было известно и до них. В результате унификации получилась теоретически изящная и практически полезная вещь — UML.
Итак, UML - искусственный язык, который имеет некоторые черты естественного языка, и формальный язык, который имеет черты неформального. Модель UML - это набор диаграмм.
Диаграмма - это графическое представление множества элементов. Обычно изображается в виде графа с вершинами (сущностями) и ребрами (отношениями). Примеров диаграмм множество: блок-схема, схема монтажа оборудования, дерево файлов.
При проектировании ПО с помощью диаграмм можно визуализировать систему с различных точек зрения. Одна из диаграмм, например, может описывать взаимодействие пользователя с системой, другая - изменение состояний системы в процессе ее работы, третья - взаимодействие между собой элементов системы. Сложную систему можно и нужно представить в виде набора небольших и почти независимых моделей-диаграмм, причем ни одна из них не является достаточной для описания системы и получения полного представления о ней, поскольку каждая из них фокусируется на каком-то определенном аспекте функционирования системы и выражает разный уровень абстракции. Другими словами, каждая модель соответствует некоторой определенной, частной точке зрения на проектируемую систему. Ни одна отдельная диаграмма не является моделью. Диаграммы - лишь средство визуализации модели, и эти два понятия следует различать. Лишь набор диаграмм составляет модель системы и наиболее полно ее описывает, а не одна диаграмма, вырванная из контекста. Более подробно рассмотрим типы диаграмм.
Структурные диаграммы:
Диаграммы поведения:
Диаграммы взаимодействия:
Диаграмма классов
Диаграмма классов (class diagram) - статическая структурная диаграмма, описывающая структуру системы, она демонстрирует классы системы, их атрибуты, методы и зависимости между классами. Это один из наиболее часто используемых видов диаграмм UML. Обычно создание диаграммы классов знаменует собой окончание процесса анализа и начало процесса проектирования.
Диаграмма классов состоит из множества элементов, которые в совокупности отражают декларативные знания о предметной области. Эти знания интерпретируются в базовых понятиях языка UML, таких как классы, интерфейсы и отношения между ними и их составляющими компонентами. При этом отдельные компоненты этой диаграммы могут образовывать пакеты для представления более общей модели системы. Если диаграмма классов является частью некоторого пакета, то ее компоненты должны соответствовать элементам этого пакета, включая возможные ссылки на элементы из других пакетов.
Класс
Класс в языке UML служит для обозначения множества объектов, которые обладают одинаковой структурой, поведением и отношениями с объектами из других классов. Класс на диаграмме изображается в виде прямоугольника, разделенного горизонтальными линиями на три части. В первой части указывается название класса. Вторая часть содержит перечень атрибутов класса, которые характеризуют тот или иной объект этого класса в модели предметной области. Третья часть содержит перечень операций, отражающих его поведение в модели предметной области.
Интерфейс
Интерфейс - это не только и не столько группа операций объекта. Интерфейс отражает внешние проявления объекта, показывает, каким образом осуществляется взаимодействие с ним, скрывая остальные детали, не имеющие отношения к процессу взаимодействия. Объект является отдельным экземпляром класса, который создается на этапе выполнения программы. Он имеет свое собственное имя и конкретные значения атрибутов. Для изображения интерфейса используется специальный графический символ - прямоугольник класса с ключевым словом или стереотипом "interface". При этом секция атрибутов у прямоугольника отсутствует, а указывается только секция операций.
Интерфейс всегда реализуется некоторым классом, который в таком случае называют классом, поддерживающим интерфейс. Один и тот же объект может иметь несколько интерфейсов. Это означает, что класс этого объекта реализует все операции этих интерфейсов.
Шаблон
Шаблон (template) или параметризованный класс (parametrized class) предназначен для обозначения такого класса, который имеет один (или более) нефиксированный формальный параметр. Он определяет целое семейство или множество классов, каждый из которых может быть получен связыванием этих параметров с действительными значениями. Обычно параметрами шаблонов служат типы атрибутов классов, такие как целые числа, перечисление, массив строк и др. В более сложном случае формальные параметры могут представлять и операции класса.
Графически шаблон изображается прямоугольником, к верхнему правому углу которого присоединен маленький прямоугольник из пунктирных линий, большой прямоугольник может быть разделен на секции, аналогично обозначению для класса. В верхнем прямоугольнике указывается список формальных параметров для тех классов, которые могут быть получены на основе данного шаблона. В верхней секции шаблона записывается его имя по правилам записи имен для классов.
Отношения между классами
Кроме внутреннего устройства или структуры классов на соответствующей диаграмме указываются различные отношения между классами. При этом совокупность типов таких отношений фиксирована в языке UML и предопределена семантикой этих типов отношений. Базовыми отношениями или связями в языке UML являются:
Отношение зависимости
Отношение зависимости в общем случае указывает некоторое семантическое отношение между двумя элементами модели или двумя множествами таких элементов, которое не является отношением ассоциации, обобщения или реализации. Оно касается только самих элементов модели и не требует множества отдельных примеров для пояснения своего смысла. Отношение зависимости используется в такой ситуации, когда некоторое изменение одного элемента модели может потребовать изменения другого зависимого от него элемента модели.
Отношение ассоциации
Отношение ассоциации соответствует наличию некоторого отношения между классами. Данное отношение обозначается сплошной линией с дополнительными специальными символами, которые характеризуют отдельные свойства конкретной ассоциации. В качестве дополнительных специальных символов могут использоваться имя ассоциации, а также имена и кратность классов-ролей ассоциации. Имя ассоциации является необязательным элементом ее обозначения. Если оно задано, то записывается с заглавной (большой) буквы рядом с линией соответствующей ассоциации.
Отношение обобщения Отношение обобщения является обычным таксономическим отношением между более общим элементом (родителем или предком) и более частным или специальным элементом (дочерним или потомком). Данное отношение может использоваться для представления взаимосвязей между пакетами, классами, вариантами использования и другими элементами языка UML.
Применительно к диаграмме классов данное отношение описывает иерархическое строение классов и наследование их свойств и поведения. При этом предполагается, что класс-потомок обладает всеми свойствами и поведением класса-предка, а также имеет свои собственные свойства и поведение, которые отсутствуют у класса-предка. На диаграммах отношение обобщения обозначается сплошной линией с треугольной стрелкой на одном из концов. Стрелка указывает на более общий класс (класс-предок или суперкласс), а ее отсутствие - на более специальный класс (класс-потомок или подкласс).
Отношение агрегации
Отношение агрегации имеет место между несколькими классами в том случае, если один из классов представляет собой некоторую сущность, включающую в себя в качестве составных частей другие сущности. Данное отношение имеет фундаментальное значение для описания структуры сложных систем, поскольку применяется для представления системных взаимосвязей типа "часть-целое". Раскрывая внутреннюю структуру системы, отношение агрегации показывает, из каких компонентов состоит система и как они связаны между собой.
Отношение композиции
Отношение композиции является частным случаем отношения агрегации. Это отношение служит для выделения специальной формы отношения "часть-целое", при которой составляющие части в некотором смысле находятся внутри целого. Специфика взаимосвязи между ними заключается в том, что части не могут выступать в отрыве от целого, т. е. с уничтожением целого уничтожаются и все его составные части.
Диаграмма состояний
В отличие от других диаграмм диаграмма состояний описывает процесс изменения состояний только одного класса, а точнее - одного экземпляра определенного класса, т. е. моделирует все возможные изменения в состоянии конкретного объекта. При этом изменение состояния объекта может быть вызвано внешними воздействиями со стороны других объектов или извне.
Главное предназначение этой диаграммы - описать возможные последовательности состояний и переходов, которые в совокупности характеризуют поведение элемента модели в течение его жизненного цикла. Диаграмма состояний представляет динамическое поведение сущностей, на основе спецификации их реакции на восприятие некоторых конкретных событий.
Хотя диаграммы состояний чаще всего используются для описания поведения отдельных экземпляров классов (объектов), но они также могут быть применены для спецификации функциональности других компонентов моделей, таких как варианты использования, актеры, подсистемы, операции и методы.
Диаграмма состояний по существу является графом специального вида, который представляет некоторый автомат. Об этом говорит сайт https://intellect.icu . Понятие автомата в контексте UML обладает довольно специфической семантикой, основанной на теории автоматов:). Вершинами этого графа являются состояния и некоторые другие типы элементов автомата (псевдосостояния), которые изображаются соответствующими графическими символами. Дуги графа служат для обозначения переходов из состояния в состояние. Диаграммы состояний могут быть вложены друг в друга, образуая вложенные диаграммы более детального представления отдельных элементов модели.
Состояние
В языке UML под состоянием (state) понимается абстрактный метакласс, используемый для моделирования отдельной ситуации, в течение которой имеет место выполнение некоторого условия. Состояние может быть задано в виде набора конкретных значений атрибутов класса или объекта, при этом изменение их отдельных значений будет отражать изменение состояния моделируемого класса или объекта.
Следует заметить, что не каждый атрибут класса может характеризовать его состояние. Как правило, имеют значение только такие свойства элементов системы, которые отражают динамический или функциональный аспект ее поведения. В этом случае состояние будет характеризоваться некоторым инвариантным условием, включающим в себя только значимые для поведения класса атрибуты и их значения.
Состояние на диаграмме изображается прямоугольником со скругленными вершинами. Этот прямоугольник, в свою очередь, может быть разделен на две секции горизонтальной линией. Если указана лишь одна секция, то в ней записывается только имя состояния. В противном случае в первой из них записывается имя состояния, а во второй - список некоторых внутренних действий или переходов в данном состоянии. При этом под действием в языке UML понимают некоторую атомарную операцию, выполнение которой приводит к изменению состояния или возврату некоторого значения (например, "истина" или "ложь").
Начальное и конечное состояния:
Начальное состояние представляет собой частный случай состояния, которое не содержит никаких внутренних действий. В этом состоянии находится объект по умолчанию в начальный момент времени. Оно служит для указания на диаграмме состояний графической области, от которой начинается процесс изменения состояний. Графически начальное состояние в языке UML обозначается в виде закрашенного кружка, из которого может только выходить стрелка, соответствующая переходу.
Конечное (финальное) состояние представляет собой частный случай состояния, которое также не содержит никаких внутренних действий. В этом состоянии будет находиться объект по умолчанию после завершения работы автомата в конечный момент времени. Оно служит для указания на диаграмме состояний графической области, в которой завершается процесс изменения состояний или жизненный цикл данного объекта. Графически конечное состояние в языке UML обозначается в виде закрашенного кружка, помещенного в окружность, в которую может только входить стрелка, соответствующая переходу.
Переход
Переход (transition) представляет собой отношение между двумя последовательными состояниями, которое указывает на факт смены одного состояния другим. Пребывание моделируемого объекта в первом состоянии может сопровождаться выполнением некоторых действий, а переход во второе состояние будет возможен после завершения этих действий, а также после удовлетворения некоторых дополнительных условий. В этом случае говорят, что переход срабатывает. До срабатывания перехода объект находится в предыдущем от него состоянии, называемым исходным состоянием, или в источнике (не путать с начальным состоянием - это разные понятия), а после его срабатывания объект находится в последующем от него состоянии (целевом состоянии). Переход обозначается стрелкой.
Переходы между параллельными состояниями
В отдельных случаях переход может иметь несколько состояний-источников и несколько целевых состояний. Такой переход получил специальное название - параллельный переход. Введение в рассмотрение параллельного перехода обусловлено необходимостью синхронизировать и/или разделить отдельные подпроцессы на параллельные нити без спецификации дополнительной синхронизации в параллельных подавтоматах.
Графически такой переход изображается вертикальной черточкой. Если параллельный переход имеет две или более входящих дуг, то его называют соединением (join). Если же он имеет две или более исходящих из него дуг, то его называют ветвлением (fork). Текстовая строка спецификации параллельного перехода записывается рядом с черточкой и относится ко всем входящим (исходящим) дугам.
Диаграмма последовательностей
Диаграмма последовательностей (sequence diagram) используется для точного определения логики сценария выполнения прецедента. Диаграммы последовательностей отображают типы объектов, взаимодействующих при исполнении прецедентов, сообщения, которые они посылают друг другу, и любые возвращаемые значения, ассоциированные с этими сообщениями. Прямоугольники на вертикальных линиях показывают "время жизни" объекта. Линии со стрелками и надписями названий методов означают вызов метода у объекта. На диаграммы может быть добавлена управляющая информация: описание условий, при которых посылается сообщение; признак многократной отправки сообщения (маркер итерации); признак возврата сообщения.
На диаграмме последовательности изображаются исключительно те объекты, которые непосредственно участвуют во взаимодействии и не показываются возможные статические ассоциации с другими объектами. Для диаграммы последовательности ключевым моментом является именно динамика взаимодействия объектов во времени. При этом диаграмма последовательности имеет как бы два измерения. Одно - слева направо в виде вертикальных линий, каждая из которых изображает линию жизни отдельного объекта, участвующего во взаимодействии. Графически каждый объект изображается прямоугольником и располагается в верхней части своей линии жизни. Внутри прямоугольника записываются имя объекта и имя класса, разделенные двоеточием. При этом вся запись подчеркивается, что является признаком объекта, который, как известно, представляет собой экземпляр класса.
Линия жизни объекта
Линия жизни объекта (lifeline) изображается пунктирной вертикальной линией, ассоциированной с единственным объектом на диаграмме последовательности. Линия жизни служит для обозначения периода времени, в течение которого объект существует в системе и, следовательно, может потенциально участвовать во всех ее взаимодействиях. Если объект существует в системе постоянно, то и его линия жизни должна продолжаться по всей плоскости диаграммы последовательности от самой верхней ее части до самой нижней.
Отдельные объекты, выполнив свою роль в системе, могут быть уничтожены, чтобы освободить занимаемые ими ресурсы. Для таких объектов линия жизни обрывается в момент его уничтожения. Вовсе не обязательно создавать все объекты в начальный момент времени. Отдельные объекты в системе могут создаваться по мере необходимости.
Сообщения
Каждое взаимодействие описывается совокупностью сообщений, которыми участвующие в нем объекты обмениваются между собой. В этом смысле сообщение (message) представляет собой законченный фрагмент информации, который отправляется одним объектом другому. При этом прием сообщения инициирует выполнение определенных действий, направленных на решение отдельной задачи тем объектом, которому это сообщение отправлено.
Таким образом, сообщения не только передают некоторую информацию, но и требуют или предполагают от принимающего объекта выполнения ожидаемых действий. Сообщения могут инициировать выполнение операций объектом соответствующего класса, а параметры этих операций передаются вместе с сообщением. На диаграмме последовательности все сообщения упорядочены по времени своего возникновения в моделируемой системе.
В таком контексте каждое сообщение имеет направление от объекта, который инициирует и отправляет сообщение, к объекту, который его получает. При этом сообщение от клиента имеет форму запроса некоторого сервиса, а реакция сервера на запрос после получения сообщения может быть связана с выполнением определенных действий или передачи клиенту необходимой информации тоже в форме сообщения. Обычно сообщения изображаются горизонтальными стрелками, соединяющими линии жизни.
Типы сообщений:
В языке UML предусмотрены некоторые стандартные действия, выполняемые в ответ на получение соответствующего сообщения. Используются следующие основные типы сообщений для моделирования действий:
Другой вид сообщений - асинхронные сообщения. Они не ждут ответа, не приостанавливают поток выполнения - сразу после их посылки происходит немедленный переход к следующему шагу, и последовательность продолжается.
Временные ограничения на диаграммах последовательности
В отдельных случаях выполнение тех или иных действий на диаграмме последовательности может потребовать явной спецификации временных ограничений, накладываемых на сам интервал выполнения операций или передачу сообщений. В языке UML для записи временных ограничений используются фигурные скобки, {d..t}. Временные ограничения могут относиться как к выполнению определенных действий объектами, так и к самим сообщениям.
Диаграмма объектов
Диаграмма объектов содержит множество экземпляров сущностей, представленных на диаграмме классов. Таким образом, диаграммы объектов выражают статическую составляющую взаимодействия и состоят из сотрудничающих объектов, однако сообщения на них не показаны. Диаграмма объектов отражает состояние системы в фиксированный момент времени.
Диаграмма объектов характеризуется следующими свойствами:
Основные элементы диаграммы объектов, так же как и диаграммы классов - класс и интерфейс описаны выше. Основные отношения на диаграмме объектов:
ArgoUML является открытым программным обеспечением(OpenSource) и распространяется под лицензией BSD.
ArgoUML полностью написан на Java и для работы ему подходит любая операционная система с установленной Java 2 JRE или JDK версии 1.4 или выше. Функциональность ArgoUML включает в себя:
Позволяет работать со следующими диаграммами:
Программный продукт UModel, разработанный компанией Altova, - это UML-редактор с функцией замкнутого инжиниринга. Он поддерживает UML 2.3 и реализует кодогенерацию и обратный реинжиниринг для языков программирования C#, VB.NET и Java. Дополнительно UModel реализует диаграммы для работы с XML-схемами и нотацией BPMN и реализует плагины для Microsoft Visual Studio и Eclips.
В AltovaUModel поддерживается работа со всеми диаграммами спецификации UML 2.3
Описание интерфеса
Интерфейс UModel содержит несколько вспомогательных панелей. На панели Model Tree отображается иерархия элементов текущей UML-модели. Панель позволяет манипулировать элементами - удалять, изменять элементы, сортировать их по заданным критериям и т. п. На панели Diagram Tree отображается полный список UML-диаграмм, используемых в проекте. Диаграммы можно отображать в виде общего списка либо в виде дерева, когда диаграммы сгруппированы по типам. Панель Favorites позволяет вести список часто используемых UML-элементов - классов, объектов, ассоциаций и т. п. - и иметь к ним быстрый доступ. Панели Properties и Styles отображают список свойств и стилей выбранного UML-элемента, а панель Hierarchy - все связи выбранного элемента в графическом виде или в виде дерева. Панель Overview отображает общую схему текущей диаграммы, панель Documentation позволяет документировать выбранный UML-элемент. Наконец, панель Layers позволяет управлять размещением элементов диаграммы на разных слоях - точно так же, как это делается в графических редакторах, - создавать, удалять слои, блокировать их от изменений и т. п. Имеется еще одна вспомогательная панель Messages, на которой отображаются сообщения об ошибках, предупреждения и подсказки, которые программа генерирует в процессе инжиниринга, проверки синтаксиса проекта и т. п. 
Элементы добавляются на диаграммы с помощью панели инструментов или через контекстное меню.
Генерация кода и обратный инжиниринг
UModel реализует функции замкнутого инжиниринга - позволяет генерировать код на основе UML-диаграмм, создавать UML-диаграммы на основе имеющегося кода и выполнять автоматическую синхронизацию кода и модели. Поддерживается кодогенерация для Java 1.4, Java 5.0, Java 6.0, C# 1.2, C# 2.0, C# 3.0, VB 7.1, VB8.0 и VB 9.0. Поддерживается на хорошем уровне - есть даже возможность использовать обобщенные типы (generics). Для того чтобы в UModel создать новый класс и сгенерировать для него рабочий код, достаточно выполнить всего несколько шагов. Прежде всего создаем новый проект и подсоединяем к проекту UML-профиль, описывающий синтаксис требуемого языка программирования. Далее добавляем в UML-модель новый класс и указываем его свойства и методы. После этого создаем новый компонент и выбираем для него рабочую директорию - в нее будут сохраняться файлы, сгенерированные для классов этого компонента. Связываем класс и компонент, указывая, что класс должен быть реализован в этом компоненте. В итоге даем команду провести проверку синтаксиса в проекте. UModel проверяет синтаксис, сообщает о всех потенциальных проблемах (например, тип возвращаемых методом данных не указан) и генерирует код.
Код генерируется на основе шаблонов кодогенерации, заданных в отдельных файлах. Шаблоны можно отредактировать - учесть необходимые соглашения об именовании, добавить поддержку использования сторонних библиотек и т. п. Шаблоны реализованы на языке Spy programming language (SPL).
Поддерживается два режима обратного реинжиниринга - создание нового проекта или обновление текущего проекта. Возможность обновления текущей UML-модели делает возможным реализацию функции замкнутого инжиниринга, когда UML-модель и код автоматически синхронизируются.
Исходная UML-модель может применяться не только для генерации исходных кодов, но и для генерации документации. UModel позволяет сгенерировать документацию в форматах Word, RTF и HTML.
Дополнительные диаграммы: XML-схемы и BPMN
Помимо стандартных UML-диаграмм, UModel реализует две дополнительные - диаграммы для XML-схем и BPMN-диаграммы (Business Process Modeling Notation).
Работа с XML-схемами в Altova UModel
Программа UModel способна отображать XML-схемы в формате, полностью аналогичном UML-моделям классов. Фактически UModel рассматривает XML-схемы как еще один своеобразный "язык программирования" - для XML-схем точно так же поддерживаются функции кодогенерации и обратного инжиниринга.
Поддержка диаграмм BPMN
BPMN-диаграммы являются стандартом OMG и активно применяются при моделировании бизнес-процессов бизнес-аналитиками, техническими разработчиками, бизнес-менеджерами и т. д. UModel не только полностью реализует возможности диаграмм BPMN, но и дополняет их полезными возможностями. Например, поддержка слоев делает возможным размещение комментариев в диаграммах BPMN на отдельном слое, что чрезвычайно удобно на практике.
XMI
UModel реализует полноценную поддержку импорта и экспорта данных в формате XMI версии 2.1. Такая поддержка делает возможным обмен данными между UModel и другими UML-инструментами, разработанными, в частности, сторонними разработчиками. Для удобства в UModel реализована обратная совместимость с UML 2.1 и UML 2.0 - на случай, если потребуется открыть созданные диаграммы в UML-редакторе, не поддерживающем UML 2.3. Поддержка XMI позволяет создавать "стандартные" архивные копии проектов UModel, которые можно открывать с помощью любых современных UML-редакторов.
MagicDraw - профессиональная программа, предназначенная для визуального UML моделирования, а также инструментом CASE с поддержкой совместной работы с поддержкой коллективной работы. Язык UML представляет собой общецелевой язык визуального моделирования, который разработан для спецификации, визуализации, проектирования и документирования компонентов программного обеспечения, бизнес-процессов и других систем. MagicDraw UML одновременно является простым и мощным средством моделирования, который может быть эффективно использован для построения концептуальных, логических и графических моделей сложных систем самого различного целевого назначения. Предназначен для бизнес-аналитиков, программистов и инженеров.
MagicDraw, так же как и UModel реализует функции замкнутого инжиниринга - позволяет генерировать код на основе UML-диаграмм, создавать UML-диаграммы на основе имеющегося кода. Поддерживается кодогенерация для таких языков, как Java, EJB, C#, C++, CORBA IDL, DDL, WSDL, XML. Teamwork Server - предназначен для работы группой разработчиков с одной моделью. Поддерживает интеграцию со следуюшими программными средствами:
MagicDraw работает с большинством операционных систем, таких как Windows 98/Me/NT/2000/XP/Vista, Solaris, OS / 2, Linux, HP-UX, AIX, MacOS (X), как и любые другие, поддерживающие Java 5 или 6.
MagicDraw позволяет работать со следующими диаграммами:
Программа Enterprise Architect разработана Sparx Systems. На данный момент доступна версия программы Enterprise Architect 7.5. Программа отличается сравнительно низкой ценой, по сравнению с другими системами управления требованиями. По данным SparxSystems почти 200 000 зарегистрированных пользователей во всем мире работают с данной программой.
Enterprise Architect (EA) – CASE-инструмент для проектирования и конструирования программного обеспечения. EA поддерживает спецификацию UML2.0+, описывающую визуальный язык, которым могут быть определены модели проекта. Некоторые из ключевых функций ЕА:
Используя EA, можно выполнять форвард и реверс-инжиниринг ActionScript, C++, C#, Delphi, Java, Python, PHP, VB.NET and Visual Basic классов, синхронизировать код и элементы моделей, проектировать и генерировать элементы баз данных. Из моделей может быть быстро создана документация в стандартном rtf-формате и импортирована в Word для финального редактирования, так же доступна генерация HTML-документов. EA поддерживает все модели/диаграммы UML 2.0. С его помощью можно моделировать бизнес-процессы, веб-сайты, пользовательские интерфейсы, сети, конфигурации аппаратного обеспечения, сообщения и т.д., оценивать размер трудозатрат проектных работ в часах, фиксировать и трассировать требования, ресурсы, тест-планы, дефекты и запросы на изменения. Т.о. EA – современный инструмент, который поддерживает все аспекты цикла разработки, обеспечивая полную трассировку от начала проектирования до размещения и поддержки. Также он обеспечивает поддержку тестирования, управления сопровождением и изменениями.
Создание нового проекта и внешний вид системы
При создании нового проекта программа предлагает выбрать один из предустановленных моделей проекта. Доступны следующие модели: Bussiness Process, Requirements, Use Case, Domain Model, Class, Database, Component, Deployment, Testing, Maintenance, Project Management, User Interface.
Рабочая область программы при работе с диаграммами разбита по умолчанию на четыре основных части(не берем в расчет панель инструментов, строку состояния и панель меню): Project Browser Model View, Resourses, Notes, Toolbox и, собственно, панель Diagram.
Кратко опишем назначение каждой панели:
Microsoft Visio — редактор диаграмм и блок-схем для Windows. Использует векторную графику для создания диаграмм.
Выпускается в двух редакциях: Standard и Professional. Первоначально Visio разрабатывался и выпускался компанией Visio Corporation. Microsoft приобрела компанию в 2000 году, когда продукт назывался Visio 2000.
С помощью Microsoft Visio возможно наглядно документировать, разрабатывать и оценивать состояние бизнес-процессов и систем, пользуясь широким набором доступных диаграмм, в том числе блок-схемами деловых процессов, сетевыми диаграммами, диаграммами рабочего потока, моделями базы данных и диаграммами программного обеспечения. Чтобы сделать диаграммы еще более полезными и наглядными, возможно связать их в Microsoft Visio Professional 2007 с исходными данными.
Этот пакет из семейства Microsoft Office предназначен исключительно для рисования диаграмм. Visio имеет некоторые дополнительные возможности, но все же по большей мере - это только средство для иллюстрирования документов MS Office, "не дотягивающее" до уровня пакетов, описанных ранее.
Изобразительные же возможности Visio действительно весьма широки, кроме того программа поддерживает:
Visio - это не полноценное средство моделирования, а программа для создания иллюстраций (как и SmartDraw и Dia), умеющая, кроме прочего, рисовать UML-диаграммы.
Всемирную известность термин «паттерн» получил после публикации книги «Приемы объектно-ориентированного проектирования. Паттерны проектирования». Авторы книги, Э. Гамма, Р. Хелм, Р. Джонсон, Дж. Влиссидес больше известны, как «Банда четырех» (Gang of Four, часто сокращается до GoF). В этой книге было описано всего 23 шаблона, но она дала толчок к появлению новых работ на эту тему.
Можно сказать, что паттерны — это стандартные решения типовых задач, возникающих в объектно-ориентированном проектировании, некий набор готовых решений, пригодных для большинства задач.
Опытные разработчики объектно-ориентированных систем сформулировали общие принципы и стандартные решения, помогающие в разработке программного обеспечения. Если эти принципы и идиомы систематизировать и структурировать, а также присвоить им имена, то их можно применять в качестве паттернов/шаблонов(patterns).
Например,Паттерн Information Expert
В объектно-ориентированной технологии проектирования паттерном называют именованное описание проблемы и ее решения, которые можно применить при разработке других систем. В идеале паттерн должен содержать советы по поводу его применения в различных ситуациях, а также описание его преимуществ и недостатков. Многие паттерны содержат рекомендации по распределению обязанностей между объектами с учетом специфики задачи.
Проще говоря, паттерн - это именованная пара "проблема-решение", содержащая рекомендации для применения в различных конкретных ситуациях, которую можно использовать в различных контекстах.
Из приведенного выше определения можно сделать вывод, что паттерн должен иметь имя. Паттерны имеют осмысленные имена, например Information Expert или Factory. Именование паттернов имеет следующие преимущества:
Порождающие паттерны
В этой группе собраны паттерны, описывающие разные способы создания объектов. Прежде всего это «Фабричный метод» (Factory Method), прием определения интерфейса создания объектов, при этом выбранный класс воплощается в подклассах. Шаблон «Абстрактная фабрика» (Abstract Factory) определяет интерфейс для создания семейств, связанных между собой или независимых объектов, конкретные классы которых неизвестны. С помощью шаблона «Строитель» (Builder) можно отделить процесс конструирования сложного объекта от его конкретного представления и при этом использовать один и тот же процесс для создания различных представлений. «Прототип» (Prototype) описывает виды разрабатываемых объектов с помощью прототипа и создает новые путем его копирования. Применение шаблона «Одиночка» (Singleton) гарантирует, что некоторый класс может иметь только один экземпляр (и предоставляет глобальную точку до ступа к нему).
Структурные паттерны
В этой группе собраны паттерны, которые позволяют менять структуру взаимодействия классов. «Адаптер» (Adapter) позволяет адаптировать интерфейс класса к конкретной ситуации, средствами шаблона «Мост» (Bridge) можно отделить интерфейс класса и его реализацию, «Компоновщик» (Composite) объединяет объекты в древовидную структуру для представления иерархии от частного к целому. Компоновщик позволяет клиентам единообразно обращаться к отдельным объектам и группам объектов. Паттерн «Оформитель» (Decorator, также известен как Wrapper, «Оболочка») позволяет динамически добавлять новое поведение к объекту, «Фасад» (Facade) — скрыть сложность системы путем сведения всех возможных внешних вызовов к одному объекту, делегирующему их соответствующим объектам системы. Шаблон «Приспособленец» (Flyweight) используется для облегчения работы с большим числом мелких объектов, а «Заместитель» (Proxy) — контролировать доступ к объекту, перехватывая все вызовы к нему.
Паттерны поведения
В этой группе собраны шаблоны, ответственные за реализацию поведения объектов. «Цепочка ответов» (Chain of Response) позволяет пропустить запрос через цепочку объектов, «Команда» (Command) инкапсулирует команду в объект, «Интерпретатор» (Interpreter) позволяет создать общее декларативное решение для часто изменяющихся условий задачи. В шаблоне «Итератор» (Iterator) организуется последовательный доступ к коллекции, «Посредник» (Mediator) определяет упрощенный механизм взаимодействия классов, «Напоминание» (Memento) задает принципы, позволяющие записывать и восстанавливать внутреннее состояние объекта. Средствами шаблона «Наблюдатель» (Observer) можно оповещать об изменениях множества объектов, «Состояние» (State) — менять поведение объекта при изменении его состояния. «Стратегия» (Strategy) инкапсулирует алгоритм внутри класса.
Паттерн «Шаблонный метод» (Template Method) выделяет конкретные шаги в алгоритме и опирается на подклассы для их реализации. Средствами паттерна «Посетитель» (Visitor) в класс добавляются новые операции без его изменения.
Примеры паттернов проектирования вы можете найти здесь
Примеры диаграмм,которые рассматривались на лабораторной:
На этом все! Теперь вы знаете все про uml, Помните, что это теперь будет проще использовать на практике. Надеюсь, что теперь ты понял что такое uml, диаграммы классов, диаграммы состояний и для чего все это нужно, а если не понял, или есть замечания, то не стесняйся, пиши или спрашивай в комментариях, с удовольствием отвечу. Для того чтобы глубже понять настоятельно рекомендую изучить всю информацию из категории Объектно-ориентированное программирование ООП
Комментарии
Оставить комментарий
Объектно-ориентированное программирование ООП
Термины: Объектно-ориентированное программирование ООП