Информационный сайт

 

Реклама
bulletinsite.net -> Книги на сайте -> Программисту -> Непейвода Н.Н. -> "Основания программирования " -> 82

Основания программирования - Непейвода Н.Н.

Непейвода Н.Н., Скопин И.Н. Основания программирования — Институт компьютерных исследований , 2002. — 919 c.
Скачать (прямая ссылка): osnovanprogramm2002.pdf
Предыдущая << 1 .. 76 77 78 79 80 81 < 82 > 83 84 85 86 87 88 .. 316 >> Следующая

3) Типизированное представление — каждое из элементарных составляю -
их требования ассоциируется с некоторм типом данных. В результате формируется набор атрибутов элементарных требований и их значений. Эта информация допускает формальное сопоставление представлений даннх, соответствуих новм элементарным требованиям, с дан-нми, соответствуими требованиями, у е представленными в проекте. опоставление проводится на разных уровнях иерархии типов требований к системе. Более того, некоторые элементарнейшие аспекты смi-сла новых данных (обычно отражаемые мнемоническими идентификаторами) так е могут проверяться почти формально.
4) Модельные представления уровня анализа — образы элементарных требований как элементы аналитических моделей систем : моделей ситуаций использования и динамики взаимодействий, которе использу тся для оценки требований.
Если требование принимается на уровне анализа, то трассировка продола-ется на следуих уровнях, и мо но говорить о продол ении последовательности трансформаций вплоть до реализации требования:
5) Модельные представления уровня конструирования — образы элементар-нх требований в диаграммах классов, состояний и других компонентах архитектуры системы. На этом уровне требования трансформируют-
222
ГЛАВА 4. ЖИЗНЕННЫЙ ЦИКЛ
ся или отклоня тся в зависимости от их соответствия у е разработанной части проекта.
5) Программные представления — программные рабочие продукты и их фрагмент , которе рассматрива тся в качестве образов требований, представленных очередной версией системы.
5) Документные представления — фрагмента документов, сопровождающих программный код и предназначенных для поддержки деятельности пользователей.
хема на рис. 4.14 иллстрирует приведенну последовательность трансформаций. Первые три представления требований изображены в виде совокупностей стрелок, которые при переходе от одного представления к другому становятся все более упорядоченнми.
ерархия типов требований представлена на рисунке следуим образом. ерхний уровень — это абстрактнй тип, свойства которого присуи требованиям всех типов (они сводятся к стандартизованному набору операций объединения, пересечения атрибутов, сравнения значений атрибутов и др.). Можно сказать, что Табстр задает регламент, которого следует придер-
иваться при оперировании с требованиями. Следуий уровень содерит четыре обязательных типа: Тэкон, Тфунк, Тинт и Тэфф, которые объединяют требования экономического характера (пределы стоимости, рентабельность и пр.), функциональне требования, требования к интерфейсу и эффективности. ноготочием обозначены тип , которые добавля тся из-за специфики проекта.
'Т(aa 1, * * *, ajbW>a), (b 1, * * *, fbnnь), (c 1, * * *, cnn c), * * *, ' Т z (1, * * *, zznnz)
это конкретные типы, к которм приписва тся элементарне составля -
ие требований (в скобках указан их атрибуты). Модельные представления уровней анализа и конструирования изобра-
ены в виде условнх схем различных видов. рограммне и документне представления это текстове файлы, пиктограммы которх показан на рисунке.
риведенная схема наглядно показывает то, что выну ден делать разработчики для преодоления трудностей управления требованиями. Она может рассматриваться в качестве проекции изненного цикла на задачи анализа
4.4. ТРЕБОВАНИЯ К ПРОГРАММНОМУ ИЗДЕЛИЮ И ЖИЗНЕННЫЙ ЦИКЛ 223
** *
1.Исходное представление требований
*** ****** ***** **
***** *
2. Унифицированные представления требований
Табстр
Та(а 1,...,8?) Tb(bl,...,bnb) Tc(cl,...,cnc) ... T2(Zl,...,^) *** ***** ** * ****
3. Типизированные представления требований
feg) J-OJ feO
4.
Модельные представления уровня анализа
6. Программные представления
7. Документные представления
Рис. 4.14. Схема трансформации требований
224
ГЛАВА 4. ЖИЗНЕННЫЙ ЦИКЛ
требований. Кадое требование, поступаее для анализа, проходит вполне традиционные этапы жизненного цикла, правда, в несколько специфичном виде: учитываются только те работы, которые имеют отношение к моделированию требований. Явное выделение задач управления требованиями способствует более успеному их реени .
4.4.3. Учет трассировки требований в модели жизненного цикла
ри построении модели изненного цикла следует указать этапы, когда производятся аги, связанные с трассировкой. о этой причине следует различать два варианта работа с требованиями в объектно-ориентированном проекте:
1. Требование или группа требований обрабатываются до начала работ над итерацией;
2. Требование или группа требований поступа т, когда работ итерации начались.
ервый вариант полность укладывается в схему модифицированной модели фазы-функции (см. рис. 4.9, 4.10). Если требование (группа требований) принимается для данной итерации и используется при разработке сценария, которй будет реализовываться (контрольне точки 2, 8), то указанные на схеме трассировки работы вкл ча тся в аналитическу и конструкторску деятельность. В противном случае оно либо откладвается до последуих итераций, либо отклоняется.
Второй вариант прерывает последовательный процесс выполнения итерации — необходима немедленная реакция на поступаие требования, после которой (а во многих случаях и параллельно с которой) прерваннй процесс выполнения итерации возобновляется. о суеству, вполняется мини-цикл обработки требований, который нужно изобразить в качестве дополнительного элемента модели, описываей итеративное развитие проекта с учетом трассировки. ри этом в модели, как и в первом варианте, следует отразить возмо ные результат анализа требования:
Предыдущая << 1 .. 76 77 78 79 80 81 < 82 > 83 84 85 86 87 88 .. 316 >> Следующая
Реклама
Авторские права © 2009 AdsNet. Все права защищены.
Rambler's Top100