Технологии программирования - Wiegers.Software R. Development Productivity Award Москва 2004 удк 004. 45 В41 Карл Разработка требований к программному с англ. М. дом Русская Редакция , 2004. ил. Isbn 5-7502-0240-2 Эта книга
 Скачать 37.95 Mb.
| Образовательный портал Как узнать результаты егэ Стихи про летний лагерь 3агадки для детей |
Полное содержание архива WinRAR ZIP archive.zip:  С этим файлом связано 6 файл(ов). Среди них: task2.txt, unit4.png, task1.txt, Mikhneva_Anastasia_1951.pkt, WinRAR_ZIP_archive.zip, Wiegers_Software_Requirements.pdf, Metodicheskie_ukazania_praktika.docx. Показать все связанные файлыГлава Любое изображение стоит слов включены все допустимые пути переходов. Клиентам, как правило, хватает незначительных пояснений, касающихся принятой системы обозначений, — что означают прямоугольники и стрелки, — чтобы прочитать диаграмму перехода состояний. Вспомните из главы 8, что основная функция Chemical Tracking System — позволить действующим лицам, которые названы «Сотруд- ники, разместившие заказ на химикат», разместить запрос химиката, который может быть выполнен либо складскими работниками (если химикат есть на либо сторонним поставщиком (для этого ему надо отправить запрос). Каждый запрос проходит через несколько со- стояний с момента его создания до момента либо его выполнения, ли- бо отмены (два конечных состояния). Таким образом, мы можем батывать жизненный цикл запроса химиката как механизм с конечным числом состояний и моделировать его так, как показано на рис. -4. Эта диаграмма перехода состояний показывает, что отдельный за- прос может находиться в одном из следующих семи состояний: I В подготовке. Сотрудник создает новый запрос, инициировав эту функцию из другой части системы; 1 Отложен. Сотрудник сохраняет часть запроса для выполнения в будущем, не передавая его в систему и не отменяя операцию за- проса; 1 Принят. Пользователь отправляет законченный запрос и система принимает его к исполнению; Размещен. Запрос должен быть удовлетворен сторонним постав- щиком, покупатель размещает заказ у продавца; 1 Выполнен. Запрос удовлетворен: контейнер с химикатом постав- лен либо со склада химикатов, либо от поставщика; 1 Заказ ожидает У продавца не оказалось химиката в наличии, и он уведомил покупателя, что заказ отложен для будущей поставки; Отменен. Сотрудник отменил принятый системой заказ до того, как тот был выполнен, или покупатель отменил заказ у продавца, до того как тот был выполнен или пока он был отложен. Когда представители пользователей Chemical Tracking System про- смотрели диаграмму перехода состояний для запроса химиката, они определили, что одно состояние не нужно, другое важное состояние отсутствует, и указали два неправильных перехода. При изучении со- ответствующих функциональных требований эти ошибки никто из них не заметил. В этом и заключается важность представления информа- ции о требованиях на нескольких уровнях абстракции. Зачастую про- 220 Часть II. Разработка требований к ПО легче обнаружить, если идти назад от наиболее детализирован- ного уровня и рассматривать большую картину, которую обеспечивают модели анализа. Однако диаграмма перехода состояний не дает уро- вень деталей, достаточный разработчику для создания ПО. тельно, в спецификацию требований к ПО для Tracking Sys- tem были включены функциональные требования, связанные с боткой запроса химиката и возможными изменениями его состояния, I t пользователь создает новый новый сохраняет незаконченный запрос пользователь вызывает незаконченный запрос система принимает запрос запрос на складе химикат от поставщика сотрудник, заказ на химикат, отменяет запрос покупатель размещает у покупатель отменяет заказ у поставщик помешает заказ на в невыполненные Рис. -4. Диаграмма перехода состояний для запроса химиката a Chemical Tracking System Глава Любое изображение стоит слов Карта диалогов Пользовательский интерфейс также можно рассматривать как меха- низм с конечным числом состояний. Только один элемент диалога (та- кой, как меню, рабочая область, диалоговое окно, командная строка или дисплей сенсорного доступен в определенный момент времени для ввода информации пользователем. Пользователь может перейти к другим определенным элементам диалога, с действием, которые он в активной области ввода. Количе- ство возможных путей навигации в сложном графическом интерфейсе велико, однако оно конечно и, как правило, все возможности извест- ны. Следовательно, множество пользовательских интерфейсов можно моделировать, применяя одну из форм диаграммы перехода состоя- ния, которая называется карта диалогов (dialog (Wasserman, Wiegers, 1996a). и описывают похо- жий прием — карту перемещений (navigation map), которую отличает более богатый набор условных обозначений для представления раз- личных типов элементов взаимодействия и контекстных переходов. Карта диалогов представляет дизайн пользовательского интерфей- са на высоком уровне абстракции. На ней показаны элементы диалога в системе и навигация между ними, но не показан подробный вид эк- рана. Карта диалогов позволяет рассмотреть возможные пользовательского интерфейса с учетом вашего понимания требова- ний. Пользователям и разработчикам стоит изучить карту диалогов, чтобы выработать общее представление того, как пользователь может взаимодействовать с системой для выполнения задачи. Карты диало- гов также полезны при моделировании визуальной архитектуры Web- сайта. Ссылки для перемещений, которые вы включаете Web-сайт, на картах диалогов изображаются в виде переходов. Карты диалогов свя- заны с архивными системными документами, в которые также включе- но краткое описание назначения каждого экрана и Widrig, 2000). Карты диалогов отражают сущность взаимодействий системы пользователя и основные моменты решения задачи, без тормозящих работу команды деталей макета экрана. С помощью такой карты поль- зователи могут отследить отсутствующие, неправильные или ненуж- ные переходы и, следовательно, отсутствующие, неправильные или ненужные требования. Абстрактная концептуальная карта диалогов, разработанная в ходе анализа требований, становится руководством для подробной разработки пользовательского интерфейса. 222 Часть II. Разработка требований к ПО как и обычные диаграммы перехода состояния, карта диало- гов показывает каждый элемент диалога как состояние ник) и каждую допустимую возможность перемещения как переход (стрелка). Условие, инициирующее перемещение по пользовательско - му интерфейсу, показано в виде текстового ярлыка на стрелке перехо- да. Существует несколько типов инициализирующих условий: действие пользователя, например нажатие функциональной ши или щелчок гиперссылки или кнопки диалогового окна; 1 значение данных, такое, как недостоверная информация, в резуль- тате чего появляется сообщение об ошибке; I системное условие, например отсутствие бумаги в принтере; некоторые комбинации вышеперечисленных, например ввод ра элемента меню и нажатие клавиши Enter, Карты диалогов слегка напоминают диаграммы потоков, но у них другое назначение. Диаграммы потока ясно показывают этапы цесса и точки принятия решений, но не пользовательский В отличие от них, на карте диалогов не отображается процесс, выпол- няющийся по линиям перехода, которые соединяют один элемент лога с другим. Выполнение решения (обычно это выбор скрыто за экранами, которые показаны на карте диалогов в виде пря- моугольников, а условия, в результате которых отображается тот или другой экран, описаны над стрелками переходов. Вы можете карту диалогов как противоположность — или дополнение — диаграм- мы потока. Чтобы упростить карту диалогов, пропустите глобальные функции, такие, как нажатие клавиши F1 для вызова справки для каждого диало- гового элемента. В разделе спецификации требований к ПО, посвя- щенному пользовательскому интерфейсу, должно быть указано, что эта функциональность будет доступна, но демонстрация множества экранов справки на карте диалогов вносит в модель беспорядок при незначительных преимуществах. Точно так же при моделировании Web-сайта не нужно включать стандартные для каждой страницы ки перемещения. Вы также можете опустить транзакции, реализую- щие последовательность перемещений по Web-странице которые запускаются кнопкой Back Web-браузера. Карта диалогов — это прекрасный способ представить взаимодей- ствия действующего лица и системы, описываемые вариантом ис- пользования. Карта диалогов позволяет отобразить направления в виде ответвлений от нормального Я обна- ружил, что наброски фрагментов карты диалогов на доске оказались особенно полезны на семинарах по сбору информации, Глава Любое изображение стоит 1024 слов 223 вариантов когда участники изучали последователь- ность действий пользователя и реакций системы при выполнении за- дачи. В главе 8 описан вариант использования Chemical Tracking System под названием «Запрос химиката». Нормальное направление развития этого использования подразумевает запрос контейнера с хи- микатом со склада. Альтернативное направление — запрос химиката у поставщика. Пользователь, размещающий запрос, хотел бы иметь воз- можность просматривать историю доступных контейнеров с этим хи- микатом, прежде чем выбрать один из них. На рис. -5 показана карта диалогов для этого несколько сложного варианта использования, На первый взгляд эта диаграмма может показаться довольно запу- танной, но в ней довольно легко разобраться, если попробовать за один раз отследить один прямоугольник и одну линию. Пользователь инициирует этот вариант использования, размещая заказ химиката из меню Tracking System. В карте это действие пользо- вателя, обозначенное стрелкой в верхней левой части карты, направ- ленной к прямоугольнику с названием «Список текущих запросов». Этот прямоугольник представляет основное рабочее пространство для такого варианта использования, те, список химикатов в текущем за- просе пользователя. Стрелки, исходящие из этого прямоугольника на карте диалогов показывают все возможные перемещения — следо- вательно, функциональность — доступные пользователю: 1 отменить весь запрос; I передать к исполнению запрос, если в нем содержится хотя бы один химикат; I добавить новый химикат к запросу; I удалить химикат из списка. В последней операции, удалении химиката, не участвует какой-либо еще элемент диалога, при этом просто обновляется список текущих запросов после как пользователь вносит По мере перемещения по этой карте диалогов вы увидите элемен- ты, отражающие остальные элементы варианта использования «За- прос химиката»: I один для химиката у поставщика; другой путь для выполнения запроса через склад химикатов; еще один возможный путь — просмотр истории контейнера, храня- щегося на складе химикатов; I отображение сообщения об ошибке для обработки ввода непра- вильного ID химиката или других возможных ошибочных условий. 224 Часть II. Разработка требований к ПО т OK; выход из функции Т запрос запросить отменить весь запрос отправить запрос для больше у удалить химикат из списка запросить другой химикат неправильное Отобразить химиката сообщение i [ 1 у . 1 1 отменить нового химиката добавление нового химиката запросить у поставщика j Cm У запросить другой химикат запросить химикат запросить на выбрать контейнер добавить к списку е д • Список и брать поставщика к списку ко можно j химикат химикат у поставщика историю контейнера возврат Рис. -5. Карта диалогов для варианта использования «Запрос химиката» в системе Chemical Tracking System Глава Любое изображение стоит слов 225 Некоторые переходы на карте диалогов позволяют пользователю откатить операцию. Пользователей раздражает, если они уже переду- мали, а им все-таки приходится завершать задачу. Карты диалогов по- зволяют облегчить и упростить работу, предлагая функции отката и от- мены в стратегических точках. Пользователь, изучающий карту диалогов, может обнаружить не- достающее требование. Например, осторожный пользователь может захотеть подтвердить операцию, которая отменяет весь запрос, чтобы избежать непроизвольной потери данных. Дешевле добавить такую функцию на этапе анализа, чем встраивать ее в уже законченный про- дукт, Поскольку карта диалогов представляет концептуальные элемен- ты, участвующие во взаимодействии пользователя и системы, не пы- тайтесь зафиксировать все детали пользовательского интерфейса на этапе работы над требованиями. Лучшее применение этих моделей — помочь всем, кто заинтересован в проекте, выработать общее понима- ние предполагаемой функциональности системы. Диаграмма классов Объектно-ориентированная разработка ПО вытеснила структурный анализ и разработку, породив анализ и разработку. Как правило, в предметной или рабочей области объекты (objects) соотносятся с объектами реального мира. Они представляют отдельные экземпляры, выведенные из родового шаблона, который называется класс (class). В описания классов входят атрибуты (дан- и которые можно выполнять с этими атрибутами. грамма классов (class diagram) — это графический способ отобразить классы, идентифицированные в ходе объектно-ориентированного анализа, и взаимоотношений между ними. Для продуктов, разработанных с помощью объектно-ориентирован- ных методов, не требуются уникальные приемы разработки требова- ний. Дело том, что требования отражают то, что пользователям необ- ходимо сделать с помощью системы, и особенности предполагаемой функциональности, а не то, как она будет создана. Пользователям не придется вникать в объекты и классы. Однако если вы собираетесь разрабатывать систему с помощью объектно-ориентированных прие- мов, то анализ требований стоит начать с определения классов доме- нов, их атрибутов и поведения. Это упростит переход от анализа к ди- зайну, так как дизайнер сопоставляет объекты предметной области с 226 Часть II. Разработка к ПО системными объектами и детализирует атрибуты и операции класса. Стандартным языком объектно-ориентированного моделирования является унифицированный язык моделирования (Unified Language, Rumbaugh и Jacobson, 1999). На уровне ракции, который годится для анализа требований, вы можете зовать систему обозначений в диаграмме классов, как показано на рис. для вы правильно Chemical System. Дизайнер переработает эти концептуальные диаграммы сов, не зависящие от особенностей реализации, в более диаграммы классов для объектно-ориентированного дизайна и зации. Взаимодействия классов и сообщения, которыми они демонстрируют диаграммы последовательностей и диаграм- мы сотрудничества, подробно о которых рассказано в Booch, Rum- baugh; Jacobson и Lauesen (2002). На рис. 4 класса — каждый в большом прямоугольни- ке: Сотрудник, разместивший заказ на химикат, Каталог Запрос химиката и Элемент строки запроса. Вы видите, что информа- ция на этой диаграмме классов и данные на другой анализа, из тех, что показаны в этой главе, похожи — везде дается одна и та же проблема). Сотрудник, разместивший заказ на хи- микат, показан на диаграмме «сущность — связь» на рис. где он представляет действующее лицо — член класса пользователей Хими- ки или Сотрудники склада химикатов. На диаграмме а рис. также что оба эти класса могут размещать запросы химикатов. Кстати, не путайте класс пользователей и класс невзирая на схожесть названий, они не связаны собой. Атрибуты (attributes), связанные с классом Сотрудник, разместив- ший заказ на химикат, показаны в средней части прямоугольника, кото- рый обозначает их класс: имя, Номер_отдела и Но мер_офиса (правило применения заглавных букв довольно странено в диаграммах). Это свойства или элементы связанные с каждым — членом класса Сотрудник, разместив- ший заказ на химикат. Похожие атрибуты могут содержаться в опреде- лении хранилищ на диаграмме потоков данных или в данных. Операции (operations) — это службы, которые объект каждого клас- са может выполнять. Операции показаны в нижней части поля класс как правило, за ними стоят пустые скобки. На диаграмме представляющей дизайн, эти операции соответствуют функциям методам а аргумент функции часто заключен в скобки. В дели анализа класса просто должно быть показано, что Сотрудник, перейти в каталог файлов | Образовательный портал Как узнать результаты егэ Стихи про летний лагерь 3агадки для детей |
