Процесс разработки “Design and programming are human activities. Forget it and all is lost.” B.Stroustrup, 1991

Фазы процесса Начало Уточнение Разработка Развитие

Методы OMT (Object Modeling Technique, Rumbaugh) RDD (Responsibility Driven Design) Objectory RUP (Booch, Rumbaugh, Jacobson) Способ моделирования Артефакты фаз процесса

CRC - карточки Class Student Ответственность Учиться Сдать экзамены Коллаборанты Teacher

UML Unified Modeling Language CASE - средства: Rational Rose Together ArgoUML

UML Язык моделирования Не является языком программирования Определяет нотацию Имеет метамодель, выраженную на нем самом

История 1988 – 1995 работы Mellor, Booch, Rambough, Jacobson, Koad, Jordan, Shlaer… 1995 – UML 0.8 (Grady Booch, Jim Rambough) 1997 – UML 1.0 (Grady Booch, Jim Rambough, Ivar Jacobson) Rational Software

Нотация Сущности Структурные Поведенческие Группирующие аннотационные Отношения Зависимость Ассоциация Обобщение Реализация

Нотация Диаграммы Вариантов использования Состояний Деятельностей Классов Объектов Последовательностей и кооперации Компонентов Размещения

Варианты использования Actor – внешнее по отношению к системе действующее лицо, некто или нечто взаимодействующее с системой, роль. Use case – некая последовательность действий системы, представляющая ценность для Actor-а, вариант использования системы (Ivar Jacobson). Use-case описывает, что делает система, но не указывает как.

Пример: Экзамен Teacher принимает экзамен у Student.

Включаемые use-cases Stereotype: > Различные use-cases могут иметь общие части abstract use-case не активируется actor-ами

Генерализация actor-ов Различные actors могут играть одну и те-же общую роль в некотором use-case

Расширение use-cases Stereotype: > Некоторые use-cases могут вызываться в контексте других только при некоторых условиях

Tips Use-case должен описывать ЧТО делает система, но НЕ КАК => Глубокие иерархии use-cases чаще всего бесполезны и ведут к функциональной декомпозиции => Большое количество мелких use- case не прибавят понимания того, что делает система

Диаграммы состояний Описывают состояния объекта и переходы между состояниями State – некое состояние объекта Event – событие, вызывающее переход Transition – переход в новое состояние Condition – условие перехода (true|false) Action – мгновенное непрерываемое действие, сопровождающее переход Activity – деятельность, связанная с состоянием

Пример: сдача экзамена

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

Пример: состояния с историей Н – недавнее историческое состояние Н* - глубокое историческое состояние

Диаграммы деятельностей Описывают последовательности действий используются для описания операций и вариантов использования Activity - деятельность Transition – переходы между деятельностями Guard condition – условие перехода Decision – блок принятия решения Concurrent threads – параллельные деятельности Synchronization bar – линейка синхронизации параллельных деятельностей

Пример: банкомат

Классы Class – набор объектов с общей структурой и поведением Interface – базовый класс, задающий только поведение, имеет стереотип > Abstract class – базовый класс, не имеющий экземпляров Parameterized class – параметризованный класс, шаблон Instantiated class – депараметризованный шаблон

Примеры классов

Атрибуты классов Attribute – атрибут (поле) Class attribute – атрибут класса (static) Derived attribute – производный атрибут Export control – доступ (public, protected, private) Containment – способ включения (value, reference) Syntax: :

Атрибуты классов name, birth_date – аттрибуты age – производный аттрибут (вычисляется через birth_date)

Атрибуты классов name, birth_date и age - аттрибуты класса

Методы(операции) Method (operation) – метод Class method – метод класса (static) Export control – public, protected, private Syntax: name( ) : Parameter: parameter_name : type

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

Dependency Отношение зависимости Обладает ролью и множественностью Может иметь стереотип

Association Ассоциация - отношение взаимодействия Обладает 2-мя ролями Роль обладает множественностью (1, n, *, 0..n, 1..n, 1..*) Пример: работник может занимать несколько должностей, на одной должности находится не более одного работника

Association Ассоциация может иметь выделенное направление Должность связана базовым тарифом оплаты Тариф оплаты никак не связан с конкретной должностью

Aggregation Агрегация – отношение часть-целое Часть принадлежит только одному целому Сотрудник относится к одному и только одному отделу

Composition Композиция – частный случай агрегации Жизненный цикл частей и целого совпадают Отделы не существуют без компании

Generalization Генерализация (наследование, обобщение) – отношение частное-общее Отдел кадров – частный случай отдела

Realization Реализация – отношение детализации Треугольник и квадрат – реализации абстрактной фигуры

Диаграммы пакетов Package – пакет. Общий механизм организации элементов модели в группы Имеет имя Определяет пространство имен Может быть импортирован другим пакетом

Package

Package diagram

package: service

package: service::local

package: service::server

package: service::agent

стереотипы пакетов system – вся система subsystem – подсистема facade – представление другого пакета Например, пакет внешних интерфейсов подсистемы framework – набор шаблонов stub – заместитель другого пакета Созданный, например, для тестирования

Диаграммы взаимодействия Последовательностей - Sequence diagrams Коллабораций - Collaboration diagrams Отражают динамические аспекты поведения объектов Семантически эквивалентны Содержат: Объекты Связи Сообщения Потоки данных

sequence diagram

collaboration diagram

Диаграммы компонент Показывают связи между компонентами системы стереотипы компонент: executable - исполняемый компонент library - библиотека table - таблица базы данных file - файл данных document - документ

