2. Язык UML. Руководство пользователя. Буч_ Рамбо_ Якобсон (2-е издание) (2006) (1185732), страница 10
Текст из файла (страница 10)
Большинство элементов UML имеют уникальную и прямую графическую нотацию, которая даетвизуальное представление наиболее важных аспектов элемента.Например, обозначение класса разработано так, что его легко рисовать, потому что класс – это часто употребляемый элемент примоделировании объектно-ориентированных систем. Нотация класса также показывает его наиболее важные аспекты: имя, атрибутыи операции.Спецификация класса может содержать и другие детали, такиекак видимость атрибутов и операций. Многие из этих деталей могут изображаться в виде графических или текстовых дополненийк базовому прямоугольнику, представляющему класс. Например,рис.
2.18 демонстрирует класс, в обозначение которого включеныдополнения, указывающие на то, что этот класс абстрактный, имеетдве открытые, одну защищенную и одну закрытую операции.Концептуальная модель UMLОбъекты обсуждаютсяв главе 13.45Во-первых, существует разделение на классы и объекты. Класспредставляет собой абстракцию, а объект – конкретную ее материализацию. В UML вы можете моделировать как классы, так и объекты (см. рис.
2.19). В графическом представлении объекта UMLиспользует тот же символ, что и для его класса, но с подчеркиванием имени объекта.Рис. 2.19. Классы и объектыНа рис. 2.19 показан один класс Customer (Покупатель) вместе с тремя объектами: Jan (Джен), который помечен, как объект,явно являющийся объектом класса Customer, :Customer (анонимныйобъект класса Customer) и Elyse (Элиза), спецификация которого относит его к классу Customer, хотя это не отображено явно.Почти каждый строительный блок UML характеризуется подобной дихотомией «класс/объект».
Например, существуют варианты использования и экземпляры вариантов использования, компоненты и экземпляры компонентов, узлы и экземпляры узлов и т.д.ИнтерфейсыВо-вторых, существует разделение интерфейса и реализации.обсуждают- Интерфейс определяет соглашение, а реализация представляет егося в главе 11. конкретное воплощение и обязуется точно следовать полной семантике интерфейса. В UML вы можете моделировать как интерфейсы,так и их реализации (см.
рис. 2.20).IDictionaryРис. 2.18. ДополненияКаждый элемент в нотации UML начинается с базового символа, к которому могут быть добавлены разнообразные специфичныедля него дополнения.Принятые разделения (common divisions). При моделированииобъектно-ориентированных систем представление о предметной области может быть разделено несколькими способами.Рис. 2.20. Интерфейсы и реализацииНа этом рисунке присутствует один компонент по имени SpellingWizard.dll (МастерПроверкиОрфографии.dll), который реализует дваинтерфейса – IUnknown (IНеизвестноеСлово) и Ispelling (IНаписание). Он также запрашивает интерфейс Idictionary (IСловарь), который должен быть предоставлен другим компонентом.Введение в UML46АрхитектураПочти каждый строительный блок UML обладает той же дихотомией «интерфейс/реализация».
Например, варианты использования реализуются кооперациями, а операции – методами.В-третьих, существует разделение на тип и роль. Тип декларируеткласс сущности, например объект, атрибут или параметр. Роль описывает значение сущности внутри контекста, такого как класс, компонентили кооперация. Любая сущность, формирующая часть структурыдругой сущности (к примеру, атрибут), обладает обеими характеристиками.
Она наследует некоторый смысл от типа, которому принадлежит, а другой смысл – от его роли в данном контексте (рис. 2.21).47стереотипа. Например, если вы работаете над «коробочным» продуктом и выпускаете много версий, вам часто приходится отслеживать версию и автора определенных важных абстракций. Ни версия,ни автор не являются примитивами UML. Они могут быть добавлены к любому строительному блоку, такому как класс, за счет введения в него новых помеченных значений. Так, например, на рис.
2.19класс EventQueue расширяется явной пометкой его версии и автора.Ограничения расширяют семантику строительного блока UML,позволяя добавлять новые правила или модифицировать существующие. Предположим, вам понадобилось ограничить класс EventQueueтак, чтобы все события добавлялись в очередь по порядку. Как видно на рис. 2.22, для этого можно добавить ограничение, явно задающее такое правило для операции add.TicketOrdercustomer:Person«authored»EventQueue«exception»Overflow«authored»version = 3.2author = egbРис. 2.21.
Часть с ролью и типомМеханизмы расширения (extensibility mechanisms). UML – этостандартный язык разработки «чертежей» программного обеспечения, но ни один замкнутый язык не может быть настолько выразительным, чтобы охватить все нюансы всех возможных моделей вовсех областях применения в любое время.
По этой причине UML является открытым языком, который дает возможность вводить контролируемые расширения. Механизмы расширения UML включают: стереотипы; помеченные значения; ограничения.Стереотип (stereotype) расширяет словарь UML, позволяя создавать новые виды строительных блоков, которые наследуются отсуществующих, но при этом специфичны для решения конкретнойпроблемы. Например, если вы работаете с языком программирования, таким как Java или C++, вам часто приходится моделироватьисключения (exceptions).
В этих языках исключения – это обычныеклассы, хотя и трактуемые особым образом. Обычно требуется, чтобы исключения можно было возбуждать и перехватывать, и ничегоболее. Вы можете пометить исключения соответствующим стереотипом, тем самым сделав их подобными базовым строительнымблокам. На рис. 2.19 это показано на примере класса OverFlow.Помеченное значение (tagged value) расширяет свойства стереотипа UML, позволяя включать новую информацию в спецификациюРис. 2.22. Механизмы расширенияВсе эти три механизма расширения языка совместно позволяютмодифицировать UML в соответствии с требованиями вашего проекта. Кроме того, они дают возможность адаптировать UML к новымпрограммным технологиям, например к вероятному появлению более мощных языков распределенного программирования.
Вы можетедобавлять новые строительные блоки, модифицировать спецификацию существующих и даже изменять их семантику. Естественно, приэтом нужно соблюдать меру, чтобы подобные расширения не повредили главной цели UML – возможности обмена информацией.АрхитектураНеобходимость представлениясложныхсистемс разныхточек зренияобсуждается в главе 1.Визуализация, специфицирование, конструирование и документирование программных систем требуют их представления с различныхточек зрения.
Разные заинтересованные лица – конечные пользователи, аналитики, разработчики, системные интеграторы, тестировщики, технические писатели и менеджеры проекта – имеют различноепредставление о проекте, и каждый из них видит систему по-разномув разные моменты его жизненного цикла. Системная архитектура является, пожалуй, наиболее важным продуктом, который может бытьиспользован для управления всеми этими разнообразными точкамиВведение в UML48зрения и тем самым управляет итеративным и пошаговым процессом разработки системы на протяжении всего ее жизненного цикла.Архитектура – это набор существенных решений относительно: организации программной системы; выбора структурных элементов, составляющих систему, и ихинтерфейсов; поведения этих элементов, определенного в их кооперациях; объединения этих структурных и поведенческих элементовв более крупные подсистемы; архитектурного стиля, определяющего организацию системы: статические и динамические элементы и их интерфейсы,кооперацию и композицию.Моделирование архитектурысистем обсуждаетсяв главе 32.Архитектура программного обеспечения касается не только егоструктуры и поведения, но также пользовательских свойств, функциональности, производительности, гибкости, возможности повторного использования, понятности, экономических и технологических ограничений и компромиссов, а также эстетических вопросов.Как показано на рис.
2.23, архитектура программной системы может быть наилучшим образом описана с помощью пяти взаимосвязанных представлений. Каждое представление – проекция организациии структуры системы, сосредоточенная на определенном ее аспекте.вид с точкизрения вариантовиспользованияРис. 2.23.
Моделирование системной архитектурыПредставление вариантов использования системы охватываетварианты использования, описывающие поведение системы с точки зрения конечных пользователей, аналитиков и тестировщиков.Их взгляд в действительности специфицирует не истинную организацию программной системы, а лишь некие движущие силы,формирующие системную архитектуру.
В языке UML статическиеаспекты этого представления передаются диаграммами вариантовиспользования, а динамические его аспекты – диаграммами взаимодействий, состояний и деятельности.Архитектура49Представление системы с точки зрения дизайна охватываетклассы, интерфейсы и кооперации, формирующие словарь проблемы и ее решение. Это представление в основном поддерживает функциональные требования к системе, то есть сервис, которыйона должна предоставлять конечным пользователям.
Статическиеаспекты этого представления в UML сосредоточены в диаграммахклассов и объектов, а динамические передаются диаграммами взаимодействий, состояний и деятельности. Диаграмма внутреннейструктуры класса, в частности, также полезна.Представление взаимодействия системы показывает поток управления, проходящий через разные ее части, включая возможные механизмы параллелизма и синхронизации. Это представление касаетсяпроизводительности, масштабируемости и пропускной способностисистемы. Статические и динамические аспекты этого представленияв UML представлены в некоторых видах диаграмм, используемыхв представлении дизайна, но сфокусированы на активных классах,управляющих системой, и передаваемых между ними сообщениях.Представление реализации системы охватывает артефакты,используемые для сборки и физической реализации системы.
Этопредставление в первую очередь относится к управлению конфигурацией версий системы, состоящей из независимых (в определенной степени) файлов и компонентов, которые могут быть собраныразличными способами для формирования работающей системы.Оно также связано с отображением из логических классов и компонентов в физические артефакты. В UML статические аспекты этогопредставления отражены в диаграммах артефактов, динамическиеаспекты – в диаграммах взаимодействия, состояний и деятельности.Представление развертывания системы охватывает узлы, образующие топологию оборудования, на котором работает система.Это представление в основном связано с поставкой, распределением и установкой частей, составляющих физическую систему.
Егостатические аспекты в UML описываются диаграммами размещения, а динамические – диаграммами взаимодействий, состоянийи деятельности.Каждое из этих пяти представлений может быть достаточнымдля различных заинтересованных лиц, имеющих отношение к разработке и эксплуатации системы, позволяя им сосредоточиться толькона тех аспектах архитектуры, которые непосредственно их касаются.Однако все эти представления также взаимодействуют друг с другом.Узлы из представления размещения содержат компоненты из представления реализации, которые, в свою очередь, представляютсобой физическую реализацию классов, интерфейсов, кооперацийи активных классов из представлений дизайна и взаимодействия.UML позволяет выразить каждое из пяти представлений.Введение в UML50Жизненный цикл разработки51Жизненный цикл разработкипрограммного обеспеченияУнифицированныйпроцессразработкипрограммного обеспечения (RationalUnifiedProcess)рассматриваетсяв приложении 2.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
