Координация процесса рецензирования. Необходим наблюдатель за процессом рецензирования (библиотекарь)

Модели используются после их одобрения. Цель (диаграмма А-0) определяет, как будет использоваться модель. Т.о., как только завершено создание модели с требуемым уровнем детализации и модель проверена, она может применяться для достижения поставленной цели.

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

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

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

Виды диаграмм:

Структурные диаграммы:

● Диаграмма классов – описывает структуру системы, демонстрирует классы системы, их атрибуты, методы и зависимости между классами.

● Диаграмма компонентов – показывает разбиение программной системы на структурные компоненты и связи м/у компонентами. Физические компоненты: файлы, библиотеки, модули, исполняемые файлы, пакеты и т. п.

● Композитной/составной структуры – внутренняя структура классов и, по возможности, взаимодействие элементов (частей) внутренней структуры класса.

● Диаграмма развёртывания – моделирование работающих узлов (аппаратных средств) и артефактов, развёрнутых на них.

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

● Диаграмма пакетов – пакеты и отношения м/у ними. Для организации элементов в группы по какому-либо признаку с целью упрощения структуры и организации работы с моделью системы.

● Диаграмма профилей

Диаграммы поведения:

● Диаграмма деятельности – разложение некоторой ти на её составные части. Деят-ть – спецификация исполняемого поведения в виде координированного последовательного и параллельного выполнения подчинённых элементов.

● Диаграмма состояний – представлен конечный автомат с простыми состояниями, переходами и композитными состояниями.

● Диаграмма прецедентов – отношения, существующие м/у акторами и вариантами использования.

● Диаграммы взаимодействия:

- Диаграмма коммуникации/ Диаграмма кооперации – взаимодействия м/у частями композитной структуры или ролями кооперации. Явно указаны отношения м/у элементами, время не используется (применяются порядковые номера вызовов).

- Диаграмма последовательности – упорядоченное во времени взаимодействие объектов: объекты и последовательность сообщений, которыми они обмениваются.

- Диаграмма сотрудничества – взаимодействия объектов, абстрагируясь от последовательности передачи сообщений.

- Диаграмма обзора взаимодействия – взаимодействие объектов в создаваемой системе.

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

RUP (Rational Unified Process) – методология разработки ПО. Принципы:

- Ранняя идентификация и непрерывное (до окончания проекта) устранение основных рисков.

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

- Ожидание изменений в требованиях, проектных решениях и реализации в процессе разработки.

- Компонентная архитектура, реализуемая и тестируемая на ранних стадиях проекта.

- Постоянное обеспечение качества на всех этапах разработки проекта (продукта).

- Работа над проектом в сплочённой команде, ключевая роль в которой принадлежит архитекторам.

Итеративная модель разработки. В конце каждой итерации (в идеале 2-6 недель) проектная команда должна достичь запланированных на данную итерацию целей, создать или доработать проектные артефакты и получить промежуточную, но ф-ную версию конечного продукта. Быстро реагирует на меняющиеся требования, обнаруживает и устраняет риски на ранних стадиях проекта, а также эффективно контролирует качество создаваемого продукта.