Проектирование ПО – логически сложная, трудоемкая и

Проектирование ПО – логически сложная, трудоемкая и длительная работа.
В начале 70-х годов в США был отмечен кризис программного обеспечения. Это
проявилось в том, что большие проекты стали выполняться с отставанием от
графика или с превышением сметы расходов. Программный продукт не обладал
требуемыми функциональными возможностями, производительность его была
низкой, качество не устраивало потребителя. Аналитические исследования и
обзоры, которые провели аналитики оказались не слишком обнадеживающими.
После анализа более 23 000 проектов оказалось: только 16,5% проектов
завершились в срок и не превысили плановые затраты; 52,7% проектов
завершились с опозданием, а расходы превысили запланированный бюджет,
требуемые функции не были реализованы в полном объеме; 31,1% проектов были
закрыты до завершения. В среднем бюджет среднего проекта превышался на 89%,
а срок выполнения на 122%.
Причинами возможных неудач являются: неточные требования к ПО,
отсутствие нужных ресурсов, плохое планирование, частое изменение требований
заказчика, новизна используемой технологии для организации, неграмотное
управление проектом. Причина многих неудач кроется в том, что многие проекты
выполнялись в экстремальных условиях, то есть проектирование выполнялось в
сжатые сроки, количество разработчиков уменьшено примерно в половину, вдвое
урезаны бюджет и ресурсы, а требования к функциям и производительности ПО
существенно завышены.
Потребность контролировать процесс разработки ПО, гарантировать
сроки, стоимость и качество проекта привело к тому, что в конце 70-х годов
начался переход к индустриальным способам создания ПО, под общим названием
программная инженерия.
В процессе развития программной инженерии выделяют два этапа: 70-е и
80-е годы – систематизация и стандартизация ПО (на основе структурного
подхода) и 90-е годы – переход к сборочному, индустриальному способу
создания ПО (на основе объектно-ориентированного подхода).
Проектирование ПО является формальным процессом, который можно
изучать и совершенствовать.
Современные крупные проекты имеют следующие особенности:
1. Сложность описания продукта требует тщательного моделирования и
анализа данных и процессов;
2. Существование тесно взаимодействующих подсистем, имеющих
локальные задачи;
3. Отсутствие полных аналогов, что ограничивает использование типовых
проектных решений;
4. Необходимость согласования существующих и вновь разрабатываемых
приложений;
5. Функционирование в неоднородной среде и на разных аппаратных
платформах;
6. Разобщенность
отдельных
групп
разработчиков,
их
разная
квалификация;
7. Временная длительность проекта
1
Сложность ПО является существенным, а не второстепенным свойством,
и она нелинейно растет при увеличении размера ПО. Сложность мешает
взаимодействию разработчиков, повышает стоимость разработки, затягивает
график работ, сдерживает развитие ПО, возможность добавления новых функций.
Для успешной реализации проекта объект проектирования должен быть
правильно описан, т. е. должны быть построены полные и не противоречивые
модели архитектуры ПО, описаны совокупности структурных элементов системы,
связей между ними, поведение элементов системы в процессе их взаимодействия,
а также создана иерархия подсистем, объединяющих структурные элементы.
Архитектура ПО – это организационная структура и связанное с ней
поведение системы. Архитектура допускает рекурсивное разбиение системы на
части, которые взаимодействуют между собой через интерфейсы. Допустимо
разбиение на отношения, связывающие эти части, и на ограничения, которые
соединяют части в систему.
Модель системы – это полное описание системы ПО с определенной точки
зрения. Модели являются средствами
для визуализации, описания,
проектирования и документирования архитектуры системы. Моделирование
является самой важной частью проектирования ПО. Модели строятся для того,
чтобы понять структуру будущей системы, облегчить управление процессом ее
создания, а также документировать проектные решения. Сложность систем
неуклонно повышается, поэтому важно иметь эффективные методы
моделирования.
При этом важно наличие строгого стандарта языка
моделирования.
Язык моделирования должен включать: элементы модели, нотацию и
руководство по эксплуатации. Нотация – это визуальное представление
элементов моделирования.
Очевидно, что конечная цель разработки ПО – это не моделирование, а
получение работающих приложений (кода). Диаграммы – это только наглядные
изображения, поэтому, используя графические языки моделирования, нужно
понимать, чем они могут помочь при написании кода программ.
Полезно использовать графические языки моделирования в случаях:
1. При изучении методов проектирования;
2. При общении с экспертами организации. Графические модели
представляют архитектуру системы и объясняют, что эта система будет
делать.
3. При получении общего представления о системе. Графические модели
показывают, какого рода абстракции существуют в системе и какие
части системы нуждаются в уточнении.
2
СУЩНОСТЬ ОБЪЕКТНО – ОРИЕНТИРОВАННОГО
ПОДХОДА
Изучение и работа с любой сложной системы требует применения техники
декомпозиции – разбиения на составляющие элементы. Известны две схемы
декомпозиции: алгоритмическая декомпозиция и объектно-ориентированная
декомпозиция. В основе алгоритмической (структурной) декомпозиции лежит
разбиение по действиям – алгоритмам. Эта схема представления применяется в
обычных программных системах (ПС).
При
объектно-ориентированной
декомпозиции
будущая
система
разбивается на автономные лица – объекты реального или виртуального мира.
Эти «лица» (объекты) - более крупные элементы, каждый из которых несет в себе
описание действий и описание данных. Статическая структура системы
описывается с помощью объектов и связей между ними, а поведение системы
описывается с помощью сообщений, которыми объекты обмениваются между
собой. Каждый объект системы обладает своим собственным поведением, которое
моделирует поведение объекта реального мира. С объектно – ориентированным
проектированием ПО тесно связаны: объектно – ориентированная архитектура,
объектно – ориентированные операционные системы, а также объектно –
ориентированные языки программирования. На объектный подход оказали
влияние также методы моделирования баз данных, особенно метод «сущность –
связь».
Концептуальной (теоритической) основой объектно – ориентированного
подхода является объектная модель. Основными элементами объектной модели
являются:
1. абстрагирование
2. инкапсуляция
3. модульность
4. иерархия
Кроме основных, имеются три дополнительных элемента, которые не
являются обязательными:
1. типизация
2. параллелизм
3. устойчивость
Абстрагирование
Абстракция – это такая характеристика сущности, которая отличает ее от
других сущностей. Аппарат абстракции – удачный инструмент для борьбы со
сложностью реальных систем. Определяя понятия для какой-либо задачи, мы
отвлекаемся (абстрагируемся) от несущественных характеристик конкретных
объектов, определяя только существенные характеристики. Абстрагирование –
это выделение существенных характеристик некоторого объекта, которые
отличают его от всех других видов объекта и четко определяют его
концептуальные границы относительно дальнейшего анализа. Абстрагирование
сосредотачивается на внешних особенностях объекта и позволяет отделить самые
существенные особенности его поведения от деталей их реализации. Например, в
3
абстракции «часы» мы выделяем характеристику «показывать время», отвлекаясь
от таких характеристик конкретных часов, как форма, цвет, материал, цена,
изготовитель.
Выбор правильного набора абстракций для заданной предметной области –
главная задача объектно – ориентированного проектирования.
Инкапсуляция – это процесс отделения друг от друга отдельных элементов
объекта, которые определяют устройство и поведение объекта. Инкапсуляция
служит для изоляции интерфейса объекта, который отражает его внешнее
поведение, от внутренней реализации объекта.
Интерфейс – это набор операций, которые определяют услуги класса или
компонента. Интерфейс описывает поведение элемента, видимое извне.
Объектный подход предполагает, что с собственными ресурсами могут
работать только методы самого класса, а от внешней среды эти ресурсы скрыты.
Обычно скрывается структура объекта и реализация его методов.
Абстрагирование и инкапсуляция являются взаимодополняющими операциями:
абстрагирование сосредотачивает свое внимание на внешних особенностях
объекта, а инкапсуляция (ограничение доступа) не позволяет объектам –
пользователям различать внутреннее устройство объекта.
Модульность – это свойство системы, которое разбивает систему на ряд
внутренне связных, но слабо связанных между собой модулей. Инкапсуляция и
модульность создают барьеры между абстракциями. Общая цель декомпозиции на
модули – уменьшение сроков разработки и стоимости ПО за счет выделения
модулей, которые проектируются и изменяются независимо. Каждая модульная
структура должна быть достаточно простой, чтобы быть полностью понятной.
Иерархия – это упорядоченная система абстракций, расположение
абстракций по уровням. Основными
видами иерархических структур
применительно к сложным системам являются структура классов (иерархия по
номенклатуре) и структура объектов (иерархия по составу). Т. е. существует
иерархия из классов и иерархия из объектов. Примерами иерархии классов
является простое и множественное наследование, где один класс разделяет
структуру или поведение, определенное в одном другом классе (единичное
наследование) или один класс разделяет структуру или поведение нескольких
других классов (множественное наследование).
Типизация – это ограничение, накладываемое на класс объектов. Оно
препятствует взаимозаменяемости различных классов. Типизация позволяет
защититься от использования объектов одного класса вместо другого.
Параллелизм – это свойство объектов находиться в активном или
пассивном состоянии и различать активные и пассивные объекты между собой.
Активный объект имеет собственный канал (поток) управления, пассивный – нет.
Активный элемент автономен, он может проявлять свое поведение без
воздействия со стороны других объектов. Пассивный объект, наоборот, может
изменять свое состояние только под воздействием других объектов.
Устойчивость – это свойство объекта существовать во времени и/или
пространстве. Во времени – это вне зависимости от процесса, создавшего данный
4
объект, в пространстве – это при перемещении объекта из адресного
пространства, в котором он был создан.
Объект
Основные понятия объектно – ориентированного подхода - это объект и
класс. Объект – это конкретное представление абстракции. Объект – это реальный
предмет или явление, имеющее четко определяемое поведение. Объект обладает
индивидуальностью, состоянием и поведением. Структура и поведение
однотипных объектов определяются в их общем классе. Термины экземпляр
класса и объект эквивалентны.
Индивидуальность – это характеристика объекта, которая отличает его от
всех других объектов.
Состояние объекта – это перечень всех свойств объекта и текущие значения
каждого из этих свойств.
Объекты не существуют изолированно друг от друга. Они подвергаются
воздействию или сами воздействуют на другие объекты.
Поведение характеризует то, как объект воздействует на другие объекты.
Поведение объекта полностью определяется его действиями.
Стул
Стоимость
Вес
Размеры
Цвет
Положение
Купить()
Продать()
Взвесить()
Переместить()
Покрасить()
Свойства
Операции
Состояние объекта равно перечню свойств плюс значению свойств.
Представление объекта с именем Стул
Операция - это определенное воздействие одного объекта на другой с целью
вызвать соответствующую реакцию.. Возможны пять видов операций клиента над
объектом
1. модификатор (изменяет состояние объекта)
2. селектор (дает доступ к состоянию, но не изменяет его)
5
3. итератор (доступ к содержанию объекта по частям, в строго
определенном порядке)
4. конструктор (создает объект и инициализирует его состояние)
5. деструктор (разрушает объект и освобождает занимаемую им память)
Примеры операций
Модификатор
пополнеть (кг)
Селектор
какойвес():integer
Итератор
показатьАссортиментТоваров
():string
Конструктор
создатьРобот (параметры)
Деструктор
уничтожитьРобот ()
В объектных и объектно – ориентированных языках операции над
объектами
называются методами. Методы являются составной частью
определения класса.
Виды отношений между объектами
Связи. Связи – это физическое или понятийное соединение между
объектами. Связь обозначает соединение, с помощью которого объект-клиент
вызывает операции объекта – поставщика или один объект перемещает данные к
другому объекту.
Связи между объектами обозначаются соединительными линиями. Связи
представляют возможные пути для передачи сообщений. Сами сообщения
показаны стрелками, отмечающими их направления, и помечены именами
вызываемых операций.
Агрегация. Связи обозначают равноправные отношения между объектами.
Агрегация обозначает отношения объектов в иерархии «целое/часть». Агрегация
обеспечивает возможность перемещения от целого (агрегата) к его частям
(свойствам).
Итак, между объектами существуют два вида отношений – связи и
агрегация. Какое из них выбрать? При выборе отношения нужно учитывать
следующие факторы:
1. связи обеспечивают низкое сцепление между объектами
2. агрегация инкапсулирует части как секреты целого.
Класс
Класс – это множество объектов, связанных общностью структуры и
поведения. Любой объект является экземпляром класса. Класс – описание
множества объектов, которые разделяют одинаковые свойства, операции,
отношения и семантику (смысл). Определение классов и объектов – одна из
самых сложных задач объектно – ориентированного проектирования. Различают
внутреннее представление класса (реализацию) и внешнее представление класса –
интерфейс. Интерфейс объявляет возможности класса, но скрывает его структуру
и поведение. Интерфейс показывает внешнему миру класс как абстракцию, его
6
внешний облик. Интерфейс в основном состоит из объявлений всех операций,
применимым к экземплярам класса. Он может включать объявления типов,
переменных, констант и исключений, необходимых для полноты данной
абстракции.
Класс
Интерфейсные части:
Публичная
Защищенная
Приватная
Реализация
Интерфейс может быть разделен на три части:
1. публичную (public), объявления которой доступны всем клиентам
2. защищенную (protected), объявления которой доступны только классу,
его подклассам и его друзьям
3. приватную (private), объявления которой доступны только самому
классу и его друзьям.
Другом называют класс, который имеет доступ ко всем частям этого класса.
Реализация класса описывает секреты поведения класса. Она включает
реализацию всех операций, определенных в интерфейсе класса.
Виды отношений между классами
Всего существует четыре основных вида отношений между классами:
1. ассоциация – она фиксирует структурные отношения, т.е. связи
между экземплярами классов
2. зависимость – она отображает влияние одного класса на другой
класс
3. обобщение-специализация
4. целое – часть
Для того, чтобы реализовать основные отношения большинство объектно –
ориентированных языков программирования поддерживают следующие
отношения:
1. ассоциация
2. наследование
3. агрегация
4. зависимость
5. конкретизация
6. метакласс
7. реализация
Ассоциация обеспечивает взаимодействие объектов, принадлежащим разным
классам. Она является клеем, соединяющей воедино все части программной
системы. Благодаря ассоциациям мы получаем работающую систему. Агрегация
обеспечивает отношения целое – часть, объявляемые для экземпляров классов.
7
Зависимость часто представляется в виде частной формы – использования,
которое фиксирует отношение между клиентом, запрашивающим услугу и
сервером, предоставляющим эту услугу.
Конкретизация - это разновидность отношения обобщение – специализация.
Применяется в некоторых языках программирования.
Метакласс – это класс классов, понятие, которое позволяет обращаться с
классами как с объектами. Отношения метакласса также поддерживаются в
других языках программирования.
Реализация - это отношение, при котором класс – приемник обеспечивает
свою собственную реализацию интерфейса другого класса – источника. Здесь
речь идет о наследовании интерфейса.
Наследование – это отношение, при котором один класс разделяет
структуру и поведение, определенные в одном другом классе (простое
наследование) или определенные во многих других классах (множественное
наследие). Наследование означает построение новых классов на основе
существующих с возможностью добавления или переопределения данных и
методов. Между n классами наследование определяет иерархию обобщение –
специализация, при котором подкласс наследует от одного или нескольких более
общих суперклассов.
Полиморфизм - это способность класса принадлежать более чем одному
типу. Полиморфизм – это возможность с помощью одного имени обозначать
операции из различных классов
Наследование и полиморфизм обеспечивают возможность определения
новых функций классов с помощью создания производных классов – потомков
базовых классов. Потомки наследуют характеристики родительских классов без
изменения их первоначального описания. При необходимости потомки добавляют
собственные структуры и методы.
Унифицированный язык моделирования UML
Большинство существующих методов объектно – ориентированного анализа
и проектирования включают в себя язык моделирования и описание процесса
моделирования. Язык моделирования – это нотация, в основном графическая.
Нотация используется методом для описания проектов. Нотация – это
совокупность графических объектов, которые используется в моделях. Нотация
является синтаксисом языка моделирования. Процесс – это описание шагов,
которое необходимо выполнить при разработке проекта.
UML – это не визуальный язык программирования, но его модели прямо
транслируются в текст на языках программирования (Java, C++, Visual Basic,
Ada95, Object Pascal) и даже в таблицы для реляционной базы, поэтому UML
называют визуальным языком моделирования.
Главными при разработки языка UML были следующие цели:
1. предоставить пользователю язык визуального моделирования, который
позволяет разрабатывать осмысленные модели и обмениваться ими
8
2. предусмотреть способы расширяемости и специализации для
расширения базовых концепций
3. обеспечить независимость от конкретных языков программирования и
процессов разработки
4. обеспечить формальную основу для понимания этого языка
моделирования
5. стимулировать
рост
рынка
объектно
–
ориентированных
инструментальных средств
6. внедрять лучший практический опыт
Создателями UML считаются Гради Буч, Джеймс Рамбо, Ивар Якобсон.
Разработки велись в компании Rational Software. Язык UML принят всеми
крупнейшими компаниями – производителями ПО. Создатели UML представляют
его как язык для определения, представления, проектирования и
документирования программных систем, технических, организационных,
экономических и других.
В языке UML используются: предметы, отношения и диаграммы.
Предметы – это абстракции, которые являются основными элементами в
модели, отношения связывают эти предметы, а диаграммы группируют коллекции
предметов.
Предметы в UML
В UML имеются четыре разновидности предметов:
1. структурные предметы
2. предметы поведения
3. группирующие предметы
4. поясняющие предметы
Эти
предметы
являются
базовыми
объектно–ориентированными
строительными блоками. Они используются для написания моделей.
Структурные предметы являются существительными в UML моделях.
Они представляют статические части модели, т. е. понятийные или физические
элементы. Рассмотрим восемь разновидностей структурных предметов.
1. Класс – описание множества объектов, которые разделяют одинаковые
свойства, операции, отношения и семантику (смысл). Класс реализует один или
несколько интерфейсов. Графически класс отображается в виде прямоугольника,
который обычно имеет секции с именем, свойствами (атрибутами) и операциями
Человек
Имя
Возраст
Вес
Родиться()
Креститься()
Поправиться()
Похудеть()
2. Интерфейс – набор операций, которые определяют услуги класса или
компонента. Интерфейс описывает поведение системы, видимое извне.
9
Интерфейс может предоставлять полные услуги класса или компонента или часть
таких услуг. Интерфейс определяет набор спецификаций операций, но не набор
реализаций операций. Спецификация – это декларативное описание некоторой
сущности, предмета. Графически интерфейс изображается в виде кружка с
именем, имя обычно начинается с буквы I. Интерфейс редко показывают
самостоятельно, его присоединяют к классу или компоненту, который реализует
интерфейс.
IУчеба
3. Кооперация характеризует взаимодействие и является совокупностью ролей и
других элементов, которые работают вместе, для обеспечения коллективного
поведения, более сложного, чем простая сумма всех элементов. Кооперация имеет
структурную и поведенческую части. Конкретный класс может участвовать в
нескольких кооперациях. Графически кооперация изображается как пунктирный
эллипс, в который вписывается ее имя.
Обслуживание клиента
4. Актер – это набор согласованных ролей, которые могут играть пользователи
при взаимодействии с системой (ее элементами Use Case). Каждая роль требует от
системы определенного поведения. Актер изображается как проволочный
человечек с именем
5. Элемент Use Case (Прецедент) – это описание последовательности действий
(или нескольких последовательностей), выполняемых системой для одного
актера. Эти действия производят видимый для актера результат. В модели
элемент Use Case применяется для структурирования предметов поведения, он
реализуется кооперацией и изображается как сплошной эллипс, в который
вписывается его имя.
Обработка заказов
6. Активный класс – это класс, чьи объекты активны и имеют один или
несколько процессов (потоков). Такой класс может и вызывать управляющую
деятельность. Активный класс похож на обычный класс, за исключением того,
что его объекты действуют одновременно с объектами других классов. Активный
10
класс изображается как утолщенный прямоугольник, обычно включающий имя,
свойства и операции.
ЦентрУправления
Запустить()
Остановить()
7. Компонент – это физическая и заменяемая часть системы, которая
соответствует набору интерфейсов и обеспечивает реализацию этого набора
интерфейсов. В систему включаются компоненты, которые являются
результатами процесса разработки (файлы исходного кода), а также
разновидности используемых компонентов. Обычно компоненты – это
физическая упаковка разных логических элементов (классов, интерфейсов и
коопераций). Компонент изображается как прямоугольник со вкладками, обычно
включающий имя.
Proxy.cpp
8. Узел - это физический элемент, который существует в период работы системы,
узел имеет память и возможность обработки. В узле размещается набор
компонентов, который может перемещаться от узла к узлу. Узел изображается как
куб с именем.
Бизнес-логика
Предметы поведения – это динамические части UML-моделей. Они являются
глаголами моделей, представляют поведение во времени и пространстве.
Существуют две основные разновидности предметов поведения.
1. Взаимодействие – поведение, в которое входит набор сообщений.
Сообщениями обменивается набор объектов в конкретном контексте для
достижения определенной цели. Взаимодействие может определять динамику как
11
группы объектов так и отдельной операции. Элементами взаимодействия
являются
сообщения,
последовательность
действий
и
связи.
Последовательность действий – это поведение, вызываемое сообщением. Связи –
это соединения между объектами. Сообщение изображается в виде направленной
стрелки с именем ее операции.
display
2. Конечный автомат – это поведение, которое показывает
последовательность состояний объекта или взаимодействия, которые
выполняются в ходе существования объекта в ответ на события. С помощью
конечного автомата можно определять поведение индивидуального класса или
кооперации классов. Элементами конечного автомата являются состояния,
переходы (от состояния к состоянию), события (предметы, вызывающие
переходы) и действия (реакции на переход). Состояние изображается как
закругленный прямоугольник, обычно включающий его имя и подсостояния.
Регулирование
Эти два элемента – взаимодействия и конечные автоматы являются базисными
предметами поведения, они могут включаться в UML-модели. Семантически (по
смыслу) взаимодействия и конечные автоматы объединяются со структурными
элементам, такими как классы, кооперации, объекты.
Группирующие предметы – это организационные части UML-моделей. Это
ящики, по которым может быть разложена модель. Есть только одна
разновидность группирующего объекта – пакет. Пакет – общий способ для
распределения элементов по группам. В пакет могут помещаться структурные
предметы, предметы поведения и другие группировки предметов. В отличие от
компонента, который существует в период выполнения, пакет чисто
концептуальное (теоретическое) понятие. Это значит, что пакет существует
только в период разработки. Пакет изображается как папка с закладкой, на
которой обозначено его имя и иногда его содержание.
Интерфейсные эл-ты
Поясняющие предметы – разъясняющие части UML-моделей. Они являются
замечаниями, которые можно писпользовать для описания, объяснения,
комментария любого элемента модели. Примечание – единственный вариант
поясняющего предмета. Примечание – значок для показа на диаграмме
12
ограничений и
замечаний, примечание присоединяется к элементу или
совокупности элементов. Примечание изображается в виде прямоугольника с
загнутым углом, в который вписывается текстовый или графический
комментарий.
Критичная по
длительности
Кооперации, паттерны, их классификация
Кооперации – это средство представления комплексных решений в разработке ПО
на высшем архитектурном уровне. Кооперации обеспечивают компактность
реализации программного продукта, или, иначе несут в себе реализации потоков
управления и данных. Кооперации называют реализациями элемента Use Case.
Если заглянуть под обложку кооперации, мы увидим набор разнообразных
диаграмм.
При реализации проектов по разработке программных систем и моделированию
бизнес-процессов встречаются ситуации, когда решение проблем в различных
проектах имеют сходные структурные черты. Попытки выявить похожие схемы
или структуры в рамках объектно-ориентированного анализа и проектирования
привели к появлению понятия паттерна, которое из абстрактной категории
превратилось в непременный атрибут современных CASE-средств
Параметризованные или настраиваемые кооперации называются паттернами или
образцами. Паттерн – это решение типичной проблемы в определенном
контексте.
Параметры
настройки
Имя паттерна
Паттерны различаются степенью детализации и уровнем абстракции.
Предлагается следующая общая классификация паттернов по категориям их
применения:




