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

Подождите немного. Документ загружается.

144 Глава 6. Рабочий поток анализа

нять их, необходимо рассмотреть классы и объекты. Они будут обсуж

даться в главе 7.

6.5. Аналитическая модель – практические

правила

Все системы разные, поэтому сложно найти универсальный подход

к созданию аналитических моделей. Тем не менее аналитическая мо

дель системы среднего размера и сложности включает от 50 до 100 клас

сов анализа. Необходимо запомнить, что при создании аналитической

модели крайне важно ограничиться лишь теми классами, которые яв

ляются частью словаря предметной области. Всегда есть искушение по

местить в аналитическую модель и проектные классы (такие как клас

сы, используемые для установления соединений или доступа к базе дан

ных), но этого необходимо избегать (если только предметная область не

касается связи или баз данных)! Такое ограничение накладывается

в попытке сделать аналитическую модель кратким, простым описани

ем структуры и поведения системы. Все решения по реализации долж

ны приниматься в рабочих потоках проектирования и реализации.

Вот некоторые практические приемы создания хорошей аналитиче

ской модели:

• Аналитическая модель всегда создается на языке соответствующей

сферы деятельности. Абстракции аналитической модели должны

формировать часть словаря бизнессферы.

• Создаваемые модели должны «рассказывать историю». Каждая

диаграмма должна раскрывать некоторые важные части поведения

системы. Иначе зачем они нужны? Как создавать такие диаграм

мы, будет показано при рассмотрении реализации прецедентов.

Архитектурный анализ

Анализ прецедента

Анализ класса

Разработчик компонентов

Архитектор

Разработчик прецедентов

Анализ пакета

Рис. 6.4. Рабочий поток анализа в UP. Воспроизведено с рис. 8.18 [Jacobson 1]

с разрешения издательства Addison+Wesley

6.6. Что мы узнали 145

• Необходимо сосредоточиться на отображении основной картины.

Не надо углубляться в детали того, как будет работать система. Для

этого отводится достаточно времени при проектировании.

• Необходимо четко различать предметную область (бизнестребова

ния) и область решения (детальные конструктивные соображения).

Основное внимание всегда должно быть направлено на абстракции

предметной области. Например, при моделировании системы элек

тронной торговли в аналитической модели должны присутствовать

классы Customer (клиент), Order (заказ) и ShoppingBasket (корзина по

купок). Здесь не должно быть классов доступа к базе данных или

классов для установления соединений, поскольку они – артефакты

области решения.

• Всегда необходимо стремиться минимизировать связанность (coup

ling). Каждая ассоциация между классами увеличивает их связан

ность. В главе 9 будет показано, как можно максимально сократить

связанность с помощью кратностей и навигации по ассоциациям.

• Если присутствует естественная и очевидная иерархия абстракций,

должна быть рассмотрена возможность применения наследования.

При анализе иерархия никогда не должна применяться просто для

повторного использования кода. Как мы увидим в разделе 17.6, на

следование – самая сильная форма связанности классов.

• Всегда должен задаваться вопрос: «Модель полезна для всех заин

тересованных сторон?» Нет ничего хуже, чем создавать аналити

ческую модель, которая игнорируется пользователями или проек

тировщиками и разработчиками. Пока что это происходит очень

часто, особенно с неопытными аналитиками. Основная превентив

ная стратегия при этом – сделать аналитическую модель и процесс

моделирования максимально открытыми, по возможности при

влечь в него заинтересованные стороны, проводить частые и пуб

личные обзоры.

И наконец, модель должна быть простой! Конечно, легче сказать, чем

сделать, но нам из собственного опыта известно, что внутри любой

сложной аналитической модели можно найти простую. Один из спосо

бов упрощения – рассматривать вопрос в общем, не погружаясь в част

ности.

6.6. Что мы узнали

Мы рассмотрели следующее:

• Анализ заключается в создании моделей, отображающих основные

требования и характеристики целевой системы – аналитическое

моделирование имеет стратегическое значение.

• Основной объем работ рабочего потока анализа выполняется в кон

це фазы Начало и в фазе Уточнение.

146 Глава 6. Рабочий поток анализа

• Рабочие потоки анализа и определения требований пересекаются,

особенно в фазе Уточнение – обычно для выявления неучтенных

или искаженных требований полезно анализировать требования

по мере их обнаружения.

• Аналитическая модель:

• всегда создается на языке соответствующей сферы деятельности;

• отображает картину в целом;

• содержит артефакты, моделирующие предметную область;

• рассказывает историю о целевой системе;

• полезна максимально возможному числу заинтересованных сто

