Application Object Modeling Using Um l

Применение объектного моделированияс использованием UML и анализ прецедентов

на примере книжного Internet�магазина

Дуг РозенбергКендалл Скотт

Applying UseCase Driven

Object Modelingwith UML

An Annotatede�Commerce Example

Doug RosenbergKendall Scott

Boston • San Francisco • New York • Toronto • MontrealLondon • Munich • Paris • Madrid

Capetown • Sydney • Tokyo • Singapore • Mexico City

Серия «Объектно�ориентированные технологиив программировании»

Москва

Применениеобъектного

моделированияс использованием

UML и анализпрецедентов

на примерекнижного Internet�магазина

Дуг РозенбергКендалл Скотт

УДК 004.415.2ББК 32.973.26�018.1

Р64

Розенберг Д., Скотт К.Р64 Применение объектного моделирования с использованием UML и анализ

прецедентов: Пер. с англ. – М.: ДМК Пресс. – 160 с.: ил. (Серия «Объектно�ориентированные технологии в программировании»).

ISBN 5�94074�050�2

Данная книга представляет собой руководство по применению преце�дентов. Практические вопросы проиллюстрированы на примере разработ�ки книжного Internet�магазина.

В книге описывается процесс ICONIX – методология, основанная на язы�ке UML, которая поможет вам избавиться от «аналитического паралича», нежертвуя при этом анализом и проектированием. Представлены четыре основ�ных этапа проектирования на основе прецедентов: моделирование предмет�ной области, моделирование прецедентов, анализ пригодности и построениедиаграмм последовательности. Приводится обзор каждой темы, подробноеобсуждение, перечень характерных ошибок и ряд упражнений, предназначен�ных для самостоятельного поиска и исправления недочетов.

Авторы показывают на конкретных примерах, как можно избежать ти�пичных ошибок проектирования. Располагая этой информацией, читательприобретет знания и навыки, необходимые для применения моделированияна основе прецедентов.

Все права защищены. Любая часть этой книги не может быть воспроизведена в какой бы тони было форме и какими бы то ни было средствами без письменного разрешения владельцевавторских прав.

Материал, изложенный в данной книге, многократно проверен. Но, поскольку вероятностьтехнических ошибок все равно существует, издательство не может гарантировать абсолютнуюточность и правильность приводимых сведений. В связи с этим издательство не несет ответ�ственности за возможные ошибки, связанные с использованием книги.

ISBN 0�201�73039�1 (англ.) © Addison�WesleyISBN 5�94074�050�2 (рус.) © Перевод на русский язык, оформление

ДМК Пресс

Authorized Translation from the English language edition, entitled Applying Use CaseDriven Object Modeling with UML: An Annotated e�Commerce Example, 1st Edition byROSENBERG, DOUG and KENDALL, SCOTT, published by Pearson Education, Inc,publishing as Addison�Wesley, Copyright © by Addison�Wesley.

All rights reserved. No part of this book may be reproduced or transmitted in any formor by any means, electronic or mechanical, including photocopying, recording or by anyinformation storage retrieval system, without permission from Pearson Education, Inc.

Содержание

Предисловие .............................................................................. 7

Глава 1. Введение в ICONIX ................................................ 12

Краткий обзор процесса ICONIX ................................................. 13

Особенности процесса ICONIX ................................................... 22Базовые принципы ..................................................................... 23

Краткое описание основных этапов процесса ............................ 24Требования к книжному Internet�магазину .................................. 25

Глава 2. Моделирование предметной области ........... 28

Основные элементы моделирования предметной области ......... 29

10 самых распространенных ошибокпри моделировании предметной области – Top 10 ..................... 31Упражнения ................................................................................ 34

Модель предметной области ...................................................... 45

Глава 3. Моделирование прецедентов ........................... 47

Основные элементы моделирования прецедентов ..................... 4810 самых распространенных ошибокпри моделировании прецедентов – Top 10 ................................. 50

Упражнения ................................................................................ 54Готовая диаграмма прецедентов ................................................ 65

Глава 4. Рецензирование требований ............................ 66

Основные элементы рецензирования требований ...................... 67

10 самых распространенных ошибокпри рецензировании требований – Top 10 .................................. 69

Глава 5. Анализ пригодности ............................................. 74

Основные элементы анализа пригодности ................................. 7610 самых распространенных ошибокпри анализе пригодности – Top 10 .............................................. 79

Объектное моделирование с использованием UML6

Упражнения ................................................................................ 82

Модель предметной области с атрибутами классов ................... 93

Глава 6. Рецензированиепредварительного проекта ................................................. 94

Основные элементы рецензированияпредварительного проекта ......................................................... 9510 самых распространенных ошибокпри рецензировании предварительного проекта – Top 10 .......... 97

Глава 7. Диаграммы последовательности .................. 101

Основные элементы диаграмм последовательности ................ 101

Введение в диаграммы последовательности ............................ 10410 самых распространенных ошибокпри составлении диаграмм последовательности – Top 10 ........ 106

Упражнения .............................................................................. 110Диаграммы классов уровня проектирования ............................ 123

Глава 8. Рецензированиеокончательного проекта ..................................................... 124

Основные элементырецензирования окончательного проекта ................................. 12410 самых распространенных ошибокпри рецензировании окончательного проекта – Top 10 ............. 129

Приложение. Отчет по взглядус точки зрения прецедентов ............................................. 133

Модель прецедентов. Документация по прецедентам .............. 133

Литература .............................................................................. 152

Предметный указатель ....................................................... 154

ПредисловиеВ первой своей книге, «Use Case Object Modeling with UML», мы отмеча�ли, что разница между теорией и практикой состоит в том, что теоретичес�ки такой разницы быть не должно, а практически она существует. В дан�ной работе мы попытались свести теорию объектно�ориентированногомоделирования к некоему полезному подмножеству, которое можно легкоизучить и применять для решения широкого круга задач. В основе книги –наш опыт преподавания (примерно с 1993 года) этого материала людям,работавшим над сотнями разнообразных проектов.

За два года книга выдержала уже пять изданий. Но, хотя наш труд по�лучил лестную оценку, нам кажется, что работа еще не доведена до конца.Довольно часто на протяжении последних двух лет нам приходилось слы�шать, что «нужно больше примеров прецедентов и моделирования на UML».А поскольку мы пользовались первой книгой как основой для проведениясеминаров, на которых применяли теорию к реальным проектам, сталоясно, что исключительно важная и плохо понимаемая тема – критическийанализ или рецензирование (reviewing) моделей.

Поэтому, несмотря на то что в нашей первой книге приведен разверну�тый пример, мы убедили издательство Addison�Wesley выпустить продолже�ние, в котором очень подробно, шаг за шагом рассматриваем проектирова�ние книжного Internet�магазина. Это позволило нам продемонстрироватьмногие распространенные ошибки и показать фрагменты моделей, в кото�рых эти ошибки устранены. Мы выбрали именно такую разработку, по�скольку в ней сконцентрированы особенности, присущие многим проек�там в современном мире, пронизанном «Всемирной паутиной». Кроме того,данный пример мы использовали во многих семинарах, так что в нашем рас�поряжении оказалось множество учебных моделей на языке UML и, естест�венно, большая коллекция ошибок, которые часто совершают студенты.

Эту книгу мы посвящаем памяти Тома Джонсона(Tom Johnson), который побуждал нас вести семина�

ры, давшие материал для этого издания. Безвре�менная кончина Тома в момент, когда подготовкарукописи уже близилась к завершению, опечалила

всех, кто его знал. Нам будет его не хватать.

Предисловие8

Мы отобрали некоторые из наших «любимых» ошибок, которые повто�рялись снова и снова, и шаг за шагом проанализировали их. Затем добави�ли еще три главы, посвященные рецензированию требований, предвари�тельного проекта и окончательного проекта.

От других изданий эта книга отличается, прежде всего, тем, что чита�тель учится исправлять допущенные при разработке недочеты.

Структура книги и соглашенияВ главе 1 мы приводим обзор процесса ICONIX, а в следующих четырехболее подробно рассматриваем четыре основных этапа этого процесса. Всеэти главы строятся по одному принципу:

в первом разделе описывается суть вопроса – моделирования пред�метной области (глава 2), моделирования прецедентов (глава 3), ана�лиза пригодности (глава 5) или построения диаграмм последователь�ности (глава 7). Показано, как излагаемый материал соотносится совсем процессом. В каждой главе вам предлагается проработать от�дельные фрагменты примера книжного Internet�магазина, а в завер�шение приводится диаграмма, в которой эти фрагменты объединены.В главе 3 мы рассмотрим «кусочки» десяти разных прецедентов; пятьиз них послужат предметом предварительного и детального проек�тирования в главах 5 и 7 соответственно. Фрагменты диаграмм клас�сов, впервые появляющиеся в главе 2, также будут развернуты дотекстового описания прецедента и полной диаграммы классов в гла�вах 5 и 7;в следующем разделе описываются основные элементы рассматрива�емого этапа. При этом в сжатом виде излагается материал соответст�вующей главы из книги «Use Case Object Modeling with UML», а так�же приводится некоторая дополнительная информация;далее мы рассматриваем десять самых распространенных ошибок,которые наши студенты допускали во время работы на семинарах.В каждую из трех глав, посвященных рецензированию, мы включи�ли соответствующие перечни: десять ошибок при анализе пригоднос�ти, при построении диаграмм последовательности и т.д.;напоследок предлагается цикл из пяти упражнений для самостоя�тельной работы. В ходе их выполнения вы можете проверить степеньусвоения материала.

У всех циклов упражнений есть общие черты:

упражнения, посвященные моделированию предметной области и пре�цедентам, пронумерованы. В упражнениях на анализ пригодности

9

и диаграммы последовательности указывается название прецедента(чуть позже мы объясним смысл такого соглашения);в одном упражнении из каждой пары допущено три или четыре ошиб�ки. Все они помечены на рисунке значком с надписью «Top 10». Циф�ра на этом значке показывает, какое правило нарушено;название упражнения, содержащего ошибки, сопровождается знаком ,а название правильного варианта, идущего следом, – знаком ;

В вашу задачу входит исправление ошибок, обнаруженных в первомупражнении из каждой пары.

Помимо этого в книге приняты следующие соглашения:

смысловые выделения в тексте обозначены курсивом;на рисунках серым цветом выделены исправления ошибок, допущен�ных студентами и отмеченных значками с надписью «Top 10» на пре�дыдущих рисунках.

Подведем итоги. В главе 2 описаны классы, которые будут использовать�ся в десяти выбранных прецедентах. Их фрагменты представлены в главе 3.В главах 5 и 7 приведены диаграммы, соответствующие пяти различнымпрецедентам. Идея состоит в том, чтобы пройти все стадии от частичногопонимания каждого прецедента через диаграммы последовательности доассоциированных с ними элементов детального проекта.

В главе 4 описана процедура рецензирования требований, в результатепроведения которой следует удостовериться, что прецеденты и модельпредметной области правильно описывают функциональные требованиязаказчика.

В главе 6 рассказывается о том, как выполнять рецензирование предва�рительного проекта, которое позволяет вам убедиться в наличии диаграммпригодности для всех прецедентов (и в их согласованности с прецедента�ми), а также в том, что модель предметной области обладает развитым на�бором атрибутов, достаточным для описания всех имеющихся прототипов(и всех объектов, которые необходимы прецедентам, представленным в мо�дели). Наконец, необходимо удостовериться, что команда разработчиковготова приступить к детальному проектированию.

Глава 8 посвящена рецензированию окончательного проекта. На этойстадии необходимо гарантировать, что реализация (как), представленнаяв детальном проекте, соответствует спецификации (что), описанной с по�мощью прецедентов. Кроме того, нужно убедиться, что детальный проектпроработан в достаточной степени, и таким образом исключить серьезныепроблемы при переходе к кодированию.

В главах 4, 6, 8 представлены общий обзор проблемы, детальный ана�лиз и перечень десяти самых распространенных ошибок, но упражнения

Структура книги и соглашения

Предисловие10

отсутствуют. Цель, общая для всех трех видов рецензирования, состоит в том,чтобы удостовериться в согласованности различных частей модели в соот�ветствии с принципами, продемонстрированными на правильных диаграм�мах в упражнениях из других глав.

В приложении содержится сводный отчет о модели нашего книжного ма�газина. Полную модель можно загрузить со страницы http://www.iconixsw.com/WorkbookExample.html. В приложении отражены все диаграммы, встре�чающиеся в книге, а полная модель включает также все детали пяти преце�дентов, оставшихся нерассмотренными. Проработку этих прецедентов мож�но рассматривать как дополнительное упражнение. Полученные результатывы можете сравнить с нашим решением, и мы настоятельно рекомендуемтак и поступить.

Ну что, нравится перспектива? Нам не попадались другие книги такогоже плана. Надеемся, что сумеем помочь вам в освоении объектного модели�рования на основе анализа прецедентов.

БлагодарностиДуг благодарит отважную команду, работающую над проектом ICONIX,в особенности Андреа Ли (Andrea Lee) за сценарий компакт�диска, посвя�щенного процессу ICONIX, из которого мы многое позаимствовали дляглавы 1, а также Криса Старчака (Chris Starczak), Джеффа Кантора (Jeff Kan�tor) и Эрина Арнольда (Erin Arnold). Еще Дуг благодарит Кендалла за то,что он, в конце концов, снисходил до просьб соавтора, говоря: «да, это дей�ствительно улучшит книгу» и «да, у нас есть время это добавить», и к томуже согласился с тем, что, поскольку буква Р предшествует букве С, мнениег�на Розенберга имеет приоритет над мнением г�на Скотта1.

Дуг и Кендалл признательны Полу Беккеру (Paul Becker) и всем со�трудникам издательства Addison�Wesley, включая Росса Венабля (Ross Ve�nables) – он там уже не работает, но начинал этот проект, – которым удалосьмаксимально сократить график запуска в производство, компенсировавтем самым задержки на стадии написания книги (все Кендалл виноват).Мы также выражаем благодарность рецензентам рукописи, особенно Мар�ку Вудбери (Mark Woodbury), чьи язвительные замечания по поводу «де�фрагментации» привели к тому, что книга стала, по нашему мнению, блестя�щей, а не просто «классной». И еще мы благодарим Грега Вилсона (GregWilson), который писал рецензию на нашу первую книгу для журнала «Dr.Dobbs’ Journal». Идея ему понравилась, и он предложил написать продол�жение. Если быть точными, вот его слова: «Никогда не думал, что выскажу

1 Надо бы мне официально поменять имя на Скотт Кендалл, будет тогда знать! – Прим.соавтора.

11

такую претензию к книге, но... она слишком короткая! Наконец�то я нашелдействительно полезное, приятное для чтения и применимое на практикеописание методологии разработки, в основе которой лежит проектирова�ние. И мне хочется видеть десяток, а то и поболее примеров на каждуютему. Если авторы напишут продолжение, обещаю, что хотя бы один поку�патель будет».

И наконец, Кендалл благодарит Дуга за то, что он поднял искусствобыть всем недовольным на такую высоту, что на этом фоне Кендалл сталвыглядеть эталоном благодушия.

Äóã Ðîçåíáåðã Êåíäàëë ÑêîòòÑàíòà Ìîíèêà, øòàò Êàëèôîðíèÿ Õàððèñîí, øòàò ÒåííåññèÌàé 2001 Ìàé [email protected] [email protected]://www.iconixsw.com http://www.usecasedriven.com

Благодарности

Глава 1. Введение в ICONIXПроцесс ICONIX представляет собой нечто среднее между очень громозд�ким рациональным унифицированным процессом (Rational Unified Pro�cess – RUP) и весьма компактной методологией программирования eX�treme (XP). Процесс ICONIX, как и RUP, основан на прецедентах, но нехарактеризуется множеством его недостатков. В этом процессе тоже при�меняется язык моделирования UML (Unified Modeling Language), одна�ко основное внимание уделяется анализу требований. Отметим еще раз,что ICONIX, по представлению Айвара Джекобсона (Ivar Jacobson), «ос�нован на прецедентах», вот почему с помощью этого процесса создаютсявполне конкретные и простые для понимания прецеденты, которые легкоиспользовать для разработки системы.

ICONIX вобрал в себя лучшие стороны трех методологий, разработан�ных в начале 90�х годов Айваром Джекобсоном, Джимом Рамбо (Jim Rum�baugh) и Грейди Бучем (Grady Booch), называющими себя «три амиго».Мы пользуемся подмножеством языка UML, отобранным в результатепроведенного Дугом анализа этих методологий.

В главе 32 руководства по языку UML, «The Unified Modeling Lan�guage User Guide», говорится: «80% всех задач можно промоделироватьс помощью 20% UML». Однако в книге нет ни слова о том, что это задвадцать процентов. В подмножество UML мы включили ту базовую но�тацию, которой должно хватить для большинства моделей. В соответ�ствующих разделах мы поясняем, как можно использовать другие эле�менты UML и при каких обстоятельствах они уместны.

Один из наших любимых афоризмов гласит: «разница между теориейи практикой состоит в том, что теоретически этой разницы не должнобыть, а практически она существует». В практической работе никогда нехватает времени для моделирования, анализа и проектирования. Руковод�ство всегда требует быстрого перехода к кодированию, поскольку степеньзавершенности программных проектов традиционно оценивается по ко�личеству написанных строк. Мы придерживаемся минималистского под�хода, обращая особое внимание на область между прецедентами и кодом.Мы хотим показать, что должно происходить в той точке жизненного цик�ла проекта, в которой вы начинаете работу: у вас уже есть несколько пре�цедентов и необходимо заняться анализом и проектированием.

13

Наша цель – выявить минимальное подмножество UML (и методоло�гии моделирования в широком смысле), которого было бы достаточно дляработы над программным проектом. Мы уточняем наше определение тако�го «минимально достаточного» подмножества на протяжении восьми илидаже девяти лет. Подход, описываемый в этой книге, выдержал проверкуна сотнях проектов и может применяться в разнообразных предметныхобластях и при разных способах организации работы.

Краткий обзор процесса ICONIXНа рис. 1.1 показан главный вопрос, на который должен ответить процессICONIX.

Код

Модель

прецедентов

???

A B

Как перейти от прецедентов к коду?

Рис. 1.1. Прецеденты, подлежащие кодированию

Краткий обзор процесса ICONIX

Наша задача – показать, как попасть из точки A в точку B за кратчай�шее время. (На самом деле мы не собираемся проходить весь путь до полу�чения готового кода, но того, что мы сделаем, будет достаточно для пони�мания смысла происходящего.) Можно считать, что точка A соответствуетмоменту, когда у вас сложилось представление о том, что должна делатьсистема, и пора сформулировать кое�какие прецеденты. А в точке B имеет�ся готовый, протестированный и отлаженный код, который делает то, чтоописано в прецедентах. Иными словами, код реализует требуемое поведе�ние, определенное с помощью прецедентов. В этой книге основное внима�ние уделяется тому, как перейти от расплывчатых и неоднозначных фразтипа «думается, что это должно работать примерно так» к недвусмыслен�ным, полным и четким формулировкам, на основе которых можно выстро�ить архитектуру, спроектировать надежную программу и написать краси�вый код, реализующий пожелания заказчика.

Мы начнем с кода и отправимся вспять, комментируя шаги, ведущиек достижению поставленной цели. Постараемся пояснить, почему предла�гаемый набор этапов минимален и в большинстве случаев достаточен дляосуществления перехода между прецедентами и кодом. На рис. 1.2 пере�числены три исходных предположения:

Введение в ICONIX14

уже проведены работы по созданию прототипа;уже есть некоторые представления об интерфейсе пользователя;возможно, уже выявлены некоторые сценарии или прецеденты в сис�теме.

Прототип

графического

интерфейса

пользователя

Код

Модель


?

Рис. 1.2. В начале пути

После этого можно приступать к анализу и проектированию. Пробле�ма в том, как добраться из данной точки до готового кода. В начале путиу нас есть лишь один главный вопрос: «Что должна делать система?».

В объектно�ориентированных системах структура кода определяетсяклассами. Поэтому, прежде чем приступать к кодированию, нужно выяс�нить, какие классы понадобятся. С этой целью следует нарисовать однуили несколько диаграмм классов. Для каждого класса необходимо описатьвсе атрибуты, то есть данные�члены, и операции, которые представляютсобой функции программы. Другими словами, мы должны идентифициро�вать все функции и удостовериться, что у нас есть данные, с которыми этифункции должны работать.

Нужно будет показать, как функции и данные инкапсулируются в клас�сах. Для иллюстрации способов организации и взаимодействия классовбудут использоваться диаграммы, а точнее, имеющиеся в UML диаграммыклассов. В конечном счете мы намерены получить очень детальные диа�граммы классов уровня проектирования. Говоря об уровне проектирования,мы имеем в виду такой уровень детализации, при котором диаграмма клас�са может служить шаблоном для создания кода; она должна точно отра�жать организацию будущей программы.

На рис. 1.3 показано, что создание диаграмм классов предшествует ко�дированию. Из рисунка видно, что классы на диаграмме и классы в кодесоответствуют друг другу. Теперь возникает другая проблема – нужно

15

Прототип




Код

Диаграмма

классов

Модель


?

Рис. 1.3. Отображение диаграмм классов на структуру кода


как�то перейти от прецедентов к диаграммам классов уровня проектиро�вания.

Один из самых сложных вопросов при разработке объектно�ориенти�рованных программ заключается в распределении поведения, что подразу�мевает определение функций, из которых будет состоять программа. Нуж�но также решить, какому классу должна принадлежать каждая функция.Требуется распределить поведение всей системы, то есть отнести каждуюфункцию к определенному проектируемому классу.

В UML для этой цели лучше всего подходят диаграммы последователь�ности – идеальное средство для принятия решений о распределении по�ведения. Диаграммы последовательности разрабатываются отдельно длякаждого сценария и показывают, какой объект отвечает за ту или инуюфункцию. На диаграмме последовательности видно, что экземпляры объ�ектов взаимодействуют путем обмена сообщениями. Каждое сообщениеприводит к вызову той или иной функции объекта�получателя. Именнопоэтому она прекрасно выполняет задачу визуализации распределенияповедения.

На рис. 1.4 расстояние между прецедентами и кодом стало заметноменьше. Осталось перейти от прецедентов к диаграммам последователь�ности.

Решения о приписывании поведения классам принимаются по мере соз�дания диаграмм последовательности. В результате мы должны определитьоперации классов. При работе с такими программами визуального моде�лирования, как Rational Rose или GDPro, рисование направленных линий,соответствующих сообщениям, означает, по сути дела, создание операций


классов, изображаемых на диаграммах классов. Инструментарий автома�тически распределяет поведение на основе диаграмм последовательности.По мере их рисования в диаграммах классов появляются операции.

Итак, вся сложность в том, как перейти от прецедентов к диаграммампоследовательности. В большинстве случаев это непростая задача, так какпрецеденты описывают систему на уровне требований, а диаграммы по�следовательности дают детальное представление с точки зрения проекти�рования. Этим�то и отличается наш подход от разработок других авторов.В других методиках много говорится и о прецедентах, и о диаграммах по�следовательности, но не уточняется, как преодолеть расстояние между ни�ми. Именно преодоление пропасти между «что» и «как» – центральнаятема в процессе ICONIX.

Следующий этап – переход от нечетких формулировок прецедентак очень точным и детальным диаграммам последовательности. Для этогослужат диаграммы пригодности. Они упрощают процесс перехода.

Если вы изучали литературу по UML, то наверняка знаете, что перво�начально диаграммы пригодности были включены в этот язык лишь час�тично. Они появились в работе Айвара Джекобсона и были утвержденыв стандарте UML как дополнения. Это связано с историей о том, как Бучи Джекобсон решили объединить свои методики. Важность этого вида диа�грамм для моделирования никоим образом не оспаривается.

В верхней части диаграммы последовательности размещается множест�во объектов, участвующих в данном сценарии. Перед тем как рисовать диа�грамму последовательности, нам надо, в частности, обдумать, какие объекты

Прототип




Код

Диаграмма

классов

Модель

прецедентов Диаграмма

последовательности

?Рис. 1.4. Диаграммы последовательности помогают распределить операции

(поведение) между классами

17

понадобятся. Неплохо было бы также иметь представление о выполняемыхими функциях. Работая над диаграммой последовательности, мы будемразмышлять о том, как отобразить множество функций, реализующих тре�буемое поведение, на множество участвующих в сценарии объектов.

Целесообразно заранее знать о том, какие объекты нужны и какие функ�ции они будут выполнять. Когда вы решаете эту задачу во второй раз, торезультат получается намного лучше, чем в первый раз. Принятый намипроцесс по существу совпадает с вариантом, предложенным в работе Ай�вара Джекобсона, и состоит в том, чтобы учесть наш предварительный про�ект, который изображается на диаграмме пригодности. Затем эти пред�варительные идеи эволюционируют до детального проекта, изображаемогона диаграмме последовательности. Диаграммы последовательности стро�ятся для каждого известного сценария.

На рис. 1.5 мы добавили новый вид диаграмм в подмножество UML.Диаграммы пригодности были описаны в оригинальных спецификацияхUML, но это определение включено в дополнительный документ под на�званием «Objectory Process�Specific Extensions». За прошедшие десять летмы обнаружили, что перейти от прецедентов к диаграммам последова�тельности без этого механизма очень сложно. Применение диаграмм при�годности помогает решить проблему, характерную для многих коллекти�вов, в которых тщательным образом обсуждают прецеденты, но ни на шаг

Прототип




Код

Диаграмма

классов

Модель



Диаграмма

пригодности

?Рис. 1.5. Диаграммы пригодности служат связующим звеном

между требованиями и детальным проектом



не продвигаются в проектировании программы. Воспользовавшись этимэтапом, вы существенно упростите работу над проектом. Мы не изобре�тали анализ пригодности, но советуем своим читателям не забывать о нем.Анализ пригодности – незаменимое средство для осуществления перехо�да между требованиями и проектом.

Анализ пригодности занимает место между тем, что система должнаделать, и тем, как этого достичь. Переход от одного к другому подразуме�вает одновременное выполнение нескольких видов деятельности. Сначаланадо выявить объекты, о которых мы забыли на первом этапе проектиро�вания системы. Возможно, прослеживая потоки данных на диаграммахпригодности, мы придем к выводу, что в классы надо добавить некоторыеатрибуты. Немаловажно еще и то, что по результатам работы над диаграм�мой пригодности мы уточняем словесное описание прецедента.

Но один вопрос пока остается открытым. И относится он как раз к про�блеме выявления объектов, позабытых при первой попытке спроектиро�вать систему.

Чтобы научить людей правильной работе с прецедентами, мы часто по�вторяем магическую фразу: «описывайте использование системы в контек�сте объектной модели». Прежде всего это означает, что мы не будем тратитьвремя на написание неоднозначных, туманных, абстрактных прецедентов,которые не содержат деталей, необходимых для вывода проекта програм�мы. Задача авторов этой книги – научить читателей составлять прецеден�ты так, чтобы они были точными и недвусмысленными. При обсуждениипрецедентов мы ставим перед собой вполне конкретную цель: из них дол�жен получиться проект программы. Во многих книгах на данную тему пре�цеденты рассматриваются скорее как абстрактное средство изучения тре�бований. Мы же придерживаемся другой точки зрения, поскольку нашацель – помочь читателям перейти от прецедентов к коду.

Начнем с так называемой модели предметной области. Это своего родасловарь основных абстракций, то есть самых важных существительныхв пространстве задачи. Если, к примеру, предметной областью являетсяэлектронная коммерция, как в этой книге, то, вероятно, в словарь войдутпонятия «каталог» и «заказ на покупку». Существительные, которые опи�сывают понятия из предметной области, будут называться доменными объ�ектами. В самом начале анализа и проектирования мы создадим модельпредметной области, в которой все доменные объекты будут изображенына одной большой диаграмме классов.

На диаграммах пригодности мы будем использовать граничные объек�ты. К ним относятся, например, мониторы, с помощью которых ведетсяработа с системой. В тексте наших прецедентов мы будем явно ссылаться

19

и на доменные, и на граничные объекты, описывать, как пользователь вза�имодействует с монитором, а монитор – с доменными объектами, которыечасто отображаются на базу данных, скрытую за объектно�ориентирован�ной частью системы. Текст прецедента будет намного яснее и конкретнее,если придерживаться следующей рекомендации: описание способов ра�боты с системой надо вести в контексте эволюционирующей объектноймодели.

При моделировании предметной области мы хотим выявить наиболееважные абстракции, описывающие пространство задачи или, что то же са�мое, предметную область создаваемой системы. Для этого воспользуемсяметодологией OMT (Object Modeling Technique), разработанной ДжимомРамбо, в которой очень подробно рассматриваются разные полезные при�емы, применяемые при создании модели предметной области.

Разница между нашим подходом и некоторыми другими, также осно�ванными на прецедентах, заключается в том, что мы считаем принципи�ально важным начинать весь процесс с моделирования предметной облас�ти. Употребление в текстах прецедентов существительных, характерныхдля предметной области, то есть использование словаря модели, позволяетустранить неоднозначность терминологии. Особенно полезен такой под�ход в ситуации, когда над задачей работает коллектив, состоящий из не�скольких групп специалистов, занятых описанием сценариев в разныхчастях системы. Если выработать единое соглашение о наиболее важныхтерминах, то можно избавиться от массы двусмысленностей в моделях пре�цедентов. Так, не возникнет расхождений в понимании того, что такое за�каз на покупку, строка заказа и покупательская корзина. Все это определе�но на первом этапе, поскольку словарь терминов был создан еще до началаработы над прецедентами.

