UML-технологии для проектирования …master.cmc.msu.ru/files/romanov-up-2017_04_24.pdf4. Прецеденты тестирования (Test Cases ) получаются

UML-технологии для проектирования программного обеспечения

1. Унифицированный процесс разработки программного обеспечения

Владимир Юрьевич Романов, Московский Государственный Университет им. М.В.Ломоносова

Факультет Вычислительной Математики и Кибернетики [email protected],

[email protected]

Романов Владимир Юрьевич ©2017МГУ им. М.В.Ломоносова. Факультет ВМК.

2

Предыстория унифицированного процесса

Rational Unified Process (RUP)

• RUP был создан фирмой Rational – разработчиком популярного CASE-инструмента Rational Rose и ряда других инструментов для разработки ПО

• В 2003 году фирма Rational вошла в фирму IBM как • В 2003 году фирма Rational вошла в фирму IBM как структурное подразделение

• Rational Unified Process был предложен для стандартизации в консорциум фирм Object Management Group (OMG).

Цель стандартизации – возможность поддержки унифицированного процесса разработки ПО различными инструментами на основе унифицированной метамодели процесса разработанной консорциумом OMG.


3

Стандартизация унифицированного процесса

1. Каталог стандартов консорциума Object Management Group связанных со стандартом на язык UML:

http://www.omg.org/technology/documents/modeling_spec_catalog.htm#UML

2. Метамодель процесса разработки программного обеспечения Software Process Engineering Metamodel (SPEM)

http://www.omg.org/spec/SPEM/2.0/


4

Стандарт SPEM 2.0 консорциума OMG


5

Состав стандарта SPEM 2.0


6

Реализация унифицированного процессакак подпроекта Eclipse

Eclipse Process Framework Project (EPF)

http://www.eclipse.org/epf/

Цель проекта:

способствовать созданию настраиваемого

фреймворка разработки программного обеспечения (SDE)

с примерным содержимым и инструментами процесса

поддерживающим широкий спектр проектов и стилей разработки


7

Пример – Open UP


8

Назначение унифицированного процесса

1. Предоставляет руководство по упорядочению деятельности команд разработчиков ПО

2. Управляет задачами решаемыми конкретными разработчиками ПО и командой в целом

3. Описывает какие артефакты (UML-модели, программы, документы) должны быть разработаны

4. Предоставляет критерии для оценки и измерения продуктов проекта и деятельностей проекта

5. Вся разработка ведется на основе UML-моделейразрабатываемого программного обеспечения


9

Назначение унифицированного процесса

1. Предоставляет руководство по упорядочению деятельности команд разработчиков ПО

2. Управляет задачами решаемыми конкретными разработчиками ПО и командой в целом

3. Описывает какие артефакты (UML-модели, программы, документы) должны быть разработаны

4. Предоставляет критерии для оценки и измерения продуктов проекта и деятельностей проекта

5. Вся разработка ведется на основе UML-моделейразрабатываемого программного обеспечения


10

Применимость Унифицированного процесса

Унифицированный процесс – это типовой процесс для:

• Для широкого класса проектируемых программных систем

• Для различных областей приложений• Для различных областей приложений

• Для различных типов организаций

• Для различных уровней компетентности

• Для различных размеров проектов


11

Отличительные особенностиУнифицированного процесса

1. Управляется прецедентами (use case driven)

2. Ориентирован на раннюю разработку архитектуры

3. Итеративный и инкрементальный


12

Управление прецедентами вУнифицированном процессе (1)

• Для построения программной системы необходимо знание потребностей пользователя

• Пользователь (user) – человек или другая программная система расположенные вне разрабатываемой системы

• Прецедент (use case) – взаимодействие пользователя и системы

• Все прецеденты вместе – это модель прецедентов (Use Case Model)

• Отличие UCM от функциональной спецификации –привязка функциональности к актерам


13


• Модель прецедентов (UCM) порождает серию других UML-моделей соответствующих UCM:

� Модель анализа (Analysis Model)

� Модель проектирования (Design Model)

� Модель реализации (Implementation Model)

� Модель тестирования (Testing Model)


14


• Процесс разработки следует потоку (flow)

• Процесс разработки проходит через потоки работ(workflows)

• Прецеденты влияют на создание архитектуры программной системы

• Архитектура программной системызатем влияет на выбор прецедентов использованияпри проектировании и реализации этой системы


15

Унифицированный процесс ориентирован на разработку архитектуры системы (1)

• Существует аналогия архитектуры в строительстве и разработке программного обеспечения

