Джим Арлоу, Айла Нейштадт - UML 2 и Унифицированный процесс. Практический объектно-ориентированный анализ и проектирование (1037782), страница 81

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

Текст из файла (страница 81)

Что мы узнали••••••••443Проектирование реализации:• соединяются конкретные классы;• чтобы сохранить простоту (но не гибкость), необходимо проектировать реализацию.Проектирование контракта:• класс соединяется с интерфейсом, у которого может быть множество возможных реализаций;• чтобы обеспечить гибкость (что, вероятно, повысит сложность),необходимо проектировать контракт.Предоставляемый интерфейс – интерфейс, предоставляемый классификатором:• классификатор реализует интерфейс;• если в модели необходимо показать операции, используется нотация в стиле «класса»;• если интерфейс отображается без операций, используется нотация в стиле «леденец на палочках».Требуемый интерфейс – интерфейс, требуемый классификатором:• классификатору необходим другой классификатор, реализующий этот интерфейс;• отображается зависимость на интерфейс, представленный в видекласса либо с помощью нотации «леденец на палочках», или используется разъем сборки.Разъем сборки – объединяет предоставляемый и требуемый интерфейсы.Сравнение реализации интерфейса с наследованием:• реализация интерфейса – «реализует определенный контракт»;• наследование – «является»;• и наследование, и реализация интерфейса формируют полиморфизм;• интерфейсы используются для описания общих протоколовклассов, которые обычно не связываются через наследование.Порт – группирует семантически связный набор предоставляемыхи требуемых интерфейсов:• может иметь имя, тип и видимость.Компонент – модульная часть системы, инкапсулирующая ее содержимое, реализация компонента замещаема в рамках его окружения:• может иметь атрибуты и операции;• может участвовать в отношениях;• может иметь внутреннюю структуру;444Глава 19.

Интерфейсы и компоненты•••••его внешнее поведение полностью определяется его предоставляемыми и требуемыми интерфейсами;• компоненты представляют один или более артефактов.Компонентноориентированная разработка (CBD) занимается построением программного обеспечения из подключаемых частей:• чтобы сделать компоненты «подключаемыми», применяются интерфейсы;• проектирование интерфейса позволяет использовать много разных реализаций множеством различных компонентов.Компоненты могут представлять:• физическую сущность (например, EJBкомпонент);• логическую сущность (например, подсистему).Стандартные стереотипы компонентов:• «buildComponent» – компонент, определяющий набор сущностейдля организационных или системных целей разработки;• «entity» – компонент постоянной информации, представляющийбизнеспонятие;• «implementation» – компонент, не имеющий собственной спецификации; он является реализацией отдельного компонента, обозначенного стереотипом «specification», с которым имеет отношение зависимости;• «specification» – классификатор, который определяет набор объектов без описания их физической реализации – например, компонент, обозначенный стереотипом «specification», имеет толькопредоставляемые и требуемые интерфейсы, но не имеет реализующих классификаторов;• «process» – ориентированный на транзакции компонент;• «service» – не имеющий состояния функциональный компонент,вычисляющий значение;• «subsystem» – элемент иерархической декомпозиции большихсистем.Подсистема – компонент, который играет роль элемента декомпозиции большой системы:• компонент, обозначенный стереотипом «subsystem»;• логическая конструкция, используемая для разложения большой системы на управляемые части;• во время выполнения экземпляр подсистемы не может быть создан, но экземпляры ее содержимого создать можно;• разложение системы на подсистемы – ключ к успешной разработке системы с использованием UP.19.14.

