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

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

UML позволяет также разработчикам программного обеспечения достигнуть соглашения в графических обозначениях для представления общих понятий (таких как класс, компонент, обобщение (generalization), объединение (aggregation) и поведение), и больше сконцентрироваться на проектировании и архитектуре.

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

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

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

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

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

Сформулировать общие требования к функциональному поведению проектируемой системы;

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

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

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

Диаграммой последовательностей (Sequence diagram) называется диаграмма взаимодействий, акцентирующая внимание на временной упорядоченности сообщений. Графически такая диаграмма представляет собой таблицу, объекты в которой располагаются вдоль оси X, а сообщения в порядке возрастания времени - вдоль оси Y. Диаграммой кооперации (Collaboration diagram) называется диаграмма взаимодействий, основное внимание в которой уделяется структурной организации объектов, принимающих и отправляющих сообщения. Графически такая диаграмма представляет собой граф из вершин и ребер.

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

Во-первых, на них показана линия жизни объекта. Это вертикальная пунктирная линия, отражающая существование объекта во времени. Большая часть объектов, представленных на диаграмме взаимодействий, существует на протяжении всего взаимодействия, поэтому их изображают в верхней части диаграммы, а их линии жизни прорисованы сверху донизу. Объекты могут создаваться и во время взаимодействий. Линии жизни таких объектов начинаются с получения сообщения со стереотипом create. Объекты могут также уничтожаться во время взаимодействий; в таком случае их линии жизни заканчиваются получением сообщения со стереотипом destroy, а в качестве визуального образа используется большая буква X, обозначающая конец жизни объекта.

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

Диаграммой классов (Class diagram) называют диаграмму, на которой показано множество классов, интерфейсов, коопераций и отношений между ними. Ее изображают в виде множества вершин и дуг.

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

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

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

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

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

Диаграмма компонентов (Component diagram) показывает набор компонентов и отношения между ними. Графически диаграмма компонентов представляется в виде графа с ребрами и вершинами.

На диаграмме развертывания, или применения (Deployment diagram), показана конфигурация обрабатывающих узлов, на которых выполняется система, и компонентов, размещенных в этих узлах. Диаграмма развертывания представлена в виде графа с ребрами и вершинами.

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

Цель работы. Ознакомление с методологией и инструментальными средствами моделирования классов на основе языка UML.

Задание. Ознакомиться с методологией моделирования классов на основе языка UML, используя методические указания и . Ознакомиться со средствами построения диаграмм классов программного продукта StarUML 5.0, используя . Разработать диаграмму классов автоматизированной системы согласно варианту индивидуального задания, используя инструментальное средство StarUML 5.0. Продемонстрировать проект и защитить работу преподавателю.

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

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

Также можно увидеть, что все вещи естественным образом разделяются по категориям (автомобили, мебель, стиральные машины и т.д.). Мы об­ращаемся к этим категориям как к классам. Класс – это категория или группа вещей, которая имеет сходные атрибуты и общие свойства. На­пример, любая вещь в классе стиральных машин имеет такие атрибуты, как производитель, номер изделия и емкость. Свойства вещей в этом классе включают операции «загрузить белье», «загрузить стиральный по­рошок», «включить» и «выгрузить белье».

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

Рис. 16. Изображение класса в UML

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

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

Диаграмма объектов

Объект представляет собой экземпляр класса – особую сущность, кото­рая имеет заданные значения атрибутов и операций. Ваша стиральная машина, например, может иметь атрибуты: компания-производитель – Laundatorium, наименование модели – Washmeister, серийный номер из­делия – GL57774 и емкость – 16 фунтов.

На рис. 17 показано, как объект представляется в обозначениях UML. Отметим, что объект изображается прямоугольником, как в случае представления класса, но его имя подчеркнуто. Наименование экземпляра размещено слева от двоеточия, а наиме­нование класса – с правой стороны.

Рис. 17. Представление объекта в UML

Прямоугольник – это условное обозначение класса в UML. Именем класса обычно является слово, начинающееся с прописной буквы. Оно располагается вверху прямоугольника. Если имя класса состоит из двух слов, объеди­ните их и второе слово тоже напишите с прописной буквы (например, Стиральная Машина, рис. 18).

