Лекция 9 Резюме по введению в моделирование

Лекция 9

Резюме по введению в моделирование

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

Термины и понятия

Иначе говоря, система представляет собой разрабатываемую сущность, которая рассматривается с разных точек зрения с помощью моделей, многообразные… Диаграмма - это просто графическая проекция элементов, составляющих систему.… Как видно из примера, та или иная сущность в системе (например, класс Работник) может многократно повторяться на одной…

Примечание На практике создаваемые вами диаграммы двумерны, то есть представляют собой плоские графы, которые можно нарисовать на листе бумаги, доске или экране компьютера. UML позволяет создавать и трехмерные, объемные диаграммы. Некоторые исследовательские коллективы, работающие в области виртуальной реальности, уже продемонстрировали такое нестандартное использование UML.

Структурные диаграммы

Названия структурных диаграмм UML соответствуют названиям основных групп сущностей, используемых при моделировании системы: • диаграммы классов - классам, интерфейсам и кооперациям; • диаграммы объектов - объектам;

Примечание Существует несколько распространенных разновидностей четырех основных типов диаграмм, названных по основным содержащимся в них объектам. Например, для иллюстрации структурной декомпозиции системы на подсистемы можно использовать диаграмму подсистем, которая представляет собой обыкновенную диаграмму классов, содержащую главным образом подсистемы.

Диаграммы поведения

Диаграммы поведения в UML условно разделяются на пять типов в соответствии с основными способами моделирования динамики системы: • диаграммы прецедентов описывают организацию поведения системы; • диаграммы последовательностей акцентируют внимание на временной упорядоченности сообщений;

Примечание Диаграммы последовательностей и кооперации изоморфны, то есть их можно преобразовывать друг в друга без потери информации.

Диаграмма состояний показывает автомат, содержащий состояния, переходы, события и действия (см. главу 24). Диаграммы такого рода относятся к динамическому виду системы и особенно важны при моделировании поведения интер­фейса, класса или кооперации. Основное внимание в них уделяется порядку возникновения событий, связанных с объектом, что особенно полезно при моделировании реактивных систем.

На диаграммах деятельности изображают передачу управления от одной деятельности к другой внутри системы. На них показаны виды деятельности, последовательные или параллельные ветвления потока управления и объекты, которые воздействуют на что-то или сами подвергаются воздействию (см. главу 19). Диаграммы деятельности относятся к динамическому представлению системы и особенно важны при моделировании ее функций. Они являются особой разновидностью диаграмм состояния. На диаграммах деятельности основное внимание уделено потоку управления между объектами.

Применение Разумеется, при попытке проиллюстрировать динамическое поведение системы с помощью диаграмм, которые по сути своей статичны (особенно если рисуются на листе бумаги, на доске или обратной стороне конверта), возникают определенные физические ограничения. При использовании компьютерных технологий к диаграммам поведения можно применять анимационные эффекты с целью имитации исполняемой системы или аппроксимации ее поведения. Язык UML позволяет рисовать динамические диаграммы, в которых цвет или другие визуальные факторы призваны создать впечатление из­меняемости. Некоторые инструментальные средства, существующие на данный момент, уже поддерживают такую возможность.

Типичные приемы моделирования

При моделировании системы с различных точек зрения вы фактически конструируете ее сразу в нескольких измерениях. Правильный выбор совокупности видов… Моделирование системы с использованием различных представлений осуществляется… 1. Решите, какие именно виды лучше всего отражают архитектуру системы и возможный технический риск, связанный с…

Различные уровни абстракции

Существует два основных способа моделировать различные уровни абстракции системы: можно, во-первых, строить диаграммы одной и той же модели,… Моделирование системы на разных уровнях абстракции с применением диаграмм… 1. Изучите потребности ваших читателей и приступайте к созданию модели.

Лекция 10

Сложные представления

Моделирование сложных представлений осуществляется следующим образом: 1. Прежде всего убедитесь, что для достижения ваших целей нельзя ограничиться… 2. Если после того, как вы скрыли максимально возможное число деталей, диаграмма все еще остается слишком сложной,…