Архитектурные паттерны
Паттерны проектирования
Паттерны анализа
Паттерны тестирования
13

Паттерны реализации
Архитектурные паттерны(Architectural patterns) - множество предварительно
определенных подсистем со спецификацией их ответственности, правил и
базовых принципов установления отношений между ними.
Архитектурные паттерны предназначены для спецификации фундаментальных
схем структуризации программных систем. Наиболее известными паттернами
этой категории являются паттерны GRASP (General Responsibility Assignment
Software Pattern). Эти паттерны относятся к уровню системы и подсистем, но не к
уровню классов. Как правило, формулируются в обобщенной форме, используют
обычную терминологию и не зависят от области приложения. Паттерны этой
категории систематизировал и описал К. Ларман.
Паттерны проектирования (Design patterns) - специальные схемы для
уточнения структуры подсистем или компонентов программной системы и
отношений между ними.
Паттерны проектирования описывают общую структуру взаимодействия
элементов программной системы, которые реализуют исходную проблему
проектирования в конкретном контексте. Наиболее известными паттернами этой
категории являются паттерны GoF (Gang of Four), названные в честь Э. Гаммы, Р.
Хелма, Р. Джонсона и Дж. Влиссидеса, которые систематизировали их и
представили общее описание. Паттерны GoF включают в себя 23 паттерна. Эти
паттерны не зависят от языка реализации, но их реализация зависит от области
приложения.
Паттерны анализа (Analysis patterns) - специальные схемы для представления
общей организации процесса моделирования.
Паттерны анализа относятся к одной или нескольким предметным областям и
описываются в терминах предметной области. Наиболее известными паттернами
этой группы являются паттерны бизнес-моделирования ARIS (Architecture of
Integrated Information Systems), которые характеризуют абстрактный уровень
представления бизнес-процессов. В
дальнейшем
паттерны анализа
конкретизируются в типовых моделях с целью выполнения аналитических оценок
или имитационного моделирования бизнес-процессов.
Паттерны тестирования (Test patterns) - специальные схемы для представления
общей организации процесса тестирования программных систем.
К этой категории паттернов относятся такие паттерны, как тестирование черного
ящика, белого ящика, отдельных классов, системы. Паттерны этой категории
систематизировал и описал М. Гранд. Некоторые из них реализованы в
инструментальных средствах, наиболее известными из которых является IBM Test
14
Studio. В связи с этим паттерны тестирования иногда называют стратегиями или
схемами тестирования.
Паттерны реализации (Implementation patterns) - совокупность компонентов и
других элементов реализации, используемых в структуре модели при написании
программного кода.
Эта категория паттернов делится на следующие подкатегории: паттерны
организации программного кода, паттерны оптимизации программного кода,
паттерны устойчивости кода, паттерны разработки графического интерфейса
пользователя и др. Паттерны этой категории описаны в работах М. Гранда, К.
Бека, Дж. Тидвелла и др. Некоторые из них реализованы в популярных
интегрированных средах программирования в форме шаблонов создаваемых
проектов. В этом случае выбор шаблона программного приложения позволяет
получить некоторую заготовку программного кода
Отношения в UML
В UML имеются четыре вида отношений: 1) зависимость;
2) ассоциация; 3) обобщение; 4) реализация.
Эти отношения являются базовыми строительными блоками отношений.
Они используются при написании моделей.
1.
Зависимость – семантическое отношение между двумя предметами.
Изменение в одном предмете (независимом предмете) может влиять на семантику
другого предмета (зависимого предмета). Зависимость отображается в виде
пунктирной линии, возможно направленной на независимый предмет и иногда
имеющей метку.
2. Ассоциация – структурное отношение, которое описывает набор связей,
которые соединяют объекты между собой. Агрегация – это специальная
разновидность ассоциации, она показывает структурное отношение между целым
и его частями. Ассоциация изображается в виде сплошной линии, возможно
направленной, иногда имеющей метку и часто мощность и имена ролей.
Роль- это имеющее имя специфическое поведение какого-то объекта в отношении
другого объекта. Роль может быть статической и динамической.
1
*
Заказчик
Заказ
15
3. Обобщение – это отношение специализации/обобщения, в котором объекты
специализированного элемента (потомка, ребенка) могут заменять объекты
обобщенного элемента (предка, родителя). Иначе говоря, потомок разделяет
поведение и структуру родителя. Обобщение изображается в виде сплошной
стрелки с полым наконечником, указывающим на родителя.
4. Реализация – это смысловое отношение между классификаторами, где один
классификатор определяет контракт, который другой классификатор обязуется
выполнять. К классификаторам относятся классы, интерфейсы, компоненты,
элементы Use Case, кооперации. Отношения реализации применяют в двух
случаях: между интерфейсами и классами (или компонентами), которые
реализуют интерфейсы а также между элементами Use Case и кооперациями,
которые реализуют элементы Use Case. Реализация изображается как нечто
среднее между обобщением и зависимостью.
Диаграммы в UML
Диаграмма – графическое представление множества элементов. Обычно
диаграмма изображается как связный граф, который состоит из вершин
(предметов) и дуг (отношений). Диаграммы рисуют для визуализации системы с
разных точек зрения. Затем диаграммы
собираются в систему. Обычно
диаграмма дает неполное представление элементов, которые составляют систему.
Теоретически диаграмма может содержать любую комбинацию предметов и
отношений, но на практике ограничиваются малым количеством комбинаций.
Набор диаграмм для моделирования
1. диаграммы вариантов использования (use case diagrams) – они
моделируют требования к системе или бизнес-процессы организации.
2. диаграммы классов (class diagrams) –моделируют статическую структуру
классов системы и связей между ними.
3. диаграмм поведения системы (behavior diagrams)
4. диаграммы взаимодействия (interaction diagrams) –моделируют процесса
обмена сообщениями между объектами. Существуют два вида диаграмм
взаимодействия:
 диаграммы последовательности (sequence diagrams)
 кооперативные диаграммы (collaboration diagrams)
