Принципы работы с требованиями к ПО. Леффингуэлл (2002) (1186169), страница 66
Текст из файла (страница 66)
Как ыам исследовать систему, чтобы определить, действительно ли за требованием 3 (отобразить полоску, (" ) отражающую выполнение) непосредственно следует требование 7 (во время компиляции алгоритм состоит...)1 Прецедент, который описывает последовательность действий п«я«т ВВОдит «эп систел~ы и пользователя, а не отдельные требования, значительно ' с«ст«««мпаэ«м«' упрощает данную проблему. В этом случае сами требования, предии коа ставленные в виде прецедентов, гораздо лучше отражают последовательность действий системы вместе со всеми альтернативами и исключительными ситуациями. Прецеденты просто "лучше рассказывают" о том, что должна делать система.
Опи также содержат важнейшую информацию для начала проектирования. Осуществление перехода Итак, хотя мы и не решили проблему ортогональиости, у нас все же есть определен. пые активы и несколько новых методов, которые могут помочь смягчить эту проблему. Если мы сможем с их помощью увеличить параллельность между требованиями и кодом, зто позволит нам использовать понимание требований при проектировании системы.
При этом также будет проще осузпествить переход между этими различными мирами, улучшить технический проект и общее качество полученной в результате системы. Однако прежде необходимо совершить небольшой экскурс в мир моделирования и программ. ной архитектуры. Моделирование систем программного обеспечения Современные системы программного обеспечения чрезвычайно сложны. Не являются исключением системы или приложения, состоящие из миллионов строк программного кода.
Опи могут в свою очередь встраиваться в другие системы, которые чрезвычайно сложны сами по себе, ые говоря уже о сложности возникающих между ними взаимодействий. Вероятно, ни один человек или даже группа людей пе в состоянии понять все дега. ли каждой нз этих систем н их планируемые взаимодействия. При таком уровне сложности полезно представить систему в виде абстрактной упрощенной модели, отбросив ыезначительные детали, чтобы получить более понятгпчо версию. Цель моделирования состоит в том, чтобы упростить систему до поыимаемой Глава 30. От понимания требований к реализации системы 303 "сути". Но важно не переусердствовать, чтобы модель не перестала адекватно представлять реальную систему.
Итак, модель позволяет думать о системе, не путаясь в деталях. Выбор модели — очень важный вопрос. Нужно, чтобы модель помогла пам надлежащим образом понять систему, и мы не хотим, чтобы она ввела цас в заблуждение из-за допущенных в ней ошибок или принятых абстракций. Всем известны рисунки и присны собления, которые помогали древним философам, астрономам и пател~этикам понять движение тел Солнечной системы. Многие из них основывались иа геоцент)тчесхом представлении о Солнечной системе.
согласно которому Земля является непогшнжныы центром Вселенной, что в результате приводило к неправильным теориям. Только после того, как были предложены гелиоцентфические модели, удалось л) пве понять природу нашей Солнечной системы. Благодаря гелиоцеитрическим моделям Вселенной возникли новые возможности и идеи, касающиеся исследования Вселенной в целом. Ученые могли, исходя из зпгх, предлагать уточненные математические теории относительного движения, гравитации и т.д. Но модель ие является реальностью. В некоторых случаях основанные на модели механические представления Вселенной не совсем совпадают с наблюдаемыми явлениями. Например, одним из пер вых подтверждений теории относительности Эйнштейна были наблюдавшиеся и преп;де нс находившие объяснения аномалии орбиты планеты Меркурий.
Помните, модель ие является реальностью! Модели обеспечивают возможность обсуждать сложнузо проблему и получать полезные гипотезы. Но необходимо помнить, что модель — это не реальность, и все время следить, чтобы она не ввела нас в заблуждение. Можно моделировать различные аспекты системы. В зависимости от того, что пас интересует в данный момент, можно создать модель параллельной обработки илп модель логической структуры системы.
Эти модели должны как.то взаимодействовать, и этот аспект также можно моделировать. Каждая нз этик моделей вносит свой вклад в ншие понимание системы, а вместе они позволяют нзм рассматривать сфхнпихпбфу сисппмы в целом. Архитектура систем программного обеспечения Рассмотрим определение Шоу и Галана (ЯЬап, Саг!ап, 1996).
Профаммная архитектура представляет сойа описание элеменпюв, из кото)»ых конспфугфуется система, взаимодействий между ними, а также офазцов, согласно копифым они составля юпия, и офа ничении налагаемых на эти офазцы. Согласно Крачтену (КгисЫеп, 1998), с помощью архитектуры решаются следующие задачи. ° Понять, тало делает система ° Понять, как она работает ° Иметь возможность обдумывать и разрабатывать части системы ° Расширять систему ° Повторно использовать часть (частн) системы при создании новых систем Архитектура является средством, с помощью которого принимаются решения о тон, как будет строиться система. Зачастую мы с самого пачзлз разр,н1откп знаем, кзк будем 306 Часть 6. Построение правильной системы 1'азличным участшскаы нужны различныс представления системы.
Архитсктурныс модели нужны различным гручгнам заинтересованных лиц, которые будут рассматривать предложенную архитектуру с разных точек зрения. Так, например, при строительстве дома нужно иметь сто представления, предназначенные для монтажников, кровелыциков, электриков, водопроводчиков и т.д. Это все один и тот же дом, но мы лсожслс рнссматрннать сто по-разному, в зависимости от потребностей. 4+1 представление архитектуры Как правило, прн рассмотрении системной архитектуры имеется небольшой набор общих потребностей.
Наш коллега Фгсллссусу Крачтсн (РЬ(1(ррс КгцсЬгсп, 1995) указал в своей книге 1+1 представление (или внд, лбслуэ), которые лучше всего иллюстрируют зти обобщснныс потребности. Эти виды изображены на рис. 30.2; различныс заинтересо. ванныс лица (программисты, руководство, пользователи) расположены возле тех представлений, которые онп обычно используют. Программист Управление разработкой программного обеспечения Конечный пользователь Функции Дизайнеры/Теетппе Поведение Сборщики системы Эффективность Масшсабнруемссгь Пропускная способность Системное проектирование Снстемнаятопояппы Доставка Инстеппяцня Обмен информацией Рис. 30.2.
4+! нредпиавление системной аркиогеьтн)ууы 1. Логи сеское гс(гедгтавленссе ()пресс( исспо) характеризует функции системы. Эта абстракция людсли ссрслектиропания представляет логическую стр)ктуру системы с псе осуществлять сборку частей системы, так как мы (или другие) уже разрабатывали впало. гичныс системы раньше.
Простые стартовые решения обозначаются понятием "доминирующая архитектура", которос есть нс что иное, как красивое выражение ыысли "все знают, как создавать систему обработки платежных ведомостей". г(оисснируюигсся архитектура помогает придать начальный импульс процессу принятия решений и минимизирует риск посредством повторного использования частей успешного решения.
Создавая систем» обработки платежных ведомостей, было бы глупо начинать с нуля н изобретать концепции социального страхования, выписки чеков и ме. дпцннскнх отчислений, Следует начать с изучения моделей существующих систем и использовать нх в своих рассуждениях. Глава ЗО. От понимания требований к реализации системы 307 наплыв подсистем и классов, которые в свою очередь являются сущностями, предоставляющими функциональные возможности пользователю. 2. Вид с тачки зрения реализации (гбяЯетен агюи иию) описывает компоненты, относящиеся к реализации системы: исходный код, библиотеки, классы объектов и т.д. Это статическое представление данных компонентов, не описывающее их юаимодейстаие.
3. Вид с точки зрения г4лаиессое (Ргосегз шею) больше подходит для описания операций системы. Такие представления чрезвычайно важны для систем, в которых имеются параллельные задачи, интерфейсы с другими системами, а также другие взаимо. действия, возникающие в ходе выполнения. Так как многие современные системы отличаются высокой степенью параллелизма и многопоточной обработкой, данный вид позволяет рецензенту определить потенциальные проблемы, такие как условия состязания нли блокировки. Можно также использовать вид с точки зрения процессов для исследования пропускной способности и других вопросов производительности, которые пользователь указал в нефункциональных требованиях.
4. Вид е яючки зрения разеертыеаиия (Вер(ауямиг ииче) демонстрирует размещение элементов реализации по поддерживающей их инфраструктуре, состоящей из операционных систем и вычислительных платформ. В этом представлении внимание уделяется не столько тому, хакими являются взаимодействия, сколько тому, что взаимодействия и ограничения существуют там, где встречаются две системы.
Роль модели прецедентов в архитектуре Вернемся к проблеме ортогональности. Вид с точки з(холил глрецедеияюе играет особую роль в архитектурной модели. выстучгая в качестве хранилища требований. В нем представлены основные прецеденты модели прецедентов, поэтому он используется в про. цессе проектирования, а также объединяет все архнтекгурньае представле. ния. Мы выделяем этот вид, поскольку он позволяет всем заинтересованным лицам исследовать планы реализации на соответствие реальному использованию и требованиям к системе.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