Советы

При разработке диаграмм руководствуйтесь следующими правилами:

• помните, что цель создания диаграмм на языке UML - не рисование красивых картинок, а визуализация, специфицирование, конструирование и документирование. Диаграммы - это только одно из средств, помогающих привести разработку программной системы к успешному завершению;

• не все диаграммы необходимо сохранять. Иногда стоит создавать их «на лету», путем опроса элементов модели, и использовать для анализа системы по мере ее построения. Многие диаграммы такого рода можно будет выбросить после того, как они выполнят свое назначение (хотя семантика, лежащая в их основе, останется частью модели);

• избегайте избыточных диаграмм, они только загромождают модель;

• каждая диаграмма должна содержать только необходимые для ее целей детали. Лишняя информация отвлечет внимание читателя от более важных элементов модели;

• старайтесь не делать диаграммы слишком краткими, если только не хотите представить что-либо на очень высоком уровне абстракции. Чрезмерное упрощение может скрыть детали, важные для понимания модели;

• поддерживайте баланс между структурными диаграммами и диаграммами поведения. Очень немногие системы являются только статическими или только динамическими;

• не делайте диаграммы очень большими (если объем превышает несколько печатных страниц, это затрудняет навигацию) или очень маленькими (в последнем случае лучше объединить несколько простых диаграмм в одну);

• у каждой диаграммы должно быть осмысленное имя, ясно отражающее ее назначение;

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

• не обременяйте себя форматированием диаграммы - используйте для этого соответствующие инструменты. Хорошо структурированная диаграмма обладает следующими свойствами:

• заостряет внимание на одном аспекте некоторого представления системы;

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

• содержит детали, соответствующие выбранному уровню абстракции (не обременена деталями, без которых можно обойтись);

• не настолько лаконична, чтобы ввести читателя в заблуждение относительно

• важных аспектов семантики.

Изображая диаграмму, воспользуйтесь нижеприведенными рекомендациями:

• дайте диаграмме имя, соответствующее ее назначению;

• расположите элементы так, чтобы свести к минимуму число пересечений;

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

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

Глава 8. Диаграммы классов

Диаграммы классов при моделировании объектно-ориентированных систем встречаются чаще других. На таких диаграммах показывается множество классов, интерфейсов, коопераций и отношений между ними.

Диаграммы классов используются для моделирования статического вида системы с точки зрения проектирования. Сюда по большей части относится моделирование словаря системы, коопераций и схем. Кроме того, диаграммы классов составляют основу еще двух диаграмм - компонентов и развертывания.

Диаграммы классов важны не только для визуализации, специфицирования и документирования структурных моделей, но также для прямого и обратного проектирования исполняемых систем.

Введение

Строя дом, вы начинаете со словаря, включающего его основные строительные блоки: стены, потолки, окна, двери, полы, стропила. Хотя все эти сущности носят преимущественно структурный характер (например, стена характеризуется высотой, шириной и толщиной), они имеют еще и поведенческие особенности (скажем, стены могут выдерживать определенную нагрузку, двери - открываться и закрываться; имеются ограничения па длину пролета без опор). Структурные и поведенческие аспекты нельзя рассматривать изолированно. Напротив, при строительстве дома необходимо учитывать их взаимодействие. Процесс архитектурного проектирования состоит в том, чтобы, объединив все вышеупомянутые сущности, смоделировать красивое и непохожее на другие здание, способное удовлетворить всеваши функциональные и нефункциональные потребности. При этом чертежи, создаваемые для визуализации дома и специфицирования его деталей для подрядчика, представляют собой графическое изображение всех составляющих его элементов и их взаимодействие.

Создание программного обеспечения похоже на строительство дома, но в силу умозрительной природы программ вы можете сами с нуля создавать нужные строительные блоки. В UML диаграммы классов служат для визуализации статических аспектов этих строительных блоков и их отношений, а также для специфицирования деталей конструкции (см. рис. 8.1).

Термины и понятия

