Transcript Unified Modeling Language - Test Page for Apache Installation

Процесс разработки
“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 описывает, что делает система, но не
указывает как.
<<stereotype>>
Actor
use case
Пример: Экзамен
Student
exam
Teacher принимает экзамен у Student.
Teacher
Включаемые use-cases



Stereotype: <<include>>
Различные use-cases могут иметь общие части
abstract use-case не активируется actor-ами
<<include>>
pass an exam
User
identify user
<<include>>
Braibench
change personal data
Генерализация actor-ов
Различные actors могут играть одну и те-же общую роль
в некотором use-case
Citizen
Student
pay taxes
Teacher
Расширение use-cases
Stereotype: <<extend>>
Некоторые use-cases могут вызываться в контексте
других только при некоторых условиях
User
login
<<extend>>
password expired
Tips



Use-case должен описывать ЧТО
делает система, но НЕ КАК
=> Глубокие иерархии use-cases чаще
всего бесполезны и ведут к
функциональной декомпозиции
=> Большое количество мелких usecase не прибавят понимания того, что
делает система
Диаграммы состояний







Описывают состояния объекта и переходы между
состояниями
State – некое состояние объекта
Event – событие, вызывающее переход
Transition – переход в новое состояние
Condition – условие перехода (true|false)
Action – мгновенное непрерываемое действие,
сопровождающее переход
Activity – деятельность, связанная с состоянием
Пример: сдача экзамена
Начало экзамена
Проверка
допуска
допуск проверен[ не
сдан зачет ]
Свободен!
допуск проверен[ зачет сдан ] / получить билет
Подготовка
entry/ достать шпаргалки
do/ списать ответы
exit/ спрятать шпаргалки
готов[ препод занят ]
вызвал преподаватель
сдача
экзамена
конец сдачи[ хорошо ответил ]
Сдал
готов сдавать[
преподаватель свободен ]
/ поднять руку
конец сдачи[ плохо ответил ] /
договориться о пересдаче
Не сдал
Пример: вложенные состояния
Применение: группировка состояний и упрощение диаграммы
Имеют не более одного начального и конечного состояний
готов
start
подготовка 2
что делать
?
ответ
доп вопросы
написание ответов
на вопросы
решение
задач
вызвал преподаватель
Пример: состояния с историей
ответ 2
получение
вопроса
H
вернулся
обдумыва
ние
ожидание
entry/ спросить подсказку
ответ
препод вышел
Н – недавнее историческое состояние
Н* - глубокое историческое состояние
Диаграммы деятельностей

Описывают последовательности действий







используются для описания операций и вариантов
использования
Activity - деятельность
Transition – переходы между деятельностями
Guard condition – условие перехода
Decision – блок принятия решения
Concurrent threads – параллельные деятельности
Synchronization bar – линейка синхронизации
параллельных деятельностей
Пример: банкомат
Классы





Class – набор объектов с общей структурой и
поведением
Interface – базовый класс, задающий только
поведение, имеет стереотип <<interface>>
Abstract class – базовый класс, не имеющий
экземпляров
Parameterized class – параметризованный класс,
шаблон
Instantiated class – депараметризованный шаблон
Примеры классов
Атрибуты классов






Attribute
– атрибут (поле)
Class attribute – атрибут класса (static)
Derived attribute – производный атрибут
Export control – доступ (public, protected, private)
Containment – способ включения (value, reference)
Syntax: <role_name>:<class_name><=default_value>
Атрибуты классов
name, birth_date – аттрибуты
age – производный аттрибут (вычисляется через birth_date)
Атрибуты классов
name, birth_date и age - аттрибуты класса
Методы(операции)





Method (operation) – метод
Class method – метод класса (static)
Export control – public, protected, private
Syntax: <stereotype> name(<parameters>) : <return type>
Parameter: parameter_name : type
Диаграмма классов
- определяет типы объектов системы и
статические связи между ними
Dependency



Отношение зависимости
Обладает ролью и множественностью
Может иметь стереотип
Association




Ассоциация - отношение взаимодействия
Обладает 2-мя ролями
Роль обладает множественностью (1, n, *, 0..n, 1..n,
1..*)
Пример: работник может занимать несколько должностей, на
одной должности находится не более одного работника
Position
+position
1..n
+person
0..1
Employee
Association