Рис. 18. Обозначение класса в UML

Атрибуты

Атрибут – это свойство класса. Атрибуты описывают перечень значе­ний, в рамках которых указываются свойства объектов (т.е. экземпляров) этого класса. Класс может не иметь атрибутов или содержать любое их количество. Имена атрибутов, состоящие из одного слова, принято обо­значать строчными буквами. Если имя состоит из нескольких слов, то эти слова объединяются, и каждое слово, за исключением первого, начи­нается с прописной буквы. Список имен атрибутов начинается ниже ли­нии, отделяющей их от имени класса (рис. 19, 20).

UML позволяет отображать дополнительную информацию об атрибутах. В изобра­жении класса можно указать тип для каждого значения атрибута. Перечень возмож­ных типов включает строку, число с плавающей точкой, целое число, логическое зна­чение и другие перечислимые типы. Для отображения типа используется двоеточие, которое отделяет имя атрибута от его типа. Здесь же можно указать значение атрибута по умолчанию. На рис. 21 показан этот способ задания атрибутов.

Рис. 20. Значения атрибутов класса

brandName: String = "Laundatorium"

modelName: String

serialNumber: String

capacity: Integer

Рис. 21. Типы атрибутов и значения по умолчанию

Перечислимый тип представляет собой информацию, заданную списком именованных значений. Логический тип также является перечислимым, по­тому что он состоит из значений «истина» и «ложь». Можно определить свои собственные перечислимые типы (например, Состояние), образованные из значений «твердое», «жидкое» и «газообразное».

Операции

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

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

Перечисленные фрагменты информации об операции носят название сигнатуры операции. На рис. 23 представлены операции класса и ее сигнатура .

Рис. 22. Операции класса и их сигнатуры

addClothes(C:String)

removeClothes(С:String)

addDetergent(D:Integer)

turnOn():Boolean

Рис. 23. Сигнатуры операций класса

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

Стереотип является гибкой конструкцией, которую можно использовать по-разному. Например, если разместить его над именем класса, то можно ука­зать дополнительную информацию о роли этого класса.

Рис. 24. Задание стереотипов

Обязанности и ограничения

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

На изображении класса его обязанности перечисляются ниже области операций (рис. 25).

«идентификационные данные»

«данные о машине»

«для белья»

«для машины»

Обязанность:

взять грязное белье на входе

и выдать чистое

на выходе

Рис. 25. Обязанности класса

Главное заключается в том, чтобы наиболее точно описать класс, поэтому включение обязанностей является неформальным способом исключить двусмысленность описания.

Более формальным путем решения задачи является добавление ограниче­ний в виде произвольного текста, заключенного в фигурные скобки. Этот текст задает одно или несколько правил класса, к которому он относится. Предположим, для класса WashingMachine нужно указать, что емкость барабана может составлять только 16, 18 или 20 фунтов (и таким образом «ограничить» атрибут емкости). Тогда рядом с изображением класса нужно написать (capacity = 16 или 18 или 20 фунтов). На рис. 26 показано, как это сделать.

Рис. 26. Ограничения классов

Комментарии

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

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

Рис. 27. Типы атрибутов и значения по умолчанию

Комментарий наряду с текстом может содержать также и графические объекты.

Недостающая информация – это взаимодействие классов между собой. Если взглянуть на модель (рис. 28), то можно заметить отсутствие связи игрока с мячом. Из самой модели не понятно, как игроки образуют команду или как происходит игра. Сконструи­рован лишь список терминов, но не «снимок» предметной области.

Рассмотрим связи между классами, позволяющие дополнить карти­ну предметной области.

Ассоциации

Если классы концептуально взаимодействуют друг с другом, то такое взаимодействие называется ассоциацией. Исходная модель игры в баскетбол содержит несколько подобных примеров. Рассмотрим одну ассоциацию – между игроком и командой. Ее можно охарактеризовать фразой «игрок играет в ко­манде» и отобразить в виде соединяющей два класса линии, указав имя ассо­циации (играет в) прямо над этой линией. Для наглядности с помощью за­крашенного треугольника указывается направление взаимосвязи. На рис. 28 показано, как изобразить ассоциацию «Играет в» между игроком и командой.

