UML2 и унифицированный процесс. Джим арлоуайла нейштадтпрактический объектно ориентированныйанализ и проектированиеu
 Скачать 6.08 Mb.
|
|
Механизмы расширения UML Ограничения Расширяют семантику элемента, обеспечивая возможность добавлять новые правила. Стереотипы Обеспечивают возможность определять новые элементы мо дели UML на основании существующих: мы определяем се мантику стереотипа самостоятельно. Стереотипы добавляют новый элемент в метамодель UML. Помеченные значения Предоставляют способ расширения спецификации элемен та, обеспечивая возможность добавлять в него новую специ альную информацию. 1.9. Общие механизмы UML 41 UML определяет Объектный язык ограничений (Object Constraint Lan guage, OCL) как стандартное расширение. Введение в OCL изложено в главе 25. 1.9.4.2. Стереотипы Стереотипы позволяют определять новые элементы модели. В книге «The UML Reference Manual» [Rumbaugh 1] утверждается: «Стереотип представляет разновидность существующего элемента мо дели, имеющего ту же форму (например, атрибуты и отношения), но другое назначение». Стереотипы позволяют создавать новые элементы модели на основании существующих . Для этого к имени нового элемента добавляется имя стереотипа во французских кавычках («…»). Число стереотипов каждо го элемента модели может изменяться от нуля до некоторого значения. Каждый стереотип может определять ряд помеченных значений и ог раничений, которые применяются к элементу, помеченному стереоти пом. Также со стереотипом можно ассоциировать пиктограмму, цвет или текстуру. Обычно следует избегать применения цвета или тексту ры в моделях UML, поскольку у некоторых читателей (например, дальтоников) могут возникнуть сложности с восприятием диаграмм. Кроме того, зачастую диаграммы распечатываются в черно белом ва рианте. Обычно со стереотипом ассоциируют новую пиктограмму. Это позволяет контролировать расширение системы графических изобра жений UML. Поскольку стереотипы вводят новые элементы модели с иным назна чением, где то должна быть определена семантика этих элементов. Как это сделать? Если инструмент моделирования не предоставляет встроенную поддержку документирования стереотипов, большинство разработчиков моделей просто помещают примечание в модель или вставляют ссылку на внешний документ, в котором описываются сте реотипы. В настоящее время поддержка стереотипов инструментами моделирования не выполняется безоговорочно – большинство инстру ментальных средств поддерживают стереотипы в той или иной степе ни, но не все из них предоставляют возможность записи семантики. С помощью элемента класс (глава 7) со специальным предопределен ным UML стереотипом « стереотип» можно самостоятельно моделиро вать стереотипы. При этом создается метамодель вашей системы сте реотипов. Это метамодель, потому что она является моделью элемен тов модели и находится на совершенно другом уровне абстракции, чем обычная UML система или бизнес модели. Метамодель ни в коем слу чае нельзя объединять с обычными моделями. Она всегда должна на ходиться в отдельной модели. Создавать новую модель, предназначен ную исключительно для стереотипов, имеет смысл, только если стерео 42 Глава 1. Что такое UML? типов много. Такая ситуация встречается довольно редко, поэтому большинство разработчиков моделей документируют стереотипы в при мечаниях или внешних документах. Стереотипы могут отображаться по разному, но чаще всего разработ чики моделей применяют просто имя стереотипа, заключенное в ка вычки «», или пиктограмму. Другие варианты отображения стереоти пов используются реже; кроме того, инструмент моделирования часто ограничивает возможности разработчика. Примеры приведены на рис. 1.12 (звездочки не являются частью UML синтаксиса; они просто указывают на наиболее удачные варианты представления). Обратите внимание, что помечать стереотипом можно и отношения. В книге вы найдете множество таких примеров. 1.9.4.3. Помеченные значения Помеченные значения позволяют добавлять собственные свойства к эле ментам модели. В UML свойство – это любое значение, прикрепленное к элементу мо дели. Большинство элементов имеют большое число предопределен ных свойств. Некоторые из них могут отображаться на диаграммах, другие являются частью семантического заднего плана модели. С помощью помеченных значений UML позволяет добавлять в элемен ты модели собственные свойства. Идея помеченных значений предель но проста: помеченное значение – это ключевое слово, к которому мо жет быть прикреплено значение. Помеченные значения имеют сле дующий синтаксис: {метка1 = значение1, метка2 = значение2, …, меткаN = значениеN}. Разделенный запятыми список пар метка – значение, напи санных через знак равенства, называется списком меток. Его заклю чают в фигурные скобки. Ticket «control» JobManager Scheduler «call» Ticket «entity» Ticket предпочтительный пиктограмма стереотип «entity» Ticket предпочтительный Рис. 1.12. Варианты отображения стереотипов 1.9. Общие механизмы UML 43 Некоторые метки являются просто дополнительной информацией об элементе модели, например {author = Jim Arlow} ({автор = Джим Арлоу}). Однако некоторые метки представляют свойства новых элементов мо дели, определенных стереотипом. Не следует применять такие метки непосредственно к элементам модели; лучше ассоциировать их со сте реотипом. Тогда при применении стереотипа к элементу модели, эле мент также получает метки, ассоциированные с этим стереотипом. 1.9.4.4. Профили UML Профиль UML определяет набор стереотипов, меток и ограничений, ко торые настраивают UML в соответствии с определенной целью. Профиль UML – это набор стереотипов, помеченных значений и огра ничений. Профиль UML используется, чтобы настроить UML для оп ределенной цели. Профили UML позволяют настраивать UML так, чтобы его можно бы ло эффективно использовать в различных областях. Профили обеспе чивают возможность согласованно и правильно применять стереоти пы, метки и ограничения. Например, если UML используется для мо делирования .NET приложения, можно воспользоваться профилем UML для .NET, который приведен в табл. 1.4. Таблица 1.4 Этот профиль – один из примеров UML профилей спецификации UML 2.0 [UML2S]. Он определяет новые элементы модели UML, адап тированные для моделирования .NET приложений. Каждый стереотип профиля расширяет один из элементов метамодели UML (например, Класс или Ассоциацию) для создания нового специаль ного элемента. Стереотип может определять новые метки и ограниче ния, которые не являлись частью исходного элемента. Стереотип Метки Ограничения Расширяет Семантика «NETCompo nent» Нет Нет Компонент Представляет компонент в .NET Framework. «NETPro perty» Нет Нет Свойство Представляет свойство компонента. «NETAssemb ly» Нет Нет Пакет Упаковка компонентов вре мени выполнения .NET. «MSI» Нет Нет Артефакт Файл автоматической уста новки компонента. «DLL» Нет Нет Артефакт Переносимый исполняе мый файл типа DLL. «EXE» Нет Нет Артефакт Переносимый исполняе мый файл типа EXE. 44 Глава 1. Что такое UML? 1.10. Архитектура Книга «UML Reference Manual» [Rumbaugh 1] определяет архитектуру системы как «Организационную структуру системы, включая ее раз биение на части, их связность, взаимодействия, механизмы и направ ляющие принципы, передающие конструкцию системы». IEEE опре деляет архитектуру системы как «высокоуровневое представление системы в ее окружении». Стратегические аспекты системы можно описать «4+1 представления ми» архитектуры: логическое представление, представление процессов, представление реализации, представление развертывания и представ ление прецедентов. Архитектура описывает фундаментальные аспекты высокоуровневой структуры системы. Существует множество способов описания архи тектуры, но самым распространенным является «4+1 представление», данное Филиппом Крухтеном (Philippe Kruchten) [Kruchten 2]. Важ нейшие аспекты архитектуры системы описываются четырьмя разны ми представлениями системы: логическим представлением, представ лением процесса, представлением реализации и представлением раз вертывания. Все они интегрируются в пятое представление – пред ставление прецедентов. Каждое из этих представлений раскрывает разные аспекты архитектуры программного обеспечения, как показа но на рис. 1.13. Давайте рассмотрим каждое из представлений по очереди. • Логическое представление описывает словарь предметной области как набор классов и объектов. Основное внимание уделяется ото бражению того, как объекты и классы, образующие систему, реа лизуют требуемое поведение системы. • Представление процессов моделирует исполняемые потоки и процес сы системы как активные классы (классы, имеющие собственный поток управления). В действительности это процессориентированная версия логического представления, все их артефакты аналогичны. • Представление реализации моделирует файлы и компоненты, обра зующие физическую базу из кода для системы. Это представление также иллюстрирует зависимости между компонентами и управля ет конфигурированием наборов компонентов для определения вер сии системы. • Представление развертывания моделирует физическое развертыва ние артефактов на физические вычислительные узлы, такие как компьютеры и периферийное оборудование. Оно обеспечивает воз можность моделирования распределения артефактов между узлами распределенной системы. 1.10. Архитектура 45 • Представление прецедентов описывает основные требования, предъ являемые к системе, как набор прецедентов (глава 4). Эти прецеден ты обеспечивают базу для создания остальных представлений. Как будет видно из дальнейшего изложения, UML предоставляет от личную поддержку каждого из 4+1 представлений, а UP является управляемым требованиями подходом, для которого замечательно подходит модель 4+1. После создания 4+1 представлений необходимо с помощью UML моде лей проанализировать все ключевые аспекты архитектуры системы. Если используется итеративный жизненный цикл UP, архитектура 4+1 создается не за один проход, а развивается с течением времени. Процесс UML моделирования с использованием UP – это процесс по степенного уточнения, приводящий к архитектуре 4+1, которая фик сирует как раз такой объем информации о системе, который обеспечи вает возможность ее построения. логическое представление представление реализации представление процессов представление развертывания диаграммы: классов составных структур объектов пакетов состояний диаграммы: классов составных структур объектов диаграммы: компонентов диаграммы: развертывания описывает: сборка системы управление конфигурацией описывает: словарь функциональность описывает: производительность масштабируемость пропускную способность описывает: топология системы распространение поставка установка поведение Аналитик Тестер Конечный пользователь Системотехник Проектировщик системы Программист представление прецедентов диаграммы: прецедентов взаимодействий Рис. 1.13. Архитектура системы. Адаптировано с рис. 5.1 [Kruchten 1] с разрешения издательства Addison Wesley 46 Глава 1. Что такое UML? 1.11. Что мы узнали Эта глава содержит введение в историю, структуру, концепции и ос новные характеристики UML. Вы узнали следующее. • Унифицированный язык моделирования (UML) – это открытый, расширяемый, принятый в качестве стандарта язык визуального моделирования, утвержденный консорциумом OMG. • UML не методология. • Унифицированный процесс (UP) или его разновидность – это тип методологии, наилучшим образом дополняющий UML. • Объектное моделирование рассматривает мир как систему взаимо действующих объектов. Объекты содержат информацию и могут выполнять функции. UML модели имеют: • статическую структуру – какие типы и объекты важны и как они взаимосвязаны; • динамическое поведение – как объекты взаимодействуют для осуществления функций системы. • UML образован тремя строительными блоками: • сущности: • структурные сущности – существительные UML модели; • поведенческие сущности – глаголы UML модели; • существует только одна группирующая сущность – пакет, ко торый используется для группировки семантически взаимо связанных сущностей; • существует только одна аннотирующая сущность – примеча ние (аналог – стикер); • отношения объединяют сущности; • диаграммы показывают интересные представления модели. • UML имеет четыре общих механизма: • спецификации – текстовые описания возможностей и семанти ки элементов модели, суть модели; • дополнения – элементы информации, обозначенные на элементе модели на диаграмме для пояснения какой либо особенности; • принятые деления: • классификатор и экземпляр: • классификатор – абстрактное понятие типа сущности, на пример банковский счет; • экземпляр – конкретный экземпляр типа сущности, на пример мой банковский счет; • интерфейс и реализация: • интерфейс – контракт, определяющий поведение сущности; 1.11. Что мы узнали 47 • реализация – конкретные детали того, как работает сущ ность; • механизмы расширения: • ограничения позволяют добавлять новые правила для элементов модели; • стереотипы вводят новые элементы модели, базирующиеся на уже существующих; • помеченные значения позволяют добавлять новые свойства эле ментам модели; помеченное значение – это ключевое слово с ас социированным значением; • профиль UML – набор ограничений, стереотипов и помеченных значений, позволяющий настроить UML для определенной цели. • UML основывается на 4+1 представлениях архитектуры системы: • логическое представление – функциональность системы и сло варь; • представление процессов – производительность, масштабируе мость и пропускная способность системы; • представление реализации – сборка системы и управление кон фигурацией; • представление развертывания – топология, распространение, поставка и установка системы; • все представления объединены представлением прецедентов, ко торое описывает требования заинтересованных сторон. 2 Что такое Унифицированный процесс? 2.1. План главы В этой главе представлен краткий обзор Унифицированного процесса (Unified Process, UP). Новички должны начать с изучения истории UP. Если вам это уже известно, можно сразу перейти к разделу 2.4, где обсуждаются UP и RUP (Rational Unified Process, Унифицированный процесс компании Rational), или к разделу 2.5, в котором рассматри вается возможность использования UP в вашем собственном проекте. В этой книге нас интересует UP как каркас процесса, в рамках которо го могут быть представлены технические приемы ОО анализа и разра ботки. Всестороннее обсуждение UP можно найти в книге [Jacobson 1], а замечательное описание RUP – в [Kroll 1], [Kruchten 2], а также в кни гах [Ambler 1], [Ambler 2] и [Ambler 3]. 2.2. Что такое UP? Процесс производства программного обеспечения (Software Engineer ing Process, SEP), также известный как процесс разработки программ ного обеспечения (Software Development Process), определяет кто, что , когда и как в разработке ПО . Как показано на рис. 2.2, SEP – это процесс, в котором требования пользователя превращаются в ПО. Унифицированный процесс разработки программного обеспечения (Unified Software Development Process, USDP) – это SEP от авторов UML. Обычно его называют Унифицированным процессом или UP [Jacobson 1]. В книге используется термин UP. Проект UML должен был предоставить и визуальный язык, и процесс производства программного обеспечения. То, что сегодня называют UML, – это наглядная часть проекта, а UP – это процесс. Следует заме тить, что UML был стандартизован OMG, UP – нет. Поэтому до сих пор не существует стандартного SEP для UML. 2.2. Что такое UP? 49 изучите процессы разработки ПО познакомьтесь с UP и RUP изучите историю UP познакомьтесь с итеративной разработкой 2.2. Что такое UP? 2.3. Рождение UP 2.4. UP и Унифицированный процесс компании Rational 2.5. Настройка UP для вашего проекта 2.6. Аксиомы UP 2.7. UP – итеративный и инкрементный процесс 2.7.1. Рабочие потоки итерации 2.7.2. Базовые версии и инкременты 2.8. Структура UP 2.9. Фазы UP 2.9.7. Построение – цели 2.9.8. Построение – на что обращено внимание 2.9.9. Построение – контрольная точка: Базовая функциональность 2.9.1. Начало – цели 2.9.2. Начало – на что обращено внимание 2.9.3. Начало – контрольная точка: Цели жизненного цикла 2.9.4. Уточнение – цели 2.9.5. Уточнение – на что обращено внимание 2.9.6. Уточнение – контрольная точка: Архитектура жизненного цикла 2.9.10. Внедрение – цели 2.9.11. Внедрение – на что обращено внимание 2.9.12. Внедрение – контрольная точка: Выпуск продукта 2.10. Что мы узнали else else else else Ри с. 2 .1. Пл ан гл ав ы 50 Глава 2. Что такое Унифицированный процесс? Процесс производства программного обеспечения описывает то, как требования превращаются в программное обеспечение. UP основывается на исследованиях процессов, проводимых в Ericsson (метод Ericsson, 1967), Rational (Rational Objectory Process, 1996–1997) и других ведущих компаниях. По сути, UP – внедренный в практику и проверенный метод разработки программного обеспечения, объеди няющий в себе лучшие качества своих предшественников. |