рон.

• Аналитические артефакты – это:

• классы анализа – ключевые понятия бизнессферы;

• реализации прецедентов – иллюстрируют, как экземпляры клас

сов анализа могут взаимодействовать для реализации поведения

системы, описанного прецедентами.

• Рабочий поток анализа в UP включает следующие деятельности:

• Архитектурный анализ

• Анализ прецедента

• Анализ класса

• Анализ пакета

• Аналитическая модель – практические правила:

• аналитическая модель среднестатистической системы состоит

из 50–100 классов анализа;

• включаются только классы, моделирующие словарь предметной

области;

• не формируются решения по реализации;

• основное внимание на классах и ассоциациях – минимизация

связанности между классами;

• наследование применяется там, где присутствует естественная

иерархия абстракций;

• необходимо стремиться к простоте модели!

Объекты и классы

7.1. План главы

Эта глава полностью посвящена объектам и классам. Они – основные

строительные блоки ОО систем. Если читатель уже хорошо знаком с по

нятием объектов и классов, можно пропустить разделы 7.2 и 7.4. Од

нако, вероятно, вам будет интересна информация о UMLнотации объ

ектов (раздел 7.3) и классов (раздел 7.5).

Глава завершается обсуждением смежных вопросов области действия

операций и атрибутов (раздел 7.5), а также вопросов создания и унич

тожения объектов (раздел 7.7).

При анализе используется только часть UMLсинтаксиса класса. НО

чтобы не разбрасывать справочную информацию по всей книге и не

возвращаться к этому позже, в этой главе рассматривается полный

синтаксис класса.

7.2. Что такое объекты?

Книга «UML Reference Manual» [Rumbaugh 1] определяет объект как

«отдельную сущность с явно выраженными границами, которая ин

капсулирует состояние и поведение; экземпляр класса».

Объекты объединяют данные и функциональность в единый блок.

Объект можно представить как единый пакет данных и функциональ

ности. Как правило, единственный путь добраться до данных объекта –

вызвать одну из предоставляемых им функций. Эти функции называ

ются операциями (operations). Сокрытие данных объекта за уровнем

операций известно как инкапсуляция (encapsulation), или сокрытие

данных (datahiding). Инкапсуляция в UML не является обязатель

ной, поскольку некоторые ОО языки не нуждаются в ней. Однако со

148 Глава 7. Объекты и классы

7.7.2. Деструкторы –

пример класса ClubMember

7.2. Что такое объекты?

7.2.1. Инкапсуляция

7.2.2. Обмен сообщениями

7.3. Нотация объектов в UML

7.3.1. Значения атрибутов объектов

7.4. Что такое классы?

7.4.1. Классы и объекты

7.4.2. Создание экземпляров класса

изучаем классы

изучаем объекты

изучаем синтаксис UML!объекта

изучаем создание и уничтожение объектовизучаем синтаксис UML!класса

изучаем процесс

присваивания имен классам

изучаем

атрибуты

изучаем

операции

изучаем

стереотипы

изучаем

область действия

изучаем конструкторы

и деструкторы

7.5. Нотация классов в UML

7.8. Что мы узнали

7.5.2. Ячейка

атрибутов

7.5.2.3. Кратность

7.5.2.4. Начальное значение

7.5.2.5. Расширенный

синтаксис атрибута

7.5.3. Ячейка

операций

7.5.3.1 Направление

параметра

7.5.3.2. Значения параметров

по умолчанию

7.5.3.3. Расширенный

синтаксис операции

7.5.3.4. Операции

запроса

7.5.4. Синтаксис

стереотипа класса

7.6. Область

действия

7.6.1. Область действия класс

и область действия экземпляр

7.6.2. Область действия опреQ

деляет возможность доступа

7.7. Создание

и уничтожение объектов

7.7.1. Конструкторы –

пример класса ClubMember

else

7.5.2.1. Видимость

7.5.2.2. Тип

7.5.1. Ячейка

имени

Рис. 7.1. План главы

7.2. Что такое объекты? 149

крытие данных объекта за уровнем операций всегда считается хоро

шим ОО стилем.

Объекты скрывают данные на уровне функций, которые называются

операциями.

Каждый объект является экземпляром некоторого класса, определяю

щего общий набор свойств (атрибутов и операций), присущих всем эк

земплярам этого класса. Идея классов и классификаторов на самом де

ле очень проста. Представим принтер типа «Epson Photo 1200». Он

описывает свойства всех отдельных экземпляров данного класса, в том

числе и конкретный «Epson Photo 1200 с/н 34120098», стоящий на на