5. диаграммы состояний (statechart diagrams) – они моделируют поведение
объектов системы при переходе их одного состояния в другое.
6. диаграммы деятельности (activity diagrams) – используются для
моделирования поведения системы в рамках различных вариантов
использования или моделирования деятельностей.
16
7. диаграммы реализации (implementation diagrams): они состоят из двух
видов:
 диаграммы компонентов(component diagrams) – для моделирования
иерархии компонентов (подсистем) системы
 диаграммы размещения (deployment diagrams) – для моделирования
физической архитектуры системы.
Варианты использования Диаграмма Use Case определяет поведение системы с
точки зрения пользователя. Вариант использования представляет собой
последовательность действий, выполняемых системой в ответ на событие,
которое вызывается внешним объектом. Диаграмма Use Case - это главное
средство для первичного моделирования динамики системы, она используется для
определения требований к разрабатываемой системе, фиксации этих требований в
форме, которая позволит проводить дальнейшую разработку. В состав диаграмм
Use Case входят элементы Use Case, актеры, отношения зависимости,
обобщения и ассоциации. В диаграмму Use Case могут включаться примечания
и ограничения. Диаграммы Use Case могут содержать пакеты, они используются
для группировки элементов модели в крупные фрагменты. Вершинами в
диаграмме Use Case являются актеры и элементы Use Case, их обозначения:
человечек и эллипс. Линии и стрелки – это разные связи между действующими
лицами и вариантами использования. Актеры представляют внешний мир,
который нуждается в работе системы. Элементы Use Case являются действиями,
которые выполняет система в интересах актеров. Актер – это роль объекта вне
системы, который прямо взаимодействует с ее частью – конкретным элементом
Use Case. Различают актеров и пользователей. Пользователь – это физический
объект, который использует систему. Он может играть несколько ролей и поэтому
может моделироваться несколькими актерами. Также актером могут быть разные
пользователи.
Пример. Для коммерческого летательного аппарата можно выделить двух
актеров: пилота и кассира. Сидоров – пользователь, который иногда действует как
пилот, а иногда как кассир. В зависимости от роли Сидоров взаимодействует с
разными элементами Use Case.
Летательный аппарат
Выполнение полета
Пилот
Кассир
Проверка режима
Продажа билетов
Модель (диаграмма) Use Case
17
Вариант использования (или элемент) – это описание последовательности
действий, которые выполняются системой и производят для отдельного актера
видимый результат. Один актер может использовать несколько вариантов
использования; один вариант использования может иметь несколько актеров,
использующих его.
Отношения в диаграммах использования (Use Case)
Между актером и элементом Use Case возможен только один вид
отношения – ассоциация, отображающая их взаимодействие. Как и любая другая
ассоциация, она может быть помечена именем, ролями, мощностью.
*
1
Размещение
Заказа
Отношение ассоциации
Между актерами допустимо отношение обобщения, означающее, что
экземпляр потомка может взаимодействовать с такими же разновидностями
вариантов использования, что и экземпляр родителя.
1
*
Размещение
Заказа
Родитель
1
*
Определение
кредита
Потомок
Отношение обобщения между актерами
Между элементами Use Case определены отношение обобщения и две
разновидности отношения зависимости – включения и расширения. Отношение
18
обобщения показывает, что потомок наследует поведение родителя. Потомок
может дополнять или изменять
поведение родителя. Элемент Use Case,
являющийся потомком, может замещать элемент Use Case, являющийся
родителем, в любом месте диаграммы.
Элемент Use Case
Родитель
Элемент Use Case
Потомок
Отношение обобщения между элементами Use Case
Отношение включения между элементами Use Case означает, что базовый
элемент Use Case явно включает поведение другого элемента Use Case в точке,
которая определена в базе. Включаемый элемент Use Case никогда не
используется самостоятельно – он может быть только частью другого, большего
элемента Use Case. Отношение включения является примером отношения
делегации. При этом в отдельное место (включаемый элемент Use Case)
помещается определенный набор обязанностей системы. Далее остальные части
системы могут включать в себя эти обязанности.
«include»
Базовый элемент
Use Case
Включаемый элемент
Use Case
Отношение включения между элементами Use Case
Отношение типа расширение
применяется тогда, когда один вариант
использования подобен другому, но несет несколько большую нагрузку. Т.е.
базовый элемент Use Case неявно включает поведение другого элементаUse Case
в точке, которая определяется косвенно расширяющим элементом Use Case.
Базовый элемент Use case может расширяться только в определенных точках
расширения. Отношение расширения применяется для моделирования
выбираемого поведения системы. Таким способом можно отделить обязательное
поведение системы от необязательного.
«extend»
Базовый элемент
Use Case
Элемент Use Case
расширения
Отношение расширение между элементами
Use Case
19
БАНК
Снять деньги
«extend»
Кредитная
Заказчик
«include»
Идентификация
клиента
Ускоренное снятие
система
денег
Простейшая диаграмма Use Case для банка
Работа с элементами Use Case
Элемент Use Case описывает, что должна делать система, но не определяет, как
она должна это делать. При моделировании это позволяет отделять внешнее
представление системы от ее внутреннего представления. Поведение элемента
Use Case описывается потоком событий. Начальное описание выполняется в
текстовой, понятной для пользователя форме. В потоке событий выделяют:
основной поток и альтернативные потоки поведения; разработчик должен
подробно описать как и когда начинается и заканчивается вариант использования
(элемент Use Case); когда элемент Use Case взаимодействует с актерами; какими
данными обмениваются актер и система.
Спецификация элементов Use Case
Итогом разработки элемента Use Case является его спецификация.
Спецификация элементов Use Case – основной источник информации для
выполнения анализа и проектирования системы. Важно, чтобы содержание
спецификации было представлено в полном объеме. Спецификация включает
главный поток, подпотоки и альтернативные потоки поведения.
Диаграммы классов
Диаграммы классов являются основными диаграммами объектноориентированного проектирования. Диаграмма классов определяет типы объектов
системы и разного рода статические связи, которые существуют между ними.
Построение диаграмм классов можно рассматривать в трех аспектах:
1. концептуальный аспект – диаграммы класса показывают понятия изучаемой
предметной области. Эти понятия соответствуют реализующим их классам, но
прямое соответствие часто отсутствует. Концептуальная диаграмма классов не
зависит от средств реализации, т.е. языка программирования
2. аспект спецификации – модель спускается на уровень ПО, но рассматриваются
только интерфейсы, а не программная реализация классов.
20
3. Аспект реализации – модель действительно определяет реализацию классов
ПО, эта модель самая важная для программистов.
Вершина в диаграмме классов – класс. Обозначение класса:
ИМЯ
Свойства
Операции
Имя класса указывается всегда, свойства и операции – выборочно.
Можно задать область действия свойства (операции). Если свойство
(операция) подчеркивается, то областью действия свойства является класс, иначе
областью действия является экземпляр. Если областью действия свойства
является класс, то все его объекты используют общее значение этого свойства, в
противном случае у каждого экземпляра свое значение свойства.
Диалоговое окно
заголовок:Заголовок окна
Область действия экземпляра
идентификатор Вида:Longint
Область действия класс
Свойства уровней класса и экземпляра
Свойства Общий синтаксис описания свойства имеет вид:
Видимость Имя [Множественностъ]: Тип=НачальнЗначение
{Характеристики}
В языке UML определены три уровня видимости:
Public- любой клиент класса может иметь свойство (операцию), обозначается
символом +
Protected – любой наследник класса может иметь свойство (операцию),
обозначается символом #
Private – свойство (операция) может использоваться только самим классом,
обозначается символом Если видимость не указана, свойство имеет публичную видимость.
Примеры объявления свойств:
Начало
Только имя
+начало
Видимость и имя
Начало:Координаты
Имя и тип
имяФамилия[0..1]:String
Имя, множественность, тип
ЛевыйУгол:Координаты=(0,10) имя, тип, начальное значение
Сумма:integer {frozen}
Имя и характеристика
Операции
21
Операции – это процессы, которые выполняются классом. Наибольшее
соответствие существует между операциями и методами над классами. В
спецификации операции соответствуют общим методам над типом класса. Тип –
это стереотип класса, он используется для описания области значений объекта
вместе с операциями, которые применяются к этим объектам.
Общий синтаксис представления операции имеет вид:
Видимость Имя (Список параметров): Возвращаемый тип {Строка свойств}
Признак видимости - + # Имя – символьная строка
Список параметров – содержит необязательные аргументы, синтаксис которых
совпадает с синтаксисом атрибутов
Возвращаемый тип - необязательная спецификация, зависит от конкретного
языка программирования
Строка свойств показывает значения свойств, которые применяются к данной
операции
Примеры объявления операций:
Записать
Только имя
+записать
Видимость и имя
Зарегистрировать(и:Имя,ф:Фамилия Имя и параметры
Баланс счета ():Integer
Имя и возвращаемый тип
Нагревать () {guarded}
Имя и характеристика
Необходимо различать
операции, которые изменяют состояние класса, и
операции, которые этого не делают. Операция, которая не изменяет наблюдаемое
состояние класса, а только извлекает из класса некоторое значения называется
запросом. Операции, которые изменяют текущее состояние объекта, называются
модификаторами.
Запросы
могут
выполняться
в
любом
порядке,
последовательность выполнения модификатора имеет важное значение.
Организация свойств и операций
Пиктограмма класса включает три секции: для имени, для свойств и для
операций. Пустота секции не означает, что у класса нет свойств или операций,
просто в данный момент они не показываются. Можно явно определить наличие у
класса большое количество свойств или атрибутов. Для этого в конце показанного
списка проставляются три точки. В длинных списках свойств и операций
разрешается группировка – каждая группа начинается со своего стереотипа.
Стереотипы. В объектно – ориентированных проектах часто встречается
ситуация, когда один класс выполняет практически все функции системы, а
другие классы не делают ничего, кроме инкапсуляции данных. Такое решение
нельзя назвать удачным, поскольку данный класс, назовем его регулятор слишком
сложный. Чтобы улучшить проект нужно перенести поведение регулятора к
другим сравнительно незанятым объектам. Эти объекты станут более
функционально нагруженными. Регулятор при этом превращается в
координатора. Координатор отвечает за выполнение задачи в определенной
последовательности, а другие объекты знают, как выполнять эти задачи.
Сущность стереотипа заключается в том, что он характеризует принципиальное
22
назначение класса. Стереотип классифицирует объекты на высоком уровне и дает
некоторое представление о типе каждого объекта. Примером может служить
отличие между регулятором и координатором. Стереотипы изображаются с
помощью текста, заключенного в кавычки, но могут изображаться с помощью
пиктограммы. В рамках диаграмм классов могут существовать стереотипы
классов, ассоциаций или обобщений.
ОбслуживаниеЗаказов
«constractor»
новыйЗаказ ()
новыйЗаказ(р:Вид)
«process»
обработатьЗаказ (о:Заказ)
…
«query»
авторЗаказа (о:Заказ)
«helper»
проверитьЗаказ (о:Заказ)
Стереотипы для характеристик класса
Ассоциации. Ассоциации представляют собой связи между экземплярами
классов (личность работает в компании, компания имеет ряд офисов). Ассоциация
обозначает смысловое соединение классов.
Пример: в системе обслуживания читателей имеются две ключевые абстракции –
Книга и Библиотека. Класс Книга играет роль элемента, хранимого в библиотеке.
Класс Библиотека играет роль хранилища для книг. Каждая ассоциация обладает
двумя ролями, каждая роль представляет собой направление ассоциации.
Книга
Элемент
*
1
Библиотека
Хранилище
Ассоциация
Ассоциация определяет двухсторонние отношения:
- для данного экземпляра Книги выделяется экземпляр Библиотеки,
обеспечивающий ее хранение;
- для данного экземпляра Библиотеки выделяются все хранимые Книги.
Ассоциация обозначает только семантическую связь. Она не указывает
направление и точную реализацию отношения. Ассоциация пригодна для анализа
проблемы, когда нам нужно только идентифицировать связи. С помощью
создания ассоциаций мы лучше понимаем участников семантических связей, их
23
ролей и мощности. Мощность – это количество элементов. Ассоциация один-комногим, приведенная в примере, означает, что для каждого экземпляра класса
Библиотека есть 0 или более экземпляров класса Книга. Для каждого экземпляра
класса Книга есть один экземпляр Библиотеки. Эту множественность обозначает
мощность ассоциации. Мощность ассоциации бывает одного из трех типов:
- один-к-одному;
- один-ко-многим;
- многие-ко-многим
Примеры ассоциаций:
- у европейской жены один муж, а у европейского мужа одна жена;
- у восточной жены один муж, а у восточного мужа много жен;
- у заказа один клиент, а у клиента сколько угодно заказаов;
- человек может посещать сколько угодно зданий, а вздании может находиться
сколько угодно людей
Один-к-одному
Европейская
жена
1
1
Европейский
муж
1
Восточный
муж
Один-ко-многим
Восточная
жена
*
Один-ко-многим
*
1
Заказ
Клиент
Один-ко-многим
Многие-ко-многим
Человек
*
*
здание
На практике наиболее распространенными вариантами множественности
являются 1, *, 0..1 (либо ноль, либо единица). В общем случае может
24
использоваться единственное число, (например, 11 игроков в команде), диапазон
(например, 2..4 игроков в карты) или дискретная комбинация из чисел и
диапазонов (например, 2,4 для количества дверей в автомобиле).
С концептуальной точки зрения ассоциации представляют собой
концептуальные связи между классами, в спецификации ассоциации показывают
ответственности классов. Если модель отражает уровень реализации, то между
связанными классами существуют указатели в обоих направлениях. К
ассоциациям могут быть добавлены стрелки. Эти стрелки показывают
направление навигации. На концептуальных диаграммах направления навигации
обычно отсутствуют, направления навигации появляются по мере того, как аспект
меняется в сторону спецификации и реализации. Навигация может быть указана в
одном или двух направлениях (см диаграмму классов с навигациями).
Обобщение
Типичный пример обобщения включает частного и
корпоративного клиентов. Они обладают некоторыми различиями, однако у них
много общего. Клиент – это супертип, а Частный клиент и Корпоративный клиент
выступают в качестве подтипов. На концептуальном уровне это означает, все, что
известно о Клиенте (ассоциации, операции) справедливо и для Корпоративного
клиента. В модели спецификации смысл обобщения в том, что интерфейс подтипа
должен включать все элементы супертипа. Кроме того обобщения связаны с
принципом подстановочности. Можно подставить определение Корпоративного
клиента в любой код, требующий определения Клиента и все должно нормально
работать. Корпоративный клиент может реагировать на некоторые команды
отличным от Клиента образом, но вызывающий объект это отличие не должно
беспокоить.
Множественность. Иногда необходимо ограничить количество объектов в
классах:
- задать ноль экземпляров (в этом случае класс превращается в утилиту,
которая предлагает свои свойства и операции);
- задать один экземпляр (класс-singleton);
- задать конкретное количество экземпляров;
- не ограничивать количество экземпляров (это случай принимается по
умолчанию)
Количество экземпляров класса называется его множественностью.
Выражение множественности записывается в правом верхнем углу значка
класса.
Например, КонтроллерУглов – это класс-singleton, а для класса ДатчикУгла
разрешены три экземпляра (объекта).
КонтроллерУглов 1
Управление[3..*]:порт
ДатчикУгла
3
25
Диаграмма классов с направлениями навигации
Множественность
Множественность применима не только к классам, но и к свойствам.
Множественность свойства задается выражением в квадратных скобках,
записанным после его имени. На рисунке заданы три и более экземпляра свойства
управление в экземпляре класса КонтроллерУглов.
Более сложные понятия
26
Множественная
и
динамическая
классификация
Понятие
классификация касается связи между объектом и его типом. Однозначная
классификация подразумевает, что любой объект принадлежит единственному
типу, этот тип может наследовать свойства от супертипов. При множественной
классификации объект может быть описан несколькими типами, которые не
обязательно
должны
быть
связаны
наследованием.
Множественная
классификация отличается от множественного наследования. При множественном
наследовании тип может иметь много супертипов, но для каждого объекта должен
быть определен только один тип. Множественная классификация допускает, что
объект может принадлежать многим типам.
Пример: подтипом личности является мужчина или женщина, доктор или
медсестра, пациент или вообще никто. Множественная классификация допускает,
чтобы объект принадлежал любым из этих типов в любом допустимом сочетании,
при этом необязательно определять типы для всех допустимых сочетаний.
Хирург
Мужчи
на
Семейный
врач
Женщи
на
пол
{полный}
Доктор
роль
Медсес
тра
Личность
Пациент
Физиотера
певт
Пациент
Дискриминатор
Множественная классификация
При множественной квалификации нужно четко определить, какие
сочетания являются допустимыми. Это делают с помощью дискриминатора,
который помечает ассоциацию - обобщение и характеризует сущность подтипов.
Несколько подтипов могут характеризоваться одним дискриминатором. Все
подтипы с одним и тем же дискриминатором
являются непересекающимися.
27
Это значит, что любой экземпляр супертипа может быть экземпляром только
одного из подтипов, которые описываются данным дискриминатором. Чтобы
изобразить такое обобщение графически, сводят ассоциации всех подклассов к
одной треугольной стрелке с одним дискриминатором, как показано на рисунке.
Дискриминатор может быть помечен как полный. Это означает, что любой
экземпляр суперкласса должен быть экземпляром одного из подклассов в данной
группе. В примере отметим следующие допустимые сочетания подтипов на
диаграмме: (Женщина, Пациент. Медсестра); (Мужчина, Физиотерапевт);
(Женщина, Пациент); (Женщина, Доктор, Хирург). Сочетания (Пациент, Доктор)
или (Мужчина, Доктор, Медсестра) недопустимы, первое не включает типа,
определенного полным дискриминантом пол, а второе включает сразу два типа,
определенным одним и тем же дискриминантом роль.
Агрегация и композиция. Агрегация (связь часть/целое) является одним
из часто встречающихся приемов моделирования. Более сильная разновидность
агрегации называется композицией. Согласно композиции объект-часть может
принадлежать только единственному целому и, как правило, жизненный цикл
частей совпадает с циклом целого: они живут и умирают вместе с ним. Любое
удаление целого распространяется на его части.
Далее на рисунке показаны примеры агрегации и композиции.
Многоугольник
Агрегация
1
Композиция
1
1
Графическ
ий объект
{упорядочено}
Вершина
3..*
Цвет
текстура
Согласно данной диаграмме Многоугольник состоит из упорядоченной
совокупности Вершин. Эти вершины могут изменяться при изменении
Многоугольника, для этого применяется агрегация. Композиция применяется для
связи между Многоугольником и Графическим объектом. Графический объект
содержит такие атрибуты как цвет и текстура. Он рассматривается отдельно от
Многоугольника, поскольку многие графические элементы могут использовать
такой набор атрибутов. Связь между Многоугольником и Графическим объектом
28
определяется как композиция. Таким образом, показывается, что данный
Графический объект создается и уничтожается вместе с данным
Многоугольником и не может быть изменен. Можно изменить атрибуты
Графического объекта, но невозможно заменить один Графический объект
другим.
Класс ассоциаций. Он позволяет определять для ассоциаций атрибуты,
операции и другие свойства, как показано на рисунке. Из данной диаграммы
видно, что Личность может работать только в одной Компании. При этом
необходимо каким-то образом хранить информацию относительно периода
времени, в течение которого каждый служащий работает в каждой Компании.
работодатель
Компания
*
Личность
0..1
Работа
класс ассоциаций
Период:интервалВремени
Это можно сделать, если дополнить ассоциацию атрибутом типа
«интервалВремени». Можно включить этот атрибут в класс Личность, однако на
самом деле он характеризует не Личность, а ее связь с Компанией, которая будет
меняться при смене работодателя. На следующей диаграмме показан другой
способ представления данной информации: преобразование Работы в обычный
класс (множественность при этом тоже подвергается преобразованию). В данном
примере каждый из классов в первоначальной ассоциации обладал однозначной
ролью по отношению к классу Работа. Таким образом, класс ассоциаций дает
возможность определить дополнительное ограничение, согласно которому двум
участвующим в ассоциации объектам может соответствовать только один
экземпляр класса ассоциаций. Диаграмма на первом рисунке не допускает, чтобы
Личность могла более чем один раз работать в одной и той же Компании. Если
необходимо, чтобы такое допускалось, то Работу следует преобразовать в
обычный класс, как на втором рисунке.
29
*
0..1
Работа
1
0..1
Личность
*
1 Компания
период:
интервалВремени
Отношения в диаграммах классов
В диаграммах классов используются следующие отношения:
Ассоциация
Обобщение
Подкласс
Суперкласс
Зависимый
Элемент
Независимый
элемент
Приемник
Источник
Зависимость
Реализация
Агрегация
Целое
Часть
Композиция
(физическое включение)
Ассоциации показывают структурные отношения между экземплярами
классов, то есть соединения между объектами. Каждая ассоциация может иметь
метку - имя, которое описывает природу отношения. Имени можно придать
направление – достаточно добавит треугольник направления, который указывает
направление, заданное для чтения имени.
Пример
30
Учится в
Студент
Институт
Когда класс участвует в ассоциации, он играет в этом отношении
определенную роль. Роль определяет, каким представляется класс на одном конце
ассоциации для класса на противоположном конце ассоциации.
Пример
Мария
Иван
Муж
Жена
Один и тот же класс может играть в разных ассоциациях разные роли.
Часто важно знать, как много объектов может соединяться через экземпляр
ассоциации. Это количество называется мощностью роли в ассоциации,
записывается в виде выражения, задающего диапазон величин или одну величину.
Запись мощности на одном конце ассоциации определяет количество объектов,
соединяемых с каждым объектом на противоположном конце ассоциации.
- неограниченное количество; 0..* - ноль или более; 1..* - один или более; 3..7 –
определенный диапазон; 1..3,7 – определенный диапазон или число.
Часто возникает проблема – как для объекта на одном конце ассоциации выделить
набор объектов на другом конце ассоциации? Рассмотрим взаимодействие между
банком и клиентом – вкладчиком. Мы устанавливаем ассоциацию между классом
Банк и классом Клиент. В контексте Банка мы имеем номерСчета, который
позволяет идентифицировать конкретного Клиента. В этом смысле номерСчета
является атрибутом ассоциации. Он не является характеристикой Клиента, т. к.
Клиенту не обязательно знать служебные параметры его счета. Теперь для
данного экземпляра Банка и данного значения номераСчета можно выявить ноль
или один экземпляр Клиента. В UML для решения этой проблемы вводится
квалификатор – атрибут ассоциации, его значения выделяют набор объектов,
связанных с объектом через ассоциацию. Квалификатор изображается маленьким
прямоугольником, присоединенным к концу ассоциации. В прямоугольник
вписывается свойство – атрибут ассоциации.
31
Пример
Банк
номерСчета:Int
*
0..1
Клиент
Квалификация
Зависимость является отношением использования между клиентам (зависимым
элементом) и поставщиком (независимым элементом). Обычно операции
клиента:
- вызывают операции поставщика;
- имеют сигнатуры, в которых возвращаемое значение или аргументы
принадлежат классу поставщика. На примере показана зависимость класса
Заказ от класса Книга, т.к. Книга используется в операциях
проверкаДоступности, добавить и удалить класса Заказ.
Заказ
Книга
ПроверкаДоступности (кн:Книга)
Добавить (кн:Книга)
Удалить (кн:Книга)
«friend»
Просмотр заказа
Отношения зависимости
32
На этом рисунке отображена еще одна зависимость, которая показывает, что
класс Просмотр Заказа использует класс Заказ. Причем Заказ ничего не знает о
Просмотре Заказа. Данная зависимость помечена стереотипом «friend», который
расширяет простую зависимость, определенную в языке. Отношений зависимости
в UML 17, различаются они по стереотипам.
Обобщение – отношение между общим предметом (суперклассом) и
специализированной разновидностью этого предмета (подклассом). Подкласс
может иметь одного родителя (один суперкласс) или несколько родителей. Во
втором случае говорят о множественном наследии. Как показано на примере
подкласс Летающий шкаф является наследником суперклассов Летающий
предмет и Хранилище вещей. Этому подклассу достаются в наследство все
свойства и операции двух классов-родителей.
Летающий предмет
Хранилище вещей
Летающий шкаф
Пример множественного наследия
Реализация - это семантическое отношение между классами, в котором
класс-приемник выполняет реализацию операций интерфейса класса-источника.
Пример
«interface»
Обработчик каталога
Каталог
запоминать ()
искать ()
Класс Каталог должен реализовать интерфейс Обработчик каталога, то есть
Обработчик каталога рассматривается как источник, а Каталог как приемник.
Интерфейс Обработчик каталога позволяет клиентам взаимодействовать с
объектами класса Каталог без знания той дисциплины доступа, которая конкретно
33
здесь реализована (последний вошел – первый вышел; первый вошел – первый
вышел).
Механизм пакетов
Один из подходов к решению проблем сложности ПО – группировка
классов в компоненты более высокого уровня, пакеты.
Механизм пакетов применяется к любым элементам модели, а не только к
классам. Диаграмма пакетов содержит пакеты классов и зависимости между
ними. Строго говоря, пакеты и зависимости являются элементами диаграммы
классов. Зависимость между двумя элементами бывает, если изменения в
определении одного элемента могут повлечь за собой изменения в другом. В
случае классов, то причины для зависимостей могут быть разными: один класс
посылает сообщения другому; один класс включает часть данных другого класса,
один класс использует другой в качестве параметра операции. Если класс меняет
свой интерфейс, то любое сообщение, которое он посылает может утратить свою
силу. В идеальном случае только изменения в интерфейсе класса должно
воздействовать на другие классы. Искусство проектирования больших систем
включает в себя минимизацию зависимостей – таким образом снижается
воздействие изменений и требуется меньше усилий на их внесение. На
следующем примере классы предметной области сгруппированы в два пакета:
Заказы и Клиенты. Оба пакета в свою очередь являются частью пакета
предметной области. Приложение Сбора Заказов имеет зависимости с обоими
пакетами предметной области. Пользовательский интерфейс Сбора Заказов имеет
зависимости с приложением Сбора Заказов AWT (средством разработки
графического интерфейса пользователя GUI в языке Java). Зависимость между
двумя пакетами существует в том случае, если между двумя любыми классами в
пакетах существует любая зависимость. Например, если любой класс в пакете
Список Рассылки зависит от какого-нибудь класса в пакете Клиенты, то между
соответствующими пакетами существует зависимость.
Пользовательский
интерфейс Сбора
Заказов
Пользовательский интерфейс
Списка Рассылки
AWT
Зависимость
Компонент
Приложение Сбора
Заказов
Заказы
Приложение Списка Рассылки
Клиенты
34
Если какой-либо класс в пакете Заказы изменяется, то это не значит, что
должен измениться пакет Пользовательский интерфейс Сбора Заказов, это значит,
что может измениться пакет Приложение Сбора Заказов. Пакет Пользовательский
интерфейс Сбора Заказов должен измениться только в том случае, если меняется
интерфейс пакета Приложение Сбора Заказов. В данной ситуации Приложение
Сбора Заказов защищает Пользовательский интерфейс Сбора Заказов от
изменений в пакетах. Пакеты не дают ответа на вопрос, как уменьшить
количество зависимостей в системе, но они помогают выделить эти зависимости,
после этого можно поработать над снижением количества зависимостей.
Диаграммы пакетов можно считать основным средством управления общей
структурой системы.
Пример: диаграмма классов системы управления полетом летательного
аппарата.
Здесь представлен класс Программа Полета, который имеет свойство
траекторияПолета, операцию-модификатор выполнятьПрограмму () и операцию35
селектор прогнозОкончУправления (). Имеется ассоциация между этим классом и
классом Контроллер СУ – экземпляры программы задают параметры движения,
которые должны обеспечивать экземпляры контроллера. Класс Контроллер Су –
агрегат, чьи экземпляры включают по одному экземпляру классов Регулятор
Скорости и регулятор Узлов, а также по 6 экземпляров класса Датчик.
Экземпляры Регулятор скорости и Регулятор узлов включены в агрегат физически
(с помощью отношения композиция), а экземпляры Датчика по ссылке, т.е.
экземпляр Контроллера СУ включает лишь указатели на объекты-датчики.
Регулятор скорости и Регулятор углов – это подклассы абстрактного суперкласса
Регулятор, который передает им в наследство абстрактные операции включить ()
и выключить (). В свою очередь, класс Регулятор использует конкретный класс
Порт. Ассоциация имеет имя (Определяет полет), роли участников ассоциации
явно указаны (Сервер, клиент). Отношения композиции также имеют имена
((Включать), причем на эти отношения наложено ограничение – контроллер не
может включать Регулятор скорости и Регулятор углов одновременно. Для класса
Контроллер СУ задано ограничение на множественность – допускается не более
трех экземпляров этого класса. Класс Регулятор скорости имеет ограничение
другого типа – повторное включение его экземпляра разрешается не раньше, чем
через 64 мс.
Диаграмма взаимодействия
Диаграммы взаимодействия являются моделями, которые описывают
поведение
взаимодействующих
групп
объектов.
Обычно диаграмма
взаимодействия показывает поведение объектов в рамках только одного варианта
использования. На такой диаграмме отображаются ряд объектов и те сообщения,
которыми объекты обмениваются между собой. Существуют две разновидности
диаграммы взаимодействия – диаграммы последовательности и кооперативные
диаграммы. Диаграмма последовательности упорядочивает сообщения между
объектами по времени. Кооперативная диаграммам – это диаграмма, которая
выделяет структурную организацию объектов, посылающих и принимающих
сообщения.
Элементами диаграмм взаимодействия являются участники
взаимодействия – объекты связи, сообщения.
Диаграммы последовательности: такие диаграммы обеспечивают более
наглядное представление порядка передачи сообщений, но не показывает
структурные характеристики объектов и связей. Объекты, участвующие во
взаимодействии помещаются на вершине диаграммы, вдоль оси Х. Обычно слева
размещается объект, который инициирует взаимодействие, а справа – объекты, по
возрастанию подчиненности. Сообщения, которыми обмениваются объекты
размещаются вдоль оси Y в порядке возрастания времени от вершины к
основанию диаграммы.
36
Обозначения:
Имя объекта подчеркивается и указывается всегда, свойства –
выборочно.
Синтаксис имени – ИмяОбъекта:ИмяКласса Например,
Свойства
Адам:Человек – имя объекта и класса; :Пользователь – только имя
класса (анонимный объект); мойкомпьютер – только имя объекта
(подразумевается, что имя класса известно); агент: - объект-сирота
(подразумевается, что имя класса неизвестно).
Синтаксис свойств имеет вид: Имя:Тип=Значение.
Например, номер:Телефон=”7350-420” – имя, тип, значение;
активен=True – имя и значение
Объекты взаимодействуют друг с другом с помощью связей – каналов для
передачи сообщений. Связь – это путь для пересылки сообщений. Сообщение –
это спецификация передачи информации между объектами в ожидании того, что
будет обеспечена требуемая деятельность. Каждое сообщение помечается именем
сообщения, можно добавить аргументы и некоторую управляющую информацию,
можно показать самоделегирование, при котором объект посылает сообщение
самому себе (стрелка сообщения указывает на ту же самую линию жизни). Из
всей возможной управляющей информации особое значение имеют два вида. Вопервых, это условие, показывающее, когда посылается сообщение (например,
[нуженПовторныйЗаказ=”true”]. Сообщение посылается только при выполнении
данного условия. Во-вторых – это управляющий маркер – маркер итерации,
показывающий, что сообщение посылается много раз для множества объектовадресатов (например, *приготовиться). Диаграмма может содержать возврат,
означающий не новое сообщение, а возврат из сообщения. Возврат отличается от
обычных сообщений тем, что его стрелка не сплошная, а имеет вид пары линий.
Существуют две отличительные характеристики диаграммы последовательности.
1.
Линия жизни объекта – это вертикальная пунктирная линия,
которая обозначает период существования объекта. Большинство
объектов существуют на протяжении всего взаимодействия, их
линии жизни тянутся от вершины до основания диаграммы. Также
объекты могут создаваться в ходе взаимодействия. Их линии жизни
начинаются с момента приема сообщения «create». Объекты могут
уничтожаться в ходе взаимодействия. Их линии жизни
заканчиваются с момента приема сообщения «destroy».
Уничтожение линии жизни отмечается пометкой Х в конце линии.
ИМЯ
«create»
:Покупки
«destroy»
Х
37
Создание и уничтожение объекта
2.
Вторая характеристика – фокус управления – это высокий тонкий
прямоугольник, отображающий период времени, в течение
которого объект выполняет (свою или подчиненную процедуру).
Вершина прямоугольника отмечает начало действия, а основание –
его завершение. Момент завершения может маркироваться
сообщением возврата, которое показывается пунктирной стрелкой.
Можно показать вложение фокуса управления, например,
рекурсивный вызов собственной операции. Для этого второй фокус
управления рисуется немного правее первого.
Для отображения условности линия жизни может быть разделена на несколько
параллельных линий жизни. Каждая отдельная линия соответствует условному
ветвлению во взаимодействии. Далее в некоторой точке линии жизни могут быть
снова слиты.
Параллельные линии жизни
Ветвление показывается множеством стрелок, идущих из одной точки. Каждая
стрелка отмечается сторожевым условием.
[x>0] положить(х)
:Счет
[x<=0] заработать(х)
Ветвление
38
Пример
Окно
Ввода
Заказа
Заказ
Строка заказа
Запас
Сообщение
Объект
Приготовиться ()
* приготовиться ()
Проверка()
Условие
итерация
[проверка=true]
Удалить()
нуженПовторныйЗаказ()
самоделегирование
Возврат
[нуженПовторныйЗаказ=true]
Новый
повторный
заказ
[проверка=true]
поставка
Создание
1. Окно ввода заказа посылает заказу сообщение «приготовиться»
2. Заказ посылает данное сообщение каждой Строке заказа в данном Заказе
3. Каждая Строка заказа проверяет состояние определенного Запаса товара:
если данная проверка удовлетворяется (результат true), то Строка заказа
удаляет соответствующее количество товара из Запаса. Иначе
количество Запаса снижается до уровня повторного заказа, и Запас
запрашивает новую поставку товара.
Фокус управления называют также активизацией. Также на диаграмме могут быть
показаны асинхронные сообщения, они имеют вид половинной стрелки (одна
часть стрелки). Асинхронное сообщение не блокирует работу вызывающего
объекта. Асинхронное сообщение может выполнять одну из трех функций:
39
1- создавать новую ветвь процесса (в этом случае оно связано с самой верхней
частью активизации)
2- создавать новый объект;
3- устанавливать связь с уже выполняющейся ветвью процесса.
Кооперативные диаграммы – это второй вид диаграммы взаимодействия.
Данные диаграммы отображают взаимодействие объектов в процессе
функционирования системы. Стрелки на ней тоже обозначают сообщения, обмен
которыми идет в рамках одного варианта использования. Временная
последовательность сообщений указывается путем нумерации сообщений.
Нумерация сообщений делает восприятие последовательности более трудной,
зато пространственное расположение позволяет проще отобразить некоторые
другие моменты, например, показать взаимосвязь объектов или перекрывающиеся
компоненты. В UML применяется десятичная схема нумерации, в этом случае
понятно, какая операция вызывает какую операцию. Результатом обработки
сообщения обычно является действие. В языке UML моделируются следующие
разновидности действий:
1- вызов – в объекте запускается операция;
2 - возврат – возврат значения в вызывающий объект;
3 - посылка (send) - в объект посылается сигнал;
4 - создание – создание объекта, выполняется по стандартному сообщению
«create»;
5 - уничтожение – уничтожение объекта (сообщение «destroy»)
На кооперативной диаграмме можно разместить такую же управляющую
нумерацию, как и на диаграмме последовательности.
Синтаксис записи сообщений в UML:
ВозвВеличина:=ИмяСообщения (аргументы), здесь ВозврВеличина задает
величину, возвращаемую как результат обработки сообщения.
Примеры:
Корд:=текущПоложение (самолетТ1) – вызов опреации, возврат значения;
Оповещение () – посылка сигнала;
установитьМаршрут (Х) – вызов операции с действительным параметром;
«create» - сообщение для создания объекта
Когда объект посылает сообщение в другой объект (делегирует некоторое
действие получателю), объект-получатель может в свою очередь послать
сообщение в третий объект и т.д. Так формируется поток сообщений, т.е.
последовательность управления. Сообщения в последовательности должны быть
пронумерованы. Номера записываются перед именами сообщений, направления
сообщений указываются стрелками, которые помещаются над линиями связи.
Наиболее общую форму управления задает процедурный или вложенный поток.
Процедурный поток рисуется стрелками с заполненными наконечниками. Далее
показан пример. В нем сообщение
2.1:напиток := изготовить (смесь №3)
определено как первое сообщение, вложенное во второе сообщение
2 : заказать (смесь №3) последовательности, а сообщение
2.2 : принести (напиток) – как второе вложенное сообщение.
40
Все сообщения процедурной последовательности считаются синхронными.
Работа с синхронным сообщением подчиняется следующему правилу: передатчик
ждет до тех пор, пока получатель не примет и не обработает сообщение. В
примере это означает, что третье сообщение будет послано только после
обработки сообщений 2.1 и 2.2. Степень вложенности сообщений может быть
любой. Главное, чтобы соблюдалось правило: последовательность сообщений
внешнего уровня возобновляется только после завершения вложенной
последовательности.
Поток синхронных сообщений
2: заказать (смесь№3)
:Клиент
2.2 : принести (напиток)
б:Бармен
о:Официант
2.1:напиток:=изготовить(смесь№3)
3:выпить (напиток)
Менее общую форму управления задает асинхронный поток управления.
Как показано на следующем примере, асинхронный поток рисуется обычными
стрелками. Здесь все сообщения считаются асинхронными, т.е. передатчик не
ждет реакции от получателя сообщения. Такой вид коммуникации имеет
семантику почтового ящика – получатель принимает сообщение по мере
готовности. Можно сказать, что при асинхронном потоке один объект избавляется
от сообщения для другого объекта. В следующем примере сообщение
подтверждениеВызова определено как второе сообщение в последовательности.
1:снятиеТрубки ()
а:Абонент
:Телефон
2:подтверждениеВызова ()
:Комутатор
В диаграмме кооперации можно моделировать и более сложные формы –
операции и ветвления. Итерация как уже говорилось ранее представляет собой
повторяющуюся последовательность сообщений. Выражение добавляется после
номера сообщения итерации *[i:=1..n]. Оно означает, что сообщение итерации
будет повторяться заданное количество раз. Например, четырехкратное
повторение первого сообщения рисоватьСторонуПрямоугольника можно задать
выражением
1*[i:=1..4]:рисоватьСторонуПрямоугольника (i).
Для моделирования ветвления после номера сообщения добавляется
выражение условия, например,[x>0]. Пример итерационного и разветвляющегося
потока сообщений показан ниже. Здесь первое сообщение повторяется четыре
раза, а в качестве второго выбирается одно из двух сообщений ( в зависимости от
значения переменной х). В итоге экземпляр рисователя нарисует на экране
прямоугольное окно, а экземпляр собеседника выведет в него соответствующее
донесение. Таким образом, для формирования кооперативной диаграммы
выполняются следующие действия:
1 - отображаются объекты, которые участвуют во взаимодействии;
41
2 - рисуются связи, соединяющие эти объекты;
3 - связи помечаются сообщениями, которые посылают и получают выделенные
объекты.
1*[i:=1..4]:рисоватьСторонуПрямоугольника (i)
:Клиент
:Рисователь
2[x<=0]:вывод(«Плохо»)
2[x<=0]:вывод («Хорошо»)
:Собеседник
На кооперативной диаграмме в случае необходимости самоделегирование
показывается следующим образом
запасХ:ЭлементЗа
паса
Сравнение диаграмм последовательности и кооперативных диаграмм
Разные разработчики отдают предпочтение разным видам диаграмм
деятельности. В диаграмме последовательностей делается акцент именно на
последовательность сообщений: здесь легче наблюдать порядок, в котором
происходят разные события. На кооперативной диаграмме можно использовать
пространственное расположение объектов для того, чтобы показать их
статическое взаимодействие. Принципиальным свойством любой формы
диаграммы взаимодействия является простота. На диаграмме легко увидеть все
сообщения. Диаграммы взаимодействия хороши, когда они отображают простое
поведение. Если нужно показать сложное поведение системы на одной
диаграмме, то следует использовать диаграмму деятельности. Диаграммы
взаимодействия используются, когда нужно описать поведение нескольких
объектов в рамках одного варианта использования. Эти диаграммы не подходят
для точного описания системы. Если нужно описать поведение единственного
объекта во многих вариантах использования, то следует применять диаграмму
состояний.
Диаграммы состояний - это средство описания поведения системы. Они
определяют все возможные состояния, в которых может находиться конкретный
объект, а также процесс смены состояния объекта в результате некоторых
событий. В большинстве объектно – ориентированных методов диаграммы
42
состояний строятся для единственного класса и отражают динамику поведения
единственного объекта. Существует много форм диаграмм состояний,
незначительно отличающихся друг от друга по семантике.
Диаграмма состояний отображает конечный автомат, выделяя поток
управления, следующий от состояния к состоянию. Конечный автомат – это
поведение, которое определяет последовательность состояний в ходе
существования объекта. Эта последовательность рассматривается как ответ на
события и включает реакцию на эти события. Диаграмма состояний показывает:
1 - набор состояний системы;
2 - события, которые показывают переход из одного состояния в другое;
3 - действия, которые происходят в результате изменения состояния.
В языке UML состоянием называют период в жизни объекта, на протяжении
которого он удовлетворяет какому-то условию, выполняет определенную
деятельность или ожидает некоторое событие. Состояние изображается как
закругленный прямоугольник, включающий имя и подсостояния (если они есть).
ИмяСостояния
Обозначение состояния
Переходы между состояниями отображаются помеченными стрелками.
Событие/Действие
Событие – происшествие, которое вызывает изменение состояния. Действие
– набор операций, запускаемых объектом. Т.е. события вызывают переходы, а
действия являются реакциями на переходы. Примеры событий:
Баланс <0
изменение в состоянии
Помехи
сигнал, объект с именем
Уменьшить(Давление) вызов действия
After (5seconds)
истечение периода времени
When (time=16:30)
наступление абсолютного момента времени
Примеры действий:
Кассир.прекратитьВыплаты ()
- вызов одной операции
flt:=new(Фильтр):flt.убратьПомехи () - вызов двух операций
send Ник.привет
- посылка сигнала в объект Ник
Для отображения перехода в начальное/конечное состояние принято
обозначение:
СТАРТ
43
Из рисунка видно, что система начинает свою жизнь в состоянии
Инициализация, затем переходит в состояние Ожидание. В этом состоянии через
каждые 10 секунд (по событию after 10 sec) выполняется самопроверка системы
(операция самопроверка()). При наступлении события тревога(Датчик)
реализуются действия, связанные с блокировкой периода охраняемого объекта,
выполняется операция блокироватьПериметр () и осуществляется переход в
состояние Активна. В активном состоянии через каждые 5 секунд по событию
after (5 sec) запускается операция приемКоманды (). Если команда получена
(наступило событие Сброс),система возвращается в состояние Ожидание. В
процессе возврата разблокируется периметр охраняемого объекта (операция
разблокироватьПериметр()).
Действия в состояниях
Для указания действий, выполняемых в состояние и при выходе из
состояния, используются метки entry и exit соответственно. Например, как
показано на следующем примере, при входе в состояние Активна выполняется
операция установитьТревогу из класса Контроллер, а при выходе из состояния –
операция сбросТревоги().
Активна
entry /Контроллер::установитьТревогу ()
do / Контроллер::подтверждатьтревогу ()
exit/ Контроллер::сбросТревоги ()
Входные и выходные действия и деятельность в состоянии Активна.
Действие, которое должно выполняться, когда система находится в данном
состоянии, указывается после метки do. Считается, что такое действие начинается
при входе в состояние и заканчивается при выходе из него. Например, в
состоянии Активна, это действие подтверждатьТревогу()
Синтаксис метки перехода:
44
Событие[Условие]/Действие например, /получить первую позицию заказа
Синтаксис метки деятельности:
Выполнить/Деятельность, например: выполнить/проверить позицию
Термин действие используется для перехода, а термин деятельность – для
состояния. Действия связаны с переходами и рассматриваются как мгновенные и
непрерывные процессы. Деятельности связаны с состояниями и могут длиться
достаточно долго. Деятельность может быть прервана в результате наступления
некоторого события.
Условные переходы
Между состояниями возможны различные типы переходов. Обычно переход
инициируется событием. Разрешены условные или охраняемые переходы
Событие[Условие]/Действие
.
Порядок выполнения условного перехода:
1- происходит событие;
2 - выполняется условие УсловиеПерехода;
При УсловиеПерехода=true запускается переход и активизируется действие,
иначе переход не выполняется. Далее показан пример условного перехода между
состояниями Инициализация и Ожидание. Он происходит по событию
ПитаниеПодано, но только в том случае, если достигнут боевой режим лазера.
ПитаниеПодано [БоевойРежимЛазера]
Инициализация
Ожидание
Вложенные состояния
Одной из наиболее важных характеристик конечных автоматов в UML
является подсостояние. Подсостояние позволяет значительно упростить
моделирование сложного поведения. Подсостояние – это состояние, вложенное в
другое состояние.
Составное состояние
Подсостояние1
Подсостояние2
Далее на рисунке приведена внутренняя структура составного состояния
Активна.
45
Активна
Проверка
Звонок
entry/вызовЦентра(Датчик)
Ждать
Семантика вложенности такова: если система находится в состоянии
Активна, то она должна быть точно в одном из подсостояний: Проверка, Звонок,
Ждать. В тоже время в подсостояние могут вкладываться другие подсостояния.
Степень вложенности подсостояний не ограничивается.
Такая семантика
соответствует случаю последовательных подсостояний.
Возможно наличие параллельных подсостояний. Они выполняются
параллельно внутри составного состояния.
Графически изображения
параллельных подсостояний отделяются друг от друга пунктирными линиями.
Инода при возврате в составное состояние возникает необходимость попасть в то
его подсостояние, которое в прошлый раз было последним. Такое подсостояние
называют историческим. Информация об историческом подсостоянии
запоминается. Такая семантика переходов отображается значком истории –
буквой H внутри кружка.
Активна
Команды
H
Запрос
Проверка
Звонок
Ждать
При первом посещении состояния Активна автомат не имеет истории,
поэтому происходит простой переход в подсостояние Проверка. Допустим в
подсостоянии Звонок произошло событие Запрос. Средства управления
заставляют автомат поктнуть подсостояние Звонок (и состояние Активна) и
вернуться в состояние Команды. Когда работа в состоянии Команда завершается,
выполняется возврат в историческое подсостояния Активна. Поскольку теперь
автомат запомнил историю, он переходит прямо в подсостояние Звонок (минуя
46
подсостояние Проверка). Для обозначения подсоставного состояния,
имеющие внутри себя скрытые (не показанные на диаграмме) подсостояния
используется символ «очки».
Диаграммы деятельности
Диаграмма деятельности представляет собой особую форму конечного
автомата, в которой показываются процесс вычислений и потоки работ. В ней
выделяются не обычные состояния объекта, а состояния выполняемых
вычислений – состояния действия. При этом полагают, что процесс вычислений
не прерывается внешними событиями. Диаграммы деятельности очень похожи на
блок-схемы алгоритмов. Основной вершиной в диаграмме деятельности является
состояние действия, которое изображается как прямоугольник с закругленными
боковыми сторонами.
Создать
Каталог
Состояние действия
Состояние действия является атомарным (т. е. действие нельзя прервать) и
выполняется за один квант времени, его нельзя подвергнуть декомпозиции. Если
нужно представить сложное действие, которое можно подвергнуть дальнейшей
декомпозиции (разбить на ряд более простых действий), то используют
состояние поддеятельности. Изображение состояния поддеятельности содержит
пиктограмму в правом нижнем углу.
Выполнить Заказ
Состояние поддеятельности
Фактически в данную вершину вписывается имя другой диаграммы,
имеющей внутреннюю структуру. Переходы между вершинами – состояниями
действий – изображаются в виде стрелок. Переходы выполняются по окончании
действий. Кроме того, в диаграммах деятельности изображают вспомогательные
вершины:
1 - решение (ромбик с одной входящей и несколькими исходящими стрелками)
2 - объединение (ромбик с несколькими входящими и одной исходящей стрелкой)
3 - линейка синхронизации – разделение (жирная горизонтальная линия с одной
входящей и несколькими исходящими стрелками
47
4 - линейка синхронизации – слияние (жирная горизонтальная линия с
несколькими входящими и одной исходящей стрелкой)
5 - начальное состояние (черный кружок)
6 - конечное состояние (незакрашенный кружок, в котором размещен черный
кружок меньшего размера).
Вершина «решение» позволяет отобразить разветвление вычислительного
процесса, исходящие из него стрелки помечаются сторожевыми условиями
ветвления. Вершина «объединение» отмечает точку слияния альтернативных
потоков действий.
Линейки синхронизации позволяют показать параллельные потоки
действий, отмечая точки их синхронизации при запуске (момент разделения) и
при завершении (момент слияния)
На следующем рисунке приведен пример диаграммы деятельности. Эта
диаграмма деятельности описывает деятельность покупателя
в Интернетмагазине. Здесь представлены две точки ветвления – для выбора способа поиска
товаров и для принятия решения о покупке.Прису3тствуют три линейки
синхронизации: верхняя отражает разделение на лва параллельных процесса,
средняя отражает и разделение, и слияние5 процессов, а нижняя – только слияние
процессов. Дополнительно на этой диаграмме показаны две плавательные
дорожки – дорожка покупателя и дорожка магазина, которые разделены
вертикальной чертой. Каждая дорожка имеет имя и фиксирует область
деятельности конкретного лица, обозначая зону его ответственности.
Самым большим достоинством диаграмм деятельности является поддержка
параллелизма. Благодаря этому, они являются мощным средством моделирования
потоков работ и параллельного программирования. Самый большой недостаток
диаграмм деятельности заключается в том, что связи между действиями и
объектами просматриваются не слишком четко. Эти связи можно попытаться
определить с помощью меток с именами объектов, но этот способ не обладает
такой же простотой, как использование диаграмм взаимодействия. Диаграммы
деятельности рекомендуется использовать в следующих ситуациях:
- анализ варианта использования. На этой стадии нас не интересует связь
между действиями и объектами, нужно только понять, какие действия должны
иметь место и каковы зависимости в поведении системы. Связывание методов и
объектов выполняется позднее с помощью диаграмм взаимодействия.
- анализ потоков работ в различных вариантах использования. Когда
варианты использования взаимодействуют друг с другом, диаграммы
деятельности хорошо представляют и анализируют их поведение.
Не рекомендуется использовать диаграммы деятельности в следующих
ситуациях:
- анализ взаимодействия объектов. Для этого лучше подходят диаграммы
взаимодействия, поскольку они проще и нагляднее.
- анализ поведения объекта в течение его жизненного цикла. Для этого
используются диаграммы состояний.
48
Диаграммы реализации состоят из диаграмм компонентов и диаграмм
размещения. Статические и динамические модели описывают логическую
организацию системы, отражают логический мир программного приложения.
Модели реализации обеспечивают представление системы в физическом мире,
они рассматривают вопросы упаковки логических элементов в компоненты и
размещения компонентов в аппаратных узлах.
Диаграммы компонентов. Диаграммы компонентов показывают, как
выглядит модель на физическом уровне. Элементами диаграмм компонентов
являются компоненты и интерфейсы, а также отношения зависимости и
реализации. Диаграммы компонентов
могут включать примечания и
ограничения. Наконец, диаграммы компонентов могут содержать пакеты и
подсистемы, они используются для группировки элементов модели в крупные
фрагменты.
Компоненты. По своей сути компонент является физическим фрагментом
реализации системы, который включает в себя программный код (исходный,
двоичный, исполняемый), сценарные описания или наборы команд операционной
системы (имеются в виду командные файлы). На языке UML компонент – это
физическая и заменяемая часть системы, которая соответствует набору
интерфейсов и обеспечивает реализацию этого набора интерфейсов. Интерфейс –
очень важная часть понятия компонент, он будет рассмотрен далее. Графически
компонент изображается как прямоугольник со вкладками, обычно с именем.
Словарь.dll
Компонент – это базисный строительный блок физического представления
ПО, поэтому его можно сравнить с базисным строительным блоком логического
представления ПО – классом.
Сходные характеристики компонента и класса:
1 - наличие имени;
2 - реализация наборов интерфейсов;
3 - участие в отношениях зависимости;
4 - возможность быть вложенным;
5 - наличие экземпляров (экземпляры компонентов можно использовать только в
диаграммах размещения).
Различия компонентов и классов:
1.
Классы – логические абстракции, компоненты – физические предметы,
которые живут в мире битов. В частности, компоненты могут жить в
физических узлах, а у классов нет такой возможности.
2.
Компоненты являются физическими упаковками, контейнерами,
инкапсулирующими в себе различные логические элементы.
49
3.
Классы имеют свойства и операции. Компоненты имеют только
операции, которые доступны через их интерфейсы.
Фабрика.dll
Компонент
Рабочий
Директор
Станок
Классы
Классы и компоненты
Класс не может дышать воздухом физического мира реализации, ему нужен
скафандр. Таким скафандром является компонент. В скафандре-компоненте
может находиться несколько классов и коопераций. Итак, в компоненте
располагается набор логики. На рисунке показано, что с помощью отношения
зависимости можно явно отобразить отношения между компонентом и классами,
которые он реализует. Но чаще всего такие отношения не отображаются. На
диаграмме изображаются компоненты программного обеспечения и связи между
ними. Выделяют два типа компонентов: исполняемые компоненты и библиотеки
кода. Каждый класс модели преобразуется в компонент исходного кода. После
создания они сразу добавляются к диаграмме компонентов. Между отдельными
компонентами изображают зависимости, которые соответствуют зависимостям на
этапе компиляции или выполнения программы. Рассмотрим диаграмму
компонентов для некоторой системы обслуживания банкоматов архитектуры
клиент-сервер. Система строится с помощью языка С++. У каждого класса
имеется свой собственный заголовочный файл и файл с расширением .cpp, так
что каждый класс преобразуется в свои собственные компоненты на диаграмме.
Некоторый класс Screen преобразуется в два компонента , представляющие тело и
заголовок класс Screen. Выделенный темным компонент называется
спецификацией пакета (package specification) и соответствует файлу тела класса
Screen на языке С++ (файл с расширением .cpp). Невыделенный компонент также
называется спецификацией пакета, но соответствует заголовочному файлу класса
языка С++ (файл с расширением .h). Компонент Client.exe является исполняемой
программой.
50
Client.exe
CardReader
CashDispenser
Screen
CardReader
Screen
CashDispenser
Компоненты соединены штриховой линией, что соответствует
зависимостям между ними. Например, класс CardReader зависит от класса
Screen. Это означает, для того, чтобы класс CardReader мог быть скомпилирован.
Класс Screen уже должен существовать. После компиляции всех классов может
создан исполняемый файл Client.exe.
Интерфейсы. Интерфейс – список операций, которые определяют услуги
класса или компонента или компонента. Можно сказать, что интерфейс – это
разъем, который торчит из ящичка компонента. С помощью интерфейсных
разъемом компоненты стыкуются друг с другом, объединяясь в систему.
Интерфейс похож на улыбку чеширского кота, где кот отдельно и улыбка
отдельна. Все операции открыты и видимы клиенту. Операции интерфейса только
именуют предлагаемые услуги. Взаимосвязь между компонентом и интерфейсом
очень важна. Возможны два способа отображения взаимосвязи между
компонентом и интерфейсом. Первый, свернутый способ, в нем интерфейс
отображается в форме пиктограммы. Компонент Образ.java, который реализует
интерфейс, соединяется со значком интерфейса (кружком) НаблюдательОбраза
простой линией. Компонент Рыцарь.java,который использует интерфейс, связан с
ним отношением зависимости.
51
Рыцарь.java
Образ.java
НаблюдательОбраза
Второй способ представления интерфейса показан на следующем рисунке.
Здесь используется развернутая форма изображения интерфейса, в которой могут
показываться его операции. Компонент, который реализует интерфейс,
подключается к нему отношением реализации. Компонент, который получает
доступ к услугам другого компонента через интерфейс, по-прежнему
подключается к нему отношением зависимости.
Рыцарь.java
«interface»
НаблюдательОбраза
Образ.java
ОбновитьОбраз ():Картинка
По способу связи компонента с интерфейсом различают:
1 - экспортируемый интерфейс – тот, который компонент реализует и предлагает
как услугу клиентам;
2 - импортируемый интерфейс – тот, который компонент использует как услугу
другого компонента.
У одного компонента может быть несколько экспортируемых и несколько
импортируемых интерфейсов. Факт, что между двумя компонентами всегда
находится интерфейс, устраняет их прямую зависимость. Компонент, который
использует интерфейс, будет работать правильно вне зависимости от того, какой
компонент реализует этот интерфейс. Это обеспечивает гибкую замену
компонентов в интересах системы.
Компоновка
системы.
Следует
отметить,
что
программный
инструментарий развивается быстрее программного. Это происходит в основном
потому, что разработчик аппаратуры создает систему из готовых аппаратных
компонентов (микросхем). Т.е. секрет в использовании компонент. Повторное
использование – магистральный путь развития программного инструментария.
Создание нового ПО из существующих, работоспособных программных
компонентов приводит к более надежному и дешевому коду. При этом сроки
разработки существенно сокращаются. Основная цель программных компонентов
– допускать сборку системы из двоичных заменяемых частей. Они должны
обеспечить начальное создание системы из компонентов, а затем и ее развитие –
добавление новых компонентов и замену некоторых старых компонентов без
перенастройки системы в целом. Эту возможность воплощают интерфейсы. После
52
того, как интерфейс определен, к выполняемой системе можно подключить
любой компонент, который удовлетворяет интерфейсу, или обеспечивает
интерфейс.
Особенности компонента:
1 - компонент физичен, он живет в мире битов, а не логических понятий и не
зависит от языка программирования;
2 - компонент – заменяемый элемент. Механизм замены оговорен современными
компонентными моделями (COM, COM+, CORBA, JavaBeans);
3 - компонент является частью системы, он редко автономен;
4 - компонент соответствует набору интерфейсов и обеспечивает реализацию
этого набора.
Вывод: компоненты – это базисные строительные блоки, из которых может
проектироваться система. Компонент может появляться на разных уровнях
иерархии представления сложной системы.
Разновидности компонентов. В Языке UML для обозначения новых
компонентов используют механизм стереотипов. Стандартные стереотипы для
компонентов представлены в таблице:
«executable» - компонент, который может выполняться вфизическом узле
(имеет расширение .exe)
«library» - статическая или динамическая объектная библиотека (имеет
расширение .dll)
«file» - компонент, который представляет файл, содержащий исходный код
или данные (имеет расширение.ini)
«table» - компонент, который представляет таблицу базы данных (имеет
расширение .tbl)
«document» - компонент, который представляет документ (имеет
расширение .hlp).
На практике применяют следующие пиктограммы компонентов:
Пиктограмма исполняемого элемента
Пиктограмма объектной библиотеки
Пиктограмма документа с исходным кодом
Или данными
Пиктограмма документа
53
Пиктограмма таблицы базы данных
Для получения работающей системы существуют различные способы
сборки компонентов. Компонентные диаграммы показывают отношения:
1 - периода компиляции (среди текстовых компонентов);
2 - периода сборки, линковки (среди объектных двоичных компонентов);
3 - периода выполнения (среди машинных компонентов).
Реализация системы может включать большое количество разнообразных
компонентов:
1 - исполняемых элементов;
2 - динамических библиотек;
3 - файлов данных;
4 - справочных документов;
5 - файлов инициализации;
6 - файлов регистраций;
7 - сценариев;
8 - файлов установки.
54
Основы компонентной объектной модели
Компонентная объектная модель (COM) – фундамент компонентноориентированных средств для всего семейства операционных систем Windows.
Рассмотрение этой модели иллюстрирует комплексный подход к созданию и
использованию компонентного программного обеспечения. COM определяет
стандартный механизм, с помощью которого одна часть ПО предоставляет свои
услуги другой части. Общая архитектура предоставления услуг в библиотеках,
приложениях, системном и сетевом программном обеспечении позволяет COM
изменить подход к созданию программ. COM устанавливает понятия и правила,
необходимые для определения объектов и интерфейсов, кроме того, в состав
COM входят программы, реализующие ключевые функции. В COM любая часть
ПО реализует свои услуги с помощью объектов COM. Каждый объект COM
содержит несколько интерфейсов. Клиенты могут получить доступ к услугам
объекта COM только через вызовы операций его интерфейсов – у них нет
непосредственного доступа к данным объекта. Представим объект COM с
интерфейсом РаботаСФайлами. Пусть в этот интерфейс входят операции
ОткрытьФайл, ЗаписатьФайл, ЗакрытьФайл. Если разработчик захочет ввести в
объект COM поддержку преобразования форматов, то объекту потребуется еще
один интерфейс ПреобразованиеФорматов, возможно с одной операцией
ПреобразоватьФормат. Операции каждого из интерфейсов сообща представляют
связанные друг с другом услуги: либо работу с файлами, либо преобразование их
форматов. Далее на рисунке показано, что объект COM всегда реализуется внутри
некоторого сервера. Сервер может быть либо динамически подключаемой
библиотекой (DLL), подгружаемой во время работы приложения, либо отдельным
самостоятельным процессом (EXE). Воспользуемся принятыми в COM
обозначениями.
ОткрытьФайл()
ЗаписатьФайл()
ЗакрытьФайл()
Интерфейс1
Интерфейс2
Интерфейс3
Объект COM
ПреобразоватьФормат()
Организация объекта COM
55
Для вызова операции интерфейса клиент объекта COM должен получить
указатель на его интерфейс. Клиенту требуется отдельный указатель для каждого
интерфейса, операции которого он намерен вызвать. Например, как показано на
следующем рисунке, клиента нашего объекта COM нужен один указатель
интерфейса для вызова операций интерфейса РаботаСФайлами, а другой – для
вызова операций интерфейса ПреобразованиеФормата. Получив указатель на
нужный интерфейс, клиент может использовать услуги объекта, вызывая
операции этого интерфейса. С точки зрения программиста, вызов операции
аналогичен вызову локальной процедуры или функции. Но на самом деле
исполняемый при этом код может быть частью или библиотеки, или отдельного
процесса, или операционной системы. Благодаря COM клиентам нет нужды
учитывать эти отличия – доступ ко всему осуществляется единообразно. Т.е. в
COM для доступа к услугам, предоставляемым любыми типами ПО, используется
одна общая модель.
Указатель на интерфейс 1
Указатель на интерфейс2
1
2
Объект COM
Клиент
Доступ клиента к интерфейсам объекта COM
Организация интерфейса COM
Каждый интерфейс объекта COM – контракт между этим объектом и его
клиентами. Они обязуются: объект - поддерживать операцию интерфейса в
точном соответствии с его определениями, а клиент – корректно вызывать
операции. Для обеспечения контракта надо задать: идентификацию каждого
интерфейса; описание операций интерфейса; реализацию интерфейса.
Диаграммы размещения – вторая разновидность диаграмм реализации.
Они отражают физические взаимосвязи между программными и аппаратными
компонентами. Диаграмма размещения является хорошим способом показать
маршруты перемещения объектов и компонентов в распределенной системе.
Элементами диаграммы размещения являются узлы, а также отношения
зависимости и ассоциации, также могут в диаграмму включаться примечания и
ограничения. Диаграммы размещения могут включать компоненты, каждый из
которых должен жить в некотором узле, а также содержать пакеты или
подсистемы, используемые для группировки элементов модели в крупные
фрагменты.
Узлы. Узел – физический элемент, который существует в период работы
системы и представляет компьютерный ресурс, имеющий память, и возможно
способность обработки. Графически узел изображается как куб с именем. Он
56
может иметь дополнительную секцию, отображающую находящиеся в нем
элементы
.
Осн_Сервер
Контроллер
размещает
Вводы.exe
Выводы.exe
Сравним узлы с компонентами. У них есть имя, возможность быть
вложенными, наличие экземпляров. Существуют и отличия. Узлы и компоненты
принадлежат разным уровням иерархии в физической реализации системы.
Физически система состоит из узлов, а узлы – из компонентов. Компонент
предназначен для физической упаковки и материализации набора логических
элементов (классов и операций). Узел же является тем местом, где физически
размещаются компоненты. Группировку набора объектов или компонентов в узле
называют распространяемым модулем. Для узла как и для класса можно задать
свойства и операции. Диаграммы размещения используются для моделирования
статического представления того, как размещается система.
Графически
диаграмма размещения – это граф из узлов (или экземпляров узлов), соединенных
ассоциациями, которые показывают существующие коммуникации. Экземпляры
узлов могут содержать экземпляры компонентов, живущих или запускаемых в
узлах. Экземпляры компонентов могут содержать объекты. Компоненты
соединяются друг с другом пунктирными стрелками зависимостей (прямо или
через интерфейсы).
57
С:СерверДанных
:Провайдер
Заказы
«database»
База
Б:БизнеСервер
Работы
:Обработчик
Вася:Клиент
:ГрафИнтерфейс
Моделирование размещения компонентов
На этой диаграмме размещена типовая трехуровневая система:
1 - уровень базы данных реализован экземпляром С узла СерверДанных;
2 - уровень бизнес логики представлен экземпляром Б узла БизнесСервис;
3 - уровень графического интерфейса пользователя образован экземпляром Вася
узла Клиент. В узле сервера данных показано размещение анонимного экземпляра
компонента Провайдер и объекта База со стереотипом «database». Узел бизнессервера содержит анонимный экземпляр компонента Обработчик, а узел клиента
– анонимный экземпляр компонента ГрафИнтерфейс. Кроме того, здесь явно
отображены интерфейсы компонентов Провайдер и Обработчик, имеющие имена
Заказы и Работы.
Пример использования объектно – ориентированного подхода
В качестве предметной области рассмотрим работу подразделения учета
налогоплательщиков-организаций. На стадии формирования требований строится
начальная диаграмма вариантов использования. При построении вариантов
использования в первую очередь составляется список всех основных
действующих лиц (физических лиц или внешних систем, которые будут
взаимодействовать с создаваемой системой). Их можно определить, задавая
следующие вопросы:
Кто использует систему непосредственно?
Кто отвечает за эксплуатацию системы?
Какое внешнее оборудование используется системой?
Какие другие системы взаимодействуют с данной системой?
58
Варианты использования строятся исходя из следующих соображений:
каждый вариант использования представляет собой некоторую функцию,
выполняемую системой в ответ на воздействие действующего лица и
характеризует конкретный способ применения системы, диалог между
действующим лицом и системой. Нужно иметь в виду, что далее варианты
использования будут служить для описания требований к системе, общения с
конечными пользователями и экспертами предметной области, а также для
тестирования системы. На стадии проектирования уточняется диаграмма
вариантов использования и строится архитектуры системы, основой которой
являются диаграммы классов. В данном примере построим диаграммы классов и
диаграммы взаимодействия. Диаграммы взаимодействия строятся для уточнения
диаграммы вариантов использования и перехода к диаграммам классов.
Проверить документы
Налогоплательщик
Налоговый инспектор
Сформировать
Свидетельство о постановке
на учет
Зарегистрировать
налогоплательщика
Зарегистрировать
Расчетный счет
Подсистема
приема отчетности и проверки
платежей
Начальная диаграмма вариантов использования
59
Диаграмма последовательности для варианта использования
«Зарегистрировать налогоплательщика»
Форма регистрации
Налогоплательщика
:Налогоплательщик
:Налоговый
инспектор
открыть форму ()
запросить данные ()
ввести данные ()
проверить регистрацию ()
проверка регистрации ()
регистрация проверена ()
запросить регистрацию ()
присвоить ИНН ()
зарегистрировать ()
регистрация ()
регистрация выполнена ()
подтвердить регистрацию ()
закрыть форму ()
Приведенная диаграмма последовательности показывает один из
возможных сценариев развития событий в рамках варианта использования
«Зарегистрировать налогоплательщика». Предполагается, что налогоплательщик
ставится на учет впервые и все его документы в полном порядке. Структура
программной системы описывается с помощью нескольких диаграмм классов,
главная из которых представляет собой диаграмму пакетов, а остальные
диаграммы представляют собой содержимое каждого из пакетов. При построении
диаграммы классов предметной области Выделение этих классов (классов60
сущностей) может быть аналогично выделению сущностей в процессе
моделирования данных. Данные классы должны иметь концептуальный характер
и отвечать на вопрос Что?, а не Как?. Начальный список может быть составлен
так:
1 - в описании исходных данных выделяются кандидаты в классы –
существительные, которые потенциально могут соответствовать классам (но
помнить, что существительные могут относиться к объектам, ассоциациям или
атрибутам классов);
2 - анализируются роли кандидатов в системе. Каждый класс должен выполнять
некоторые действия и взаимодействовать с другими классами. Каждый класс
должен иметь уникальное имя, отражающее характер абстракции, представляемой
данным классом. Если классу трудно придумать краткое и содержательное имя,
то это характерный признак неудачного выделения класса.
Рассматривается каждая возможная пара классов и устанавливается
существование ассоциации между ними (по аналогии с установкой связей между
сущностями в процессе моделирования данных). Присваиваются наименования
ролям ассоциаций и определяется их множественность.
Далее составляется список атрибутов каждого класса (аналогично
определению атрибутов сущностей при моделировании данных). Процесс
определения атрибутов должен быть коротким, т.к. существенные атрибуты могут
быть добавлены позднее. При этом нужно убедиться, что не пропущены
существенные характеристики, представленные в исходных данных.
Определяются действия (операции), выполняемые каждым классом. При
определении операций следует учитывать:
1 - каждая операция должна выполнять одну простую функцию;
2 - название операции должно отражать результат функции, а не то, как она
выполняется.
Примерами простых операций являются: получить значение атрибута,
установить значение атрибута, добавить или исключить связь с другим объектом,
удалить данный объект.
Полученная в результате диаграмма классов предметной области показана
на следующем рисунке.
61
НалогоплательщикОрганизация
1
ГНИ
*
ИНН
КПП
Наименование организации
Юридический адрес
Фактический адрес
Код ФС
Код ОПФ
Код ОКПО
Код ОКОНХ
Код вида деятельности
Руководитель
Код ГНИ
Адрес
1
Проверить регистрацию ()
Зарегистрировать ()
1
*
*
Учредитель
Счет налогоплательщика
ИНН
Номер счета
Тип счета
Открыть счет()
Закрыть счет ()
*
1
Юридическое лицо
Код ОПФ
Код вида
Деятельности
Наименование
Адрес
Физическое лицо
Номер паспорта
Серия паспорта
Банк
Наименование
БИК
Кор.счет
Адрес
Руководи тель
Телефон
62