Принципы работы с требованиями к ПО. Леффингуэлл (2002) (1186169), страница 67
Текст из файла (страница 67)
Итак, вид с точки зрения Модель прецедентов. представляюшпй функциональные воэможности системы, ацщщялгоа является "связующим звеном", объединяюппсч остальные виды. Например, прецедент "Инициация последовательности действий в чрезвычайной ситуации" системы НОЫЬ повлияет на проектирование системы в каждом иэ четырех представлений следующим образом. 1, Логическое представление будет описывать различные классы и подсистемы, реализующие варианты поведения, предусмотренные чрезвычайной последовательно. стью действий.
2. Вид с точки зрения ираиессае будет отражать, каким образом способность НОЫЯ к многозадачности позволит ей начать чрезвычайную последовательность в любой момент, даже тогда, когда производится программирование системы или она занята выполнением других задач. 3. Вид с точки зрения РсмееРтмеаиил будет показывать, как функциональные возможности НОЫБ распределяются по трем ее узлам илн подсистелгам (" Управление включением", "Центральный блок управления" и "ПК домовладельца" ).
303 Часть 6. Построение правильной системы 4. Вттд с пюиктт з(тония реалшакии будет содержать описание различных кодовых артефактов НОБ13, в том числе исходных и выполняемых файлов. Реализация прецедентов в модели проектирования "Основ;ншое на прецедентах проектирование" является основной темой Унифицированного языка моделирования ((тп)Гтет) Модейпб 1.апйнайе) и посвященной ему книги 0нфет1 5о~Яптаге Ветте(о)ттелг Рптсезз (Джейкобсон ()асоЬвоп), Буч (ВоосЬ), Рамбо (КнтЬанВЬ), 1999). Предлагаемый в рамках ПМ1. и унифицир~ ванного процесса метод позволяет группе разработчиков перейти от по. ,АИ нимания птребовоний к проектированию и реализации решения.
Язык ПМЕ солержит специальные модельные конструкции, которые поддерживают Реалшацию (геататн3) прецедентов. Прецеденты резлизупроектирования ются посредством коонерппттй (сотйтттогаттош), которые представляют сс» бой сообщества классов, интерфейсов, подсистем или других элементов, кооперируемых лля получения определенного поведения. Для этого используется 1)М1:стереотип, )мштт. завил ттРецедеитла (шестие тиайшттотт). Он является просто специальной формой кооперации, которая показывает, как функциональные возмоатностн конкретного прецедента осуществляются в модели проектирования.
Таким образом, кооперации являются основными модельными конструкциями в рас. сматриваемой области, так как именно внутри них заключены общие поведенческие ао пекты системы (т.е. механизмы достижения системой своих глобальньпс целей). Посредством деятельности классов-участников и др)тих логических элементов эти конструкции дают более сложное поведение, чем просто "сумма вариантов поведения их составляю. шнх".
Графичсскиьт символом кооперации является эллипс, нарисованный пунктирной линией, внутри которого указано имя (рис. 30.3). (Авторы ПМ$ отметили, что сходство с обозначением прецедента не случайно.) т \ Сообщение об аварийной ситуации Рис. ЗОЗ. зкооие)тикка Кооперации имеют еще одно полезное свойство. С их помощью можно осуществлять трассировку модели прецедентов к модели проектирования, как показано на рис. 30лй Структурная и поведенческая части коопераций Кооперации имеют спфукту~н~ую нмиь, задающую статичеслую структуру системы (классы, элементы, интерфейсы и подсистемы). и гтоеедеттческую, задающую динамику озапмодейтствпя элементов для получения результата.
Однако кооперация не является физическим предметом, это всего лишь описание того, как совместно работают коопери- Глава 30. От понимания требований к реализации системы 309 рованпые элеыстттьт системы. т1тобьт болыле узнать о том, как действует кооперация, нс. обходимо рассмотреть ес внутрсштсс строение.
Модель проекте Модель прецедентов трассировка г Сообщение об аварийной ситуации с ~Г ф 4 с с ! Коолерецил Ъ е с Прецедент 1 т Классы-участники Рнс. 50.4. Реалнзарнл нренедента е модотн нроеиннроеаннн Внутри кооперации структурные элементы можно представить с помощью диагралтзты классов. На рнс. 30 3 показана диаграмма классов для кооперации "Последовательность действий системы НО1.13 при создании чрезвычайных сообщений".
Для моделирования поведенческих аспектов кооперации используются диаграмлты взаимодействий, подобные представленной на рис. 30.6. Рнс.50.5.Днаерамма классон иееиерорнн "Поотедееотелымсмь Ь НОик Р У Р 310 Часть б. Построение правильной системы аа .т. Онтяо>но(;Мене ;Мезмое щеа!е мточеМещвое 1з>с. з0.6. Поведенческие асивки>ьт кооперации "Пвглвдвваимлмииин дейктивий пнтвеиы НОтн ири оидаиии чрвзвычай имк ои>бтцвиий " Использование коопераций для реализации наборов отдельных требований С помощью кооперации можно моделировать реализацию нс только прецедента, но и лн>бого отлсльиого требования или набора требований (рис.
30.7). Несмотря на то что ирецелеиты имск>т искис особые свойства (а именно послелонательность событий), всегяа можит> так составить перечень требований, чтобы добиться той же цели. Таким образом, у иас есть способ, мозно>тнтощий использовать требования всея типов для проектирования и реализации. Модель проектирования трассировка Синхронизировать часы ~ - - - ~- - - - ъ Ф > ь Кооперации > Т Трвбоеан«в Часы должны ., ч - - - -- Каждые 74 часа... щ.
- -- Сннхронизацнв возникает.„ло Рис. ЗО. 7. Модель реализации требований в виде реализации прецедента От проектирования к реализации Молслируя систему иояобным образом, можно гарантировать, что важные прецеденты и требования надлежащим образом отражены а модели проектирования. В свою оче- Глава 30. От понимания требований к реализации системы 311 редь, это помогает удостовериться, что проект программы соответствует требованиям, а это является значительным шагом в процессе ве(зкфккаиии ~фоскт~фованпя.
Следующий шаг совершенно логичный, хотя и непростой. Классы и объекты, определенные в модели проектирования, реализуются посредством физических программных компш нентов (исходпых, двоичных, выполняемых файлов н т.п.), которые оудут псполюооаться для создания выполняемой программы. Но лаже в этом отображении есть свои сложпоспь Например, решения, которые приволят к опрсделсщнгму разбпспщо лопщсской молелн на компоненты, часто зависят от таких требований, как гибкость, производительность, ограничения па топологию развертывания системы и т,д. Главным является то, что па каждое представление системной архитектуры влияют нли, по крайней морс, должны влнязь системные требования, Если помнить об этом, то мы сумеем завершить процесс перехода от понимания требований к проектированию, а затем — к реализации системы.
Заключение Было бы замечательно, если бы можно было непосредственно псрсйтп от трссюваний к программному коду. К сожалению, так нс бываст. Лу*пясс, что может предложить со. временная практика, — это набор конструкций, которые помогают приблизиться к цели непосредственногопреобразования. Один из этих методов, ~еализацил я)згйя)еники, использует прснмущссгва )нпкальных характеристик прецедента и модельных конструкций языка 1 ~МЕ для того, чтобы упростить проектирование и значительно сократить путь от понимания трсй~взни й до ргали:кщн н.
Еще один современный подход предлагает нам рассматривать разработку с помощью "4+1" представлений архитектуры, что позволяет обеспечить разделение пптсрссов. 11ри этом различным участникам процесса реализации становится проще работать пзд техническим проектом и получать доступ к нему по морс его развития. Далее.. Мы признаем, что лишь едва коснулись темы реализации, которая сама по себе является весьма обширной.
К счастью, данная книга не о реализации программных систем, поэтому нам нет необходимости погружаться в эту проблему. Мы оставляем тему реализации и переходим к тому, что объединяет все эти элементы разработки в монолит, — к верификации и проверке правильности (кепйсайоп апб ка1кбапоп, Кбг'г). В послед)ющих нескольких главах мы рассмотрим некоторыс подходы, разработанные для минимизации внесения ошибок на разных сталиях разработки, а также опшпсм методы тестирования и проверки правильности, которые помогут удостовериться, что система осуществляет свои цели.
Верификация и проверка правильности играют важную роль в достижении цели разработки качественного программного обеспечения, В частности, действия но верификации удержившот нас оттого, чтобы заниматься "тсстпрошшпем качества в продукте". Зачастую ре. зультаты рюработки не оправдывают ожиданий нз за неверного прсдстщлспля о том, что "все дефекты можно выявить в процессе тестирования". Это вряд лп возмолою.
Выявлять н исправлять ошибки гораздо дороже, чем просто пс вношпь пх с самого начала. 312 т1асть б, Построение правильной системы Мощным средством, помогающим проводить верификацию и минимизировать вне. сеине случайных ошибок, является трассировка.
В свою очередь, проверка правильности (та)Ыа6оп) помогает направить тестирование иа выявление все же "просочившихся" в систему дефектов. Глава 31 Использование трассировки для поддержки верификации Основные положении ш Трассировка является эффективным методом поддержки верификации. ° Программные требования трассируются от одной или нескольких функций продукта, заданных в документе концепции. ° Автоматические средства трассировки позволяют проверять верификационные отношения, чтобы удостовериться, что ссикакис необходимыс отношения не пропущены и нет лишних верификационных отношений. ° Сами по себе автоматические средства не могут выполнить всю работу; вш рификация требует размышлений, Мы рекомендуем проводить верификацию постоянно, чтобы )бсдиться, что каждый шаг разработки корректен, удовлетворяет потребности следующего шага и пе содержит лишних лействий.
Данная глава посвящена методам трассировки, которые можно использовать лля полдержки всех стадий верификации проекта, начиная с самых первых шагов. Роль трассировки при верификации требований Важным показателем качества реализации программы является возможность ее трассировки на стадиях спецификации, архитекзз ры, проектирования, реалижщии и тестирования.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
