Проектная документация системы

из "Разработка и управление требованиями "

Проницательный читатель, наверняка, уже заметил, что идея аргументов удовлетворения весьма напоминает основную идею сэндвича управления требованиями, представленного на рис. 1.9, - только здесь начинкой между слоями являются аргументы удовлетворения. Далее - проще если все аргументы удовлетворения собрать в единый документ, то все вместе они сформируют аналитическую и проектную документацию. Эта документация и будет являться связующим звеном между требованиями и моделированием. [c.166]
Роль проектной документации состоит в том, чтобы агрегировать - в тестовой и графической формах - все те разрозненные части моделей и сценариев, которые расшифровывают, почему требований данного уровня являются необходимыми и достаточными для удовлетворения требований более высокого уровня. Документ будет содержать данные, полученные в результате моделирования, которые подтверждают обоснованность принятых проектных решений. При этом связи между уровнями требований фактически присутствуют и в этом проектном документе. Следовательно результаты моделирования также оказываются включенными в цепочку связей и могут вовлекаться в процесс анализа, в частности, в процесс анализа влияния. [c.167]
Давайте рассмотрим пример, поясняющий какого рода информация может включаться в проектный документ. [c.167]
Данный раздел будет содержать текстовое описание всех моделируемых сущностей. Каждая их них будет соответствовать понятию класс в модели UML. [c.167]
Термин Единица багажа обозначает один предмет, сдаваемый в багаж. Каждый пассажир может иметь 0 или более единиц багажа. [c.167]
Термин Учитываемая единица багажа обозначает единицу багажа, для которой может быть однозначно определена ее принадлежность определенному пассажиру. [c.167]
Термин Багажная квитанция обозначает средства, позволяющие пассажиру подтвердить принадлежность ему единицы багажа. [c.167]
Багажная квитанция предназначена для однозначной идентификации единицы багажа. [c.167]
Последовательность рисунков этого раздела иллюстрирует выдержки из документа анализ потребностей , который описывает модель системы регистрации багажа в области проблем. Модель, если можно так выразится, располагается между документом, описывающим перечень потребностей и документом, отражающим пользовательские требования (см. рис. 7.12), и использует графическую нотацию и язык моделирования UML 2 для отображения анализа в визуальной форме. [c.168]
Основные понятия. Для отображения основных понятий из области проблем и отношений между ними используется диаграмма классов UML. Каждое понятие изображается в виде класса UML, а каждое отношение - в виде ассоциации UML. И классы и ассоциации являются компонентами документа и отображаются в нем в текстовой форме. На рис. 7.13 показан пример системы регистрации багажа. Значок слева от параграфа обозначает, что эта часть документа соответствует определенному объекту в UML модели. [c.168]
Заинтересованные стороны. Данный раздел документа перечисляет все заинтересованные стороны, которые были определены в результате анализа, и содержит диаграмму классов, показывающую отношения между ними. Рис. 7.14 иллюстрирует пример системы с двумя заинтересованными сторонами и одним отношением между ними. [c.168]
Данный раздел должен содержать текстовое описание каждой из заинтересованных сторон. Каждая из них должна соответствовать понятию актер в модели UML. [c.168]
Пассажир - это любой человек, собирающийся полететь на самолете. [c.168]
Семья - это группа пассажиров, путешествующих вместе. Они могут иметь общий багаж, а также желание сидеть рядом. [c.168]
Дополнительная диаграмма классов может показывать отношения между заинтересованными сторонами, в случае, если они существуют. [c.168]
Статическое окружение. Целью этого раздела (рис. 7.15) является идентификация окружения, в котором существует система регистрации багажа. На диаграмме классов система регистрации багажа, наряду с окружающими и составляющими ее внутренними системами, изображается в виде класса. Для моделирования отношений между этими системами используются ассоциации и включения. Как уже отмечалось выше, каждый класс и ассоциация появляются в документе в виде текстового описания. [c.168]
Данный раздел должен начинаться с диаграммы классов, описывающей основной контекст разрабатываемой системы. [c.169]
Данный раздел определяет и описывает разрабатываемую систему. [c.169]
Это система того же уровня иерархии - внутренняя по отношению к разрабатываемой. Мы отобразим ее как класс , но со стереотипом актер . [c.169]
Это система того же уровня иерархии - внутренняя по отношению к разрабатываемой. Мы отобразим ее как класс , но со стереотипом актер . [c.169]

Вернуться к основной статье