В терминологии UML модель предметной области – это, по сути дела,диаграмма классов. Обычно в этой модели мы опускаем большую часть де�талей, в частности атрибуты и операции классов. Вот почему можно счи�тать, что модель предметной области является сводной диаграммой классов.На самом деле это первый шаг к получению настоящей диаграммы классов,при котором мы стараемся представить систему в целом. Затем в процессеработы над прецедентами мы будем постепенно уточнять эту диаграммуи в конце концов получим детальную статическую модель системы.

На рис. 1.6 показано, как перейти от прецедентов и прототипов, изоб�раженных в левой части, к диаграммам классов уровня проектированияи исходному коду в правой части.

Таким образом, наш подход не слишком замысловат. Мы пользуем�ся только четырьмя видами UML�диаграмм из девяти возможных. Как



правило, для большинства проектов вполне хватает менее половинывозможностей UML. Если вы сосредоточитесь на базовом подмножест�ве диаграмм, то сможете быстрее научиться созданию моделей средства�ми UML.

Мы будем отталкиваться от модели предметной области, которая пред�ставляет собой диаграмму классов аналитического уровня, – первое при�ближение к статической структуре системы. Затем начнем постепенно ееобогащать, стремясь к получению детального проекта. Диаграмма классов,изображенная в нижней половине рис. 1.6, – это статическое описаниеорганизации кода, тогда как прецеденты описывают динамическое поведе�ние системы во время выполнения.

Свои первые представления о системе мы зафиксируем в виде стати�ческой модели, после чего займемся исследованием различных прецедентов.При проработке каждого из них мы будем что�то добавлять в диаграммуклассов. После рассмотрения всех сценариев, которые должна поддержи�вать система, добавления необходимых деталей и повторного рецензиро�вания результата должен получиться проект, удовлетворяющий всем тре�бованиям. После этого можно приступать к написанию кода.

На рис. 1.7 представлена укрупненная схема процесса ICONIX. Этотрисунок повторяется в начале каждой главы нашей книги. Он состоит из

Прототип




Код

Диаграмма

классов

Статическаямодель

Модель

предметной

области

Модель



Диаграмма


Рис. 1.6. Ссылка на доменные объекты по именипомогает избежать неоднозначности прецедентов

21

двух частей: сверху изображена динамическая модель, описывающая по�ведение, а снизу – статическая, описывающая структуру.

Начнем с создания прототипов, которые достаточно просто нарисоватьна экране. Затем, заручившись поддержкой потенциальных пользователейв правильности выбранного пути, нанесем прецеденты на диаграмму, стре�мясь показать все сценарии, которые должна выполнять система. Далееприступим к словесному описанию прецедентов. Тексты будут уточнятьсяпо ходу анализа пригодности. Важно добиться стабильного и правильногоописания еще на этапе предварительного проектирования до того, как мыприступим к созданию детального проекта, изображаемого на диаграммахпоследовательности.

Многие разработчики жалуются на постоянное изменение требований.Некоторые расценивают это как предлог для преждевременного переходак кодированию. Готовы поспорить, что эти люди, как правило, не выполня�ют анализа пригодности, который мог бы весьма ощутимо помочь в фикса�ции требований.

Разбивая работу над динамической моделью на три вышеописанныхэтапа, мы получаем шанс дважды отрецензировать описание поведения. Хо�чется надеяться, что ко времени второго рецензирования наше понимание

Прототип




Код

Диаграмма

классов


Модель


области

Модель



Диаграмма


Динамическаямодель

Рис. 1.7. Процесс ICONIX – простой подход к моделированию с помощью UML



требований будет достаточно детальным и стабильным, чтобы лечь в ос�нову проектирования.

Как видно из статической части картины, первое представление об объ�ектах мы получаем исключительно из описания пространства задачи. Одиндлинный цикл последовательных уточнений выполняется при анализе ди�намического поведения системы. Мы стараемся во всех деталях понять,как должен выполняться отдельно взятый сценарий, а затем обновляемдиаграммы классов. Наконец, возвращаемся назад и снова размышляемнад тем, как должна вести себя система.

На следующем шаге мы уточняем структуру нашей программы. Этотподход, на 80% заимствованный из работы Айвара Джекобсона, позволяетразбить систему на части, определяемые границами прецедентов, послечего результаты анализа прецедентов используются с целью перехода надостаточно детальный для кодирования уровень модели.

Особенности процесса ICONIXНа рис. 1.7 изображен простой подход к разработке программного обеспе�чения, использующий минимальный набор UML�диаграмм и ряд приемов,которые позволяют быстро и эффективно перейти от прецедентов к коду.Этот подход обладает гибкостью и открытостью.

Хотелось бы подчеркнуть его особенности.Во�первых, простое использование UML. Описанные в последующих

главах шаги – это минимум, который, по нашему мнению, необходим и до�статочен для успешной разработки объектно�ориентированного проекта.Взяв на вооружение лишь часть довольно громоздкого языка UML, кол�лектив сумеет справиться с «аналитическим параличом» на первых этапахработы над проектом.

Во�вторых, возможность легкого отслеживания хода работы. На каж�дом шаге мы так или иначе возвращаемся к требованиям. Ни на какомэтапе процесс не может увести слишком далеко от потребностей пользова�телей. Говоря о легкости отслеживания, мы имеем в виду и то, что за эво�люцией объектов при переходе от анализа к проектированию удается про�следить без труда.

В�третьих, подход является итеративным и инкрементным, хотя этитермины мы рассматриваем не в традиционном смысле. При разработкемодели предметной области, выявлении и анализе прецедентов выполня�ется несколько итераций. На протяжении жизненного цикла системымогут возникать и другие итерации. Статическая модель постепенно уточ�няется по мере выполнения последовательных итераций в работе над ди�намической моделью (составленной из прецедентов, результатов анализа

23

пригодности и диаграмм последовательности). Заметьте, впрочем, что мыне требуем выполнения формальностей и создания внутренних докумен�тов. Работа по уточнению развивается естественным образом по мере того,как коллектив расширяет свое понимание задачи.

В предисловии уже говорилось о том, что цель книги – продемонстри�ровать практическое применение процесса ICONIX на примере книжногомагазина, работающего в режиме реального времени. При этом особое вни�мание уделено восприятию системы пользователем.

На протяжении последних десяти лет мы вели курсы по процессуICONIX и с уверенностью можем говорить о его полезности и актуаль�ности. Речь идет о поиске ответов на фундаментальные вопросы о сис�теме:

каковы пользователи системы (актеры) и что они пытаются сделать;что такое объекты «реального мира» (предметной области) и какиемежду ними ассоциации;какие объекты участвуют в каждом прецеденте;как объекты взаимодействуют друг с другом в каждом прецеденте;как учесть ограничения, налагаемые режимом реального времени;как будет выглядеть система на самом низком уровне.

Нам еще не встречались системы, которые не требовали ответов на этивопросы (особенно на первые четыре), или системы, где ответы нельзябыло бы получить с помощью описываемых в этой книге методов с исполь�зованием итеративного, инкрементного и оппортунистического («видишьответ – подбери») подхода. Хотя строгое следование нашей методике пред�полагает выполнение шагов в определенном порядке, но это не столь ужважно. Многие проекты со временем прекращали свое существование из�за чрезмерно формализованного процесса, поэтому мы не являемся сто�ронниками такого подхода. Мы лишь говорим, что отсутствие ответа налюбой из сформулированных выше вопросов может подвергнуть разработ�ку необоснованному риску.

Базовые принципыМы утверждаем, что лучший способ сделать процесс привлекательным –научить ему как можно больше людей, рассказав о преимуществах поискаответов на поднятые нами и другие подобные вопросы, а также об опаснос�тях, связанных с игнорированием этих вопросов. Построение хорошей мо�дели намного упрощается, если вы твердо намерены искать ответы нафундаментальные вопросы о создаваемой системе и не увлечены второсте�пенными техническими вопросами моделирования.

Базовые принципы


Заказчиками разработки являются как непосредственные участникипроцесса, так и руководящее звено. Мы представляем себе процесс какпуть, по которому следует коллектив разработчиков, как дорогу, помечен�ную километровыми столбами или вехами, в конце которой находитсявысококачественный продукт.

Коллектив может выбирать разные пути в зависимости от способнос�тей и предпочтений отдельных сотрудников. Но, каков бы ни был путь,необходимо пройти каждый этап. Это те точки, на которых работа стано�вится видима руководству, – в ходе рецензирования промежуточных ре�зультатов. Соблюдение всех этапов не гарантирует получения качествен�ного продукта, но существенно повышает шансы на это.

Мы полагаем, что в объектно�ориентированном процессе должны быть,по крайней мере, следующие вехи:

выявление и описание всех сценариев использования системы;поиск повторно используемых абстракций (классов), участвующихв нескольких сценариях;анализ предметной области и идентификация принадлежащих ейклассов. Другими словами, должны быть рассмотрены возможностиповторного использования за пределами данной системы;проверка выполнения всех функциональных требований;тщательное обдумывание того, как требуемое поведение системы бу�дет распределено между выявленными абстракциями с учетом прин�ципов правильного проектирования, как то: минимизация степенисвязанности, максимизация плотности (cohesion), общность, доста�точность и т.д.

Более того, к процессу предъявляются следующие требования:

он должен быть достаточно гибким для адаптации к различным ви�дам задач;он должен поддерживать реально применяемые способы организациитруда (включая создание прототипов и инкрементную, итеративнуюразработку);он должен повышать производительность менее опытных членовколлектива, не отвлекая по мелочам более сведущих сотрудников;он должен демонстрировать руководству результаты работы, пред�шествующей кодированию, в достаточно понятном виде.

Краткое описание основных этапов процессаНа рис. 1.8–1.11 изображены основные этапы процесса ICONIX и свя�занные с ними вехи. Отметим, что первые три рисунка будут встречаться

25Требования к книжному Internet�магазину

Веха 1: рецензирование требований

Выявите объекты предметной области, а также существующие между нимиотношения обобщения и агрегирования. Начните рисовать высокоуровневуюдиаграмму классов.

Если можно, создайте приблизительный прототип системы или соберите всюдоступную информацию об унаследованной системе, которую вы хотитепереработать.

Выявите прецеденты, используя для этой цели диаграммы прецедентов.

Организуйте прецеденты в группы. Изобразите группы в виде пакетов.

Распределите функциональные требования между прецедентами и объектамипредметной области.

R

Рис. 1.8. Анализ требований

и в следующих главах с целью напомнить, в какой точке мы находимся.(В настоящей работе реализация не рассматривается, но в первой нашейкниге есть глава, посвященная этой теме, так что рис. 1.11 приведен толь�ко для полноты картины.)

В совокупности эти диаграммы иллюстрируют принципы, на которыхоснован весь процесс (изнутри наружу, снаружи внутрь и сверху вниз – всеодновременно):

1. Движемся внутри, отталкиваясь от требований пользователя.2. Движемся наружу, отталкиваясь от основных абстракций предмет�

ной области.3. Спускаемся вниз от высокоуровневых моделей к детальному проекту.

Во всех последующих главах мы будем обращаться к этим принципамснова и снова. Если вы будете придерживаться их на каждом этапе работынад проектом, то ваши шансы на успех значительно возрастут.

Требования к книжному Internet�магазинуНачиная со следующей главы мы будем разрабатывать реальный пример подназванием «Книжный Internet�магазин» и пройдем все этапы только что


Веха 2: рецензирование предварительного проекта

Составьте текстовые описания прецедентов * главную последовательностьдействий и альтернативные последовательности, которые выполняются режеили в случае возникновения ошибок.

Выполните анализ пригодности. Для каждого прецедента:

* выявите приблизительный набор объектов, которые выполняют описанный сценарий. Используйте стереотипы объектория (Objectory), имеющиеся в UML;

* добавьте вновь обнаруженные объекты вместе с атрибутами в диаграмму классов из модели предметной области.

Завершите модификацию диаграммы классов так, чтобы она отражала конецфазы анализа в работе над проектом.

Рис. 1.9. Анализ и предварительное проектирование

описанного процесса. Те прецеденты и классы, с которыми мы встретимся,призваны удовлетворить требования заказчика (владельца книжного мага�зина). Сформулируем их:

книжный магазин должен принимать заказы через Internet;книжный магазин должен поддерживать до миллиона счетов кли�ентов;книжный магазин должен обеспечивать защиту счетов с помощьюпароля;книжный магазин должен предоставлять средства поиска в главном ка�талоге;должны быть реализованы различные методы поиска, в том числе поавтору, по названию, по ISBN и по ключевым словам;книжный магазин должен обеспечить безопасность при осуществле�нии платежей по кредитной карточке;книжный магазин должен предоставить безопасные средства плате�жа по перечислению;книжный магазин должен поддерживать специальный вид счетов,для которых заранее дано разрешение платить по перечислению;книжный магазин должен поддерживать электронный обмен даннымис системой доставки товаров;

27

Веха 3: рецензирование окончательного проекта

Распределите поведение. Для каждого прецедента:

* выявите сообщения, которыми обмениваются объекты, и соответствующие им методы. Нарисуйте диаграмму последовательности так, чтобы текст прецедента располагался сверху вниз вдоль левой стороны, а сообщения были справа. Вновь модифицируйте диаграмму классов, добавив новые атрибуты и операции;

* если хотите, покажите на диаграмме кооперации основные транзакции, выполняемые объектами;

* по желанию продемонстрируйте поведение в реальном времени на диаграмме состояний.

Завершите статическую модель, добавив в нее детальную проектнуюинформацию (например, о видимости и примененных паттернах).

Вместе с коллегами проверьте, что проект удовлетворяет всем записаннымранее требованиям.

Рис. 1.10. Проектирование

Веха 4: поставка готовой системы

По мере необходимости разработайте дополнительные диаграммы, напримерразвертывания и компонентов, если это поможет вам на этапе реализации.

Напишите или сгенерируйте код.

Выполните автономное тестирование и тестирование сопряжений.

Протестируйте систему и проведите приемо*сдаточные испытания, пользуясьпрецедентами как описаниями тестов.

Код

Рис. 1.11. Реализация

книжный магазин должен поддерживать электронный обмен даннымис системой управления запасами;книжный магазин должен поддерживать рецензирование книг и по�зволять посетителям оставлять свои комментарии;книжный магазин должен следить за рейтингом книг на основе отзы�вов посетителей.

Требования к книжному Internet�магазину

Глава 2. Моделированиепредметной областиМоделирование предметной области является основой статической частимодели UML. Построение модели предметной области начинается с выяв�ления абстракций, существующих в реальном мире, то есть тех основныхконцептуальных объектов, которые встречаются в системе. При проектиро�вании объектно�ориентированного программного обеспечения вы стреми�тесь структурировать программу так, чтобы в центре оказались именно этиобъекты из пространства задачи. Это делается потому, что требования к про�грамме меняются намного быстрее, чем реальный мир. Основой объектногомоделирования вообще и статического моделирования в частности как рази является создание модели этих абстракций из предметной области.

Возможно, у вас возник вопрос, почему данная глава предшествует об�суждению прецедентов. Дело в том, что, приступая к их записи (см. главу 3),мы не собирались излагать прецеденты с чисто пользовательской точки зре�ния. Вместо этого мы будем формулировать их в контексте объектной мо�дели. Это позволит связать статические и динамические части модели, чтоочень важно, если мы хотим заниматься проектированием на базе анализапрецедентов. Модель предметной области представляет словарь терминов,которым авторы прецедентов могут пользоваться на более поздних этапах.

В ходе выявления объектов из предметной области необходимо устано�вить, какие связи существуют между ними. Особый интерес представляютдва вида отношений: обобщение (отношение между подклассом и суперклас�сом) и агрегирование (отношение между целым и частью). Между классамимогут существовать и другие отношения, в том числе простейшие ассоциа�ции, но эти два исключительно важны. В основу статической модели мыположим диаграммы классов, отображающие модель предметной области.

Классы в UML – это место для размещения атрибутов (то есть данных�членов) и операций (то есть функций, выполняемых объектами). Однако,начиная моделировать предметную область, мы обычно не хотим тратитьмного времени на идентификацию атрибутов и операций; этим мы займем�ся позже, при уточнении и наполнении статической части модели. Сейчасже следует сконцентрировать внимание на выявлении собственно объек�тов и отношений между ними.

29

Одной из главных целей построения программы на основе абстракцийиз реального мира является повторное использование. Имейте в виду, что,если вы собираетесь что�то повторно использовать, нужно будет оченьтщательно поработать над моделированием предметной области, так каквозможность повторного использования выявляется именно на данномэтапе. Таким образом, модель предметной области становится фундамен�том статической части модели.

При моделировании предметной области мы будем следовать методи�ке OMT (Object Modeling Technique), которой свойственна направлен�ность изнутри наружу. Это означает, что мы начинаем с ключевых объек�тов в системе, а затем движемся наружу, изучая, с какими еще объектамиони взаимодействуют. Таким образом, при выявлении прецедентов илидинамической части системы мы продвигаемся снаружи внутрь, а при соз�дании статической модели – изнутри наружу. Секрет в том, чтобы, двигаясьодновременно в обоих направлениях, встретиться посередине, не оставивникакого разрыва. Когда речь пойдет об анализе пригодности (глава 5)и диаграммах последовательности (глава 7), мы увидим, как это делается.А пока запомните, что моделирование предметной области и статическоемоделирование – это взгляд на систему изнутри наружу.

На рис. 2.1 показано, какое место моделирование предметной области за�нимает в общей картине процесса ICONIX.

Основные элементы моделированияпредметной области

Первое, что нужно сделать при построении статической модели системы, –отыскать классы, которые адекватно отражают абстракции предметнойобласти. Если эта работа выполнена хорошо, то у вас будет не только проч�ный фундамент для построения системы, но и хорошие шансы для повтор�ного использования этих классов в следующих системах.

Лучшими источниками классов, по�видимому, являются высокоуров�невое описание задачи, низкоуровневые требования и экспертная оценказадачи. Начните с выписывания максимально возможного числа предло�жений из этих источников (не забывая и о других, например о литературепо маркетингу), а затем обведите или подчеркните все существительныеи именные группы. Шансы на то, что таким образом вы найдете почти всеважные доменные объекты (классы), весьма велики.

По мере уточнения этого перечня должно происходить следующее:

имена существительные и именные группы становятся объектамии атрибутами;

Элементы моделирования предметной области

Моделирование предметной области30

глаголы и глагольные группы становятся операциями и ассоциациями;родительный падеж показывает, что имя существительное должнобыть атрибутом, а не объектом.

Далее следует отсеять из списка кандидатов на звание класса ненужные(избыточные или несущественные) и непригодные (слишком расплывчатыеили представляющие концепции, лежащие за рамками модели) элементы.

При построении диаграмм классов вы можете также принять предва�рительные решения об обобщениях (отношениях вида «является»). Еслинеобходимо заниматься этим на ранней стадии проекта, можете построитьдаже несколько уровней обобщения. Ищите такие предложения в описа�нии задачи, которое содержит слова «является» или «представляет разно�видность». Этап моделирования предметной области – также подходящиймомент для принятия решений об агрегировании (отношении вида «име�ет») классов.

В итоге модель предметной области, дополненная ассоциациями (стати�ческими отношениями между парами классов), должна адекватно описыватьаспекты задачи, не зависящие от времени (статические), и в этом напоми�нать диаграммы сущность–связь, применяемые в моделировании данных.

Прототип




Код

Диаграмма

классов


Модель


области

Модель



Диаграмма



Рис. 2.1. Моделирование предметной области и процесс ICONIX

31

Мы рекомендуем отвести фиксированное время на построение началь�ной модели предметной области. Не надо добиваться ее совершенства,просто постарайтесь закончить ее побыстрее, а затем модифицируйте помере продвижения вперед. Не забывайте вносить необходимые корректи�ровки в модель классов аналитического уровня на стадии выполнения ана�лиза пригодности и на более поздних этапах процесса.

10 самых распространенных ошибокпри моделировании предметной области – Top 10

Перечислим типичные ошибки, которые наши студенты допускают примоделировании предметной области:

#10Сразу начинают назначать кратности ассоциациям, стараясь, что�бы у каждой ассоциации была кратность.Одни ассоциации на диаграмме классов представляют отношенияодин�к�одному, другие – отношения один�ко�многим. Эта характе�ристика называется кратностью. Однако при моделировании пред�метной области не следует обращать внимание на кратности, таккак это отнимает время и может стать причиной «аналитическогопаралича».

#9Так тщательно выполняют анализ существительных и глаголов,что забывают обо всем остальном.Книга Курта Дерра (Kurt Derr) «Applying OMT» (SIGS Books,1995) – хороший источник информации о «грамматическом ана�лизе». Однако, если буквально следовать рекомендациям Дерра,есть риск спуститься на чересчур низкий уровень абстракции.Пользуйтесь этой методикой, чтобы начать выявление объектов,но не слишком увлекайтесь.

#8Включают в классы операции, не изучив как следует прецедентыи диаграммы последовательности.Не стоит уделять слишком много внимания определению опера�ций на этапе моделирования предметной области. В этот моментеще не хватает информации для принятия обоснованных реше�ний. Но информация появится (по крайней мере, на это хочетсянадеяться), когда мы дойдем до моделирования взаимодействий(см. главу 7).

#7Оптимизируют код с учетом повторного использования, не удосто�верившись в выполнении требований пользователя.Чем более общими являются ваши объекты и классы, тем большешансов, что вы сможете ими повторно воспользоваться в других

Ошибки при моделировании предметной области


проектах. А полным называется класс, который теоретически мож�но использовать в любом контексте. Однако для повторного ис�пользования необходимо рассмотреть атрибуты и операции, а мытолько что объяснили, почему не следует включать операции наэтапе моделирования предметной области. Так что не тратьте лиш�них усилий на обеспечение возможности повторного использова�ния при работе с диаграммами классов высокого уровня. Лучшепоскорее завершайте данный этап, чтобы осталось время убедить�ся, что вы проектируете то, что нужно заказчику.

#6По поводу каждой ассоциации вида «является частью» спорят, чтоиспользовать – агрегирование или композицию.Оригинальное описание отношения «имеет по ссылке», данноеГрейди Бучем, трансформировалось в UML в понятие агрегирова�ния. А отношение «имеет по значению» стало «сильной» формойагрегирования – композицией (имеется в виду, что родительскийкласс владеет классом�«частью»: если родитель уничтожается, тоавтоматически ликвидируются и все экземпляры входящих в негообъектов). Попытка различить эти случаи на этапе моделированияпредметной области – верный способ сбиться с пути. Мы предпо�читаем на этой стадии говорить просто об агрегировании. Болееточный выбор следует отложить до этапа детального проектиро�вания.

#5Предлагают конкретную стратегию реализации, не выполнив мо�делирование предметной области.Занимаясь постепенным уточнением модели предметной области,вы должны исключить всякие упоминания о действиях или кон�кретной реализации и думать только о зависимостях. Чего катего�рически не следует делать, так это помещать на диаграммы высоко�го уровня какие�либо отсылки к конкретным технологиям, скажемк реляционным базам данных или специализированным серверам.Отложите эти вопросы до стадии реализации, сначала нужно по�строить модель предметной области.

#4Дают классам маловразумительные имена, например cPortMgr-Intf вместо PortfolioManager.Одной из причин, которая побудила нас начать с моделированияпредметной области, является стремление добиться согласия меж�ду членами коллектива об именовании ключевых абстракций. Чемочевиднее имена классов, тем проще решается эта задача. Об акро�нимах и других видах сокращений (если вы совсем не можете безних обойтись) можно подумать на этапе реализации.

33

#3Сразу начинают пользоваться программными конструкциями, на�пример отношениями дружественности и параметризованнымиклассами.UML предоставляет массу возможностей включить в диаграммыто, что мы называем «штучками Буча». К их числу относятся кон�струкции, заимствованные из языка C++, в частности параметри�зованные классы и отношения дружественности. Но они в большейстепени имеют отношение к пространству решения, а не к простран�ству задачи, а при моделировании предметной области, безусловно,следует сконцентрировать внимание на последнем.

#2Создают взаимно однозначное соответствие между классами изпредметной области и таблицами в реляционной базе данных.Если вы занимаетесь переработкой унаследованной системы, в ко�торой использовалась реляционная база данных, то имена таблицв базе, конечно же, как нельзя лучше подходят в качестве именклассов. Однако не переносите их целиком в статическую модель.В реляционной таблице может быть много атрибутов, вовсе не от�носящихся к контексту объектной модели. Попытайтесь использо�вать агрегирование для выделения групп атрибутов во вспомога�тельные классы.

#1Выполняют «преждевременную паттернизацию», пытаясь постро�ить элегантное решение на основе паттернов, мало связанных иливообще не связанных с поставленной задачей.Паттерны часто начинают проявляться на этапе анализа пригоднос�ти. Как мы увидим в главе 5, есть две стратегии: «элемент управле�ния на экране» и «контроллер прецедентов», которые помогают об�наружить паттерны в прецедентах. Забегая вперед, отметим, чтопаттерны проектирования могут оказаться полезными в контекстедиаграмм последовательности и диаграмм классов уровня проек�тирования. Но на этапе моделирования предметной области невремя думать о терминологии паттернов.

Ошибки при моделировании предметной области


УпражненияПостарайтесь найти те десять ошибок, которые часто допускают при моде�лировании предметной области. (Полная модель приведена в конце этойглавы, а также в приложении.) В первом упражнении из каждой пары до�пущено три или четыре таких ошибки. Ваша задача – исправить их. Во вто�ром упражнении приведены правильные решения и пояснения по поводутого, какие правила были нарушены.

35Упражнения

Упражнение 1а

ПользовательЗаказ

Товар

Книга

Каталог cBinaryTreecLoginMgr

проверитьПароль()

ПредпочтенияПользователя

Счет

Книга

#4

#8#3

Рис. 2.2. Упражнение 1а


Упражнение 1б

ПользовательЗаказ

Товар

Книга

Каталог


Счет

МенеджерРегистрации

На предыдущей диаграмме:

cBinaryTree – это параметризованный класс (в UML он также называется шаблоном клас�са). На данном этапе моделирования не стоит задумываться о таких элементах реализации,как двоичное дерево;в классе cLoginMgr имеется операция ïðîâåðèòüÏàðîëü. Еще слишком рано прини�мать решения о том, какие операции должны быть определены в классах. К тому же весьмавероятно, что эта операция в любом случае принадлежит классу Ñ÷åò;

имя класса cLoginMgr недостаточно понятно.

Рис. 2.3. Упражнение 1б

37


Упражнения

Товар

cSessionBeanShpngCart

Каталог

Книга Заказ

Менеджер Регистрации

Пользователь

Счет ПредпочтенияПользователя

#4

#6#5





Товар

Корзина

Каталог

Книга Заказ

Менеджер Регистрации


Счет ПредпочтенияПользователя

На предыдущейдиаграмме:

имя класса cSessionBeanShpngCart наводит на мысль, что автор модели решил пред�ставить концепцию покупательской корзины с помощью сессионного аппарата Enterprise JavaBeans (EJB). Для размышлений о том, как отобразить классы на такого рода механизмы, впол�не подойдет этап анализа пригодности (см. главу 5);класс, представляющий покупательскую корзину, так и следует назвать – Êîðçèíà;этот класс связан отношением композиции с классом Çàêàç. Автор модели твердо решил,что Çàêàç уничтожается вместе с корзиной, которой он принадлежит. Так это или нет, наданной стадии решать рановато.

39



Книга

Товар

1

1..3

Статус

ТаблицаЗаказов Счет

МетодДоставки

ПлатежнаяИнформация

«entity»Заказ

иддатаРазмещениядатаДоставкиполучательномерДоставкистатусметодДоставкиключВнешнейБазы

изменитьСтатус()извлечьМетодДоставки()извлечьДетали()

#10

#2

#8




Книга

Товар

Статус

ТаблицаЗаказов

Счет



Заказ



наличие атрибута êëþ÷ÂíåøíåéÁàçû говорит о том, что автор модели уже решил исполь�зовать реляционную базу данных (заметим, что классы в модели предметной области не долж�ны иметь ни атрибутов, ни операций);в классе Çàêàç определены операции;для ассоциации между классами Ñ÷åò и Ïëàòåæíàÿ Èíôîðìàöèÿ проставлена кратность.

41



Заказ

Товар

ЗаместительЗаказа

РеальныйЗаказ

Книга

названиеценадатаПубликациипиктограммадоступноеКоличествоминимальныйОстатокскидкаиздатель

Заказ на Покупку

датаРазмещениястатуспозиции : Vector

#2

#5

#1





Товар

Издатель


Запасы ТарифнаяПолитика

Заказ

Книга


наличие атрибутов öåíà, äîñòóïíîåÊîëè÷åñòâî и èçäàòåëü, которые, по всейвидимости, принадлежат ассоциированным классам, свидетельствует о том, что автор мо�дели отобразил существующую таблицу Order непосредственно на класс Çàêàç (хотя, какотмечалось в упражнении 3, классы в модели предметной области еще не должны иметьатрибутов);в классе Çàêàç íà Ïîêóïêó используется класс Vector из языка Java;автор модели применил паттерн проектирования Çàìåñòèòåëü (Proxy). На данной стадииэто решение преждевременно.




Товар

Книга

Корзина

«client»Возможный

Заказ

«server»Заказ

Рецензия

записать()