Ассоциация может иметь выделенное направление


Должность связана базовым тарифом оплаты
Тариф оплаты никак не связан с конкретной должностью
-rate
Position
BasicRate
1
Aggregation


Агрегация – отношение часть-целое
Часть принадлежит только одному целому

Сотрудник относится к одному и только одному отделу
+employee
Department
1
Employee
*
Composition


Композиция – частный случай агрегации
Жизненный цикл частей и целого совпадают

Отделы не существуют без компании
+company
+departments
Company
Department
1
0..*
Generalization

Генерализация (наследование, обобщение) –
отношение частное-общее

Отдел кадров – частный случай отдела
+employee
Department
1
HR Department
n
Employee
Realization

Реализация – отношение детализации

Треугольник и квадрат – реализации абстрактной фигуры
Диаграммы пакетов




Package – пакет. Общий механизм
организации элементов модели в группы
Имеет имя
Определяет пространство имен
Может быть импортирован другим
пакетом
package1
package2
Package
0..*
Package
Class
UML_Element
Component
Node
Diagram
Package diagram
service
<<Interface>>
<<Interface>>
Service
ResultSet
(f rom serv ice)
(f rom serv ice)
local
(from service)
server
(from service)
agent
(from service)
Package diagram
service
agent
(from service)
server
(from service)
local
(from service)
package: service
package: service::local
package: service::server
package: service::agent
стереотипы пакетов



system – вся система
subsystem – подсистема
facade – представление другого пакета



Например, пакет внешних интерфейсов
подсистемы
framework – набор шаблонов
stub – заместитель другого пакета

Созданный, например, для тестирования
Диаграммы взаимодействия


Последовательностей - Sequence diagrams
Коллабораций - Collaboration diagrams
• Отражают динамические аспекты поведения объектов
• Семантически эквивалентны
• Содержат:
• Объекты
• Связи
• Сообщения
• Потоки данных
sequence diagram
: Application
do( )
: ServiceAgent
: ServiceServer
: Service
: ResultSet
"initiate do request"
"check authorization"
do( )
"create"
addData(String)
"return results"
collaboration diagram
1: do( )
: Application
:
ServiceAgent
2: "initiate do request"
7: "return results"
: ServiceServer
3: "check authorization"
: ResultSet
:
Service
5: "create"
6: * addData(String)
4: do()
Диаграммы компонент
Показывают связи между компонентами системы
стереотипы компонент:
• executable - исполняемый компонент
• library
- библиотека
• table
- таблица базы данных
• file
- файл данных
• document - документ
component



Компонент – физическая упаковка
логической сущности
Может реализовывать несколько
классов и интерфейсов
Использует другие компоненты
component diagram
Service
ResultSet
<<library>>
localservice.dll
<<library>>
server.dll
server1
server2
<<library>>
localservice.dll
servers
Диаграмма размещения
Показывает физическое расположение исполняемых
компонент по процессорам системы и структуру сети
Элементы:
• Node – узел, процессор
• Process – процесс, поток
deployment diagram
Service 1
server1
Client
client
Service 2
server2
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 actor>>
Business use-case – бизнес-процесс,
представляющий ценность для business actor

UML: use-case со стереотипом <<business use-case>>
business use-case model
Partner
Investor
подписание контракта
ревизия работ
оценка выгодности
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 worker>>
Business-entity – пассивная сущность,
используемая в бизнесе

