UML Учебный Курс ITM АНХ

Моделирование программных
систем с использованием нотации
UML 2
Учебный курс
Подготовил : Леоненков А.В.
1
Леоненков Александр Васильевич
кандидат технических наук, доцент
Personal Sertification: IBM Rational Software
„
„
„
Преподаватель:
Школы IT-менеджмента Академии народного хозяйства при
Правительстве РФ
Учебно-консалтингового Центра Interface
Интернет Университета информационных технологий
Содержание
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
Цели и особенности курса
Основные понятия визуального моделирования
История развития языка UML
Определение языка UML
Классификация моделей в языке UML
Противоречивость и адекватность моделей в нотации UML
Механизмы расширения языка UML
Управляемая моделями архитектура (MDA)
Диаграмма вариантов использования (use case diagram)
Диаграмма классов (class diagram)
Диаграмма последовательности (sequence diagram)
1
„
„
„
„
Цели и особенности курса
Знакомство с методикой построения визуальных моделей
программных систем
„ Визуальная модель – это неформальная модель!
Изучение терминологии, которая может отличаться от общепринятой
корпоративной лексики
„ Основные определения ООАП – ключ к пониманию элементов
нотации!
Изучение нотации базовых элементов языка UML
„ Графические пиктограммы – каркас всех диаграмм!
Изучение семантики базовых элементов языка UML
„ Знание семантики – гарантия разработки непротиворечивых
моделей в нотации UML!
Структура учебного материала
RUP 7
RUP 2003
Method
Composer
Разв-ние
Дисциплины RUP
БМ
УТ
А&П
Исх.
тр-ния
Текст
Анализ
Реинж-г
Use Case
Проекти
рование
RequisitePro
Rose
Р
Т
Упр-ние
RAD
Test
Предмет
проектом
нашего
Robot
изучения!
Quantify
RSA,
RSM
PureCoverage
Purify
Упр-ние
КИ
Упр-ние
средой
ClearCase
ClearQuest
IBM Rational Suite
UML 1
UML 2
Rational Rose
RSA, RSM
Borland Together
Sparx EA
MS Project
Отсутствие моделей при разработке ПО
„
„
„
„
„
„
Не позволяет справиться с растущей сложностью разрабатываемых
программных систем
Не позволяет эффективно управлять разработкой в условиях
изменяющихся требований
Создает барьеры непонимания: аналитик не понимает руководителя
проекта, разработчик – аналитика, тестировщик – разработчика и пр.
Не позволяет обеспечить адекватный контроль изменений в
процессе выполнения работ
Не позволяет избежать субъективности в оценке качества
разрабатываемых продуктов
Модель (model) — абстракция физической системы,
рассматриваемая с определенной точки зрения и представленная
на некотором языке или в графической форме
2
„
„
„
„
„
Основные понятия визуального
моделирования
Нотация – система условных обозначений для графического
представления визуальных моделей
Семантика – система правил и соглашений, определяющая
смысл и интерпретацию конструкций некоторого языка
Методология – совокупность принципов моделирования и
подходов к логической организации методов и средств разработки
моделей
CASE (Computer Aided Software Engineering) – методология
разработка программного обеспечения, основанная на
комплексном использовании компьютеров не только для
написания исходного кода, но и для анализа и моделирования
соответствующей предметной области
CASE-средства (CASE-tools) – программное обеспечение,
которое предназначено для разработки визуальных моделей
программных систем и генерации исходного кода или схемы базы
данных на некотором языке
Основные понятия ООП
„
„
„
„
„
Объектно-ориентированное программирование (ObjectOriented Programming) — совокупность принципов, технологии и
инструментальных средств для создания программных систем, в
основу которых закладывается архитектура взаимодействия
объектов
Абстракция — характеристика сущности, которая отличает ее
от других сущностей
Наследование — принцип, в соответствии с которым знание о
более общей категории разрешается применять для более
частной категории
Инкапсуляция — сокрытие отдельных деталей внутреннего
устройства классов от внешних по отношению к нему объектов
или пользователей
Полиморфизм — свойство элементов модели с одинаковыми
именами иметь различное поведение
Основные понятия ООАП
„
„
„
„
Объектно-ориентированный анализ и проектирование
(Object-Oriented Analysis/Design) — технология разработки
программных систем, в основу которых положена объектноориентированная методология представления предметной области
в виде объектов, являющихся экземплярами соответствующих
классов
Предметная область (domain) – часть реального мира, которая
имеет существенное значение или непосредственное отношение к
процессу функционирования программы
Диаграмма (diagram) — графическое представление совокупности
элементов модели в форме связного графа, вершинам и ребрам
(дугам) которого приписывается определенная семантика
Нотация канонических диаграмм является основным
средством разработки моделей на языке UML
Классификация проектов по типу приложений
Моно
пользовательские
приложения
Проекты для
Webприложения
Встроенные
Системы
мониторинга
использования внутри
компании (IIT-проекты)
Системы
Локальные БД Корпоративные Видео
БД
наблюдения
Проекты в интересах
внешнего заказчика,
аутсорсинг
Системы
Ауторизации
доступа
Бухгалтерские
Системы
(EIT-проекты)
Проекты разработки
«коробочных»
Приложений
(ISV-проекты)
Текстовые
редакторы
Графические
редакторы
Корпоративные
порталы
Использование
ERP & MES
Системы
Внедрение
модулей
ERP-систем
Кастомизация
ERP-систем
Банковские
языка
UML
Информационные
системы
необходимо!
Типовые
Интернетмагазины
Системы
контроллинга Разработка
коммерческих
ERP-систем
Графические нотации моделирования,
используемые в России
„
„
„
UML (Unified Modeling Language) – отраслевой стандарт OMG,
поддерживают более 50 CASE-средств, основной инструмент
IBM Rational Rose / IBM RSA (IBM Rational Software)
ARIS (ARchitecture of Integrated Information Systems) –
методология и нотация для профессионального моделирования
бизнес-процессов, инструмент ARIS Toolset (IDS Scheer AG)
IDEF – семейство нотаций, стандарт МО США, рекомендован
Правительством РФ для применения в государственных
учреждениях, основной инструмент AllFusion Pricess Modeller
(Computer Associations)
Взаимосвязь нотации UML, методологии и
инструментальных средств
Нотация - UML 2
Нотация – UML 2
Pest Practices
Методология
RUP
Средство
IBM Rational
Software
Architect
Методология
ALM (Application
Lifecycle
Management)
Средство
Borland
Together
Architect
3
История развития
языка UML
Спецификация языка UML 2.2:
„
Суперструктура:
09-02-02.pdf – 740 стр.
„
Инфраструктура:
07-02-04.pdf – 218 стр.
„
Object Constrain Language
v.2.0:
2005-06-06.pdf – 185 стр.
„
Diagram Interchange:
03-07-03.pdf – 34 стр.
„
Model Driven Architecture
03-06-01.pdf – 62 стр.
„
www.omg.org
2009 г.
февраль
(formal/09-02-02)
UML 2.2
2007 г.
ноябрь
(formal/07-11-02)
UML 2.1.2
2007 г.
февраль
(formal/07-02-03)
UML 2.1.1
2005 г.
август
(formal/05-07-04)
UML 2.0
2004 г.
октябрь
(ptc/04-10-02)
2003 г.
март
(ptc/03-07-06)
Draf t
UML 2.0
1996 г.
июньоктябрь
1995 г.
октябрь
UML 1.5
(ptc/03-03-01)
UML 1.4
UML 1.3
1999 г.
июнь
1997 г.
январь
Current
Of f icial
Version
UML 2.0
2001 г.
сентябрь
1997 г.
ноябрь
SysML 1.0
UML 1.1
UML 1.0
UML 0.9/0.91
Унифицированный
метод 0.8
Гаф ические нотации визуал ьного
м одел ирования (конец 80-х гг.)
Поддержка
OM G
Партнеры по
разработке
UM L
Метод
OOSE
Язык UML 2 и современные информационные
технологии
MDA
Model Driven
Architecture
GoF
Design patterns
J2EE
Java 2
Enterprise
Edition
SysML
OCL
Systems
Modeling
Language
Object
Constraint
Language
BPML, BPMN
SOA
Service-oriented
architectures
BPEL
Business Process
Execution Language
Business Process
Modeling Language/
Notation
4
•
•
Определение языка UML
Unified Modeling Language — унифицированный язык
моделирования для описания, визуализации и документирования
объектно-ориентированных систем в процессе их анализа и
проектирования
Язык UML предоставляет стандартный способ написания проектной
документации на системы, включая концептуальные аспекты, такие
как бизнес процессы и функции системы, а также конкретные
аспекты, такие как выражения языков программирования, схемы баз
данных и повторно используемые компоненты ПО
„ Язык UML не является методологией
„ Язык UML не является процессом
„ Язык UML не является языком программирования
„ Язык UML не является формальным языком
UML = нотация + семантика !
Назначение языка UML
„
„
„
„
„
„
Предоставить разработчикам легко воспринимаемый и выразительный
язык визуального моделирования, специально предназначенный для
разработки и документирования моделей сложных систем различного
целевого назначения
Снабдить исходные понятия языка UML возможностью расширения и
специализации для более точного представления моделей систем в
конкретной предметной области
Графическое представление моделей в нотации UML не должно зависеть
от конкретных языков программирования и инструментальных средств
проектирования
Описание языка UML должно включать в себя семантический базис для
понимания общих особенностей ООАП
Способствовать распространению объектных технологий и поощрять
развитие рынка программных инструментальных средств
Интегрировать в себя новейшие и наилучшие достижения практики ООАП
5
Классификация моделей в языке UML
Система
„
„
„
„
„
Имеет структуру
Обладает поведением
Структурные модели (structured models) – модели,
предназначенные для описания статической структуры сущностей
или элементов некоторой системы, включая их классы,
интерфейсы, атрибуты и отношения
Модели поведения (behavioral models) – модели, предназначенные
для описания процесса функционирования элементов системы,
включая их методы и взаимодействие между ними, а также
процесс изменения состояний отдельных элементов и системы в
целом
Количество диаграмм различных типов для модели конкретного
приложения не является строго фиксированным!
Канонические диаграммы языка UML 2
Диаграмма
вариантов
использования
Диаграмма
последовательн
ости
Диаграмма
классов
Диаграмма
пакетов
ИНТЕГРИРОВАННАЯ
МОДЕЛЬ СЛОЖНОЙ
СИСТЕМЫ
Диаграмма
композитной
структуры
Диаграмма
компонентов
Диаграмма
конечного
автомата
Диаграмма
обзора
взаимодействия
Временная
диаграмма
Диаграмма
коммуникации
Диаграмма
деятельности
Диаграмма
объектов
Диаграмма
развертывания
Особенности изображения диаграмм в
нотации UML
„
„
„
„
Графические узлы на плоскости, которые изображаются с
помощью геометрических фигур и могут иметь различную высоту и
ширину с целью размещения внутри этих фигур других конструкций
языка UML
Пути, которые представляют собой последовательности из отрезков
линий, соединяющих отдельные графические узлы
Значки или пиктограммы. Значок представляет собой
графическую фигуру фиксированного размера и формы, которая не
может увеличивать свои размеры, чтобы разместить внутри себя
дополнительные символы.
Строки текста. Служат для представления различных видов
информации в некоторой грамматической форме.
Общие рекомендации по изображению
диаграмм в нотации языка UML
„
„
„
„
„
„
Каждая диаграмма должна служить законченным представлением
соответствующего фрагмента моделируемой предметной области
Все сущности на диаграмме модели должны быть одного
концептуального уровня
Вся информация о сущностях должна быть явно представлена на
диаграммах
Диаграммы не следует перегружать текстовой информацией
Каждая диаграмма должна быть самодостаточной для правильной
интерпретации всех ее элементов и понимания семантики всех
используемых графических символов
Диаграммы не должны содержать противоречивой информации!
6
„
„
„
„
„
„
„
Противоречивость и адекватность
моделей в нотации UML
Модель, соответствующая правилам нотации или семантики языка
UML называется непротиворечивой (well-formed model)
Модель, нарушающая правила нотации или семантики языка UML
называется противоречивой (ill-formed model)
Здесь могут быть использованы формальные критерии –
соответствие спецификации языка UML! (аудит и проверка)
Модель, достаточно полно и правильно отражающая предметную
область или решаемую проблему называется адекватной
Модель, не достаточно полно или неправильно отражающая
предметную область или решаемую проблему называется не
адекватной
Здесь могут быть использованы только неформальные критерии –
субъективное мнение экспертов!
Моя модель – это не ваша модель, а ваша модель – не моя!
7
„
„
„
Механизмы расширения языка UML
Стереотип (stereotype) — элемент
модели, который расширяет
семантику некоторого базового
элемента метамодели языка UML, но
не переопределяет существующие
типы элементов
Ограничение (constraint) —
некоторое логическое условие,
ограничивающее семантику
выбранного элемента модели
Помеченное значение (tagged value)
— явное определение некоторого
свойства объекта как пары "имя –
значение"
Стереотипы в языке UML
„
„
„
„
В форме текста, заключенного в двойные угловые кавычки и
размещенного выше или перед именем элемента модели
„ Первая буква текста имени стереотипа не должна быть заглавной
буквой («entity», «control», «boundary»)
„ Текстовые стереотипы — ключевые слова языка UML!
В форме графической пиктограммы, которая заменяет текст имени
соответствующего стереотипа
„ описываются
в профилях языка UML и поддерживаются
некоторыми CASE-средствами
В форме прямоугольника класса с уменьшенной пиктограммой
стереотипа внутри этого прямоугольника, расположенного в верхнем
правом углу
Некоторые стереотипы предопределены в языке UML, другие могут
быть определены разработчиками
Профилирование языка UML для различных
областей приложений
„
„
„
„
„
„
„
„
„
„
„
„
UML Profile for Software Development Processes
UML Profile for Business Modeling
UML Profile for Patterns
UML Profile for CORBA® (EJB)
UML Profile for CORBA® Component Model (CCM)
UML Profile for Enterprise Application Integration (EAI)
UML Profile for Enterprise Collaboration Architecture (ECA)
UML Profile for Enterprise Distributed Object Computing (EDOC)
UML Profile for Quality of Service (QoS) and Fault Tolerance
UML Profile for Meta Object Facility
UML Profile for Relationships
UML Profile for Schedulability, Performance, and Time
8
„
„
„
„
Управляемая моделями архитектура
MDA (Model Driven Architecture) – Управляемая моделями архитектура
„ Концепция проектирования архитектур много платформенных
приложений, в рамках которой поддерживается управляемый
моделями подход для разработки программного обеспечения
CIM (Computation Independent Model) – Независимая от вычислений
модель
„ Представление системы, которое концентрирует внимание на
предметной области решаемой задачи или проблемы, скрывая
детали их процедурной реализации
PIM (Platform Independent Model) – Платформенно-независимая
модель
„ Представление системы, которое концентрирует внимание на
общей архитектуре системы и скрывает детали, необходимые для
ее реализации на отдельной платформе
PSM (Platform Specific Model) – Платформенно-зависимая модель
„ Представление системы, которое специфицирует все
особенности, необходимые для ее реализации на конкретной
платформе
9
„
Диаграмма вариантов использования
(use case diagram)
– диаграмма, на которой изображаются варианты использования
проектируемой системы, заключенные в границу системы, и внешние
актеры, а также определенные отношения между актерами и вариантами
использования
<<extend>>
Клиент Банка
Пополнить счет
Открыть счет
варианты использования
актеры
Кассир
<<extend>>
Операционист
ассоциации
Снять деньги со счета
Закрыть счет
зависимость с текстовым
стереотипом
Назначение диаграммы вариантов
использования
„
„
„
„
Определить общие границы функциональности проектируемой
системы в контексте моделируемой предметной области
Специфицировать требования к функциональному поведению
проектируемой системы в форме вариантов использования
Разработать исходную концептуальную модель системы для ее
последующей детализации в форме логических и физических
моделей
Подготовить исходную документацию для взаимодействия
разработчиков системы с ее заказчиками и пользователями
Вариант использования (use case)
„
„
„
– представляет собой общую спецификацию совокупности
выполняемых системой действий с целью предоставления
некоторого наблюдаемого результата, который имеет
значение для одного или нескольких актеров
Отвечает на вопрос «Что должна выполнять система?», не
отвечая на вопрос «Как она должна выполнять это?»
Имена – отглагольное существительное или глагол в
неопределенной форме
<<use case>>
Формирование отчета по
выполненным заказам
Проверка состояния
текущего счета клиента
Формирование отчета по
выполненным заказам
Актер (actor)
„
„
– любая внешняя по отношению к проектируемой системе сущность,
которая взаимодействует с системой и использует ее
функциональные возможности для достижения определенных целей
или решения частных задач
Примеры актеров: кассир, клиент банка, банковский служащий,
президент, продавец магазина, менеджер отдела продаж, пассажир
авиарейса, водитель автомобиля, администратор гостиницы,
сотовый телефон
Клиент банка
<<actor>>
Посетитель
Интернет-магазина
Удаленный
пользователь
Вопросы для идентификации актеров в
системе
„
„
„
„
„
„
„
Какие организации или лица будут использовать систему
Кто будет получать пользу от использования системы
Кто будет использовать информацию от системы
Будет ли использовать система внешние ресурсы
Может ли один пользователь играть несколько ролей при
взаимодействии с системой
Могут ли различные пользователи играть одну роль при
взаимодействии с системой
Будет ли система взаимодействовать с законодательными,
исполнительными, налоговыми или другими органами
Отношение ассоциации
„
„
„
Ассоциация (association) является одним из фундаментальных
понятий в языке UML 2 и может использоваться на различных
канонических диаграммах при построении визуальных моделей
Применительно к диаграммам вариантов использования отношение
ассоциации может служить только для обозначения взаимодействия
актера с вариантом использования
Полный набор свойств отношения ассоциации на данных
диаграммах не используется!
Просмотр списка
представленных товаров
Посетитель
Интернет-магазина
Отношение включения
„
„
Отношение зависимости (dependency)
определяется как форма взаимосвязи
между двумя элементами модели,
предназначенная для спецификации
того обстоятельства, что изменение
одного элемента модели приводит к
изменению некоторого другого
элемента
Отношение включения (include)
специфицирует тот факт, что
некоторый вариант использования
содержит поведение, определенное в
другом варианте использования
Оформление Заказа в
Интернет-магазине
вариант использования А
<<include>>
Регистрация
покупателя
вариант использования Б
Отношение расширения
„
Отношение расширения (extend)
определяет взаимосвязь одного
варианта использования с
некоторым другим вариантом
использования, функциональность
или поведение которого
задействуется первым не всегда, а
только при выполнении некоторых
дополнительных условий
Оформление Заказа в
Интернет-магазине
вариант использования А
<<extend>>
Предоставление бонусной
скидки постоянному
покупателю
вариант использования Б
Изображение отношения расширения с
условием выполнения
Условие: {клиент имеет бонусную карточку}
extention point:Скидка
Оформление Заказа в
Интернет-магазине
extention point
Скидка
<<extend>>
Предоставление бонусной
скидки постоянному
покупателю
Отношение обобщения
„
„
Отношение обобщения (generalization) предназначено для
спецификации того факта, что один элемент модели является
специальным или частным случаем другого элемента модели
Данное отношение реализует принцип наследования ООП!
Оплата выбранного в
Интернет-магазине товара
Оплата товара по
кредитной карточке
вариант использования А
вариант использования Б
Посетитель
Интернет-магазина
Покупатель
(актер А)
(актер Б)
Формализация функциональных
требований с помощью диаграммы ВИ
„
„
„
Требование (requirement) – желательное свойство, характеристика
или условие, которым должна удовлетворять система в процессе
своей эксплуатации
Требование к ПО – некоторое свойство ПО, которым должна
обладать система или ее компонент, чтобы удовлетворять
условиям контракта, положениям стандартов, формальной
спецификации или технической документации
Управление требованиями – это систематический подход к
выявлению, организации и документированию требований к
системе, а также процесс, в ходе которого вырабатывается и
обеспечивается соглашение между заказчиком и разработчиком по
поводу меняющихся требований к системе
Модель классификация требований
FURPS+
Functionality – (функциональные требования)
„ Usability
(требования практичности)
„ Reliability
(требования надежности)
„ Performance (требования производительности)
„ Supportability (требования обслуживания и
сопровождения)
Дополнительно + IEEE 610.12.1990
„ Проектные ограничения
„ Требования выполнения
„ Требования к GUI
„ Физические требования
„
Функциональные и нефункциональные
требования
„
„
Функциональные требования определяют действия, которые
должна быть способна выполнить система, без рассмотрения
физических особенностей их реализации
„ функциональные требования определяют внешнее поведение
системы
„ лучше всего они описываются в форме модели вариантов
использования
„ каждому функциональному требованию в этом случае будет
соответствовать отдельный вариант использования
Требования, которые не содержат функциональности, называются
нефункциональными требованиями
„ описывают атрибуты системы или атрибуты среды
„ как правило, описываются в Дополнительной спецификации,
которая является артефактом проекта, выполняемого в
соответствии с методологией RUP
Последовательность разработки
вариантов использования
„
„
„
„
„
„
„
Определить главных (первичных) актеров и определить их цели по
отношению к системе
Специфицировать все базовые (основные) варианты
использования
Выделить цели базовых ВИ, интересы актеров в контексте этих ВИ,
предусловия и постусловия ВИ
Написать успешный сценарий выполнения базовых ВИ
Определить исключения (неуспех) в сценариях ВИ и написать
сценарии для всех исключений
Выделить ВИ исключений и изобразить их со стереотипом «extend»
Выделить общие фрагменты функциональности ВИ и изобразить их
отдельными ВИ со стереотипом «include»
Показатели качества для модели
вариантов использования
„
„
„
„
„
„
Все ли функциональные требования описываются вариантами
использования?
Не содержит ли модель вариантов использования ненужное
поведение, которое отсутствует в требованиях?
Действительно ли в модели необходимы все выявленные связи
включения, расширения и обобщения?
Правильно ли произведено деление модели на пакеты вариантов
использования?
Стала ли модель в результате деление на пакеты проще и
удобнее для восприятия и сопровождения?
Можно ли на основе модели вариантов использования составить
четкое представление о функционировании системы в контексте
ее пользователей?
UML Profile for Business Modeling
• Бизнес вариант использования –
элемент модели, предназначенный для
представления отдельного бизнес
процесса
• Реализация бизнес варианта
использования – описывает реализацию
отдельного бизнес варианта
использования в терминах кооперации
объектов, экземпляров сотрудников и
бизнес сущностей
UML Profile for Business Modeling
• Бизнес актер – индивидуум, группа,
организация, компания или система, которые
взаимодействуют с моделируемой системой
(компанией), но не входят в нее. Примеры –
клиенты, поставщики, партнеры.
• Сотрудник – индивидуум, который действует
внутри моделируемой системы (компании),
взаимодействует с другими сотрудниками и
манипулирует бизнес сущностями.
• Организационная единица – пакет, в состав
которого могут входить сотрудники, бизнес
сущности, реализации бизнес вариантов
использования, диаграммы языка UML и другие
организационные единицы
Типичные ошибки при разработке диаграмм
вариантов использования
„
„
„
„
„
„
„
Превращение диаграммы вариантов использования в диаграмму
деятельности за счет желания отразить все функциональные
действия
Инициатором действий является разрабатываемая система
Спецификация атрибутов и операций классов до того, как
сформулированы все варианты использования
Задание слишком кратких имен вариантам использования
Описание вариантов использования в терминологии, непонятной
пользователям системы или заказчику
Отсутствие описаний альтернативных последовательностей
действий
Тратится слишком много времени на решение вопросов о том,
какие стереотипы и ассоциации использовать на диаграмме
10
„
„
„
„
Диаграмма классов (class diagram)
Диаграмма классов — диаграмма, предназначенная для
представления модели статической структуры программной
системы в терминологии классов объектно-ориентированного
программирования
Диаграмма классов представляет собой граф, вершинами или
узлами которого являются элементы типа “классификатор”,
которые связаны различными типами структурных отношений
Диаграмма классов — основная логическая модель проектируемой
системы!
Класс (class) – элемент модели, который описывает множество
объектов, имеющих одинаковые спецификации характеристик,
ограничений и семантики
Элементы нотации диаграммы классов
Разновидности классов
„
„
„
„
„
Абстрактный (abstract) класс не имеет экземпляров или объектов,
для обозначения его имени используется наклонный шрифт
(курсив)
Активный класс (active class) – класс, каждый экземпляр которого
имеет свою собственную нить управления
Пассивный класс (passive class) – класс, каждый экземпляр
которого выполняется в контексте некоторого другого объекта
Квалифицированное имя (qualified name) используется для того,
чтобы явно указать, к какому пакету относится тот или иной класс
„ в качестве разделителя в имени класса применяется
специальный символ – двойное двоеточие “::”
Простое имя класса – имя класса без символа разделителя
Формат записи атрибутов класса
Атрибут (attribute) класса служит для представления отдельной
структурной характеристики или свойства, которое является общим
для всех объектов данного класса
„ Общий формат записи отдельного атрибута класса следующий
(БНФ):
„ <атрибут>::= [<видимость>] [‘/’] <имя> [‘:’ <тип атрибута>]
[‘[‘<кратность>‘]’] [‘=’ <значение по умолчанию>]
[‘{‘<модификатор атрибута> [‘,’ <модификатор атрибута>]* ’}’]
„ видимость (visibility) может принимать одно из 4-х возможных
значений и отображаться либо посредством специального символа,
либо соответствующего ключевого слова
„ <видимость>::= ‘+’ | ‘–‘ | ‘#’ | ‘~’
„
Вид видимости
„
„
„
„
+ public (общедоступный)
„
общедоступный элемент является видимым всеми элементами,
который имеют доступ к содержимому пространства имен,
который им владеет
- private (закрытый)
„
закрытый элемент является видимым только внутри
пространства имен, который им владеет
# protected (защищенный)
„
защищенный элемент является видимым для элементов,
которые имеют отношение обобщения с пространством имен,
который им владеет
~ package (пакет)
„
элемент, помеченный как имеющий пакетную видимость,
является видимым всеми элементами в ближайшем
охватывающем пакете
„
за пределами ближайшего охватывающего пакета элемент,
помеченный как имеющий пакетную видимость, не является
видимым
Элементы записи атрибута
„
„
“/” означает, что атрибут является производным (derive)
„ значение производного атрибута может быть вычислено на
основе значений других атрибутов этого или других классов
„ данный атрибут называют иногда вычислимым
„ при использовании производных атрибутов разработчик должен
явно указать процедуру или операцию для вычисления их
значений
<имя> (name) представляет собой строку текста, которая
используется в качестве идентификатора соответствующего
атрибута и поэтому должна быть уникальной в пределах данного
класса
„ имя атрибута является единственным обязательным элементом
в обозначении атрибута, должно начинаться со срочной (малой)
буквы и, как правило, не должно содержать пробелов
Элементы записи атрибута
„
„
„
<тип атрибута> (attribute type) – имя классификатора, который
является типом данного атрибута
„ тип атрибута представляет собой имя некоторого типа данных,
определенного в языка UML или в форме отдельного класса
„ простейшие типы в языке UML: Integer, Boolean, String,
UnlimitedNatural
<кратность> (multiplicity) атрибута характеризует общее
количество конкретных значений для атрибута, которые могут
быть заданы для объектов данного класса
<значение по умолчанию> (default) – некоторое выражение,
которое служит для задания начального значения или значений
данного атрибута в момент создания отдельного экземпляра
соответствующего класса
„ конкретное значение по умолчанию должно соответствовать
типу данного атрибута
Примеры записи атрибутов
„
„
„
„
„
+ имяСотрудника : String
„ простейший тип атрибута
~ датаРождения : Data
„ тип атрибута должен быть определен разработчиком
# /возрастСотрудника : Integer
„ вычислимый атрибут, должна быть определена процедура
вычисления его значения
+ номерТелефона : Integer [1..*] {unique}
„ кратный атрибут, значения которого не должны повторяться
– заработнаяПлата : Currency = 500.00
„ тип атрибута должен быть определен разработчиком
„ для всех экземпляров класса задается значение по умолчанию
данного атрибута
Формат записи операций класса
„
„
„
„
„
Операция (operation) класса служит для представления отдельной
характеристики поведения, которая является общей для всех
объектов данного класса
Общий формат записи отдельной операции класса следующий
(БНФ):
<операция>::=[<видимость>] <имя операции> ‘(‘ [<список
параметров>] ‘)’ [‘:’ [<тип возвращаемого результата>] ‘{‘
<свойство операции> [‘,’ <свойство операции>]* ‘}’]
<видимость> ::= ‘+’ | ‘-‘ | ‘#’ | ‘~’
<имя операции> (operation name) представляет собой строку текста,
которая используется в качестве идентификатора соответствующей
операции и поэтому должна быть уникальной для каждой операции
данного класса
Формат записи операции класса
„
„
„
„
„
<список параметров> (parameter list) представляет собой
перечень разделенных запятыми формальных параметров
операции и имеет следующий общий формат записи (БНФ):
<список параметров> ::= <параметр> [‘,’<параметр>] *
<параметр> ::= [<направление>] <имя параметра> ‘:’
<выражение типа> [‘[‘<кратность>’]’] [‘=’ <значение по
умолчанию>] [‘{‘ <свойство параметра > [‘,’ <свойство
параметра>]* ‘}’]
<направление> ::= ‘in’ | ‘out’ | ‘inout’| ‘return‘. Если оно не указано,
то по умолчанию принимается значение “in”.
<тип возвращаемого результата> (return type) специфицирует
тип значения, возвращаемого данной операцией
Примеры записи операций
„
+ нарисоватьПрямоугольник (x : Integer, y : Integer, x1 : Integer, y1
: Integer)
„
– изменитьЗначение(inout заработнаяПлата : Currency)
„
# создатьОбъект() : Boolean
„
~ преобразоватьВСтроку(in значение : Integer) : String
Ассоциация
„
„
„
„
„
„
Ассоциация (association) – произвольное отношение или взаимосвязь
между классами
Имя конца ассоциации специфицирует роль (role), которую играет
класс, расположенный на соответствующем конце рассматриваемой
ассоциации
Видимость конца ассоциации специфицирует возможность доступа
к соответствующему концу ассоциации с других ее концов
Кратность конца ассоциации специфицирует возможное
количество экземпляров соответствующего класса, которое может
соотноситься с одним экземпляром класса на другом конце этой
ассоциации
Символ наличия навигации (navigable) изображается с помощью
простой стрелки в форме буквы «V» на конце ассоциации
Символ отсутствия навигации (non navigable) изображается с
помощью буквы «X» на линии у конца ассоциации
Бинарная ассоциация между классами
Символ направления чтения
ассоциации
Имя ассоциации
Имя конца ассоциации
Сотрудник
+работник
Имя конца ассоциации
Работает
1..*
+работодатель
1
Кратность конца
ассоциации
Компания
Обобщение
„
Обобщение (generalization) – таксономическое отношение между
общим классификатором (родителем или предком) и специальным
классификатором (дочерним или потомком)
Класс-предок
Прямоугольник
+имя: String
+цветЗаливки : Color
+высота : Interger = 5
+ширина : Interger
/площадь : Interger {readOnly}
Класс-потомок
Квадрат
+id {redefines имя}
+высота = 7
/ширина
(а)
(б)
Агрегация
„
Агрегация (aggregation) – направленное отношение между двумя
классами, предназначенное для представления ситуации, когда один
из классов представляет собой некоторую сущность, которая
включает в себя в качестве составных частей другие сущности
Класс-контейнер
Класс-часть
Персональный
компьютер
Системный
блок
Монитор
Клавиатура
Мышь
Композиция
„
Композиция (composition) или композитная агрегация предназначена
для спецификации более сильной формы отношения "часть-целое",
при которой с уничтожением объекта класса-контейнера
уничтожаются и все объекты, являющимися его составными частями
Класс-композит
Класс-часть
Окно программы
1
1
Заголовок
1
2
Полоса
прокрутки
1
1
1
Рабочая
область
1
Главное
меню
Интерфейс
„
Интерфейс (interface) – вид класса, который представляет собой
объявление множества общедоступных характеристик и
обязанностей
СигналТревоги
<<interface>>
IДатчик
включить()
прочитать()
требуемый
интерфейс
БесконтактныйДатчик
предоставляемый
интерфейс
СигналТревоги
БесконтактныйДатчик
IДатчик
UML Profile for Software Development
Processes
„
„
„
Управляющий класс отвечает за
координацию действий других
классов. Этому классу посылают
мало сообщений, а он рассылает
много сообщений
Граничный класс располагается на
границе системы с внешней средой.
Класс-сущность содержит
информацию, которая хранится
постоянно и не уничтожается с
выключением системы
11
„
„
„
Диаграмма последовательности
(sequence diagram)
Диаграмма последовательности – диаграмма, которая служит для
представления взаимодействия элементов модели в форме
последовательности сообщений и соответствующих событий на
линиях жизни объектов
Взаимодействие (interaction) – единица поведения некоторого
классификатора, которая концентрирует внимание на наблюдаемом
обмене информацией между элементами, являющимися
участниками этого взаимодействия
Линия жизни (lifeline) – представляет одного индивидуального
участника взаимодействия или отдельную взаимодействующую
сущность
Семантика времени на диаграмме
последовательности
„
„
„
„
„
„
Ось времени присутствует неявно и направлена сверху вниз
Масштаб для оси времени на диаграмме последовательности не
указывается, поскольку эта диаграмма предназначена для
моделирования только лишь временного порядка следования
сообщений типа "раньше-позже”
Абсолютные расстояния между наступлениями событий на линиях
жизни не имеют семантики, т.е. смысла
Сообщения, расположенные на диаграмме выше, передаются
раньше, чем сообщения, расположенные ниже
Время на диаграмме последовательности имеет шкалу порядка, а не
шкалу отношений, о чем необходимо знать всем разработчикам
При необходимости для отдельных событий на диаграмме можно
специфицировать временные ограничения
Элементы диаграммы последовательности
Сообщение
„
„
„
Сообщение (message) – элемент модели, предназначенный для
представления отдельной коммуникации между линиями жизни
некоторого взаимодействия
В качестве сообщения на диаграмме последовательности может
выступать имя операции или сигнала
„
Если сообщением является имя операции, то данная операция
должна быть определена у класса, экземпляру которого
передается данное сообщение
„
Если сообщением является имя сигнала, то у класса,
экземпляру которого передается данное сообщение, должен
быть определен протокол реакции на данный сигнал
Сорт сообщения (message sort) – представляет собой
разновидность сообщения, которая служит для идентификации
характера коммуникации, лежащей в основе реакции на данное
сообщение
Нотация и семантика сортов сообщений
„
„
„
„
„
Синхронное сообщение (synchCall) – соответствует синхронному
вызову операции или метода
„ изображается сплошной линией с закрашенной стрелкой
Асинхронное сообщение (asynchCall) – соответствует асинхронному
вызову операции или метода
„ изображается сплошной линией с открытой стрелкой в форме
буквы “V”
Асинхронный сигнал (asynchSignal) – соответствует некоторому
асинхронному действию
„ изображается сплошной линией с открытой стрелкой в форме
буквы “V”
Ответное сообщение (reply) от вызова метода
„ изображается пунктирной линией с открытой стрелкой в форме
буквы “V”
Сообщение создания объекта (object creation) также изображается
пунктирной линией с открытой стрелкой в форме буквы “V”
Комбинированный фрагмент
„
„
„
„
Комбинированный фрагмент (combined fragment) – элемент модели,
предназначенный для представления внутренней логической
структуры фрагментов взаимодействия
Операнд взаимодействия (interaction operand) – отдельный
фрагмент взаимодействия, предназначенный для использования в
качестве внутренней части комбинированного фрагмента
Ограничение взаимодействия (interaction constraint) представляет
собой логическое выражение, которое выступает в роли сторожевого
условия некоторого операнда в комбинированном фрагменте
Оператор взаимодействия (interaction operator) – определяет тип
комбинированного фрагмента и является перечислением следующих
12 литералов: alt, assert, break, critical, ignore, consider, loop, neg,
opt, par, seq, strict
Графическое изображение комбинированного
фрагмента
sd Комбинированные
фрагменты
ob1: C1
ob2: C2
ob3: C3
Операнды
взаимодействия
par
Оператор
взаимодействия
opt
[x>0]
Разделитель
операндов
взаимодействия
Ограничение
взаимодействия
фрейм
комбинированного
фрагмента
Альтернативы
„
„
„
„
„
„
Альтернативы (alternatives) – комбинированный фрагмент с
оператором взаимодействия alt, который представляет некоторый
выбор поведения
Данный фрагмент должен иметь не менее двух операндов
Выбор может быть сделан не более чем одного из операндов
Выбранный операнд должен иметь явное или неявное выражение
сторожевого условия, которое в этой точке взаимодействия должно
принимать значение «истина»
Если операнд не имеет никакого сторожевого условия, то неявно
предполагается, что сторожевое условие имеет значение «истина»
Операнд, помеченный сторожевым условием [else], обозначает
отрицание дизъюнкции всех других сторожевых условий этого
комбинированного фрагмента
Пример комбинированного фрагмента
Альтернативы
sd Покупка товара
:Покупатель
:Кассир
alt
[кредит не
превышен]
создать()
оплатитьПоКарте()
[кредит
превышен]
оплатитьНаличными()
оформитьДоставку()
:Транзакция
Завершение
„
„
„
„
„
Завершение (break) – комбинированный фрагмент с оператором
взаимодействия break, который представляет некоторый сценарий
завершения взаимодействия
Этот сценарий выполняется вместо оставшейся части фрагмента
взаимодействия, который содержит этот соответствующий операнд
Оператор Завершение содержит некоторое сторожевое условие
Если это сторожевое условие принимает значение “истина”, то
выполняется комбинированный фрагмент Завершение, а оставшаяся
часть фрагмента взаимодействия, содержащего этот операнд,
игнорируется
Если сторожевое условие операнда Завершение принимает значение
“ложь”, то операнд Завершение игнорируется, и выполняется оставшаяся
часть фрагмента взаимодействия, содержащего этот операнд
Пример комбинированного фрагмента
Завершение
break
Цикл
„
„
„
„
„
Цикл (loop) – комбинированный фрагмент с оператором
взаимодействия loop, который представляет собой циклическое
повторение некоторой последовательности сообщений
„ Операнд цикла повторяется несколько раз
„ Условие цикла включает нижний и верхний пределы числа
повторений цикла, а также некоторое логическое выражение.
Оператор цикла имеет следующий синтаксис (БНФ):
<цикл> ::=‘loop’[‘(‘ <minint> [‘,’ <maxint> ] ‘)’]
где <minint> ::= натуральное число, которое обозначает
минимальное количество итераций цикла;
<maxint> ::= натуральное число, которое обозначает максимальное
количество итераций цикла.
Значение <maxint> должно быть больше или равно <minint> | ‘*’
„ где символ ‘*’ означает бесконечность
Семантика цикла
„
„
„
„
„
Операнд цикла всегда повторяется минимальное число раз, которое
равно значению <minint>
После того, как минимальное число повторений будет выполнено,
проверяется логическое выражение сторожевого условия
Если это логическое выражение принимает значение “ложь”, то
выполнение цикла на этом заканчивается
Если же логическое выражение принимает значение “истина”, а
количество выполненных итераций не превышает значения
<maxint>, то происходит еще одно выполнение цикла
После этого снова проверяется логическое выражение сторожевого
условия, аналогично процедуре выполнения минимального числа
повторений
Пример комбинированного фрагмента Цикл
sd Снятие наличных
:Клиент
Банкомата
loop (1, 3)
:Клавиатура
Банкомата
:Контроллер
Банкомата
[result==false]
вводПИНкода()
result=проверитьКод()
Необязательный
„
„
„
„
„
Необязательный (option) – комбинированный фрагмент с
оператором взаимодействия opt, который представляет выбор
поведения, когда или выполняется единственный операнд, или
вовсе ничего не выполняется
Необязательный комбинированный фрагмент состоит из одного
операнда со сторожевым условием
Операнд выполняется, если сторожевое условие принимает
значение «истина»
В противном случае операнд не выполняется
Оператор выбора семантически эквивалентен альтернативному
комбинированному фрагменту, в котором имеется один операнд с
непустым содержанием, а второй операнд отсутствует
Параллельный
„
„
„
„
Параллельный (parallel) – комбинированный фрагмент с оператором
взаимодействия par, который представляет некоторое параллельное
выполнение взаимодействий своих операндов
Каждый операнд изображается в отдельном регионе, который
отделяется от других регионов пунктирной линией
Наступление событий у различных операндов могут чередоваться во
времени произвольным образом
Внутри каждого операнда соблюдается порядок следования
сообщений
Критический регион
„
„
„
„
Критический регион (critical region) – комбинированный фрагмент
Оператор взаимодействия critical траектории которого не могут
чередоваться с другими спецификациями наступления событий на
тех линиях жизни, которые этот регион покрывает.
Критический регион рассматривается как неделимый при
определении множества возможных траекторий диаграммы или
региона, который его содержит
Множество траекторий критического региона не может прерываться
другими событиями, происходящими вне этого региона
На практике Критический регион используется, как правило,
совместно с оператором параллельности
Пример комбинированных фрагментов
Параллельный и Критический регион
sd Критический Регион
:Пользователь
БД
par
:СУБД
запрос(код)
обработкаЗапроса(код)
запрос(код)
обработкаЗапроса(код)
critical
обновление(данные)
обработкаОбновления(данные)
Рассмотрение и Игнорирование
„
„
„
„
Рассмотрение (consider) – комбинированный фрагмент с
оператором взаимодействия consider, в котором изображены только
те типы сообщений, какие должны рассматриваться в этом
фрагменте
Это эквивалентно определению того, что при рассмотрении данного
фрагмента игнорируются любые другие сообщения, которые не
изображены в этом фрагменте.
Игнорирование (ignore) – комбинированный фрагмент с оператором
взаимодействия ignore, в котором имеются некоторые типы
сообщений, не изображенные на данной диаграмме
Эти типы сообщений рассматриваются как несущественные и могут
появляться в траекториях при выполнении соответствующего
фрагмента
Примеры Рассмотрения и Игнорирования
„
„
„
Список сообщений следует за операндом и заключается в фигурные
скобки согласно следующему формату:
<оператор> ::=‘consider‘’|‘ignore’ {‘<имя-сообщения>[‘,’<имясообщения>]*‘}’
Выражение consider {m, s} указывает, что в соответствующем
фрагменте только сообщения m и s рассматриваются как
существенные, а все остальные могут быть проигнорированы
Выражение ignore {q, r} указывает, что в соответствующем
фрагменте только сообщения q и r рассматриваются как
несущественные, все остальные изображены в данном фрагменте
Отрицание (neg)
„
„
„
„
Отрицание (negative) – комбинированный фрагмент с оператором
взаимодействия neg, который представляет траектории, которые
определяются как недействительные или недопустимые
Множество траекторий, которые определяют комбинированный
фрагмент с оператором взаимодействия neg, равно множеству
траекторий, заданных его единственным операндом
При этом в это множество входят только недействительные или
запрещенные траектории
Все фрагменты взаимодействия, кроме Отрицания,
рассматриваются в положительном смысле, т.е. они описывают
траектории, которые являются допустимыми и возможными
Литература -1
„
„
„
„
„
„
„
„
Леоненков А.В. Самоучитель UML 2. – СПб.: «БХВ – Петербург», 2007. –
576 с.
Леоненков А.В. Объектно-ориентированный анализ и проектирование с
использованием UML и IBM Rational Rose. – М.: Интернет-Университет
Информационных технологий: БИНОМ, Лаборатория знаний, 2006. – 320 с.
Буч Г., Максимчук Р.А, Энгл М.У., Янг Б.Д., Коналлен Д., Хьюстон К.А.
Объектно-ориентированный анализ и проектирование с примерами
приложений, 3-е изд./Пер. с англ. - М.: ООО «Вильямс», 2008. – 720 с.
Буч Г., Якобсон А., Рамбо Дж. UML. Классика CS. 2-е изд. Пер. с англ. СПб: «Питер», 2006. - 736 с.:ил.
Буч Г., Рамбо Дж., Джекобсон А. Язык UML. Руководство пользователя:
Пер. с англ. – М.: ДМК, 2000. –432 с.
Рамбо Д., Блаха М. UML 2. 0. Объектно-ориентированное моделирование и
разработка. Пер. с англ. - СПб: «Питер», 2007. - 544 с.:ил.
Рамбо Дж., Якобсон А., Буч Г. UML: специальный справочник. Пер. с англ. СПб: "Питер", 2001.– 656 с.
Арлоу Д., Нейштадт А. UML 2 и Унифицированный процесс. Практический
объектно-ориентированный анализ и проектирование. 2-е изд./Пер. с англ.
– СПб: «Символ Плюс», 2007. – 624 с.
Литература - 2
„
„
„
„
„
„
„
Фанг Дж. И др. Введение в IBM Rational Application Developer: учебное
руководство. –М.: КУДИЦ-ПРЕСС. – 2006. –592 с.
Свитинбенк П., Чессел М., Гарднер Т. и др. Шаблоны: управляемая
моделями разработка в среде IBM Rational Software Architect. Пер. с англ.
IBM Press, 2007. –216 с.
Гамма Э., Хелм Р., Джонсон Р., Влиссидес Дж. Приемы объектноориентированного проектирования. Паттерны проектирования: Пер. с англ.
- СПб: "Питер", 2001.– 368 с.
Биберштейн Н. И др. Компас в мире сервис-ориентированной архитектуры
(SOA). –М.: КУДИЦ-ПРЕСС. – 2007. –256 с.
Боггс У., Боггс М. UML и Rational Rose: Пер. с англ. – М.: «ЛОРИ», 2000. 582 с.
Гома Х. UML. Проектирование систем реального времени, параллельных и
распределенных приложений. Пер. с англ. – М.: «ДМК Пресс», 2002. -704 с.
Кватрани Т., Палистрант Д. Визуальное моделирование с помощью IBM
Rational Software Architect и UML. Пер. с англ. –М.: КУДИЦ-ПРЕСС, 2007. –
192 с.