шем столе. Конкретный экземпляр класса называется объектом.

Немного поразмыслив над этим примером объекта принтера Epson,

можно увидеть, что ему присущи определенные свойства, общие для

всех объектов.

Каждый объект имеет уникальный идентификатор.

• Идентификатор (identity) – это определение существования и един

ственности объекта во времени и пространстве. Это то, что отличает

его от всех остальных объектов. В нашем примере серийный номер

может использоваться в качестве идентификатора для обозначения

конкретного принтера на нашем столе и представления уникально

го идентификатора этого объекта. Серийный номер – замечатель

ный способ идентифицировать физический объект. Для идентифи

кации каждого программного объекта, принимающего участие в ОО

анализе и проектировании, используется аналогичный принцип –

идея объектной ссылки. Конечно, в реальности не у всех объектов

есть серийный номер, но все равно они имеют уникальные иденти

фикаторы: конкретные пространственные и временные координа

ты. Подобным образом в ОО программных системах каждый объект

имеет некоторую объектную ссылку.

Значения атрибутов хранят данные объекта.

• Состояние (state) – определяется значениями атрибутов объекта

и его отношениями с другими объектами в конкретный момент вре

мени. В табл. 7.1. приведен полный список возможных состояний

принтера, из которого видно, как состояние объекта зависит от зна

чений его атрибутов и его связи с другими объектами.

• Поведение (behavior) – принтер может выполнять конкретные дей

ствия:

switchOn() (включиться)

switchOff() (выключиться)

150 Глава 7. Объекты и классы

printDocument() (распечатать документ)

pageFeed() (заправить бумагу)

clearInkJetNozzles() (очистить форсунки)

changeInkCartridge() (заменить картридж)

Вызов операции объекта всегда приводит к изменению значений одного

или более его атрибутов или отношений с другими объектами. Это мо+

жет обусловить переход состояний – целенаправленный переход объ

екта из одного состояния в другое. Из табл. 7.1 видно, что состояние

объекта может влиять и на его поведение. Например, если в принтере

закончились чернила (состояние объекта = OutOfBlackInk), вызов опера

ции printDocument() приведет к сообщению об ошибке. Поэтому поведе

ние printDocument() является зависимым от состояния.

Метод – это реализация операции.

Операция – это описание части поведения. Реализация этого поведе

ния называется методом (method).

Таблица 7.1

7.2.1. Инкапсуляция

Как уже говорилось, идентификатор объекта – это некий уникальный

дескриптор, обычно адрес памяти, предоставляемый языком реализа

ции. С этого момента будем называть эти дескрипторы объектными

ссылками. В ОО анализе не надо беспокоиться об их реализации. Мож

но просто принять, что у каждого объекта есть уникальный идентифи

катор, управляемый технологией реализации. Возможно, при проек

тировании понадобится рассмотреть реализацию объектных ссылок.

Это необходимо, если целевым языком является ОО язык программи

рования, такой как С++, который позволяет напрямую работать с оп

ределенными типами объектных ссылок, известными как указатели.

На рис. 7.2 приведено концептуальное представление объекта, под

черкивающее инкапсуляцию. Обратите внимание, что рис. 7.2 не яв+

Состояние объекта Атрибут класса Значение атри

бута объекта

Отношение

On power on Не определено

Off power off Не определено

OutOfBlackInk blackInkCartridge empty Не определено

OutOfColorInk colorInkCartridge empty Не определено

Connected не определено не определено Подключен к объек

ту компьютер

NotConnected не определено не определено Не подключен к объ

екту компьютер

7.2. Что такое объекты? 151

ляется UMLдиаграммой. UMLсинтаксис для объектов будет показан

позже.

Состояние объекта определяется значениями его атрибутов.

Состояние объекта – это набор значений атрибутов (в данном случае

1234567801, «Jim Arlow», 300.00) объекта в любой момент времени.

Значения некоторых атрибутов постоянны, значения других могут со

временем меняться. Например, номер счета и имя останутся постоян

ными, а вот баланс, надеемся, будет постепенно увеличиваться!

Поскольку баланс меняется со временем, мы видим, что состояние

объекта также изменяется во времени. Например, если баланс отрица

тельный, можно сказать, что объект находится в состоянии Overdrawn

(кредит превышен). При изменении баланса из отрицательного в нуле

вой объект существенно меняет свою суть: переходит из состояния

Overdrawn в состояние Empty (пустой). Более того, когда баланс объекта

Account (счет) становится положительным, осуществляется еще один пе

реход состояния: из Empty в InCredit (кредитоспособен). Возможны и дру

