Объектно-ориентированный анализ

А.Ю. Мельников

 

Объектно-ориентированный анализ

И проектирование

Информационных систем

Учебное пособие

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

«Экономическая кибернетика»

и

«Интеллектуальные системы принятия решений»

 

 

Утверждено на заседании

ученого совета ДГМА

Протокол № 1 от 28.09.2006г.

 

Краматорск 2006

УДК 004:681

ББК 32.973-01

М48

 

Рецензенты:

· В.Ф.СЫТНИК, доктор экономических наук, профессор, заведующий кафедрой Киевского национального экономического университета

· Р.Н.ЛЕПА, кандидат экономических наук, доцент, заведующий отделом Научно-исследовательского центра информационных технологий Института экономики промышленности Национальной академии наук Украины

 

Навчальний посібник містить основні теоретичні відомості по об’єктно-орієнтованому аналізу і проектуванню систем на уніфікованій мові моделювання UML, порядок роботи у середовищі IBM Rational Rose і приклади створення моделей систем в цьому середовищі.

Рекомендується студентам спеціальностей 7.050102 “Економічна кібернетика” і 7.080404 “Інтелектуальні системи прийняття рішень” як навчальний посібник при вивченні відповідних модулів курсів “Об’єктно-орієнтоване програмування”, “Проектування інформаційних систем”, “Системний аналіз і проектування систем обробки інформації” і “Технологія програмування і створення програмних продуктів”, а також як довідник під час курсового і дипломного проектування.

 

Мельников А. Ю.

М48 Объектно-ориентированный анализ и проектирование информационных систем: Учебное пособие для студентов специальностей «Экономическая кибернетика» и «Интеллектуальные системы принятия решений». – Краматорск: ДГМА, 2006. – 184 с.

ISBN 966-379-103-9

 

Учебное пособие включает основные теоретические сведения по объектно-ориентированному анализу и проектированию систем на универсальном языке моделирования UML, порядок работы в среде IBM Rational Rose и примеры создания моделей систем в этой среде.

Рекомендуется студентам специальностей 7.050102 «Экономическая кибернетика» и 7.080404 «Интеллектуальные системы принятия решений» в качестве учебного пособия при изучении соответствующих модулей курсов «Объектно-ориентированное программирование», «Проектирование информационных систем», «Системный анализ и проектирование систем обработки информации» и «Технология программирования и создания программных продуктов», а также как справочное пособие в ходе курсового и дипломного проектирования.

УДК 004:681

ББК 32.973-01

 

ISBN 966-379-103-9 Ó Мельников А.Ю., 2006

Ó ДГМА, 2006

Содержание

Введение…………………………………………………………………
1 Основные понятия объектно-ориентированного подхода…………
1.1 Объектная модель………………………………………………..
1.2 Классы и объекты………………………………………………..
1.3 Классификация…………………………………………………..
2 Унифицированный язык моделирования UML как средство проектирования программных систем и бизнес-процессов…………
2.1 Предыстория, основы и структура UML……………………….
2.2 Диаграмма концептуального моделирования – диаграмма вариантов использования (use case diagram).………………………
2.3 Диаграммы логического моделирования………………………
2.3.1 Диаграмма классов (class diagram).……………………….
2.3.2 Диаграмма кооперации (collaboration diagram).………….
2.3.3 Диаграмма последовательности (sequence diagram).……
2.3.4 Диаграмма состояний (statechart diagram).……………….
2.3.5 Диаграмма деятельности (activity diagram).……………..
2.4 Диаграммы физического моделирования………………………
2.4.1 Диаграмма компонентов (component diagram).………….
2.4.2 Диаграмма развертывания (deployment diagram).………..
3 Проектирование программных систем с использованием CASE-средства IBM Rational Rose……………………………………
3.1 Общая характеристика инструментария IBM Rational Rose….
3.2 Пример разработки модели информационной системы в среде IBM Rational Rose…………………………………………
3.3 Генерация кода спроектированной модели в среде программирования…………………………………………………
4 Примеры проектирования информационных систем………………
4.1 Информационная система для функционирования кадрового агентства…………………………………………………………………
4.2 Информационная система для автоматизированного составления расписания занятий в высшем учебном заведении…
4.3 Информационная система для специализированного торгового предприятия………………………………………………
4.4 Информационная система для небольшой страховой компании…………………………………………………………….
4.5 Информационная система для обеспечения функционирования финансового отдела предприятия……………
4.6 Информационная система для расчета себестоимости металлопродукции……………………………..……………………
4.7 Информационная система для учета и контроля готовой продукции……………………………..……………………………
4.8 Информационная система для маркетинговых исследований и анализа надежности…………………………………………………..
Список литературы……………………………..………………………