Рис. 28. Ассоциация между классами

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

Рис. 29. Роль класса в ассоциации

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

Рис. 30. Две ассоциации между классами

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

Рис. 31. Ассоциации нескольких классов с одним

Ограничения ассоциаций

Иногда ассоциация между двумя классами должна удовлетворять некоторому пра­вилу. Это правило заключается в размещении ограничения возле линии ассоциации. Например, Банковский Служащий обслуживает клиентов по очереди. Этот факт отра­жается в модели с помощью фразы {по очереди} в фигурных скобках возле класса Клиент – для отражения ограничения (рис. 32).

Рис. 32. Ограничения на ассоциацию

Другой тип ограничения представляется отношением ИЛИ, которое обозначается с помощью пунктирной линии, соединяющей две линии ассоциаций с надписью {или}. Модель на рис. 33 показывает студента, выбирающего бюджетную или ком­мерческую форму обучения.

Рис. 33. Отношение ИЛИ между двумя ассоциациями

Связи

Ассоциация (как и класс) характеризуется наличием экземпляров. Если предста­вить себе конкретного игрока, играющего в конкретной команде, отношение «Играет в» называется связью , которую изображают в виде линии, соединяющей два объекта. Имя этой связи, как и имя объекта, подчеркивается (рис. 34).

Рис. 34. Связь как элемент ассоциации

Кратность

Ассоциация между объектами Игрок и Команда предполагает, что два класса находятся в отношении «один к одному». Здравый смысл подсказывает, что это не единственный ва­риант взаимосвязи. В баскетбольной команде пять человек, не считая запасных игроков. Ассоциация «Включает» должна учитывать этот факт. С другой стороны, игрок может играть только в одной команде, что должно учитываться в ассоциации «Играет в».

Рис. 35. Кратность связи

Приведенные отношения являются примерами разной кратности, кото­рая означает количество объектов одного класса, связанных с одним объек­том другого. Чтобы представить это количество на диаграмме, опреде­ленное число можно поместить над линией ассоциации возле соответст­вующего класса, как это сделано на рис. 35.

Рис. 36. Возможные значения кратности

В этом примере приведен только один из вариантов кратности. Возможны также и другие значения кратности. Один класс может быть связан с другим различными спосо­бами: «один к одному», «один ко многим», «один к нескольким», «один к ограниченному интервалу» (например, «один к 5..10»), «один к заданному количеству» (как в рассматриваемом примере) или «один к набору» (например, «один к 9 или 10»).

Для представления понятия «много» в UML используется символ звездочки (*). Логическое ИЛИ передается двумя обозначениями: с помощью двух точек (1. . *), что означает «один или более», или запятой (5,10), что означает «5 или 10». На рис. 36 показаны изображения возможных значений кратности.

Если класс А находится в отношении «один к 0 или 1» с классом Б, то по­следний называется необязательным для класса А.

Квалификатор ассоциации

Если кратность ассоциации описывается отношением «один ко многим», возника­ет проблема поиска. Если объект одного класса для выполнения отведенной ему роли в ассоциации должен выбрать конкретный объект другого класса, то он может сделать это на основе некоторого заданного атрибута. Этот атрибут обычно представляет со­бой идентификатор, а точнее, числовой идентификатор. Когда вы резервируете место в гостинице, вам присваивается номер заказа. Если нужно узнать о наличии зарезерви­рованного места, необходимо сообщить номер заказа.

В UML идентифицирующая информация называется квалификатором. Он обозначается небольшим прямоугольником, который прилегает к обозначе­нию класса, выполняющего поиск (рис. 37). Такое изображение позволяет эффективно свести кратность «один ко многим» к случаю «один к одному».

Рис. 37. Квалификатор ассоциации

Рефлексивные ассоциации

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

Рис. 38. Рефлексивная ассоциация

Наследование и обобщение

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