Что мы узнали••445Подсистемы используются для:• разделения задач проектирования;• представления мало детализированных компонентов;• создания оболочек для унаследованных систем.• Интерфейсы используются для сокрытия деталей реализацииподсистем:• шаблон Фасад скрывает сложную реализацию за простым интерфейсом;• шаблон Разбиение на уровни компонует подсистемы в семантически связные уровни:• зависимости между уровнями должны быть направленыв одну сторону;• во всех зависимостях между уровнями должны присутствовать интерфейсыпосредники;• примерами уровней могут быть представление, бизнеслогика и сервисные уровни.Выявление интерфейсов:• ставим под сомнение ассоциации;• ставим под сомнение отправки сообщений;• выделяем группы многократно используемых операций;• выделяем группы повторяющихся операций;• выделяем группы повторяющихся атрибутов;• ищем классы, играющие в системе одну и ту же роль;• ищем возможности будущего расширения;• ищем зависимости между компонентами.20Реализация прецедентана этапе проектирования20.1.

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

Кроме того, на примересоздания диаграмм взаимодействия подсистем мы научимся использование диаграммы взаимодействий для представления высокоуровневых взаимодействий в системе. В этой главе рассказывается о временных диаграммах. Это новый, введенный в UML 2 тип диаграмм, оченьполезный для моделирования аппаратных систем реального времении встроенных систем. И завершается глава реальным, но простым примером реализации прецедента на этапе проектирования.20.2. Деятельность UP:Проектирование прецедентаДеятельность UP Проектирование прецедента (Design a use case) (рис. 20.2)заключается в выявлении проектных классов, интерфейсов и компонентов, взаимодействие которых обеспечивает поведение, описанноепрецедентом (артефакты, измененные по сравнению с оригинальнымрисунком, затушеваны). Это процесс реализации прецедента, которыйРис.

20.1. План главы20.3. Проектная реализацияпрецедента20.5.1. Активные классы20.5. Моделированиепараллелизма20.6. Взаимодействияподсистем20.9. Что мы узнали20.8. Пример реализации прецедента на этапе проектирования20.5.3. Параллелизм на коммуникационных диаграммах20.5.2. Параллелизм на диаграммах последовательностей20.4. Диаграммы взаимодействийпри проектировании20.2. Деятельность UP: Проектирование прецедента20.7. Временныедиаграммы20.2. Деятельность UP: Проектирование прецедента447448Глава 20.

Реализация прецедента на этапе проектированияМодель прецедентовПроектная реализацияпрецедентаМодель требованийАналитическая модельРазработчикпрецедентовПроектированиепрецедентаПроектный класс[в общих чертах]«subsystem»Проектная модельПодсистема[в общих чертах]Модель развертыванияИнтерфейс[в общих чертах]Рис. 20.2. Деятельность UP Проектирование прецедента. Адаптированос рис. 9.34 [Jacobson 1] с разрешения издательства Addison+Wesleyобсуждался в главе 12, но теперь основное внимание сосредоточено напроектировании, что имеет несколько важных следствий:• При проектировании в реализациях прецедентов участвуют проектные классы, интерфейсы и компоненты, а не классы анализа.• Процесс создания реализаций прецедентов на этапе проектирования часто выявляет новые нефункциональные требования и новыепроектные классы.• Проектирование реализации прецедента помогает найти то, чтоБуч называет центральными механизмами [Booch 1].

Это стандартные пути решения конкретных проблем проектирования (например, организация доступа к базе данных), которые остаются неиз+менными в течение всего процесса разработки.Входными артефактами Проектирования прецедента являются:• Модель прецедентов – см. часть II «Определение требований».• Модель требований – см. часть II «Определение требований».• Аналитическая модель – рассматривается в части III «Анализ».• Проектная модель – это то, что мы создавали в разделе, посвященномпроектированию. UP представляет проектную модель как входной20.3.

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

По существу, информация, выявленная в отношении одного артефакта, может повлиять на остальные артефакты.Синхронизация всех артефактов является составной частью проектирования.20.3. Проектная реализация прецедента«Проектная реализация прецедента» – это взаимодействие проектныхобъектов и проектных классов, реализующих прецедент.Проектная реализация прецедента – это взаимодействие проектныхобъектов и проектных классов, реализующих прецедент. Между аналитической и проектной реализациями прецедента установлено отношение «trace». Проектирование реализации прецедента определяет решения уровня реализации и реализует нефункциональные требования.

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

Характеристики

Список файлов книги