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

Просмтор этого файла доступен только зарегистрированным пользователям. Но у нас супер быстрая регистрация: достаточно только электронной почты!

Текст из файла (страница 28)

Рабочий поток анализа в UP. Воспроизведено с рис. 8.18 [Jacobson 1]с разрешения издательства Addison+Wesleyнять их, необходимо рассмотреть классы и объекты. Они будут обсуждаться в главе 7.6.5. Аналитическая модель – практическиеправилаВсе системы разные, поэтому сложно найти универсальный подходк созданию аналитических моделей. Тем не менее аналитическая модель системы среднего размера и сложности включает от 50 до 100 классов анализа. Необходимо запомнить, что при создании аналитическоймодели крайне важно ограничиться лишь теми классами, которые являются частью словаря предметной области. Всегда есть искушение поместить в аналитическую модель и проектные классы (такие как классы, используемые для установления соединений или доступа к базе данных), но этого необходимо избегать (если только предметная область некасается связи или баз данных)! Такое ограничение накладываетсяв попытке сделать аналитическую модель кратким, простым описанием структуры и поведения системы.

Все решения по реализации должны приниматься в рабочих потоках проектирования и реализации.Вот некоторые практические приемы создания хорошей аналитической модели:• Аналитическая модель всегда создается на языке соответствующейсферы деятельности. Абстракции аналитической модели должныформировать часть словаря бизнессферы.•Создаваемые модели должны «рассказывать историю». Каждаядиаграмма должна раскрывать некоторые важные части поведениясистемы. Иначе зачем они нужны? Как создавать такие диаграммы, будет показано при рассмотрении реализации прецедентов.6.6. Что мы узнали145•Необходимо сосредоточиться на отображении основной картины.Не надо углубляться в детали того, как будет работать система. Дляэтого отводится достаточно времени при проектировании.•Необходимо четко различать предметную область (бизнестребования) и область решения (детальные конструктивные соображения).Основное внимание всегда должно быть направлено на абстракциипредметной области.

Например, при моделировании системы электронной торговли в аналитической модели должны присутствоватьклассы Customer (клиент), Order (заказ) и ShoppingBasket (корзина покупок). Здесь не должно быть классов доступа к базе данных иликлассов для установления соединений, поскольку они – артефактыобласти решения.•Всегда необходимо стремиться минимизировать связанность (coupling). Каждая ассоциация между классами увеличивает их связанность. В главе 9 будет показано, как можно максимально сократитьсвязанность с помощью кратностей и навигации по ассоциациям.•Если присутствует естественная и очевидная иерархия абстракций,должна быть рассмотрена возможность применения наследования.При анализе иерархия никогда не должна применяться просто дляповторного использования кода.

Как мы увидим в разделе 17.6, наследование – самая сильная форма связанности классов.•Всегда должен задаваться вопрос: «Модель полезна для всех заинтересованных сторон?» Нет ничего хуже, чем создавать аналитическую модель, которая игнорируется пользователями или проектировщиками и разработчиками. Пока что это происходит оченьчасто, особенно с неопытными аналитиками. Основная превентивная стратегия при этом – сделать аналитическую модель и процессмоделирования максимально открытыми, по возможности привлечь в него заинтересованные стороны, проводить частые и публичные обзоры.И наконец, модель должна быть простой! Конечно, легче сказать, чемсделать, но нам из собственного опыта известно, что внутри любойсложной аналитической модели можно найти простую.

