Введение. Унифицированный язык моделирования (UML - Unified Modeling Language) является стандартным инструментом для создания документированных каркасов («чертежей»)

Унифицированный язык моделирования (UML - Unified Modeling Language) является стандартным инструментом для создания документированных каркасов («чертежей») программного обеспечения. С помощью UML можно визуализировать, специфицировать, конструировать и документировать процесс разработки программных систем.

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

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

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

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

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

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

UML – это язык визуализации

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

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

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

UML – это язык специфицирования

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

UML – это язык конструирования

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

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

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

UML – это язык документирования

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

· требования к системе;

· архитектуру;

· проект;

· исходный код;

· проектные планы и сметы;

· тесты;

· прототипы;

· версии и другие.

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

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

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

· информационные системы масштаба предприятия;

· банковские и финансовые услуги;

· телекоммуникации;

· транспорт;

· оборонная промышленность, авиация, космонавтика;

· торговые системы;

· медицинская электроника;

· наука;

· распределенные Web-системы.

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

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

Словарь UML включает три вида основных конструкций:

· сущности – абстракции, являющиеся основными элементами модели;

· отношения – связи между сущностями;

· диаграммы, группирующие представляющие интерес множества сущностей и отношений.

Теперь обо всем более подробно.

Сущности UML

В UML имеется четыре типа сущностей:

· структурные;

· поведенческие;

· группирующие;

· аннотационные.

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

Класс (class) – это описание совокупности объектов с общими атрибутами, операциями отношениями и семантикой. Графически класс изображается в виде прямоугольника, в котором записаны его имя, атрибуты и операции, например как это показано на рис.

Рис. Пиктограмма класса.

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

Рис. Пиктограмма интерфейса.

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

Рис. Пиктограмма кооперации.

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

Рис. Пиктограмма прецедента.

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

Рис. Пиктограмма активного класса.

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

Рис. Пиктограмма компонента.

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

Рис. Пиктограмма узла.

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

Теперь определим другие типы сущностей, о которых мы не упоминали раньше. Поведенческие сущности (behavioral things) являются динамическими составляющими модели UML. Это глаголы языка, они описывают поведение модели во времени и в пространстве. Существует всего два основных типа поведенческих сущностей.

Взаимодействие (interaction) – это поведение, суть которого заключается в обмене сообщениями (messages) между объектами в рамках конкретного контекста для достижения определенной цели. С помощью взаимодействия можно описать как отдельную операцию, так и поведение совокупности объектов. Взаимодействие предполагает ряд других элементов, таких как сообщения, последовательности действий (поведение, инициированное сообщениями) и связи (между объектами). Графически сообщение изображается в виде стрелки. Над которой почти всегда пишется имя соответствующей операции, как показано на рис..

Рис. Пиктограмма сообщения.

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

Рис. Пиктограмма состояния.

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

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

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

Рис. Пиктограмма пакета.

Аннотационные сущности – пояснительные части модели UML. Это комментарии для дополнительного описания, разъяснения или замечания к любому элементу модели. Имеется только один базовый тип аннотационных элементов – примечание. Примечание (note) – это просто символ для изображения комментариев или ограничений, присоединенный к элементу или группе элементов. Графически примечание изображается в виде прямоугольника с загнутым краем, содержащим текстовый или графический комментарий, как показано на рис..

Рис. Пиктограмма примечания.

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

Отношения UML

В языке UML определены четыре типа отношений:

· зависимость;

· ассоциация;

· обобщение;

· реализация.

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

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

Рис. Пиктограмма зависимости.

Ассоциация (association) – структурное отношение, описывающее совокупность связей, где под связью понимается некоторая смысловая связь между объектами. Разновидностью ассоциации является агрегирование (aggregation) – так называется структурное отношение между целым и его частями. Графически ассоциация изображается в виде линии (иногда завершающейся стрелкой или содержащей метку), рядом с которой могут присутствовать дополнительные обозначения, например кратность и имена ролей. На рис. Показан пример отношений этого вида.

Рис. Пиктограмма ассоциации.

Обобщение (generalization) – это отношение «специализация/обобщение», при котором объект специализированного элемента (проще говоря, потомок) может быть подставлен вместо объекта обобщенного элемента (родителя, предка). Как и положено в объектно-ориентированном программировании, потомок (child) наследует структуру и поведение своего предка (parent). Графически отношение обобщения изображается в виде линии с незакрашенной стрелкой, указывающей на предка. Как показано на рис..

Рис. Пиктограмма обобщения.

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

Рис. Пиктограмма реализации.

Мы описали четыре элемента UML, которые являются основными типами отношений в моделях UML. Существую также их варианты, например уточнение (refinement), трассировка (trace), включение и расширение для зависимостей.

Диаграммы UML

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

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

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

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

Диаграммы взаимодействия, на которых представлены связи между объектами, показаны, в частности, сообщения, которыми объекты могут обмениваться. Обычно рассматриваются два частных случая это вида диаграмм: диаграммы последовательностей (sequence diagram), которые отражают временную упорядоченность сообщений, и диаграммы кооперации (collaboration diagram), на которых показана структурная организация обменивающихся сообщениями объектов. Эти виды диаграмм являются изоморфными, то есть свободно могут быть трансформированы друг в друга.

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

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

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

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

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

Правила языка UML

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

· имена, которые можно давать сущностям, отношениям и диаграммам;

· области действия – контексты, в которых имя имеет некоторое значение;

· видимость, когда имена видимы и могут использоваться другими элементами;

· целостность, как элементы должны правильно и согласованно соотноситься друг с другом;

· выполнение, что означает выполнить или имитировать некоторую динамическую модель.

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

· содержат скрытые элементы (ряд элементов не показывают, чтобы упростить восприятие);

· неполные (отдельные элементы пропущены);

· несогласованные (целостность модели не гарантируется).

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

Общие механизмы языка UML

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

· спецификации (specifications);

· дополнения (adornments);

· принятые деления (common divisions);

· механизмы расширения (extensibility mechanisms).

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

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

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

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

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

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

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

· стереотипы (stereotype), которые расширяют словарь UML, позволяя на основе существующих блоков языка создавать новые, специфичные для решения конкретной проблемы.;

· помеченные значения (tagged value), которые расширяют свойства основных конструкций UML, позволяя включать новую информацию в спецификацию элемента;

· ограничения (constraints), которые расширяют семантику конструкций UML, позволяя создавать новые и отменять существующие правила.

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

Тема лекции №8:«Системы и модели»

ТЕКСТ ЛЕКЦИИ

Дата добавления: 2014-01-07