Принципы работы с требованиями к ПО. Леффингуэлл (2002) (1186169), страница 63
Текст из файла (страница 63)
По понятным причинам все пути в этой блок схеме заканчивались одним и тем же решением: "Купить 3ААВ". Где'го должна быаа быть логическая ошибка. но мы ие смогли ее найти. Нам действительно нравится эта машина! 28б Часть б. Уточнение определения системы На рис. 28.4 показана типичная диаграмма деятельности в принятых в (зМЬ обозначениях.
Хотя ту же информацию можно представить в форме псевдокода, $3МЬ обеспечивает визуальное представление, которое проще понять. Наело Рва 28.4. Дяасрамма дееасаевноааа Единственная проблема при использовании диаграмм деятельности, как выяснили программисты за последние 80 лет, состоит в том, что достаточно скучно поддерживать их соответствие современному состоянию разработки.
Такая проблема существует для всех графических представлений при отсутствии автоматических средств; никому не хочется перерисовывать диаграмму перехода состояний или дерево решений. Модели сущность-связь Если набор требований описывает структуру данньи системы и связи между ними, удобно представить зту информацию в виде диаграммы сущность-связь (ЕпШуге(аг(опв)г(р б)абгащ, Е)с1)). На рис. 28.8 представлена типичная ЕИЗ. Диаграмма сущность-связь обеспечивает высокоуровневое "архитектурное" представление данных (на рисунке — это закаэчики, счета. фактуры, заказы и т.д.). Ее можно затем дополнить соответствующими подробностями, содержащими необходимую информацию (например, описание заказчика).
В Есс)з основное внимание уделяется внешнему поведению системы, что позволяет ответить на такие вопросы, как "Можно ли в счет- фактуре укззать более одного адреса выставления счетас" Овмвзас иет. Хотя модели сущность-связь являются мощным инструментом моделирования, они имеют существенный недостаток, который заключается в том, что далекому от техники читателю трудно их понять. Как видно иэ рис. 28.5, линии, соединяющие заказчика и захаз, а также заказ и счет-фактуру, отмечены кружками и "птичьими лапками". Возникает вопрос: что зжо все азначаежУ Попытка ответить иа него в рам- Глава 28. Теоретически обоснованные формальные методы...
287 ках данной книги бмла бы значительным откэонением от темы, чего мы решили избежать, Но если уклониться от ответа на этот вопрос при описании множества требований, это может привести к тому, что некоторые пользователи просто не поймут, что происходит. Можно организовать для пользователей двухдневные курсы по принятой в ЕКЕьмоделях системе обозначений. но неизвестно, воспримут ли они ее. Можно использовать ЕКВ в качестве "формальной" формы документации в среде разработчиков.
Ряс. 38.5. ДяасРамма с)эвяасмьсэюь Объектно-ориентированные модели Если детально разрабатываемые требования должны содержать описание структуры и связей суэаносжей системы (например, расчетных листов. служащих, сотрудников отдела заработной платы и т.д), для более полного описания поведения системы можно использовать объектно-ориентированные модели.
При современном уровне популярности объектно-ориентированных методов и быстром внедрении языка ПМЕ эти модели постепенно превращаются в спецификации и, более того, в реализационные модели, используемые при реализации функциональных возможно. стей системы. Удобство заключается в том, что применение стандартов 13М) обеспечивает всем общее понимание того, что означает данное представление, и тем самым уменывает неоднозначность, заставляя всех "говорить на одном языке", пусть и техническом. Например, объект "Сотрудник" на рис.
28.6 будет описываться с помощью содержащихся в нем ориентированных на данные ажрибутоэ, таких как название подразделения и должность, а также предоставляелгых им углуд таких как добавление нового сотрудника, удал ение сотрудника и поиск конкретного экземпляра сотрудника. 288 Часть 5.
Уточнение определения системы Ркс. 28.6. Обэеьтяяэериемяюраэяяиал модель Схемы потоков данных При обсуждении требований в данной главе предполагалось, что мы имеем дело с гребо. ваннами "атомарного уровня". Как правило, так и бывает в типичном документе, но часто п<» лезно иметь визуальное представление, иллкктрирующее структуру и организацию этих ато парных требований, а также связей квола-вывода между ними.
Для этого широко используется представление подобной информации в виде схемы потоков данных (рис. 28.7). Модели, использующие схемы потоков данных (1)Н)), испытывают те же трудности, что и модели сущность.связь (ЕИЭ), хотя далекому от техники читателю обычно несколько проще понять значение 1)Р1) без специальной подготовки. Некоторые органиэации добились значительного успеха, используя РГ1) в качестве основы общения нетехнически ориентированных пользователей и разработчиков; в то время как другие обна. ружили, что их пользователи блокируют любые попытки использовать столь "формальные" обозначения. Если схему потоков данных в я)зия(Гияс удаежсл испольэ~ вать, то возможно провести декомпозицию каждого из "кружков" (рис. 28.7) на 1)Г1) бо. лее низкого уровня.
Так требования для кружка 5 ("закупаелгые ресурсы" ) поясно описать подробнее с помощью схемы более низкого уровня, которая иллюстрирует соответствующие детали. Процесс декомпозиции продолжается до тех пор, пока кружки действи. тельно станут "атомарными"; на этом уровне связанные с кружком требования уже можно описать с помощью псевдокода, конечного автомата, дерева решений или блок-схем.
(На самом деле сегодня существует более серьезная опасность при использовании 1)Р1); приверженцы объектно-ориентированного программирования могут посчитать, что вы занимаетесь функциональной декомпозицией данных и, следовательно, являетесь ретро. градом, и в дальнейшем будут игнорировать все, что вы скажете по любому поводу.) Глава 28. Теоретически обоснованные формальные методы... 289 Продала та ~~™м Ри. гВЛ. С Ь Ведение спецификаций Работая с требованиями, мы не злоупотребляем этими формальными методами и используем их только для того, чтобы проиллюстрировать поведение системы. Это значительно уменыпает головную боль от необходгсиостн их сопровождения. Кроме того, новое поколение автоматических средств разработки программ обеспечивает существенную поддержку прямо.
го и обрапюго проектирования, т.е, они предоставляют возможносп автоматически поддеР живать синхронизацию кода и представления в модели. По мере развития этих средств появится воэможность рассматривать изменения требований кэк принятые в процессе кодирования решения, которые влияют на внешнее поведение системы. Когда дело касается сопровождения, на первом плане должен быть здравый смысл. х90 Яаеть 5. Уточнение определения системы Типичная проблема сопровождения возникает, когда код или спецификации пере. сматрнваются, а соответствующие формальные спецификации одновременно не исправляются. Теория гласит: "код — это спецификация".
Мы не утверждаем, что абсолютным правилом является ебязаямлькое обновление формальных спецификаций по мере развн. тня проекта. Но тех, кто случайно обратится к устаревшей документации, подстерегает множество ловушек. С нами это также случалось в процессе написания данной книги, когда мы говорили, что "не нужно обновлять этот рисунок", а затем по ошибке использова. лн устаревшую версию. В том, что касается обновления. следует руководствоваться здравым смыслом. Обновляйте то, что необходимо, основываясь на важности данной информации. Если это не является жизненно важным, может быть, можно отказаться от обновленна.
Один нз методов, который мы в свое время использовали, состоит в том, чтобы при принятии решения не обновлять некий документ, а делать на нем пометку "Устаревший". Мы считаем устаревшую модель менывнм из двух зол. Лучше иметь устаревшую экая дель, чем не иметь модели спецификаций вовсе! Рабочий пример Все эти методы рассматривались командой проекта НО! !Я прн подготовке пакета НО1Л5 ЯЙЗ РасЕаяе.
Первая версия данного пакета представлена среди артефактов системы НОЕЬ в приложении А. Глава хб. Теоретически обоснованные формалыгые методы... з91 В части 5 мы выяснили, что требования должны полно и сжато фиксировать потребности пользователей в таком виде, чтобы разработчик люг построить удовлетворяющее ик приложение. Кроме того, требования должны быть достаточно конкретными, чтобы можно было определить, когда они удовлетворены.
Зачастую именно команда обеспечивает эту конкретизацию; это еще одна возможность убедиться, что определяется правильная система. Существуют различные возможности органиэации и документирования этих требований. Мы остановились на пакете Мооетп 5Й5 Расйще, логической конструкции, которая позволяет документировать требования в виде прецедентов, документов, форм бзэ данньпс и т.д. Хотя мы внесли несколько предложений относительно того, как организовать такой пакет, мы считаем, что форма не так важна, лишь бы пакет содержал все, что необходимо. Вся разработка должна вытекать из требований, зафиксированных в пакете Мобегп 5Й5 Раскзбе, а все спецификации пакета должны найти отражение в действиях разработки.
Таким образом, все виды деятельности яввиотся отражением пакета и наоборот. Пакет Мобегп 5й5 РасЬбе является "живой" сущностью; его следует пересматривать и обновлять на протяжении жизненного цикла проекта. В пакете указывается, какие функции должны осущеспопггься, а ие то, как они осуществляются. Он используется для задания функциональных требований, нефункциональных требований и ограничений проектирования. Мы также предложили набор показателей, которые можно испольэовать для оценки качества пакета и содержащихся в нем элементов.
Если необходимо, документация требований может дополняться одиилг или несколькилги более формальнылги либо более структурированными методами спецификации. Пакет Модегп 555 Расйабе содержит детали, которые необходимы оэл аосягроекия феализавои) правильной системы. Эту часть работы над проектом мы обсудим в части б, "Построение правильной системы". Часть 6 Построение правильной системы И Глава 29.
Как правильно построить правильную систему: общие положения ° Глава 30. От понимания требований к реализации системы И Глава 31. Использование трассировки для поддержки верификации ° Глава 32. Проверка правильности системы ° Глава 33. Применение метода анализа дивидендов для определения объема У8сУ-действий ° Глава 34. Управление изменениями 294 Часть 6. Построение правильной системы В части 5 мы ознакомились с некоторыми методами сбора, ор~анизации и документирования требований к разработке. Мы рассмотрели различные методы спецификации требований и отметили, что самос ~лавное — собРать осе тРебооания к пРоекту, а п~икже сгюсобсншооагаь тому, ч снобы заинтересованные лико их поняли и одофили.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