Введение

 

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

В настоящее время в мире распространены три нотации визуального моделирования: IDEF (Icam DEFinition), ARIS (Architecture of Integrated Information Systems) и UML (Unified Modelling Language). Первые две применяются чаще всего при моделировании бизнес-процессов. Рассмотрению третьего, ставшего, по сути, мировым стандартом разработки программного обеспечения, и посвящено данное учебное пособие.

Пособие состоит из четырех частей – двух разделов теоретической направленности и двух – практической. Сначала в конспективной форме излагаются концепции объектно-ориентированного подхода к анализу и проектированию – понятия и определения объектной модели, классов и объектов и их возможных классификаций (за более подробной информацией следует обращаться к «классическому» труду Гради Буча [1]). Затем подробно описывается язык проектирования программных систем UML (в качестве базового учебника принят авторский труд Александра Леоненкова [2], который, в отличие от ряда переводных изданий [3-7], максимально удобно структурирован и предполагает путь «от простого к сложному»).

Третий раздел посвящен описанию CASE-средства проектирования программных систем «IBM Rational Rose», четвертый содержит примеры спроектированных систем (все представленные модели разработаны студентами специальности «Экономическая кибернетика» в рамках курсового и дипломного проектирования под руководством или с участием автора пособия).

Основные понятия

Объектная модель

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

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

Выбор правильного набора абстракций – самая главная задача.

Абстракции можно объединить в 4 группы.

Абстракция сущности: объект представляет собой полезную модель некой сущности в предметной области.

Абстракция поведения: объект состоит из обобщенного множества операций.

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

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

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

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

Абстрагирование и инкапсуляция дополняют друг друга: первое направлено на наблюдаемое поведение объекта, а вторая занимается его внутренним устройством. Интерфейс отражает внешнее поведение объекта, описывая абстракцию поведения всех объектов данного класса; внутренняя реализация описывает представление этой абстракции и механизмы достижения желаемого поведения объекта.

(Следует обратить внимание: «Инкапсуляция не спасает от глупости; она защищает от ошибок, но не от жульничества» – Б. Страуструп).

Пример: простой нагреватель имеет расположение (конструктор), включатель, выключатель и проверку состояния. Усложненный нагреватель может быть связан с датчиком температуры и планом выращивания.

Модульность – это свойство системы разлагаться на внутренне связные, но слабо связанные между собой модули. Логическое продолжение инкапсуляции, ее «практическая проекция».

Иерархия – это упорядочение абстракций, расположение их по уровням. Различают два вида иерархических структур: структура классов («is-a») и структура объектов («part of»).

Структура классов представляет иерархию наследования типа «обобщение-специализация», в которой подкласс (потомок) представляет собой специализированный частный случай своего суперкласса (предка). Пример: «токарь есть частный случай рабочего», «датчик температуры есть частный случай датчика».

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

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

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

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

Спектр сохраняемости объектов охватывает:

– промежуточные результаты вычисления выражений;

– локальные переменные в подпрограммах;

– собственные (глобальные) переменные и динамически создаваемые данные;

– данные, сохраняющиеся между сеансами выполнения программы;

– данные, сохраняемые при переходе на новую версию программы;

– данные, которые вообще переживают программу.

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

Существуют так называемые объектно-ориентированные базы данных (OODB), которые хранят не только данные, но и классы. Эта технология не прижилась, на практике предпочитают создавать объектно-ориентированную оболочку для реляционных баз данных.

 

Некоторые факты из истории

1969 – Кэй (Kay) в своей диссертации предложил идею объектного подхода;

1979 – Джонс (Jones) ввел концепцию объектного подхода;

1981 – Буч (Booch) предложил методы OOD;