В рамках объектно-ориентированного подхода такое положение вещей называется наследованием. В UML для наследования используется термин обобщение. Один класс (дочерний или подкласс) может наследовать атри­буты и операции другого (родительского класса или суперкласса). Роди­тельский класс является более общим по отношению к дочернему.

В отношении обобщения можно сказать, что ребенок способен заменить ро­дителя. Другими словами, везде, где появляется родитель, может появить­ся и ребенок, а обратное утверждение неверно.

Иерархия наследования не ограничивается двумя уровнями: дочерний класс может вы­ступать в роли родительского класса для другого дочернего класса. Класс Млекопитающее является дочерним классом для класса Животное и родительским – для класса Лошадь.

В UML наследование отображается с помощью линии, которая соединяет родительский класс с дочерним. Конец линии, связанный с родительским классом, поме­чается не закрашенным треугольником, указывающим на родительский класс. Такая связь соответствует отношению – «является видом». Млекопитающее «является видом» жи­вотного, лошадь «является видом» млекопитающего. На рис. 39 представлены ранее описан­ная иерархия наследования и дополнительные классы. Обратите внимание на графи­ческое представление ситуации, когда родительский класс имеет несколько дочерних классов. Такая конструкция позволяет разгрузить диаграмму. Нужно отметить, что UML не за­прещает изображать все без исключения линии и треугольники и не требует указы­вать наследуемые атрибуты и операции в прямоугольниках подклассов, т.к. они уже представлены в обозначении суперкласса.

При моделировании наследования нужно убедиться, что дочерний класс удовлетворяет требованию «является видом» по отношению к родительско­му классу. Если связь классов описывается по-другому, нужно использовать другую ассоциацию.

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

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

Рис. 39. Иерархия наследования

Зависимости

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

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

Рис. 40. Изображение зависимости

Visual Studio 2010 Ultimate предоставляет достаточно удобные возможности для реверс-инжиниринга. С помощью средств Visual Studio мы можем на основе существующего кода построить UML-модель и понять как у нас, собственно, все работает, но при этом не прилагать гигантские усилия по созданию диаграмм вручную и поддержанию их в актуальном состоянии.

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

Недавно Microsoft выпустила дополнение под названием Microsoft Visual Studio 2010 Feature Pack 2. Данный инструмент дает нам прекрасную возможность синхронизировать изменения модели в код. Вкратце расскажу, как это можно использовать.

Для примера допустим, что у нас есть примитивный блог. Предметная область представлена двумя классами: Author и Article. Добавляем в солюшн новый Modeling Project. В нем создаем UML Class Diagram.

Воспользуемся возможностями Reverse Engineering. Перетаскиваем классы из Architecture Explorer-а на диаграмму. При этом на диаграмме сущность появляются вместе с атрибутами. Периодически между сущностями образуются связи, которые должны быть (и даже периодически правильно показывается тип связи), но в каких случаях – определить пока не получилось.

Как нам всем известно, стандарт UML 2.0 определяет четыре стандартных типа данных: Boolean, Integer, String и UnlimitedNatural. Остальные типы автоматически создаются в пакетах в соответствии с расположением в пространствах имен.NET.

Итак, попытаемся «починить» модель до адекватного состояния, а заодно, немного расширим ее. Для этого, создаем на диаграмме новый класс, в UML Model Explorer-е перетаскиваем его в нужный Package и выбираем стереотип C# Class (Microsoft добавила несколько специфичных для.NET стереотипов, которые используются при кодогенерации).

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

В Model Explorer выбираем сборку Domain, идем в Properties и в пункте Text Template Binding тыкаем кнопочку «…». Добавляем новый элемент, в поле Project Path указываем имя проекта, в который будет генерироваться код, в поле Target Directory указываем папочку относительно проекта (мы генерим в корень) и указываем адрес шаблона. По умолчанию они находятся в папке «C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\Extensions\Microsoft\Visualization and Modeling Feature Pack\2.0\Templates\Text». Можно задать несколько шаблонов на все случаи жизни. В нашем случае, выбираем ClassTemplate.t4.

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

И – вуаля! Новый класс добавлен в сборку, все изменения применены в соответствии с моделью.

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