Диаграммой классов (Class diagram) называют диаграмму, на которой показано множество классов, интерфейсов, коопераций и отношений между ними. Ее изображают в виде множества вершин и дуг.

Общие свойства

Диаграмме классов присущи общие для всех диаграмм свойства (см. главу 7): имя и графическое содержание, являющееся одной из проекций модели. Вместе с тем диаграммы такого рода отличаются от остальных специфичным содержанием.

Содержание

Диаграммы классов обычно содержат следующие сущности:

• классы (см. главы 4 и 9);

• интерфейсы (см. главу 11);

• кооперации (см. главу 27);

• отношения зависимости, обобщения и ассоциации (см. главы 5 и 10).

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

Также в диаграммах классов могут присутствовать пакеты (см. главу 12) или подсистемы (см. главу 31), применяемые для группирования элементов модели в более крупные блоки. Иногда в эти диаграммы помещают экземпляры (см главу 13), особенно если требуется визуализировать их тип (возможно, динамический).

Примечание На диаграммы классов похожи диаграммы компонентов и развертывания, но вместо классов они содержат соответственно компоненты и узлы.

Типичные примеры применения

Диаграммы классов применяют для моделирования статического вида системы с точки зрения проектирования. В этом представлении удобнее всего описывать функциональные требования к системе - услуги, которые она предоставляет конечному пользователю.

Обычно диаграммы классов используются в следующих целях:

• для моделирования словаря системы (см. главу 4). Моделирование словаря системы предполагает принятие решения о том, какие абстракции являются частью системы, а какие - нет. С помощью диаграмм классов вы можете определить эти абстракции и их обязанности;

• для моделирования простых коопераций (см. главу 27). Кооперация - это сообщество классов, интерфейсов и других элементов, работающих совместно для обеспечения некоторого кооперативного поведения, более значимого, чем сумма составляющих его элементов. Например, моделируя семантику транзакций в распределенной системе, вы не сможете понять происходящие процессы, глядя на один-единственный класс, поскольку соответствующая семантика обеспечивается несколькими совместно работающими классами. С помощью диаграмм классов удается визуализировать и специфицировать эти классы и отношения между ними;

• для моделирования логической схемы базы данных. Логическую схему можно представлять себе как чертеж концептуального проекта базы данных. Во многих сферах деятельности требуется хранить устойчивую (persistent) информацию (см. главу 23) в реляционной или объектно-ориентированной базе данных. Моделировать схемы (см. главу 29) также можно с помощью диаграмм классов.

Типичные приемы моделирования

Простые кооперации

Классы не существуют сами по себе. Любой класс функционирует совместно с другими, реализуя семантику, выходящую за границы каждого отдельного элемента. Таким образом, кроме определения словаря системы нужно уделить внимание визуализации, специфицированию, конструированию и документированию различных способов совместной работы вошедших в словарь сущностей. Для моделирования такого «сотрудничества» применяются диаграммы классов.

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

Моделирование кооперации осуществляется следующим образом:

1. Идентифицируйте механизмы, которые вы собираетесь моделировать. Механизм - это некоторая функция или поведение части моделируемой системы, появляющееся в результате взаимодействия сообщества классов, интерфейсов и других сущностей. (Механизмы, как правило, тесно связаны с прецедентами, см. главу 16.)

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

3. Проверьте работоспособность системы с помощью прецедентов (см. главу 15). По ходу дела вы, возможно, обнаружите, что некоторые ее части оказались пропущены, а некоторые - семантически неправильны.

4. Заполните идентифицированные элементы содержанием. Что касается классов, начните с правильного распределения обязанностей; позже можно будет превратить их в конкретные атрибуты и операции.

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

существует один абстрактный класс Мотор с двумя конкретными потомками, МоторПоворотногоМеханизма и ГлавныйМотор, которые наследуют пять операций их родителя. Эти два класса, в свою очередь, являются частью класса Привод. Класс АгентТраектории связан отношением ассоциации «один к одному» с классом Привод и отношением «один ко многим» - с классом ДатчикСтолкновений. Для класса АгентТраектории не показано ни атрибутов, ни операций, хотя при­ведены обязанности.