Рецензия Посетителя

оценить()

Рецензия Редактора#8

#5

#5#6



Товар

Книга

Корзина

ВозможныйЗаказ

«server»Заказ

Рецензия

Рецензия ПосетителяРецензия Редактора



в классе Ðåöåíçèÿ Ïîñåòèòåëÿ определена операция;показано, что ассоциация между классами Товар и Êîðçèíà является композицией, нопока еще не ясно, почему бы не воспользоваться простым агрегированием;приписывание стереотипов классам Çàêàç и Âîçìîæíûé Çàêàç указывает на преждевре�менное решение о распределении классов по уровням системы.

45

Модель предметной областиНа рис. 2.12 приведена полная модель предметной области для книжногоInternet�магазина. Диаграмма объединяет фрагменты, встречавшиесяв упражнениях, а также содержит классы и ассоциации, которые будутрассматриваться позднее.

Модель предметной области

Мод

елир

овани

е пр

едм

етной

области

46

ГлавнаяТаблица Счетов







ДеталиЗаказаСтатус

Запасы

ТарифнаяПолитика

РецензияПосетителя

РецензияРедактора

ИздательРецензия

КаталогРезультатыПоиска

Книга

КорзинаЗаказ наПокупку

Строка Заказа

Товар Заказ


Счет

Ри

с. 2.1

2. М

од

ель п

ре

дм

етн

ой

об

ласти д

ля кни

жн

ого

Inte

rne

t+магази

на

Рис. 3.1. Основа процесса ICONIX

Прототип




Код

Диаграмма

классов


Модель


области

Модель



Диаграмма



Глава 3. Моделирование прецедентовВ этой главе обсуждается основной вопрос, который необходимо задатьв начале разработки любой системы: «Что хотят сделать ее пользователи?».Мы попытаемся как можно подробнее представить действия пользовате�лей и реакцию системы, поскольку ее поведение обусловлено их требова�ниями. Другими словами, работа системы зависит от того, как к ней обра�щаются и чего хотят добиться. Часто эти вопросы связаны с графическиминтерфейсом пользователя.

На рис. 3.1 показано место моделирования прецедентов в общей картинепроцесса ICONIX – для определения прецедентов нужно использовать про�тотипы. Кроме того, мы работаем над моделью прецедентов параллельнос моделированием предметной области на самых ранних этапах проекта.Вся динамическая часть объектной модели непосредственно вытекает из

Моделирование прецедентов48

модели прецедентов. Поскольку динамическая модель определяет стати�ческую, модель прецедентов оказывает решающее воздействие на по�следнюю.

Из рис. 3.1 также видно, что мы постоянно уточняем статическую мо�дель на основе анализа прецедентов. То же самое касается диаграмм при�годности и последовательности. Статическая модель развивается по мерерассмотрения все новых сценариев. Именно так происходит эволюцияот грубой модели предметной области к детальной статической моделиуровня проектирования. Этот подход целиком и полностью основываетсяна прецедентах – они определяют и архитектуру, и проект программнойсистемы.

Наш подход к построению динамической модели можно описать как«снаружи внутрь». Мы начинаем с обследования пользователей, которыенаходятся вне системы, и по пути раскрываем детали поведения програм�мы. На этой основе создается структура программы, которая поддерживаеттребуемое поведение. Продвижение направлено внутрь, его шагом являет�ся рассмотрение одного конкретного сценария. Поскольку прецеденты –это фундаментальные единицы декомпозиции, то все остальное жесткоподчинено этому движению. В результате можно быть уверенным, что спро�ектированная система будет отвечать требованиям пользователей, а это со�всем не мало.

Основные элементы моделирования прецедентовЧтобы решить задачу построения прецедентов для новой системы, необ�ходимо с самого начала идентифицировать как можно больше прецеден�тов, а затем составить и постоянно уточнять их словесное описание. Походу дела будут обнаруживаться новые прецеденты и общие для них фраг�менты.

При выявлении прецедентов необходимо всегда помнить главный прин�цип: их следует тесно связывать с будущим руководством пользователя.Связь между каждым прецедентом и разделом руководства должна бытьочевидной. Это подкрепляет основную идею, состоящую в том, что проектсистемы базируется на восприятии ее пользователями. Можно сказать, что«основа на прецедентах» означает: «Сначала напишите руководство поль�зователя, а потом код». Если вы перерабатываете унаследованную систе�му, то можете просто отталкиваться от руководства пользователя и вно�сить необходимые изменения.

Написав какой�то текст прецедента, отшлифуйте его, сформулировавпредложения в ясной и краткой форме. Постарайтесь, чтобы каждое пред�

49

ложение имело структуру существительное–глагол–существительное,а актеры и потенциальные доменные объекты были сразу видны. Как толь�ко обнаруживаются новые объекты или уточняется поведение ранее най�денных, сразу обновите модель предметной области (см. главу 2). И еще –очень важно иметь в виду все возможные альтернативные последователь�ности действий для каждого прецедента, хотя на их учет уходит большаячасть времени. Отметим, что анализ пригодности (см. главу 5) способству�ет выполнению последовательных уточнений.

Некоторые авторы призывают использовать развернутые шаблоны пре�цедентов. Но наши рекомендации всем ученикам таковы:

1. Создайте шаблон прецедента, в котором есть разделы «Главная по�следовательность» и «Альтернативные последовательности». Другиеразделы не нужны, они будут только отвлекать внимание.

2. Задайте себе вопрос: «Что происходит?». С ответа на него начинает�ся главная последовательность.

3. Спросите себя: «А что дальше?». Продолжайте в том же духе, покавсе детали главной последовательности не будут записаны на бумаге.

4. Спросите себя: «А что еще может происходить?». Будьте упорны.Хоть что�нибудь еще может происходить? Вы уверены? Задавайтесебе эти вопросы, пока не появится достаточно обширный набор аль�тернатив. Поверьте, проблемы на этом этапе – ничто по сравнениюс бедами, возникающими, скажем, во время тестирования сопряжений.

Цель состоит не в том, чтобы построить красивую модель прецедентов;важно учесть все, что может сделать пользователь.

Вы еще будете анализировать этот материал при рецензировании тре�бований (глава 4), и еще раз во время рецензирования предварительногопроекта (глава 6), и снова при рецензировании окончательного проекта(глава 8). Если вам кажется, что это чересчур, вспомните: чем четче опре�делено поведение системы, тем легче ее построить.

В вашем распоряжении есть несколько механизмов для вычлененияфрагментов (к примеру, обработки ошибок), общих для некоторого набо�ра прецедентов. Обычно это разумно, так как разбиение на атомарныеблоки упрощает анализ и экономит время при рисовании диаграмм. Бу�дете ли вы применять механизм обобщения прецедентов и отношениявключения (include) и расширения (extend), имеющийся в UML, или от�ношения вызова (invoke) и предшествования (precede) из языка OpenModeling Language (OML), рекомендуемые нами в книге «Use Case Dri�ven Object Modeling with UML», цель состоит в том, чтобы получить на�

Элементы моделирования прецедентов


бор небольших, четко очерченных и допускающих повторное использо�вание прецедентов.

Мы рекомендуем объединять прецеденты в пакеты главным образомпотому, что последние определяют логические участки работы, которыеможно распределить между различными группами сотрудников. Стоитпридерживаться правила: каждый пакет должен соответствовать главеили по крайней мере большому разделу руководства пользователя.

Переходить к дальнейшим этапам процесса разработки следует послетого, как достигнуты следующие цели моделирования прецедентов:

созданные прецеденты описывают всю требуемую функциональ�ность системы;для каждого прецедента четко и кратко описана главная последова�тельность действий, а также все альтернативные последовательности;выделены (с помощью того или иного удобного для вас механизма)сценарии, общие для нескольких прецедентов.

10 самых распространенных ошибокпри моделировании прецедентов – Top 10

Перечислим типичные ошибки, допускаемые студентами при моделирова�нии прецедентов:

#10Пишут функциональные требования вместо словесного сценарияиспользования.Требования обычно формулируются из расчета на то, что системадолжна делать. Сценарий же описывает действия, предпринима�емые пользователем, и реакцию на них системы. В конечном сче�те мы хотим, чтобы текст прецедента служил спецификацией по�ведения системы для описываемого сценария и располагалсяв левой части диаграммы последовательности. Мы хотим, что�бы сразу было видно, как система (представленная в виде сово�купности объектов и сообщений) реализует требуемое поведение(описанное с помощью текста прецедента). Поэтому нужно четкоотличать описание порядка использования (поведение) от требо�ваний к системе.

#9Описывают атрибуты и методы, а не порядок использования.Тексты прецедентов не должны излишне подробно описыватьдетали представления. По возможности следует также воздержи�ваться от ссылок на поля в экранных формах. Имена полей частосоответствуют именам атрибутов классов предметной области,о которых говорилось в главе 2. Если вы ловите себя на перечис�

51

лении, скажем, 13 полей в тексте прецедента, остановитесь. От�кройте модель предметной области, найдите классы, которым при�надлежат соответствующие атрибуты, и поместите имена полейв раздел атрибутов. Позже, когда эти атрибуты понадобятся, вы лег�ко сможете их найти. Что касается методов, их не следует ни име�новать, ни описывать в тексте прецедента, поскольку они говорято том, как система делает нечто, а не о том, что она должна делать.

#8Слишком лаконично записывают прецеденты.Когда дело доходит до написания текстов прецедентов, многосло�вие более предпочтительно, чем лаконичность. При переходе к ана�лизу пригодности и моделированию взаимодействий придется от�разить все детали операций пользователя, поэтому вполнелогично хотя бы часть этих деталей с самого начала описать в пре�цедентах. Всегда помните о том, что прецеденты будут служитьосновой руководства пользователя, так что лучше включитьслишком много деталей, чем что�то упустить из виду.

#7Полностью абстрагируются от интерфейса пользователя.Один из фундаментальных принципов «основан на прецедентах»состоит в том, что при проектировании системы разработчикиотталкиваются от ее восприятия пользователями. Но при этом ни�как нельзя игнорировать те действия, которые пользователи выпол�няют с помощью экрана и клавиатуры. При описании ошибки 9 ужеотмечалось, что не нужно упоминать в тексте прецедента о полях наэкране и не стоит вдаваться в описание косметических деталей ин�терфейса. Все это при необходимости можно отразить в прототипах.Но вы обязаны обсудить те особенности интерфейса, которые по�зволяют пользователю указать системе, что она должна делать.

#6Не присваивают явные имена граничным объектам.Граничными называются объекты, с которыми взаимодействуютактеры. К их числу относятся экранные формы, диалоговые окнаи меню. Стремясь включать побольше деталей и явно описыватьспособы навигации, мы считаем, что граничные объекты следуетявно именовать в текстах прецедентов. Другая причина, по кото�рой это важно сделать, состоит в том, что поведение таких объек�тов будет подвергнуто исследованию на этапе анализа пригодно�сти (глава 5) и присвоение им имен на ранних стадиях позволитизбежать неоднозначности в дальнейшем.

#5Описывают прецеденты не с точки зрения пользователя.

Ошибки при моделировании прецедентов


Наиболее эффективно прецедент формулируется, с точки зренияпользователя, с применением глаголов настоящего времени в дей�ствительном залоге. Инженеры давно используют страдательныйзалог, но прецеденты должны описывать выполняемые пользова�телем действия и реакцию на них системы, а такого рода текст луч�ше всего звучит в действительном залоге.

#4Описывают только действия пользователя, игнорируя реакциюсистемы.Текст прецедента должен отражать как событие, так и отклик нанего, например: «Система делает то�то, когда пользователь делаетто�то». Прецедент должен описывать многое из того, что происхо�дит «под капотом» в ответ на действия пользователя: создание но�вых объектов, контроль вводимых данных или вывод сообщенийоб ошибках. Не забывайте, что в тексте прецедента рассматрива�ются обе стороны диалога пользователя с системой, а поведениепрограммы – то, что вы и пытаетесь выявить, – находится на сис�темной стороне этого диалога. Игнорируя реакцию системы, выигнорируете поведение программы.

#3Опускают описание альтернативных последовательностей дей�ствий.Главные последовательности обычно проще выявить и описать. Ноэто вовсе не означает, что работу с альтернативными последова�тельностями можно отложить, скажем, до этапа детального проек�тирования. Опыт показывает, что, когда важные альтернативныепоследовательности остаются нераскрытыми до этапов кодирова�ния и отладки, программист, отвечающий за их реализацию, посту�пает так, как ему удобно. Стоит ли говорить, что на качестве про�екта это не всегда сказывается благоприятно?

#2Концентрируют внимание на чем�то не относящемся к самомупрецеденту, например на том, когда он начинается или что проис�ходит позже.Некоторые известные авторы выступают в поддержку длинныхи сложных шаблонов прецедентов. Обычно в них есть разделы дляпред� и постусловий. Мы полагаем, что вполне достаточно двухразделов: «Главная последовательность» и «Альтернативные по�следовательности». Не следует настаивать на громоздких шабло�нах только потому, что о них упоминается в книге или статье. Нетратьте зря свое время.

53

#1Затрачивают много времени, решая, что использовать: включениеили расширение.За все время преподавания нам ни разу не пришлось для выделе�ния общих фрагментов использовать более одного механизма. Мо�жете применять механизм включения (include) из UML или меха�низмы вызова (invoke) и предшествования (precede) из OML либоеще что�нибудь – большой роли это не играет. Важно лишь оста�новиться на чем�то одном и далее придерживаться этого выбора.Две аналогичных конструкции хуже, чем одна. Пытаясь пользо�ваться обеими, легко запутаться и увязнуть.

Ошибки при моделировании прецедентов


УпражненияСледующие упражнения, относящиеся к книжному Internet�магазину,позволяют проверить, сможете ли вы найти те десять ошибок, которые ча�сто допускают при моделировании прецедентов. (Полная модель преце�дентов приведена в конце этой главы и в приложении.) В первом упраж�нении из каждой пары допущено три или четыре таких ошибки. Вашазадача – исправить их. Во втором упражнении приведены правильныерешения (курсивом) и пояснения по поводу того, какие правила были на�рушены.

55

Упражнение 1a

[из прецедента Îòêðûòü Ñ÷åò]

Главная последовательность. Êëèåíò вводит требуемую информацию.Система проверяет ее корректность и создает новый объект Счет.

Альтернативная последовательность. Если введенные данные некоррект�ны, система выводит соответствующее сообщение об ошибке.

[из прецедента Поиск по Автору]

Пользователь отправляет запрос. Система выводит страницу, содержащуюрезультаты поиска.

[из прецедента Ðåãèñòðàöèÿ]Êëèåíò вводит свой код и пароль, после чего нажимает кнопку Зарегист�

рироваться. Система выводит Íà÷àëüíóþ Ñòðàíèöó.


#8

#6

#3



Главная последовательность. Êëèåíò вводит свое имя, адрес электронной почты и па�роль (дважды), затем нажимает кнопку Создать Счет. Система проверяет корректность данных,после чего создает объект Ñ÷åò на основе этих данных и выводит Íà÷àëüíóþ Ñòðàíèöó.

Альтернативные последовательности:

если Êëèåíò не ввел имя, система выводит соответствующее сообщение об ошибке и пред�лагает ввести имя;если формат введенного адреса электронной почты некорректен, система выводит соответ�ствующее сообщение об ошибке и предлагает повторить ввод адреса;если Êëèåíò ввел слишком короткий пароль, система выводит соответствующее сообще�ние об ошибке и предлагает ввести более длинный пароль;если два введенных Êëèåíòîì пароля различаются, система выводит сообщение об ошиб�ке и предлагает ввести пароль повторно.

Êëèåíò вводит имя Àâòîðà на Ñòðàíèöå Ïîèñêà и нажимает кнопку Искать. Система ...находит все Êíèãè, написанные этим Àâòîðîì ..., и выводит список книг на Ñòðàíèöå Ðå-çóëüòàòîâ Ïîèñêà.

Главная последовательность. Клиент вводит свой код и пароль, затем нажимаеткнопку Зарегистрироваться. Система сравнивает информацию с той, что хранится в Ñ÷åòå,после чего выводит Íà÷àëüíóþ Ñòðàíèöó.

Альтернативная последовательность. Cистема не может найти введенный пользова�телем код.

В предыдущем упражнении:

первый прецедент записан слишком лаконично. Не сказано, какую информацию вводитÊëèåíò и на какую страницу он попадает после успешного завершения операции. Из текстане ясно, как именно проверяется корректность данных. Кроме того, не описано, каким обра�зом Êëèåíò должен реагировать на ошибки;во втором прецеденте явно не указаны имена граничных объектов;в третьем прецеденте отсутствуют альтернативные последовательности, хотя из контекста по�нятно, что какой�то контроль данных должен быть и что возможно несколько разных ошибок.

57


[из прецедента Ðåãèñòðàöèÿ]

Название. Ðåãèñòðàöèÿ.Назначение. Зарегистрировать вход Êëèåíòà в систему.Предусловие. Êëèåíò еще не зарегистрировался.Главная последовательность. Êëèåíò вводит свой код и пароль, после

чего нажимает кнопку Зарегистрироваться.Постусловие. Вход Êëèåíòà в систему зарегистрирован.

[из прецедента Èçìåíèòü Ñîäåðæèìîå Êîðçèíû]

На Ñòðàíèöå Êîðçèíû Êëèåíò изменяет количество Òîâàðà в Êîðçè-íå и нажимает кнопку Обновить. Затем Êëèåíò нажимает кнопку ПродолжаюПокупать.

[из прецедента Îòìåíèòü Çàêàç]

Главная последовательность. Система выводит информацию о Çàêàçåна Ñòðàíèöå Îòìåíû Çàêàçà, в том числе состав заказа и адрес доставки.Êëèåíò нажимает кнопку Подтвердить отмену...


#2

#4

#3



Главная последовательность. Клиент вводит свой код и пароль, после чего нажимаеткнопку Зарегистрироваться...

На Странице Корзины Клиент изменяет количество Товара в Корзине и нажимаеткнопку Обновить. Система сохраняет новое количество, после чего вычисляет и выводит новуюстоимость Товара...

Главная последовательность. Система проверяет, можно ли отменить Заказ (то есть ненаходится ли он в состоянии «готовится к доставке» или «доставлен»). Затем система выводитинформацию о Заказе на Странице Отмены Заказа, в том числе состав Заказа и адресдоставки. Клиент нажимает кнопку Подтвердить отмену. Система помечает Заказ как «уда�ленный», после чего вызывает прецедент Вернуть Товар на Склад.

Альтернативная последовательность. Если Заказ находится в состоянии «готовится кдоставке» или «доставлен», система выводит сообщение о том, что отменять Заказ уже по�здно.


на примере первого прецедента видно, насколько бесполезным может быть слепое следова�ние сложному шаблону. Из самого названия прецедента понятно его назначение, а ход глав�ной последовательности делает избыточными пред� и постусловия;во втором прецеденте не сказано, что система делает в ответ на нажатие Клиентом кнопкиОбновить. В частности, это может быть и удаление товара из Заказа;в третьем прецеденте не отмечено, что Заказ может находиться в таком состоянии, что от�менить его невозможно.



[из прецедента Поиск по Автору]

Клиент вводит имя Автора и отправляет запрос на поиск... Система нахо�дит существенную информацию о каждой Книге и выводит список Книг.

[из прецедента Изменить Содержимое Корзины]

Главная последовательность. Если Клиент изменяет количество Това!ра в Корзине и нажимает кнопку Обновить, то система сохраняет новое коли�чество, а затем вычисляет и показывает новую стоимость данного товара...

Альтернативная последовательность. Система удаляет Товар из Кор!зины, если его количество становится равным нулю.

[из прецедента Обработать Готовый к Доставке Заказ]

Приемщик проверяет, что каждой Строке Заказа, присутствующей в За!казе на Покупку, соответствует физический товар. Приемщик считываетштрих�коды с упаковочного листа. Система выполняет метод изменить состо!яние заказа, чтобы перевести Заказ в состояние «выполнен», а затем вызы�вает метод сменитьДоступноеКоличество для каждой книги. Приемщикпередает Книги Учетчику.

#10

#9

#7



Клиент вводит имя Автора на Странице Поиска и нажимает кнопку Искать... Системанаходит существенную информацию о каждой Книге, после чего выводит список Книг наСтранице Результатов Поиска...

Главная последовательность. На странице Корзины Клиент изменяет количество То!вара в Корзине и нажимает кнопку Обновить. Система сохраняет новое количество, а затемвычисляет и показывает новую стоимость данного товара...

Альтернативная последовательность. Если Клиент вводит в качестве нового количе�ства нуль, то система удаляет данный Товар из Корзины.

Приемщик проверяет, что каждой Строке Заказа, присутствующей в Заказе на По!купку, соответствует физический товар. Приемщик считывает штрих�коды с упаковочного ли�ста. Система изменяет состояние Заказа на «выполнен» и обновляет количество каждой кни�ги. Приемщик передает Книги Учетчику.


в первом прецеденте не названы граничные объекты;второй фрагмент скорее напоминает спецификацию требований, а не текст прецедента;в третьем прецеденте упоминаются два метода.

61


[из прецедента Оформить Заказ]

Клиент выбирает метод оплаты и нажимает кнопку Использовать этот ме�тод оплаты. Затем Клиент нажимает кнопку Подтвердить Заказ. Прецедентзавершается.

[из прецедента Доставить Заказ]

Служащий считывает штрих�коды с упаковочного листа. Система изменяетсостояние Заказа на «готовится к доставке», затем выясняет, какой Метод До!ставки был указан в Заказе, и выводит его на Консоль Участка Достав!ки...

[из прецедента Просмотреть Недавние Заказы]

Клиент щелкает по гиперссылке. Система находит и показывает в режимечтения Состав Заказа на Странице Деталей Заказа. В частности, наверхувыводятся значения из объекта Заказ, а ниже – детали о каждом Товаре, вклю�чая основные сведения о заказанных Книгах, но без пиктограмм. Для возвратана Страницу Просмотра Заказов Клиент нажимает кнопку OK.


#4

#3

#9



Клиент выбирает метод оплаты и нажимает кнопку Использовать этот метод платежа. Си�стема связывает данный объект Платежная Информация с объектом Возможный Заказ. За�тем система выводит Страницу Подтверждения Заказа.

Клиент нажимает кнопку Подтвердить Заказ. Система преобразует Возможный Заказв Заказ и уничтожает Корзину, после чего возвращает управление вызвавшему прецеденту.

Главная последовательность. Упаковщик проверяет, что Товары, перечисленные в упа�ковочном листе, приложенном к Заказу, соответствуют физическим товарам. Упаковщиксчитывает штрих�коды с упаковочного листа. Система изменяет состояние Заказа на «гото�вится к доставке», затем выясняет, какой Метод Доставки был указан в Заказе, и выводитего на Консоль Участка Доставки...

Альтернативная последовательность. Если Упаковщик обнаруживает расхождениемежду Заказом и подобранными физическими товарами, то обработка Заказа прекращает�ся до устранения неувязок.

Клиент щелкает по гиперссылке. Система находит и показывает в режиме чтения Со!став Заказа на Странице Деталей Заказа [обратите внимание, что часть исходного тек�ста опущена]. Для возврата на Страницу Просмотра Заказов Клиент щелкает по кнопкеOK.


в первом прецеденте не описано, что происходит, когда Клиент нажимает кнопки Исполь�зовать этот метод платежа и Подтвердить Заказ;во втором прецеденте не учтено, что товары, лежащие перед Упаковщиком, могут не соот�ветствовать упаковочному листу;в третьем прецеденте слишком подробно описывается структура Страницы Деталей За!каза.

63


[из прецедента Доставить Заказ]

Служащий заканчивает упаковку Заказа, записывает его номер и отправ�ляет через соответствующего Поставщика.

[из прецедента Просмотреть Недавние Заказы]

Система выводит список Заказов, которые Клиент разместил за послед�ние 30 дней... Клиент запрашивает детальную информацию о Заказе. Сис�тема находит и выводит состав Заказа в режиме чтения. Закончив просмотрданного Заказа, Клиент возвращается к списку Заказов.

[из прецедента Просмотреть Список Книг]

Клиент щелкает по ссылке Категория на Странице Просмотра Книг.Система вызывает метод отобразитьПодкатегории объекта Категория.Процесс продолжается, пока есть подкатегории, после чего система выводитсписок Книг в самой глубокой подкатегории.


#8

#6

#9



Служащий взвешивает подобранные товары, упаковывает Товары, наклеивает на упа�ковку накладную, соответствующую методу доставки, считывает штрих�код с накладной. Си�стема сохраняет извлеченный из штрих�кода номер Заказа. Служащий отправляет Заказчерез соответствующего Поставщика.

Система находит Заказы, размещенные Клиентом за последние 30 дней, и выводит ихсписок на Странице Просмотра Заказов. В каждой строке присутствует ИдентификаторЗаказа (в виде гиперссылки)... Клиент щелкает по ссылке. Система находит и выводит со�став Заказа в режиме чтения на Странице Деталей Заказа. Для возврата на СтраницуПросмотра Заказов Клиент нажимает кнопку OK.

Клиент щелкает по ссылке Категория на Странице Просмотра Книг. Система отобра�жает подкатегории данной Категории. Процесс продолжается, пока есть подкатегории, послечего система выводит список Книг в самой глубокой подкатегории.


в первом прецеденте не указано, как Упаковщик записывает номер заказа, поэтому непо�нятно, каким образом номер ассоциируется с Заказом;во втором прецеденте опущены некоторые детали представления списка Заказов и дета�лей одного Заказа и, как следствие, остался неясным способ перехода от одного к другому;в третьем прецеденте происходящее описывается в терминах методов, а не с точки зрения ак�тера.

65

Изменить СодержимоеКорзины

Оформить Заказ

Открыть Счет

ПросмотретьНедавние Заказы

Доставить Заказ

Обработать Готовыйк Доставке Заказ

Искать по Автору

Отменить Заказ

ПросмотретьСписок Книг

Регистрация

Клиент

Упаковщик Участок Доставки

Доставщик

Учетчик

Участок Приемки

Приемщик

Рис. 3.2. Диаграмма прецедентов для книжного Internet�магазина

Готовая диаграмма прецедентов

Готовая диаграмма прецедентовНа рис. 3.2 показана полная диаграмма прецедентов для книжного In�

ternet�магазина. В частности, на ней присутствуют и прецеденты, которыеупоминались в упражнениях, и задействованные в них актеры.

Глава 4. РецензированиетребованийЗадача процедуры рецензирования требований заключается в том, чтобывыяснить, отвечает ли всем требованиям заказчика набор прецедентов со�вместно с моделью предметной области. Кроме того, заказчик должен от�четливо представлять, что ему нужно (что сформулированные требованияможно положить в основу проектирования). Некоторые авторы считают,что «заказчик никогда не знает, чего хочет, требования меняются каждуюнеделю, а иногда каждый день и даже каждый час», оправдывая этим игно�рирование этапов анализа и проектирования. Однако задача аналитика

Веха 1: рецензирование требований

Выявите объекты предметной области, существующие в реальном мире,а также отношения обобщения и агрегирования между ними. Начните рисоватьдиаграмму классов верхнего уровня.

Если требуется, создайте какой#нибудь прототип системы или соберитеимеющуюся информацию об унаследованной системе, которую высобираетесь переработать.

Выявите прецеденты и изобразите их на диаграмме прецедентов.

Организуйте прецеденты в группы и покажите результат на диаграммепакетов.

Распределите функциональные требования между прецедентами и объектамипредметной области.

R

Рис. 4.1. Рецензирование требований и процесс ICONIX

67

в том и состоит, чтобы помочь заказчику четко сформулировать требова�ния. Прецеденты, прототипы и модели предметной области – средства до�стижения этой цели.

На рис. 4.1 показано, на каком этапе мы сейчас находимся.

Основные элементы рецензирования требованийК рецензированию требований могут быть привлечены представители за�казчика и разработчики, а также менеджеры проекта. Задача состоит в том,чтобы все участники согласились, что имеющиеся прецеденты, моделипредметной области и прототипы адекватно описывают функциональныетребования к системе. Лучше всего, если обсуждение происходит в однойкомнате и имеется ведущий, который контролирует беседу, записывая ходи результаты дискуссии. Самое главное, чтобы было понятно, как каждоетребование отражается в прецедентах и как классы из модели предметнойобласти и прототипы взаимодействуют с прецедентами для удовлетворе�ния требований.

Вот один из принципиальных вопросов, стоящих перед разработчика�ми любой системы: «Какие объекты реального мира необходимо учестьв модели и как они взаимосвязаны?». В рамках процесса ICONIX моде�лирование предметной области лежит в основе статической части UML�модели. При построении модели предметной области мы начинаем с вы�явления абстракций в реальном мире, то есть основных концептуальныхобъектов, которые будут участвовать в системе.

Проектируя объектно�ориентированную систему, мы пытаемся помес�тить в центр объекты предметной области, существующие в реальном ми�ре, поскольку реальный мир изменяется реже, чем программа. В основеобъектного моделирования вообще и статического моделирования в част�ности – создание модели этих абстракций из предметной области. Перво�начальные диаграммы классов будут развиваться, пока модель предметнойобласти не станет достаточно подробной, чтобы из нее можно было создатькод, поэтому ключевые абстракции желательно выявить по возможностибыстро и эффективно.