Итак, M$ предлагает нам прекрасный инструмент, серьезно облегчающий жизнь архитекторам и разработчикам. К сожалению, этот очень необходимый пакет доступен только подписчикам MSDN, и компания почему-то не позволяет использовать его всем желающим легальным пользователям. И это при стоимости VS Ultimate порядка 300 тыс. рублей. Будем надеяться, что в ближайшем будущем такое положение вещей изменится.

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

Зачем она нужна?

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

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

Также стоит отметить, что есть несколько видов таких диаграмм.

Диаграмма классов

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

Стоит отметить тот факт, что есть несколько точек зрения на построение таких диаграмм в зависимости от того, каким образом они будут использоваться:

• Концептуальная. В данном случае диаграмма классов UML осуществляет описание модели определенной предметной области, и в ней предусматриваются только классы прикладных объектов.
• Специфическая. Диаграмма используется в процессе проектирования различных информационных систем.
• Реализационная. Диаграмма классов включает в себя всевозможные классы, которые непосредственно используются в программном коде.

Диаграмма компонентов

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

Диаграмма композитной/составной структуры

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

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

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

Диаграмма развертывания

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

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

Диаграмма объектов

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

Диаграмма пакетов

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

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

Диаграмма деятельности

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

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

Диаграмма автомата

Этот вид называется и несколько иначе - диаграмма состояний UML. Имеет представленный конечный автомат с простыми и композитными состояниями, а также переходами.

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

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

Диаграммы сценариев использования

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

Если диаграмма вариантов использования UML используется в процессе моделирования системы, то аналитик собирается:

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

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

Коммуникации

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

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

Данный тип отличается абсолютно свободным форматом упорядочивания нескольких объектов и связей точно так же, как это осуществляется в диаграмме объектов. Если есть необходимость в том, чтобы поддерживать порядок сообщений при этом свободном формате, осуществляется их хронологическая нумерация. Чтение данной диаграммы начинается с изначального сообщения 1.0, и впоследствии продолжается по тому направлению, по которому осуществляется передача сообщений от одного объекта к другому.

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

Диаграмма последовательности

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

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

Диаграмма сотрудничества

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

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

Диаграммы обзора взаимодействия

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

Стоит отметить тот факт, что данный формат объединяет в себе Collaboration и Sequence diagram, которые предоставляют возможность с разных точек зрения рассматривать взаимодействие между несколькими объектами в формируемой системе.

Диаграмма синхронизации

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

В чем преимущества?

Стоит отметить несколько преимуществ, которыми отличается UML диаграмма пользования и другие:

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

Недостатки

Несмотря на то что построение UML-диаграмм отличается массой своих плюсов, довольно часто их и критикуют за следующие недостатки:

• Избыточность. В преимущественном большинстве случаев критики говорят о том, что UML является слишком большим и сложным, и зачастую это неоправданно. В него входит достаточно много избыточных или же практически бесполезных конструкций и диаграмм, причем наиболее часто подобная критика идет в адрес второй версии, а не первой, потому что в более новых ревизиях присутствует большее количество компромиссов «разработанных комитетом».
• Различные неточности в семантике. По той причине, что UML определяется комбинацией себя, английского и OCL, у него отсутствует скованность, которая является присущей для языков, точно определенных техникой формального описания. В определенных ситуациях абстрактный синтаксис OCL, UML и английский начинают друг другу противоречить, в то время как в других случаях они являются неполными. Неточность описания самого языка одинаково отражается как на пользователях, так и на поставщиках инструментов, что в конечном итоге приводит к несовместимости инструментов из-за уникального способа трактовки различных спецификаций.
• Проблемы в процессе внедрения и изучения. Все указанные выше проблемы создают определенные сложности в процессе внедрения и изучения UML, и в особенности это касается тех случаев, когда руководство заставляет инженеров насильно его использовать, в то время как у них отсутствуют предварительные навыки.
• Код отражает код. Еще одним мнением является то, что важность имеют не красивые и привлекательные модели, а непосредственно рабочие системы, то есть код и есть проект. В соответствии с данным мнением есть потребность в том, чтобы разработать более эффективный способ написания программного обеспечения. UML принято ценить при подходах, компилирующих модели для регенерирования выполнимого или же исходного кода. Но на самом деле этого может быть недостаточно, потому что в данном языке отсутствуют свойства полноты по Тьюрингу, и каждый сгенерированный код в конечном итоге будет ограничиваться тем, что может предположить или же определить интерпретирующий UML инструмент.
• Рассогласование нагрузки. Данный термин происходит из теории системного анализа для определения неспособности входа определенной системы воспринять выход иной. Как в любых стандартных системах обозначений, UML может представлять одни системы в более эффективном и кратком виде по сравнению с другими. Таким образом, разработчик больше склоняется к тем решениям, которые являются более комфортными для переплетения всех сильных сторон UML, а также других языков программирования. Данная проблема является более очевидной в том случае, если язык разработки не соответствует основным принципам объектно-ориентированной ортодоксальной доктрины, то есть не старается работать в соответствии с принципами ООП.
• Пытается быть универсальным. UML представляет собой язык моделирования общего назначения, который старается обеспечить совместимость с любым существующим на сегодняшний день языком обработки. В контексте определенного проекта, для того, чтобы команда проектировщиков смогла добиться конечной цели, нужно выбирать применимые возможности этого языка. Помимо этого возможные пути ограничения сферы использования UML в какой-то определенной области проходят через формализм, который является не полностью сформулированным, а который сам представляет собой объект критики.

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

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

1.5.1. Диаграмма использования

Диаграмма использования (use case diagram) ‒ это наиболее общее представление функционального назначения системы.

Диаграмма использования призвана ответить на главный вопрос моделирования: что делает система во внешнем мире?

На диаграмме использования применяются два типа основных сущностей: варианты использования 1 и действующие лица 2 , между которыми устанавливаются следующие основные типы отношений:

• ассоциация между действующим лицом и вариантом использования 3 ;
• обобщение между действующими лицами 4 ;
• обобщение между вариантами использования 5 ;
• зависимости (различных типов) между вариантами использования 6 .

На диаграмме использования, как и на любой другой, могут присутствовать комментарии 7 . Более того, это настоятельно рекомендуется делать для улучшения читаемости диаграмм.

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

1.5.2. Диаграмма классов

Диаграмма классов (class diagram) ‒ основной способ описания структуры системы.

Это не удивительно, поскольку UML в первую очередь объектно-ориентированный язык, и классы являются основным (если не единственным) "строительным материалом".

На диаграмме классов применяется один основной тип сущностей: классы 1 (включая многочисленные частные случаи классов: интерфейсы, примитивные типы, классы-ассоциации и многие другие), между которыми устанавливаются следующие основные типы отношений:

• ассоциация между классами 2 (с множеством дополнительных подробностей);
• обобщение между классами 3 ;
• зависимости (различных типов) между классами 4 и между классами и интерфейсами.

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

1.5.3. Диаграмма автомата

Диаграмма автомата (state machine diagram) ‒ это один из способов детального описания поведения в UML на основе явного выделения состояний и описания переходов между состояниями.

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

На диаграмме автомата применяют один основной тип сущностей ‒ состояния 1 , и один тип отношений ‒ переходы 2 , но и для тех и для других определено множество разновидностей, специальных случаев и дополнительных обозначений. Перечислять их все во вступительном обзоре не имеет смысла.

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

1.5.4. Диаграмма деятельности

Диаграмма деятельности (activity diagram) ‒ способ описания поведения на основе указания потоков управления и потоков данных.

Диаграмма деятельности ‒ еще один способ описания поведения, который визуально напоминает старую добрую блок-схему алгоритма. Однако за счет модернизированных обозначений, согласованных с объектно-ориентированным подходом, а главное, за счет новой семантической составляющей (свободная интерпретация сетей Петри), диаграмма деятельности UML является мощным средством для описания поведения системы.

