Презентация на тему Уточнение ИС (развитие, проектирование - Elaboration) в RUP

архитектора в фазе «Уточнение (проектирование)»
Технология проектирования Моделирование реализации вариантов

(прецедентов) использования в RSA:
Диаграммы взаимодействий (interaction):
Последовательностей (sequence)
Коммуникаций (communication)
Диаграммы классов (class)
Диаграммы активностей (activity)
Диаграммы жизненного цикла объектов (life cycle)

Проектирование)
Цель – выбор и создание основы архитектуры системы, которая

должна стать фундаментом для разработки всей системы в следующей фазе
Программная архитектура – это набор существенных решений, касающихся организации программной системы:
Выбор структурных элементов и их интерфейсов (классов)
Поведение, определяемое взаимодействием этих элементов (методов)
Объединение этих структурных и функциональных элементов в более крупные подсистемы (компоненты)
Архитектурный стиль организации (принципы, методы, инструментальные средства, интерфейсы в соответствии с ИТ-стратегией – относится к встраиванию разрабатываемых компонентов в существующую систему)
Архитектура определяется, исходя из самых существенных требований (вариантов использования) и оценки рисков:
Риски, связанные с требованиями (те ли приложения?)
Риски, связанные с архитектурой (те ли решения?)
Риски, связанные со стоимостью и сроками (ресурсами)
Риски, связанные с процессом и инструментальной средой (технологии разработки)
Архитектурно значимые решения оказывают длительный эффект на производительность, качество и масштабируемость системы

и проверить базовую архитектуру
Снизить существенные риски и дать более

точную оценку сроков и стоимости
Уточнить прецедент разработки и установить среду разработки
Рецензирование проекта. Веха архитектуры жизненного цикла

использования ( оставшиеся 80 % use-case)
Создание прототипа пользовательского интерфейса

для главных прецедентов использования
Выделение дополнительных прецедентов использования
Обновление глоссария (тезауруса системы)

важных строительных блоков (компонентов) системы (подсистем, пакетов, прецедентов использования)

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

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

к исходному коду для внесения изменений
Документирование компонентов: описание проектных решений, способы использования и тестирования

оценку сроков и стоимости
Менеджер проекта проводит обновление Экономического обоснования

и Плана разработки проекта, добавляя дополнительные планы, списки рисков, ключевые управленческие артефакты
Менеджер проекта проводит совещание с ключевыми заинтересованными лицами с целью рассмотрения экономического обоснования, списка рисков, концепции и плана разработки системы

изменений в прецедент разработки: какие артефакты нужно дополнительно создать,

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

Концепция и требования проекта устойчивыми?
Является ли архитектура устойчивой?
Проверены ли

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

направляет и координирует решение технических задач и разработку артефактов

(программ, баз данных, документации и т.д.), а также координирует принятие ряда ключевых решений, касающихся технологий, структуры и организации программной системы (ИС)
Архитектор должен быть широко образован, обладать зрелостью, видением и глубоким опытом, который позволяет быстро решать проблемы и выносить грамотные суждения при отсутствии полной информации

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

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

архитектурной целостности

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

менеджером проекта) – на основе анализа рисков, архитектурной важности, наличия ресурсов)
Архитектурный анализ – построение логической структуры моделей и классов, устраняя избыточность
Конструирование архитектурного прототипа «подтверждения концепции» в целях уяснения границ системы, проверки её осуществимости и оценки реальности риска и эффективности решения

программной инфраструктуры (промежуточного ПО: СУБД, программных сред,…), выбор конкретных

механизмов реализации
Определение элементов проектной модели – выбор ключевых элементов проектной модели
Объединение имеющихся элементов проектной модели – повторное использование программного кода (других платформ, проектов, систем). Переработка имеющихся элементов и интеграция в новую систему
Структурирование модели реализации – размещение повторно используемых элементов, разрабатываемых артефактов: исходных и исполняемых кодов, БД, документации в проектном репозитории; организация системы контроля конфигураций и версий
Описание распределения и архитектуры времени выполнения (календарный план-график работ) с учетом:
Анализа требований к параллелизму
Определения процессов и потоков и механизмов взаимодействия между ними
Распределения ресурсов для координации между процессами
Связывания процессов с программной средой
Распределения элементов моделей среди проектов

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

выбранного языка программирования
Рецензирование архитектуры (review):
выявить все неизвестные риски для сроков и бюджета
определить архитектурные недостатки
выявить несоответствия требованиям
оценить одно или несколько качественных характеристик ПО
выявить возможности повторного использования кода

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

для других прецедентов)
Проектирование критичных прецедентов использования (итерации от аналитической модели к проектной)
Объединение и сборка готовых классов в пакеты
Проверка архитектурного охвата всех основных артефактов (классов и интерфейсов) - применяемости
Проектирование базы данных
Определение и применение архитектурных механизмов (типовых решений, шаблонов)
Интеграция компонентов – выпуски версий (релизов)
Тестирование критических сценариев (по производительности, нагрузке, интерфейсам, нефункциональным требованиям)

критически важных параметров: производительность системы, время реакции на запрос.
Проверка

использования бизнес-сущностей (объектов) – принцип архитектурного охвата
Проектируя, реализуя, тестируя и документируя архитектурные механизмы – можно решить самые общие и трудные проблемы, которые потом будут использоваться как готовые решения для реализации всех прецедентов.

к проектной модели)
Создать предварительную схему объектов аналитической модели на

