UML2 и унифицированный процесс. Джим арлоуайла нейштадтпрактический объектно ориентированныйанализ и проектированиеu
 Скачать 6.08 Mb.
|
|
• Пакет – это UML механизм группировки сущностей. • Пакеты служат многим целям: • группируют семантически взаимосвязанные элементы; • образуют «семантическую границу» в модели; • обеспечивают элементы управления конфигурацией; • в проектировании они обеспечивают элементы для распаралле ливания работы; • предоставляют инкапсулированное пространство имен, в кото ром все имена должны быть уникальными – чтобы организовать доступ к элементу пространства имен, необходимо указать и имя элемента, и имя пространства имен. • Каждый элемент модели принадлежит одному пакету: • пакеты образуют иерархию; • корневой пакет может быть обозначен стереотипом «topLevel»; • по умолчанию элементы модели помещаются в пакет «topLevel». • В пакетах анализа могут содержаться: • прецеденты; • классы анализа; • реализации прецедентов. • Элементы пакета могут иметь видимость: • видимость используется для управления количеством взаимо связей между пакетами; • существует два уровня видимости: • открытый ( +) – элементы видимы другим пакетам; • закрытый (–) – элементы полностью скрыты. 262 Глава 11. Пакеты анализа • Стереотипы пакетов: • «framework» – пакет, содержащий элементы модели, которые оп ределяют многократно используемую архитектуру; • «modelLibrary» – пакет, содержащий элементы, предназначенные для использования другими пакетами. • Пакет определяет инкапсулированное пространство имен: • для обращения к элементам других пакетов используются пол ные имена, например Library::Users::Librarian • Вложенные пакеты: • внутренний пакет может видеть все открытые члены своих внешних пакетов; • если между внешним пакетом и членами его внутренних паке тов не установлена явная зависимость (обычно «access» или «im port»), он не может видеть члены своих внутренних пакетов; это обеспечивает возможность скрывать детали реализации во вло женных пакетах. • Отношение зависимости между пакетами указывает на то, что кли ентский пакет некоторым образом зависит от пакета поставщика. • «use» – элемент клиентского пакета использует открытый эле мент пакета поставщика. • «import» – открытые элементы пространства имен поставщика добавляются как открытые элементы в пространство имен кли ента. Элементы клиента имеют доступ ко всем открытым эле ментам поставщика через неполные имена. • «access» – открытые элементы пространства имен поставщика до бавляются как закрытые элементы в пространство имен клиен та. Элементы клиента имеют доступ ко всем открытым элемен там поставщика через неполные имена. • «trace» – клиент является историческим развитием поставщика. Это отношение обычно применяется к моделям, а не к элементам. • «merge» – открытые элементы пакета поставщика объединяются с элементами клиентского пакета. Используется только при раз работке метамоделей. • Транзитивность: если у A есть отношение с B, и у B есть отношение с C, значит, A имеет отношение с C. • «import» транзитивно. • «access» нетранзитивно. • Обобщение пакетов: • очень похоже на обобщение классов; 11.8. Что мы узнали 263 • дочерние пакеты: • наследуют элементы от родительского пакета; • могут вводить новые элементы; • могут переопределять родительские элементы. • Архитектурный анализ: • распределяет связные наборы классов анализа в пакеты анализа; • распределяет пакеты анализа по уровням согласно их семантике; • пытается минимизировать количество взаимосвязей путем: • сокращения до минимума зависимостей пакетов; • сокращения до минимума количества открытых элементов во всех пакетах; • доведения до максимума количества закрытых элементов во всех пакетах. • Выявление пакетов анализа. • Рассматриваются классы анализа с целью поиска: • связных групп тесно взаимосвязанных классов; • иерархий наследования; • самую тесную взаимосвязь классов образуют (в порядке убы вания) наследование, композиция, агрегирование, зависи мость. • Рассматриваются прецеденты: • в группах прецедентов, поддерживающих определенный биз нес процесс или актера, могут быть классы анализа, которые должны быть объединены в один пакет; • среди взаимосвязанных классов могут быть классы анализа, которые должны быть объединены в один пакет; • будьте внимательны: пакеты анализа часто охватывают не сколько прецедентов! • Модель пакетов должна быть уточнена с целью максимального увеличения связности в рамках пакетов и сокращения до мини мума зависимостей между пакетами. Это достигается путем: • перемещения классов из пакета в пакет; • добавления пакетов; • удаления пакетов; • удаления циклических зависимостей путем объединения па кетов или разделения их для выделения объединенных клас сов. 12 Реализация прецедентов 12.1. План главы В этой главе обсуждается процесс реалG294 изации прецедентов, в которых осуществляется моделирование взаи модействий объектов. 12.2. Деятельность UP: Анализ прецедента В предыдущих главах было показано, как создается класс анализа – артефакт деятельности Анализ прецедента. Второй артефакт, получае мый в результате этой деятельности, – реализация прецедента, как по казано на рис. 12.2. Входные артефакты этой деятельности рассматри вались в разделе 8.2. Аналитическая модель классов – это статическая структура системы, а реализации прецедентов показывают, как взаимодействуют экземп ляры классов анализа для осуществления функциональности систе мы. Это часть динамического представления системы. Цели разработчика при реализации прецедентов во время фазы анали за следующие: • Выяснить, взаимодействие каких классов анализа обеспечивает по ведение, определенное прецедентом; во время реализации преце дентов могут быть обнаружены новые классы анализа. • Выяснить, какими сообщениями должны обмениваться экземпля ры этих классов для реализации заданного поведения. Как будет показано в этой главе, это выявит: • ключевые операции, необходимые классам анализа; • ключевые атрибуты классов анализа; • важные отношения между классами анализа. 12.2. Деятельность UP: Анализ прецедента 265 изучаем коммуникационные диаграммы 12.2. Деятельность UP: анализ прецедента 12.3. Что такое реализации прецедентов? 12.4. Реализация прецедента – элементы 12.5. Взаимодействия 12.6. Линии жизни 12.7. Сообщения 12.7.1. Синхронные, асинхронные и сообщения возврата 12.7.2. Сообщения создания и уничтожения 12.7.3. Найденные и потерянные сообщения 12.8. Диаграммы взаимодействий 12.9. Диаграммы последовательностей 12.9.1. Линии жизни и сообщения 12.9.2. Активации 12.9.3. Документирование диаграмм последовательностей 12.9.4. Инварианты состояния и ограничения 12.10. Комбинированные фрагменты и операторы 12.10.1. Ветвление с помощью операторов opt и alt 12.12. Что мы узнали 12.10.2. Организация итераций операторами loop и break 12.11. Коммуникационные диаграммы 12.11.1. Итерация 12.11.2. Ветвление изучаем реализацию прецедента изучаем диаграммы последовательностей Рис. 12.1. План главы 266 Глава 12. Реализация прецедентов • Скорректировать модель прецедентов, модель требований и классы анализа, добавив в них информацию, полученную при реализации прецедентов. Все модели должны быть согласованы и синхронизи рованы друг с другом. При реализации прецедентов в процессе анализа важно сосредото читься на отражении ключевых атрибутов, операций и отношений ме жду классами анализа. На этом этапе не надо заниматьсятакими дета лями, как параметры операций. Эта информация будет раскрыта при проектировании. Также не надо реализовывать все прецеденты. Необходимо выбрать и проработать только самые основные. Реализация прецедентов долж на продолжаться до тех пор, пока разработчик не почувствует, что об ладает достаточной информацией для понимания совместной работы классов анализа. Получив необходимый набор информации, останови тесь. UP – итеративный процесс. Поэтому при необходимости вы смо жете доработать реализацию прецедентов позже. По завершении реализации прецедентов в процессе анализа вы полу чите аналитическую модель, обеспечивающую высокоуровневое пред ставление динамического поведения системы. 12.3. Что такое реализации прецедентов? После нахождения классов анализа ключевым моментом в анализе яв ляется поиск реализаций прецедентов. Они включают наборы классов, реализующих поведение, определенное в прецеденте. Пусть, к приме Разработчик прецедентов Анализ прецедента Описание архитектуры Класс анализа Реализация прецедента Модель прецедентов Бизнес модель [или модель предметной области] Модель требований Рис. 12.2. Два артефакта деятельности Анализ прецедента. Адаптировано с рис. 8.25 [Jacobson 1] с разрешения издательства Addison Wesley 12.3. Что такое реализации прецедентов? 267 ру, есть прецедент BorrowBook (взять книгу на время) и идентифициро ваны классы анализа Book (книга), Ticket (формуляр), Borrower (пользо ватель библиотеки) и актер Librarian (библиотекарь). Необходимо соз дать реализацию прецедента, демонстрирующую взаимодействие этих классов и их объектов, которое направлено на реализацию поведения, определенного в BorrowBook. Таким образом, прецедент, который явля ется описанием функциональных требований, превращается в диа граммы классов и взаимодействий, а это уже высокоуровневое описа ние системы. Реализации прецедентов показывают, как взаимодействуют классы, чтобы реализовать функциональность системы. Хотя UML предлагает символ для реализаций прецедентов (рис. 12.3), они редко представляются в моделях явно. Причина состоит в том, что у каждого прецедента только одна реализация. Таким образом, созда ние диаграммы реализаций прецедентов не привнесет никакой допол нительной информации. Соответствующие элементы (табл. 12.1) про сто добавляются в инструмент моделирования, и реализации преце дентов становятся неявной частью базы (задним планом) модели. Реализации прецедентов – это неявная часть базы модели; обычно они не отображаются на диаграммах. Таблица 12.1 Элемент Назначение Диаграммы классов анализа Показывают классы анализа, взаимодействующие для реа лизации прецедента. Диаграммы взаимодействий Показывают взаимодействия определенных экземпляров, реализующих прецедент; это «моментальные снимки» ра ботающей системы. Особые требования Процесс реализации прецедентов может выявить новые ха рактерные для прецедента требования; они должны быть зафиксированы. Уточнение прецедентов Во время реализации может быть обнаружена новая инфор мация, т. е. происходит обновление исходного прецедента. Place Order «trace» 1 1 зависимость реализация прецедента прецедент «use case realization» Place Order Рис. 12.3. Синтаксис реализации прецедента 268 Глава 12. Реализация прецедентов 12.4. Реализация прецедента – элементы Реализации прецедентов включают элементы, показанные в табл. 12.1. По сути, реализация прецедента – это процесс уточнения. Вы выбирае те один из аспектов поведения системы, зафиксированный в прецеден те и любых ассоциированных с ним требованиях, и моделируете то, как это все может быть реализовано через взаимодействия экземпля ров классов анализа, которые были найдены. Тем самым вы проходите путь от общей спецификации требуемого поведения до довольно под робного описания взаимодействий между классами и объектами, кото рые сделают это поведение реальным. Диаграммы классов анализа «рассказывают историю» об одном или бо лее прецедентах. Диаграммы классов анализа – жизненно важная часть реализации прецедента. Они должны «рассказывать истории» о системе: о том, как должны быть взаимосвязаны классы, чтобы их экземпляры могли взаимодействовать для реализации поведения, определенного в одном или более прецедентах. Диаграммы взаимодействий показывают, как взаимодействуют экземп ляры классификаторов для реализации поведения системы. Кроме диаграмм классов можно создать диаграммы, демонстрирующие совместную работу и взаимодействие экземпляров этих классов анали за, направленные на реализацию части или всего поведения прецедента. Эти диаграммы называют диаграммами взаимодействий. Существует четыре типа таких диаграмм: диаграммы последовательностей, комму никационные диаграммы, диаграммы обзора взаимодействий и вре менные диаграммы. Диаграммы последовательностей и коммуникаци онные обсуждаются в этой главе, диаграммы обзора взаимодействий – в разделе 15.12, а временные диаграммы – в разделе 20.7. ОО моделирование – итеративный процесс. Поэтому не надо удивлять ся, если при более глубоком моделировании будут выявлены новые требования или понадобится изменить существующие прецеденты. Все это – часть реализации прецедентов. Существующие документы долж ны соответствовать самой последней информации о системе. Необходи мо обновлять модель прецедентов, модель требований и классы анали за, чтобы все они были согласованными. 12.5. Взаимодействия Взаимодействия – это просто единицы поведения классификатора. Этот классификатор, который называют контекстным классифика тором (context classifier), предоставляет контекст взаимодействия. 12.6. Линии жизни 269 Взаимодействие – это единица поведения контекстного классификатора. Взаимодействие может использовать любую из возможностей своего контекстного классификатора или любые возможности, к которым классификатор имеет доступ (например, временные или глобальные переменные). В реализации прецедента контекстным классификатором является прецедент. Создается одно или более взаимодействий, чтобы показать, как экземпляры классификаторов (в данном случае классов анализа), обмениваясь сообщениями, могут реализовать определенное преце дентом поведение. В ходе работы над диаграммами взаимодействий обнаруживается все больше и больше операций и атрибутов классов анализа. Как часть процесса реализации прецедента должно осуществляться обновление диаграмм классов анализа этой информацией. Ключевые элементы диаграмм взаимодействий – линии жизни и сооб щения. Они подробно рассматриваются в следующих двух разделах. 12.6. Линии жизни Линия жизни – участник взаимодействия. Линия жизни (lifeline) представляет одного участника взаимодейст вия, т. е. она представляет, как экземпляр конкретного классифика тора участвует во взаимодействии. Синтаксис линии жизни приведен на рис. 12.4. У каждой линии жизни есть необязательное имя, тип и необязатель ный селектор. • Имя используется для обращения к линии жизни во взаимодейст вии. • Тип – имя классификатора, экземпляр которого представляет ли ния жизни. • Селектор – логическое условие, которое может использоваться для выбора единственного экземпляра, удовлетворяющего этому усло вию. Если селектора нет, линия жизни ссылается на произвольный экземпляр классификатора. Селекторы действительны, только ес имя селектор тип jimsAccount [ id = "1234" ] : Account Рис. 12.4. Синтаксис линии жизни 270 Глава 12. Реализация прецедентов ли кратность типа больше единицы, т. е. существует множество эк земпляров, из которых можно выбирать. На рис. 12.4 селектор вы бирает экземпляр класса Account, id которого – «1234». Линии жизни изображаются той же пиктограммой, что и их тип, и име ют вертикальный пунктирный «хвост», когда используются в диа граммах последовательностей. Некоторые примеры линий жизни при ведены на рис. 12.5. Линии жизни представляют, как экземпляр классификатора участвует во взаимодействии. Линию жизни объекта можно рассматривать как элемент, который представляет, как экземпляр классификатора может участвовать во взаимодействии. Однако она не представляет никакого конкретного экземпляра классификатора. Это едва различимое, но важное отли чие. Взаимодействие описывает, как экземпляры классификатора вза имодействуют в общем, а не выделяет какое то одно конкретное взаи модействие между рядом конкретных экземпляров. Поэтому можно считать, что линия жизни объекта представляет роль, которую может играть во взаимодействии экземпляр классификатора. Реальные экземпляры можно показать прямо на диаграмме взаимо действий. Используется обычная нотация для экземпляров: символ классификатора с именем экземпляра, селектор (если таковой имеет ся), двоеточие и имя классификатора; все подчеркивается. Различие между линиями жизни и экземплярами послужило причиной появления двух разных форм диаграмм взаимодействий. Общая форма (generic form) диаграммы взаимодействий показывает взаимодействие между линиями жизни, представляющими произвольные экземпля ры. Форма экземпляров (instance form) диаграммы взаимодействий показывает взаимодействие между конкретными экземплярами. Об щая форма диаграммы является более удобной и часто используемой. Чтобы взаимодействие было полным, должны быть определены сооб щения, посылаемые между линиями жизни. Сообщения рассматрива ются в следующем разделе. jim:Person :OrderProcessing Orders.jar имя классификатор |