1988 – Шлеер и Меллор (Shlaer and Mellor) предложили методы OOA;

1988 – Страуструп (Stroustrup) опубликовал методическую статью по OOP;

1991 – Румбах (Rumbaugh) объединил OOA и OOD.

Организации, отвечающие за стандарты по объектной технологии: Object Management Group (OMG) и комитет ANSI X3J7.

 

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

 

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

Объект моделирует часть окружающей действительности и, таким образом, существует во времени и пространстве. Объект обладает состоянием, поведением и идентичностью; структура и поведение схожих объектов определяет общий для них класс; термины «экземпляр класса» и «объект» взаимозаменяемы.

Состояние объекта характеризуется перечнем (обычно статическим) всех свойств данного объекта и текущими (обычно динамическими) значениями каждого из этих свойств. Пример: автомат по продаже напитков.

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

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

1. Модификатор – операция изменения состояния объекта.

2. Селектор – операция, считывающая состояние объекта, но не изменяющая его.

3. Итератор – операция, позволяющая организовать доступ ко всем частям объекта в строго определенной последовательности.

4. Конструктор – операция создания объекта и/или его инициализации.

5. Деструктор – операция очищения и/или разрушения объекта.

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

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

Идентичность – это такое свойство объекта, которое отличает его от всех других объектов. Следует уметь отличать имя объекта от самого объекта. Если абстракция представляет собой собрание свойств без собственного поведения, это не объект, а структура.

Система реализуется только в процессе взаимодействия объектов. Отношения между объектами могут быть двух типов: связи и агрегация.

Связь – это специфическое сопоставление, через которое клиент запрашивает услугу у объекта-сервера или через которое один объект находит путь к другому.

Участвуя в связи, объект может выполнять одну из трех ролей:

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

– сервер: может только подвергаться воздействию со стороны других объектов, но сам никогда не выступает в роли воздействующего объекта (исключительно пассивный объект);

– агент: может выступать как в активной, так и в пассивной роли.

На рис.1 представлены четыре объекта, каждый из которых характеризует описанные выше роли.

 

Рисунок 1 – Взаимодействующие объекты

 

Агрегация – специализированный частный случай ассоциации; описывает отношения целого и части, приводящие к соответствующей иерархии объектов.

Агрегация может означать физическое вхождение одного объекта в другой (автомобиль и двигатель), но не обязательно (акционер и акции). Пример агрегации с физическим вхождением представлен на рис. 2.

 

Рисунок 2 – Агрегация

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

Поддерживаются 6 (шесть) видов отношений между классами.

1. Ассоциация – смысловая связь (по умолчанию – двусторонняя), фиксирующая участников, их роли и мощность отношения (1:1, 1:*, *:*).

 

 

* 1

Товар Сделка

 

2. Наследование – такое отношение между классами, когда один класс повторяет структуру и поведение другого или других классов. Устанавливает отношение общего и частного. Классы, экземпляры которых создаются, называются конкретными, не создаются – абстрактными. Выводы: у любого класса может быть два вида клиентов – экземпляры (объекты) и подклассы (наследники).

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

 

Датчик Датчик температуры

 

3. Агрегация между классами имеет тот же смысл, что и в случае объектов. Различают агрегацию по значению (физическое включение) и по ссылке. Если есть сомнения в выборе между наследованием и агрегацией, лучше выбрать вторую.

Изображается в виде линии с закрашенным кругом:

 

Контроллер Нагреватель

 

4. Отношение использования между классами соответствует связи между их экземплярами (клиент-серверные отношения).

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

 

Контроллер План выращивания

 

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

Изображается в виде прямоугольника-врезки в правом верхнем углу класса.

6. Метакласс – это класс, экземпляры которого являются классами.

Изображается в виде закрашенного класса.

 

На этапе анализа и ранних стадиях проектирования решаются две основные задачи:

– выявление основных классов и объектов, составляющих словарь предметной области;

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

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

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

Связность – это степень взаимодействия между элементами отдельного модуля (класса, объекта), характеристика его насыщенности: «Класс Dog будет функционально связным, если он описывает поведение собаки, всей собаки, и ничего, кроме собаки».

Достаточность – наличие в классе или модуле всего необходимого для реализации логичного и эффективного поведения.

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

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

 