В описанную систему входит значительно больше классов, но внимание на диаграмме заостряется только на таких абстракциях, которые непосредственно участвуют в движении робота. Некоторые указанные классы могут присутствовать и на других диаграммах. Например, хотя здесь это не показано, АгентТраектории сотрудничает по крайней мере еще с двумя классами (Окружение и АгентЦели) в механизме более высокого уровня, управляющем поведением робота при наличии конфликтующих целей. ДатчикСтолкновений и Привод, а также их части сотрудничают с другим, не показанным на диаграмме классом АгентОтказа в механизме, отвечающем за постоянный контроль аппаратных сбоев. Описывая каждую из этих коопераций в отдельных диаграммах, вы сможете создать простое для восприятия представление системы с различных точек зрения.

Логическая схема базы данных

Многие моделируемые системы содержат устойчивые объекты, то есть такие, которые можно сохранять в базе данных и впоследствии извлекать при необходимости (см. главу 23). Для этого чаще всего используют реляционные, объектно-ориентированные или гибридные объектно-реляционные базы данных. UML позволяет моделировать логические схемы баз данных, равно как и сами физические базы (см. главу 29).

Диаграммы классов UML включают в себя, как частный случай, диаграммы «сущность-связь» (E-R диаграммы), которые часто используются для логического проектирования баз данных. Но если в классических E-R диаграммах внимание сосредоточено только на данных, диаграммы классов - это шаг вперед:

они позволяют моделировать также и поведение. В реальной базе данных подобные логические операции обычно трансформируются в триггеры или хранимые процедуры.

Моделирование схемы производится следующим образом:

1. Идентифицируются классы модели, состояние которых должно сохраняться и после завершения работы создавшего их приложения.

2. Создается диаграмма классов, содержащая эти классы и ори характеризуются как устойчивые с помощью стандартного помеченного значения persistent (устойчивый). Для работы со специфическими деталями базы данных можно определить и свои собственные помеченные значения.

 

3. Раскрываются структурные особенности классов. В общем случае это означает, что надо детально специфицировать их атрибуты и обратить особое внимание на ассоциации и их кратности.

4. Отыскиваются типичные структурные образцы, усложняющие проектирование физической базы данных, например циклические ассоциации, ассоциации «один к одному» и парные ассоциации. При необходимости создаются промежуточные абстракции для упрощения логической структуры.

5. Рассматривается поведение этих классов и раскрываются операции, важные для доступа к данным и поддержания их целостности. В общем случае для лучшего разделения обязанностей бизнес-правила, отвечающие за манипуляции наборами объектов, должны быть инкапсулированы в слое, находящемся над этими устойчивыми классами.

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

Примечание Рассмотрение логического проектирования базы данных выходит за рамки данной книги, цель которой состоит только в том, чтобы показать, как моделировать схемы с помощью языка UML На практике все сводится к применению стереотипов (см. главу 6), настроенных на конкретный тип используемой базы данных (реляционной или объектно-ориентированной).

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

 

Рисунок содержит достаточное количество деталей для конструирования физической	базы данных. В левой нижней части
диаграммы расположены классы Студент, Курс и Преподаватель. Между классами	Студент	и Курс есть ассоциация, по-
казывающая, что студенты могут посещать курсы. Более того, каждый студент может посещать	любое количество курсов и на
каждый курс может записаться любое число студентов.
Все шесть классов на диаграмме помечены как устойчивые (persistent), то есть	их экземпляры должны содержаться в
базе данных или каком-то ином хранилище. Приведены также атрибуты всех шее™	i классов. Обратите внимание, что все
атрибуты являются примитивными типами (см. главу 4). Моделируя схему, отношения	с непримитивными типами лучше всего
представлять с помощью явного агрегирования (см. главы 5 и 10), а не с помощью атрибутов.

Два класса (Вуз и Факультет) содержат несколько операций, позволяющих манипулировать их частями. Эти операции

включены из-за их важности для поддержания целостности данных (например, добавление или удаление Факультета

затрагивает целый ряд других объектов).

