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

8.2) являютсяклассы анализа и реализации прецедентов. В этой главе основное внимание сосредоточено на классах анализа. Реализации прецедентов(глава 12) – это кооперации объектов, показывающие, как системы взаимодействующих объектов могут реализовывать поведение системы,описанное в прецеденте.Рассмотрим входные данные Анализа прецедента.Деятельность UP «Анализ прецедента» включает создание классов анализа и реализации прецедентов.••Бизнесмодель – в распоряжении разработчиков модели может быть(а может и не быть) бизнесмодель моделируемой системы. Если онауже есть, это превосходный источник требований.Модель требований – процесс создания этой модели описан в главе 3.Требования (этот артефакт затушеван, чтобы показать изменениепо сравнению с исходным рисунком) обеспечивают полезные вход8.3.1. Анатомия класса анализа8.3.

Что такое классы анализа?8.2. Деятельность UP: Анализ прецедента8.4.3.2. Выявление классов типа «control»8.4.3.3. Выявление классов типа «entity»8.4.2.2. Этап 1: мозговая атака – сбор информации8.4.2.3. Этап 2: анализ информацииРис. 8.1. План главы8.4.3.1. Выявление классов типа «boundary»8.4.2.1. Процедура CRCQанализа8.4.1.1. Процедура анализасуществительное/глагол8.6. Что мы узнали8.5. Создание аналитической модели в первом приближении8.4.3. Выявление классов путемприменения стереотипов RUP8.4.2.

Выявление классовс помощью CRCQанализа8.4.1. Выявление классов с помощьюанализа существительное/глаголучимся выявлять классы с помощью стереотипов RUPучимся выявлять классы путем мозговой атакиучимся находить классы в документации8.4.4.1. Базовые шаблоны8.4.4. Выявление классовиз других источниковизучаем источники классов8.3.3. Практические правила создания классов анализа8.3.2. Каковы признаки хорошего класса анализа?изучаем классы анализаизучаем деятельность UP8.4. Выявление классовelseelse8.2. Деятельность UP: Анализ прецедента179180Глава 8. Выявление классов анализаБизнес!модель[или модель предметной области]Разработчик прецедентовКласс анализаМодель требованийАнализ прецедентаМодель прецедентовРеализация прецедентаОписание архитектурыРис. 8.2.

Деятельность UP: Анализ прецедента. Адаптировано с рис. 8.25[Jacobson 1] с разрешения издательства Addison+Wesley••ные данные для процесса моделирования прецедентов. В частности,функциональные требования предложат прецеденты и актеров, а нефункциональные требования – то, что, возможно, надо иметь в видупри создании модели прецедентов.Модель прецедентов – создание модели прецедентов обсуждалось в главах 4 и 5.Описание архитектуры – представление важных с архитектурной точки зрения аспектов системы.

Может включать фрагменты UMLмоделей, вставленные в пояснительный текст. Создается архитекторами на основании данных, полученных от аналитиков или проектировщиков.8.3. Что такое классы анализа?Классы анализа моделируют важные аспекты предметной области, такие как «покупатель» или «продукт».Классы анализа – это классы, которые:• представляют четкую абстракцию предметной области (problem domain);• должны проецироваться на реальные бизнеспонятия (и быть аккуратно поименованы соответственно этим понятиям).8.3.

Что такое классы анализа?181Предметная область – это область, в которой возникает необходимостьв программной системе (и, следовательно, в деятельности по разработке программного обеспечения). Обычно это определенная область деловой активности, например сетевая торговля или управление взаимоотношениями с клиентами. Однако важно отметить, что предметнаяобласть может вообще не быть деловой активностью, а являться следствием существования физического оборудования, для которого необходимо программное обеспечение. В конечном счете, вся разработкакоммерческого программного обеспечения служит некоторой прикладной цели, будь то автоматизация существующего бизнеспроцессаили разработка нового продукта, имеющего существенную программную составляющую.Класс анализа должен четко и однозначно проецироваться в реальноеприкладное понятие.Самое важное свойство класса анализа – он должен четко и однозначно проецироваться в некоторое реальное прикладное понятие, например покупатель, продукт или счет.