Другой принципиальный вопрос звучит так: «Что пользователи систе�мы собираются делать?». В ходе моделирования прецедентов, а затем и ре�цензирования требований мы прилагаем усилия к максимально точномуи подробному описанию поведения пользователей, поскольку работа про�граммы обусловлена именно требованиями пользователей. Другими сло�вами, функции программы зависят от того, как пользователи получаютдоступ к ней и чего они хотят достичь. Всегда помните: чем более четкоопределено поведение системы, тем проще ее построить.

Элементы рецензирования требований

Рецензирование требований68

Из рис. 4.1 видно, что задача выявления прецедентов облегчается за счетприменения прототипов. Мы рекомендуем своим слушателям при любойвозможности пользоваться средствами быстрого создания прототипов. Идеяв том, чтобы разработчики и заказчики сели рядом и общими усилиями соз�дали нечто способное сыграть роль «доказательства правильности концеп�ции». Но – и это очень большое «но», которое отличает нас от привержен�цев методики eXtreme Programming (XP), – не принимайте этот прототипза готовую к поставке программу, даже если вы прогнали на нем несколькосотен автономных тестов. Если только вы не хотите, чтобы пользователинажимали Ctrl+Alt+Delete, увидев «синий экран смерти».

Прототипы, доказывающие правильность концепции, создаются с цельюбыстрой разработки продукта ценой отказа от всеобъемлющего проекта.Пытаясь продемонстрировать, что они на верном пути, авторы максимальнобыстро создают нечто, внешне отвечающее ожиданиям пользователя. В ре�зультате получается «что�то простенькое и, возможно, работающее». В об�щем, это похоже на создание съемочных декораций. «Дом» (на самом делетолько фасад), который снаружи выглядит потрясающе, можно построитькуда быстрее, чем настоящее здание, но жить�то в нем как? Чтобы постро�ить настоящий дом, нужны поэтажные планы, схемы электрической развод�ки и водоснабжения и т.д. Всегда помните, что прототипы, доказывающиеправильность концепции, – не более чем декорация. А что делать, если вашеначальство не видит разницы? Да просто не пишите код прототипа, огра�ничьтесь карандашом и бумагой. Некоторые наши клиенты очень эффектив�но пользуются для этого абстракцией графического интерфейса пользова�теля (ГИП), которая называется диаграммой потоков взаимодействия. Посути дела, это большой лист бумаги, на котором схематично нарисованы эк�ранные формы и пути навигации между ними.

Эту идею можно развить и дальше. Мы обнаружили, что часто отличныерезультаты дает параллельное проектирование графического интерфейсапользователя и требуемого поведения системы. При этом совместно с заказ�чиками уточняются детали представления, а по мере окончательного согла�сования некоторых экранных форм записываются соответствующие преце�денты. Иногда такое «возвратно�поступательное» движение бывает оченьэффективным. Следует распространить эти идеи и на этап рецензированиятребований: тексты прецедентов должны быть согласованы с ассоциирован�ными элементами ГИП в том, что касается содержащихся в прецедентахописаний основных особенностей этих элементов и реакции системы на дей�ствия, выполняемые актером.

Некоторые известные специалисты в области объектно�ориентирован�ного проектирования придерживаются противоположной точки зрения,

69

настаивая на том, что в тексте прецедентов не должно быть отсылок к спе�цифике ГИП и не следует говорить о какой бы то ни было специфике; текстдолжен быть максимально абстрактным – телеоцентрическим, то есть ори�ентированным на цель. (Кстати, «телеоцентризм» – это наш любимый нео�логизм.) Мы же считаем, что на основе абстрактного прецедента не удастсясоздать код столь же эффективно, как на основе конкретного прецедента.Конечно, вряд ли стоит говорить о том, что поле представляет собой наборпереключателей или что у окна есть горизонтальная и вертикальная полосыпрокрутки, но нужно определенно упомянуть, что актер «вызывает» систе�му, а та ему «отвечает», и следует как�то назвать участвующие в этом взаи�модействии объекты. Так вы сможете эффективно проследить пути транс�формации прецедентов на этапах анализа и проектирования.

В ходе рецензирования требований следует выполнить грамматичес�кий анализ текстов прецедентов. Правильнее всего формулировать преце�дент с точки зрения пользователя с использованием глаголов настоящеговремени в действительном залоге. Хотя привычка инженеров пользоватьсястрадательным залогом – давняя традиция, но, как мы только что сказали,в прецедентах должны быть сформулированы действия, которые выпол�няет пользователь, и отклики на них системы, а такого рода описания луч�ше звучат именно в действительном залоге.

Еще один существенный аспект моделирования прецедентов имеет от�ношение к альтернативным последовательностям. В главе 3 уже говори�лось, что все альтернативные последовательности действий для каждогопрецедента очень важны и на учет этого уходит львиная доля времени. Вотпочему следует задаться вопросами типа: «Что еще может произойти? Естьли еще что�нибудь, что может произойти? Вы уверены?».

В главе 8 мы рекомендовали не увлекаться длинными и сложными шаб�лонами прецедентов, в которых предусмотрено место для пред� и пост�условий и многих других вещей, в лучшем случае никому не нужных,а в худшем – вызывающих раздражение.

10 самых распространенных ошибокпри рецензировании требований – Top 10

Перечислим типичные ошибки, допускаемые нашими студентами в ходерецензирования требований:

#10Не занимаются рецензированием требований, поэтому кодировщи�ки делают все, что душе угодно.Один из главных принципов методологии XP гласит: если требо�вания изменяются ежедневно, то не имеет смысла пытаться явно

Ошибки при рецензировании требований