Существует много других операций, которые стоило бы рассмотреть при проектировании этих и иных классов, например

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

операции по поддержанию целостности данных, поэтому лучше располагать их на более высоком уровне абстракции.

Прямое и обратное проектирование

Моделирование, конечно, важная вещь, но Следует помнить, что основным результатом деятельности группы

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

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

Поэтому очень важно, чтобы модели и основанные на них реализации соответствовали друг другу, причем с минималь-

ными затратами по поддержанию синхронизации между ними (см. главу 1).

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

например, моделируется бизнес-процесс с помощью диаграмм действий (см. главу 19), то во многих действиях будут

участвовать люди, а не компьютеры. В других случаях необходимо моделировать системы, составными частями которых на

данном уровне абстракции являются только аппаратные средства (хотя на другом уровне абстракции вполне может оказаться,

что они содержат встроенные процессоры с соответствующим программным обеспечением).

Но чаще всего модели все-таки преобразуются в код. Хотя UML не определяет конкретного способа отображения на какой-

либо объектно-ориентированный язык, он проектировался с учетом этого требования. В наибольшей степени это относится к

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

программирования, как Java, C++, Smalltalk, Eiffel, Ada, ObjectPascal и Forte. Кроме того, в проект UML была заложена

возможность отображения на коммерческие объектные языки, например Visual Basic.

Примечание Раскрытие темы отображения UML на конкретные языки программирования для прямого и обратного

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

стереотипов и помеченных значений (см. главу 6), настроенных на определенный язык.

Прямым проектированием (Forward engineering) называется процесс преобразования модели в код путем отображения на

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

языке UML модели семантически богаче любого из существующих объектно-ориентированных языков. Фактически именно это

различие и является основной причиной, из-за которой помимо кода, нужны и моделях. Некоторые структурные

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

визуализированы в UML, но в чистом коде наглядность теряется.

Прямое проектирование диаграммы классов производится следующим образом:

1. Идентифицируйте правила отображения модели на один или несколько языков программирования по вашему выбору. Это

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

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

UML. Например, язык UML допускает множественное наследование, а язык программирования Smalltalk - только одиночное.

В связи с этим можно или запретить авторам моделей пользоваться множественным наследованием (что сделает создава-

емые модели зависимыми от языка), или разработать идиомы для трансляции таких расширенных возможностей в

конструкции, поддерживаемые данным языком программирования (что усложнит отображение).

3. Применяйте помеченные значения для специфицирования языка программирования. Это можно сделать как на уровне

индивидуальных классов (если нужна тонкая настройка), так и на более высоком уровне, например для пакетов или

коопераций.

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

На рис. 8.4 изображена простая диаграмма классов, на которой проиллюстрирована реализация образца (см. главу 28)

цепочки обязанностей. В данном примере представлены три класса: Client (Клиент), EventHandler (ОбработчикСобытий) и

GUIEventHandler (ОбработчикСобытийГИП). Первые два из них являются абстрактными, а последний - конкретным. Класс

EventHandler содержит обычную для данного образца операцию handleRequest (обработатьЗапрос), хотя в рассматриваемом

случае было добавлено два скрытых атрибута.

Определенное для каждого класса помеченное значение показывает, что они будут преобразованы в код на языке Java. Прямое проектирование в данном случае легко осуществимо с помощью специального инструмента. Так, для класса EventHandler будет сгенерирован следующий код:

public abstract class EventHandler {

EventHandler successor;

private Integer currentEventID;

private String source;

EventHandler () {}

public void handleRequest () {}

}

Обратным проектированием (Reverse engineering) называется процесс преобразования в модель кода, записанного на каком-либо языке программирования. В результате этого процесса вы получаете огромный объем информации, часть которой находится на более низком уровне детализации, чем необходимо для построения полезных моделей. В то же время обратное проектирование никогда не бывает полным. Как уже упоминалось, прямое проектирование ведет к потере информации, так что полностью восстановить модель на основе кода не удастся, если только инструментальные средства не включали в комментариях к исходному тексту информацию, выходящую за пределы семантики языка реализации. Пример, пред­ставленный на рис. 3.3, был создан с помощью обратного проектирования библиотеки классов языка Java.