UML: class со стереотипом <<business entity>>
business object model
подписание контракта
(f rom Business Use-Case model)
<<realize>>
Class
Diagram:
контракт
Activity
Diagram:
use-case realization содержит набор диаграмм, описывающих КАК
реализован исходный use-case
activity diagram для use-case realization “контракт”
start
переговоры
не договорились
не выгоден
договорились
отклонение
оценка
контракта
не подписан
подписание
выгоден
подписан обеими сторонами
регистрация в
системе учета
end
class diagram для use-case realization “контракт”
Collaboration diagram для use-case “контракт”
1: подготовить предложение( )
2: рассмотреть предложение( )
: Partner
6: подписать контракт( )
7: чтение( )
: Director
4: оценить выгодность( )
3: чтение( )
8: зарегистрировать( )
5: чтение( )
: Contract
: Accountant
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 со стереотипом <<actor>>
• Use-case – вариант использования системы actor-ом
UML: use-case
Пример: use-case model
Director
ContractReviewer
заключение контракта
проверка контрактов
<<include>>
<<include>>
оценка контракта
Actors generalization
view contracts
ContractReviewer
Investor
Director
included use-cases
ContractReviewer
проверка контрактов
<<include>>
оценка контракта
семантика <<include>>
extended use-cases
регистрация контракта
<<extend>>
запрос дополнительных данных
семантика <<extend>>
use-case generalization
оценка контракта
оценка завершенного контракта
оценка планируемого контракта
семантика generalization
use-case package
• содержит набор вариантов использования, актеров,
диаграмм и других пакетов
• используется для структуризации use-case model
• UML: package со стереотипом <<use-case package>>
<<use-case package>>
contracts
use-case storyboard
-Коллаборация, описывающая реализацию use-case с
точки зрения пользовательского интерфейса
UML: use-case со стереотипом <<use-case storyboard>>
Use-case model
Analysis model
<<trace>>
Use Case
Use Case Storyboard
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 со стереотипом <<boundary>>
Примеры: классы пользовательского интерфейса, классы
интерфейсов систем и устройств
<<boundary>>
ContractViewer
ContractViewer
ContractViewer
3 представления boundary class в Rational Rose
Control
-Класс, управляющий другими классами. Можно
сказать, что control “исполняет” use-case
UML: class со стереотипом <<control>>
<<control>>
ContractsRegistry
ContractsRegistry
ContractsRegistry
3 представления control class в Rational Rose
Entity
-Класс, класс, моделирующий информацию,
используемую в системе
UML: class со стереотипом <<entity>>
<<entity>>
Contract
Contract
Contract
3 представления entity class в Rational Rose
Проверка контрактов
проверка контрактов
<<realize>>
(f rom Use-case model)
Class
Diagram:
Collaboration
Diagram:
проверка контрактов
Class diagram
entity
EstimationSystem
Contract
boundary
*
ContractViewer
Director
(f rom Use-case model)
control
ContractsRegistry
Заключение контракта
заключение контракта
(f rom Use-case model)
<<realize>>
Collaboration
Diagram:
заключение контракта
Class
Diagram:
Сlass diagram
ContractsRegistry
(f rom Analy sis)
*
Contract
ContractManagementSystem
(f rom Analy sis)
(f rom Analy sis)
EstimationSystem
(f rom Analy sis)
Collaboration diagram
: NewContractsRegistry
1: getNewContract( )
4: remove( )
3: register( )
: ContractsRegistry
: ContractManagementSystem
2: estimate( )
: EstimationSystem
Ограничения на связи
From\To
(navigability)
Boundary
Entity
Control
Boundary
yes
yes
avoid
Entity
no*
yes
no*
avoid
yes
yes
Control
*
Используйте обратные связи со стереотипом “subscribe-to”
Avoid – короткоживущая связь, нет необходимости моделировать (RUP)
Design model
 Модель реализации системы. Создается на основе
Analysis model. Фиксирует язык реализации классов.
Сопровождается до конца разработки.
 Элементы design model:
• Layer - слой (application, business, middle, system)
• Subsystem - подсистема
• Package - пакет
• Class – класс
• Use-case realization - коллаборация
Layer
- пакет, включающий другие пакеты некоторого уровня
абстракции.
UML: package со стереотипом <<layer>>
Типичные уровни:
•Application – набор специфичных для приложения подсистем
• Business
– подсистемы специфичные для данного типа бизнеса
• Middleware – подсистемы c платформно-независимыми сервисами
• System
– интерфейсы к аппаратуре, API операционной системы
и тд
Package
-набор классов, отношений, use-case realization и других
пакетов
UML: package
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
Implementation model – коллекция подсистем (subsystems)
и содержащих их компонентов (components). Компоненты
включают как поставляемые компоненты (deliverable
components, такие как программы),так и их составляющие.
Contract
Viewer
ContractViewer
ContractVie
wer
Contract
Contract