UML2 и унифицированный процесс. Джим арлоуайла нейштадтпрактический объектно ориентированныйанализ и проектированиеu
 Скачать 6.08 Mb.
|
|
442 Глава 19. Интерфейсы и компоненты 19.14. Что мы узнали Интерфейсы обеспечивают возможность проектировать программное обеспечение как контракт, а не как конкретную реализацию. Мы уз нали следующее: • Деятельность 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.2. Деятельность UP: Проектирование прецедента 447 20.5.3. Параллелизм на коммуникационных диаграммах 20.2. Деятельность UP: Проектирование прецедента 20.3. Проектная реализация прецедента 20.4. Диаграммы взаимодействий при проектировании 20.5. Моделирование параллелизма 20.6. Взаимодействия подсистем 20.7. Временные диаграммы 20.5.1. Активные классы 20.9. Что мы узнали 20.8. Пример реализации прецедента на этапе проектирования 20.5.2. Параллелизм на диаграммах последовательностей Ри с . 2 0 .1 . Пл ан гл ав ы 448 Глава 20. Реализация прецедента на этапе проектирования обсуждался в главе 12, но теперь основное внимание сосредоточено на проектировании, что имеет несколько важных следствий: • При проектировании в реализациях прецедентов участвуют про ектные классы, интерфейсы и компоненты, а не классы анализа. • Процесс создания реализаций прецедентов на этапе проектирова ния часто выявляет новые нефункциональные требования и новые проектные классы. • Проектирование реализации прецедента помогает найти то, что Буч называет центральными механизмами [Booch 1]. Это стандарт ные пути решения конкретных проблем проектирования (напри мер, организация доступа к базе данных), которые остаются неиз менными в течение всего процесса разработки. Входными артефактами Проектирования прецедента являются: • Модель прецедентов – см. часть II «Определение требований». • Модель требований – см. часть II «Определение требований». • Аналитическая модель – рассматривается в части III «Анализ». • Проектная модель – это то, что мы создавали в разделе, посвященном проектированию. UP представляет проектную модель как входной Разработчик прецедентов Проектирование прецедента Проектный класс [в общих чертах] Аналитическая модель Модель прецедентов Модель требований Интерфейс [в общих чертах] Проектная модель Модель развертывания Подсистема [в общих чертах] «subsystem» Проектная реализация прецедента Рис. 20.2. Деятельность UP Проектирование прецедента. Адаптировано с рис. 9.34 [Jacobson 1] с разрешения издательства Addison Wesley 20.3. Проектная реализация прецедента 449 артефакт Проектирования прецедента, чтобы обозначить итеративную природу этого процесса. По мере выявления в процессе проектиро вания все большего числа деталей системы происходит уточнение каждого из артефактов. • Модель развертывания – обсуждается в главе 24. Модель развертыва ния также представлена как входной артефакт этой деятельности проектирования, чтобы проиллюстрировать, как все артефакты со вместно эволюционируют во времени. Важно понимать, что проектирование – итеративный процесс, а не по следовательность шагов. По существу, информация, выявленная в от ношении одного артефакта, может повлиять на остальные артефакты. Синхронизация всех артефактов является составной частью проекти рования. 20.3. Проектная реализация прецедента «Проектная реализация прецедента» – это взаимодействие проектных объектов и проектных классов, реализующих прецедент. Проектная реализация прецедента – это взаимодействие проектных объектов и проектных классов, реализующих прецедент. Между ана литической и проектной реализациями прецедента установлено отно шение «trace». Проектирование реализации прецедента определяет ре шения уровня реализации и реализует нефункциональные требова ния. Проектная реализация прецедента состоит из: • проектных диаграмм взаимодействий; • диаграмм классов, включающих участвующие в ней проектные классы. При анализе основное внимание в реализации прецедентов было сосре доточено на том, что должна делать система. В проектировании нас интересует, как система собирается это делать. Таким образом, теперь нам необходимо определить детали реализации, которые игнорирова лись на этапе анализа. Поэтому проектные реализации прецедентов являются намного более детализированными и сложными, чем исход ные аналитические реализации прецедентов. Важно помнить, что моделирование осуществляется лишь для того, чтобы облегчить понимание создаваемой системы. Объем работы дол жен быть ограничен лишь тем, что на самом деле представляет инте рес. Такой подход называют стратегическим проектированием. Суще ствует также тактическое проектирование, которое можно без ущерба перенести в фазу реализации. По сути, полное проектирование осуще ствляется только тогда, когда предполагается генерировать большую часть кода из модели. И даже в этом случае проектные реализации прецедентов редко активно используются в генерировании кода. По 450 Глава 20. Реализация прецедента на этапе проектирования этому они создаются, только если необходимо обозначить малопонят ные аспекты поведения системы. 20.4. Диаграммы взаимодействий при проектировании При проектировании можно уточнять основные диаграммы взаимодей ствий или создавать новые для иллюстрации центральных механизмов, таких как сохранение объектов. Диаграммы взаимодействий – основная часть проектной реализации прецедента. Поскольку большие объемы информации проще показать на диаграммах последовательностей, то при проектировании зачастую именно им, а не коммутационным диаграммам, уделяется основное внимание. Диаграммы взаимодействий в проектировании могут быть: • уточнением основных аналитических диаграмм взаимодействий с дополнением деталей реализации; • абсолютно новыми диаграммами, созданными для иллюстрации технических вопросов, возникших при проектировании. При проектировании вводится ограниченное число центральных ме ханизмов, таких как сохранение объектов, распределение объектов, транзакции и т. д. Часто диаграммы взаимодействий создаются имен но для представления этих механизмов. Диаграммы взаимодействий, иллюстрирующие центральные механизмы, нередко охватывают не сколько прецедентов. Чтобы понять роль диаграмм последовательностей в проектировании, рассмотрим прецедент AddCourse, который обсуждался ранее в разде ле 12.9.1 (рис. 20.3). На рис. 20.4 показана аналитическая диаграмма взаимодействий, соз данная нами в разделе 12.9.1 (с. 276). На рис. 20.5 представлена обычная диаграмма последовательностей для прецедента AddCourse на ранних этапах проектирования. Как види те, здесь добавлен слой GUI, хотя он и не был смоделирован достаточно глубоко. Также высокоабстрактные операции аналитической диаграм мы последовательностей превращены в операции уровня проектирова ния, достаточно полно описанные для реализации. Например, теперь подробно показано создание объекта посредством вызова явной опера ции конструктора. Рисунок 20.5 также включает центральный механизм – обеспечение сохранения объектов Course. В данном случае был выбран очень про стой механизм сохранения: :RegistrationManager использует сервисы :DBManager для хранения объектов Course в базе данных. Важно, что этот 20.4. Диаграммы взаимодействий при проектировании 451 центральный механизм, будучи определенным один раз, должен оста ваться неизменным в течение всего проектирования. Однажды нам пришлось работать над большой системой, в которой было не менее трех разных механизмов сохранения – конечно, это слишком много! Прецедент: AddCourse Главные актеры: Registrar. Предусловие: 1. Registrar вошел в систему. Постусловие: 1. Новый курс добавлен в систему. Основной поток: 1. Registrar выбирает «add course». 2. Registrar вводит имя нового курса. 3. Система создает новый курс. Альтернативные потоки: CourseAlreadyExists ID: 8 Краткое описание: Добавляет детали нового курса в систему. Второстепенные актеры: Нет. Рис. 20.3. Спецификация прецедента AddCourse :Registrar :RegistrationManager uml:Course addCourse( "UML" ) «create» sd AddCourse Registrar выбирает «add course» Система создает новый курс Рис. 20.4. Аналитическая диаграмма взаимодействий 452 Глава 20. Реализация прецедента на этапе проектирования 20.5. Моделирование параллелизма Параллелизм – один из ключевых вопросов, рассматриваемых при про ектировании. Параллелизм означает параллельное выполнение частей системы. Это один из ключевых вопросов, рассматриваемых при проектировании. UML 2 обеспечивает хорошую поддержку параллелизма: • активные классы (раздел 20.5.1); • ветвления и объединения на диаграммах деятельности (раздел 14.8.3); • оператор par на диаграммах последовательностей (раздел 20.5.2); |