М. Фаулер, К. Скотт - UML Основы (1114905), страница 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 актера: менеджер по продажам, трейдер (оптовый торговец), продавец и система счетов клиентов. (Да, я знаю, что было бы лучше использовать слово «роль», но, по всей видимости, имел место неточный перевод со шведского языка.) Вероятно, в конкретной организации будет много трейдеров, но все они по отношению к системе играют одну и ту же роль. Отдельный пользователь может играть и более одной роли. Например, один из старших трейдеров может играть роль менеджера по продажам и являться при этом постоянным трейдером.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