На диаграмме деятельности применяют один основной тип сущностей ‒ действие 1 , и один тип отношений ‒ переходы 2 (передачи управления и данных). Также используются такие конструкции как развилки, слияния, соединения, ветвления 3 , которые похожи на сущности, но таковыми на самом деле не являются, а представляют собой графический способ изображения некоторых частных случаев многоместных отношений. Семантика элементов диаграмм деятельности подробно разобрана в главе 4 . Основные элементы нотации, применяемые на диаграмме деятельности, показаны ниже.

1.5.5. Диаграмма последовательности

Диаграмма последовательности (sequence diagram) ‒ это способ описания поведения системы на основе указания последовательности передаваемых сообщений.

Фактически, диаграмма последовательности ‒ это запись протокола конкретного сеанса работы системы (или фрагмента такого протокола). В объектно-ориентированном программировании самым существенным во время выполнения является пересылка сообщений между взаимодействующими объектами. Именно последовательность посылок сообщений отображается на данной диаграмме, отсюда и название.

На диаграмме последовательности применяют один основной тип сущностей ‒ экземпляры взаимодействующих классификаторов 1 (в основном классов, компонентов и действующих лиц), и один тип отношений ‒ связи 2 , по которым происходит обмен сообщениями 3 . Предусмотрено несколько способов посылки сообщений, которые в графической нотации различаются видом стрелки, соответствующей отношению.

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

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

На следующем рисунке показаны основные элементы нотации, применяемые на диаграмме последовательности. Для обозначения самих взаимодействующих объектов применяется стандартная нотация ‒ прямоугольник с именем экземпляра классификатора. Пунктирная линия, выходящая из него, называется линией жизни (lifeline) 4 . Это не обозначение отношения в модели, а графический комментарий, призванный направить взгляд читателя диаграммы в правильном направлении. Фигуры в виде узких полосок, наложенных на линию жизни, также не являются изображениями моделируемых сущностей. Это графический комментарий, показывающий отрезки времени, в течении которых объект владеет потоком управления (execution occurrence) 5 или другими словами имеет место активация (activation) объекта. Составные шаги взаимодействия(combined fragment) 6 позволяют на диаграмме последовательности, отражать и алгоритмические аспекты протокола взаимодействия. Прочие детали нотации диаграммы последовательностей см. в главе 4 .

1.5.6. Диаграмма коммуникации

Диаграмма коммуникации (communication diagram) ‒ способ описания поведения, семантически эквивалентный диаграмме последовательности.

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

Таким образом, на диаграмме коммуникации также как и на диаграмме последовательности применяют один основной тип сущностей ‒ экземпляры взаимодействующих классификаторов 1 и один тип отношений ‒ связи 2 . Однако здесь акцент делается не на времени, а на структуре связей между конкретными экземплярами.

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

1.5.7. Диаграмма компонентов

Диаграмма компонентов (component diagram) ‒ показывает взаимосвязи между модулями (логическими или физическими), из которых состоит моделируемая система.

Основной тип сущностей на диаграмме компонентов ‒ это сами компоненты 1 , а также интерфейсы 2 , посредством которых указывается взаимосвязь между компонентами. На диаграмме компонентов применяются следующие отношения:

• реализации между компонентами и интерфейсами (компонент реализует интерфейс);
• зависимости между компонентами и интерфейсами (компонент использует интерфейс) 3 .

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

1.5.8. Диаграмма размещения

Диаграмма размещения (deployment diagram) наряду с отображением состава и связей элементов системы показывает, как они физически размещены на вычислительных ресурсах во время выполнения.

Таким образом, на диаграмме размещения, по сравнению с диаграммой компонентов, добавляется два типа сущностей: артефакт 1 , который является реализацией компонента 2 и узел 3 (может быть как классификатор, описывающий тип узла, так и конкретный экземпляр), а также отношение ассоциации между узлами 4 , показывающее, что узлы физически связаны во время выполнения.

На рисунке показаны основные элементы нотации, применяемые на диаграмме размещения. Для того чтобы показать, что одна сущность является частью другой, применяется либо отношение зависимости «deploy» 5 , либо фигура одной сущности помещается внутрь фигуры другой сущности 6 . Детальное описание диаграммы приведено в главе 3 .