Обратное проектирование диаграммы классов осуществляется так:

1. Идентифицируйте правила для преобразования из выбранного вами языка реализации. Это можно сделать на уровне
проекта или организации в целом. С помощью инструментального средства укажите код, который вы хотите

2. Подвергнуть обратному проектированию. Воспользуйтесь этим средством для создания новой модели или для
модификации ранее созданной.

3. Пользуясь инструментальными средствами, создайте диаграмму классов путем опроса полученной модели. Можно начать, например, с одного или нескольких классов, а затем расширить диаграмму, следуя вдоль некоторых отношений или добавив соседние классы. Раскройте или спрячьте детали содержания диаграммы в зависимости от ваших намерений.

Советы

Создавая диаграмму классов на языке UML, помните, что это всего лишь графическое изображение статического вида системы с точки зрения проектирования. Взятая в отрыве от остальных, ни одна диаграмма классов не может и не должна охватывать этот вид целиком. Диаграммы классов описывают его исчерпывающе, но каждая в отдельности - лишь один из его аспектов.

Хорошо структурированная диаграмма классов обладает следующими свойствами:

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

• содержит лишь элементы, существенные для понимания данного аспекта;

• показывает детали, соответствующие требуемому уровню абстракции, опуская те, без которых можно обойтись;

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

При изображении диаграммы классов руководствуйтесь следующими правилами:

• дайте диаграмме имя, связанное с ее назначением;

• располагайте элементы так, чтобы свести к минимуму число пересекающихся линий;

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

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

• старайтесь не показывать слишком много разных видов отношений; как правило, в каждой диаграмме классов должны доминировать отношения какого-либо одного вида.

Часть III. Изучение структурного моделирования Глава 9. Углубленное изучение классов

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

Классификаторы, и в особенности классы, характеризуются большим количеством дополнительных свойств, кроме простейших, таких как атрибуты и операции, которые были описаны в предыдущих разделах (см. главу 4). Можно моделировать кратность, видимость, сигнатуры, полиморфизм и другие характеристики. Язык UML позволяет определить семантику класса с расчетом па любой нужный вам уровень формализации.

В UML существует несколько разновидностей классификаторов и классов;

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

Введение

На определенном этапе строительства дома вам надлежит принять решение о том, какие материалы нужно использовать (см. главу 2). В самом начале достаточно лишь указать, что это будет дерево, камень или сталь. Такой степени детализации довольно для того, чтобы двигаться дальше. На выбор материалов, разумеется, будут влиять требования проекта, - например, сталь и бетон подойдут, если дом должен выдерживать натиск ураганов. Впоследствии ваш выбор определит дальнейшее развитие проекта, - скажем, выбрав дерево вместо стали, вы должны будете учитывать, что оно выдерживает меньшую нагрузку.

По мере дальнейшей работы над проектом базовые решения придется уточнить и добавить ряд деталей, которые позволят конструктору произвести расчеты на прочность, а строителям - приступить к возведению дома. Например, вы можете выбрать не просто дерево, но дерево определенной твердости или пропитанном определенным составом, который защищает древесину от насекомых.

Те же самые правила применимы и к созданию программного обеспечения. В самом начале работы над проектом достаточно сказать, что вы собираетесь использовать класс Клиент, выполняющий определенные обязанности (см. главу 6). По мере уточнения архитектуры и перехода к конструированию придется определить структуру класса (его атрибуты) и его поведение (операции), необходимые и достаточные для выполнения указанных обязанностей. Наконец, дойдя до стадии преобразования модели в исполняемую систему, вы должны будете смоделировать и такие детали, как, видимость отдельных атрибутов и операций, семантику параллелизма класса в целом и его операций, а также реализуемые классом интерфейсы.

Как видно из рис. 9.1, язык UML позволяет определять большое количество развитых свойств класса. Эта нотация дает возможность визуализировать, специфицировать, конструировать и документировать класс на любом желаемом уровне