гие переходы состояний. Фактически любой вызов операции, приво

дящий к изменению сути объекта, обуславливает переход состояний.

UML предоставляет мощный набор методов моделирования измене

ний состояния, которые называются конечными автоматами; им по

священа глава 21.

Поведение объекта – это то, «что он может сделать для нас», т. е. его

операции.

значения атрибутов

операции

объект Account

deposit( )

withdraw( )

getOwner( )

setOwner( )

1234567801

«Jim Arlow»

300.00

Рис. 7.2. Представление объекта, подчеркивающее инкапсуляцию

152 Глава 7. Объекты и классы

Поведение любого объекта – это, по существу, то, «что он может сде

лать» для вас. Объект на рис. 7.2 предоставляет операции, перечис

ленные в табл. 7.2.

Таблица 7.2

Этот набор операций определяет поведение объекта. Обратите внима

ние, что вызов некоторых из этих операций (deposit(), withdraw(), setOwn

er()) приводит к изменению значений атрибута и может генерировать

переходы состояния. Операция getOwner() не меняет значения атрибута

и поэтому не приводит к переходу состояния.

Инкапсуляция, или сокрытие данных, – одно из основных преиму

ществ ОО программирования. Она обеспечивает возможность создания

более надежного и расширяемого программного обеспечения. В этом

простом примере объекта Account пользователю не надо беспокоиться

о структуре данных, сокрытых в объекте. Его интересует только то,

что объект может сделать. Иначе говоря, ему интересны сервисы (ser+

vices), предлагаемые другим объектам.

7.2.2. Обмен сообщениями

Объекты формируют поведение системы путем обмена сообщениями

по связям. Это – кооперация.

У объектов есть значения атрибутов и поведение, но как эти объекты

объединить, чтобы создать систему программного обеспечения? Объ

екты кооперируются для осуществления функций системы. Это озна

чает, что они устанавливают связи с другими объектами и обменива

ются сообщениями по этим связям. Когда объект получает сообщение,

он проверяет набор своих операций в поиске той, сигнатура которой

соответствует сигнатуре сообщения. Если таковая имеется, он иници

ирует эту операцию (рис. 7.3). В сигнатуру входят имя сообщения (или

операции), типы параметров и возвращаемое значение.

Во время выполнения ОО система состоит из множества создаваемых

объектов, существующих некоторое время и затем, возможно, уничто

жаемых. Эти объекты обмениваются сообщениями, инициируя серви

сы друг друга. Такая структура радикально отличается от процедур

Операция Семантика

deposit() Размещает некоторую сумму в объекте Account.

Увеличивает значение атрибута balance.

withdraw() Снимает некоторую сумму с Account.

Уменьшает значение атрибута balance.

getOwner() Возвращает владельца объекта Account – операция запроса.

setOwner() Меняет владельца объекта Account.

7.3. Нотация объектов в UML 153

ных программных систем, которые изменяются со временем путем по

следовательного применения функций к данным.

7.3. Нотация объектов в UML

Пиктограмма объекта в UML – это прямоугольник с двумя ячейками

(рис. 7.4). В верхней ячейке размещается идентификатор объекта, ко

торый всегда подчеркивается. Это важно, поскольку в UML обозначе

ния классов и объектов очень похожи. Если строго следовать прави

лам применения подчеркивания, никогда не возникнет вопроса, чем

является моделируемый элемент – классом или объектом.

UML очень гибок относительно представления объектов на диаграм

мах объектов. Идентификатор объекта может включать следующие

элементы.

• Только имя класса, например :Account

. Это означает, что имеется ано

нимный объект или экземпляр данного класса (т. е. это экземпляр

класса Account, но он не идентифицирован или в действительности не

имеет значения, какой именно это экземпляр). Анонимные объекты

обычно используются, когда на данной диаграмме присутствует тол

ко один объект этого конкретного класса. Если необходимо показать

два объекта одного и того же класса, каждому из них должно быть

присвоено уникальное имя, чтобы можно было их различать.

Объект Bank Объект Account

сообщение

Объект Bank посылает сообщение

«withdraw 150.00» объекту Account

В ответ объект Account вызывает свою операцию

withdraw, которая уменьшает баланс счета на 150.00

withdraw (150.00)

Рис. 7.3. Обмен сообщениями

accountNumber : String = "1234567"

owner : String = "Jim Arlow"

balance : double = 300.00

имя

атрибута

ячейка атрибутов

ячейка имени

тип

атрибута

значение

атрибута

имя

объекта

имя

класса

jimsAccount:Account

Рис. 7.4. Нотация объектов в UML