component Компонент – физическая упаковка логической сущности Может реализовывать несколько классов и интерфейсов Использует другие компоненты

component diagram

servers

Диаграмма размещения Показывает физическое расположение исполняемых компонент по процессорам системы и структуру сети Элементы: Node – узел, процессор Process – процесс, поток

deployment diagram

Rational Unified Process

RUP: Business modeling Задачи: Идентификация бизнес-процессов (use-cases) Идентификация бизнес-акторов и сущностей(entity) Улучшение (refine) бизнес-процессов Модели: business use-case model business object model

business use-case model Модель, описывающая бизнес процессы в терминах business-actors и business use-cases Business actor – некто или нечто вовне бизнеса, взаимодействующее с ним UML: класс со стереотипом > Business use-case – бизнес-процесс, представляющий ценность для business actor UML: use-case со стереотипом >

business use-case model

business object model Модель, описывающая реализацию business use-cases в терминах взаимодействующих business workers и entities Business use-case realization – коллаборация, описывающая при помощи activity, sequence, class и interaction диаграмм, как данный business use-case реализован в business-object model. UML: use-case со стереотипом “business use-case realization”

business objects Business-worker – исполнитель бизнес- процесса UML: class со стереотипом > Business-entity – пассивная сущность, используемая в бизнесе UML: class со стереотипом >

business object model use-case realization содержит набор диаграмм, описывающих КАК реализован исходный use-case

activity diagram для use-case realization “контракт”

class diagram для use-case realization “контракт”

Collaboration diagram для use-case “контракт”

RUP: Анализ требований Задачи: сбор и анализ требований к системе классификация use-cases оценки затрат и рисков Модели: Use-case model

Vision  Vision – представляет собой общее описание проекта и является базисом для уточнения требований к системе  Содержит: Цели проекта Stakeholders & Users (описание инициаторов проекта и конечных пользователей ) Перспективы и возможности продукта Особенности Ограничения

Use-case model  Use-case model – модель, описывающая требования к системе в терминах вариантов использования (use-case). Создается на основе Vision и Business Analysis.  Элементы use-case model: Actor – внешнее по отношению к системе действующее лицо, роль. UML: Class со стереотипом > Use-case – вариант использования системы actor-ом UML: use-case

Пример: use-case model

Actors generalization

included use-cases

семантика >

extended use-cases

семантика >

use-case generalization

семантика generalization

use-case package содержит набор вариантов использования, актеров, диаграмм и других пакетов используется для структуризации use-case model UML: package со стереотипом >

use-case storyboard -Коллаборация, описывающая реализацию use-case с точки зрения пользовательского интерфейса UML: use-case со стереотипом >

SRS SRS (Software Requirements Specification) - полностью определяет требования к системе, зависит от Vision Содержит: Функциональные требования (что должна делать система, роли пользователей, фактически, описание use-cases) Нефункциональные требования (производительность, ограничения по используемым технологиям и т.д.)

RUP: Analysis & Design Задачи: Трансформировать требования собранные на предыдущем этапе в дизайн системы Проработать архитектуру системы Адаптировать дизайн к среде исполнения Модели: Analysis model Design model

Analysis model  Абстрактная модель системы, описывающая ее в терминах use-case realization. Язык реализации классов не фиксируется. Обычно не сопровождается.  Элементы analysis model: Use-case realization – реализация use-case, набор activity, state, collaboration и class диаграмм Boundary class – класс, разграничивающий actor-ов и систему Control – класс, управляющий другими классами Entity – класс, моделирующий информацию, используемую в системе

Boundary class -Класс, разграничивающий (под-)систему и окружение. UML: class со стереотипом > Примеры: классы пользовательского интерфейса, классы интерфейсов систем и устройств 3 представления boundary class в Rational Rose

Control -Класс, управляющий другими классами. Можно сказать, что control “исполняет” use-case UML: class со стереотипом > 3 представления control class в Rational Rose

Entity -Класс, класс, моделирующий информацию, используемую в системе UML: class со стереотипом > 3 представления entity class в Rational Rose

Проверка контрактов

Class diagram

Заключение контракта

Сlass diagram

Collaboration diagram

Ограничения на связи From\To (navigability) BoundaryEntityControl Boundaryyes avoid Entityno*yesno* Controlavoidyes * Используйте обратные связи со стереотипом “subscribe-to” Avoid – короткоживущая связь, нет необходимости моделировать (RUP)

Design model  М одель реализации системы. Создается на основе Analysis model. Фиксирует язык реализации классов. Сопровождается до конца разработки.  Элементы design model: Layer - слой (application, business, middle, system) Subsystem - подсистема Package - пакет Class – класс Use-case realization - коллаборация

Layer - пакет, включающий другие пакеты некоторого уровня абстракции. UML: package со стереотипом > Типичные уровни: Application – набор специфичных для приложения подсистем Business – подсистемы специфичные для данного типа бизнеса Middleware – подсистемы c платформно-независимыми сервисами System – интерфейсы к аппаратуре, API операционной системы и тд

Package -набор классов, отношений, use-case realization и других пакетов UML: package

SAD  SAD (Software Architecture Document) – содержит полное описание архитектуры системы  Содержит: Use-case view Logical View (архитектурно важные части Design model) Process View Deployment View Implementation View Performance issues Quality issues

RUP: Implementation Задачи: Структурирование системы Реализация компонент системы Артефакты: Implementation model

Implementation model – коллекция подсистем (subsystems) и содержащих их компонентов (components). Компоненты включают как поставляемые компоненты (deliverable components, такие как программы),так и их составляющие.