зафиксировать их. Люди, исповедующие этот или аналогичный под�ход, не только не могут отслеживать связи между требованиямии реализацией, но и отказываются от доверительных отношениймежду разработчиками и заказчиками, которые устанавливаютсятолько в ходе интенсивных личных переговоров. В результате впол�не может случиться, что будет написана замечательная система, неимеющая ничего общего с тем, за что заплатил заказчик.Приверженцы методологии XP располагают рядом громких афо�ризмов для объяснения этого явления. Вот как Кент Бек (KentBeck) описывал причины неудачи проекта C3 (сильный удар поXP) на сайте Wiki: «...главная проблема была в том, что финансисти постановщик задачи1 оказались разными лицами. Заказчик, с ко�торым общалась команда, совершенно не интересовался тем, чтодумают менеджеры, оценивающие результаты работы... Новые за�казчики требовали всяких доработок в существующей системе,а руководство желало поскорее перейти к новой системе расчетазарплаты на больших ЭВМ». Если перевести это с жаргона XP, топод «постановщиком задач» понимается представитель заказчика,который сидит в одной комнате с кодировщиками и говорит, чтоизменение требований по ходу работы – это нормально, а «финан�сист» – это спонсор проекта, который дает деньги. В случае с про�ектом C3 (целью которого была замена программы расчета зар�платы на большой ЭВМ в связи с проблемой 2000 года) финансист«по непонятным причинам» прикрыл «кран» в феврале 2000 года,когда программа (обладавшая рядом уникальных возможностей)обсчитывала только треть сотрудников, хотя на ее разработкуушло без малого четыре года. (Мы приглашаем вас посетить сайтhttp://c2.com/cdi/wiki?CthreeprojectTerminated и хорошенько об�думать то, что там написано.)Могло бы рецензирование требований спасти проект? Навернякасказать нельзя. Тем не менее стремление «включить побольше бан�тиков» ценой нарушения графика работы – это типичный и пред�сказуемый результат того, что коллективу программистов позволя�ют самостоятельно определять и в дальнейшем произвольно менятьприоритеты требований (иначе говоря, формулировать их по ходуработы) вместо того, чтобы рассмотреть их вместе с «финансистом».

1 Непереводимая игра слов: по�английски Gold Owner (владелец капитала) и Goal Donor (постанов�щик задачи) звучат примерно одинаково. – Прим. переводчика.

71

#9Не проверяют, отвечают ли тексты прецедентов требуемому по�ведению системы.Фраза «основанный на прецедентах» подразумевает определенныйпорядок использования прецедентов, в которых должно быть отра�жено, что система должна делать. Эта информация далее ложитсяв основу анализа, проектирования и реализации (как это делается).Если прецедент плохо корреллирует с ожиданиями пользователей,вы создадите не ту систему.

#8Не используют никаких прототипов ГИП или их заменителей дляпроверки правильности поведения системы.Какую бы форму ни принимали прототипы – полнофункциональ�ного внешнего интерфейса, рисунков на клочках бумаги или че�го�то среднего между этими крайностями, – обычно они могутслужить лишь отправной точкой при решении задачи выявленияи исследования прецедентов. Сравнение текста прецедента с нави�гацией, проиллюстрированной на прототипе, – отличный способудостовериться в том, что вы делаете «правильную» систему. Есливизуальный материал отсутствует, то вы сильно рискуете, так какпрограммисты, реализующие интерфейс, сделают нечто, не от�вечающее требованиям пользователей, которые зафиксированыв прецедентах.

#7Создают слишком абстрактные прецеденты, поэтому клиенты безтехнического образования не понимают, о чем речь.Хорошие прецеденты содержат достаточно деталей, чтобы их мож�но было использовать на протяжении всего цикла разработки сис�темы – от формулирования требований до кодирования. Они так�же помогают при обсуждении требований с заказчиками. Однаковсе это лишь при условии, что текст прецедента конкретен: актерделает то�то, система – то�то. Заказчик не сможет подписаться подпрецедентом, которого не понимает.

#6Забывают убедиться в том, что модель предметной области точ�но отражает концептуальные объекты из реального мира.Вы будете создавать код на основе диаграмм классов, содержа�щих массу деталей. Эти диаграммы, в свою очередь, получены издиаграмм верхнего уровня, на которых отражена первоначальнаямодель предметной области. Но такой переход попросту невоз�можен, если с самого начала определен неадекватный набор объ�ектов предметной области.



#5Не проверяют наличие в тексте прецедентов ссылок на объектыпредметной области.Основная причина, которая побудила нас заняться моделирова�нием предметной области (глава 2) еще до обсуждения моделиро�вания прецедентов (глава 3), следующая: при создании моделипредметной области формируется словарь терминов для исполь�зования в прецедентах. Это помогает сделать прецеденты конкрет�ными и упрощает отслеживание их эволюции, поскольку в преце�дентах и диаграммах классов применяется единая терминология.Кроме того, анализ пригодности (тема главы 5) будет проведенбыстрее, если вы уже назвали объекты в текстах прецедентов.

#4Не беспокоятся по поводу прецедента, в котором нет альтерна�тивных последовательностей действий.По нашему опыту, не менее чем в 90% прецедентов есть хотя быодна альтернативная последовательность. Появление в тексте та�ких слов, как «проверить» или «контролировать», – верный при�знак наличия альтернативной последовательности, связанной с об�работкой ошибок. Кроме того, каждый прецедент обычно содержитветвь, по которой актер ходит реже, чем по той, что описана в глав�ной последовательности. Нужно стремиться обнаружить такиеветви.

#3Не проверяют, все ли альтернативные последовательности дей�ствий были рассмотрены.Неплохой метод обнаружения альтернативных последовательнос�тей состоит в том, чтобы поставить вопрос к каждому предложениюиз главной последовательности. Что может пойти не так? Можетли актер сделать что�то еще, помимо данного действия? Может лисистема ответить по�другому? Мы уже говорили, что нужно про�являть настойчивость в поиске альтернативных последовательнос�тей, так как многие интересные особенности поведения системыотражены именно в них, а не в главной последовательности.

#2Не обращают внимания на страдательный залог в текстах преце�дентов.Ваши прецеденты должны описывать действия, совершаемые какактером, так и системой. Для выражения действия лучше всегоподходят глаголы в действительном залоге. Страдательный залогприемлем лишь в случае, когда автор не знает, кто или что выпол�няет данное действие, – вещь, абсолютно недопустимая в текстепрецедента.

73

#1Считают, что все в порядке вещей, когда текст прецедента зани�мает четыре страницы.Главная последовательность прецедента не должна быть длиннееодного�двух абзацев. Каждая альтернативная последовательностьдолжна состоять из одного�двух предложений. Иногда прецедентыоказываются короче, особенно если выполняют функции «соеди�нительной ткани» (например, описывают выбор из меню). Бываети так, что нужны более длинные прецеденты. Но для выделенияобщего поведения следует пользоваться такими механизмами, каквызов или предшествование. Это позволит писать краткие пре�цеденты, которые, возможно, даже удастся использовать повтор�но. И уж совершенно точно следует держаться подальше от длин�ных шаблонов прецедентов, которые только затемняют суть дела.


Глава 5. Анализ пригодностиДля связывания статической и динамической моделей надо ответить надва основных вопроса. Во�первых, какие объекты нужны для каждого пре�цедента? (Второй вопрос обсуждается в главе 7.) Для ответа на этот во�прос воспользуемся техникой анализа пригодности, разработанной А. Дже�кобсоном.

Диаграмма пригодности напоминает диаграмму кооперации из UML:на ней изображены объекты, участвующие в сценарии, и способы их вза�имодействия. Анализ пригодности не входит в ядро UML, но требует не�которых стереотипов. Он был частью метода Objectory, созданного Дже�кобсоном. Эта неформальная методика весьма полезна для уточненияпрецедентов и выявления объектов, которые для них необходимы, но покакой�то причине не вошли в модель предметной области.

Создавая язык UML, «три амиго» знали о существовании этой техники,но не включили ее в основную часть стандарта. Вместо этого они разра�ботали специализированные расширения для процесса Objectory с по�мощью механизма стереотипов, который позволяет связывать нестандарт�ные пиктограммы с любыми символами. При анализе пригодности в ролитаких стереотипов выступают пиктограммы классов.

По существу, диаграмма пригодности в UML – это диаграмма классов,хотя в оригинальной концепции Джекобсона она была ближе к диаграм�мам кооперации, на которых показываются не классы, а их экземпляры.Но в настоящее время это диаграмма классов, на которой вместо обычныхв UML символов классов изображаются пиктограммы трех видов (рис. 5.1):

граничные объекты, которыми актеры пользуются для взаимодей�ствия с системой;

Граничныйобъект

Сущностныйобъект

Управляющийобъект

Рис. 5.1. Символы на диаграммах пригодности

75

Рис. 5.2. Связь между анализом и проектированием

Разрыв

сущностные объекты – обычно из модели предметной области (см.главу 2);управляющие объекты (обычно называются контроллерами, так каким ничего не соответствует в реальном мире), выполняющие функ�ции «клея» между граничными и сущностными объектами.

На рис. 5.1 изображены пиктограммы для трех видов объектов.В процессе ICONIX эта простая, но исключительно полезная техника

служит связующим звеном между анализом (что) и проектированием(как) – рис. 5.2.

Эта диаграмма объясняет, почему процесс разработки программногообеспечения такой сложный. Дело в том, что начинаем мы с уровня тре�бований, на котором размышляем только о том, что нужно пользовате�лям от системы, не задумываясь о деталях реализации, а затем меняемугол зрения, сосредотачиваясь исключительно на проектировании. Приэтом на диаграмме последовательности (см. главу 7) отражено, как взаи�модействуют экземпляры объектов, существующие во время исполнения.Одна из самых трудных проблем при разработке программного обеспе�чения – переход от взгляда на мир с позиции «что делать» к взглядус позиции «как делать». Именно для решения этой задачи и предназна�чен анализ пригодности.

На стадии предварительного проектирования нужно задуматься о воз�можных альтернативных стратегиях и архитектурах, выбор которых за�висит от применяемых технологий. Стоит задуматься и о вопросах про�изводительности системы. Например, может выясниться, что есть дваобъекта, обменивающихся большим количеством данных и при этом свя�занных вычислительной сетью. Это может отрицательно сказаться на

Анализ пригодности

Анализ пригодности76

Прототип




Код

Диаграмма

классов


Модель


области

Модель

прецедентовДиаграмма

последова�

тельности

Диаграмма



Рис. 5.3. Анализ пригодности помогает уточнить тексты прецедентови модель предметной области

производительности. В ходе анализа пригодности вы берете тексты пре�цедентов, изложенные с учетом требований, и на их основе принимаетепредварительные проектные решения.

Любопытно, что в литературе по языку UML эта методика практичес�ки не упоминается. Но наш опыт показывает, что от нее напрямую зависитуспешность работы над проектом.

На рис. 5.3 показано место анализа пригодности в общей картине про�цесса ICONIX.

Основные элементы анализа пригодностиАнализ пригодности выполняет несколько задач в процессе ICONIX. Сра�зу заметим, что по результатам анализа пригодности уточняются и текстыпрецедентов, и статическая модель (см. рис. 5.4):

он является средством санитарной проверки (контроля на отсутствиетривиальных ошибок), помогая удостовериться, что тексты преце�дентов корректны и что вы не допустили ошибок при описании пове�дения системы с учетом того набора объектов, с которым придетсяработать. Такое уточнение текста меняет его природу: если раньше мы

77

подходили к прецеденту как к руководству пользователя, то теперьон становится описанием порядка применения в контексте объект�ной модели;он является средством проверки полноты и правильности, давая уве�ренность, что в прецедентах описаны все необходимые альтернатив�ные последовательности (см. главу 3). Наш опыт показывает, что вре�мя, потраченное на рисование диаграмм пригодности и написаниетекстов в строгом соответствии с четкими рекомендациями, обяза�тельно окупается, когда дело доходит до рисования диаграмм после�довательности (см. главу 7);он позволяет обнаруживать новые объекты, а это особенно важно, по�скольку почти наверняка вы что�то пропустите на этапе моделиро�вания предметной области. Кроме того, несоответствия и конфликтыв именовании объектов выявляются еще до того, как они стали при�чиной серьезных затруднений. И наконец, анализ пригодности помо�гает выявить граничные и сущностные классы до того, как вы при�ступите к рисованию диаграмм последовательности;он выполняет функции предварительного проектирования, о чем упо�миналось в начале этой главы.

Теперь подробно рассмотрим три стереотипа, применяемые к объектамна этапе анализа пригодности:

граничные объекты – это такие объекты, с которыми непосредственновзаимодействуют актеры (например, пользователи) в разрабатываемой

Основные элементы анализа пригодности

Полны?Правильны?

Обнаружение объектовпроизводится на основе

анализа прецедентов.

Рассмотрены все альтернативныепоследовательности? Идентифицированывсе функции? Откуда поступают данные?

Добавить при необходимости новыеклассы. Включить в классы атрибуты.

Модель предметной области превратилась в детальную статическую модель.Эта эволюция шла по пути углубленного исследования прецедентов.

Рис. 5.4. Обратная связь между моделью пригодности и статической моделью


системе. К ним относятся экранные формы, диалоговые окна и меню.Если у вас есть прототип ГИП, то многие из основных граничныхобъектов можно себе представить. Если вы следовали рекомендаци�ям, изложенным в главе 3, то легко извлечете граничные объекты изтекстов прецедентов;сущностные объекты часто отображаются на таблицы базы данныхи файлы, содержащие информацию, которая должна «пережить»время выполнения прецедента. Отдельные сущностные объекты, на�пример результаты поиска, являются временными и исчезают, когдапрецедент завершается. Многие сущностные объекты приходят измодели предметной области;управляющие объекты (контроллеры) заключают в себе логику при�ложения. Они служат соединительной тканью между пользователя�ми и хранимыми данными. Именно в них инкапсулируются бизнес�правила и стратегии. Идея заключается в том, чтобы локализоватьизменения в этих объектах, не трогая интерфейса пользователя и схе�мы базы данных. Изредка (примерно в 20% случаев) контроллерыоказываются реальными объектами в проекте, но обычно они выпол�няют задачу контейнеров и напоминают о функциональности и пове�дении, диктуемых прецедентами.

Анализ пригодности для прецедента выполняется путем исследованияего текста – предложение за предложением, изображения актеров, гранич�ных и сущностных объектов и контроллеров, а также связей между раз�личными элементами на диаграмме. И главная, и все альтернативные по�следовательности должны уместиться на одной диаграмме.

Существует четыре основных правила:

1. Актеры могут общаться только с граничными объектами.2. Граничные объекты могут общаться только с контроллерами и акте�

рами.3. Сущностные объекты могут общаться только с контроллерами.4. Контроллеры могут общаться с граничными объектами, сущностны�

ми объектами и другими контроллерами, но не с актерами.

Не забывайте, что граничные и сущностные объекты обозначаются су�ществительными, а контроллеры – глаголами. Существительные не могутобщаться с другими существительными, а глаголы могут общаться какс существительными, так и с глаголами.

На рис. 5.5 показаны правила построения диаграмм пригодности.Рецензент диаграммы пригодности должен суметь прочесть описание

последовательности действий в тексте прецедента, провести пальцем вдоль

79

ассоциаций на диаграмме и увидеть точное соответствие между текстоми картинкой. Возможно, придется переписать текст прецедента, чтобыустранить неоднозначность и ввести явные ссылки на граничные и сущ�ностные объекты. Немногим удается написать идеальный текст прецеден�та с первой попытки.

Результаты анализа пригодности используются не только для улуч�шения текста прецедента, но и для постоянного уточнения статическоймодели. Новые объекты, которые обнаруживаются по мере рисования диа�грамм, должны войти в диаграммы классов. На этой стадии основные ат�рибуты уместно включить в некоторые из наиболее важных классов.

10 самых распространенных ошибокпри анализе пригодности – Top 10

Перечислим типичные ошибки, которые наши студенты допускают прианализе пригодности:

Разрешено Запрещено

Рис. 5.5. Правила построения диаграмм пригодности

Ошибки при анализе пригодности


#10Нарушают одно или несколько правил построения диаграмм при�годности.Эти правила предназначены прежде всего для того, чтобы придатьвашему тексту четкую глагольно�именную структуру и предотвра�тить распределение поведения между объектами до того, как бу�дет собрана информация для принятия правильных проектныхрешений. (Подробно о распределении поведения рассказываетсяв главе 7, посвященной диаграммам последовательности.) Прави�ла, касающиеся граничных объектов, помогут определить грани�цы системы, за которыми располагаются все участвующие в пре�цедентах актеры.

#9Не используют анализ пригодности для структурирования тек�стов прецедентов.Паттерн граничный объект–контроллер–сущностный объект будетвстречаться во многих диаграммах пригодности. Он тесно связансо структурой предложения в английском (да и в русском) языке:подлежащее–сказуемое–дополнение. Применяйте анализ пригод�ности, чтобы повысить уровень стилистического единства преце�дентов и улучшить их восприятие и дальнейшее сопровождение.

#8Не отражают альтернативные последовательности на диаграм�мах пригодности.Анализу пригодности следует подвергнуть весь текст прецедента,а не только главную последовательность. Нередко самые интерес�ные аспекты поведения системы проявляются как раз в контекстеальтернативных последовательностей, так что их рассмотрение иг�рает огромную роль при моделировании. Анализ пригодности так�же поможет обнаружить пропущенные альтернативные последова�тельности, особенно если вы будете снабжать контроллеры такимиметками, как «Проверить» или «Проконтролировать».

#7Не используют анализ пригодности для проверки согласованностиимен классов на диаграммах классов и в текстах прецедентов.Описание порядка применения системы в контексте объектной мо�дели – это волшебная формула, помогающая при построении по�лезных диаграмм последовательности. Именуя граничные и сущ�ностные объекты в прецедентах, вы значительно облегчите себежизнь при создании диаграмм – нужно будет всего лишь нарисо�вать упомянутые в прецеденте объекты в верхней части диаграм�мы для этого прецедента.

81

#6Распределяют поведение между классами прямо на диаграмме при�годности.Мы уже говорили, что контроллеры – это контейнеры для функ�циональности и поведения системы. Не следует начинать проек�тировать методы классов на диаграмме пригодности, посколь�ку вы еще не располагаете достаточной информацией. Решенияо том, как распределить поведение, будут приниматься в ходеразработки диаграмм последовательности.

#5Включают слишком много или слишком мало контроллеров.Мы рекомендуем от двух до пяти контроллеров на одной диа�грамме пригодности. Если в прецеденте есть лишь один контрол�лер, то, скорее всего, ваши прецеденты слишком малы, и каждыйиз них описывает тот или иной аспект поведения системы недо�статочно полно. Если же на одной диаграмме оказывается болеедесяти контроллеров, то следует подумать о разбиении прецеден�та на несколько более мелких.

#4Тратят слишком много времени на шлифовку диаграмм пригодности.Диаграмму пригодности можно в какой�то мере уподобить старте�ру, который запускает процесс преобразования прецедентов в объ�ектно�ориентированный проект. Анализ пригодности – это инстру�мент, помогающий обнаружить объекты, распределить атрибутыклассов и проверить тексты прецедентов на полноту и правиль�ность. Но, решив эти задачи, не следует доводить диаграммы при�годности до состояния рабочего продукта. Это средство достиже�ния цели, а не сама цель.

#3Пытаются выполнять детальное проектирование на диаграммахпригодности.Концепция временных (позже выбрасываемых) диаграмм полезнав контексте предварительного проектирования, но перестает бытьтаковой, когда дело доходит до детального проектирования. Длянего больше всего подходят диаграммы последовательности. В хо�де анализа пригодности нужно быстро пробежаться по всем сце�нариям и извлечь из этого максимальную пользу для проекта. Еслипредварительное проектирование будет занимать столько же вре�мени, сколько детальное, то преимуществ быстрой «санитарнойпроверки» никто не заметит.

#2Не выполняют визуальной сверки текста прецедента с диаграммойпригодности.

Ошибки при анализе пригодности


Мы настоятельно рекомендуем, чтобы рецензирование текстов пре�цедентов и диаграмм пригодности выполнялось не вами, а колле�гой, который должен сверить все ассоциации на диаграмме с описа�нием прецедента. Не считайте работу над прецедентом законченной,пока этот простой визуальный тест не будет выполнен. Если егопройдут все прецеденты, то следующий шаг – рисование диаграммпоследовательности – окажется гораздо проще, чем если бы выприступили к нему с нечеткими набросками текстов абстрактныхпрецедентов.

#1Не обновляют статическую модель.Вы обязательно должны обновить модель предметной области,прежде чем покончить с анализом пригодности и перейти к моде�лированию взаимодействий с помощью диаграмм последователь�ности. Ведь нельзя же приписать поведение классу, которого нетв статической модели.

УпражненияПостарайтесь найти десять ошибок, которые часто возникают при выпол�нении анализа пригодности. На первой диаграмме из каждой пары допу�щено три или четыре таких ошибки. Ваша задача – исправить их. На вто�рой диаграмме приведены правильные решения и пояснения по поводутого, какие правила были нарушены.


Упражнение 1а. Регистрация

Начальная Страница

Страница Регистрации

Проверить введеннуюинформацию

КлиентСчет

счетчикНеправильныхПаролей()

вводит данные и нажимаеткнопку Зарегистрироваться

нажимает кнопкуЗарегистрироваться

#8

#10

#6

#8

Рис. 5.6. Регистрация

Главная последовательность. Клиент нажимает кнопку Зарегистрироваться на Началь�ной Странице. Система выводит Страницу Регистрации. Клиент вводит свой код и па�роль и нажимает кнопку Зарегистрироваться. Система сравнивает введенную информациюс данными, хранящимися в Счете, после чего открывает Начальную Страницу.

Альтернативные последовательности. Если Клиент нажимает кнопку Новый счет наСтранице Регистрации, то система вызывает прецедент Открыть Счет. Если Клиент на�жимает кнопку Вспомнить на Странице Регистрации, то система выводит секретный во�прос, хранящийся для данного Клиента, в отдельном диалоговом окне. Когда Клиент щелкаетв этом окне по кнопке OK, система возвращается к Странице Регистрации.


Упражнение 1б. Регистрация

Вывод

Проверить


Клиент


ДиалоговоеОкно Напоминания Счет

нажимает OK

вводит данныеи нажимает кнопку

Зарегистрироваться



Рис. 5.7. Регистрация


граничный объект Начальная Страница общается с граничным объектом Страница Ре�гистрации и сущностным объектом Счет;для объекта Счет определен метод;альтернативные последовательности не представлены.

85

Упражнение 2а. Поиск по Автору


Искать поАвтору

Создать

Страница Поиска

РезультатыПоиска

Извлечь Детали

Каталог(из Логического Взгляда

на Систему)

Книга(из Логического Взгляда


Страница РезультатовПоиска

Клиент

выбирает книгу

вводит имя автора;нажимает кнопку

Искать

Добавить в Корзину

#5

#10

#5

Рис. 5.8. Поиск по Автору

Главная последовательность. Клиент вводит имя Автора на Странице Поиска, пос�ле чего нажимает кнопку Искать. Система проверяет, что Клиент ввел допустимый запрос,после чего ищет в Каталоге все удовлетворяющие ему Книги. Для каждой найденной Кни�ги система извлекает существенные детали, после чего выводит список Книг на СтраницеРезультатов Поиска, отсортированный по датам издания в порядке убывания. В каждойстроке появляется пиктограмма обложки, название Книги и имена Авторов, средний Рей�тинг и кнопка Добавить в корзину. Клиент нажимает кнопку Добавить в корзину для вы�бранной книги. Система передает управление прецеденту Добавить Товар в Корзину.

Альтернативные последовательности: ...не задан критерий поиска ... книг не найдено...Клиент выходит, не выполнив поиск...


Упражнение 2б. Поиск по Автору


Отобразить

ПроверитьЗапрос на Поиск

Создать




Каталог(из Логического Взгляда


Книга(из Логического Взгляда



Клиент

выбирает книгу

вводит имя автора,нажимает кнопку

Искать


книг ненайдено

не введен запрос

[обратите внимание наотсутствующую стрелку]


Система извлекает существенные детали о каждой найденной Книге и помещает эту ин�формацию на Страницу Результатов Поиска, после чего выводит Страницу Результа�тов Поиска.


слишком мало контроллеров. Контроллер Проверить запрос на поиск введен для того,чтобы система не тратила времени на поиск с незаданным критерием, а контроллер Выве�сти – это стандартный для Web�страниц механизм (такие контроллеры отражают, кромепрочего, альтернативные последовательности, которые не были показаны на предыдущейдиаграмме);сущностный объект Результаты Поиска общается с граничным объектом Страница Ре�зультатов Поиска;в прецеденте не отражено создание объекта Результаты Поиска.


ОбновитьКоличество

ИзменитьСтоимость

Вывести

Удалить Товар

Страница Просмотра Корзины

Товар(из Логического Взгляда


Корзина(из Логического Взгляда


Клиент

изменяет количество;нажимает кнопку

Обновить


Заказ на Покупку Корзина

ТоварСтрокаЗаказа

#1#7

#5

Рис. 5.10. Изменить Содержимое Корзины

Упражнение 3а. Изменить Содержимое Корзины

Главная последовательность. На Странице Просмотра Корзины Клиент изменяетколичество в Строке Заказа и нажимает кнопку Обновить. Система сохраняет новое количе�ство, после чего вычисляет и показывает новую стоимость по этой строке. Клиент нажимаеткнопку Продолжаю Покупать. Система возвращает управление вызывающему прецеденту.

Альтернативные последовательности:

1. Если Клиент изменяет количество на 0, то система удаляет Товар из Корзины.2. Если Клиент нажимает кнопку Удалить вместо кнопки Обновить, то система удаляет Товар

из Корзины.3. Если Клиент нажимает кнопку Оформить Заказ вместо кнопки Продолжаю Покупать, сис�

тема передает управление прецеденту Оформить Заказ.


Упражнение 3б. Изменить Содержимое Корзины

ОбновитьКоличествои Стоимость

ИзменитьСтоимость




Корзина(из Логического Взгляда


Клиент

изменяет количество;нажимает кнопку

Обновить


Заказ на Покупку Корзина

ТоварСтрокаЗаказа количество

стоимость

Рис. 5.11. Изменить Содержимое Корзины

На Странице Просмотра Корзины Клиент изменяет количество Товара и нажимаеткнопку Обновить. Система сохраняет новое количество, после чего вычисляет и показывает но�вую стоимость этого Товара.


контроллер Изменить стоимость не нужен, так как и он, и контроллер Обновить коли�чество работают с одним и тем же объектом Товар;в прецеденте говорится о Строке Заказа, хотя из диаграмм классов и пригодности ясно,что речь должна идти о Товаре (такая несогласованность в именовании может привестик очень серьезным последствиям);на выдержке из диаграммы классов не показаны атрибуты, упомянутые в тексте прецедента.


Упражнение 4а. Доставить Заказ

Прервать ИзменитьСостояние

Извлечь МетодДоставки

Отобразить МетодДоставки

Интерфейс Доставщика

Консоль наУчастке Упаковки

Устройство СчитыванияШтрих#Кодов

Заказ(из Логического

Взгляда на Систему)

Упаковщик Доставщик

считывает штрих�код

изменитьСтатус()извлечьМетодДоставки()

#6

#3

Рис. 5.12. Доставить Заказ

Главная последовательность. Упаковщик проверяет, что Товары, пере�численные в упаковочном листе, который приложен к Заказу, соответствуюятфизическим товарам. Упаковщик считывает штрих�код на упаковочном листе,пользуясь устройством считывания. Состояние Заказа изменяется на «готовит�ся к доставке». Метод доставки выводится на консоль участка доставки.

Упаковщик взвешивает физические Товары, пакует Товары, наклеивает накладную, со�ответствующую методу доставки, считывает штрих�код с накладной, посылает заказ через уполно�моченного Поставщика.

Альтернативная последовательность. Если Упаковщик обнаруживает несоответствиемежду Заказом и физическими товарами, то он прекращает обработку Заказа, пока это не�соответствие не будет устранено.

#9


Упражнение 4б. Доставить Заказ

ИзменитьСостояние




Консоль наУчастке Упаковки

Устройство СчитыванияШтрих#Кодов




считывает штрих�код [обратите внимание наотсутствующий контроллер]

Рис. 5.13. Доставить Заказ

Система изменяет состояние на «готовится к доставке», после чего извлекает Метод До�ставки, указанный Клиентом для данного Заказа, и выводит его на консоль участка до�ставки.


контроллер Прервать – это конструкция, относящаяся к этапу детального проектирования;для объекта Заказ приведены методы;текст прецедента содержит глаголы в страдательном залоге и по сравнению с диаграммойпригодности не вполне точен.

91

Упражнение 5а. Просмотреть Недавние Заказы


Извлечь НедавниеЗаказы


Извлечь ДеталиЗаказа

Страница ПросмотраЗаказов

СтраницаДеталей Заказа

Таблица Заказов(из Логического




Клиент

Заказ

иддатаРазмещениядатаДоставкиполучательномерДоставкистатусметодДоставки

Счет

идПользователяпарольнапоминаниеemailАдрес

#1

#8

#10

Рис. 5.14. Просмотреть Недавние Заказы

Главная последовательность. Система находит Заказы, которые Клиент разместил втечение последних 30 дней, и выводит данные о них на Страницу Просмотра Заказов. Вкаждой строке указан идентификатор (в виде гиперссылки), дата, состояние, получатель и Ме�тод Доставки Заказа. Клиент щелкает по гиперссылке. Система извлекает данные о со�держимом Заказа и выводит эту информацию в режиме чтения на Странице Деталей За�каза. Клиент нажимает кнопку OK для возврата к Странице Просмотра Заказов. Закончивпросмотр, Клиент щелкает по ссылке Ведение счета на Странице Просмотра Заказов. Си�стема возвращает управление вызывающему прецеденту.

Альтернативная последовательность. Если Клиент не разместил за последние 30 днейни одного Заказа, то на Странице Просмотра Заказов появится соответствующая инфор�мация.


Упражнение 5б. Просмотреть Недавние Заказы








Таблица Заказов(из Логического


Клиент

Заказ

Счет

Таблица Заказов



Рис. 5.15. Просмотреть Недавние Заказы


граничный объект Страница Деталей Заказа общается с граничным объектом Страни�ца Просмотра Заказов;не показано, что происходит, если Клиент в последнее время не размещал заказов;на выдержке из диаграммы классов не отражен только что выявленный класс Таблица За�казов.

93

Модель предметной области с атрибутами классовНа рис. 5.16 изображена диаграмма классов, включающая некоторые ат�рибуты классов из примера книжного Internet�магазина.

Заказ

Книга

названиеценадатаПубликациипиктограммадоступноеКоличествоминимальныйОстатокскидкаиздатель

Счет


датаРазмещениястатуспозиция : Vector

Издательство

названиедатаПубликации

Запасы

минимальныйОстатокдоступноеКоличество

Товар

количествоцена


типКредитнойКартыномерКредитнойКарты

Тарифная Политика

ценаскидка

Рецензия

рейтинг

Результаты Поиска

Корзина

Метод Доставки

Статус

Детали Заказа


ПользовательМенеджерРегистрации


Каталог



Рис. 5.16. Модель предметной области с атрибутами классовдля книжного Internet)магазина

Модель предметной области с атрибутами классов

Глава 6. Рецензированиепредварительного проектаРецензирование предварительного проекта (РПП) включает анализ диа�грамм пригодности и текстов прецедентов для каждого сценария с цельюудостовериться, что они соответствуют друг другу и с достаточной степеньюполноты и правильности описывают требуемое поведение системы. Крометого, данная процедура должна убедить вас, что модель предметной областине противоречит диаграммам пригодности (в частности, что все сущностныеобъекты, присутствующие на диаграммах пригодности, представлены в мо�дели). Другими словами, мы проверяем идентификацию всех объектов изпространства задачи, необходимых для реализации требуемого поведения.

Кроме того, данный вид рецензирования нужен, чтобы проверить, всемли сущностным классам заданы атрибуты и можем ли мы проследить по�ток данных от экранных форм системы (которые к этому моменту должныбыть поименованы) к сущностным классам и, вероятно, к некоторым таб�лицам базы данных. Мы также должны проанализировать выбранную тех�ническую архитектуру и убедиться, что проект, к разработке которого мыприступаем, может быть реализован в рамках этой архитектуры.

На рис. 6.1 показано, в какой точке мы находимся.

Веха 2: рецензирование предварительного проекта

Напишите описания прецедентов # главные и альтернативные последовательностидействий.

Выполните анализ пригодности. Для каждого прецедента:

# выявите приблизительный начерно набор объектов, участвующих в сценарии. Воспользуйтесь стереотипами, входящими в состав UML Objectory;

# дополните диаграмму классов из модели предметной области вновь выявленными объектами и их атрибутами.

Доведите диаграмму классов до состояния, соответствующего моментузавершения этапа анализа проекта.

Рис. 6.1. Рецензирование предварительного проекта и процесс ICONIX

95

Основные элементы рецензированияпредварительного проекта

В процедуре рецензирования предварительного проекта должны прини�мать участие представители заказчика и разработчика, а кроме того заин�тересованные менеджеры, точно так же, как в процедуре рецензированиятребований. Однако есть и важное отличие: это последний шанс для заказ�чика изменить требования перед тем, как программисты начнут писать код,реализующий данный набор прецедентов. Можно представлять себе РППкак рубеж, за которым заказчик уже не может активно участвовать в про�цессе. Ранее мы уже говорили, что прецеденты – это контракты между за�казчиками и разработчиками; в ходе РПП эти контракты подписываются.

В главе 5 упоминалось, что на этапе анализа пригодности выполняется«санитарная проверка», благодаря которой выясняется, правильны ли пре�цеденты и не содержит ли описанное поведение системы явных ошибокс учетом рабочего набора объектов.

Такое уточнение прецедентов изменяет природу текстов: если раньше ониносили характер руководства пользователя, то теперь становятся описаниемпорядка применения в контексте объектной модели. В центре РПП долженбыть анализ текстов всех прецедентов и диаграмм пригодности. Каждыйрецензент должен выполнить следующие действия для всех прецедентов:

прочитать последовательность действий;визуально проследить ассоциации на соответствующих диаграммахпригодности;убедиться в наличии соответствия между текстом и картинкой.

На рис. 5.5 показаны результаты анализа пригодности. При условии, чтовсе граничные и сущностные объекты – существительные, а контроллеры –глаголы, видно, что существительные не могут общаться с существительны�ми, тогда как глаголы могут общаться и с глаголами, и с существительными.Ваша цель – классифицировать поведение прецедента в виде управляющихобъектов (контроллеров). Это означает, что нужно встать на точку зрениячитателя пользовательского руководства и выявить все имеющие местологические функции, а затем перефразировать текст прецедента так, что�бы в нем была отчетливо видна структура «подлежащее–сказуемое–до�полнение». Когда мы доберемся до детального проектирования, такаяструктура позволит проверить правильность, то есть убедиться, что ниодна существенная особенность поведения не забыта. К тому же при этомвырабатывается общий для всего коллектива стиль записи прецедентов.

Мы уже упоминали, что глаголы в тексте прецедента соответствуютконтроллерам на диаграммах пригодности. Контроллеры инкапсулируют

Элементы РПП

Рецензирование предварительного проекта96

поток управления и служат «клеем» между граничными и сущностнымиобъектами. Они называются контроллерами, а не управляющими объек�тами потому, что выполняют функцию контейнеров, – мы еще не готовыотнести представляемое ими поведение к какому�либо объекту, посколь�ку не располагаем достаточной информацией. Принимать решения о том,какие методы должны войти в граничные и сущностные объекты, а такжео том, какие контроллеры претендуют на роль настоящих объектов в ста�тической модели, пока преждевременно. Мы сделаем это в процессе ра�боты над диаграммами последовательности, а не пригодности.

На диаграмме пригодности стрелки, соединяющие объекты разных ти�пов, могут быть направлены как в одну, так и в обе стороны. Стрелка, на�правленная от граничного объекта к управляющему, указывает на то, чтопервый требует от последнего какой�то работы. Двусторонняя стрелкамежду управляющим и сущностным объектом показывает, что они оба чи�тают и записывают данные. Отметим, однако, что следует пользоватьсятолько одним видом стрелок, что нетипично для некоторых других типовUML�диаграмм. В отличие от диаграмм последовательности, стрелки надиаграммах пригодности не представляют программные сообщения – онипросто обозначают коммуникационные ассоциации. Поскольку никакойкод на основе этих диаграмм не создается, сконцентрируйте внимание налогическом потоке управления в прецедентах, а задуматься о направлениистрелок можно будет позже, при составлении диаграмм последователь�ности.

Не забывайте, впрочем, о наличии паттернов в диаграммах пригоднос�ти. Часто паттерны начинают выявляться в ходе анализа пригодности. Дляобнаружения паттернов, связанных с прецедентами, применяются двестратегии: управление на экране и контроллер прецедента (см. книгу «UseCase Driven Object Modeling»). Забегая вперед, скажем, что паттерны про�ектирования могут оказаться чрезвычайно полезными при работе над диа�граммами последовательности и диаграммами классов уровня проектиро�вания. Но на диаграммах пригодности не следует рисовать паттерны вовсей их полноте; достаточно задуматься о том, как вы смогли бы приме�нить их на этапе детального проектирования.

В начале главы мы употребили термин «техническая архитектура». Онописывает все основные технологические решения, которые вы собирае�тесь применять при реализации системы. Это и выбор языка программи�рования (скажем, Java или Visual Basic), и способ создания и распределе�ния программных компонентов (к примеру, Enterprise Java Beans (EJB)и Java Server Pages (JSP) или технологии Distributed Component Object Mo�del (DCOM) и Active Server Pages (ASP) от Microsoft). Решение о выборе

97

технической архитектуры может быть до некоторой степени отражено надиаграммах пригодности.

Если, например, вы остановились на архитектуре EJB и JSP, то диа�грамма пригодности будет в большей степени тяготеть к паттерну управ�ление на экране, нежели при использовании «чистых» HTML�страниц.Таким образом, анализ пригодности, основная задача которого – быстрополучить неформальное описание проекта, позволяет выяснить, будет ливыбранная техническая архитектура удовлетворительно работать для рас�сматриваемых сценариев, а рецензирование диаграмм становится провер�кой «жизнеспособности» архитектуры.

Продолжим нашу мысль по поводу паттернов. Концепция временныхдиаграмм полезна на этапе предварительного проектирования, но переста�ет быть таковой, когда речь заходит о детальном проектировании. Для эта�па детального проектирования больше всего подходят диаграммы после�довательности. В ходе анализа пригодности нужно быстро просмотреть всесценарии и попытаться извлечь из этого максимальную пользу для проек�та. Если предварительное проектирование будет занимать столько же вре�мени, сколько детальное, то преимущества быстрой «санитарной провер�ки» будут сведены на нет.

Анализ пригодности позволяет тщательно просмотреть всю модельпрецедентов на предмет повторного использования еще до того, как утвер�жденные прецеденты станут основой детального проектирования. Поисквозможностей повторного использования также помогает выявить объекты,пропущенные при моделировании предметной области. Перед тем как за�вершить анализ пригодности и перейти к моделированию взаимодействий,вы должны обновить статическую модель (см. главу 7). Новые объекты, об�наруженные при рисовании диаграмм пригодности и в ходе бесед с заказ�чиками, должны быть включены в диаграмму классов сейчас, а не позже.

Это также подходящий момент для включения в некоторые наиболееважные классы основных атрибутов. Кстати, об атрибутах: когда мы поме�щаем окна и экранные формы – в виде граничных объектов – на диаграммыпригодности, то начинаем прослеживать ассоциированные с этими объек�тами данные до сущностного объекта, являющегося их источником или по�требителем. Естественным результатом этого процесса как раз и являетсявключение атрибутов в классы из модели предметной области.

10 самых распространенных ошибок прирецензировании предварительного проекта – Top 10

Перечислим типичные ошибки, которые наши студенты допускают прирецензировании предварительных проектов:

Ошибки при РПП


#10Не доводят до сведения заказчиков, что это их последний шанс из�менить поведение системы перед тем, как будет выпущена перваяверсия.Анализ пригодности – это стадия, в ходе которой прецедентыутверждаются и разработчики готовятся перейти к этапу деталь�ного проектирования. Ваша цель – зафиксировать прецеденты доначала рисования диаграмм последовательности. Таким образом,заказчик должен подписаться под каждым прецедентом, рассмот�ренным в ходе РПП. Если позволить заказчикам впоследствииизменять прецеденты, то вы рискуете нарваться на проблемы,пытаясь что�то спроектировать с учетом постоянно обновляемыхтребований.

#9Не проверяют, что тексты прецедентов и диаграммы пригоднос�ти соответствуют друг другу.Рецензент диаграммы пригодности должен прочитать последова�тельность действий, описанную в прецеденте, провести пальцем поассоциациям на диаграмме пригодности и убедиться в наличии со�ответствия между текстом и картинкой. Если рецензент не смогэтого сделать, нужно либо переписать текст прецедента, либо пере�рисовать диаграмму, либо сделать то и другое. Не стоит переходитьк составлению диаграммы последовательности для прецедента,пока этот простой тест не пройден! Для этой процедуры, по наше�му мнению, хорошо подходит название устранение противоречий.Мы предпочитаем не заниматься разработкой проекта, требованияк которому противоречивы, если этого можно избежать.

#8Не добавляют новые объекты в модель предметной области.Одна из причин проведения анализа пригодности состоит в том,чтобы ускорить переход от начальной модели предметной области(пространства задачи) к конечной модели классов (пространствурешения). Окончательная модель создается путем назначения по�ведения всем объектам, участвующим в прецедентах. Но правиль�но сделать это не удастся, если на статической модели не обозна�чены все классы.

#7Не занимаются поиском атрибутов классов из предметной области.После проведения анализа пригодности для данного набора пре�цедентов у вас должно образоваться достаточно полное множествоатрибутов классов. Ранее мы уже говорили, что многие из этих ат�рибутов должны соответствовать элементам граничных объек�

99

тов, например полям экранных форм. Другие атрибуты в большейстепени связаны с внутренней функциональностью системы.Если не выявить их до перехода к рисованию диаграмм последо�вательности, решения о том, какие операции принадлежат конк�ретным классам, будут недостаточно обоснованными. В духеобъектно�ориентированного проектирования мы стремимся по�мещать операции туда, где располагаются данные. Но при нашемподходе такие решения принимаются в два этапа: данные опреде�ляются в ходе предварительного проектирования, а функции – входе детального проектирования.

#6Считают, что операции следует включать в классы в ходе РПП.В главе 5 мы говорили о том, что контроллеры являются контейне�рами для функциональности и поведения системы. Не следует на�чинать распределение методов между классами в ходе работы наддиаграммой пригодности, поскольку вы еще не обладаете всей ин�формацией. Заниматься этим нужно по мере составления диаграммпоследовательности (см. главу 7).

#5Не напоминают заказчикам, что текст прецедента – это контрактмежду ними и разработчиками.В главе 7 рассказывается о том, как разместить текст прецедентана соответствующей ему диаграмме последовательности. В резуль�тате требования к поведению системы будут у вас перед глазамивсе время, пока вы занимаетесь проектированием. Таким образом,проектировщики вынуждены постоянно помнить о природе преце�дента как договора между заказчиками и разработчиками. РПП –это этап, на котором данное положение следует довести до созна�ния заказчика.

#4Требуют, чтобы в предварительном статическом проекте широкоиспользовались паттерны проектирования. О преждевременном рассмотрении паттернов говорилось в главе 2.В эту ловушку часто попадаются на этапе анализа пригодностии РПП. Выявлять прецеденты на диаграммах пригодности – нор�мальное явление, особенно если их легко удается отобразить нашироко известные или изобретенные вами паттерны. А вот превра�щать простые паттерны, обнаруженные в предварительном проектена диаграммах пригодности, в паттерны этапа детального проек�тирования нельзя. Отложите это до разработки диаграмм после�довательности и диаграмм классов уровня проектирования.

Ошибки при РПП


#3В ходе анализа пригодности не обращают внимания на правило«глагол–существительное».На диаграммах последовательности существительные вполне мо�гут общаться с существительными. Это связано с тем, что глаголыпредставляют сообщения между объектами, а значит, граничныеобъекты могут общаться с другими граничными объектами, сущ�ностные – с другими сущностными объектами, и граничные объ�екты – с сущностными. Тем не менее на диаграммах пригодностисуществительные могут общаться только с глаголами, но не с дру�гими существительными. Имеются правила, позволяющие удо�стовериться, что прецедент сформулирован правильно с учетомстандартной структуры предложения на естественном языке (под�лежащее–сказуемое). Эти правила надо соблюдать, так как сущест�вительные и глаголы требуется выявить до составления диаграммпоследовательности. Единый стиль записи всех прецедентов по�может без труда перейти к диаграммам последовательности, осно�ванным на прецедентах.

#2Ожидают, что на диаграммах пригодности будет показан полныйдетальный проект, тогда как на самом деле они служат для офор�мления концептуального проекта.Мы уже говорили, что на диаграммах пригодности не должно бытьни методов, ни паттернов проектирования, поэтому вряд ли вы уди�витесь, услышав, что в ходе РПП не следует углубляться и в любыедругие аспекты детального проекта. Кроме того, прецеденты, диа�граммы классов и диаграммы последовательности остаются неотъ�емлемой частью проекта, тогда как диаграммы пригодности обыч�но выбрасываются (хотя многие предпочитают сохранять и их,особенно если это часть визуальной модели; ничего плохого в этомнет). Поэтому не стоит тратить время, доводя диаграммы пригод�ности до совершенства.

#1Тратят много времени на размышления о том, куда должна бытьнаправлена стрелка, вместо того чтобы быстро убедиться, что всеварианты поведения учтены.Анализ пригодности – это всего лишь неформальная техника, помо�гающая зафиксировать прецеденты, выявить новые объекты и под�готовить почву для детального проектирования. Диаграммы при�годности – не более чем средства на пути достижения этой цели.Глупо тратить силы на рисование стрелок. Ваше внимание должнобыть сосредоточено на совершенствовании диаграмм последова�тельности, а не на возне с диаграммами пригодности.

Глава 7. ДиаграммыпоследовательностиПо завершении рисования диаграмм пригодности и рецензирования пред�варительного проекта наступает очередь детального проектирования. Цельанализа пригодности (предварительного проектирования) – выявить объ�екты. На этапе же детального проектирования мы занимаемся распреде�лением функций программы между этими объектами. Данная глава посвя�щена диаграммам последовательности как основному элементу детальногопроектирования или, по крайней мере, динамической части объектноймодели.

Выполнив предварительное проектирование с помощью анализа при�годности, мы возвращаемся к нашим сценариям и изучаем их более деталь�но. Мы хотим пересмотреть первые неформальные предположения о коопе�рации объектов и уточнить свои представления. К этому моменту должныбыть выполнены две задачи. Во�первых, тексты прецедентов должны бытьполными, правильными, детализированными и недвусмысленными. Во�вторых, следует выявить большую часть необходимых объектов по край�ней мере на концептуальном уровне абстракции.

На рис. 7.1 показано место диаграмм последовательности в общей кар�тине процесса ICONIX.

Основные элементы диаграмм последовательностиПри моделировании взаимодействий вам предстоит выполнить три основ�ные задачи:

распределить поведение между граничными, сущностными и управля�ющими объектами.Во время анализа пригодности вы выявили (или хотя бы постаралисьвыявить) набор объектов, которые в совокупности способны обеспечитьтребуемое прецедентами поведение, а также разбили это поведение надискретные блоки и создали управляющие объекты�контейнеры длякаждого такого блока. Теперь нужно решить, какие объекты отвечают закаждый конкретный аспект поведения. Если вы не уверены в том, чтопредставляют собой граничные, сущностные и управляющие объекты,

102 Диаграммы последовательности

то размышлять над тем, как распределить между ними поведение, еще ра�новато. Вернитесь к анализу пригодности и разберитесь в этом вопросе;детально показать взаимодействия между объектами, участвующи�ми в каждом прецеденте.Во время выполнения программы объекты взаимодействуют, посы�лая друг другу сообщения. Джекобсон называет их стимулами, имеяв виду, что сообщение побуждает объект выполнить то или иное дей�ствие. Для каждого аспекта поведения в прецеденте вы должны иден�тифицировать необходимые сообщения/методы;закончить распределение операций по классам.Нужно стремиться к тому, чтобы значительная часть атрибутов (до75–80%) была включена в статическую модель по завершении ана�лиза пригодности. Что же касается определения операций в ходе мо�делирования предметной области и анализа пригодности, мы реко�мендуем не усердствовать. Более того, лучше вообще не определятьникаких методов во время предварительного проектирования. Этосвязано с тем, что на данных этапах у вас еще нет информации, доста�точной для принятия грамотных проектных решений. (Подумайтесами: пока не закончено составление диаграмм пригодности, вы ещедаже не выявили всех объектов, а попытка распределить поведение

Прототип




Код

Диаграмма

классов


Модель


области

Модель


Диаграмма


Диаграмма



Рис. 7.1. Распределение поведения между классами

103Элементы диаграмм последовательности

по неполному набору объектов может быть ошибочной.) Однако припереходе к моделированию взаимодействий информации уже доста�точно – по крайней мере, хочется на это надеяться. Изображая дета�ли поведения объектов на диаграммах последовательности, вы долж�ны окончательно определиться с тем, куда отнести все атрибутыи операции. Выполняя такое динамическое моделирование, вы про�должаете модифицировать и расширять статическую модель, улуч�шая понимание того, как должна работать система.

Диаграммы последовательности в том виде, в каком они существуютв UML, получены от диаграмм взаимодействия объектов Джекобсонаи диаграмм трассировки событий, заимствованных из методики OMT.В процессе ICONIX диаграммы последовательности – это основной рабочийпродукт проектирования. Для каждого прецедента создается диаграмма, опи�сывающая как главную, так и все альтернативные последовательности дей�ствий. (При необходимости можно расположить ее на нескольких страни�цах.) В результате получается ядро динамической модели, в котором оченьподробно определено поведение системы во время выполнения и то, какреализуется это поведение.

Диаграмма последовательности (рис. 7.2) состоит из четырех основныхэлементов:

текста последовательности действий в прецеденте, который записы�вается сверху вниз по левой стороне. Разумно разбить текст на фраг�менты, отделив их пустыми строками, чтобы было видно, каким эле�ментам диаграммы (в правой части) соответствует каждое предложение;объектов, перенесенных прямо с диаграммы пригодности и представ�ленных в виде прямоугольников, в которых в формате «объект:класс»записывается имя или номер экземпляра объекта и имя класса объек�та. Любое имя может быть опущено. Объекты можно также изобра�жать в виде стереотипов, заимствованных из диаграмм пригодности;часто это помогает проследить сообщения, которыми обмениваютсяактеры, граничные и сущностные объекты;сообщений, изображаемых стрелками, которые направлены от одногообъекта к другому. Стрелка может соединять две пунктирные линии,линию и прямоугольник, представляющий метод, или два таких пря�моугольника;методов (операций), представляемых в виде прямоугольников. Онирасположены на пунктирных линиях, соответствующих тем объек�там, которым методы принадлежат. Длину прямоугольника можноиспользовать для того, чтобы показать фокус управления в последо�вательности: метод владеет управлением вплоть до точки, в которой


Модельпрецедентов

Диаграммапоследовательности

Диаграммапригодности

Главная:

Альтернативные:

Текст прецедента уточняется в ходе анализа пригодностии согласуется во время рецензирования предварительного проекта.

Главная и альтернативныепоследовательности

действий

1. Скопируйте текст прецедента в левое поле диаграммы последовательности.

2. Добавьте сущностные объекты.3. Добавьте граничные объекты.

4. Рассмотрите контроллеры по очереди и решите, как распределить поведение между кооперирующимися объектами.

На всем протяжении работы над проектированием системымы учитываем требования пользователя.

Рис. 7.2. Основные элементы диаграмм последовательности

прямоугольник кончается. Увы, понятие фокуса управления пред�ставляется полезным лишь с теоретической точки зрения, так как напрактике большинство средств визуального моделирования не слиш�ком хорошо поддерживает эту возможность. Если не удается пока�зать фокус управления на диаграмме, просто отключите его отоб�ражение, чтобы ничто не отвлекало вас от действительно важнойработы.

Введение в диаграммы последовательностиНаш опыт показывает, что на этой стадии разработки проекта возникаетмного проблем (особенно если был пропущен этап предварительного про�ектирования). Описываемая ниже техника помогла слушателям разрешитьих в ходе проведения разных семинаров на протяжении последних лет.

На рис. 7.2 показаны четыре этапа рисования диаграмм последователь�ности в процессе ICONIX:

1. Скопируйте текст прецедента из спецификации. Вставьте его в ле�вое поле страницы. Текст на диаграмме будет постоянно напоминать

105Введение в диаграммы последовательности

о том, чего вы хотите добиться. В результате требования к поведе�нию системы будут находиться у вас перед глазами на протяжениивсего процесса проектирования. Заметим, что если в прецеденте неописаны альтернативные последовательности действий, то присту�пать к рисованию диаграммы последовательности не следует. Такаядиаграмма не отразит поведение прецедента во всей полноте; значит,вы не выявите все необходимые методы.

2. Добавьте сущностные объекты, представленные на диаграмме при�годности. Каждый из них – это экземпляр некоторого класса, изобра�женного на диаграмме классов в статической модели. (Если вы забы�ли обновить статические диаграммы классов сразу после обнаруженияновых объектов на этапе анализа пригодности, сделайте это сейчас.У этих объектов уже должна быть проставлена боˆльшая часть атрибу�тов. Многие из них будут выступать в качестве данных, передавае�мых другим объектам.) Можно надеяться, что пропущенные атрибутывы обнаружите по ходу работы над диаграммой последовательности.Не забудьте добавить их в статическую модель, так как, по всей веро�ятности, это последний шаг перед написанием кода.

3. Добавьте граничные объекты и актеров из диаграммы пригодности.Мы не говорили о добавлении граничных объектов в модель пред�метной области, поскольку они принадлежат пространству решения,а не пространству задачи. Показав граничные объекты на диаграм�мах последовательности, вы делаете первый шаг к объединению двухэтих пространств.Если вы придерживаетесь методологии ICONIX, то первые три шагадолжны выполняться механически. (На самом деле нам удалось свес�ти их к программе, которая создает основу диаграммы последователь�ности. Если вы пользуетесь программой Rational Rose, то можете за�грузить написанный для нее сценарий со страницы http://www.iconixsw.com/RoseScripts.html. Похожие средства разрабатываютсяи для других инструментальных систем, например GDPro компанииEmbarcadero и Together/J компании TogetherSoft.) Такого рода сред�ства автоматизации очень воодушевляют, если вы серьезно относи�тесь к проектированию.

4. Определите, какие методы и в какие классы поместить – это суть мо�делирования взаимодействий.Распределение методов по классам предполагает, в частности, преоб�разование контроллеров, изображенных на диаграммах пригодности,в методы и сообщения, реализующие нужное поведение. (Кстати,контроллер можно превратить и в настоящий управляющий объект.)В связи с этим мы рекомендуем использовать диаграмму пригодности


как контрольный список, дабы убедиться, что на диаграммах последова�тельности учтены все требования к поведению системы. Вы просто вы�черкиваете управляющий объект по мере того, как соответствующиеему сообщения наносятся на диаграммы последовательности. Таким об�разом, вы избавите себя от ошибок типа «ой, про эту функцию я и поза�был», которые проявляются в самый неподходящий момент. Заметим,что один контроллер на диаграмме пригодности может транслировать�ся в несколько методов на диаграмме последовательности.Существует два метода преобразования контроллеров: управление наэкране и контроллер прецедента. Если вы последовательно придержи�ваетесь того или иного подхода при составлении диаграмм последова�тельности для всех прецедентов, то можно сказать, что вы пользуетесьпаттернами. Идея в том, чтобы все члены коллектива, отвечающие задиаграммы, определили еще на ранних стадиях работы некие стандар�ты и следовали им при рассмотрении всех прецедентов.

Теперь взглянем на проблему с другой стороны. При моделированиивзаимодействий между различными объектами большую пользу могут ока�зать стандартные паттерны, описанные, например, в книге Эриха Гаммы(Erich Gamma), Ричарда Хелма (Richard Helm), Ральфа Джонсона (RalphJohnson) и Джона Влиссидеса (John Vlissides) «Design Patterns» (издатель�ство Addison�Wesley, 1995)1. Возможно, вы сами разработаете новые пат�терны для стандартизации решения задач, возникающих в несколькихпрецедентах. Настало время обратиться к статической модели, отразитьпроектные решения на диаграммах классов, а затем нарисовать соответ�ствующие диаграммы последовательности. Именно здесь и проявляетсявся мощь объектно�ориентированного проектирования.

Вы уже сверяли диаграммы пригодности с текстами прецедентов. Со�поставление диаграмм последовательности и пригодности добавит уверен�ности, что вы проектируете то, что нужно пользователю.

10 самых распространенных ошибок присоставлении диаграмм последовательности – Top 10

Типичные ошибки, которые наши студенты допускают при рисовании диа�грамм последовательности:

#10Составляют диаграммы последовательности не для каждого пре�цедента.Джекобсон ясно описал необходимость моделирования взаимо�действий в книге, посвященной реорганизации бизнес�процессов

1 Русский перевод: «Паттерны проектирования» (Питер, ДМК, 2001).

107Ошибки при составлении диаграмм

(«The Object Advantage», Addison�Wesley, 1995): «Только после то�го, как будут нарисованы диаграммы взаимодействий (в UML на�зываемые диаграммами последовательности) для всех последова�тельностей событий во всех прецедентах, можно быть уверенным,что полностью выявлены роли, которые каждый объект может ис�полнять в системе, а значит, и задачи каждого объекта».

#9Не размещают на диаграмме последовательности текст преце�дента.Размещение текста прецедента, отражающего требования заказчи�ка (уточненного в ходе анализа пригодности), на полях диаграммпоследовательности позволяет визуально проследить, как требова�ния превращаются в проект. Разработчики затратили много уси�лий на создание текстов прецедентов, а заказчики подписались подними. Диаграмма должна соответствовать словесному описаниюконкретного прецедента.

#8Предварительно не выявляют все необходимые объекты на диа�грамме пригодности.Если вы испытываете затруднения, приступая к составлению диа�граммы последовательности, то, вероятно, вы либо плохо записа�ли прецедент, либо плохо провели анализ пригодности. Наличиехороших диаграмм пригодности вкупе с четко определенными пре�цедентами значительно упрощает задачу.

#7Не показывают визуального соответствия между текстом преце�дента и стрелками, обозначающими сообщения.Каждое предложение и, если необходимо, даже части предложениядолжны быть окружены пустыми строками и находиться напротиводного или нескольких сообщений, которые соответствуют опи�сываемому поведению. Это позволит читателям диаграммы сразуувидеть, как система реализует то, что описывает прецедент.

#6Не показывают деталей, оставляя диаграммы последовательнос�ти на высоком уровне абстракции.На диаграммах пригодности можно опускать детали, посколькуперед нами лишь предварительный проект системы. Диаграммыже последовательности – это последняя остановка перед началомкодирования, так что на них должны быть изображены все деталипроекта.

#5Превращают диаграммы последовательности в блок�схемы вместотого, чтобы использовать их для распределения поведения междуобъектами.


Не забывайте, что диаграмма последовательности – это основнойинструмент для принятия решений о распределении поведения.По сути дела, она нужна именно для того, чтобы расписать опе�рации классов, а значит, не стоит помечать стрелки�сообщениясвободным текстом – нужно сопоставить стрелке имя сообщения,которое совпадает с именем операции класса. (К примеру, в про�грамме Rational Rose связывание имени со стрелкой производит�ся щелчком правой кнопкой мыши по стрелке; при этом програм�ма обеспечивает визуальную обратную связь, отображая скобкипосле имени операции.) Распределение поведения (принятие ре�шений об отнесении операций к конкретным классам) – это осно�ва процесса ICONIX. Решения, принятые на этом этапе работы,определяют качество проекта в целом.

#4Обращают внимание не на интересные методы (которые, собст�венно, и реализуют поведение), а на методы чтения и установкиатрибутов.Изучая динамическое поведение системы, вы приходите к выводамо том, какие атрибуты и операции необходимы в классах, описан�ных статической моделью. Добавляйте в классы атрибуты и методы,как только примете решение на основе диаграммы последователь�ности. Но не стоит тратить слишком много времени, вырисовываяна диаграммах стрелочки с метками "getAttribute" и "setAttribute".Конечно, мы не имели ничего против принципа инкапсуляции дан�ных – доступ к атрибутам должен производиться только с помощьюсоответствующих методов. Просто не надо все эти методы рисоватьна диаграммах.

#3Не задумываются о том, в каком направлении рисовать стрелку(то есть какой объект владеет в данный момент управлением).Сообщения, которыми обмениваются объекты, приводят к вызо�ву операций классов. На диаграммах пригодности направлениестрелок несущественно, а на диаграммах последовательности иг�норировать этот вопрос уже нельзя. Поток управления долженбыть показан точно, всегда должно быть понятно, какой объектявляется вызывающим, а какой – вызываемым.

#2При распределении поведения не придерживаются базовых принци�пов объектно�ориентированного проектирования.Класс должен отвечать за связанное множество функций. Можнопровести параллель с известным правилом, гласящим, что объектыдолжны быть плотными и слабо связанными. Еще два принципа,

109

которых следует придерживаться, – это повторное использование(чем более общими являются объекты и классы, тем выше вероят�ность, что их можно будет использовать в других проектах) и при�менимость (включая в класс метод, спросите себя, уместен ли онв этом классе и действительно ли задача, которую этот метод ре�шает, имеет отношение к данному классу).

#1Не обновляют статическую модель по мере построения локальныхдиаграмм классов для каждого пакета прецедентов.На диаграммах из модели предметной области нужно не только от�ражать «чистое» множество доменных классов, но и рисовать «ло�кализованные» статические диаграммы классов, на которых по�казываются объекты из пространства задачи и из пространстварешения. Мы рекомендуем создать по одной такой диаграмме накаждый пакет прецедентов. Добравшись до различных инфраструк�турных классов, поместите и их на статическую диаграмму. Лока�лизованные диаграммы классов хороши прежде всего тем, что за�нимают мало места по сравнению со статической моделью, котораяразрастется настолько, что изобразить ее на одной диаграмме до�вольно трудно. Кроме того, эта техника позволяет распределитьработу между несколькими группами.

Ошибки при составлении диаграмм


УпражненияС помощью парных упражнений, относящихся к книжному Internet�мага�зину, можно проверить, способны ли вы найти те десять ошибок, которыечасто возникают при составлении диаграмм последовательности. В первомупражнении из каждой пары допущено три или четыре таких ошибки.Ваша задача – исправить их. Во втором упражнении приведены верныерешения и пояснения по поводу того, какие правила были нарушены.



1 :

Кл

ие

нт

2 :

Стр

ан

иц

а П

ои

ска

3 :

Стр

ан

иц

а Р

езу

льт

ато

вП

ои

ска

4 :

Ка

тал

ог

5 :

Кн

ига

Гла

вна

я п

осл

ед

ова

тел

ьно

сть

Кл

ие

нт

вво

ди

т и

мя

Авт

ор

а н

а С

тра

ни

це

По

иск

а и

на

жи

ма

ет

кно

пку

Иск

ать

.

Си

сте

ма

пр

ове

ряе

т, ч

то К

ли

ен

т вв

ел

до

пус

тим

ый

за

пр

ос,

по

сле

че

го и

ще

тв

Ка

тал

оге

все

Кн

иги

ука

зан

но

го а

вто

ра

.

Дл

я ка

жд

ой

на

йд

ен

но

й К

ни

ги с

ист

ем

аи

звл

ека

ет

сущ

ест

вен

ны

е д

ета

ли

.

За

тем

си

сте

ма

вы

вод

ит

на

Стр

ан

иц

еР

езу

льт

ато

в П

ои

ска

сп

исо

к К

ни

г, о

тсо

р+

тир

ова

нн

ый

по

да

там

изд

ан

ия

в п

ор

ядке

убы

ван

ия.

В к

аж

до

й с

тро

ке о

тоб

ра

жа

етс

яп

икт

огр

ам

ма

об

ло

жки

, на

зва

ни

е К

ни

гии

им

ен

а А

вто

ро

в, с

ре

дн

ий

Ре

йти

нг

и к

но

пка

До

ба

вить

в к

ор

зин

у.

Кл

ие

нт

на

жи

ма

ет

кно

пку

До

ба

вить

в ко

рзи

ну

дл

я вы

бр

ан

но

й к

ни

ги. С

ист

ем

ап

ер

ед

ае

т уп

ра

вле

ни

е п

ре

це

де

нту

До

ба

вить

То

вар

в К

ор

зин

у.

Ал

ьте

рн

ати

вны

е п

осл

ед

ова

тел

ьно

сти

Есл

и к

ли

ен

т н

аж

ал

кн

оп

ку И

ска

ть,

не

вве

дя

зап

ро

са, т

о с

ист

ем

а в

ыво

ди

тсо

об

ще

ни

е о

б о

ши

бке

и п

ре

дл

ага

ет

зад

ать

кр

ите

ри

й п

ои

ска

.

Есл

и с

ист

ем

а н

е н

ахо

ди

т К

ни

г д

ан

но

гоА

вто

ра

, он

а в

ыво

ди

т со

отв

етс

твую

ще

есо

об

ще

ни

е и

пр

ед

ла

гае

т К

ли

ен

ту з

ад

ать

др

уго

й к

ри

тер

ий

по

иск

а.

Есл

и К

ли

ен

т п

оки

да

ет

стр

ан

иц

у,н

е н

аж

ав

кно

пку

До

ба

вить

в к

ор

зин

у,си

сте

ма

во

звр

ащ

ае

т уп

ра

вле

ни

ето

му

пр

ец

ед

ен

ту, и

з ко

тор

ого

бы

л в

ызв

ан

да

нн

ый

.

Пе

ре

да

ть у

пр

авл

ен

ие

пр

ец

ед

ен

ту Д

об

ави

тьв

Ко

рзи

ну.

на

По

иск

()

пр

ове

ри

тьП

ои

ско

вый

За

пр

ос(

)

по

иск

По

Авт

ор

у()

по

луч

ить

Де

тал

и()

ото

бр

ази

ть()

на

До

ба

вле

ни

еВ

Ко

рзи

ну(

)

ото

бр

ази

тьО

ши

бку

ИП

овт

ор

ить

()

ото

бр

ази

тьО

ши

бку

ИП

овт

ор

ить

()

#8

#3

#2

Упражнение 1a. Поиск по Автору



1 :

Кл

ие

нт

Пе

ре

да

ть у

пр

авл

ен

ие

пр

ец

ед

ен

ту Д

об

ави

тьв

Ко

рзи

ну.

3 :

Стр

ан

иц

аР

езу

льт

ато

в П

ои

ска

2 :

Стр

ан

иц

аП

ои

ска

5 :

Кн

ига

4 :

Ка

тал

ог

6 :

По

иск

Гла

вна

я п

осл

ед

ова

тел

ьно

сть

Кл

ие

нт

вво

ди

т и

мя

Авт

ор

а н

а С

тра

ни

це

По

иск

а и

на

жи

ма

ет

кно

пку

Иск

ать

.

Си

сте

ма

пр

ове

ряе

т, в

вел

ли

Кл

ие

нт

до

пус

тим

ый

за

пр

ос,

по

сле

че

го и

ще

тв

Ка

тал

оге

все

Кн

иги

ука

зан

но

го а

вто

ра

.

Дл

я ка

жд

ой

на

йд

ен

но

й К

ни

ги с

ист

ем

аи

звл

ека

ет

сущ

ест

вен

ны

е д

ета

ли

.

За

тем

си

сте

ма

вы

вод

ит

на

Стр

ан

иц

еР

езу

льт

ато

в П

ои

ска

сп

исо

к К

ни

г, о

тсо

р+

тир

ова

нн

ый

по

да

там

изд

ан

ия

в п

ор

ядке

убы

ван

ия.

В к

аж

до

й с

тро

ке о

тоб

ра

жа

етс

яп

икт

огр

ам

ма

об

ло

жки

, на

зва

ни

е К

ни

гии

им

ен

а А

вто

ро

в, с

ре

дн

ий

Ре

йти

нг

и к

но

пка

До

ба

вить

в к

ор

зин

у.

Кл

ие

нт

на

жи

ма

ет

кно

пку

До

ба

вить

в ко

рзи

ну

дл

я вы

бр

ан

но

й к

ни

ги. С

ист

ем

ап

ер

ед

ае

т уп

ра

вле

ни

е п

ре

це

де

нту

До

ба

вить

То

вар

в К

ор

зин

у.

Ал

ьте

рн

ати

вны

е п

осл

ед

ова

тел

ьно

сти

Есл

и к

ли

ен

т н

аж

ал

кн

оп

ку И

ска

ть,

не

вве

дя

зап

ро

са, т

о с

ист

ем

а в

ыво

ди

тсо

об

ще

ни

е о

б о

ши

бке

и п

ре

дл

ага

ет

зад

ать

кр

ите

ри

й п

ои

ска

.

Есл

и с

ист

ем

а н

е н

ахо

ди

т К

ни

г д

ан

но

гоА

вто

ра

, он

а в

ыво

ди

т со

отв

етс

твую

ще

есо

об

ще

ни

е и

пр

ед

ла

гае

т К

ли

ен

ту з

ад

ать

др

уго

й к

ри

тер

ий

по

иск

а.

Есл

и К

ли

ен

т п

оки

да

ет

стр

ан

иц

у,н

е н

аж

ав

кно

пку

До

ба

вить

в к

ор

зин

у,си

сте

ма

во

звр

ащ

ае

т уп

ра

вле

ни

ето

му

пр

ец

ед

ен

ту, и

з ко

тор

ого

бы

л в

ызв

ан

да

нн

ый

.

на

По

иск

()

пр

ове

ри

тьП

ои

ско

вый

За

пр

ос(

)

по

иск

По

Авт

ор

у()

по

луч

ить

Де

тал

и()

ото

бр

ази

ть()

ото

бр

ази

ть()

созд

ать

()

на

До

ба

вле

ни

еВ

Ко

рзи

ну(

)

ото

бр

ази

тьО

ши

бку

ИП

овт

ор

ить

()

ото

бр

ази

тьО

ши

бку

ИП

овт

ор

ить

()

Упражнение 1б. Поиск по Автору


не показан объект Результаты Поиска. Его следовало выявить на этапе анализа пригод�ности, поскольку все содержимое каталога, очевидно, выводиться не будет;страница Поиска посылает сообщение отобразить, хотя из диаграммы следует, чтоуправлением владеет объект Каталог.объект Каталог дважды вызывает метод отобразитьОшибкуИПовторить страницыПоиска.

113У

пр

ажн

ени

я

У

пр

ажн

ени

е 2a. Регистр

аци

я

Ри

с. 7.5

. Ре

гистр

аци

я

1 : Клиент 2 : Начальная Страница 3 : СтраницаРегистрации

4 : ОкноНапоминания

5 : Счет

Главная последовательность

Клиент нажимает кнопкуЗарегистрироваться на НачальнойСтранице. Система выводит СтраницуРегистрации. Клиент вводит свой коди пароль и нажимает кнопкуЗарегистрироваться. Системасравнивает введенную информациюс данными, хранящимися в Счете, послечего возвращает Клиента на НачальнуюСтраницу.

Если Клиент нажимает кнопку Вспомнитьна Странице Регистрации, то системавыводит секретный вопрос для негов отдельном диалоговом окне. КогдаКлиент нажимает кнопку OK, системавозвращается на Страницу Регистрации.

Если Клиент ввел код, который неизвестенсистеме, она выводит соответствующеесообщение и предлагает Клиенту либонабрать другой код, либо нажать кнопкуНовый счет.

Если Клиент набрал неправильный пароль,то система выводит соответствующеесообщение и предлагает повторно ввестипароль.

Вызвать прецедентОткрыть Счет.

наРегистрацию()

отобразитьОшибкуИПовторить()


заморозить()

отобразить()



проверитьРегистрационнуюИнформацию()


наOK()


наНовыйСчет()

Клиент нажимает кнопку Вспомнить

Альтернативные последовательности

Если Клиент нажимает кнопку НовыйСчет на Странице Регистрации, тосистема вызывает прецедент ОткрытьСчет.

Если Клиент три раза подряд набралнеправильный пароль, система выводитсообщение с предложением обратитьсяв службу работы с клиентами, и СтраницаРегистрации становится неактивной.

#5

#7

#3

114Д

иагр

амм

ы п

оследовательн

ости



5 : Счет


Клиент нажимает кнопкуЗарегистрироваться на НачальнойСтранице.


Если Клиент нажимает кнопку Новыйсчет на Странице Регистрации, тосистема вызывает прецедент ОткрытьСчет.

Если Клиент нажимает кнопку Вспомнитьна Странице Регистрации, то системавыводит секретный вопрос для негов отдельном диалоговом окне. КогдаКлиент нажимает кнопку OK, системавозвращается на Страницу Регистрации.









проверитьРегистрационнуюИнформацию


наОК()



наНапоминание()

Клиент вводит свой код и парольи нажимает кнопку Зарегистрироваться.

Система сравнивает введеннуюинформацию с данными, хранящимисяв Счете, после чего возвращает Клиентана Начальную Страницу.

Если Клиент набрал код, которыйнеизвестен системе, она выводитсоответствующее сообщениеи предлагает Клиенту либо ввести другойкод, либо нажать кнопку Новый счет.


Если Клиент три раза подряд набралнеправильный пароль, то система выводитсообщение с предложением обратитьсяв службу работы с клиентами, и СтраницаРегистрации становится неактивной.

[обратите внимание на пустое место]

Ри

с. 7.6

. Ре

гистр

аци

я

У

пр

ажн

ени

е 2б. Реги

страц

ия

На пр

еды

дущ

ей д

иагр

амм

е:

текст прецед

ента не выровнен со стрелкам

и�сооб

щени

ями

;об

ъект С

чет

посылает сооб

щени

е отобразить

, хотя из д

иаграм

мы

вид

но, что управлени�

ем в этот м

омент влад

еет страница

Регистрации

;стр

елка, ассоци

ир

ованная с последовательностью

напоминание

, помечена своб

одны

мтекстом

, а не им

енем м

етода.

115У

пр

ажн

ени

я

Ри

с. 7.7

. До

ставить З

аказ

2 : Доставщик1 : Упаковщик 3 : Устройство СчитыванияШтрих+Кодов

4 : Консоль на УчасткеДоставки

5 : Заказ

считатьШтрих+Код()

сменитьСтатус()

получитьМетодДоставки()

отобразитьМетодДоставки()

#9

#3

#8

У

пр

ажн

ени

е 3а. До

ставить Заказ

116Д

иагр

амм

ы п


ости

У

пр

ажн

ени

е 3б. Д

остави

ть Заказ

На пр

еды

дущ

ей д

иагр

амм

е:

в левой части

отсутствует текст прецед

ента;отсутствует об

ъект И

нтерфейс

Поставщика

. Так как Упаковщик

общ

ается непосредствен�

но с Поставщиком

, то на ди

аграмм

е не показано, как регистри

руется факт д

оставки;

объ

ект Устройство

Считывания

получает управление, хотя в д

анной си

туации

это нело�ги

чно.

Ри

с. 7.8

. До

ставить З

аказ

1 : Упаковщик 2 : Доставщик 3 : УстройствоСчитывания

Штрих+Кодов

4 : Консольна УчасткеДоставки

5 : ИнтерфейсДоставщика


Упаковщик проверяет,что товары, перечисленныев упаковочном листе для данногоЗаказа, соответствуют физическипредставленным товарам.

Система изменяет состояние Заказана "готовится к доставке".

Затем система находит МетодДоставки для данного Заказа,указанный Клиентом, и выводитего на Консоль Участка Доставки.

Упаковщик взвешивает физическиетовары и пакует Товары. ТакжеУпаковщик наклеивает накладную,соответствующую методу доставки.



сменитьСтатус()


получитьПакет()

Упаковщик считывает штрих+кодыс упаковочного листа.

Упаковщик отправляет бандерольпри помощи соответствующегоДоставщика.

Альтернативная последовательность

Если Упаковщик обнаруживаетнесоответствия между заказаннымии физическими товарами, он прекращаетобработку Заказа до устраненияпроблемы.

[обратите внимание на наличие текста прецедента]

6 : Заказ

117У

пр

ажн

ени

я

Ри

с. 7.9

. Изм

ен

ить С

од

ер

жи

мо

е К

ор

зин

ы

1 : Клиент


На Странице Просмотра Корзины Клиентизменяет количество Товара и нажимает кнопкуОбновить.

Система сохраняет новое количество, послечего вычисляет и показывает новую стоимостьданного Товара.

Клиент нажимает кнопку Продолжаю Покупать.Система возвращает управление вызывающемупрецеденту.


Если Клиент изменяет количество Товара на 0,то система удаляет Товар из Корзины.

Если Клиент нажимает кнопку Удалить,а не Обновить, то система удаляетТовар из Корзины.

Если Клиент нажимает кнопку ОформитьЗаказ, а не Обновить, система передаетуправление прецеденту Оформить Заказ.

Передача управления прецеденту ОформитьЗаказ

Передать управлениепрецеденту Оформить

Заказ.

наОбновление()

отобразитьСтоимость()

обновитьКоличествоИСтоимость()

получитьПозицию()

удалитьПозицию()



наУдаление()

наПродолжениеПокупки()

наПодтверждениеЗаказа()

3 : Товар2 : Корзина 4 : Корзина

#6

#2

#4

У

пр

ажн

ени

е 4а. И

змен

ить С

од

ерж

им

ое К

ор

зин

ы

118Д

иагр

амм

ы п


ости

У

пр

ажн

ени

е 4б

. Изм

ени

ть Со

дер

жи

мо

е Ко

рзи

ны

На пр

еды

дущ

ей д

иагр

амм

е:

второй вы

зов метод

а получитьПозицию

только загромож

дает д

иаграм

му;

объ

ект Товар

посылает сооб

щени

е удалитьПозицию

объ

екту Корзина

;отсутствую

т сообщ

ения у

ничтожить

, что мож

ет свид

етельствовать о серьезном упущ

ении

проектировщ

ика, поскольку об

ъекты

Товар

не удаляю

тся (если только си

стема не б

удет на�

писана на язы

ке типа Java, которы

й автом

атически

«соберет м

усор»).

Ри

с. 7.1

0. И

зме

ни

ть Со

де

рж

им

ое

Ко

рзи

ны

1 : Клиент


Заказ.


[обратите внимание на

отсутствие сообщения]



Система сохраняет новое количество, послечего вычисляет и показывает новую стоимостьданного Товара.




Если Клиент нажимает кнопку Удалить,а не Обновить, то система удаляетТовар из Корзины.

Если Клиент нажимает кнопку ОформитьЗаказ, а не Обновить, система передаетуправление прецеденту Оформить Заказ.

Передача управления прецеденту ОформитьЗаказ






уничтожить()







119У

пр

ажн

ени

я

У

пр

ажн

ени

е 5а. Пр

осм

отр

еть Нед

авни

е Заказы

Ри

с. 7.1

1. П

ро

смо

тре

ть Не

давн

ие

Заказы

1 : Клиент 2 : Страница ПросмотраЗаказов

3 : Страница ДеталейЗаказа

4 : Таблица Заказов 5 : Заказ


Система находит Заказы, которые Клиентсделал в течение последних 30 дней,и выводит соответствующие данныена Страницу Просмотра Заказов.В каждой строке указаны идентификаторЗаказа (в виде гиперссылки), датаи состояние Заказа, получатель и МетодДоставки. Клиент щелкает по гиперссылке.Система извлекает данные о содержимомЗаказа и выводит эту информациюв режиме чтения на Странице ДеталейЗаказа. Клиент нажимает кнопку OK длявозврата к Странице Просмотра Заказов.Закончив просмотр Заказов, Клиентщелкает по ссылке Ведение счета наСтранице Просмотра Заказов. Системавозвращает управление вызывающемупрецеденту.


Если Клиент не сделал за последние30 дней ни одного Заказа, то системавыводит на Странице Просмотра Заказовсоответствующее сообщение.

наНажатиеСвязи()

наУправлениеСчетом()

отобразитьНедавниеЗаказы()

получитьНедавниеЗаказы()

получитьДетали()


наОК


отобразитьСообщениеНетЗаказа()

#7 #8

#2

120Д

иагр

амм

ы п


ости

1 : КлиентГлавная последовательность

Система находит Заказы, которыеКлиент сделал в течение последних30 дней, и выводит соответствующиеданные на Страницу Просмотра Заказов.В каждой строке указаны идентификаторЗаказа (в виде гиперссылки), датаи состояние Заказа, получатель и МетодДоставки.

Клиент щелкает по гиперссылке.Система извлекает данные о содержи+мом Заказа и создает объект ДеталиЗаказа. Содержимое этого объектавыводится в режиме чтения на СтраницеДеталей Заказа.

Клиент нажимает кнопку OK для возвратак Странице Просмотра Заказов.

Закончив просмотр Заказов, Клиентщелкает по ссылке Ведение счета наСтранице Просмотра Заказов. Системавозвращает управление вызывающемупрецеденту.


Если Клиент не разместил за последние30 дней ни одного Заказа, то системавыводит на Странице Просмотра Заказовсоответствующее сообщение



отобразитьНазванияЗаказов()

отобразитьСообщениеНетЗаказов()

получитьЗаказы()


создать()



наОК



2 : СтраницаПросмотра Заказов

6 : ДеталиЗаказа

4 : ТаблицаЗаказов

5 : Заказ[обратите внимание

на пустое место]

Ри

с. 7.1

2. П

ро

смо

тре

ть Не

давн

ие

Заказы

У

пр

ажн

ени

е 5б. П

ро

смо

треть Н

едавн

ие Заказы

На пр

еды

дущ

ей д

иагр

амм

е:

текст прецедента не вы

ровнен со стрелками

�сообщ

ениям

и;

отсутствует объ

ект Детали

Заказа

, который

долж

ен бы

ть выявлен на этапе анали

за при�

годности

. Вот почему текст прецед

ента неверен;объект Т

аблица

Заказов

вызы

вает метод о

тобразитьСообщениеНетЗаказов

объектаСтраница

Просмотра

Заказов

. Мы

не приветствуем идею

о том, чтобы

таблицы базы

дан�ны

х или замещ

ающ

ие их объекты (proxy) вы

зывали м

етоды пользовательского интерф

ейса.

121Диаграммы классов уровня проектирования

Рис. 7.13. Статическая модель книжного Internet%магазина (часть 1)

«boundary»Страница Ошибки

отобразитьОтсутствиеИмени()отобразитьНеверныйПочтовыйАдрес()отобразитьНеверныйПароль()

«boundary»Страница Поиска

наПоиск()проверитьПоисковыйЗапрос()отобразитьОшибкуИПовторить()



Издатель


Запасы




«boundary»Страница Нового Счета

отобразитьСтраницу()ввестиТекст()наНажатиеСоздать()

«boundary»Начальная Страница

наРегистрацию()отобразить()названиеОперации()

«boundary»Страница Напоминания

отобразить()наНажатиеOK()

«boundary»Страница Результатов Поиска

отобразить()наДобавлениеВКорзину()

«entity»Каталог

поискПоАвтору()

«entity»Результаты Поиска

создать()

рейтинг

«boundary»Страница Деталей Заказа

отобразить()наOK()

«entity»Корзина

удалитьПозицию()получитьПозицию()

«boundary»Страница Регистрации

отобразить()наРегистрацию()отобразитьОшибкуИПовторить()заморозить()наНовыйСчет()наНапоминание()

«boundary»Страница Корзины

наОбновление()отобразитьСтоимость()наПродолжениеЗакупки()наУдаление()наПроверку()удалитьПозицию()

«boundary»Страница Просмотра Заказов

отобразитьПоследниеЗаказы()наНажатиеСвязи()отобразить()наУправлениеСчетом()отобразитьСообщениеНетЗаказов()

«entity»Товар

количествостоимость

обновитьКоличествоИСтоимость()уничтожить()получитьПозицию()

«entity»Книга

заголовокценадатаПубликациипиктограммадоступноеКоличествоминимальныйОстатокскидкаиздатель


Рецензия

записать()

Клиент(из Взгляда с Точки

Зрения Прецедентов)

ввод данных и нажатие кнопкиЗарегистрироваться

нажатиекнопки OK

нажатие кнопкиЗарегистрироваться

ввод имени автора

выбор книги

изменениеколичества











«entity»Таблица Заказов


«entity»Страница Деталей Заказа

отобразить()наНажатиеОК()

«entity»Детали Заказа

создать()получитьДетали()



«entity»менеджерРегистраций


наОбновление()отобразитьСтоимость()наПродолжениеПокупки()наУдаление()наПроверку()удалитьПозицию()


наОбновление()наНажатиеСвязи()отобразить()наУправлениеСчетом()наПроверку()отобразитьСообщениеНетЗаказа()


отобразить()наРегистрацию()отобразитьОшибкуИПовторить()заморозить()наНовуюРегистрацию()наНапоминание()

«entity»Счет


счетчикНеверныхПаролей()задатьИмя()задатьEmail()задатьПароль()проверитьСчет()


иддатаРазмещениядатаДоставкиполучательномерДоставкистатусспособДоставкикодВнешнейБазыДанных

сменитьСтатус()получитьМетодДоставки()получитьДетали()






ввод данныхи нажатие кнопки




123

Диаграммы классов уровня проектированияНа рис. 7.13–7.15 показана диаграмма классов уровня проектированиядля книжного Internet�магазина. (Классы в левой части рис. 7.13 соответ�ствуют классам в правой части рис. 7.12. Рис. 7.14 аналогичным образомсвязан с рис. 7.13.)



получитьНедавниеЗаказы

«boundary»Интерфейс Доставщика


«boundary»Консоль Участка Доставки


«boundary»Устройство Считывания Штрих+кодов



Предпочтения Пользователя

Статус

«entity»Счет




иддатаРазмещениядатаДоставкиполучательномерДоставкистатусспособДоставкикодВнешнейБазыДанных


Упаковщик(из Взгляда с Точки


Участок Доставки(из Взгляда с Точки


Платежная Информация


считывает штрих коды

Диаграммы классов уровня проектирования

Глава 8. Рецензированиеокончательного проектаПри рецензировании окончательного проекта (РОП) – Critical Design Re�view (CDR) следует удостовериться в том, что все ответы на вопрос как,найденные в ходе детального проектирования, отражены на диаграммахпоследовательности и ассоциированных диаграммах классов и согласуют�ся с тем, что специфицировано прецедентами. Помимо этого необходимоубедиться, что детальный проект достаточно проработан для сравнитель�но простого перехода к этапу кодирования. РОП включает также анализкачества проекта, в том числе модульности, плотности классов, степенисвязанности объектов и других метрик.

На этой стадии вы должны проверить, отвечает ли проект внутреннимстандартам проектирования, принятым в вашей организации. Иногда онитребуют использования паттернов проектирования. Например, может бытьпринято решение об использовании фабрик для создания экземпляровобъектов. Или могут наличествовать стандартные механизмы доступак реляционным базам данных. Диаграммы последовательности и сопут�ствующие им детальные диаграммы классов должны отражать видениепрограммы старшими проектировщиками. На предыдущих этапах мы при�ложили много усилий, чтобы зафиксировать и всесторонне проверить тре�бования к программе. РОП – это последняя остановка перед кодировани�ем, так что нужно этим воспользоваться для устранения неразрешенныхвопросов. На рис. 8.1 показано место РОП в процессе ICONIX.

Основные элементы рецензированияокончательного проекта

Главное, что нужно помнить о РОП, – в нем участвуют исключительно про�ектировщики и разработчики. В главе 6 уже говорилось, что этап рецензи�рования предварительного проекта (РПП) – это последний шанс поучаст�вовать в процессе разработки для большинства представителей заказчика.Если только у заказчика нет специалистов с большим опытом детальногопроектирования, которые должны принять участие в рецензировании окон�чательного проекта (по техническим или политическим мотивам), то вам

125

следует мило улыбнуться и сказать: «Спасибо, дальше этим мы будем за�ниматься сами. Вы уже дважды утвердили спецификации, и теперь они за�морожены до момента создания готового продукта».

Прежде чем приступать к РОП, убедитесь в наличии диаграмм после�довательности для всех прецедентов, которые должны быть реализованыв первой версии продукта. Вспомните цитату из книги Джекобсона, при�веденную в главе 7, – нельзя быть уверенным, что выявлены все обязан�ности каждого объекта, если не нарисованы диаграммы последователь�ности для каждой главной и альтернативной последовательности действийво всех прецедентах. В совокупности эти диаграммы составляют ядро ди�намической модели, на которой должно быть детально показано поведе�ние системы во время выполнения и, в частности, то, как реализуется этоповедение.

Один из важнейших аспектов РОП – это тщательный анализ соответ�ствия между каждым предложением в тексте прецедента и сообщениями на�против этого предложения на диаграммах последовательности, посколькуспециалисты, работавшие над проектом, потратили много сил на выверкутекстов, а заказчики подписались под ними. Кроме того, на моделях при�годности должна быть продемонстрирована реализуемость проекта в кон�тексте объектной модели. Иными словами, должна быть уверенность в том,что найдены объекты, совместная работа которых обеспечивает нужное по�ведение. Теперь настал момент удостовериться, что ответы «как», представ�ленные на диаграммах последовательности, соответствуют требованиям«что», описанным в прецедентах.

Веха 3: рецензирование окончательного проекта

Окончательно оформите статическую модель, добавив детальную проектнуюинформацию (например, видимость атрибутов и паттерны).

Проверьте, отвечает ли ваш проект всем ранее сформулированнымтребованиям.

Распределите поведение. Для каждого прецедента:

! выявите сообщения, которыми должны обмениваться объекты, и методы, которые при этом вызываются. Нарисуйте диаграмму последовательности, на которой слева расположен текст прецедента, а справа ! детали проекта. Добавьте в диаграмму классов вновь обнаруженные атрибуты и операции;

! если хотите, изобразите на диаграмме кооперации основные транзакции между объектами;

! если хотите, используйте диаграмму состояний, чтобы показать реальное поведение во времени.

Рис. 8.1. Рецензирование окончательного проекта и процесс ICONIX

Элементы рецензирования окончательного проекта

Рецензирование окончательного проекта126

Должно быть очевидно, какие сообщения или группы сообщений в пра�вой части диаграммы последовательности соответствуют каждому предло�жению в тексте прецедента как из главной, так и изо всех альтернативныхпоследовательностей. Это очень важно, поскольку дает возможность про�следить связь между проектными решениями и функциональными тре�бованиями. Мы рекомендуем, чтобы старшие проектировщики подверглитакому анализу часть работы, сделанную младшими, и наоборот (вдумай�тесь в это).

Следующее, на что нужно обратить внимание, – это непрерывность со�общений. В главе 7 мы уже говорили, что на диаграммах последовательнос�ти очень важно правильно проставлять направление стрелок�сообщений,тем самым показывая поток управления. В любой момент должно бытьясно, какой объект владеет управлением. Если вы заметите переходы меж�ду объектами, в которых сообщения не участвуют, нужно сказать проекти�ровщикам, чтобы они исправили эту ошибку.

Решения о распределении поведения, принимаемые проектировщика�ми, влияют на качество классов. Халберт (Halbert) и О’Брайен (O’Brien)сформулировали четыре критерия «хорошего» класса:

возможность повторного использования. Чем более общими являют�ся классы и объекты, тем выше вероятность, что вы сможете их ис�пользовать в других проектах. Всегда спрашивайте себя, как скажет�ся добавление нового метода в класс на повторном использовании;применимость. Концепция применимости в контексте моделированиявзаимодействий означает по сути дела то же самое, что и при модели�ровании предметной области или прецедентов. Распределяя методы пообъектам на диаграммах последовательности, всегда задавайте себевопрос, уместен ли данный метод в данном объекте, относится ли за�дача, решаемая этим методом, именно к данному объекту;сложность. Это прямое свидетельство того, насколько серьезно выподходите к реализации. Вопрос ставится так: будет ли проще помес�тить данный метод в этот или какой�то другой объект;знание реализации. Этот критерий связан с таким вопросом: зависит лиреализация поведения от внутренних деталей соответствующего метода.

Возможно, самым важным из этих критериев является применимость.По мере приобретения опыта ООП у вас выработается интуиция, благода�ря которой решения о распределении поведения по объектам на диаграм�мах последовательности будут приниматься сами собой.

Заметим, что эти критерии (и те, что приведены ниже) мы заимствова�ли из книги Грейди Буча «Object�Oriented Analysis and Design with Appli�cations» (Addison�Wesley, 1994).

127

Ну а теперь пришло время подумать о классах и выяснить, отвечают лиони следующим критериям качества:

связанность (coupling) характеризует обилие связей между двумяклассами. Модульность системы повысится, если классы будут сла�бо связанными, то есть мало зависящими друг от друга;плотность (cohesion) характеризует, насколько сильно зависят другот друга атрибуты и операции одного класса. Нужно стремиться к вы�сокой функциональной плотности. Это означает, что для обеспечениячетко определенного поведения нужна слаженная совместная работавсех элементов класса;достаточность (sufficiency) означает, что класс инкапсулирует до�статочное число абстракций, присутствующих в модели, то естьпредставляет собой нечто, с чем можно осмысленно и эффективновзаимодействовать. Главный вопрос – охватывает ли класс все вза�имосвязанные прецеденты;полнота (completeness) характеризует то, в какой мере интерфейскласса покрывает все абстракции, для которых он разработан. Теоре�тически полный класс может повторно использоваться в любых кон�текстах. Но не переусердствуйте в этом направлении, а то может по�лучиться, что вы вообще ничего не построите;примитивность (primitiveness) говорит о том, что операция можетбыть эффективно реализована при наличии доступа к другим уже по�строенным элементам. Идея заключается в том, чтобы одни операциисоздавались как строительные блоки для других.

Еще один критерий качества диаграммы последовательности – это до�статочное количество деталей. Поскольку диаграммы последовательнос�ти – последняя остановка перед кодированием, то на них должен быть от�ражен истинный проект во всех деталях. Не считайте данный этап проектазавершенным, пока все методы, показанные на диаграммах последователь�ности, не будут включены в тот или иной класс из статической модели. Вытакже должны позаботиться о выделении абстрактных и параметризован�ных классов и отношении дружественности и композиции (особенно еслисобираетесь кодировать на языке C++). Следует подумать о том, как будутхраниться устойчивые объекты, и о распределении объектов в системе.

Кстати говоря, если вы программируете на C++ и хотите побольшеузнать о «штучках Буча», мы рекомендуем помимо работы самого Бучакнигу Роберта Мартина (Robert Martin) «Designing Object Oriented C++Applications Using the Booch Method» (Prentice Hall, 1995). Боб написалэту книгу до того, как начал преподавать методологию XP. Вот одна из на�ших любимых цитат: «К чему тратить время на рисование этих диаграмм,

Элементы рецензирования окончательного проекта


если код объясняет все не хуже, а то и лучше? Если ваша задача настолькопроста, как та, что решена выше, действительно можно обойтись без них.Рисование диаграмм для таких простых моделей – бессмысленный педан�тизм. Я рассматриваю эти диаграммы только для того, чтобы продемон�стрировать технику, а не потому, что собираюсь ими пользоваться. Пре�имущества диаграмм становятся очевидными по мере перехода к болеесложным примерам. Диаграммы позволяют на одной странице нагляднопроиллюстрировать концепции, для выражения которых на C++ могло быпотребоваться несколько десятков страниц. Они дают возможность «по�играть» с этими концепциями и изложить их другим людям. Более того,при обсуждении отношения использования мы уже видели, что диаграм�мы позволяют визуализировать зависимости от компилятора, а равно ло�гические и алгоритмические идеи, то есть выразить полный спектр реше�ний о статической и динамической структуре приложения. Мы можем нетолько проверить логическую непротиворечивость проекта, но и посмот�реть, насколько хорошо он вписывается в имеющуюся среду разработки».

Хотя ныне Боб проповедует «Евангелие от XP», мы думаем, что правон был тогда, когда писал эти строки.

Верный признак неконкретной диаграммы последовательности – от�сутствие деталей реализации, например имеющих отношение к распреде�ленности системы. Если вы собираетесь применять такие технологии, какDCOM или EJB, то на диаграммах должны быть отражены элементы, ха�рактерные именно для этих технологий. Помните: нельзя создать код издетального проекта, если связь между проектом и средой, в которой будетработать система, неочевидна.

Рассмотрим проблему с другой стороны. Анализируя взаимодействиямежду различными объектами, вы можете прийти к выводу, что лучше вос�пользоваться каким�то из хорошо известных паттернов проектирования.Например, вы можете выбрать паттерн фабричный метод, в соответствиис которым создание объектов поручается подклассам, или паттерн ите�ратор, который позволяет обходить список, не зная о том, как он реали�зован. Подробнее об этих и других паттернах говорится в книге ЭрихаГаммы, Ричарда Хелма, Ральфа Джонсона и Джона Влиссидеса «Паттерныпроектирования». Возможно, вы решитесь разработать новые паттерныдля решения задач проектирования, возникающих в нескольких прецеден�тах. Именно сейчас наступает подходящий момент, чтобы критически пе�ресмотреть такого рода решения и удостовериться, что они действитель�но уместны, поскольку вскоре их придется переводить в код.

В главе 6 рассматривалось понятие технической архитектуры как на�бора базовых решений о том, какие технологии будут применяться при

129

реализации системы: языки программирования, способы создания и рас�пределения компонентов и т.д. Мы говорили, что решение о техническойархитектуре должно быть отражено на диаграммах пригодности. В ходе ре�цензирования окончательного проекта необходимо еще раз проверить со�ответствие детального проекта выбранной технической архитектуре. Еслиодна из целей рецензирования предварительного проекта – убедитьсяв пригодности архитектуры, то теперь вы должны сосредоточиться на том,как именно в ней будут реализованы все сценарии.

10 самых распространенных ошибок прирецензировании окончательного проекта – Top 10

Перечислим типичные ошибки, допускаемые нашими студентами при ре�цензировании окончательного проекта:

#10Не приглашают технических специалистов для участия в рецензи�ровании проекта.Диаграммы последовательности, как правило, изобилуют деталя�ми, которые имеют смысл разве что для самых технически подко�ванных представителей заказчика. Эти диаграммы предназначеныдля проектировщиков и разработчиков. Поэтому в рецензирова�нии окончательного проекта должны принимать участие толькоэти люди.

#9Не сверяют текст прецедента с соответствующей диаграммойпоследовательности.Рецензент должен суметь визуально сопоставить каждое пред�ложение прецедента с одним или несколькими сообщениями, ко�торые описывают выраженное в этом предложении поведениев терминах взаимодействий объектов. В правой части диаграммыдолжны быть отражены также все альтернативные последователь�ности действий, причем так, чтобы читатель мог легко в них разо�браться. Если это не так, то, по всей видимости, проектировщик, соз�дававший диаграмму, учел не все требования, выраженные в данномпрецеденте.

#8Не проверяют направления стрелок�сообщений на всех диаграммахпоследовательности.Очень важно, чтобы из диаграммы последовательности всегда быловидно, какой объект владеет управлением. Если что�то пропущено,то позже – при попытке построить код на основе такой диаграммы –возникнут сложности.

Ошибки при РОП


#7Забывают о критериях Халберта–О’Брайена при рецензирова�нии диаграмм последовательности.Нужно всегда помнить о возможностях повторного использова�ния объектов, изображенных на диаграммах последовательности,и о том, чтобы методы каждого объекта обладали высокой степеньюприменимости. Следует также стремиться к снижению уровня слож�ности зависимости от реализации как для отдельных методов, таки для объекта в целом. Соблюдение этих критериев качества по�зволит создать хороший объектно�ориентированный проект.

#6Не анализируют статическую модель на предмет соответствияклассов критериям качества.Один из лучших способов находить правильные решения о рас�пределении поведения – выяснять, какой объект за что отвечает.В главе 7 говорилось, что у класса должна быть одна «личность»,а сомнительные объекты лучше не использовать. Это означает, чтокласс должен отвечать за набор взаимосвязанных функций и в ми�нимальной степени зависеть от других классов. Наиболее важныеиз приведенных выше критериев качества класса – высокая плот�ность и слабая связанность. Чтобы закончить эту тему, приведемцитату из книги Ребекки Уерфс�Брокк (Rebecca Wirfs�Brock) «De�signing Object�Oriented Software» (Prentice Hall, 1990): «Смыслпонятия обязанности в том, чтобы оценить назначение объектаи его место в системе. Обязанности объекта – это все те сервисы,которые он предоставляет по заключенным контрактам. Назначаяклассу обязанность, мы постулируем, что все экземпляры этогокласса будут выполнять данную обязанность». Постарайтесь, что�бы в рецензировании окончательного проекта принял участие че�ловек, который прочел – и понял – эту книгу.

#5Не задумываются о деталях реализации (мол, само собой образуется).Диаграммы последовательности – этап, непосредственно предшест�вующий кодированию, поэтому проект должен быть отражен на нихво всех деталях. В частности, должны быть определены способы хра�нения устойчивых объектов (на какие таблицы базы данных вы со�бираетесь их отобразить) и освещены вопросы распределенностисистемы (на каком уровне должен располагаться каждый объект).

#4Не задумываются о применении паттернов проектирования в сво�ем проекте.Паттерны проектирования могут оказаться очень полезными дляобеспечения повторного использования и сопровождения вашего

131

проекта. Чем больше паттернов вы обнаружите и включите в диа�граммы последовательности, тем проще будет переход к кодиро�ванию и тем больше времени вы сможете уделить решению слож�ных проблем, которые не ложатся ни на какой паттерн.

#3Рисуют обобщенные диаграммы последовательности, не привязан�ные к конкретной технологии реализации, например DCOM или EJB.Мы уже неоднократно подчеркивали, что в процессе ICONIX диа�граммы последовательности – это последняя остановка перед ко�дированием. Вы должны стремиться сократить разрыв между де�тальным проектом и кодом, включив в проект максимум сведенийо технологии, с помощью которой вы собираетесь строить систему.

#2Рецензируют диаграммы последовательности не для всех сценари�ев, которые должны быть реализованы в текущей версии системы.Если вы не нарисовали или не подвергли рецензированию диа�грамму последовательности хотя бы для одного прецедента илиесли на диаграммах отражены не все возможные последователь�ности действий, то вы наверняка пропустите аспекты поведения,которые должны реализовать объекты, или примете неверное ре�шение о распределении поведения.

#1Беспечно относятся к деталям проекта вплоть до начала кодиро�вания. Считают, что реорганизация кода поможет расставить всепо своим местам.Мартин Фаулер (Martin Fowler) в книге «Refactoring» (Addison�Wesley, 2000) характеризует реорганизацию (refactoring) как «про�цесс модификации программной системы таким образом, что еевнешнее поведение не меняется, а внутренняя структура становит�ся лучше». Да, это отличная техника оптимизации кода. Но при�верженцы методики XP применяют ее с самыми разными целями.Приведем цитату из книги Рона Джеффриса (Ron Jeffries), ЭннАндерсон (Ann Anderson) и Чета Хендриксона (Chet Hendrickson)«Extreme Programming Installed» (Addison�Wesley, 2001): «Еслипроект может измениться, что ж – измените его». Те, кто меняетпроект по ходу кодирования, вряд ли сумеют построить такие женадежные системы, как те, что создаются в результате детальногопроектирования и критического анализа проекта. Концентрируявнимание на кодировании маленького фрагмента, вы упускаете извиду общую картину проекта. Реорганизация не гарантирует, чтовсе удастся исправить, если вы, посмеиваясь, пропустили этапыанализа и проектирования, и получится правильная (то есть отве�чающая требованиям заказчика) система.

Ошибки при РОП


Стремление одновременно проектировать и кодировать равносильножеланию играть в шахматы и в то же время выполнять домашнее заданиепо математическому анализу.

И проектирование, и кодирование (да и анализ тоже) – это вполне са�мостоятельные этапы работы. На каждом их них нужно учитывать разно�образные аспекты.

Мы хотим, чтобы вы запомнили одну важную мысль: «Все люди совер�шают ошибки, и лучший способ уменьшить их число – решать проблемыпоочередно». Эти слова напрямую относятся ко всему процессу ICONIX.

ПриложениеОтчет по взглядус точки зрения прецедентов

Модель прецедентов. Документация по прецедентамВ этом приложении приведен отчет о модели книжного Internet�магазина,созданной в программе Rational Rose. Отчет состоит из следующих частей:

диаграмма классов, приведенная в конце главы 2;правильные тексты всех прецедентов, представленных в главе 3;диаграмма прецедентов, приведенная в конце главы 2;все правильные диаграммы пригодности из главы 5;диаграмма классов, приведенная в конце главы 5;все правильные диаграммы последовательности из главы 7;диаграммы классов, приведенные в конце главы 7.

Взгляд с точки зрения прецедентов:актер – Клиент;актер – Упаковщик;актер – Поставщик;актер – Приемщик;актер – Учетчик;актер – Участок Доставки;актер – Участок Приемки.

Прецедент – Просмотреть Список КнигДокументация

Главная последовательность. Клиент щелкает по ссылке Категорияна Странице Просмотра Книг. Система отображает подкатегории дан�ной Категории. Процесс продолжается, пока есть подкатегории, послечего система выводит список Книг в самой глубокой подкатегории. Кли�ент щелкает по пиктограмме обложки Книги. Система вызывает преце�дент Детали Книги.

134 Приложение

Рис. П1. Диаграмма прецедентов – Main

Изменить СодержимоеКорзины

Подтвердить Заказ


Просмотреть НедавниеЗаказы

Доставить ЗаказОбработать Готовый

к Доставке Заказ

Искать по Автору

Отменить Заказ

ПросмотретьСписок Книг

Регистрация

Клиент

Упаковщик Участок Доставки

ДоставщикУчетчик

Участок Приемки

Приемщик

Альтернативная последовательность. Если система не находит Книгв данной Категории, она отображает соответствующее сообщение ипредлагает Клиенту выбрать другую Категорию.

Список ассоциаций. Клиент взаимодействует с прецедентом Про�смотреть Список Книг.

Прецедент – Отменить ЗаказДокументация

Главная последовательность. Система проверяет, можно ли отменитьЗаказ (то есть не находится ли он в состоянии «готовится к доставке» или«доставлен»). Затем система выводит информацию о Заказе на Стра�нице Отмены Заказа, в том числе его состав и адрес доставки. Клиентнажимает кнопку Подтвердить отмену. Система помечает Заказ как«удаленный», а затем вызывает прецедент Вернуть Товар на Склад.

135

Альтернативная последовательность. Если Заказ находится в состо�янии «готовится к доставке» или «доставлен», то система выводит сооб�щение о том, что отменять Заказ уже поздно.

Список ассоциаций. Страница Результатов Поиска взаимодейст�вует с прецедентом Отменить Заказ.

Отчет по взгляду с точки зрения прецедентов

ГлавнаяТаблица Счетов







ДеталиЗаказаСтатус

Запасы

ТарифнаяПолитика

РецензияПосетителя

РецензияРедактора

ИздательствоРецензия

КаталогРезультатыПоиска

Книга

КорзинаЗаказ наПокупку

Позиция Заказа

Товар Заказ


Счет

Рис. П2. Диаграмма классов – модель предметной области


Прецедент – Оформить ЗаказДокументация

Заказ


Книга

заголовокценадатаПубликациипиктограммадоступныйОстатокминимальныйЗапасскидкаиздатель

Счет



датаРазмежениястатуспозиции : Vector

Издательство


Запасы


Товар

количествоцена





Рецензия

рейтинг

Результаты Поиска

Корзина


Статус

Детали Заказа


ПользовательМенеджерРегистрации


Каталог

Рис. П3. Диаграмма классов – модель предметной области с атрибутами

137

«boundary»Страница Ошибки

отобразитьОтсутствиеИмени()отобразитьНеверныйПочтовыйАдрес()отобразитьНеверныйПароль()

«boundary»Страница Поиска

наПоиск()проверитьПоисковыйЗапрос()отобразитьОшибкуИПовторить()



Издатель


Запасы








«boundary»Страница Напоминания


«boundary»Страница Результатов Поиска

отобразить()наДобавлениеВКорзину()

«entity»Каталог

поискПоАвтору()

«entity»Результаты Поиска

создать()

рейтинг






отобразить()наРегистрацию()отобразитьОшибкуИПовторить()заморозить()наНовыйСчет()напоминание()


наОбновление()отобразитьСтоимость()наПродолжениеПокупки()наУдаление()наПроверку()удалитьПозицию()


отобразитьНедавниеЗаказы()наНажатиеСвязи()отобразить()наУправлениеСчетом()отобразитьСообщениеНетЗаказов()





заголовокценадатаПубликациипиктограммадоступноеКоличествоминимальныйОстатокскидкаиздатель


Рецензия

записать()



ввод данных и нажатие кнопкиЗарегистрироваться

нажатиекнопки OK


ввод имени автора

выбор книги


Рис. П4. Диаграмма классов – статическая модель (часть 1)














отобразить()наОК()

«entity»Детали Заказа

создать()получитьДетали()



«entity»Менеджер Регистраций


наОбновление()отобразитьСтоимость()наПродолжениеПокупки()наУдаление()наПодтверждениеЗаказа()удалитьПозицию()


отобразитьНедавниеЗаказы()наНажатиеСвязи()отобразить()наУправлениеСчетом()наПроверку()отобразитьСообщениеНетЗаказа()


отобразить()наРегистрацию()отобразитьОшибкуИПовторить()заморозить()наНовуюРегистрацию()наНапоминание()

«entity»Счет




иддатаРазмещениядатаДоставкиполучательномерДоставкистатусметодДоставкикодВнешнейБазыДанных







ввод данныхи нажатие кнопки





139

Главная последовательность. Система создает объект Возможный За�каз, который содержит все товары из Корзины Клиента, затем извлека�ет Адреса Доставки, ассоциированные со Счетом Клиента, и отобра�жает их на Странице Адреса Доставки.

Клиент выбирает адрес и нажимает кнопку Использовать этот адрес.Система ассоциирует выбранный Адрес Доставки с Возможным Зака�зом, после чего выводит разрешенные Методы Доставки на СтраницеМетода Доставки.




«boundary»Интерфейс Доставщика


«boundary»Консоль Участка Доставки


«boundary»Устройство Считывания Штрих!кодов

считатьШтрих!Код()


Предпочтения Пользователя

Статус

«entity»Счет




иддатаРазмещениядатаДоставкиполучательномерДоставкистатусметодДоставкикодВнешнейБазыДанных


Упаковщик(из Взгляда с Точки


Участок Доставки(из Взгляда с Точки


Платежная Информация


считывает штрих�коды



Клиент выбирает метод доставки и нажимает кнопку Использоватьэтот метод доставки. Система ассоциирует выбранный Метод Доставки сВозможным Заказом, после чего выводит содержимое объектов Платеж�ная Информация, ассоциированных со Счетом Клиента, на СтраницеМетода Платежа.

Клиент выбирает метод платежа и нажимает кнопку Использоватьэтот метод платежа. Система ассоциирует выбранный объект ПлатежнаяИнформация с Возможным Заказом, затем выводит Страницу

Подтверждения Заказа.Клиент нажимает кнопку Подтвердить заказ. Система преобразует

Возможный Заказ в Заказ и уничтожает Корзину, а потом возвращаетуправление вызывающему прецеденту.

Альтернативные последовательности. Если Клиент еще не зарегист�рирован, система вызывает прецедент Регистрация.

Если система не находит Адресов Доставки, она вызывает преце�дент Создать Адрес Доставки.

Если система не находит объектов Метод Платежа, она вызывает пре�цедент Определить Метод Платежа.

Если Клиент в любом месте нажимает кнопку Отменить Заказ, систе�ма уничтожает Возможный Заказ и возвращает управление вызывающе�му прецеденту.

Список ассоциаций. Клиент взаимодействует с прецедентом Офор�мить Заказ.

Страница Просмотра Корзины взаимодействует с прецедентомОформить Заказ.

Прецедент – Изменить Содержимое КорзиныДокументация

Главная последовательность. На Странице Просмотра КорзиныКлиент изменяет количество Товара и нажимает кнопку Обновить. Си�стема сохраняет новое количество, после чего вычисляет и показываетновую стоимость товара.

Клиент нажимает кнопку Продолжаю Покупать. Система возвраща�ет управление вызывающему прецеденту.

Альтернативные последовательности. Если Клиент изменяет коли�чество на 0, то система удаляет Товар из Корзины.

Если Клиент нажимает кнопку Удалить вместо кнопки Обновить, тосистема удаляет Товар из Корзины.

Если Клиент нажимает кнопку Оформить Заказ вместо кнопки Про�должаю Покупать, система передает управление прецеденту ОформитьЗаказ.

141

Список ассоциаций. Клиент взаимодействует с прецедентом Изме�нить Содержимое Корзины.

Прецедент – РегистрацияДокументация

Главная последовательность. Клиент нажимает кнопку Зарегистри�роваться на Начальной Странице. Система выводит Страницу Регис�трации. Клиент вводит свой код и пароль и нажимает кнопку Зарегист�рироваться.

Система сравнивает введенную информацию с данными, хранящими�ся в Счете, после чего открывает Начальную Страницу.

Альтернативные последовательности. Если Клиент нажимает кноп�ку Новый счет на Странице Регистрации, то система вызывает преце�дент Открыть Счет.

Если Клиент нажимает кнопку Вспомнить на Странице Регистра�ции, то система выводит секретный вопрос, хранящийся для этого Кли�ента, в отдельном диалоговом окне. Когда Клиент щелкает в нем покнопке OK, открывается Страница Регистрации.

Если Клиент набрал неизвестный системе код, появится соответству�ющее сообщение с предложением либо ввести другой код, либо нажатькнопку Новый счет.

Обновить Количествои Стоимость

Удалить Позицию(из Модели ПредметнойОбласти с Атрибутами)




Корзина(из Модели ПредметнойОбласти с Атрибутами)

Клиент

изменяет количество,нажимает кнопку

Обновить

Подтвердить Заказ

Рис. П7. Диаграмма классов – Изменить Содержимое Корзины(диаграмма пригодности)


142

Пр

ило

жен

ие

1 : Клиент



Система сохраняет информацию о количестветовара, после чего вычисляет и показываетего новую стоимость.




Если Клиент нажимает кнопку Удалить,а не Обновить, то система удаляет Товариз Корзины.

Если Клиент нажимает кнопку ПодтвердитьЗаказ, а не Обновить, система передаетуправление прецеденту Подтвердить Заказ.


Заказ.














Ри

с. П8

. Ди

аграм

ма взаи

мо

де

йстви

й –

Изм

ен

ить С

од

ер

жи

мо

е К

ор

зин

ы(д

иагр

амм

а по

след

овате

льно

сти)

143

Если Клиент ввел неправильный пароль, то система выводит соответ�ствующее сообщение и предлагает повторно ввести пароль.

Если Клиент три раза подряд ввел неправильный пароль, то системавыводит сообщение с предложением обратиться в службу работы с клиен�тами и блокирует Страницу Регистрации.

Список ассоциаций. Клиент взаимодействует со Страницей Регис�трации.


Проверить


Клиент


ДиалоговоеОкно Напоминания Счет

(из МоделиПредметной Области

с Атрибутами)

нажимаеткнопку OK

вводит данныеи нажимает кнопку




Рис. П9. Диаграмма классов – Регистрация (диаграмма пригодности)

Прецедент – Открыть СчетДокументация

Главная последовательность. Клиент вводит свое имя, электронныйадрес, пароль (дважды) и нажимает кнопку Создать Счет. Система прове�ряет правильность введенных данных и добавляет новый Счет в Глав�ную Таблицу Счетов, после чего открывает Начальную Страницу.

Альтернативные последовательности. Если Клиент не ввел имя, си�стема выводит соответствующее сообщение об ошибке и предлагаетввести имя.


144

Пр

ило

жен

ие

Ри

с. П1

0. Д

иагр

амм

а взаим

од

ей

ствий

– Р

еги

страц

ия

(ди

аграм

ма п

осле

до

вательн

ости

)



5 : Счет


Клиент нажимает кнопкуЗарегистрироваться на НачальнойСтранице.


Если Клиент нажимает кнопку Новыйсчет на Странице Регистрации, тосистема вызывает прецедент ОткрытьСчет.

Если Клиент нажимает кнопку Вспомнитьна Странице Регистрации, то системавыводит для него секретный вопросв отдельном диалоговом окне. КогдаКлиент нажимает кнопку OK, системавозвращается на Страницу Регистрации.









проверитьРегистрационнуюИнформацию()


наOK()



наНапоминание()

Клиент вводит свой код и парольи нажимает кнопку Зарегистрироваться.

Система сравнивает введеннуюинформацию с данными, хранящимисяв Счете, после чего возвращает Клиентана Начальную Страницу.

Если Клиент набрал код, которыйнеизвестен системе, то система выводитсоответствующее сообщение и предлагаетКлиенту либо ввести другой код, либонажать кнопку Новый счет.


Если Клиент три раза подряд набралнеправильный пароль, то система выводитсообщение с предложением обратитьсяв службу работы с клиентами и СтраницаРегистрации становится неактивной.

145

Если формат введенного Клиентом электронного адреса некоррек�тен, система выводит соответствующее сообщение об ошибке и предлага�ет Клиенту ввести другой адрес.

Если Клиент ввел слишком короткий пароль, система выводит соот�ветствующее сообщение об ошибке и предлагает ввести более длинный па�роль.

Если два введенных Клиентом пароля различаются, система выводитсоответствующее сообщение об ошибке и предлагает ввести пароль по�вторно.

Если Счет уже есть в Главной Таблице Счетов, система сообщаетоб этом Клиенту.

Список ассоциаций. Клиент взаимодействует с прецедентом От�крыть Счет. Страница Регистрации взаимодействует с прецедентомОткрыть Счет. Прецедент Открыть Счет взаимодействует со Страни�цей Регистрации.

Прецедент – Обработать Готовый к Доставке ЗаказДокументация

Главная последовательность. Приемщик проверяет, что каждой Стро�ке Заказа, присутствующей в Заказе на Покупку, соответствует физи�ческий товар. Приемщик считывает штрих�коды с упаковочного листа.

Система изменяет состояние Заказа на «выполнен» и обновляет ко�личество каждой книги. Приемщик передает Книги Учетчику.

Альтернативная последовательность. Если Упаковщик обнаружива�ет расхождение между Заказом и подобранными физическими товара�ми, то он прекращает обработку Заказа до устранения неувязок.

Список ассоциаций. Приемщик взаимодействует с прецедентом Об�работать Готовый к Доставке Заказ. Прецедент Обработать Гото�вый к Доставке Заказ взаимодействует с Учетчиком. Прецедент Об�работать Готовый к Доставке Заказ взаимодействует с УчасткомПриемки.

Прецедент – Поиск по АвторуДокументация

Главная последовательность. Клиент вводит имя Автора на Стра�нице Поиска, после чего нажимает кнопку Искать. Система проверяетправильность запроса, после чего ищет в Каталоге все удовлетворяю�щие запросу Книги.

Для каждой найденной Книги система извлекает существенные дета�ли и создает на их основе объект Результаты Поиска. Затем система вы�водит список Книг на Странице Результатов Поиска, отсортирован�



ный по датам издания в порядке убывания. В каждой строке выводитсяпиктограмма обложки, название Книги и имена Авторов, средний Рей�тинг и кнопка Добавить в корзину.

Клиент нажимает кнопку Добавить в корзину для выбранной книги.Система передает управление прецеденту Добавить Товар в Корзину.

Альтернативные последовательности. Если Клиент нажал кнопкуИскать, не введя запроса, система отобразит сообщение об ошибке и пред�ложит ввести критерий поиска.

Если система не находит Книг данного Автора, она выводит соответ�ствующее сообщение и предлагает Клиенту задать другой критерий поиска.

Если Клиент закрывает страницу не нажатием кнопки Добавить в кор�зину, а каким�то другим способом, система возвращает управление томупрецеденту, из которого был вызван данный.

Список ассоциаций. Клиент взаимодействует с прецедентом Поискпо Автору.

Прецедент – Доставить ЗаказДокументация

Рис. П11. Диаграмма классов – Поиск по Автору (диаграмма пригодности)



ПроверитьЗапрос на Поиск

Создать



(из Модели ПредметнойОбласти с Атрибутами)


Каталог(из Модели ПредметнойОбласти с Атрибутами)

Книга(из Модели ПредметнойОбласти с Атрибутами)


Клиент

вводит имя автора,нажимает кнопку

Искать


книг ненайдено

не введен запрос

147

1 :

Кл

ие

нт

Гла

вна

я п

осл

ед

ова

тел

ьно

сть

Кл

ие

нт

вво

ди

т и

мя

Авт

ор

а н

а С

тра

ни

це

По

иск

а и

на

жи

ма

ет

кно

пку

Иск

ать

.

Си

сте

ма

пр

ове

ряе

т, ч

то К

ли

ен

т вв

ел

до

пус

тим

ый

за

пр

ос,

по

сле

че

го и

ще

тв

Ка

тал

оге

все

Кн

иги

ука

зан

но

го а

вто

ра

.

Дл

я ка

жд

ой

на

йд

ен

но

й К

ни

ги с

ист

ем

аи

звл

ека

ет

сущ

ест

вен

ны

е д

ета

ли

.

За

тем

си

сте

ма

вы

вод

ит

спи

сок

Кн

иг

на

Стр

ан

иц

е Р

езу

льт

ато

в П

ои

ска

, отс

ор

!ти

ро

ван

ны

й п

о д

ате

изд

ан

ия

в п

ор

ядке

убы

ван

ия.

В к

аж

до

й с

тро

ке в

ыво

ди

тся

пи

кто

гра

мм

а о

бл

ож

ки, н

азв

ан

ие

Кн

иги

,и

ме

на

Авт

ор

ов,

ср

ед

ни

й Р

ей

тин

ги

кн

оп

ка Д

об

ави

ть в

ко

рзи

ну.

Кл

ие

нт

на

жи

ма

ет

кно

пку

До

ба

вить

в ко

рзи

ну

дл

я вы

бр

ан

но

й к

ни

ги. С

ист

ем

ап

ер

ед

ае

т уп

ра

вле

ни

е п

ре

це

де

нту

До

ба

вить

То

вар

в К

ор

зин

у.

Ал

ьте

рн

ати

вны

е п

осл

ед

ова

тел

ьно

сти

Есл

и к

ли

ен

т н

аж

ал

кн

оп

ку И

ска

ть,

не

на

бр

ав

зап

ро

са, т

о с

ист

ем

а в

ыво

ди

тсо

об

ще

ни

е о

б о

ши

бке

и п

ре

дл

ага

ет

зад

ать

кр

ите

ри

й п

ои

ска

.

Есл

и с

ист

ем

а н

е н

ахо

ди

т К

ни

г д

ан

но

гоА

вто

ра

, он

а в

ыво

ди

т со

отв

етс

твую

ще

есо

об

ще

ни

е и

пр

ед

ла

гае

т К

ли

ен

ту з

ад

ать

др

уго

й к

ри

тер

ий

по

иск

а.

Есл

и К

ли

ен

т п

оки

да

ет

стр

ан

иц

у, н

е н

аж

ав

кно

пку

До

ба

вить

в к

ор

зин

у, с

ист

ем

аво

звр

ащ

ае

т уп

ра

вле

ни

е т

ом

у п

ре

це

де

нту

,и

з ко

тор

ого

бы

л в

ызв

ан

да

нн

ый

.

на

По

иск

()

пр

ове

ри

тьП

ои

ско

вый

За

пр

ос(

)

ото

бр

ази

тьО

ши

бку

ИП

овт

ор

ить

()

по

иск

По

Авт

ор

у

созд

ать

()

ото

бр

ази

ть()

на

До

ба

вле

ни

еВ

Ко

рзи

ну(

)

ото

бр

ази

тьО

ши

бку

ИП

овт

ор

ить

()

3 :

Стр

ан

иц

аР

езу

льт

ато

в П

ои

ска

2 :

Стр

ан

иц

аП

ои

ска

6 :

Ре

зул

ьта

тыП

ои

ска

4 :

Ка

тал

ог

5 :

Кн

ига

по

луч

ить

Де

тал

и()

Пе

ре

да

тьуп

ра

вле

ни

еп

ре

це

де

нту

До

ба

вить

в К

ор

зин

у.

Рис. П12. Диаграмма взаимодействий – Поиск по Автору(диаграмма последовательности)



Главная последовательность. Упаковщик проверяет, что товары, пе�речисленные в упаковочном листе для данного Заказа, соответствуютфизически представленным Товарам, и считывает штрих�коды с упако�вочного листа.

Система изменяет состояние Заказа на «готовится к доставке», пос�ле чего находит Метод Доставки, указанный Клиентом для данного За�каза, и выводит его на Консоль Участка Доставки.

Упаковщик взвешивает и пакует физические Товары, наклеивает на�кладную, соответствующую методу доставки, и отправляет бандероль че�рез соответствующего Поставщика.

Альтернативная последовательность. Если Упаковщик обнаружива�ет несоответствия между Заказом и физическими Товарами, он прекра�щает обработку Заказа до выяснения обстоятельств.

Список ассоциаций. Упаковщик взаимодействует с прецедентом До�ставить Заказ. Прецедент Доставить Заказ взаимодействует с По�ставщиком и Участком Доставки.

Прецедент – Просмотреть Недавние ЗаказыДокументация

ИзменитьСтатус




Консольна Участке Упаковки

Устройство СчитыванияШтрих!Кодов

Заказ(из Модели ПредметнойОбласти с Атрибутами)


считывает штрих код

Рис. П13. Диаграмма классов – Доставить Заказ (диаграмма пригодности)

149

1 : Упаковщик 2 : Доставщик 3 : УстройствоСчитывания

Штрих!Кодов

4 : Консольна УчасткеДоставки

5 : ИнтерфейсДоставщика


Упаковщик проверяет соответствиетоваров, перечисленных в упаковочномлисте для данного Заказа, физическимтоварам.

Система изменяет состояние Заказана "готовится к доставке".

Затем система находит Метод Доставкиданного заказа, указанный Клиентом, и выводит его на Консоль УчасткаДоставки.

Упаковщик взвешивает физическиетовары и пакует Товары. Также Упаковщикнаклеивает накладную, соответствующуюметоду доставки.


считать Штрих!Код()

изменитьСтатус()



Упаковщик считывает штрих!кодыс упаковочного листа.

Упаковщик отправляет бандерольпри помощи соответствующегоДоставщика.


Если Упаковщик обнаруживает несоот!ветствие между Заказом и физическимитоварами, он прекращает обработкуЗаказа до устранения проблемы.

6 : ЗаказРи

с. П1

4. Д

иагр

амм

а взаим

од

ей

ствий

– Д

остави

ть Заказ

(ди

аграм

ма п

осле

до

вательн

ости

)

Отчет п

о взгляду с точки

зрен

ия п

рец

еден

тов


Главная последовательность. Система находит Заказы, которые Кли�ент разместил в течение последних 30 дней, и выводит данные об этихЗаказах на Страницу Просмотра Заказов. В каждой строке указыва�ется идентификатор (в виде гиперссылки), дата, состояние, получатель иМетод Доставки Заказа.

Клиент щелкает по гиперссылке. Система извлекает данные о содержи�мом Заказа и создает объект Детали Заказа. Система выводит содержи�мое этого объекта в режиме чтения на Странице Деталей Заказа. Кли�ент нажимает кнопку OK для возврата к Странице Просмотра Заказов.

Закончив просмотр Заказов, Клиент щелкает по ссылке Ведениесчета на Странице Просмотра Заказов. Система возвращает управле�ние вызывающему прецеденту.

Альтернативная последовательность. Если Клиент не разместил запоследние 30 дней ни одного Заказа, то на Странице Просмотра За�казов появляется соответствующее сообщение.

Список ассоциаций. Клиент взаимодействует с прецедентом Про�смотреть Недавние Заказы.

Итого: пакетов – 2; прецедентов – 10.

Структура пакета прецедентов.Взгляд с точки зрения прецедентов






Таблица Заказов(из Модели ПредметнойОбласти с Атрибутами)

Заказ(из Модели ПредметнойОбласти с Атрибутами)

Клиент

Рис. П15. Диаграмма классов – Просмотреть Недавние Заказы(диаграмма пригодности)

151О

тчет по взгляд

у с точки зр

ени

я пр

ецед

ентов

1 : КлиентГлавная последовательность

Система находит Заказы, которые Клиентразместил в течение последних 30 дней,и выводит соответствующие данныена Страницу Просмотра Заказов. В каждойстроке указаны идентификаторы Заказа(в виде гиперссылки), дата и состояниеЗаказа, получатель и Метод Доставки.

Клиент щелкает по гиперссылке. Системаизвлекает данные о содержимом заказаи создает объект Детали Заказа.Содержимое этого объекта выводитсяв режиме чтения на Странице ДеталейЗаказа.

Клиент нажимает кнопку OK для возвратак Странице Просмотра Заказов.

Закончив просмотр Заказов, Клиентщелкает по ссылке Ведение счетана Странице Просмотра Заказов.Система возвращает управлениевызывающему прецеденту.


Если Клиент не разместил за последние30 дней ни одного Заказа, системавыводит на Странице Просмотра Заказовсоответствующее сообщение



отобразитьНедавниеЗаказы()

отобразитьСообщениеНетЗаказов()



создать()



наOK()



2 : СтраницаПросмотра Заказов

6 : ДеталиЗаказа

4 : ТаблицаЗаказов

5 : Заказ

Ри

с. П1

6. Д

иагр

амм

а взаим

од

ей

ствий

– П

ро

смо

тре

ть Не

давн

ие

Заказы

(ди

аграм

ма п

осле

до

вательн

ости

)

Литература1. Grady Booch. Object�Oriented Analysys and Design with Applications.

Second Edition. Addison�Wesley, 1994.2. Grady Booch, James Rumbaugh, Ivar Jacobson. The Unified Modeling

Language User Guide. Addison Wesley Longman, 1999.3. Peter DeGrace, Leslie Hulet Stahl. The Olduvai Imperative. Prentice

Hall, 1993.4. Tom DeMarco. Structured Analysis and System Specification. Prentice

Hall, 1985.5. Kurt Derr. Applying OMT. SIGS Books, 1995.6. Bruce Powel Douglass. Real�Time UML: Developing Efficient Objects

for Embedded Systems. Addison Wesley Longman, 1998.7. Martin Fowler. Refactoring. Addison�Wesley, 2000.8. Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides [Gang of

Four]. Design Patterns: Elements of Reusable Object�Oriented Software.Addison�Wesley, 1995. (Русский перевод: Гамма Э. и др. «Паттерныпроектирования». Питер, ДМК, 2001.)

9. Maurice Howard Halstead. Elements of Software Science. 1977.10. Ivar Jacobson, Maria Ericsson, Agneta Jacobson. The Object Advantage:

Business Process Reengineering with Object Technologe. Addison�Wes�ley, 1995.

11. Ron Jeffries, Ann Anderson, Chet Hendrickson. Extreme ProgrammingInstalled. Addison�Wesley, 2001.

12. Chris Kemerer. Software Project Management. Reading and Cases. RichardD. Irwin, 1996.

13. Robert Cecil Martin. Designing Object�Oriented C++ Applications Usingthe Booch Method. Prentice Hall, 1995.

14. Doug Rosenberg. Applying O�O Methods to Interactive MultimediaProjects / OBJECT, June 1995.

15. Doug Rosenberg. Inside the ICONIX Process (CD�ROM; ICONIX, 2001).16. Doug Rosenberg. Mastering UML with Rational Rose (CD�ROM; ICO�

NIX, 1997).17. Doug Rosenberg. Modeling Client/Server Systems / OBJECT, March

1994.

153

18. Doug Rosenberg. An Object Methodology Overview (CD�ROM; ICO�NIX, 1994).

19. Doug Rosenberg. Rational Rose 98 for Power Users (CD�ROM; ICO�NIX, 1998).

20. Doug Rosenberg. UML Applied: Nine Tips to Incorporating UML IntoYour Project / Software Development, March 1998.

21. Doug Rosenberg. A Unified Object Modeling Technique with Objectoryfor Client/Server Development / OBJECT, November 1993.

22. Doug Rosenberg. Validating the Design of Client/Server Systems / OBJECT,July 1994.

23. Doug Rosenberg and Kendall Scott. Optimizing Rose 98 to Support UseCase Driven Object Modeling (данный материал доступен в Internetпо адресу: http://www.rosearchitect.com/archives/9810/online.shtml).

24. Doug Rosenberg and Kendall Scott. Use Case Driven Object Modelingwith UML: A Practical Approach. Addison Wesley Longman, 1999.

25. James Rumbaugh, Michael Blaha, William Premerlani, Frederick Eddy,William Lorenzen. Object�Oriented Modeling and Design. Prentice Hall,1991.

26. William Shakespeare. Much Ado About Nothing.27. Rebecca Wirfs�Brock, Brian Wilkerson, Lauren Wiener. Designing Object�

Oriented Software. Prentice Hall, 1990.

Литература

Предметный указатель

ААгрегирование 28, 32Анализ пригодности

10 самых распространенныхошибок 79выполнение 76закрытие разрывамежду «что» и «как» 18правила 78

«Аналитический паралич» 22, 31Ассоциация 28, 30Атрибуты

и анализ пригодности 79и имена существительные 29и родительный падеж 30и РПП 94и тексты прецедентов 50на диаграммах классов 28

ББлок#схема 107Буч Грейди 12, 16, 32, 126

ВВехи 24

ГГрамматический анализ 31, 69Граничный объект

на диаграммахпоследовательности 101, 105на диаграммах пригодности 18нотация 75обсуждение 77определение 51, 74

ДДействительный залог 52, 69, 72Детальное проектирование

и диаграммы пригодности 81обзор 101

Джекобсон Айвар 12, 16, 22,74, 103, 106, 125Диаграмма

классованалитического уровня 20модели предметнойобласти 18уровня проектирования 14

последовательности10 самых распространенныхошибок 106и последовательностидействий 103обзор 101рецензирование 129стрелки 108, 126, 129элементы 103

потоков взаимодействия 68пригодности

как контрольный список 106рецензирование 78, 81, 97сравнение с диаграммойкооперации 74стрелки 96, 100

сущность–связь 30Динамическая модель

и атрибуты и операции 108и прецеденты 48и процесс ICONIX 20

155Предметный указатель

и РОП 125и статическая модель 103исследование 21подход снаружи внутрь 48

Доказательство правильностиконцепции 68Доменные объекты 18

ЗЗаказчики

и рецензированиетребований 67и РОП 124, 129и РПП 95, 98

Знание реализации 126, 130

ИИнфраструктура 109Итеративностьи инкрементность 22

ККлассы

выявление 29, 77и таблица реляционнойбазы данных 33источники 29

Композиция 32Контроллер

и диаграммыпоследовательности 105нотация 75определение 75рекомендациипо количеству 81

Кратность 31

ЛЛокализация изменений 78Локализованные диаграммыклассов 109

ММинималистский подход 12Минимальная достаточность 13, 22Моделирование предметнойобласти

10 самых распространенныхошибок 31введение 28

Модельпредметной области

и прецеденты 71и процесс ICONIX 29и рецензированиетребований 71как словарь 18, 28на диаграмме классов 18обновление 49, 98определение 18построение 18пример 45, 93

прецедентовзавершение создания 50и процесс ICONIX 47рецензирование 49

Модульность 124

ООбобщение 28, 30Операции

и РПП 99на диаграммах классов 28распределениепо классам 102

Отношениевключения (include) 49, 53вызова (invoke) 49, 53предшествования(precede) 49, 53расширения (extend) 49

Отношения дружественности 33


ППакеты 50Параметризованные классы 33Паттерны проектирования

и анализ пригодности 33, 99и диаграммы пригодности 96и моделированиепредметной области 33и РОП 124, 130и РПП 99итератор 128на диаграммахпригодности 106фабричный метод 128

Переговоры 70Плотность 108, 124, 127Повторное использование 31,108, 126, 130Подход

изнутри наружу 25, 29сверху вниз 25снаружи внутрь 25, 29, 48

Полнота 127Предварительноепроектирование 75, 77Предметнаяобласть 18, 22, 28, 29Преждевременнаяпаттернизация 33Преждевременноерассмотрение паттернов 99Прецеденты

альтернативныепоследовательностидействий 52, 69, 72, 80главная последовательностьдействий 52, 72грамматический анализ 69действительный залог 69, 72и диаграммы

последовательности 103, 107и модельпредметной области 71и проектирование ГИП 68пакеты 50уточнение 95

Применимость 108, 126, 130Примеры прецедентов

Доставить Заказдиаграммапоследовательности 149диаграмма пригодности 148фрагменты текста 61, 63

ИзменитьСодержимое Корзины

диаграммапоследовательности 116, 142диаграммапригодности 88, 141фрагменты текста 57

Обработать готовыйк Доставке Заказ 59Открыть Счет 55Отменить Заказ 57Оформить Заказ 61Поиск по Автору

диаграммапоследовательности 147диаграмма пригодности 146фрагменты текста 55, 59

Просмотреть Недавние Заказыдиаграммапоследовательности 151диаграмма пригодности 150фрагменты текстов 61, 63

Регистрациядиаграммапоследовательности 144диаграмма пригодности 143фрагменты текста 55

Примитивность 127

157Предметный указатель

Проверка полнотыи правильности 77Проектирование графическогоинтерфейса пользователя 68Производительность 75Прототипы 21, 24, 47, 51, 68, 71Процесс ICONIX

и методологияeXtreme Programming 12и рациональныйунифицированный процесс 12общая картина 21

РРамбо Джим 12, 19Распределение поведения

и анализ пригодности 80и диаграммыпоследовательности 101, 107и процесс разработки 24и РОП 126и РПП 99определение 15

Распространенные ошибкипри анализе пригодности 79при моделировании

предметной области 31прецедентов 50

при рецензированиитребований 69при РПП 97

Рациональныйунифицированный процесс ипроцесс ICONIX 12Реорганизация кода 131Рецензирование

окончательного проекта (РОП)10 самых распространенныхошибок 129вехи 125обзор 124

определение 9участники 124

предварительногопроекта (РПП) 97

10 самых распространенныхошибок 97обзор 94определение 9участники 95

требований10 самых распространенныхошибок 69обзор 67определение 9участники 67

РОП. См. Рецензированиеокончательного проектаРПП. См. Рецензированиепредварительного проектаРуководствопользователя 48, 51, 95

С«Санитарнаяпроверка» 76, 81, 95Связанность 108, 124, 127Сложность 126, 130Соединительная ткань 73Статическая модель

атрибуты 108и модельпредметной области 31и процесс ICONIX 20обновление 49, 82, 97, 103,105, 108операции 107первое приближение 20постепенное уточнение 22эволюция 19

Стереотипы 74, 77Существительное#глагол#существительное 49, 100


Сущностный объекти РПП 94на диаграммахпоследовательности 101нотация 75обсуждение 78определение 75

ТТелеоцентризм 69Техническая архитектура

и производительность 75и РОП 129и РПП 94определение 96

Требованияи анализ пригодности 21и диаграммыпоследовательности 106и прецеденты 50как источники классов 29

УУнаследованные системы 33, 48Управление на экране 96Управляющий объект

нотация 75определение 75

ШШаблоны прецедентов 49, 52,69, 73

EeXtreme Programming

и прототипы 68и процесс ICONIX 12мысли о проектировании 131проект C3 70

GGDPro 15, 105

OObject Modeling Technique (OMT),методология 19, 29, 103Objectory 17, 74OML. См. Object Modeling LanguageOMT. См. Object Modeling TechniqueOpen Modeling Language (OML),язык 50

invoke 53precede 53

RRational Rose 15, 105, 108

TTogether/J 105

UUML

диаграммыклассов 14, 28, 74последовательности 15, 103

обобщение прецедентов 49отношение

extend 49include 49, 53

Дуг Розенберг, Кендалл Скотт

Применение объектного моделированияс использованием UML и анализ прецедентов

Главный редактор

Перевод с англ. Слинкин А. А.Научный редактор Степин Д. Б.

Выпускающий редактор Готлиб О. В.Технический редактор Панчук Л. А.

Верстка Трубачев М. П.Графика Шаклунов А. К.

Дизайн обложки Панкусова Е. Н.

Гарнитура «Петербург». Печать офсетная.Усл. печ. л. 13. Зак. №

Отпечатано на Чеховском полиграфическом комбинатег. Чехов, ул. Полиграфистов, д. 1.

Издательство «ДМК Пресс».

Мовчан Д. А.

Application Object Modeling Using Um l

Documents

Transcript of Application Object Modeling Using Um l