• Архитектура в строительстве (точки зрения на здание

� Структура� Структура

� Электрификация

� Водоснабжение

� Обогрев

� Сервис

• Архитектура в строительстве позволяет видеть всездание до начала строительства


16


Архитектура в разработке программного обеспечения

• Порождается из нужд пользователя – модели прецедентов (Use Case Model)

• Зависит также от:

� Платформы: - архитектуры компьютера; - архитектуры компьютера; - операционной системы; - СУБД; - связанности компьютеров в сети

� Переиспользуемых компонент:- framework для построения интерфейса пользователя - соглашению по внедрению системы (deployment)- нефункциональным требованиям (производительность, память, …)


17



• Это точка зрения (view) на программную систему в целом, в которой:

� Существенные свойства системы сделаны видимымивидимыми

� Несущественные свойства системы скрыты

� Архитектор обладает достаточным опытом, что бы определить что существенно, а что не существенно


18



• Архитектор создает черновик (draft) архитектурысвязанный не с прецедентами, а с платформой

• Архитектор далее работает с набором ключевых прецедентов.прецедентов.

• Каждый ключевой прецедент описывается и реализуется с использование понятий:подсистем, классов, компонент

• Разработанная архитектура затем используется для выбора и реализации оставшихся прецедентов


19



• Унифицированный процесс позволяет архитекторусконцентрироваться на правильных целях:

� Понимаемости системы

� Устойчивости системы к последующим изменениям

� Переиспользуемости компонент системы

• Архитектор находит 5-10% ключевых прецедентов


20

Унифицированный процесс итеративный и инкрементальный (1)

• Разработка ПО может продолжаться от нескольких месяцев до нескольких лет

• По этой причине разработка ПО разделяется на несколько мини-проектов

• Каждый мини-проект называется итерацией

• Итерация выбирается и выполняется по плану

• Итерация проходит через потоки работ (workflows)

• Результат итерации - инкремент


21


• Необходимость итерации

� Итерация имеет дело с группой прецедентов расширяющих используемость системы

� Итерация имеет дело с наиболее важными рисками

• Итерация проходит через более мелкие шаги -• Итерация проходит через более мелкие шаги -потоки работ:

� Поток работ анализа

� Поток работ проектирования

� Поток работ реализации

� Поток работ тестирования


22


Достоинства итерактивного процесса

• Уменьшается стоимость риска для одного инкремента. В случает неудачи теряется только одна итерация

• Уменьшается риск не поставки системы в заданные • Уменьшается риск не поставки системы в заданные сроки. Риски определяются в начале проекта

• Ускоряется разработка ПО. Разработчик имеет ясную цель на короткий период времени

• По мере реализации итераций уточняются требования к системе


23


Фазы итерактивного процесса


24

Процесс управляемый прецедентамиЧто определяют прецеденты

• Поиск и описание классов

• Поиск и описание подсистем и интерфейсов

• Поиск и описание прецедентов тестирования

• Планирование итераций разработки

• Системную интеграцию


25

Процесс управляемый прецедентами.Цели сбора требований к системе

1. Определение существенных требований.

Существенные те, которые принесут пользователю ощутимый и значимый результат.

2. Представление в форме удобной для:2. Представление в форме удобной для:- пользователей- заказчиков- разработчиков

с использование понятного для всех языка


26

Процесс управляемый прецедентами.Построение модели прецедентов

1. Выявление категорий пользователей.

2. Представление категорий с помощью актеров языка UML

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

4. Модель прецедентов – полный набор актеров и прецедентов


27

Процесс управляемый прецедентами.Построение модели анализа (1)

1. Модель анализа - описание структуры системы сиспользованием концептуальных классификаторов

2. Отдельная модель сопровождаемая для больших систем

3. Первая модель в понятиях привычных разработчикусистемы (классификаторы, пакеты, …)

4. Используется также и для сбора требований


28

Процесс управляемый прецедентами.Построение модели анализа (2)

5. Нет привязки к особенностям реализации

- к языку программирования

- к операционной системе

- системе управления базами данных

- библиотекам используемым для построения интерфейса пользователя

6. Составляет 20% от объема модели проектирования(Design Model)


29

Процесс управляемый прецедентами.Построение модели проектирования (1)

1. Для модели проектирования (design model) строится иерархия классов и интерфейсов

2. Описываются детально отношения ассоциации

3. Описываются отношения зависимости3. Описываются отношения зависимости

4. Детально с использованием классификаторов и с помощью диаграмм поведения языка UML описываются реализации прецедентов

5. Затем модель проектирования отображается в модель реализации (Implementation Model)


30

Процесс управляемый прецедентами.Построение модели проектирования (2)

4. Выполняется привязка к конкретным инструментам разработки:- языку программирования- операционной системе- системе управления базами данных- библиотекам для построения интерфейса пользователя пользователя

5. Классы группируются в подсистемы, между которыми определяются интерфейсы

6. Строится модель внедрения (deployment model) описывающая распределение системы по вычислительным узлам


31

Процесс управляемый прецедентами.Построение модели реализации

1. Разбиение системы на компоненты- файлы исходных текстов- jar-файлы- war-файлы- exe-файлы- DLL-файлы- DLL-файлы

2. Распределение компонент по вычислительным узлам и директориям файловой системы

3. Определение отношений зависимости между компонентами


32

Процесс управляемый прецедентами.Построение модели тестирования (1)

1. Модель тестирования (Testing Model)- для проверки реализации функциональности определенной в модели прецедентов- для проверки нефункциональных требований к системе

2. Модель тестирования содержит прецеденты 2. Модель тестирования содержит прецеденты тестирования (Test Cases). Из прецедентов получаются:

- входные данные- условия выполнения прецедентов- результаты


33

Процесс управляемый прецедентами.Построение модели тестирования (2)

4. Прецеденты тестирования (Test Cases) получаются сразу после получения прецедентов использования (Use Cases).

Следовательно прецеденты использования возможно планирование тестирования «черного ящика»планирование тестирования «черного ящика»

5. После получения модели проектирования возможно тестирование «белого ящика».

Каждая ветвь в реализации прецедента использования определяет отдельный прецедент тестирования белого ящика.


34






35

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

системы.


36

Построение модели прецедентов.Пример

WithdrawMoney

Deposit

Функциональные требования:

BankCustomer

DepositMoney

TransferbetweenAсcount

Нефункциональные требования к WithdrawMoney:время отклика для BankCustomer не более 30 сек в 95% случаев


37

Построение модели анализа.Пример

Для всех прецедентов текущей итерации строится

система классификаторов и отношений между ними

• Какие классификаторы необходимы для реализации прецедентовреализации прецедентов

• Какие отношения ассоциации между классификаторами необходимы для реализации прецедента


38

Построение модели анализа.Выбор классификаторов.

WithdrawMoney

Модель

прецедентов

Модель

анализа

Withdraw

<<trace>>

Money WithdrawMoney

Dispenser CashierInterface

Withdraw Account


39

Построение модели анализа.Определение отношений ассоциации

Модель анализа

Dispenser Withdraw

CashierInterface

AccountBankCustomer

MoneyReceptor

Transfer

Deposit


40

Построение модели анализа.Описание реализации прецедента

Модель анализа

: CashierInterface

1: identify 2: request withdraw

: Dispenser

: Withdraw: BankCustomer

3: authorize dispense

4: authorize dispense


41

Построение модели проектирования.Определение классов модели проектирования (1)

Модель

анализа

DispenserCashier Interface

<<trace>>Модель

Display

Keypad

CardReader


проектированияDispenser

Sensor

DispenserFeeder

CashCounter

ClientManager


42

Построение модели проектирования.Определение классов модели проектирования (2)

Модель

анализа


Withdraw Account

Withdraw


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

TransactionManagerс

Account

PersistentClass Account

Manager


43

Построение модели проектирования.Определение отношений ассоциации

Display

Keypad

Card Reader

Dispenser

ClientManager

TransactionManager

Withdraw

BankCustomer

DispenserSensor

DispenserFeeder

CashCounter

Withdraw

AccountManager

AccountPersistent

Class


44

Построение модели проектирования.Описание реализации прецедента

:BankCustomer

:Display :Keypad:Card Reader :TransactionManager

insertCard

cardInserted(ID)

:ClientManager

:CashCounter

askForPINCode

showRequest

specifyPINCodePINCode(pin)

requestPINValidation(pin)

askForAmount

showRequest

specifyAmount

amount(A)requestCashAvailable(A)

requestAmount(A)


45

Построение модели проектирования.Пример

Системы с сотнями классов не управляемы =>

1. Классы группируются в подсистемы

2. Подсистемы группируются в подсистемы

3. Подсистемы нижнего уровня – сервисные подсистемыподсистемы

4. В подсистемы группируются классы реализующие необязательную (optional) функциональность

5. В подсистемы группируются взаимосвязанныеклассы (имеют тенденцию к общему изменению)

6. Группирование на основе уже найденных классов (снизу вверх)

7. Подсистемы и их интерфейсы определяет архитектор (сверху вниз)


46

Построение модели проектирования.Определение отношений ассоциации

Display

CardReader

Client

TransactionManager

AccountManager

<<subsystem>>ATM Interface

Withdraw

<<subsystem>>TM

Transfer

<<subsystem>>AM

Display

Keypad

DispenserSensor

DispenserFeeder

CashCounter

ClientManager Withdraw

Account

Dispensing

Persistent Class


47

Построение модели реализации.Компоненты

1. Компонента– физическая и заменяемая часть системы- реализует интерфейсы

2. Для разработки исполняемой компоненты- исходные файлы- исходные файлы- таблицы баз данных- другие исполняемые компоненты (DLL или JAR)

3. Сервисные компоненты- для размещения на отдельном вычислительном узле- может быть несколько реализаций для каждого типа вычислительного узла


48

Построение модели реализациииз модели проектирования

ClientManager

Модель


<<executable>>client.exe

Модель

реализации

<<trace>>

DispenserSensor

DispenserFeeder

CashCounter

<<file>>client.c

<<file>>dispenser.c

<<trace>>

<<compilation>><<compilation>>


49

Построение модели тестирования.Прецеденты и процедуры тестирования

1. Прецедент тестирования (Test Case)- Входные данные- Условия тестирования- Предполагаемые результатыдля- конкретной реализации прецедента (черный - конкретной реализации прецедента (черный ящик)- конкретной ветви прохода через реализациюпрецедента (белый ящик)- конкретному не функциональному требованию

2. Процедура тестирования (Test Procedure) описывает как:- выполнить инициализацию системы- выполнить тест- оценить результаты тестирования


50

Построение модели тестированияиз модели прецедентов

WithdrawMoney

Модель


Модель тестирования

<<trace>>

Withdraw MoneyMoney

Withdraw MoneyBasic Flow

Withdraw MoneyWithout Cash

<<trace>>


51

Построение модели тестирования.Пример теста

1. Ввод- Клиент на счету 11-11-1111 имеет 350$- Клиент правильно идентифицировал- Клиент запросил снять 200$ со счета 11-11-1111- денег в банкомате достаточно- денег в банкомате достаточно

2. Результат- Баланс клиента уменьшился на 200$- Клиент получил 200$


52






53

Процесс ориентированный на разработку архитектуры системы.архитектуры системы.


54

Процесс ориентированный на разработку архитектуры системы (1)

Архитектура – общий взгляд на систему,

с которым согласны все разработчики системы

Архитектура – ясный взгляд на систему в целом,

дающий возможность управлять ее разработкой

Архитектура – описывает наиболее важные

элементы модели, которые

• управляют работой в каждом конкретной итерации

• управляют работой через весь жизненный цикл


55


Архитектура – содержит некоторые из:

� Подсистем

� Интерфейсов

� Вычислительных узлов

� Зависимостей

� Взаимодействий� Взаимодействий

� Активных классов

которые позволяют:

� Понять систему

� Разработать систему

� Оценить стоимость разработки системы


56


Архитектор проходит несколько итераций в фазах:

• Inception (начальная, анализа и планирования)

• Elaboration (исследование) цель фазы исследования – разработать архитектуры в виде выполняемого – разработать архитектуры в виде выполняемого фундамента (architecture baseline)

• Construction (конструирование) – на фазе конструирования есть прочный фундамент для построения полной системы

• Deployment (внедрение)


57


Архитектор – специалист по интеграции частей проекта,

но не эксперт по каждой части проекта.

Описание архитектуры используется разработчиками системы, но и них есть и более детальное описание

Архитектор дает взаимосвязанные виды, проекции (view) Архитектор дает взаимосвязанные виды, проекции (view) системы с помощью UML-диаграмм

Архитектор принимает решения о

• организации программной системы

• Структурных элементах и их интерфейсах, о взаимодействии элементов (collaborations)


58


• Композиции элементов структуры и поведения в пакеты

• Структурных элементах и их интерфейсах, о взаимодействии элементов (collaborations)взаимодействии элементов (collaborations)

• Описание архитектуры:

для каждой модели 4+1 вида


РеализационноеЛогическое

59

Модель представления архитектуры4+1

Конечный пользовательФункциональные возможности

ПрограммистыУправление прогр.обеспечением

АналитикиПоведение системы

Процедурное

представлениеПредставление

внедрения

Реализационное

представление

Логическое

представление

Прецеденты

Системный интеграторФункциональные возможностиМодульное наращивание

Производительность

СистемотехникаТопология системы Внедрение

Установка

Связи


60


• ПрецедентыКлючевые сценарии и прецеденты. Используются для задания направления поиска других представлений

• Логическое представление• Логическое представление

� Функциональные требования системы (что нужно пользователю)

� Абстракция модели проектирования- пакеты- подсистемы- классы


61


• Реализационное представлениеОрганизация статических программных кодов- тексты- данные- компоненты- исполняемые коды

в терминах

- пакетов- уровней- управления конфигурациями


62


• Процедурное представление

� Параллельность- задач- потоков- процессов- их взаимодействие- их взаимодействие

� Распределенность объектов

� Отказоустойчивость

• Представление внедренияРаспределение компонент на платформы и вычислительные узлы


63

Описание архитектуры.

• Сложность создания описания архитектуры –извлечение только самого важного без добавления в описание нового

• Первая версия описания архитектуры появляется в конце фазы Elaborationконце фазы Elaboration

• Сложно сохранить описание системы небольшим


64

Описание архитектуры.Зачем нужна архитектура

1. Для понимания системы

2. Для организации разработки системы

3. Для стимулирования повторного использования уже написанного кода и компонент системынаписанного кода и компонент системы

4. Для развития системы в дальнейшем


65

Описание архитектуры.Понимание системы

1. Сложное поведение системы

2. Работа с сложном окружении – сложно интегрировать во множество компонент разработанных сторонними разработчиками

3. Используются сложные технологии (EJB или COM)

4. Используют и индивидуальные пользователи и группы пользователей

5. Разрабатываются распределенно (географически) и поэтому необходимо координировать работу


66

Описание архитектуры.Организация разработки

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

2. Назначение групп ответственных за подсистемы дает возможность распределенности и независимостивозможность распределенности и независимости

3. Стабильные интерфейсы – позволяют независимо развивать программу по обе стороны интерфейса

4. Правильная архитектура и шаблоны проектированияпозволяют найти правильные интерфейсы между подсистемами


67

Описание архитектуры.Шаблоны архитектуры (1)

Facade – предназначен для создания упрощенного интерфейса для группы подсистем или сложной подсистемы. Область применения:

• Необходимо предоставить более простой вариант • Необходимо предоставить более простой вариант стандартного интерфейса

• Уменьшить зависимость клиента от подсистемы

• Нужно создать слои подсистемы


68


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

• Необходимо динамически менять свойства классов- незаметно для пользователя класса- не испытывая ограничения механизма наследования - не испытывая ограничения механизма наследования классов

• Свойства компонента динамически включаются и отключаются

• Есть несколько независимых функций, применяемых:- динамически- в разной комбинации


69


Layers – Способ организации модели проектирования

на уровни.

Компоненты одного уровня могут ссылаться только

на компоненты нижнего уровня

=> Упрощение:

• Компоненты нижнего уровня не зависят от:

- интерфейсов верхнего уровня

- реализации верхнего уровня


70

Описание архитектуры.Поощрение повторного использования

1. Архитектор может определить повторно используемые подсистемы тщательно проектируя их

2. Архитектор может определить повторно используемые компоненты

3. UML ускоряет создание повторно используемых подсистем и компонент

4. Должно предполагаться использование подсистем вне текущего контекста

5. Архитектор должен решать более общую задачу


71

Описание архитектуры.Развитие системы

1. Развитие стимулируется изменением окружения системы

2. Может потребоваться новая функциональность системы

3. Необходима устойчивость системы при ее изменении, а не ее деградация


72

Описание архитектуры. Развитие системы.Принципы разработки системы (1)

1. Функциональная модульность. Классы группируются в optional сервисные подсистемы SSS. SSS имеют только внутреннее сцепление (cohesion) => SSS независимы

2. Отделение проектирования интерфейсов от 2. Отделение проектирования интерфейсов от проектирования SSS

1. => несколько SSS могут поддерживать тот же интерфейс

2. => возможна замена подсистем, поскольку зависимость клиента только от интерфейса


73

Описание архитектуры. Развитие системы.Принципы разработки системы (2)

3. SSS – на этапе проектирования помещается в отдельную компоненту

=> компоненты могут быть размещены на разные вычислительные узлы

4. Необходимо уменьшение сцепления между SSS.

=> единственный способ общения между подсистемами через асинхронные сигналы

=> поощряется не только инкапсуляция,но и распределенность


74

Взаимосвязь прецедентов и архитектуры.

Прецеденты • Системное ПО• Middleware• Frameworks• Стандарты

Архитектура

Опыт

• шаблоны архитектуры• предшествующие архитектуры

• Стандарты • Нефункциональные требования

• Особенности внедрения


75

Шаги к архитектуре. (1)

• Результат фазы Elaboration – фундамент архитектуры(скелет системы)Ы

• Выбор прецедентов для построения архитектуры

� те, которые позволяют оценить наиболее серьезные � те, которые позволяют оценить наиболее серьезные риски

� Наиболее важная функциональность для пользователя

• Реализация, интеграция и тестирование фундамента архитектуры приводит к демонстрационной версиисистемы от которой идет обратная связь


76

Шаги к архитектуре. (2)

• Фундамент архитектуры – небольшая тощая система которая имеет все модели которые имеет полная система в конце фазы конструирования

• Фундамент имеет скелет для:

� Подсистем� Подсистем

� Компонент

� Вычислительных узловНо и имеет также

� Поведение

� Исполняемый код

• После стабилизации фундамента архитектуры заканчивается фаза уточнения


77

Описание архитектуры.Модель прецедентов

• В модель прецедентов включаются наиболее важные актеры и прецеденты

• В нашей модели (условно) наиболее важным будем считать прецедент WithdrawMoney

BankCustomer

WithdrawMoney


78

Описание архитектуры.Модель проектирования

• Наиболее важные подсистемы

• Интерфейсы

• Несколько особенно важных классов

• Активные классы

• Реализация наиболее важных прецедентов с помощью описанных в архитектуре классификаторов

• Распределение активных классов по вычислительным узлам


79

Модель проектирования (архитектура).Активные классы

• Все активные классы включаются в описание модели проектирования архитектуры

• Классы необходимые для понимания реализации прецедента WithdrawMoney

ClientManager

TransactionManager

AccountManager


80

Модель проектирования (архитектура).Подсистемы и их интерфейсы

• Подсистемы и интерфейсы необходимые для понимания реализации прецедента WithdrawMoney

<<subsystem>>ATM

Interface

<<subsystem>>Transaction

Manager

<<subsystem>>AccountManager

Withdraw

Dispensing

Transfer

TransferredDeposits

History


81

Модель проектирования архитектуры.Реализация прецедента WithdrawMoney

• Взаимодействие подсистем для реализации прецедента WithdrawMoney

2: Withdraw::perform(amount, account) 3: Transfer::validateAndWithdrawal(amount, account)

1: identify(amount)

<<subsystem>>ATM

Interface


Manager


4:Dispensing::athorizeDispence(amount)Bank

Customer

5: money()


82

Модель внедрения (архитектура).(Deployment Model)

ATM ATM

Applicationinternet

• Классификаторы – вычислительные узлы

BankCustomer

ATM Client

ApplicationServer

ATM Data

Server

intranet


83

Модель внедрения (архитектура).Активные объекты

• Активные объекты распределенные на экземпляры вычислительных узлов

: ATM Client :ATM Application Server :ATM Data Server

:ClientManager

:TransactionManager

AccountManager


84

Модель внедрения (архитектура).(Deployment Model)

• Определяется архитектура физической системыв терминах вычислительных узлов

• Модель внедрения может быть смоделирована на этапе сбора требований

• Для активных классов определяется:

� Что делают активные объекты (экземпляры классов)� Что делают активные объекты (экземпляры классов)

� Жизненный цикл активных объектов:кто, когда и как создает и уничтожает активные объекты

� Как активные объекты: общаются, синхронизируются, передают информацию

• Оцениваются возможности выч. узлов и их память

• Оценивается пропускная способность и доступность линий связи


85






86

Итеративность и инкрементальностьпроцесса.процесса.


87


Фазы итерактивного процесса


88

Итерактивность и инкрементальностьунифицированного процесса

• Для эффективности унифицированного процесса необходимо иметь последовательность ясно сформулированных контрольных точек (milestones)

которые дают команде критерии окончания фазыдля перехода от одной фазы к другой фазе

• Внутри каждой фазы процесс проходит через итерации и приращения (increment)


89

Фаза анализа и планирования требований

Фаза анализа и планирования требований (inception)

На этой фазе критерий – определение жизнеспособности

проекта:

1. Определение и уменьшение рисков критичных для жизнеспособности системы

2. Выделение ключевых требований –> моделирование прецедентов -> получение архитектуры-кандидата

3. Получение оценки: стоимости, сроков разработки, качества разрабатываемого продукта

4. Составление бизнес плана подтверждающего возможность выполнимость проекта


90

Фаза проектирования

Фаза проектирования (Elaboration)

На этой фазе критерий – возможность построить систему

1. Определение и снижение рисков существенно влияющих на конструирование системы

2. Определение большинства прецедентов, описывающих функциональность системыописывающих функциональность системы

3. Переход от архитектуры-кандидата к исполняемомуфундаменту архитектуры

4. Подготовка детального плана проекта позволяющего выполнить фазу построения (construction)

5. Уточнение предварительной оценки стоимости

6. Законченный бизнес план – проект выгодно делать


91

Фаза построения

Фаза построения (construction)

Критерий – способность системы начать работать в среде

Пользователя

• Достигается выполнением итераций и выпуском сборки (build) в конце каждой итерациисборки (build) в конце каждой итерации

• В конце каждой сборки работоспособная функционально законченная версия системы


92

Фаза построения

Фаза построения (construction)

Критерий – способность системы начать работать в среде

Пользователя

• Достигается выполнением итераций и выпуском сборки (build) в конце каждой итерациисборки (build) в конце каждой итерации

• В конце каждой сборки работоспособная функционально законченная версия системы


93

Фаза внедрения

Фаза внедрения (transition)

Критерий – система готова к эксплуатации

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

• Исправлением дефектов замеченных пользователем


94

Итерактивность и инкрементальность.Разработка небольшими шагами

• У команды небольшие планы

• Спецификация, проектирование и реализация также небольшие

• Сборка, тестирование и исполнение кода в каждой итерации для каждого инкремента также небольшие

При этом

• Маленький шаг реализует функциональность необходимую пользователю

• Команда получает обратную связь от пользователя

• Снижаются риски вызывающие беспокойство


95

Достоинства итеративной и инкрементальной разработки (1)

• Ранняя обработка критических и опасных рисков

• Ускорение разработки устойчивой архитектуры с помощью которой будет управляться дальнейшая разработка

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

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

• Процесс разработки строго регламентирован –

увеличивается эффективность разработки


96


• Ранняя обработка критических и опасных рисков

• Ускорение разработки устойчивой архитектуры с помощью которой будет управляться разработка

• Появляется скелет системы упрощающий сбор дополнительных требований к системедополнительных требований к системе

• Система разрабатывается постепенно, а не на последнем этапе разработки когда изменения в требованиях дороги

• Процесс разработки строго регламентирован –

увеличивается эффективность разработки


97


• Возможность раннего обучения

� После нескольких итераций каждый в команде понимает смысл различных потоков работ (workflows)

� Легче обучать новых людей. Не требуется специальных «пилотных проектов» для новичков, которые затем выбрасываютсявыбрасываются

� Ошибки новичков еще не критичны

� Упрощается обучение новым технологиям. Риск их использования на ранних итерациях невелик =>стимулируется использование этих технологий


98


• Возможность раннего обучения

� После нескольких итераций каждый в команде понимает смысл различных потоков работ (workflows)

� Легче обучать новых людей. Не требуется специальных «пилотных проектов» для новичков, которые затем выбрасываютсявыбрасываются

� Ошибки новичков еще не критичны

� Упрощается обучение новым технологиям. Риск их использования на ранних итерациях невелик =>стимулируется использование этих технологий


99

Итеративный процесс управления рисками.Риски представления системы

Риск – опасность для разработки, степень которой еще

Неизвестна

Риски:

• Идентифицируются

• Получают приоритеты

• Отслеживаются• Отслеживаются

Примеры рисков представления системы

• Скорость работы

• Память используемая системой

• Точность вычислений

• Надежность

• Доступность


100

Итеративный процесс управления рисками.Организационные (не технические) риски

• Организация не имеет людей опытных в уникальных областях необходимых для построения системы

• Предлагается новый язык реализации, но не все его знают

• Заказчик требует слишком быстрого появления системы

• Необходимо включать в разработку внешние фирмы


101

Итеративный процесс управления рисками.Работа с рисками

После идентификации рисков и задания их приоритетов

• Уход от риска, перепроектировав проект или изменив требования к системе

• Ограничить риск, что бы при этом затрагивалась по возможности меньшая часть системы или проекта

• Материализация риска, проверив оправдались ли опасения. Затем уход от риска или ограничение риска

• Риск оправдался. Если исправить невозможно, то возможен отказ о проекта с минимальными затратами времени и денег, до вовлечения в проект большого числа людей


102

Типовая итерация

• Итерация – мини-проект при полном проходе по всем потокам работ (workflows)

• Поток работ - кооперация между исполнителями (workers) производящими и использующими артефакты

• Пять основных потоков работ:• Пять основных потоков работ:

� Определение требований

� Анализ

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

� Реализация

� Тестирование


103

Отличие итеративного процесса от модели водопада (1)

• Между итерациям существует перекрытие

Треб. Анализ Проект Реализ. Тест

Итерация1

Итерация2


Итерация2


Итерация3


104

Типовая итерация

• Исполнители и артефакты могут участвовать более чем в одном потоке работ.

Например, разработчик компонент (component engineer)участвует в потоках работ по анализу, проектированию и реализации

• После завершения итерации

� Регрессионное тестирование

� Оценка изменений требований

� Оценка появления новых требований


105

Распределение сбора артефактов по различным фазам унифицированного процесса

Сдвиг важности каждого потока работ в течении

итераций и фаз процесса разработки


106

Проверка команды с помощью итеративного подхода

• Тенденция переходить к написанию кода.Строки кода – то, что менеджеры способны сосчитать

• Сопротивление изменениямИзменения замедляют написание кода

• Нет заинтересованности в многократном использовании анализа, проекта или кодаВозможно потому что работу оценивают по написанию Возможно потому что работу оценивают по написанию нового кода

Изменение

• Теперь основное:

� Уменьшение рисков

� Создание фундамента архитектуры

� Реализация функциональности

• Прогресс изменяется в рисках, прецедентах, и компонентах реализующих прецедент


107

Последствия итеративного подхода

• Для создание бизнес-плана в фазах анализа и определения требований, необходимо снижать риски и создание демонстрационной версии системы

• Для создания законченного бизнес плана в конце фазы Elaboration организация должна быть уверена фазы Elaboration организация должна быть уверена что не осталось невыясненных рисков и спланировать дальнейшие действия исходя из существующего фундамента архитектуры и требований к системе

• Для минимизации затрат организация должна использовать многократно используемые компоненты полученные в результате ранней разработки архитектуры


108

Последствия итеративного подхода

• Для избегания задержки разработки и роста цены разработки организация должна делать сначала сложные вещи

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

Разбитый на фазы Итеративный подход позволяет вносить изменения в течение всего времени разработки системы


109

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

системы.


110

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

• Основная задача потока работ по определению требований –построение модели прецедентов использования системы

• Функциональные требования структурируются на прецеденты использования

• Нефункциональные требования привязываются к конкретным прецедентам использования системы

• Общие для нескольких прецедентов нефункциональные требования выделяются в отдельный документ называемый дополнительные требования (supplementary requirements)


111

Построение модели прецедентов

• Построение модели прецедентов требует от системного аналитика привязывать функциональность системы к конкретному пользователю системы –актеру (actor)

• Требует от системного аналитика выявлять категории • Требует от системного аналитика выявлять категории пользователей системы - актеров

• Какие задачи (прецеденты использования) должна выполнить система для конкретных категорий пользователей

• Затем построенная модель прецедентов управляет всей разработкой


112

Построение модели прецедентовСхема описания потока работ

1. Описание артефакта (artifact). Артефакт – общий термин для любого вида информации (создаваемой, изменяемой, используемой) исполнителями (workers) при работе по созданию системы

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

3. Описание деятельности (activity) – часть работы за выполнение которой отвечает исполнитель в потоке работ и имеет результат в виде набора артефактов


113

Построение модели прецедентовИсполнители и артефакты (1)

Системный

аналитик

МодельПрецедентов Актер

____________________________________

Глоссарий


114


Спецификатор


Проектировщик

интерфейса пользователя

Архитектор

Прецедент

пользователя

Прототипинтерфейса


Описаниеархитектуры

____________________________________


115

Артефакты в потоке работ по построению модели прецедентов (1)

Модель прецедентов

• Позволяет разработчикам системы договориться с

заказчиками и пользователями системы о требованиях

к разрабатываемой системе

• Позволяет заключить соглашение (контракт) на • Позволяет заключить соглашение (контракт) на разработку системы

• Структурировать требования на пакеты содержащие прецеденты и диаграммы прецедентов

• Модель прецедентов - исходная модель для построения моделей анализа, проектирования, реализации, тестирования


116


Актер

• Модель прецедентов описывает действия системы

для каждой категории пользователей – актеров

• Актером может быть внешняя программная система

• Актером может быть внешнее устройство: часы, телефонная карта, …

• Актерами могут быть сотрудники или клиенты фирмы для которой разрабатывается система. И сотрудники, и клиенты могут быть взяты из бизнес модели


117

Построение модели прецедентов.Примеры артефактов - актеров

<<use case model>>Chess

Player Viewer Timer

Seller

<<use case model>>Trade System

Buyer


118


Прецедент

• Прецедент – способ использования системы.

• Описывает последовательность действий с альтернативами, которые система может выполнить взаимодействуя с актерамивзаимодействуя с актерами

• Прецедент – классификатор для описания поведения=> имеет атрибуты и операции

• Прецедент может включать :

� диаграммы переходов и состояний,

� диаграммы деятельности,

� диаграммы взаимодействия

� диаграммы последовательности взаимодействия


119

Артефакты в потоке работ по построению модели прецедентов. Прецедент (2)

Прецедент

• State Transition Diagram – описывает жизненный цикл прецедентов в терминах состояний и переходов

• Activity Diagram – более подробное описание, описывая деятельности выполняемые при переходе на описывая деятельности выполняемые при переходе на диаграмм состояний и переходов

• Collaboration Diagram и Sequence Diagram –используются для описания взаимодействия между типовым экземпляром актера и типовым экземпляром прецедента


120


Типовой жизненный цикл прецедента

• Инициализация прецедента и установка прецедента в начальное состояние

• Активизация прецедента внешним сообщением

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

• Ждет в новом состоянии прихода нового сообщения от актера

• Активизация новым сообщением и повторение цикла.


121


Особенности прецедента

• Атрибуты прецедента локальны для экземпляра прецедента (не могут быть использованы другими экземплярами прецедентов). Взаимодействие прецедента только с актерами.

• Нет конфликта между прецедентами из-за данных.

• Не требуется синхронизация с другими прецедентами

• Прецедент выполняется полностью или не выполняется совсем.

• Цель – сделать описание простым, что бы модель можно было обсуждать с пользователем и заказчиком.


122

Артефакты в потоке работ по построению модели прецедентов. Описание архитектуры

Описание архитектуры (модель прецедентов)

• Важная и критичная функциональность

• Важные требования, которые должны быть реализованы в начале жизненного цикла разработки системысистемы

• Описание архитектуры используется для задания приоритетов в реализации прецедентов.

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


123

Артефакты в потоке работ по построению модели прецедентов. Глоссарий

Глоссарий

• Определение важных или общих для всего проекта понятий

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

• Может возникать из бизнес модели


124

Артефакты в потоке работ по построению модели прецедентов. Прототип интерфейса

Прототип интерфейса пользователя

• Прототип интерфейса помогает сбору требований к системе

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

• Способствует лучшему пониманию взаимодействия актеров и прецедентов при построении модели прецедентов

• При построении прототипа интерфейса могут использоваться артефакты:модели интерфейса пользователя и скриншоты


125

Исполнители в потоке работ по построению модели прецедентов.

Исполнитель (worker) – абстракция человека с некоторыми способностями и знаниями

Это не конкретный человек (один человек – много исполнителей)

Это не должность. Должность одна – исполнителей много

Для исполнителя выполняется:

• Описание ответственности исполнителя

• Описание предполагаемого поведения исполнителя

Системный аналитик (System analyst)

Спецификатор прецедентов (Use Case Specifier)

Проектировщик интерфейса пользователя (UI Designer)


126

Исполнители в потоке работ по построению модели прецедентов. Системный аналитик

Системный аналитик

• Отвечает за все множество требований, которые

моделируются как прецеденты, включая:

� функциональные требования и

� нефункциональные требования относящиеся к прецедентупрецеденту

• Отвечает за ограничение системы

• Отвечает за поиск актеров и прецедентов

• Обеспечивает полноту и согласованность модели прецедентов

• Не отвечает за каждый конкретный прецедент (для этого есть спецификатор прецедента)


127


Системный

аналитик

МодельПрецедентов Актер

____________________________________

Глоссарий


128

Исполнители в потоке работ по построению модели прецедентов. Системный аналитик


• Отвечает за все множество требований, которые

моделируются как прецеденты, включая:

� функциональные требования и

� нефункциональные требования относящиеся к прецедентупрецеденту

• Отвечает за ограничение системы

• Отвечает за поиск актеров и прецедентов

• Обеспечивает полноту и согласованность модели прецедентов

• Не отвечает за каждый конкретный прецедент (для этого есть спецификатор прецедента)


129

Исполнители в потоке работ по построению модели прецедентов. Спецификатор прецедентов



Спецификатор прецедентов

• Отвечает за детальное описание одного и более прецедентов

• Спецификатор прецедентов должен работать с реальными пользователями

Прецедент

работать с реальными пользователями и заказчиками системы

• Детально описывает на языке UML взаимодействие актеров и прецедентов


130

Исполнители в потоке работ по построению модели прецедентов. Проектировщик интерфейса пользователя

Проектировщик интерфейса пользователя

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


Прототипинтерфейса



131

Исполнители в потоке работ по построению модели прецедентов. Архитектор


• Разрабатывает описание архитектуры в виде модели прецедентовАрхитектор


____________________________________


132

Построение модели прецедентовПоток работ (workflow)


Поиск актеров ипрецедентов

Задание приоритетов прецедентам

Реструктурирование модели прецедентов




Архитекторпрецедентам

Детализация прецедентов

Создание прототипа интерфейса пользователя


133

Обзор потока работ по построению модели прецедентов (1)

Каждая деятельность может быть пройдена несколько раз.

Каждый раз при этом будет выполнена лишь часть работы

текущей итерации.

1. Системный аналитик выполняет поиск актеров и прецедентов для подготовки новой версии модели прецедентов. На вход аналитику поступает:прецедентов. На вход аналитику поступает:

� Бизнес модель и модель предметной области (domain model)

� Список возможностей (feature-list)

� Дополнительные возможности (не функциональные)

2. Архитектор после этого задает приоритеты прецедентам, определяя прецеденты важные для создания архитектуры


134


3. Проектировщики интерфейса затем создают прототип интерфейса пользователя для каждого выявленного аналитиком актера на основе существующих прецедентов

4. Спецификаторы прецедентов выполняют детализацию 4. Спецификаторы прецедентов выполняют детализацию прецедентов в соответствии с заданными архитектором приоритетами прецедентов

5. Системный аналитик выполняет реструктурирование модели прецедентов, определяя отношения обобщения и включения между прецедентами


135


Результат первого прохода через поток работ – 1-я версия

артефактов:

• Модели прецедентов

• Прецеденты

• Прототипы пользователя

Следующие проходы через этот поток работ уточняют этиСледующие проходы через этот поток работ уточняют эти

артефакты.

Различия в проходах по потоку работ на различных фазах

• В фазах Inception и Elaboration системный аналитик находит много актеров

• В фазе Construction изменения в составе актеров и прецедентов минимальны, но уточняются диаграммы прецедентов и взаимодействие прецедентов и актеров


136

Деятельность по поиску актеров и прецедентов

Цели:

1. Отделить систему от окружения

2. Кто или что взаимодействует с системой (актеры)

3. Какая функциональность ожидается от системы

4. Определить глоссарий понятий используемых при детальном описании прецедентовдетальном описании прецедентов

Поддеятельности:

1. Поиск актеров

2. Поиск прецедентов

3. Краткое описание каждого прецедента

4. Описание модели прецедентов в целом


137













138

Деятельность по поиску актеров и прецедентов и ее артефакты

Системный аналитикBusiness model &

Domain model

Модель прецедентов


____________________________________

Глоссарий

____________________________________

Дополнительныетребования

____________________________________

Списоквозможностей


139

Поиск актеров

1. По одному актеру для каждого сотрудника (внутреннего актера) в бизнес-модели

2. По одному актеру для каждого бизнесактера (внешнего актера) в бизнес-модели

Критерии отбора:

1. Идентификация пользователей и их обобщение в 1. Идентификация пользователей и их обобщение в актеров

2. Избегать пересечения ролей у актеров.Если роли актеров пересекаются то ввести отношение обобщения у актеров

Результат поддеятельности:

1. Описание роли актера

2. Описание задач, для которых актер использует систему


140

Поиск актеров. Пример

BankCustomer

Buyer Seller


141

Поиск прецедентов

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

2. Системный аналитик предлагает для каждого актера список прецедентов-кандидатов. Каждый актер:список прецедентов-кандидатов. Каждый актер:

• Создает, изменяет, отслеживает, удаляет бизнес-объекты. Например, заказы и счета.

• Информирует системы о событиях. Например, если актер – это таймер или календарь, а событие – счет просрочен.

• Информирует об истечении интервала времени

• Актеры для:

• Запуска системы

• Остановки системы

• Техобслуживание


142

Краткое описание каждого прецедента

1. Текстовое описание назначения каждого прецедента

2. Пошаговое описание деятельностей прецедента

Пример

1. Прецедент «оплатить счет» используется

актером «покупатель» для пометки счетов к оплате.актером «покупатель» для пометки счетов к оплате.

2. Затем прецедент «оплатить счет» выполняет платеж

в назначенный день


143

Описание модели прецедентов в целом

Связь прецедентов друг с другом и с актерами.

Диаграммы прецедентов представляющих модель


• Диаграмму прецедентов на каждый бизнес-прецедент с описанием его реализации

• Прецеденты для каждого актера

• Группирование прецедентов в пакеты

• Диаграмма прецедентов пакета

• Диаграмма связей пакета


144

Пример диаграммы прецедентов.Отношения ассоциации

Заказать товар или услугу

ПокупательПродавец

Подтвердить получение заказа

Переслать покупателю счет


145

Пример диаграммы прецедентов.Отношения обобщения и расширения


Оплатить счет

<<extends>>

Перевести деньги Оплатить в кредит


146

Диаграмма прецедентов.Настольные игры


147













148

Деятельность по заданию приоритетов прецедентам

АрхитекторUse Case Model


____________________________________

Глоссарий

____________________________________


____________________________________

Описание архитектуры[Вид моделипрецедентов]


149

Деятельность по заданию приоритетов прецедентам (1)

1. На начальных фазах – определение прецедентов

необходимых для раннего построения архитектуры.

2. На поздних фазах - выбор прецедентов определяется

очередностью и важностью прецедентов. Выбирают

архитектор и менеджер проектовархитектор и менеджер проектов

3. Результат фиксируется в описании архитектуры и

используется менеджером проекта для планирования

итераций


150













151

Деятельность по заданию детализации прецедентов


прецедентовUse Case Model


____________________________________

Глоссарий

____________________________________


Прецедент

[ детализированный ]


152

Деятельность по детализации прецедентов

1. Пошагово описывается последовательность действий

2. Детализация описания прецедента

3. Формализация описания варианта использования

Спецификатор прецедентов непосредственно работает

с будущими пользователями прецедента.

Должна быть обратная связь от пользователя.


153

Деятельность по детализации прецедентов.Структурирование описание прецедента

Определяются состояния экземпляров прецедента

и переходов между ними

1. Выбирается полный основной путь от начального состояния до конечного состояния

2. Описываются альтернативные пути

• Отказы актера

• Вмешательство других актеров

• Ошибочный ввод от актеров

• Недостаток ресурсов


154

Деятельность по детализации прецедентовПример диаграммы

Переход – последовательность действий, которая выполняется

экземпляром прецедента в случае некоторого события

Состояния – например, состояния документа


155

Деятельность по детализации прецедентов.Формализованное описание прецедента

1. State transition diagram (диаграмма переходов и состояний) – для описания состояния прецедента

2. Activity diagram (диаграмма деятельности) – для детального описания переходов как последовательности действийпоследовательности действий

3. Collaboration diagram & Sequence diagram (диаграмма кооперации объектов и диаграмма последовательности взаимодействия объектов) – для описания взаимодействия экземпляра актера и экземпляра прецедента


156

Деятельность по детализации прецедентов.Пример формализованного описания

InvoicePaid

InvoiceScheduled

Browsingschedule pay

InvoiceCanceled

reject


157













158




Use Case Model

__________________


__________________

Глоссарий


Прототип интерфейса пользователя

Прецедент



159

Создание прототипа интерфейса пользователя.Создание логического экрана

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

• Элементы интерфейса пользователя – это атрибуты прецедента. прецедента.

• Актер манипулирует атрибутами прецедента.

• Часто атрибуты – это термины из глоссария.

• Атрибуты представляются пиктограммами, списками, папками, объектами на карте


160

Создание прототипа интерфейса пользователя.Создание физического экрана

• Взаимное расположение управляющих элементов

• Для навигации и структурирования – папки, окна, инструменты (tools)

• Табуляция, ускорители• Табуляция, ускорители

• Цвета, размеры


161













162



Use Case Model

__________________


__________________

Глоссарий


Прецедент


Use Case Model[ структурированная ]


1. Выделить общие и совместно используемыепрецеденты (описания функциональности которые могут быть использованы более специализированно)

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

163

Реструктурирование модели прецедентов.Разделяемые описания функциональности.

выполнить все поведение, описанное в обобщающем прецеденте

3. Экземпляр A будет включать поведение B

A B


164

Реструктурирование модели прецедентов.Разделяемые описания функциональности. Пример



Перевести деньги


1. Выделить дополнительные и условные прецеденты которые могут расширить более специфичные прецеденты

2. Отношение зависимости со стереотипом <<extends>> моделируют дополнение к последовательности действий прецедента. Отношение включает условие

165

Реструктурирование модели прецедентов.Дополнительные и условные описания функциональности

действий прецедента. Отношение включает условие расширения и точку расширения в целевом прецеденте.

3. Экземпляр A может при некоторых условиях включать поведение B

A B<<extends>>


166

Реструктурирование модели прецедентов.Дополнительные и условные описания функциональности



<<extends>>

Оплатить в кредит


167

Поток работ по анализу системы.


168

Построение модели анализа

На этом этапе анализируются требования, полученные

при построении модели прецедентов, путем их

уточнения и структурирования.

Цели:

• Получить более полное понимание требований

• Получить описание требований, которые легко • Получить описание требований, которые легко сопровождать

• Что поможет определить структуру системы в целом,включая ее архитектуру

Структура требований в построении модели анализа

основана на классах и пакетах =>

Ортогональна структуре требований на основе

модели прецедентов


169

Построение модели анализаСравнение моделей прецедентов и анализа

Use Case Model

• Язык заказчика

• Внешний вид системы

• Внешний вид структурируется с помощью прецедентов и актеров

Analysis Model

• Язык разработчика

• Внутренний вид системы

• Внутренний вид структурируется с помощью стерео-классификаторов и пакетов

• Используется как контракт заказчика и разработчика(что делать и не делать)

• Среди требований дублирование и несогласованность

• Получает функциональность системы (+архитектурно важную)

пакетов

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

• Избыточности и несогласованности нет

• Черновик для реализации архитектурно важной функциональности


170

Построение модели анализаИсполнители и артефакты

Архитектор Инженер


Инженер

компонент

Модельанализа

____________________________________

Реализацияпрецедента[ анализ ]


Пакетанализа

Классанализа


171

Артефакты в потоке работ по построению модели анализа (1)

Артефакт - Модель анализа

1. Пакеты анализа (Analysis Packages). Эти пакеты будут представлять уровни в модели проектирования (Designmodel).

2. Классы анализа (Analysis Classes). Эти классы будут представлять один и более классов в модели проектирования.

3. Реализации прецедентов (Use Case Realization). Эти реализации прецедентов будут описывать реализацию прецедентов как взаимодействие экземпляров классов анализа.


172


Артефакт - Класс анализа

Абстракция одного и более классов и/или подсистем

модели проектирования. Имеет особенности:

1. Класс анализа ориентирован на сбор функциональных требований. Не функциональные требования требований. Не функциональные требования обрабатываются на этапе построения моделей проектирования и реализации.

2. Класс анализа редко определяет и предоставляет интерфейсы в терминах операций и их сигнатур.

Вместо этого поведение определяется в терминах ответственностей (responsibility) на высоком уровне.


173


Ответственность (responsibility) - текстовое описание

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

классом анализа.

3. Класс анализа определяет атрибуты на высоком уровне. Типы атрибутов концептуальны и получаются из Типы атрибутов концептуальны и получаются из проблемной области. Это не типы языка программирования, как в модели проектирования и модели реализации. Возможно типы атрибутов станут классами в модели проектирования.

4. Класс анализа может включать отношения ассоциации и обобщения. Свойство navigability (навигация) отношения ассоциации не имеет такого значения в модели анализа, как имеет в модели проектирования


174


1. Граничный (boundary) класс – используется для

моделирования взаимодействия системы и актеров.

2. Граничные классы используются для сбора требований

к системе на границе системы =>

Изменение интерфейса пользователя изолируетсяИзменение интерфейса пользователя изолируется

1..* граничных классов.

3. Граничные классы представляют: окна, формы, терминалы

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


175


BuyerPayment

Request UI

Invoice

browsing


176


1. Класс-сущность (Entity)– используется для

моделирования долгоживущей и часто сохраняемой

информации.

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

3. Класс-сущность может быть взят из Business model или Domain model

4. Класс-сущность не обязательно пассивен

5. Класс-сущность:

� показывает логическую структуру данных

� показывает от какой информации зависит система


177


1. Управляющий класс (Control) – в нем сложная логика работы, но нет долгоживущей информации.

2. Управляющие классы не связаны с актерами

3. Управляющие классы делегирует работу в граничные 3. Управляющие классы делегирует работу в граничные классы и классы-сущности => имеют много связей с другими классами

4. Управляющие классы инкапсулируют

� Изменения логики алгоритма

� Изменения в координации классов


178


Invoicebrowsing

change

Payment Request UI

PaymentScheduler

scheduleinvoice

changestatus


179


Артефакт - Реализация прецедента [ анализ ]

– описывает реализацию прецедента в терминах классов

анализа и взаимодействия объектов анализа (экземпляров

классов)

Реализация прецедента включает:Реализация прецедента включает:

• текстовое описание потока событий

• диаграмму классов анализа, участвующих в реализации прецедента

• диаграммы взаимодействия объектов

• специальные требования

ориентированные на описание функциональных требований


180


Диаграмма классов - – включает шаблон для рассылки

сообщений:

• классы участвующие в реализации прецедента

• некоторые ответственности, атрибуты, ассоциации

Invoice

Payment Request UI

PaymentSchedulerBuyer

PaymentRequest

PaymentScheduler

Order Confirmation


181


Диаграмма взаимодействия

PaymentScheduler

Order Confirmation

4: get

5: get

Invoice

Payment Request UI

PaymentSchedulerBuyer

PaymentRequest

Scheduler Confirmation

1: browser invoice6: schedule invoice

2: browse3: check invoice

7: schedule payment

8: new5: set status


182



183


Поток событий

• Часто бывает необходим, в дополнение к диаграммам, упорядоченный текст облегчающий понимание сложных диаграмм

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

• Не должны упоминаться меняющиеся атрибуты, ассоциации, роли

Специальные требования

• Текстовое описание нефункциональных требований

• Пример:

Если покупатель хочет посмотреть счета, то они должны появиться не более чем через 0.5 сек.


184

Артефакты в потоке работ по построению модели анализа. Пакеты модели анализа

Артефакт - Пакеты модели анализа

1. Средство организации модели в управляемые фрагменты.

2. Содержит классы анализа, реализации прецедентов и другие пакеты

3. Зависимости между пакетами анализа должны быть минимизированы, а классы внутри пакета должны быть минимизированы, а классы внутри пакета должны быть связаны

4. Свойства пакетов анализа:

• Позволяют анализировать параллельно и раздельно различными разработчиками с опытом в разных предметных областях

• Должны создаваться на основе функциональных требований и предметных областях

• Пакеты станут 2-я верхними уровнями модели проектирования


185

Артефакты в потоке работ по построению модели анализа. Пакеты модели анализа

Сервисные пакеты

1. Система предоставляет заказчику множество сервисов

2. Сервис предоставляет неделимое множество функциональности (все или ничего)

3. Прецеденты для пользователей, сервисы для заказчика

4. Сервисный пакет – множество функционально 4. Сервисный пакет – множество функционально связанных классов

5. Неделим. Заказчик получает все классы или ничего.

6. Используется для реализации многих прецедентов

7. Имеет ограниченную зависимость от других сервисных пакетов

8. С одним или небольшим количеством актеров

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


186

Артефакты в потоке работ по построению модели анализа. Описание архитектуры

Артефакт – Описание архитектуры

1. Разбиение модели анализа на пакеты анализа – важная информация для создания архитектуры. Часто это подсистемы верхнего уровня в модели проектирования

2. Включает классы:2. Включает классы:

• Классы-сущности описывающие предметную область

• Граничные классы – наиболее важные пользовательские интерфейсы

• Граничные классы – реализующие общие механизмы интерфейса пользователя

• Управляющие классы – координирующие взаимодействие классов в важных прецедентах

• Классы анализа: общие, центральные, имеющие много отношений с другими классами, абстрактные классы


187

Артефакты в потоке работ по построению модели анализа. Описание архитектуры

3. Реализации прецедентов:

• Реализующие важную и критичную функциональность

• Реализацию прецедентов, используемых многими пакетами анализа (utility)пакетами анализа (utility)

• Которые включают много классов анализа

• Которые должны быть реализованы как можно раньше, поскольку их реализация используется реализациями других прецедентов


188

Построение модели анализа Классы в модели анализа для шахмат


189

Артефакты в потоке работ по построению модели анализа. Классы

Portable Game Notation (PGN) – текстовый формат для хранения информации о шахматной партии (об игроках и сделанных в партии ходах)

PGN_File - файл с множеством сохраненных партий игр

History – история ходов игры (партия)

Viewer – обозреватель. Пользователь наблюдающий за игрой и имеющий возможность просмотреть историю игры.

Player – игрок. Пользователь имеющий возможность передвигать фигуры на доске.


190

Построение модели анализа.Отношение классов History и PGN_File

Партия хранится только в одном файле

В PGN-файле хранится

неограниченное количество партий


191

Построение модели анализа.Отношение классов History и Board

На доске показывается только

одна партия Одна партия одна партия Одна партия может быть показана на

неограниченном числе досок

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

moveNumberходе


192

Построение модели анализа.Отношение класса Viewer

Обозреватель может смотреть и воздействовать (выбирая номер хода) на истории партии.

Обозреватель может смотреть на панель доски с выбранным ходом.


193

Построение модели анализа. ИсполнителиАрхитектор


1. Отвечает за правильность, согласованность и читаемость модели анализа

2. Полностью отвечает за описание архитектуры

3. Другие сотрудники отвечают

Модельанализа

____________________________________


3. Другие сотрудники отвечают за согласование с архитектурой пакетов верхнего уровня

4. Модель анализа верна, если реализует функциональность только из прецедентов

5. Архитектор не отвечает за сопровождение артефактов


194

Построение модели анализа. Исполнители.Инженер прецедентов

1. Отвечает за целостность одной и более реализаций прецедентов

2. Прецедент полностью реализует функциональность и только ее

Инженер


3. Обеспечивает читаемость всех диаграмм и текстов описывающих реализацию

4. Инженер прецедентов НЕ отвечает за классы модели анализа и их отношения. За это отвечают только инженеры компонент

Реализацияпрецедента[ анализ ]


195

Построение модели анализа. Исполнители.Инженер компонентов

1. Для одного и более классов определяет и поддерживает ответственности, атрибуты, отношения, специальные требования

2. Поддерживает целостность одного и более пакетов.

• Классы пакета и их отношения корректны.

Инженер

компонент• Классы пакета и их отношения корректны.

• Отношения с классами из других пакетов корректны и минимальны

3. Инженер компонент отвечает за пакеты и подсистемы моделей проектирования и реализации, соответствующие пакетам анализа

компонент

Пакетанализа



196

Построение модели анализаПоток работ (workflow)


Анализ архитектуры

Инженер

компонент

Инженер прецедентов

Анализ прецедента

Анализ класса Анализ пакета


197

Построение модели анализаОбзор потока работ (workflow)

1. Поток работ инициируется архитектором, определяющим:

• Главные пакеты анализа

• Очевидные классы сущности

• Общие требования

2. Инженер прецедентов реализует каждый прецедент 2. Инженер прецедентов реализует каждый прецедент используя классы анализа, задавая требования к поведению каждого класса

3. Затем эти требования к поведению классов инженер компонент интегрирует в классы, создавая:

• Согласованные ответственности класса

• Атрибуты классов

• Отношения классов

4. Ответственный за пакеты инженер компонентов согласовывает содержимое пакета и его отношения


198




Инженер

компонент





199



Дополнительные

__________________ Пакет анализа

[ черновик ]

Анализ архитектурыB-model &

D-model


Описание архитектуры[ Вид UCM ]

__________

__

Описание архитектуры[ Вид модели анализа ]

__________

__



200

Анализ архитектурыИдентификация пакетов модели анализа

1. Пакеты анализа разделяют модель на более легко управляемые части. Пакеты организуются:

• По организации работ

• Путем декомпозиции большой структуры

2. Первичная идентификация пакетов делается на основе функциональных требований и модели предметной области функциональных требований и модели предметной области (domain model)

• В отдельный пакет прецеденты реализующие конкретный бизнес процесс

• В отдельный пакет прецеденты поддерживающие конкретного актера

• В один пакет прецеденты связанные отношения наследования и расширения

Такие пакеты локализуют изменения в бизнес процессе


201

Анализ архитектурыИдентификация пакетов в модели анализа


202


3. При реализации прецедентов как диаграмм поведения с помощью классов происходит уточнение структуры пакетов

Pay InvoiceSend invoice

to buyer

Send reminder Pay Invoice

<<trace>>

Buyer Invoice Management

to buyer

<<trace>>

Seller Invoice Management

<<trace>>


203


4. Обработка общности среди пакетов анализа. Если пакеты разделяют общий класс, то этот класс должен быть вынесен в отдельный пакет или быть вне разделяющих его пакетов.

Account Bank Account

<<trace>>

Account Management


Bank Customer

<<trace>>


204


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


Send reminder

<<trace>>

AutomaticReminder

<<service>>

HandleReminder

<<service>>

<<trace>>


205


6. Определение зависимостей между пакетами. Если содержимое пакетов имеют отношения друг с другом, то между пакетами отношения зависимости. Направление отношений совпадают.Полезно показать модель анализа с уровнями зависимости

Account Management


Buyer Invoice Management


206

Анализ архитектурыИдентификация очевидных классов-сущностей

1. При сборе требований предварительно предлагается 10-20 наиболее важных классов из Business model или Domain model

2. Большинство классов определяется при реализации прецедентов

3. Классы необходимые для реализации архитектурно важных прецедентов остаются, остальные отсеиваются

4. Пример класса сущности – счет. Атрибуты класса: сумма, дата выписки, крайний срок оплаты


207

Анализ архитектурыИдентификация общих специальных требований

Специальные требования выявляются на этапе анализа.

Эти требования важны, поскольку оказываю влияние

на построение модели проектирования и реализации

• Persistency – сохранение долгоживущей информации

• Распределенность и параллельность

• Безопасность• Безопасность

• Устойчивость к сбоям

• Управление транзакциями

Пример:

• Диапазон размеров хранимых объектов

• Число хранимых объектов

• Срок хранения объектов

• Частота обновления

• Защита объектов от сбое программы или апаратуры


208

Построение модели анализа. Пакеты модели анализа верхнего уровня


209

Построение модели анализа. Общие классы для настольных игр


210

Построение модели анализа Абстрактные классы для настольных игр


211

Построение модели анализа. Базовые классы шахмат


212




Инженер

компонент





213


Инженер


Use Case Model


__________________ Реализация

прецедента[ анализ ]

Анализ прецедентаB-model &

D-model


Описание архитектуры[ Вид UCM ]

__________

__

Класс анализа[ черновик ]

[ анализ ]


214

Анализ прецедентаОбзор

1. Идентификация классов анализа, экземпляры которых (объекты) необходимы для потока событий в прецеденте

2. Распределить поведение прецедента на множество взаимодействующих объектоввзаимодействующих объектов

3. Получить специальные требования на реализацию прецедента


215

Анализ прецедентаИдентификация классов анализа

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

• Имен

• Ответственностей

• Атрибутов• Атрибутов

• Отношений

Рекомендации

• Идентификация классов-сущностей. Какая информация из Business-model и описания прецедента должна быть включена в реализацию прецедента


216

Анализ прецедентаИдентификация классов анализа

2. Определить центральный граничный класс для каждого актера-человека. Пусть этот класс представляет главное окно в интерфейсе пользователя для этого актера. Часто этот граничный класс строится из нескольких других граничных классов.

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

4. Определить граничный класс для внешней системы. Этот класс будет представлять протокол общения между системами.

5. Определить один управляющий класс для каждой

реализации прецедента


217

Анализ прецедентаОписание взаимодействия объектов анализа

После получения черновиков классов для реализации

прецедента, описываются объекты анализа.

Для этого используются диаграммы кооперации объектов.

Отдельная диаграмма строится для каждого потока.

• Прецедент активизируется сообщением посылаемым от актера к граничному классуактера к граничному классу

• Для каждого класса анализа существует объект анализа на диаграмме кооперации.

• Сообщения посылаемые объекту – это не операции. Это способность объекта к взаимодействию. Сообщение может ответственностью объекта.

• Связи на диаграммах кооперации – это экземпляры ассоциаций показанные на диаграммах классов для этой реализации прецедента


218

Анализ прецедентаОписание взаимодействия объектов анализа

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

6. Диаграмма кооперации должна содержать все 6. Диаграмма кооперации должна содержать все отношения реализуемого прецедента. Если реализуемый прецедент имеет отношения обобщения или расширения с другим прецедентом, диаграммы кооперации должны существовать и для прецедентов с которыми реализуемый прецедент вступает в такие отношения.


219

Построение модели анализа Прецеденты программы настольных игр


220

Построение модели анализа Реализация прецедента GameView


221

Построение модели анализа Реализация прецедента GameView


222




Инженер

компонент





223

Анализ класса

Инженер

компонентовРеализацияпрецедента[ анализ ]

Анализ класса

Класс анализа[ черновик ]

[ анализ ]

Класс анализа


224

Анализ классаОбзор

1. Идентификация и поддержка ответственности класса анализа на основе его роли в реализации прецедента

2. Идентификация и поддержка атрибутов и отношений в классе анализа

3. Извлечение специальных требований на класс анализа


225

Анализ классаИдентификация ответственности и атрибутов

1. Определение ответственности – собрать все роли, которые класс анализа играет в разных реализациях прецедента.

2. Атрибуты - это свойства объекта, которые предполагают или требуют ответственности классапредполагают или требуют ответственности класса

3. Типы атрибутов концептуальны и НЕ должны от реализации. В модели анализа тип Amount, в модели проектирования – тип integer

typedef in Amount

4. По возможности необходимо выбирать уже существующие типы


226

Анализ классаИдентификация атрибутов

5. Если множество атрибутов делает класс сложным для понимания, разделить его на несколько классов.

6. Добавить атрибуты к граничным классам –информацию, с которой работает актер

7. Управляющие классы имеют атрибуты представляющие накапливаемую или порожденную информацию.

8. Возможно потребуются диаграммы только для иллюстрации атрибутов класса анализа


227

Анализ классаИдентификация ассоциаций и агрегаций

1. Объекты анализа взаимодействуют через связи –экземпляры ассоциаций

2. Число ассоциаций между классами должно минимизировано. Иметь только отношения которые необходимы для реализации прецедентанеобходимы для реализации прецедента

3. Цель анализа не поиск оптимальных путей меду классами. Оптимизация в модели проектирования

4. Необходимо определить множественность, имена ролей, ассоциации-классы, порядок ролей

5. Для физического включения – композиция, при совпадении времени жизни - агрегация


228

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

1. Для выделения общего поведения – создание базового класса анализа.

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

Пример:

• От 3 до 24 КБ на объект

• Объем – до 100000

• Частота обновления – создание/обновление 100 раз в день, чтение – 1 раз в час


229




Инженер

компонент





230


Инженер

компонентПакет анализа


Анализ пакета

Описание архитектуры[ Вид A-M ]

__________

__

Пакет анализа [ завершенный ]


231


Цели анализа пакета

• Добиться по возможности независимости пакета от других пакетов

• Описать участие пакета в реализации прецедента

• Описать зависимости пакета, что бы в дальнейшем минимизировать влияние вносимых изменений


232


Рекомендации для деятельности

• Определить и сопровождать зависимости пакета

• Включать в пакет только функционально связанные классы

• Уменьшать зависимость пакетов, перемещая сильно зависимые классы в другие пакеты.


233

Анализ классаИдентификация ассоциаций и агрегаций

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

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

• Это позволит понять архитектуру системы

• Даст возможность синхронизации работы команд разработчиков

5. Детально описать и проанализировать проект с

помощью полной нотации языка UML

6. Создать бесшовную интеграцию проекта и его

реализации для использования технологии round-trip


234

Поток работ по проектированию системы.


235

Поток работ по построению модели проектирования

Цели построения модели проектирования

1. Понять ограничения накладываемые на функциональные требования

� Языками программирования

� Повторным использованием компонент

Операционными системами� Операционными системами

� Базами данных

2. Собрать исходную информацию для деятельности по реализации:

• На отдельные подсистемы


• Классы


236

Построение модели проектированияИсполнители и артефакты

АрхитекторИнженер


Модельпроектирования

____________________________________

Реализацияпрецедента

[ проектирование ]


Модельвнедрения


237

Построение модели проектированияИсполнители и артефакты

Инженер

компонент

Пакетпроектирования

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

Интерфейспроектирования


238

Артефакты в потоке работ по построению модели проектирования (1)

Артефакт: Модель проектирования

1. Модель проектирования описывает физическую реализацию прецедентов

2. Модель проектирования состоит из:

• Подсистем проектирования• Подсистем проектирования

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

• Интерфейсов

• Реализаций прецедентов описанных с использованием нотации языка UML для проектирования

3. Модель проектирования используется для создания модели реализации


239

Артефакт – Модель проектирования.Модель шахмат


240


Артефакт: Класс проектирования

Абстракция класса, максимально приближенная к

реализации класса (классу языка программирования или

аналогичной конструкции)

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

• Задается видимость для классов, интерфейсов, операций и атрибутов как это принято в языке программирования


241


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

4. Отношения ассоциации отображаются в переменные классовклассов

5. Методы (реализация операций) – отображаются в методы классов языка программирования.

6. Проектировать класс должен тот, кто его будет реализовывать


242


Артефакт: Проект реализации прецедента

Описание реализации прецедента в терминах классов

проектирования и экземпляров этих классов

Это описание включает:

• Текстовое описание потока событий• Текстовое описание потока событий

• Диаграммы классов представляющие участвующие в реализации объекты

• Диаграммы взаимодействия описывающие конкретные потоки событий в прецеденте использования с использованием объектов проектирования


243

Артефакт – Модель проектирования.Классы ядра настольных игр


244

Артефакт – Модель проектирования.Диаграмма последовательности (sequence)


245


Диаграммы классов

1. Описание реализации содержит описание классов

с атрибутами, операциями и ассоциациями относящимися

только к конкретной реализации прецедента.

2. На диаграммах показываются подсистемы которые2. На диаграммах показываются подсистемы которые

участвуют в реализации прецедента.

3. Для подсистем показываются их отношения

зависимости, реализуемые и используемые подсистемами

интерфейсы


246


<<subsystem>>ATM

Interface


Manager


Withdraw

Dispensing

Transfer

Dispensing

TransferredDeposits

History


247


Диаграммы взаимодействия

1. При проектировании предпочтение отдается диаграммам sequence, а не диаграммам collaboration. Важна временная последовательность взаимодействия

2. На диаграммах показывается реализация прецедента 2. На диаграммах показывается реализация прецедента высокого уровня как взаимодействие подсистем. Реализация прецедента внутри каждой подсистемы может быть описана позднее.

3. Имя сообщения на диаграмме высокого уровня – это операция внутреннего объекта или интерфейса реализуемого внутренним объектом


248


<<subsystem>>ATM

Interface


Manager


2: Withdraw::perform(amount, account) 3: Transfer::validateAndWithdrawal(amount, account)

1: identify(amount)

5: money()

4:Dispensing::athorizeDispence(amount)Bank

Customer


249


Поток событий в проекте реализации прецедента

1. Описывается диаграммой переходов и состояний

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

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

4. Такое описание может использоваться для связи нескольких диаграмм последовательности участвующих в реализации прецедента


250


Требования к реализации

1. Это текстовое описание, в котором собраны нефункциональные требования к реализации прецедента

2. В требования включаются те требования, которые 2. В требования включаются те требования, которые были обнаружены на стадии проектирования,

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


251


Артефакт: Подсистема проектирования

• Группирует артефакты модели проектирования

управляемые части

2. Включает:

• Классы проектирования• Классы проектирования

• Реализации прецедентов


• Подсистемы

3. Подсистемы должны быть слабо связаны. Зависимость

подсистем друг от друга или от интерфейсов должны быть

минимизированы


252


Особенности подсистем проектирования:

• Большая система проектируется раздельно и параллельно, если разделена на подсистемы

• Два верхних уровня и их подсистемы в модели проектирования появляются из модели анализапроектирования появляются из модели анализа

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

• Правильно спроектированные подсистемы допускают их повторное использование


253

Артефакт – Модель проектирования.Подсистема шахматы


254


Сервисные подсистемы:

• Располагаются на нижних уровнях

• Предназначены для локализации изменений в предоставляемых системой сервисах

• Предоставляют сервисы предоставляются через интерфейсы

• Классов проектирования больше – сервисные системы проектирования допускают дальнейшее разбиение на подсистемы

• Сервисные системы отображаются в исполняемые файлы и библиотеки


255


Артефакт: Интерфейс

1. Используются для описания предоставляемой классом проектирования или подсистемой функциональности.

2. Подсистемы, предоставляющая интерфейс, содержит класс непосредственно реализующий данный класс непосредственно реализующий данный интерфейс

3. Выполняет разделение операций и методов

• Изменение реализации интерфейса не вызывает изменения в клиенте интерфейса

• Изменение в клиенте на меняют реализацию интерфейса


256


4. Большинство интерфейсов между подсистемами архитектурно важные и должны войти в описание архитектуры

5. Важно стабилизировать интерфейсы как можно раньше. Необходимо описать интерфейсы между раньше. Необходимо описать интерфейсы между подсистемами еще до реализации этих интерфейсов

6. Интерфейс – это требование на разработку подсистем в команде разработчиков

7. Интерфейс – инструмент синхронизации работы команд разработчиков


257


Артефакт: Описание архитектуры

1. Описание архитектуры – разделение системы на интерфейсы, подсистемы и описание зависимостей между ними

2. Описание архитектуры включает:

• Классы проектирования, возникшие из архитектурно • Классы проектирования, возникшие из архитектурно важных классов модели анализа

• Активные классы, исполняемые параллельно на собственном потоку управления

• Общие классы используемые разными подсистемами

• Основные классы, имеющие большое число связей с другими классами проектирования

• Абстрактные и базовые классы

• Классы – типовые или необычные потомки абстрактных и базовых классов


258


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

4. Детальное описание классов, подсистем и интерфейсов, необходимых для реализации таких прецедентов прецедентов


259

Артефакт – Модель проектирования.Модель шахмат


260


Артефакт: Модель внедрения1. Объектная модель описывающая вычислительные узлы

системы и связь между ними

2. Распределение функциональности на вычислительных узлахузлах

3. Узел – вычислительный ресурс, связь – канал связи (интернет, интранет, внутренняя шина

4. Может описывать несколько конфигураций компьютеров

5. Служит исходной информацией для проектирования и реализации


261

Построение модели проектирования. Исполнители. Архитектор

1. Отвечает за правильность, согласованность и читаемость модели проектирования

2. Полностью отвечает за описание архитектуры

3. Другие сотрудники


3. Другие сотрудники отвечают за согласование с архитектурой пакетов верхнего уровня

4. Модель проектирования верна, если реализует функциональность только из прецедентов

5. Архитектор не отвечает за сопровождение артефактовМодель


____________________________________


Модельвнедрения


262

Построение модели проектирования. Исполнители. Инженер прецедентов

1. Отвечает за целостность одной или нескольких реализаций прецедента

2. Все тексты и диаграммы читаемы, относятся только к реализации прецедента

Инженер


3. Не отвечает за классы, пакеты и интерфейсы, а также за их зависимости




263

Построение модели проектирования. Исполнители. Инженер компонентов

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

2. Поддерживает целостность подсистема: содержимое

Инженер

компонентподсистема: содержимое корректно, зависимости подсистем корректны и минимальны

3. Реализация интерфейсов подсистемами корректна

Пакетпроектирования

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

Интерфейспроектирования


264

Построение модели проектированияПоток работ (workflow)


Проектирование архитектуры

Инженер

компонент


Проектирование прецедента

Проектирование класса

Проектирование подсистем


265

Построение модели проектированияОбзор потока работ (workflow)

1. Поток работ инициируется архитектором, определяющим:

• Черновик вычислительных узлов

• Главные подсистемы

• Интерфейсы для подсистем

• Важные и активные классы проектирования

• Типовые (generic) механизмы модели проектирования

2. Инженер прецедентов реализует каждый прецедент 2. Инженер прецедентов реализует каждый прецедент используя классы проектирования, подсистемы и интерфейсы

3. Затем эти требования к реализации прецедентов инженер компонент интегрирует в классы, создавая новые:

• Атрибуты классов

• Операции классов

4. Возможно предлагаются новые подсистемы, классы, интерфейсы


266




Инженер

компонент






267




__________________

Подсистемы [ черновик ]

Интерфейсы [ черновик ]

Проектирование архитектурыAnalysis-model


требования

Описание архитектуры[ Вид модели анализа ]

__________

__

Описание архитектуры[ Вид модели проектирования

и внедрения ]

__________

_____


Класс проектирования[ черновик ]

Deployment Model


268

Проектирование архитектурыОбзор

Выполняется идентификация артефактов

• Узлов и сетевых конфигураций

• Подсистем и их интерфейсов

• Архитектурно-важных классов проектирования. • Архитектурно-важных классов проектирования. Например активных классов

• Типовых механизмов проектирования. Например, сохранение информации (persistency),внедрения


269

Проектирование архитектурыИдентификация узлов и сетевых конфигураций

Идентификация узлов и сетевых конфигураций

1. Физическая конфигурация сети порождает активные классы и их распределение по вычислительным узлам

2. Решаемые деятельностью задачи:

• Включаемые в сеть узлы, их производительность и • Включаемые в сеть узлы, их производительность и память

• Соединения узлов и протокол общения по этим соединения

• Скорость, доступность соединения

• Механизмы:

• Для восстановления системы при сбоях аппаратуры

• Миграция процессов в сети

• Создание резервных копий данных


BuyerServer

270

Проектирование архитектурыПример идентификации узлов и сетевых конфигураций

internet

SellerServer

intranet

BuyerClient

internet

*Server Server

SellerClient

Bank Server

Client

internet internet

*


271

Проектирование архитектурыИдентификация подсистем и их интерфейсов

Идентификация подсистем и их интерфейсов

1. Идентификация прикладных подсистем:

• Идентификация специфических прикладных систем

• Идентификация общих прикладных систем

Управление счетами

покупателя

Управление планированием

платежей

Управлениебанковскими

счетами


272

Проектирование архитектурыИдентификация подсистем и их интерфейсов

Идентификация подсистем и их интерфейсов2. Идентификация подсистем среднего уровня (middleware):

• Необходима минимизация зависимости от подсистем среднего уровня =>

• взаимодействие с ними только через интерфейсы => уменьшения рисков от их использованияуменьшения рисков от их использования

Java.Swing Java.RMI

TCP/IP

JVMBrowser


273

Проектирование архитектурыОпределение зависимостей между подсистемами




платежей


счетами

Java.AppletJava.RMI

JVM


274

Проектирование архитектурыИдентификация интерфейсов

4. Идентификация интерфейсов



Прием счетов



платежей


счетами

Запрос на оплату

Перечисления


275

Проектирование архитектурыИдентификация интерфейсов шахмат

Идентификация пакетов верхнего уровня


276


Идентификация интерфейсов используемых пакетами.

Интерфейсы шахмат.


277

Проектирование архитектурыИдентификация архитектурно важных классов

Идентификация архитектурно важных классов1. Архитектурно важные классы проектирования из

архитектурно важных классов анализа

2. Идентификация активных классов

• Для обеспечения требований по скорости и доступности для актеров могут создаваться активные классыдля актеров могут создаваться активные классы

• Для вычислительного узла не менее одного активного класса

• Активные классы:

� Запуск системы

� Останов системы

� Снятие зависание

� Восстановление системы после сбоев

� Снятие блокировок

� Загрузка соединений

� Реконфигурация узлов


278

Проектирование архитектурыИдентификация типовых механизмов проектирования

Идентификация типовых механизмов проектированияВозможно проектирование типовых механизмов:

• Длительного хранения (persistency)

• Распределения объектов по вычислительным узлам

• Обеспечения секретности

• Контроля и исправления ошибок

• Управления транзакциями

Для реализации типовых механизмов могут

использоваться абстрактные классы, интерфейсы и

родовые (generic) типы языков программирования


279

Проектирование архитектурыИдентификация типовых механизмов

Trade ObjectCreation UI

Sender

Sender Processing

Receiver Processing

Trade ObjectPresentation UI

Receiver

Trade Object

Invoice UI

Buyer

InvoiceProcessing

PaymentRequest

Processing

InvoicePresentation UI

Seller

Invoice


280




Инженер

компонент






281


Инженер


Use Case Model

____________



Проектирование прецедентов

Analysis-model &Design-model &

Deployment-model


требования

______ [ черновик ]





282

Проектирование прецедентовОбзор

Цели проектирования прецедента

1. Определение классов и подсистем проектирования, экземпляры которых необходимы для проектирования прецедента

2. Описание реализации прецедента на диаграмме 2. Описание реализации прецедента на диаграмме взаимодействия объектов и подсистем

3. Определение требований на операции в классах проектирования, подсистемах и их интерфейсах

4. Определение требований к реализации прецедентов


283

Проектирование прецедентовОпределение участвующих классов и подсистем

Определение участвующих классов и подсистем

1. Выбор или порождение классов проектирования из реализации прецедентов с помощью классов анализа. Выбор из классов определенных архитектором

2. Выбор классов определенных для реализации 2. Выбор классов определенных для реализации специальных требований

3. Инженер назначает ответственности для этих классов (что классы делают)

4. Если необходимый класс отсутствует, назначается ответственный за этот класс инженер компонент


284








285

Проектирование прецедентовОписание реализации прецедента

Описание реализации прецедента

1. На диаграмме последовательности взаимодействия объектов показывается:

• Порождение прецедента вызовом из актера

• Для каждого класса проектирования создается объект• Для каждого класса проектирования создается объект

• Пересылка сообщений между линиями жизни объектов.Названия сообщений даются временные. Постоянные задаст инженер компонентов при определении операций классов

• Основная цель инженера прецедентов – точное описание последовательности рассылки сообщений

• Диаграмма последовательности взаимодействия может быть дополнена диаграммой переходов и состояний


286








287

Проектирование прецедентовИдентификация подсистем и интерфейсов

Идентификация подсистем и интерфейсов

1. При проектировании системы сверху вниз может быть необходимо определить требования к подсистемам и их интерфейсам до проектирования взаимодействия объектов внутри подсистемы.Это может позволить заменить реализацию Это может позволить заменить реализацию интерфейсов одной подсистемой реализацией другой подсистемы

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


288

Проектирование реализации прецедента


289

Проектирование реализации прецедента

Buyer UI Payment RequestManagement

InvoiceManagement

Payment InvoiceManagement Management

Payment SchedulingManagement

Payment Request


290

Проектиырование реализации прецедентаРеализация прецедента DoMove


291

Проектирование реализации прецедентаСделать ход игрока


292

Проектирование реализации прецедентаПоказать ход обозревателю.


293




Инженер

компонент






294


Инженер

компонентов


Класс анализа [ черновик ]

Проектирование классов







295

Проектирование прецедентовОбзор

Цели проектирования класса – определение

следующих характеристик класса

1. Операции класса

2. Атрибуты класса

3. Отношения класса3. Отношения класса

4. Методы класса

5. Состояния класса

6. Зависимости от типовых механизмов проектирования

7. Требования к реализации класса

8. Правильная реализация интерфейсов класса


296

Проектирование прецедентовПроектирование классов

Проектирование классов на основе класса анализа

1. Использование граничного класса анализа. Для построения классов проектирования на основе граничного класса может быть использован прототип интерфейса пользователя.

2. Использование класса – сущности. Могут появиться классы соответствующие таблицами и видам баз данных.

3. Использование управляющих классов.

• Если логика работы требует несколько вычислительных узлов, то необходимо несколько классов проектирования.

• Может потребоваться класс проектирования, реализующий логику транзакции


297

Проектирование прецедентовИдентификация операций

Идентификация операций

1. Используется синтаксис языка программирования

2. Задаются видимости операций

3. Одна ответственность класса анализа – несколько 3. Одна ответственность класса анализа – несколько операций класса проектирования

4. Специальные требования могут привести к использованию в реализации типовых механизмов проектирования

5. Реализация классом методов определенных в интерфейсах


298

Проектирование прецедентовИдентификация атрибутов

Идентификация атрибутов

1. Использование атрибутов определенных в классах анализа => один или несколько атрибутов проектирования

2. Типы атрибутов выбираются из доступных типов модели проектирования. Возможно типы атрибутов анализа станут классом проектированияклассом проектирования

3. Общие атрибуты нескольких классов выносятся в базовый класс

4. Если атрибутов слишком много – класс разделяется на несколько классов

5. Диаграмма классов для иллюстрации атрибутов


299

Проектирование прецедентовИдентификация ассоциаций и агрегаций

Идентификация ассоциаций и агрегаций

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

2. Число отношений между классами должно быть сведено к минимуму

3. Отношения ассоциации и агрегации между классами анализа => появляются отношения ассоциации и агрегации в порожденных классах проектирования

4. Направления посылки сообщений задают направление навигации на отношении ассоциации.


300

Проектирование классов

Идентификация отношений обобщения

• Если язык программирования не поддерживает множественное наследование, то такое наследование представляется с помощью реализуемых классом интерфейсов.

Идентификация методов• Частично реализация метода может быть получена из

рассылки сообщений на диаграммы последовательности взаимодействия

• Реализация пишется на языке программирования инженером компонент, а модель попадает в результате обратного проектирования


301

Проектирование классовИдентификация состояний

Идентификация состояний

Помеченк оплате

Созданschedule

Просрочен

Closed()

[время после срока оплаты]

Закрыт

Closed()


302

Проектирование классовКлассы-фигуры в шахматной программе


303


• Фигуры: King – король, Queen –ферзь, Bishop – слон, Knight - конь, Root – ладья, Pawn – пешка

• Фигуры реализуют интерфейс Piece – общие свойства всех настольных игр. Это проверка корректности хода фигурой isCorrect() и выполнение хода фигурой makeMove() с возвратом экземпляра хода для сохранения истории игрывозвратом экземпляра хода для сохранения истории игры

• ChessPiece – реализует общие свойства фигур (нельзя ходить с пустого поля, нельзя бить свою фигуру, …)

• DiagonalPiece – реализует общий алгоритм проверки связанности диагональных фигур (Bishop и Queen)

• LinePiece – реализует общий алгоритм проверки связанности прямолинейных фигур (Root и Queen)


304

Проектирование классовКлассы-ходы в шахматной программе


305


• Ходы: SimpleMove – простой ход, Castling – рокировка, Capture – взятие, Promotion – превращение пешки,EnPassant – взятие пешкой «на проходе»

• SimpleMove – перемещение фигуры на пустую клетку.

• Фигуры реализуют интерфейс Move – общие свойства ходов всех настольных игр. Это выполнение хода doMove() и его отмена undoMove()

• ICapture – реализует удаление фигуры с доски и ее восстановление на доске. Действительно ли было взятие (в случае Promotion) проверяется с помощью метода isCapture().


306




Инженер

компонент






307


Инженер

компонентов

____________

Подсистема [ законченная ]



Описание архитектуры

______

Интерфейс

[ законченный ]Интерфейс



308

Проектирование подсистемСопровождение зависимостей подсистем

• Должны быть идентифицированы и сопровождаться зависимости подсистемы от других подсистем.

• Если другие зависимости предоставляют интерфейсы, то должны быть зависимости в направлении интерфейсовинтерфейсов

• По возможность необходимо спроектировать систему так, что бы зависимость была только от интерфейсов

• Зависимости должны быть минимизированы перемещением классов между подсистемами


309

Проектирование подсистемСопровождение интерфейсов подсистем

• Операции, определенные интерфейсами подсистемы, должны поддерживать все роли которые подсистема играла в реализации прецедента

• Интерфейсы определенные архитектором, уточняются инженером компонентинженером компонент

• Интерфейсы и подсистемы используются в разных реализациях =>Инженер прецедентов определяет новые требования к интерфейсам


310

Проектирование подсистемСопровождение содержимого подсистем

• Для каждого интерфейса подсистемы внутри подсистемы или во вложенной подсистеме должен быть класс реализующий этот интерфейс.

• Для прояснения внутренней реализации интерфейса для каждого интерфейса создаются диаграммы для каждого интерфейса создаются диаграммы кооперации проясняющие реализацию в терминах классов и пакетов содержащихся в подсистеме


311

Влияние рисков на план итерации

1. На начальной фазе определяются наиболее опасные риски.

2. Для них разрабатывается небольшой набор прецедентов и включить его в прототип системы. На работе прототипа проверить оправданы ли опасения.


312

Литература и ссылки

1. Джим Арлоу, Айла Нейштадт, UML 2 и Унифицированный процесс. Практический объектно-ориентированный анализ и проектирование

Москва. 2007. Символ-Плюс, ISBN 978-5-93286-094-6

2. Гари Поллис, Лиз Огастин, Крис Лоу, Джас Мадхар. Разработка 2. Гари Поллис, Лиз Огастин, Крис Лоу, Джас Мадхар. Разработка программных проектов. На основе Rational Unified Process (RUP)Москва. 2011. Бином-Пресс ISBN 978-5-9518-0449-5.

3. Object Management Group, Software Process Engineering Metamodel OMG document, http://www.omg.org/spec/SPEM/2.0/PDF

4. Open Unified Process, http://epf.eclipse.org/wikis/openup/index.htm


313

Приложение А. CASE-инструмент Papyrus


314

Инсталляция Papyrus.Загрузка

1. http://www.eclipse.org/papyrus/download.html


315

Инсталляция Papyrus.Запуск


316

Инсталляция Papyrus.Установка дополнительных компонент

Установка дополнительных дополнительных

компонент


317

Создание нового проекта в Papyrus.


318

Создание нового проекта в Papyrus.Выбор графической нотации


319

Создание нового проекта в Papyrus.Имя проекта и модели


320

Создание нового проекта в Papyrus.Выбор диаграммы классов как первой диаграммы


321

Создание нового проекта в Papyrus.Проект UP2017-practicum-sample


322

Задание профиля модели проекта в Papyrus.

Задание профиля для модели


323

Задание профиля модели проекта в Papyrus.Моделируем программу для языка Java


324

Задание профиля модели проекта в Papyrus.Моделируем программу для языка Java


325



326

Импорт примитивных типов языка Java


327



328



329



330

Создание в модели пакета game


331

Создание в пакета game.core классовPiece, Square и Board


332

Создание в модели отношения ассоциациимежду классам Board и Square


333

Отношение ассоциации между классам Board и Square

На доске может быть1 и более клеток

Клетка должна принадлежать

только одной доске


334

Отношение ассоциации между классам Piece и Square

На клетке может быть не более 1 фигуры

Фигура может быть расположена на

клетке


335

Отношение наследования между классам Piece и ChessPiece

Абстрактный класс ChessPieceнаследник

абстрактного класса Piece


336


Идентификация пакетов верхнего уровня


337


Идентификация интерфейсов используемых пакетами.

Интерфейсы шахмат.


338



339


Documents

UML-технологии для проектирования …master.cmc.msu.ru/files/romanov-up-2017_04_24.pdf4. Прецеденты тестирования (Test Cases ) получаются