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

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

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

Что мы узналиИнтерфейсы обеспечивают возможность проектировать программноеобеспечение как контракт, а не как конкретную реализацию. Мы узнали следующее:•Деятельность UP Проектирование подсистемы заключается в разделении системы на подсистемы – по возможности максимально независимые части.•••Посредниками во взаимодействии систем выступают интерфейсы.Интерфейс определяет именованный набор открытых свойств.•Интерфейсы отделяют описание функциональности от ее реализации.•Интерфейсы могут быть прикреплены к классам, подсистемам,компонентам и любому другому классификатору и определяютпредлагаемые ими сервисы.•Если классификатор в подсистеме реализует открытый интерфейс, подсистема или компонент также реализует открытый интерфейс.•Все, что реализует интерфейс, соглашается придерживатьсяконтракта, определенного набором операций, описанных в интерфейсе.Семантика интерфейса – реализующий интерфейс классификаторимеет следующие обязанности по отношению к каждой из возможностей:•операция – должен иметь операцию с аналогичной сигнатуройи семантикой;•атрибут – должен иметь открытые операции для задания и получения значения атрибута:••классификатор, реализующий интерфейс, не обязан иметь атрибут, но он должен вести себя так, как будто атрибут у негоесть;ассоциация – должен иметь ассоциацию с целевым классификатором:•если интерфейс описывает ассоциацию с другим интерфейсом, ассоциация между этими интерфейсами должна сохраняться и у реализующего их классификатора;•ограничение – должен поддерживать ограничение;•стереотип – имеет стереотип;•помеченное значение – имеет помеченное значение;•протокол – должен реализовывать протокол.19.14.

Что мы узнали••••••••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.

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

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