UML2 и унифицированный процесс. Джим арлоуайла нейштадтпрактический объектно ориентированныйанализ и проектированиеu
 Скачать 6.08 Mb.
|
|
411 той системы управления библиотекой. На нее наложены следующие бизнес ограничения: • существует два типа класса Borrower (читатель) – StudentBorrower (чи татель студент) и StaffBorrower (читатель сотрудник); • у StudentBorrower одновременно на руках может быть максимум че тыре книги; • у StaffBorrower одновременно на руках может быть максимум восемь книг; • одновременно в системе может быть зарегистрирован только один Librarian (библиотекарь) – это однопользовательская система. Все атрибуты и операции на этом рисунке скрыты, потому что основ ное внимание направлено на аспекты структуры системы. Как видите, у класса LibraryManager (менеджер библиотеки) есть внут ренняя структура – сочетание Borrower, Book и Librarian. Из за транзитив ной природы композиции классы Loan (выдача) также являются частью этой составной структуры. Класс LibraryManager можно представить как структурированный класс, как показано на рис. 18.21. Обратите вни мание, что классы StudentBorrower и StaffBorrower тоже отображены как структурированные. Кстати, структурированные классы могут быть вложенными с любым уровнем вложенности. Loan Borrower StudentBorrower StaffBorrower Librarian LibraryManager borrowers 0..* loans 0..* 0..* 1 borrowedBook catalog 0..* 1 1 1..* 1 1 {одновременно только один библиотекарь (Librarian) может быть зарегистрирован в системе} {число книг на руках = 4} {число книг на руках = 8} LibraryManagementSystem Book Рис. 18.20. Диаграмма классов для системы управления библиотекой 412 Глава 18. Уточнение отношений, выявленных при анализе Рисунок 18.21 дает несколько другое представление системы и позво ляет взглянуть на класс LibraryManager немного подробнее, рассмотрев роли, исполняемые экземплярами класса в его реализации. • С точки зрения менеджера библиотеки ( LibraryManager) существует два типа читателей ( Borrower), которые обрабатываются немного по разному исходя из максимального количества выданных книг ( Loan). Чтобы представить это, вводятся новые роли – student (сту дент) и staff (штат). • У student и staff может быть разное максимальное количество невоз вращенных Loan в любой момент времени. Чтобы показать это, соз даются две разные роли Loan – studentLoan и staffLoan – и для каждой из них вводится соответствующая кратность. • LibraryManager допускает одновременную регистрацию в системе только одного Librarian, поэтому введена роль loggedOnLibrarian (заре гистрированный библиотекарь) с кратностью 0..1. Некоторые роли ассоциаций могут проецироваться в роли частей. Как видите, мы смогли явно представить внутренние роли, исполняе мые экземплярами в рамках контекста класса LibraryManager. Заметьте, что эти роли могут отличаться от ролей, исполняемых классами в их ассоциациях с LibraryManager. Например, на рис. 18.20 класс Borrower иг рает роль borrowers в своей ассоциации с LibraryManager. А на рис. 18.21 эта роль была уточнена и превратилась в более конкретные роли под studentLoan:Loan[0..4] :Book[0..*] LibraryManager implementation student:Borrower[0..*] staff:Borrower[0..*] 0..* 0..* 1 1 :Librarian[1..*] loggedOnLibrarian:Librarian[0..1] staffLoan:Loan[0..8] :LibraryManager Рис. 18.21. Структурированный класс LibraryManager 18.13. Что мы узнали 413 классов Borrower, student и staff. Как правило, некоторые роли ассоциа ций проецируются в роли частей, а некоторые – нет. Аналогично соединители могут проецироваться в ассоциации между классами или только во временные отношения, созданные в контексте структурированного класса. В этом простом примере каждый соедини тель может быть отображен в ассоциацию. Внутреннюю структуру структурированных классификаторов можно представить как на диаграмме классов, так и на специальной диаграм ме, которую называют диаграммой составных структур (composite structure diagram ). Имя диаграммы соответствует имени структуриро ванного классификатора, а содержимое диаграммы – это содержимое структурированного классификатора. На рис. 18.22 изображена диа грамма составных структур класса LibraryManager. 18.13. Что мы узнали В этой главе было показано, как выявленные при анализе отношения преобразуются в отношения уровня проектирования, которые уже можно реализовывать. Мы узнали следующее. • Уточнение аналитических отношений до отношений уровня проек тирования включает: • уточнение ассоциаций до агрегации или композитной агрегации в соответствующих случаях; studentLoan:Loan[0..4] :Book[0..*] staffLoan:Loan[0..8] student:StudentBorrower[0..*] staff:StaffBorrower[0..*] 0..* 0..* 1 1 :Librarian[1..*] loggedOnLibrarian:Librarian[0..1] LibraryManager диаграмма составных структур Рис. 18.22. Диаграмма составных структур класса LibraryManager 414 Глава 18. Уточнение отношений, выявленных при анализе • реализацию классов ассоциаций; • реализацию ассоциаций один ко многим; • реализацию ассоциаций многие к одному; • реализацию ассоциаций многие ко многим; • реализацию двунаправленных ассоциаций; • введение возможности навигации; • введение кратности на обоих концах ассоциации; • введение имени роли на обоих концах ассоциации или, по край ней мере, на целевом конце; • использование структурированных классификаторов. • Агрегация и композиция. • Это отношения типа целое часть, где объекты одного класса иг рают роль целого, или агрегата, а объекты другого класса игра ют роль частей: • целое использует сервисы частей; части обслуживают запро сы целого; • целое является доминирующей, контролирующей стороной отношения; часть обычно играет более пассивную роль. • Эти отношения транзитивны – если C является частью B и B яв ляется частью A, тогда C является частью A. • Эти отношения асимметричны: • целое никогда – ни прямо, ни косвенно – не может быть ча стью самого себя; • циклы в схеме агрегации недопустимы. • Существует два типа отношения агрегации: • агрегация; • композитная агрегация – обычно ее называют просто компо зицией. • Агрегация. • Семантика агрегации: • агрегат может зависеть от частей, а иногда может существо вать независимо от них; • части могут существовать независимо от агрегата; • агрегат является несколько неполным в случае отсутствия не которых частей; • несколько агрегатов могут владеть частями совместно; • возможны иерархии и сети агрегации; • целое всегда знает о существовании частей, но если отношение однонаправленное, от целого к части, части не знают о целом. 18.13. Что мы узнали 415 • Примером агрегации может быть компьютер и его периферий ное оборудование: • компьютер слабо связан со своим периферийным оборудова нием; • периферийное оборудование может появляться и исчезать; • периферийное оборудование может использоваться совместно несколькими компьютерами; • периферийное оборудование не «принадлежит» ни одному конкретному компьютеру. • Композиция. • Это строгая форма агрегации: • части одновременно принадлежат только одному композиту; • композит обладает исключительной ответственностью за уп равление всеми своими частями – ответственностью за их соз дание и уничтожение; • композит также может высвобождать части, если ответствен ность за них берет на себя другой объект; • если композит уничтожается, он должен уничтожить все свои части или передать ответственность за них какому то другому объекту; • каждая часть принадлежит только одному композиту, поэто му возможны только иерархии композиции – сетей компози ции не существует. • Примером композиции может быть дерево и его листья: • листья принадлежат только одному дереву; • листья не могут принадлежать нескольким деревьям; • когда умирает дерево, умирают и его листья. • Часть в композите эквивалентна атрибуту: • явная композиция применяется, когда части важны и пред ставляют интерес; • атрибуты используется, когда части не важны и не представ ляют интереса. • Уточнение аналитических ассоциаций. • Аналитические ассоциации должны быть уточнены в одно из от ношений агрегации везде, где это возможно. Если при этом в схе ме агрегации образуется цикл, должна использоваться ассоциа ция или зависимость. • Процедура уточнения ассоциаций до отношений агрегации: • вводятся кратности и имена ролей; 416 Глава 18. Уточнение отношений, выявленных при анализе • принимается решение о том, какая сторона отношения явля ется целым, а какая – частью: • рассматривается кратность со стороны целого: • если она равна 1, вероятно, можно использовать компози цию – если ассоциация имеет семантику композиции, должна применяться композиция; • если она не равна 1, должна использоваться агрегация; • вводится возможность навигации от целого к части. • Типы ассоциаций. • Ассоциация один к одному – почти всегда становится компози цией. Однако она может быть заменена на атрибут или два клас са, которые она связывает, могут быть объединены в один. • Ассоциация многие к одному: • используется агрегация; композиция не может использовать ся, поскольку кратность целого – «многие»; • проводится проверка на наличие циклов в схеме агрегации. • Ассоциация один ко многим: • здесь на стороне части находится коллекция объектов; • используется встроенный массив (большинство ОО языков программирования поддерживают массивы напрямую); обыч но они обладают плохой гибкостью, но довольно быстрые; • используется класс коллекция; они характеризуются боль шей гибкостью, чем встроенные массивы, и поиск по коллек ции осуществляется быстрее (в других случаях они медлен нее массивов). • Коллекции. • Это специализированные классы, экземпляры которых могут управлять коллекциями других объектов. • Все классы коллекции имеют операции для: • добавления объектов в коллекцию; • удаления объектов из коллекции; • получения ссылки на объект коллекции; • обхода коллекции – прохода по коллекции от первого объ екта до последнего. • Моделирование с использованием коллекций – существует че тыре варианта: • класс коллекция моделируется явно; • путем введения свойства в отношение, например {Vector}, ин струменту моделирования сообщается, какую коллекцию ис пользовать; 18.13. Что мы узнали 417 • путем введения свойства в отношение программисту сообща ется требуемая семантика коллекции: • {ordered} – элементы коллекции располагаются в строгом порядке; • {unordered} – элементы коллекции располагаются не в стро гом порядке; • {unique} – все элементы коллекции уникальны; • {nonunique} – в коллекции допускается дублирование эле ментов. • задача по уточнению отношений один ко многим в классы коллекции передается программистам; • нельзя «переусердствовать» в моделировании – выбор кон кретного класса коллекции часто является тактическим ре шением, которое может быть принято программистами во время реализации. • Типы коллекций: • Коллекции OCL: • Bag – {unordered, nonunique}; • Set – {unordered, unique}; • OrderedSet – {ordered, unique}; • Sequence – {ordered, nonunique}. • Карта: • еще называют словарем; • очень быстрый поиск соответствующего значения по за данному ключу; • ведет себя как база данных с таблицей, состоящей из двух столбцов – ключа и значения; • ключи должны быть уникальными. • Конкретизированные отношения. • Некоторые отношения являются исключительно артефакта ми анализа и должны быть подготовлены к реализации по средством процесса конкретизации. • Ассоциации многие ко многим: • это отношение конкретизируется в класс; • принимается решение, какая часть является целым, и ис пользуется агрегация, композиция или ассоциация. • Двунаправленные ассоциации: • заменяются однонаправленной агрегацией или компози цией от целого к части и однонаправленной ассоциацией или зависимостью от части к целому. 418 Глава 18. Уточнение отношений, выявленных при анализе • Классы ассоциации: • принимается решение, какая сторона является целым, а ка кая – частью; • заменяется классом (обычно его имя аналогично имени класса ассоциации); • добавляется примечание с ограничением, указывающим на то, что объекты на каждом конце конкретизированного отношения должны образовывать уникальную пару. • Изучение композиции с использованием структурированных клас сов. • Структурированный классификатор – классификатор (напри мер, класс), имеющий внутреннюю структуру. • моделируется как части, объединенные с помощью соедини телей: • часть – роль, которую могут исполнять один или более эк земпляров классификатора в контексте структурирован ного классификатора; • имя – имя части; • тип – тип объектов, которые могут играть роль; • кратность – число объектов, которые одновременно мо гут играть ту или иную роль; • соединитель – отношение между частями в контексте структурированного классификатора. • Внутренняя структура может быть отображена на диаграм мах классов или на диаграмме составных структур. • Структурированный класс: • класс, имеющий внутреннюю структуру; • имеет дополнительное ограничение относительно того, что ему принадлежат (он имеет неявное отношение включения) все его части, соединители и порты. 19 Интерфейсы и компоненты 19.1. План главы Данная глава посвящена двум основным понятиям – интерфейсам и компонентам. Эти темы обсуждаются вместе, потому что, как вы увидите, они тесно взаимосвязаны. Кроме того, в разделе 19.10 будет показано, как использование интерфейсов в сочетании со специаль ным типом компонентов, которые называют подсистемами, обеспечи вает возможность создания гибких архитектур систем. 19.2. Деятельность UP: Проектирование подсистемы Эта глава в основном посвящена деятельности UP Проектирование под системы (Design a subsystem). Подсистема – это всего лишь особый тип компонентов, поэтому здесь мы обсуждаем компоненты и компонент но ориентированную разработку вместе с подсистемами. Как будет по казано позже, рассматриваемые вопросы оказывают влияние на дру гие проектные деятельности UP. Деятельность UP Проектирование подсистемы представлена на рис. 19.2. Оригинальный рисунок изменен в соответствии с UML 2, в котором подсистемы являются типами компонентов, а не помеченными стерео типами пакетами. Измененные артефакты на рисунке затушеваны. Деятельность Проектирование подсистемы заключается в разделении сис темы на максимально независимые друг от друга части. Эти части и на зывают подсистемами. Посредниками во взаимодействии подсистем выступают интерфейсы. Цель проектирования подсистем – миними зировать связанность в системе, разработав соответствующие интер фейсы, и гарантировать во всех подсистемах правильную реализацию поведения, определенного интерфейсами. 420 Глава 19. Интерфейсы и компоненты Рис. 19.1. План главы изучаем моделирование с использованием интерфейсов 19.2. Деятельность UP: Проектирование подсистемы 19.3. Что такое интерфейс? 19.4. Предоставляемые и требуемые интерфейсы 19.5. Сравнение реализации интерфейса и наследования 19.7. Интерфейсы и компонентно ориентированная разработка 19.6. Порты разбираемся, в чем разница между реализацией интерфейса и наследованием 19.8. Что такое компонент? 19.9. Стереотипы компонентов 19.10. Подсистемы 19.14. Что мы узнали 19.13. Преимущества и недостатки интерфейсов 19.12.2. Архитектура и шаблон Разбиение на уровни 19.12.1. Шаблон Фасад 19.12. Проектирование с использованием интерфейсов 19.11. Выявление интерфейсов изучаем, как выявляются интерфейсы 19.3. Что такое интерфейс? 421 19.3. Что такое интерфейс? Интерфейс определяет именованный набор открытых свойств. Интерфейс определяет именованный набор открытых свойств. Главная идея, лежащая в основе интерфейсов, – разделение описания функциональности (интерфейс) от ее реализации классификатором, та ким как класс или подсистема. Создать экземпляр интерфейса невоз можно. Он просто объявляет контракт, который может быть реализован классификаторами. Все, что реализует интерфейс, принимает и согла шается следовать определяемому интерфейсом контракту. Интерфейсы разделяют описание функциональности от ее реализации. Возможности, которые могут быть описаны в интерфейсах, перечисле ны в табл. 19.1. В ней также показаны обязанности реализующих их классификаторов по отношению к интерфейсу. В интерфейсах также должны присутствовать описания семантики их возможностей (обычно в виде текста или псевдокода) как руководства для тех, кто будет их реализовывать. Интерфейс [полный] Интерфейс [в общих чертах] Разработчик компонентов Проектирование подсистемы Описание архитектуры Подсистема [в общих чертах] Подсистема [полная] «subsystem» «subsystem» |