Один из способов упрощения – рассматривать вопрос в общем, не погружаясь в частности.6.6. Что мы узналиМы рассмотрели следующее:•Анализ заключается в создании моделей, отображающих основныетребования и характеристики целевой системы – аналитическоемоделирование имеет стратегическое значение.•Основной объем работ рабочего потока анализа выполняется в конце фазы Начало и в фазе Уточнение.146Глава 6. Рабочий поток анализа•••••Рабочие потоки анализа и определения требований пересекаются,особенно в фазе Уточнение – обычно для выявления неучтенныхили искаженных требований полезно анализировать требованияпо мере их обнаружения.Аналитическая модель:• всегда создается на языке соответствующей сферы деятельности;• отображает картину в целом;• содержит артефакты, моделирующие предметную область;• рассказывает историю о целевой системе;• полезна максимально возможному числу заинтересованных сторон.Аналитические артефакты – это:• классы анализа – ключевые понятия бизнессферы;• реализации прецедентов – иллюстрируют, как экземпляры классов анализа могут взаимодействовать для реализации поведениясистемы, описанного прецедентами.Рабочий поток анализа в UP включает следующие деятельности:• Архитектурный анализ• Анализ прецедента• Анализ класса• Анализ пакетаАналитическая модель – практические правила:• аналитическая модель среднестатистической системы состоитиз 50–100 классов анализа;• включаются только классы, моделирующие словарь предметнойобласти;• не формируются решения по реализации;• основное внимание на классах и ассоциациях – минимизациясвязанности между классами;• наследование применяется там, где присутствует естественнаяиерархия абстракций;• необходимо стремиться к простоте модели!7Объекты и классы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), или сокрытиеданных (datahiding). Инкапсуляция в UML не является обязательной, поскольку некоторые ОО языки не нуждаются в ней. Однако со7.5.3.1 Направлениепараметра7.5.2.1.

Видимость7.5.3.3. Расширенныйсинтаксис операции7.5.3.4. Операциизапроса7.5.2.4. Начальное значение7.5.2.5. Расширенныйсинтаксис атрибута7.5.2.3. Кратность7.5.3.2. Значения параметровпо умолчанию7.5.3. Ячейкаопераций7.5.2. Ячейкаатрибутов7.5.2.2. ТипизучаемоперацииизучаематрибутыРис. 7.1. План главы7.5.1. Ячейкаимениизучаем процессприсваивания имен классам7.5. Нотация классов в UML7.6.2. Область действия опреQделяет возможность доступа7.6.1.

Область действия класси область действия экземпляр7.6. Областьдействияизучаемобласть действия7.7.2. Деструкторы –пример класса ClubMember7.7.1. Конструкторы –пример класса ClubMember7.7. Созданиеи уничтожение объектовизучаем конструкторыи деструкторы7.4.2. Создание экземпляров класса7.4.1.

Классы и объекты7.4. Что такое классы?7.3.1. Значения атрибутов объектов7.3. Нотация объектов в UML7.2.2. Обмен сообщениями7.2.1. Инкапсуляция7.2. Что такое объекты?изучаем создание и уничтожение объектовизучаем классыизучаем синтаксис UML!объектаизучаем объекты7.8. Что мы узнали7.5.4. Синтаксисстереотипа классаизучаемстереотипыизучаем синтаксис UML!классаelseelseelse148Глава 7. Объекты и классы7.2. Что такое объекты?149крытие данных объекта за уровнем операций всегда считается хорошим ОО стилем.Объекты скрывают данные на уровне функций, которые называютсяоперациями.Каждый объект является экземпляром некоторого класса, определяющего общий набор свойств (атрибутов и операций), присущих всем экземплярам этого класса.

Идея классов и классификаторов на самом деле очень проста. Представим принтер типа «Epson Photo 1200». Онописывает свойства всех отдельных экземпляров данного класса, в томчисле и конкретный «Epson Photo 1200 с/н 34120098», стоящий на нашем столе. Конкретный экземпляр класса называется объектом.Немного поразмыслив над этим примером объекта принтера Epson,можно увидеть, что ему присущи определенные свойства, общие длявсех объектов.Каждый объект имеет уникальный идентификатор.•Идентификатор (identity) – это определение существования и единственности объекта во времени и пространстве.

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

Подобным образом в ОО программных системах каждый объектимеет некоторую объектную ссылку.Значения атрибутов хранят данные объекта.••Состояние (state) – определяется значениями атрибутов объектаи его отношениями с другими объектами в конкретный момент времени.

В табл. 7.1. приведен полный список возможных состоянийпринтера, из которого видно, как состояние объекта зависит от значений его атрибутов и его связи с другими объектами.Поведение (behavior) – принтер может выполнять конкретные действия:switchOn() (включиться)switchOff() (выключиться)150Глава 7. Объекты и классыprintDocument() (распечатать документ)pageFeed() (заправить бумагу)clearInkJetNozzles() (очистить форсунки)changeInkCartridge() (заменить картридж)Вызов операции объекта всегда приводит к изменению значений одногоили более его атрибутов или отношений с другими объектами.

Характеристики

Список файлов книги