UML2 и унифицированный процесс. Джим арлоуайла нейштадтпрактический объектно ориентированныйанализ и проектированиеu
 Скачать 6.08 Mb.
|
|
Актер Указывает на Представляет человека Класс пользовательского интерфейса (GUI) Представляет систему Класс системного интерфейса Представляет устройство Класс аппаратного интерфейса 8.4. Выявление классов 193 рой мы считаем использование стереотипов RUP необязательным. Они могут сбить с толку начинающих разработчиков моделей! В реальности контроллеры, вытекающие непосредственно из предмет ной области (а не появляющиеся как побочный продукт определенной техники анализа), обычно охватывают несколько прецедентов. Удач ным примером контроллера является класс Registrar (регистратор). Он задействован во многих прецедентах, описывающих систему регистра ции курса. Аналогично одному прецеденту может требоваться участие нескольких управляющих классов. Если управляющий класс обладает очень сложным поведением, это го ворит о том, что, вероятно, его можно разбить на два или более про стых контроллера, реализующих связную часть этого поведения. Ка ждый из получившихся простых классов должен по прежнему пред ставлять что то, что реально имеет место в предметной области. На пример, при проектировании системы регистрации курса сначала может быть введен управляющий класс CourseRegistrationController (кон троллер регистрации курса), координирующий весь процесс. Но по ведение такого класса очень сложное, поэтому его можно разбить на ряд взаимодействующих классов, каждый из которых будет отвечать за один два аспекта этого поведения. Класс можно было бы разложить на классы Registrar, CourseManager (менеджер курсов) и PersonnelManager (менеджер персонала). Обратите внимание, что каждый из этих клас сов представляет реальную сущность предметной области. Хороший способ проанализировать управляющие классы – предста вить себя в роли такого класса. Что вам пришлось бы сделать в такой ситуации? 8.4.3.3. Выявление классов типа «entity» Эти классы моделируют информацию о чем то и обычно имеют очень простое поведение, состоящее практически только в получении и зада нии значений. Классы, представляющие постоянную информацию, например адреса (класс Address) и людей (класс Person), являются клас сами сущностями. Классы сущности: • пересекают несколько прецедентов; • с ними оперируют управляющие классы; • предоставляют и принимают информацию от граничных классов; • представляют ключевые сущности, которыми управляет система (например, Customer); • часто являются постоянными (persistent). Классы сущности выражают логическую структуру данных системы. Если есть модель данных, классы сущности тесно связаны с сущностя ми или таблицами этой модели. 194 Глава 8. Выявление классов анализа 8.4.4. Выявление классов из других источников Помимо анализа существительное/глагол, CRC анализа и стереотипов RUP существует множество других потенциальных источников клас сов, которые необходимо учитывать. Мы ищем четкие абстракции, ко торые проецируются на реальные сущности предметной области. По добным же образом можно найти классы и в реальном мире. • Все физические объекты, такие как самолет, люди и гостиницы, могут обозначать класс. • Документооборот – еще один богатый источник классов. Такие ве щи, как счета, заказы и сберегательные книжки, могут указывать на возможные классы. Однако при рассмотрении системы докумен тооборота необходимо быть очень осторожными. Во многих компа ниях она развивалась в течение многих лет с сохранением поддерж ки устаревших и неиспользуемых бизнес процессов, которые новая система, возможно, пытается заменить! Самая неприятная работа для ОО аналитика/проектировщика – автоматизация устаревшей бумажной системы. • Известные внешние интерфейсы, такие как экраны, клавиатуры, периферийные устройства и другие системы, также могут быть ис точником предполагаемых классов, особенно в случае встроенных систем. • Концептуальные сущности – это сущности, важные для функцио нирования предприятия, но не являющиеся конкретными сущно стями. Примером такой сущности может быть LoyaltyProgram (про грамма лояльности), например призовая карта. Конечно, сама про грамма не является конкретной сущностью (ее нельзя пощупать!), но это связная абстракция, поэтому ее можно смоделировать как класс. 8.4.4.1. Базовые шаблоны Базовые шаблоны могут предоставить готовые компоненты аналитиче ской модели. В нашей книге «Enterprise Patterns and MDA» [Arlow 1] описывалось по нятие, названное нами базовые шаблоны (archetype patterns). Это шаб лоны бизнес понятий, настолько распространенных в бизнес системах, что мы решили считать их по настоящему базовыми. То есть их можно смоделировать один раз и затем использовать повторно, а не моделиро вать вновь и вновь в каждой новой бизнес системе. Основная мысль книги состоит в том, что шаблоны можно использовать в исходном или измененном виде, создавая аналитическую модель из компонентов мо дели (model components). Эта техника называется компонентно ориен тированным моделированием (component based modeling). 8.5. Создание аналитической модели в первом приближении 195 Мы предоставляем следующие базовые шаблоны: • Customer Relationship Management; • Inventory; • Money; • Order; • Party; • Party relationship; • Product; • Quantity; • Rule. Каждый шаблон разработан очень подробно и отличается содержа тельностью. Их использование позволит сохранить массу человеко дней или даже человеко месяцев работы. Если шаблон не вполне под ходит для моделируемой системы, он может служить источником по лезных идей для написания собственных классов анализа. Это лучше, чем начинать с чистого листа. Использование шаблонов – это, наверное, самый эффективный способ выявления классов моделей: просто взять их с полки! 8.5. Создание аналитической модели в первом приближении Чтобы создать аналитическую модель в первом приближении, необхо димо в инструментальном средстве моделирования объединить в одну UML модель результаты анализа существительное/глагол, CRC ана лиза, стереотипов RUP и изучения других источников классов (осо бенно базовых шаблонов). Объединение осуществляется следующим образом: 1. Сравниваются все источники классов. 2. Классы анализа, атрибуты и обязанности, полученные из разных источников, объединяются и вводятся в инструментальное средст во моделирования. 2.1. С помощью глоссария проекта выявляются синонимы и омо нимы. 2.2. Находятся различия в результатах трех методов. Отличия ука зывают на неопределенности или моменты, требующие более тщательной проработки. Обработайте эти различия сейчас или оставьте это на будущее. 3. Участники (или линии между клеящимися записками на доске) представляют отношения между классами. Моделирование отно шений будет обсуждаться в главе 9. 196 Глава 8. Выявление классов анализа 4. Корректируются имена классов, атрибутов и обязанностей согласно какому либо стандартному соглашению о присваивании имен, при нятому в компании, или в соответствии с простыми соглашениями, изложенными в главе 7. Результатом этой деятельности является набор классов анализа, в ко тором у каждого класса может быть несколько ключевых атрибутов и должно быть от трех до пяти обязанностей. Это аналитическая мо дель в первом приближении. 8.6. Что мы узнали В этой главе мы описали, что такое классы анализа, и рассмотрели ме тоды поиска таких классов с помощью анализа существительное/гла гол, мозгового штурма CRC, применения стереотипов RUP и проверки других источников классов. Вы узнали следующее: • В результате UP деятельности Анализ прецедентов получаем классы анализа и реализации прецедентов. • Классы анализа представляют четкую, точно определенную абст ракцию предметной области. • Предметная область – это область, в которой возникла необходи мость в программной системе. • Классы анализа должны точно и четко проецироваться в реаль ное бизнес понятие. • Бизнес понятия часто нуждаются в уточнении во время анализа. • Аналитическая модель содержит только классы анализа – любые классы, вытекающие из соображений проектирования (области ре шения), должны быть исключены. • Классы анализа включают: • высокоуровневый набор предполагаемых атрибутов; • высокоуровневый набор операций. • Каковы признаки хорошего класса анализа? • Имя класса отражает его назначение. • Класс является четкой абстракцией, которая моделирует один конкретный элемент предметной области. • Класс проецируется в четко идентифицируемую возможность предметной области. • У класса анализа небольшой, определенный набор обязанностей: • обязанность – это контракт или обязательство, которое класс имеет перед своими клиентами; 8.6. Что мы узнали 197 • обязанность – семантически связный набор операций; • класс должен иметь не более трех пяти обязанностей. • Класс имеет высокую внутреннюю связность (cohesion) – все свойства класса служат реализации его назначения. • Класс имеет низкую связанность с другими классами (coupling) – для реализации своего назначения класс должен взаимодейство вать с небольшим числом классов. • Каковы признаки плохого класса анализа? • Он является функтоидом – классом с одной операцией. • Он является всемогущим классом – классом, делающим все. Классам, в именах которых присутствуют слова «system» или «controller», следует уделять больше внимания. • У него глубокое дерево наследования – в реальности деревья на следования, как правило, небольшие. • У него низкая внутренняя связность. • У него высокая связанность с другими классами. • Анализ существительное/глагол: • Ищите существительные или именные группы; это потенциаль ные классы или атрибуты. • Ищите глаголы или глагольные группы; это потенциальные обя занности или операции. • Процедура: собрать относящуюся к делу информацию и проана лизировать ее. • CRC анализ – мощная и одновременно забавная техника мозгового штурма. • Важные моменты предметной области записываются на клея щихся записках (стикерах). • Каждая записка разделена на три ячейки: • класс – содержит имя класса; • обязанности – содержит список обязанностей этого класса; • участники – содержит список других классов, с которыми взаимодействует данный класс. • Процедура CRC анализа – мозговой штурм: • попросите членов команды назвать «сущности», которые дей ствуют в их области деятельности, и запишите их на клея щихся записках; • попросите команду обозначить обязанности сущностей и за пишите их в ячейке обязанностей на записке; • попросите команду определить классы, которые могли бы ра ботать совместно, и запишите их в ячейке участников каждой 198 Глава 8. Выявление классов анализа записки; если стикеры приклеены на доску, нарисуйте между ними линии. • Стереотипы RUP могут использоваться с целью сосредоточить ана лиз на трех типах классов: • «boundary» – класс, играющий роль посредника во взаимодейст вии системы и ее окружения; • «control» – класс, инкапсулирующий характерное поведение пре цедента; • «entity» – класс, используемый для моделирования постоянной информации о чем то. • Учтите другие источники классов: • физические объекты, документооборот, интерфейсы с внешним миром и концептуальные сущности; • базовые шаблоны – ориентированное на компоненты моделиро вание. • Создание аналитической модели в первом приближении: • сравниваются результаты анализа существительное/глагол, CRC анализа, применения стереотипов RUP и проверки других источников классов; • разрешаются синонимы и омонимы; • отличия результатов разных техник указывают на области неоп ределенности; • результаты объединяются в аналитическую модель в первом приближении. 9 Отношения 9.1. План главы В этой главе рассматриваются отношения между объектами и между классами. Чтобы понять, что такое отношение, прочтите раздел 9.2. Далее обсуждаются: в разделе 9.3 – связи (отношения между объекта ми), в разделе 9.4 – ассоциации (отношения между классами) и в раз деле 9.5 – зависимости (универсальные отношения). 9.2. Что такое отношение? Отношения – это семантические (значимые) связи между элементами модели. Отношения – это способ объединения сущностей в UML. Нам уже встречались некоторые типы отношений: • между актерами и прецедентами (ассоциация); • между прецедентами и прецедентами (обобщение, «include», «ex tend»); • между актерами и актерами (обобщение). UML отношения объединяют сущности. В этой главе рассматриваются взаимоотношения между объектами и между классами. Начнем со связей и ассоциаций, а в главе 10 обсу дим обобщение и наследование. Чтобы создать функциональную ОО систему, нельзя позволять объек там оставаться в гордом одиночестве. Их необходимо объединять, что бы они могли выполнять полезную для пользователей системы работу. Соединения между объектами называются связями. Когда объекты работают совместно, говорят, что они взаимодействуют. 200 Глава 9. Отношения 9.5.2.4. «derive» 9.2. Что такое отношение? 9.6. Что мы узнали 9.3. Что такое связь? 9.4. Что такое ассоциация? 9.5. Что такое зависимость? 9.3.1. Диаграммы объектов 9.3.2. Пути 9.4.1. Синтаксис ассоциации 9.4.3. Возможность навигации 9.4.2. Кратность 9.4.5. Классы ассоциации 9.4.2.1. Рефлексивные ассоциации 9.4.4. Ассоциации и атрибуты 9.4.2.2. Иерархии и сети 9.4.6. Квалифицированные ассоциации 9.5.1. Зависимости использования 9.5.2. Зависимости абстракции 9.5.3. Зависимости доступа 9.5.1.1. «use» 9.5.2.1. «trace» 9.5.3.1. «access» 9.5.1.2. «call» 9.5.2.2. «substitute» 9.5.3.2. «import» 9.5.1.3. «parameter» 9.5.2.3. «refi n e» 9.5.3.3. «permit» 9.5.1.4. «se n d» 9.5.1.5. «i n sta n tiate» Рис. 9.1. П л ан гл ав ы 9.3. Что такое связь? 201 Если между объектами установлена связь, то и между их классами должно существовать какое то семантическое соединение. В этом есть здравый смысл: чтобы объекты могли общаться друг с другом напря мую, классы этих объектов должны каким то образом знать друг о друге. Соединения между классами называются ассоциациями. Свя зи между объектами на самом деле являются экземплярами ассоциа ций между их классами. 9.3. Что такое связь? Чтобы создать объектно ориентированную программу, объекты долж ны общаться друг с другом. В сущности, исполняющаяся ОО програм ма – это гармоничное сообщество взаимодействующих объектов. Объекты обмениваются сообщениями через соединения, называемые связями. Связь – это семантическое соединение между двумя объектами, кото рое обеспечивает им возможность обмена сообщениями. Исполняю щаяся ОО система содержит множество объектов, которые появляют ся и исчезают, и множество связей (которые тоже появляются и исче зают), объединяющих эти объекты. Через эти связи происходит обмен сообщениями между объектами. Получив сообщение, объект иниции рует соответствующую операцию. Разные ОО языки программирования реализуют связи по разному. Java реализует связи как объектные ссылки; C++ может реализовывать связи как указатели, как ссылки или путем прямого включения одно го объекта в другой. Каким бы ни был подход, минимальное требование для установления связи: по крайней мере один из объектов должен иметь объектную ссылку на другой. 9.3.1. Диаграммы объектов Диаграмма объектов – это диаграмма, представляющая объекты и их отношения в некоторый момент времени. Это как снимок части испол няющейся ОО системы в определенный момент, показывающий объ екты и связи между ними. Соединенные связями объекты могут исполнять различные роли по от ношению друг к другу. На рис. 9.2 можно видеть, что объект ila играет роль chairperson (председатель) в его связи с объектом bookClub (книж ный клуб). На диаграмме объектов это отображается путем размеще ния имени роли на соответствующем конце связи. Имена ролей могут располагаться на любом или на обоих концах связи. В данном случае объект bookClub всегда играет роль «клуба», поэтому нет особого смысла 202 Глава 9. Отношения показывать это на диаграмме. Это никак не улучшило бы понимания отношений объектов. На рис. 9.2 показано, что в определенный момент времени объект ila играет роль chairperson. Однако важно понимать, что связи – это дина мические соединения (dynamic connections) объектов. Иначе говоря, они могут быть непостоянными во времени. В данном примере роль chairperson может передаваться объектам erica или naomi, и можно было бы без труда создать диаграмму объектов, отображающую эту новую ситуацию. Обычно одна связь соединяет только два объекта, как показано на рис. 9.2. Однако UML допускает соединение нескольких объектов од ной связью. Такую связь называют n арной. Она изображается в виде ромба, от которого отходят линии к каждому из объектов участников. Многие разработчики моделей (и мы в том числе) считают такую идио му ненужной. Она редко используется и не всегда поддерживается средствами моделирования UML. Поэтому не будем ее рассматривать. Диаграммы объектов – это моментальные снимки работающей ОО сис темы. На рис. 9.2 можно найти три связи между четырьмя объектами: |