/OOAaD

Объектно-ориентированный анализ и проектирование. Разработка ТЗ.

OOAaD - Объектно-ориентированный анализ и проектирование

Этап 1 "Формулировка требований"

Этап 1 состоит из определения предметной области проекта и работ по формулировке требований к проектируемому программному обеспечению. Темой проекта может быть любое программное обеспечение, обслуживающее некоторую деятельность. Результатом этапа 1 являются два документа - документ представления предметной области проекта в виде текстового описания и документ со списком функциональных требований. Текстовое описание можно рассматривать как конспект интервью с заказчиком. Документ с требованиями является исходными данными для последующих этапов.

Этап 2 "Описание вариантов использования"

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

Этап 3 "Диаграмма классов"

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

Этап 4 "Диаграммы логического уровня"

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

Этап 5 "Диаграммы физического уровня"

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