Это предполагает четкость и однозначность самих бизнеспонятий, что является большой редкостью.Следовательно, задача ОО аналитика – попытаться прояснить беспорядочные или несоответствующие прикладные понятия и превратитьих в то, что может стать основой для класса анализа. Вот в чем сложность ОО анализа.Итак, первый шаг в построении ОО программного обеспечения – прояснить предметную область.

Если она содержит четко определенные бизнеспонятия и имеет простую функциональную структуру, решениепрактически лежит на поверхности. Большая часть этой работы осуществляется в рабочем потоке определения требований в деятельностяхпо выявлению требований и созданию модели прецедентов и глоссарияпроекта. Однако намного большая ясность вносится при построенииклассов анализа и реализации прецедентов.Важно, чтобы все классы аналитической модели являлись классамианализа, а не классами, вытекающими из проектных соображений (области решения). Когда дело дойдет до детального проекта, может случиться так, что классы анализа будут в конце концов переработаныв один или более проектных классов.Правильное выявление классов анализа – ключ к ОО анализу и проектированию.В предыдущей главе мы поневоле начинали с рассмотрения конкретныхобъектов.

Теперь вы поймете, что подлинная цель ОО анализа – выявление классов этих объектов. По сути, правильное выявление классованализа – ключ к ОО анализу и проектированию. Если при анализеклассы определены неверно, то и весь процесс производства программ182Глава 8. Выявление классов анализаного обеспечения, основывающийся на рабочих потоках определениятребований и анализа, окажется под угрозой. Поэтому критическиважно уделить анализу достаточное количество времени, чтобы бытьуверенными в правильности определения классов анализа.

И это время будет потрачено не зря, поскольку практически наверняка оносэкономит время в дальнейшем.В этой книге основное внимание уделяется разработке бизнессистем,поскольку именно этим занимается большинство ОО аналитиков и проектировщиков. Но разработка встроенных систем – лишь особый случай разработки обычной бизнессистемы, поэтому к ней применимы теже основные принципы. В бизнессистемах обычно доминируют функциональные требования, поэтому самым сложным здесь является определение требований и анализ. Во встроенных системах, как правило, доминируют нефункциональные требования, вытекающие из аппаратных средств, в которые встраивается система.

В этом случае анализ довольно прост, тогда как проектирование может быть довольносложным. Требования важны для всех типов систем, а для некоторыхвстроенных систем, таких как устройства управления рентгеновскими аппаратами, они могут стать вопросом жизни и смерти.8.3.1. Анатомия класса анализаКлассы анализа должны представлять «высокоуровневый» набор атрибутов. Они указывают атрибуты, которые, возможно, будут присутствовать в проектных классах.

Можно сказать, что классы анализа включают предполагаемые атрибуты проектных классов.В классах анализа содержатся только ключевые атрибуты и обязанности, определенные на очень высоком уровне абстракции.Операции классов анализа определяют на высоком уровне абстракции, ключевые сервисы, которые должен предлагать класс. В проектеони станут реальными операциями. Однако одна операция уровня анализа очень часто разбивается на несколько операций уровня проекта.Синтаксис UML уже подробно обсуждался в главе 7. В анализе реально используется лишь небольшая его часть.

Конечно, аналитик всегдаволен добавить любые необходимые, по его мнению, дополнения, чтобы сделать модель более понятной. Однако базовый синтаксис классаанализа всегда избегает деталей реализации. В конце концов, при анализе создается общее представление.Минимальная форма класса анализа включает следующее?•Имя – обязательно.•Атрибуты – имена атрибутов являются обязательными, хотя на данном этапе могут моделироваться только важные предполагаемыеатрибуты. Типы атрибутов считаются необязательными.8.3. Что такое классы анализа?имя класса183BankAccountатрибутыaccountNumberownerbalanceоперацииwithdraw()calculateInterest()deposit()Рис. 8.3. Пример класса анализа••Операции – в анализе операции могут быть всего лишь очень приблизительными формулировками обязанностей класса.

Параметрыи возвращаемые типы операций приводятся только в том случае,если они важны для понимания модели.Видимость – обычно не указывается.•Стереотипы – могут указываться, если это приводит к улучшениюмодели.•Помеченные значения – могут указываться, если это улучшает модель.Пример класса анализа приведен на рис. 8.3.Основное назначение класса анализа состоит в том, что в нем делаетсяпопытка уловить суть абстракции, а детали реализации оставляют наэтап проектирования.8.3.2.