UML2 и унифицированный процесс. Джим арлоуайла нейштадтпрактический объектно ориентированныйанализ и проектированиеu
 Скачать 6.08 Mb.
|
|
• Состояние образуют наборы только таких значений атрибу тов и отношений, которые обуславливают существенное се мантическое отличие от других возможных наборов. Напри мер, объект BankAccount: balance < 0, state = Overdrawn; balance > 0, state = InCredit. • Переход состояний – перемещение объекта из одного значи мого состояния в другое. • Поведение – сервисы, предлагаемые объектом другим объектам: • моделируется в виде набора операций; • вызов операции может генерировать переход состояния. • Совместная работа объектов генерирует поведение системы. • Взаимодействие включает в себя обмен сообщениями между объ ектами – при получении сообщения инициируется соответству ющая операция; это может привести к переходу состояний. • Нотация объектов в UML – в каждой пиктограмме объекта две ячейки. • В верхней ячейке находится имя объекта и/или имя класса, и то и другое должно быть подчеркнуто. • Имена объектов записываются в стиле lowerCamelCase. • Имена классов записываются в стиле UpperCamelCase. • Никаких специальных символов, знаков препинания или со кращений. • Имя объекта отделяется от имени класса одним двоеточием. • Нижняя ячейка содержит имена и значения атрибутов, разде ляемые знаком равенства. • Имена атрибутов записываются в стиле lowerCamelCase. • Типы атрибутов могут быть представлены, но обычно для крат кости их опускают. • Класс определяет характеристики (атрибуты, операции, отноше ния и поведение) ряда объектов. • Каждый объект – это экземпляр только одного класса. • Разные объекты одного класса имеют одинаковый набор атрибу тов, но значения этих атрибутов могут быть разными. Разные значения атрибутов обусловливают разное поведение объектов одного класса. Например, сравните попытку снять $100 с объек 176 Глава 7. Объекты и классы та BankAccount, кредит которого превышен, с попыткой снять $100 с объекта BankAccount, на котором есть $200 кредита. • Существует множество классификаций мира. Правильный вы бор схемы классификации – один из ключей к успешному ОО анализу. • Отношение создания экземпляра между классом и одним из его объектов можно показать с помощью зависимости, обозначен ной стереотипом «instantiate»: • отношения объединяют сущности; • отношение зависимости показывает, что изменение сущно сти поставщика оказывает влияние на сущность клиент. • При создании экземпляра с использованием класса в качестве шаблона создается новый объект. • Большинство ОО языков программирования предоставляют специальные операции, конструкторы, которые вызываются, когда необходимо создать объект – конструкторы создают или инициализируют объекты; область действия конструкто ров – класс (они принадлежат классу). • Некоторые ОО языки программирования предоставляют спе циальные операции, деструкторы, которые вызываются при уничтожении объекта – деструкторы «наводят порядок» по сле уничтожения объектов. • Нотация классов в UML: • В ячейке имени размещается имя класса, записанное в стиле UpperCamelCase: • никаких сокращений, знаков препинания или специальных символов. • Ячейка атрибутов – у каждого атрибута есть: • видимость – управляет доступом к характеристикам класса; • имя (обязательно) – записывается в стиле lowerCamelCase; • кратность – коллекции, например [10]; неопределенные зна чения, например [0..1]; • тип; • у атрибутов могут быть стереотипы и помеченные значения. • Ячейка операций – у каждой операции может быть: • видимость; • имя (обязательно) – записывается в стиле lowerCamelCase; • список параметров (имя и тип каждого параметра); • у параметра может быть применяемое по умолчанию зна чение (не обязательно); 7.8. Что мы узнали 177 • у параметра может быть направление (не обязательно): in, out, inout, return. • возвращаемый тип; • стереотип; • помеченные значения. • В операциях запроса атрибут isQuery = true – эти операции не ока зывают побочного действия. • Сигнатура операции включает: • имя; • список параметров (типы всех параметров); • возвращаемый тип. • Сигнатура каждой операции или метода класса должна быть уникальной. • Область действия. • Атрибуты и операции, область действия которых – экземпляр, принадлежат или выполняются в конкретных объектах: • операции уровня экземпляра имеют доступ к другим опера циям или атрибутам уровня экземпляра; • операции уровня экземпляра имеют доступ ко всем атрибу там или операциям уровня класса. • Атрибуты и операции, область действия которых – класс, при надлежат или выполняются во всех объектах класса: • атрибуты и операции уровня класса имеют доступ только к операциям уровня класса. 8 Выявление классов анализа 8.1. План главы Эта глава посвящена основной деятельности ОО анализа – выявлению классов анализа. В разделе 8.2 описывается деятельность UP по выяв лению классов анализа. Из раздела 8.3 можно узнать, что такое класс анализа. В разделе 8.4 обсуждается, как выявлять классы анализа. Представле ны три метода: анализ существительное/глагол (8.4.1), анализ CRC (8.4.2) и RUP стереотипы классов анализа (8.4.3). В подразделе 8.4.4 рассмотрены в общих чертах другие возможные источники классов. 8.2. Деятельность UP: Анализ прецедента Результатом рабочего потока UP Анализ прецедента (рис. 8.2) являются классы анализа и реализации прецедентов. В этой главе основное вни мание сосредоточено на классах анализа. Реализации прецедентов (глава 12) – это кооперации объектов, показывающие, как системы вза имодействующих объектов могут реализовывать поведение системы, описанное в прецеденте. Рассмотрим входные данные Анализа прецедента. Деятельность UP «Анализ прецедента» включает создание классов ана лиза и реализации прецедентов. • Бизнес модель – в распоряжении разработчиков модели может быть (а может и не быть) бизнес модель моделируемой системы. Если она уже есть, это превосходный источник требований. • Модель требований – процесс создания этой модели описан в главе 3. Требования (этот артефакт затушеван, чтобы показать изменение по сравнению с исходным рисунком) обеспечивают полезные вход 8.2. Деятельность UP: Анализ прецедента 179 изучаем источники классов 8.4.1. Выявление классов с помощью анализа существительное/глагол 8.2. Деятельность UP: Анализ прецедента 8.3. Что такое классы анализа? 8.3.1. Анатомия класса анализа 8.3.2. Каковы признаки хорошего класса анализа? 8.3.3. Практические правила создания классов анализа 8.4.2. Выявление классов с помощью CRCанализа 8.4. Выявление классов 8.4.3. Выявление классов путем применения стереотипов RUP 8.4.4. Выявление классов из других источников 8.4.2.1. Процедура CRCанализа 8.4.1.1. Процедура анализа существительное/глагол 8.4.3.1. Выявление классов типа «bo u ndary» 8.4.3.2. Выявление классов типа «control» 8.4.2.2. Этап 1: мозговая атака – сбор информации 8.4.4.1. Базовые шаблоны 8.4.2.3. Этап 2: анализ информации 8.5. Создание аналитической модели в первом приближении 8.6. Что мы узнали 8.4.3.3. Выявление классов типа «entity» изучаем деятельность UP изучаем классы анализа учимся находить классы в документации учимся выявлять классы путем мозговой атаки учимся выявлять классы с помощью стереотипов RU P else else Ри с. 8 .1. Пл ан гл ав ы 180 Глава 8. Выявление классов анализа ные данные для процесса моделирования прецедентов. В частности, функциональные требования предложат прецеденты и актеров, а не функциональные требования – то, что, возможно, надо иметь в виду при создании модели прецедентов. • Модель прецедентов – создание модели прецедентов обсуждалось в гла вах 4 и 5. • Описание архитектуры – представление важных с архитектурной точ ки зрения аспектов системы. Может включать фрагменты UML мо делей, вставленные в пояснительный текст. Создается архитекто рами на основании данных, полученных от аналитиков или проек тировщиков. 8.3. Что такое классы анализа? Классы анализа моделируют важные аспекты предметной области, та кие как «покупатель» или «продукт». Классы анализа – это классы, которые: • представляют четкую абстракцию предметной области (problem do main); • должны проецироваться на реальные бизнес понятия (и быть акку ратно поименованы соответственно этим понятиям). Разработчик прецедентов Анализ прецедента Описание архитектуры Класс анализа Реализация прецедента Модель прецедентов Бизнес модель [или модель предметной области] Модель требований Рис. 8.2. Деятельность UP: Анализ прецедента. Адаптировано с рис. 8.25 [Jacobson 1] с разрешения издательства Addison Wesley 8.3. Что такое классы анализа? 181 Предметная область – это область, в которой возникает необходимость в программной системе (и, следовательно, в деятельности по разработ ке программного обеспечения). Обычно это определенная область де ловой активности, например сетевая торговля или управление взаимо отношениями с клиентами. Однако важно отметить, что предметная область может вообще не быть деловой активностью, а являться след ствием существования физического оборудования, для которого необ ходимо программное обеспечение. В конечном счете, вся разработка коммерческого программного обеспечения служит некоторой при кладной цели, будь то автоматизация существующего бизнес процесса или разработка нового продукта, имеющего существенную программ ную составляющую. Класс анализа должен четко и однозначно проецироваться в реальное прикладное понятие. Самое важное свойство класса анализа – он должен четко и однознач но проецироваться в некоторое реальное прикладное понятие, напри мер покупатель, продукт или счет. Это предполагает четкость и одно значность самих бизнес понятий, что является большой редкостью. Следовательно, задача ОО аналитика – попытаться прояснить беспо рядочные или несоответствующие прикладные понятия и превратить их в то, что может стать основой для класса анализа. Вот в чем слож ность ОО анализа. Итак, первый шаг в построении ОО программного обеспечения – прояс нить предметную область. Если она содержит четко определенные биз нес понятия и имеет простую функциональную структуру, решение практически лежит на поверхности. Большая часть этой работы осуще ствляется в рабочем потоке определения требований в деятельностях по выявлению требований и созданию модели прецедентов и глоссария проекта. Однако намного большая ясность вносится при построении классов анализа и реализации прецедентов. Важно, чтобы все классы аналитической модели являлись классами анализа, а не классами, вытекающими из проектных соображений (об ласти решения). Когда дело дойдет до детального проекта, может слу читься так, что классы анализа будут в конце концов переработаны в один или более проектных классов. Правильное выявление классов анализа – ключ к ОО анализу и проекти рованию. В предыдущей главе мы поневоле начинали с рассмотрения конкретных объектов. Теперь вы поймете, что подлинная цель ОО анализа – выявле ние классов этих объектов. По сути, правильное выявление классов анализа – ключ к ОО анализу и проектированию. Если при анализе классы определены неверно, то и весь процесс производства программ 182 Глава 8. Выявление классов анализа ного обеспечения, основывающийся на рабочих потоках определения требований и анализа, окажется под угрозой. Поэтому критически важно уделить анализу достаточное количество времени, чтобы быть уверенными в правильности определения классов анализа. И это вре мя будет потрачено не зря, поскольку практически наверняка оно сэкономит время в дальнейшем. В этой книге основное внимание уделяется разработке бизнес систем, поскольку именно этим занимается большинство ОО аналитиков и про ектировщиков. Но разработка встроенных систем – лишь особый слу чай разработки обычной бизнес системы, поэтому к ней применимы те же основные принципы. В бизнес системах обычно доминируют функ циональные требования, поэтому самым сложным здесь является оп ределение требований и анализ. Во встроенных системах, как прави ло, доминируют нефункциональные требования, вытекающие из ап паратных средств, в которые встраивается система. В этом случае ана лиз довольно прост, тогда как проектирование может быть довольно сложным. Требования важны для всех типов систем, а для некоторых встроенных систем, таких как устройства управления рентгеновски ми аппаратами, они могут стать вопросом жизни и смерти. 8.3.1. Анатомия класса анализа Классы анализа должны представлять «высокоуровневый» набор атри бутов. Они указывают атрибуты, которые, возможно, будут присутст вовать в проектных классах. Можно сказать, что классы анализа вклю чают предполагаемые атрибуты проектных классов. В классах анализа содержатся только ключевые атрибуты и обязанно сти, определенные на очень высоком уровне абстракции. Операции классов анализа определяют на высоком уровне абстрак ции, ключевые сервисы, которые должен предлагать класс. В проекте они станут реальными операциями. Однако одна операция уровня ана лиза очень часто разбивается на несколько операций уровня проекта. Синтаксис UML уже подробно обсуждался в главе 7. В анализе реаль но используется лишь небольшая его часть. Конечно, аналитик всегда волен добавить любые необходимые, по его мнению, дополнения, что бы сделать модель более понятной. Однако базовый синтаксис класса анализа всегда избегает деталей реализации. В конце концов, при ана лизе создается общее представление. Минимальная форма класса анализа включает следующее? • Имя – обязательно. • Атрибуты – имена атрибутов являются обязательными, хотя на дан ном этапе могут моделироваться только важные предполагаемые атрибуты. Типы атрибутов считаются необязательными. 8.3. Что такое классы анализа? 183 • Операции – в анализе операции могут быть всего лишь очень при близительными формулировками обязанностей класса. Параметры и возвращаемые типы операций приводятся только в том случае, если они важны для понимания модели. • Видимость – обычно не указывается. • Стереотипы – могут указываться, если это приводит к улучшению модели. • Помеченные значения – могут указываться, если это улучшает мо дель. Пример класса анализа приведен на рис. 8.3. Основное назначение класса анализа состоит в том, что в нем делается попытка уловить суть абстракции, а детали реализации оставляют на этап проектирования. 8.3.2. Каковы признаки хорошего класса анализа? Признаки хорошего класса анализа можно кратко охарактеризовать следующим образом: • его имя отражает его назначение; • он является четкой абстракцией, моделирующей один конкретный элемент предметной области; • он проецируется на четко определяемую возможность предметной области; • у него небольшой четко определенный набор обязанностей; • у него высокая внутренняя связность (cohesion); • у него низкая связанность с другими классами (coupling). Имя класса анализа должно отражать его назначение. При анализе делается попытка точно и лаконично смоделировать один аспект предметной области с точки зрения создаваемой системы. На пример, при моделировании клиента банковской системы необходимо записать его имя, адрес и т. д. При этом вряд ли представляет интерес withdraw() calculateInterest() deposit() BankAccount accountNumber owner balance операции атрибуты имя класса Рис. 8.3. Пример класса анализа 184 Глава 8. Выявление классов анализа информация о том, предпочитает ли он сидеть в самолете у окна или в проходе. Необходимо сосредоточиться на важных с точки зрения строящейся системы аспектах реальных сущностей. Нередко составить первое впечатление о том, «хорош» класс или нет, можно уже по его имени. В системе электронной коммерции вполне понятно, какую реальную сущность может обозначать имя Customer; оно является хорошей кандидатурой для имени класса. ShoppingBasket также могло бы быть хорошей абстракцией, мы практически интуи тивно понимаем его семантику. Однако семантика такого имени, как WebSiteVisitor (посетитель веб сайта), кажется неопределенной и по сути напоминает роль, выполняемую Customer по отношению к системе элек тронной коммерции. Необходимо всегда искать «четкую абстракцию» – что то, что имеет ясную и очевидную семантику. Обязанности описывают связный набор операций. Обязанность – это контракт или обязательство класса по отношению к его клиентам. По существу, обязанность – это сервис, который класс предлагает другим классам. Очень важно, чтобы классы анализа име ли связный набор обязанностей, абсолютно соответствующих назначе нию класса (которое выражено в его имени) и реальной «сущности», моделируемой классом. Возвращаясь к примеру ShoppingBasket, можно ожидать, что этот класс будет иметь следующие обязанности: • добавить позицию в корзину; • удалить позицию из корзины; • показать позиции, находящиеся в корзине. Это связный набор обязанностей, обслуживающий коллекцию товар ных позиций, выбранных покупателем. Он является связным, потому что все обязанности направлены на реализацию одной цели – обслу живание корзины для покупок клиента. На очень высоком уровне аб стракции эти три обязанности можно представить как обязанность «обслужить корзину». Теперь в класс ShoppingBasket можно было бы добавить следующие обя занности: |