основе диаграммы взаимодействий
Распределить действия по классам объектов аналитической модели для обеспечения функциональности прецедента использований
Прорецензировать классы объектов на предмет дублирования функций и взаимодействия
Спроектировать классы объектов проектной модели (путем объединения/разъединения классов объектов аналитической модели
Детализировать классы объектов проектной модели путем определения атрибутов и методов.

данных в сценарии прецедента

данных

различного рода статические связи, которые существуют между ними.
На

диаграммах классов изображаются атрибуты классов, операции классов и ограничения, которые накладываются на связи между классами.
Диаграммы классов отражают взаимодействие между классами системы. Классы можно рассматривать как типы объектов.
Классы содержат данные и поведение (действия), влияющее на эти данные.

являются моделями, описывающими поведение взаимодействующих групп объектов.
Как правило,

диаграмма взаимодействия охватывает поведение объектов в рамках только одного варианта использования. На такой диаграмме отображается ряд объектов и те сообщения, которыми они обмениваются между собой.
Сообщение (message) - средство, с помощью которого объект-отправитель запрашивает у объекта получателя выполнение одной из его операций.
Информационное (informative) сообщение - сообщение, снабжающее объект-получатель некоторой информацией для обновления его состояния.
Сообщение-запрос (interrogative) - сообщение, запрашивающее выдачу некоторой информации об объекте-получателе.
Императивное (imperative) сообщение - сообщение, запрашивающее у объекта-получателя выполнение некоторых действий.
Существует два вида диаграмм взаимодействия: диаграммы последовательности (sequence diagrams) и кооперативные диаграммы (collaboration diagrams).
Диаграммы Последовательности отражают поток событий, происходящих в рамках варианта использования.

1 операция

кооперативные диаграммы (collaborations) отображают поток событий через конкретный

сценарий варианта использования.
Диаграммы последовательности упорядочены по времени, а кооперативные диаграммы больше внимание заостряют на связях между объектами.
У разных разработчиков имеются различные предпочтения по поводу выбора вида диаграммы взаимодействия.
В диаграмме последовательности делается акцент именно на последовательность сообщений: легче наблюдать порядок, в котором происходят различные события. На кооперативной диаграмме можно использовать пространственное расположение объектов для того, чтобы показать их статическое взаимодействие.

Заказ 1 --- * Пункт заказа
Ассоциации: Предприятие 0..1 --->*

Клиент
Обобщение: Частный клиент --- |> Клиент

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

работ.
Во многих случаях DA напоминают блок-схемы, но принципиальная разница заключается в том, что они поддерживают параллельное исполнение процесса (асинхронное/синхронное).

решений – Decision (Хor)
Разделение потока - Fork (And)
Объединение потоков

– Join (And)
Слияние потоков – Merge (Or)
Начальная и конечная точка (Initial, End)
Разбиение деятельности (Partition)

Machine diagram)
Диаграмма автомата (State Machine diagram, диаграмма конечного автомата,

диаграмма состояний) — диаграмма, на которой представлен конечный автомат с простыми состояниями, переходами и композитными состояниями.
Конечный автомат (State machine) — спецификация последовательности состояний, через которые проходит объект или взаимодействие (совокупности взаимодействующих объектов) в ответ на события своей жизни, а также ответные действия объекта на эти события. Конечный автомат прикреплён к одному исходному классу и служит для определения поведения его экземпляров

основным содержанием которой являются пакеты («контейнеры» диаграмм и элементов)

и отношения между ними.
Жёсткого разделения между разными структурными диаграммами не проводится, поэтому данное название предлагается исключительно для удобства и не имеет семантического значения (пакеты и диаграммы пакетов могут присутствовать на других структурных диаграммах).
Пакеты (диаграммы пакетов) служат, в первую очередь, для логического объединения элементов в группы по какому-либо признаку с целью упрощения структуры и организации работы с моделью системы.

Principle) - причины изменения классов пакета должны быть одинаковые.
Общий

принцип повторного использования (Common Reuse Principle) утверждает, что классы должны использоваться повторно все вместе

интерфейсы одного актора (АРМы)
По слоям клиент-серверной архитектуры
Удобство конфигурации для

конкретных пользователей

на компоненты и надо показать их взаимоотношения посредством интерфейсов

или схему компонентов в низкоуровневой структуре системы.
Компонент – это физически заменяемая часть системы, которая соответствует некоторому набору интерфейсов и обеспечивает его реализацию.
Компонент представляет собой физическую упаковку логических элементов, таких как классы, интерфейсы, кооперации классов. Минимально компонент реализует один класс
Компоненты имеют расширение: dll, exe, xml, db …
Компоненты представляют элементы, которые можно независимо друг от друга создать, приобрести, повторно использовать и обновить.
Компоненты обычно отображаются на диаграммах развертывания с префиксом «component»

или требуемых интерфейсов, при этом применяется шарово-гнездовая нотация.
Интерфейс –

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

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

составляющая программного обеспечения
Главными элементами диаграммы являются узлы, связанные информационными путями.
Узлы бывают двух типов:
Устройство (device) – это физическое оборудование: компьютер или устройство, связанное с системой.
Среда выполнения (execution environment) – это программное обеспечение, которое само может включать другое программное обеспечение, например операционную систему или процесс-контейнер
Узлы могут содержать артефакты (artifacts), обычно это исполняемые файлы (такие как файлы .exe, двоичные файлы, файлы DLL, файлы JAR, сборки или сценарии) или файлы данных, конфигурационные файлы, HTML документы и т. д.
Артефакты часто являются реализацией компонентов, что можно показать, задав значения метки внутри прямоугольников артефактов.
Информационные пути между узлами представляют обмен информацией в системе. Можно сопровождать эти пути информацией об используемых информационных протоколах