М. Фаулер, К. Скотт - UML. Основы - 2002 (1158629), страница 12
Текст из файла (страница 12)
Слишком ранняя оптимизация затруднит последующую разработку, поэтому ее следует выполнять в последнюю очередь. Глава 2. Основы процесса разработки На стадии внедрения не следует дополнять конечный продукт новой функциональностью, кроме, может быть, самой минимальной и абсолютно необходимой. Именно на этой фазе следует выявлять ошибки. Хорошим примером фазы внедрения может служить период между выпуском бета-версии и появлением окончательной версии продукта. Когда использовать итеративную разработку Итеративную разработку следует использовать только в тех проектах, в которых вы желаете добиться успеха.
Может быть, это звучит несколько поверхностно, но с годами я становлюсь все большим сторонником использования итеративной разработки. При грамотном применении она является весьма важным методом, который может быть использован для раннего выявления риска и достижения лучшего управления процессом разработки. Однако это не означает, что можно вовсе обойтись без управления проектом (хотя, если быть справедливым, я должен отметить, что некоторые используют ее именно для этой цели). Итеративная разработка требует тщательного планирования.
Это весьма серьезный подход, и поэтому любая книга по объектно-ориентированной разработке рекомендует его использовать. Где найти дополнительную информацию Имеется довольно много специальной литературы, посвященной рассмотрению процесса. Я отдаю предпочтение двум книгам: ° Кокберн (Сос)сЬпгп), 1998 [12] проделал прекрасную работу, рассмотрев ключевые аспекты в столь небольшой книге.
Именно поэтому я рекомендую ее для первоначального знакомства с управлением объектно-ориентированными проектами. ° Мак-Коннелл (МсСоппе11), 1996 [31] представил глубокий анализ наилучших практических методов. Что касается Рационального унифицированного процесса, то дополнительная информация содержится в: ° книге Крухтена (КгисЫеп), 1999 [27], которая представляет собой краткое изложение данной темы. ° книге Джекобсона, Буча и Рамбо, 1999 [23], где процесс описан более детально. Если вас интересуют вопросы нового и еще развивающегося подхода, познакомьтесь с книгой Кента Бека (Кеп~ Вес)с), 2000 [2] по экстремальному программированию. Этот подход существенно отличается от рассматриваемого, поскольку уделяет основное внимание тестированию и развитию проекта.
См. также по адресу: /тггрт//шшш.агтагтев: сот/ехвгете./ттт. Варианты использования Варианты использования представляют собой интересный Феномен. Долгое время как в процессе объектно-ориентированной, так и традиционной разработки аналитики использовали типовые сценарии, которые помогали им лучше понять требования к системе. Однако эти сценарии трактовались довольно неФормально — постоянно используя, их редко документировали. Свою известность Айвар Джекобсон (1чаг дасоЪзоп) получил благодаря тому, что разработанный им метод ОЪ)ес$огу и посвященная этому методу книга [24) изменили зту ситуацию.
Расширив содержание вариантов использования, А. Джекобсон повысил их значимость, что позволило превратить варианты использования в основной элемент разработки и планирования проекта. Со времени публикации его книги (1992) объектное сообщество в значительной степени одобрило применение вариантов использования. Что же такое вариант использования? Прямого ответа на этот вопрос не существует. Но попытаться на него ответить можно, описав вначале сценарий. Сценарий представляет собой последовательность шагов, описывающих взаимодействие между пользователем и системой.
Таким образом, если мы рассмотрим реализованный на веб-технологии интернет- магазин, то можно представить следующий сценарий покупки товаров в этом магазине: Покупатель проснатривает каталог и понеизает выбранные товары в корзину. При желании оплатить покупку он вводит информа- 56 Глава 3. Варианты использования цию а кредитной карпючке о совершает платель система проверяет авторозацою кредитной карточки о подтверждает оплату товара тотчас псе и по электронной почте. Подобный сценарий описывает только одну ситуацию, которая может иметь место. Если авторизация кредитной карточки окажется неудачной, то подобная ситуация может послужить предметом уже другого сценария. В таком случае вариант мспользования представляет собой множество сценариев, объединенных вместе некоторой общей целью пользователя.
В нашем случае вы можете построить вариант использования вПокупка товараь, который охватывает оба сценария — как успешной оплаты, так и неудачной авторизации. Для вариантов использования могут быть и другие альтернативные кути продолжения сценариев. Часто вы можете столкнуться с тем, что вариант использования представляет самую общую ситуацию, которая включает множество альтернатив как заканчивающихся неудачей, так и приводящих к успешному завершению. Ниже представлен простой формат для записи варианта использования, в котором исходный сценарий описан в виде последовательности нумерованных шагов, а альтернативы могут изменять эту последовательность (рис. 3. 1).
Покупка товара 1. Покупатель просматривает каталог и выбирает товары для покупки. 2. Покупатель оценивает стоимость всех товаров. 3. Покупатель внодит информацию, необходимую для доставки товара (адрес, доставка на следующий день или в течение трех дней). 4. Система предоставляет полную информацию о цене товара и его доставке. 6. Покупатель вводит информацию о кредитной карточке. 6. Система осуществляет авторизацию счета покупателя. 7. Система выполняет немедленную оплату товаров. 8. Система подтнерждавт оплату товаров для покупателя по адресу его электронной почты.
Альтернатива: Неудача авторизации На шаге 6 система получает отрицательный отнег ва запрос о состоянии счета покупателя. Необходимо предоставить покупателю возможность повторно ввести информацию о кредитной карточке и ныполннть ее авторизацию. Альтернатива: Постоянный покупатель За. Система предоставляет информацию о текущей покупке и ее цене, а также последние 4 цифры информации о кредитной карточке. 36. Покупатель может согласиться нли отказаться от предложенной системой информации. После этого перейти иа шаг 6 исходного сценария.
Рис. 3.1. Текст примера варианта использования Существует множество способов записи содержания вариантов использования; язык ПМ1. в этом смысле не определяет никакого стан- Диаграммы вариантов использования дарта. При этом вы можете добавить в вариант использования дополнительные секции. Например, можно ввести дополнительную секцию для предусловий, выполнение которых является обязательным для того, чтобы началась реализация отдельного варианта использования.
Просмотрите несколько книг, в которых рассматриваются варианты использования, и дополните свой вариант теми элементами, которые имеют для вас значение. Однако не включайте в вариант ничего лишнего, что не сможет оказать вам реальную помощь. Приведем важный пример того, как могут уточняться варианты использования. Рассмотрим другой сценарий покупки в интернет-магазине, при котором покупатель уже известен системе как постоянный покупатель.
Некоторые аналитики будут рассматривать эту ситуацию как третий сценарий, в то время как другие выделят ее в отдельный вариант использования. Вы можете также применить одно из отношений между вариантами использования, которые будут описаны позже. Количество деталей в сценарии зависит от риска в соответствующем варианте использования: чем больше риск, тем больше деталей необходимо указать. Часто случается так,что на фазе исследования я детально описываю только небольшое количество вариантов использования, в то время как остальные из них содержат не больше информации, чем вариант использования на рис. 3.1.
В процессе итерации вы можете добавить в вариант использования больше деталей, если они необходимы для его реализации. При этом можно не записывать все детали явным образом; часто очень эффективно их вербальное понимание. Диаграммы вариантов использования Когда А. Джекобсон в 1994 г. [241 предложил варианты использования в качестве основных элементов процесса разработки программного обеспечения, он ввел также диаграмму для их наглядного представления. Диаграмма вариантов использования в настоящее время также является частью языка 11М1. Многие аналитики находят такую диаграмму полезной. Однако нет необходимости рисовать эту диаграмму при описании вариантов использования.
В одном из наиболее удачных из известных мне проектов каждый вариант использования записывался на отдельной помеченной карточке, которые впоследствии раскладывались по пачкам, чтобы показать, что необходимо выполнять на каждой итерации. На рис. 3.2 показаны некоторые варианты использования для финансовой торговой системы (трейдинг). Глава 3. Варианты использования Система счетов ввиевтов по Рис. 3.2. Диаграмма вариантов использования Актеры Актер представляет собой некоторую роль, которую играет пользователь по отношению к системе.
На рис. 3.2 представлены 4 актера: менеджер по продажам, трейдер (оптовый торговец), продавец и система счетов клиентов. (Да, я знаю, что было бы лучше использовать слово «роль», но, по всей видимости, имел место неточный перевод со шведского языка.) Вероятно, в конкретной организации будет много трейдеров, но все они по отношению к системе играют одну и ту же роль. Отдельный пользователь может играть и более одной роли. Например, один из старших трейдеров может играть роль менеджера по продажам и являться при этом постоянным трейдером. Трейдер может быть также продавцом. Когда имеешь дело с актерами, важно думать о ролях, а не о людях или их работе. Актеры связаны с вариантами использования.
Один актер может выполнять несколько вариантов использования; в свою очередь, у варианта использования может быть несколько актеров, которые его выполняют. Я пришел к выводу, что на практике актеры наиболее полезны при попытке сформулировать варианты использования. В случае большой системы часто трудно определить список вариантов использования. В подобной ситуации бывает кроше сначала перечислить всех актеров, Диаграммы вариантов использования после чего для каждого из них попытаться разработать варианты ис- пользования.
Актеры не обязаны быть людьми, хотя на диаграмме вариантов использования они изображаются в виде стилизованных человеческих фигурок. Отдельный актер может быть даже внешней системой, которой необходима некоторая информация от разрабатываемой системы. На рис. 3.2 мы можем видеть подобную ситуацию при необходимости обновления состояния счетов для системы счетов клиентов.
Существует несколько вариантов изображения актеров. Некоторые разработчики на диаграмме вариантов использования указывают каждую внешнюю систему или пользователя как актера; другие предпочитают указывать только инициатора варианта использования. Я предпочитаю изображать актера, который получает от варианта использования некоторую информацию или сервис, при этом некоторые разработчики считают таких актеров первичными. Однако я далек от подобной точки зрения. В связи с этим вынужден заметить, что хотя система счетов клиентов получает сервис от разрабатываемой системы, на диаграмме вариантов использования не показывается тот факт, что кто-либо из актеров может получать информацию от самой системы счетов клиентов. Эту ситуацию следует представить при разработке модели собственно системы счетов клиентов. Другими словами, вам следует всегда подвергать сомнению взаимосвязи вариантов использования с актерами системы, выясняя истинные цели пользователей и рассматривая альтернативные пути достижения этих целей.
В процессе работы с актерами и вариантами использования я не очень беспокоился о том, насколько точно установлены отношения между ними. Большую часть времени я посвящал вариантам использования; актеры же являлись лишь средством для их получения. Пока не выявлялись все варианты использования, меня не интересовало детальное описание актеров. Иногда все же встречаются ситуации, когда, возможно, следует больше внимания уделять актерам. ° Для различных видов пользователей может потребоваться переконфигурация системы.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