Классификация

 

Классификация – это средство упорядочения знаний. Исторически известны только три подхода: классическая категоризация, концептуальная кластеризация, теория прототипов.

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

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

Концептуальная кластеризация – современный вариант классического подхода. Здесь сначала формируются концептуальные описания классов («кластеров объектов»), а затем мы классифицируем сущности в соответствии с их описаниями. Это именно понятие, а не признак или свойство: «Если песня скорее про любовь, чем про что-то другое, то мы помещаем ее в категорию любовная песня, хотя степень любовности едва ли можно измерить».

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

Однако существуют некоторые абстракции, которые не имеют ни четких свойств, ни четкого определения. Теория прототипов определяет класс одним объектом-прототипом; новый объект относится к классу при условии, что он наделен существенным сходством с прототипом. Пример: игры.

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

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

Существует семь проверенных практикой подходов к анализу объектно-ориентированных систем.

1. Классические подходы – опираются на классическую категоризацию.

Шлаер и Меллор: осязаемые предметы (датчики), роли (рабочий, студент), события (запрос, прерывание), взаимодействие (встреча, пересечение).

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

Коад и Йордан: структуры (отношения «целое-часть» и «общее-частное»), другие системы (внешние), устройства, события, роли, места, организационные единицы.

2. При анализе поведения именно динамическое поведение рассматривается как первоисточник классов и объектов; основан на концептуальной кластеризации. Инициаторы определенного поведения и его участники опознаются как объекты и делаются ответственными за определенные роли. Примеры: ввод/вывод, запрос.

3. Анализ предметной области – попытка выделить те объекты, операции и связи, которые эксперты данной области считают наиболее важными.

Этапы: построение скелетной модели предметной области; изучение существующих в данной области систем; определение сходства и различий между системами; уточнение общей модели для приспособления к нуждам конкретной системы.

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

Эксперт – будущий пользователь системы (бухгалтер, диспетчер).

4. По отдельности все вышеперечисленные подходы сильно зависят от индивидуальных способностей и опыта аналитика. Анализ вариантов предусматривает упорядоченное последовательное их использование. Основан на перечислении и тщательной проработке сценариев работы системы.

5. Метод CRC-карточек удачно реализует на практике предыдущий подход (Class / Responsibilities / Collaborators – Класс / Ответственности / Участники). Сверху на карточке пишется название класса, снизу в левой половине – за что он отвечает, в правой – с кем он сотрудничает. Проход по сценарию приводит к дописыванию новых пунктов в существующих карточках или к созданию новых. Расположение карточек может показать поток сообщений между объектами и иерархию классов.

6. Неформальное описание – радикальная альтернатива классическому анализу (Аббот). Надо описать задачу или ее часть на обычном (человеческом) языке, а потом подчеркнуть существительные и глаголы. Существительные – кандидаты на роль классов, а глаголы могут стать именами операций. Метод можно автоматизировать. Используется в Токийском технологическом институте и в Fujitsu.

7. Вторая альтернатива классической технике – использование структурного анализа как основы объектно-ориентированного проектирования. После его проведения мы уже имеем модель системы, описанную диаграммами потоков данных; исходя из этого, можно приступать к определению классов и объектов любыми другими способами.

Как средство проектирования

Методологические основы UML

– методология процедурно-ориентированного программирования;

– методология объектно-ориентированного программирования;

– методология объектно-ориентированного анализа и проектирования;

– методология системного анализа и системного моделирования

Математические основы UML

– теория множеств (диаграммы Венна);

– теория графов;

– семантические сети

Основные компоненты UML

Язык UML опирается на некоторый набор базовых принципов, применяемых при моделировании сложных систем, а именно:

– принцип абстрагирования, предписывающий включать в модель только те аспекты проектируемой системы, которые имеют непосредственное отношение к выполнению системой своих функций;

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

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

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

Общая схема взаимосвязей моделей и представлений сложной системы в процессе объектно-ориентированного анализа и проектирования представлена на рис. 3.

 

Рисунок 3 – Схема взаимосвязей моделей и представлений сложной

системы

 

Формальное описание языка UML основывается на некоторой общей иерархической структуре модельных представлений, состоящей из четырех уровней:

- мета-метамодель;

- метамодель;

- модель;

- объекты пользователя.

Подробнее о каждом уровне см. в [1-7].

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

1 Диаграмма вариантов использования (use case diagram)

2 Диаграмма классов (class diagram)

3 Диаграммы поведения (behavior diagrams):

3.1 Диаграмма состояний (statechart diagram);

3.2 Диаграмма деятельности (activity diagram)

3.3 Диаграммы взаимодействия (interaction diagrams):

3.3.1 Диаграмма последовательности (sequence diagram);

3.3.2 Диаграмма кооперации (collaboration diagram)

4 Диаграммы реализации (implementation diagrams):

4.1 Диаграмма компонентов (component diagram);

4.2 Диаграмма развертывания (deployment diagram).

 

 

 

Рисунок 4 – Модель сложной системы в нотации UML

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

Рисунок 13 – Пример отношения обобщения между актерами

 

В [2] представлен пример модели системы работы банкомата, которую мы также примем в качестве базового примера. Рассматриваемая система имеет двух актеров – Клиент и Банк, причем главным является Клиент, поскольку инициирует работу. Базовые варианты использования – «Снятие наличных с карточки» и «Получение информации о состоянии счета». Дополнительные сервисы – «Проверка PIN-кода» (используется всегда, поэтому связано отношением включения) и «Печать чека» (используется при желании Клиента увидеть состояние счета не только на экране, но и в печатном виде, поэтому связано отношением расширения). Полученная диаграмма представлена на рис. 14.

Рисунок 14 – Диаграмма вариантов использования для модели

Банкомата

 

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

 

Рисунок 15 – Диаграмма вариантов использования для модели

Рисунок 16 – Изображение класса

 

Как правило, если даже какая-то секция оказывается пустой, в обозначении класса она все равно показывается. Различные примеры изображения классов представлены на рис. 17

 

 

Рисунок 17 – Примеры изображений различных классов

 

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

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

Атрибут класса служит для представления отдельного свойства или признака, который является общим для всех объектов данного класса. Запись атрибута подчиняется синтаксическим правилам:

 

<квантор видимости> <имя атрибута> [кратность]:

<тип атрибута> = <исходное значение> {строка-свойство}

 

Квантор видимости (visibility) может принимать одно из четырех значений:

«+» – public – доступность без ограничений;

«#» – protected – доступность только для данного класса и его потомков;

«–» – private – доступность только для данного класса;

«~» – package – доступность только в пределах данного пакета.

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

Кратность характеризует общее количест во атрибутов данного типа, входящих в состав класса (по умолчанию равно 1), например:

[0..1] – либо такого атрибута нет, либо он есть;

[0..*] – либо такого атрибута нет, либо их сколько угодно;

[1..5] – таких атрибутов может быть от 1 до 5.

Тип атрибута определяется типом данных, например: «цвет: Color» или «имяСотрудника [1..2]: String».

Исходное значение служит для задания некоторого начального значения атрибута в момент создания экземпляра класса, например: «цвет:Color=(255,0,0)» или «имяСотрудника[1..2]:String=“Иван Иванович”».

Строка-свойство служит для указания дополнительных свойств атрибута, например: «заработнаяПлата:Деньги=500{frozen}» – фиксированная сумма.

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

Формат записи операции следующий:

 

<квантор видимости> <имя операции> (список параметров):

<возвращаемое значение> {строка-свойство}

 

Например:

 

+нарисовать (форма: Многоугольник = Прямоугольник)

–изменитьСчет (номерСчета: Integer): Деньги

 

Подробнее об операциях см. в [1-7].

 

Между классами могут быть следующие виды отношений:

– отношение ассоциации (association relationship);

– отношение обобщения (generalization relationship).

– отношение агрегации (aggregation relationship);

– отношение композиции (composition relationship);

– отношение зависимости (dependency relationship).

 

Отношение ассоциации соответствует наличию произвольной взаимосвязи между классами и может быть как ненаправленной (рис. 18), так и направленной (рис. 19). Если связаны два класса друг с другом, ассоциация называется бинарной, если класс связан сам с собой – рефлексивной. Ассоциация может иметь имя и содержать кратности классов-ролей ассоциации.