Арлоу Д., Нейштадт А. UML2 и Унифицированный процесс. Практический объектно-ориентированный анализ и проектирование
Подождите немного. Документ загружается.
174 Глава 7. Объекты и классы
Что происходит, если программа создает и уничтожает объекты Club
Member? Очевидно, что значение атрибута numberOfMembers быстро поте
ряет смысл. Исправить эту ситуацию можно, введя в класс операцию
для уменьшения значения атрибута numberOfMembers (рис. 7.17) и обес
печив ее вызов при каждом уничтожении экземпляра класса ClubMember.
В некоторых ОО языках программирования есть специальные опера
ции уровня экземпляра, называемые деструкторами, которые автома
тически вызываются в момент уничтожения объекта. Например, в С++
деструктор всегда имеет форму ~ИмяКласса (списокПараметров). В С++
операция уничтожения гарантированно вызывается в момент уничто
жения объекта.
В Java есть аналогичная возможность: каждый класс имеет операцию
под названием finalize(), которая вызывается при окончательном унич
тожении объекта. Но сама программа явно не уничтожает объекты.
Этим занимается автоматический сборщик мусора. Вам известно, что
finalize() будет вызван, но вы не знаете, когда это произойдет! Конечно,
это не подходит для нашего простого приложения со счетчиком. Здесь
приходится самостоятельно уменьшать значение атрибута number
OfMembers, вызывая операцию уровня класса decrementNumberOfMem
bers(), когда работа с объектом завершена и он отправляется в сборщик
мусора.
C# имеет аналогичную Java семантику уничтожения, только опера
ция называется Finalize().
7.8. Что мы узнали
В этой главе были представлены основные сведения по классам и объ
ектам, которые используются далее в книге. Классы и объекты – это
строительные блоки ОО систем, поэтому важно всесторонне и детально
их понимать.
Мы узнали следующее:
• Объекты – это образующие единое целое элементы, сочетающие в се
бе данные и функции.
• Инкапсуляция – данные, находящиеся внутри объекта, скрыты.
Манипулировать ими можно, только инициируя одну из функций
объекта.
• Операции – это спецификации функций объекта, создаваемые
во время анализа.
• Методы – это реализации функций объекта, создаваемые во вре
мя реализации.
• Каждый объект – это экземпляр класса. Класс определяет общие
характеристики, присущие всем объектам этого класса.
7.8. Что мы узнали 175
• У каждого объекта есть следующие характеристики:
• Идентичность – уникальность существующего объекта: вы ис
пользуете объектные ссылки для однозначного указания на кон
кретный объект.
• Состояние – значимый набор значений атрибутов и отношений
объекта в определенный момент времени.
• Состояние образуют наборы только таких значений атрибу
тов и отношений, которые обуславливают существенное се
мантическое отличие от других возможных наборов. Напри
мер, объект 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. Выявление классов
с помощью CRCQанализа
8.4. Выявление классов
8.4.3. Выявление классов путем
применения стереотипов RUP
8.4.4. Выявление классов
из других источников
8.4.2.1. Процедура CRCQанализа
8.4.1.1. Процедура анализа
существительное/глагол
8.4.3.1. Выявление классов типа «boundary»
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
изучаем классы анализа
учимся находить классы в документации учимся выявлять классы путем мозговой атаки учимся выявлять классы с помощью стереотипов RUP
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. Пример класса анализа