Дж. Арлоу, А. Нейштадт - UML 2 и Унифицированный процесс - Практический объектно-ориентированный анализ и проектирование, страница 68

Этот артефакт затушеван, чтобы показать, что он был изменен. В оригинальном описании деятельности он был неявным результатом.Создание входного артефакта Класс анализа [полный] уже обсуждалосьв части книги, посвященной анализу, поэтому мы больше не будем возвращаться к этому вопросу.Стоит более подробно рассмотреть артефакт Проектный класс [в общихчертах]. С точки зрения деятельности кажется, что здесь присутствуютдва отдельных самостоятельных артефакта, Проектный класс [в общих370Глава 17.

Проектные классы17.2. Деятельность UP: Проектирование класса17.3. Что такое проектные классы?17.4. Анатомия проектного класса17.5. Правильно сформированные проектные классы17.5.1. Полнота и достаточность17.5.2. Простота17.5.3. Высокаявнутренняя связность17.5.4. Низкая связанностьс другими классами17.6. Наследование17.6.1. Сравнение агрегациии наследования17.6.2. Множественноенаследование17.7. Шаблоны17.8. Вложенные классы17.9. Что мы узналиРис.

17.1. План главы17.6.3. Сравнение наследованияи реализации интерфейса37117.2. Деятельность UP: Проектирование классаРеализация прецедента –проектированиеРазработчиккомпонентовИнтерфейс[полный]Проектный класс[в общих чертах]ПроектированиеклассаИнтерфейс[в общих чертах]Проектный класс[полный]Класс анализа[полный]Рис. 17.2. Деятельность Проектирование класса. Адаптировано с рис. 9.39[Jacobson 1] с разрешения издательства Addison+Wesleyчертах] и Проектный класс [полный]. Однако это не так. Они просто представляют один и тот же артефакт (проектный класс) на разных этапахразвития.Если взять набор артефактов UPпроекта в конце фазы Уточнение илив начале Построения, то не найдется артефактов под названием Проектный класс [в общих чертах] или Проектный класс [полный]. Там будут толькопроектные классы, находящиеся на разных этапах своего развития.С точки зрения UP «полный» проектный класс – это класс, достаточнодетализированный, чтобы служить базой для создания исходного кода.

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

В этой главе рассказывается, как моделировать проектныеклассы, достаточно подробные для любого проекта.372Глава 17. Проектные классыСоображения по поводу артефактов Проектный класс [в общих чертах]и Проектный класс [полный] также применимы к Интерфейсу [в общих чертах] и Интерфейсу [полный].Входной артефакт Реализация прецедента – проектирование (use case realization – design) – это всегонавсего завершающий этап жизненного циклареализации прецедента.

Хотя он изображен вливающимся в Проектирование класса, на самом деле он включает проектные классы как частьсвоей структуры и разрабатывается параллельно с ними. Отложим обсуждение Реализации прецедента – проектирование до главы 20, поскольку, по нашему мнению, эффективнее (и понятней для читателя) сначала рассмотреть его составляющие части.17.3. Что такое проектные классы?Проектные классы – это классы, описания которых настолько полные, что они могут быть реализованы.При анализе источником классов является предметная область.

Это набор требований, описывающий задачу, которую необходимо решить.Как мы видели, прецеденты, описания требований, глоссарии и любаядругая относящаяся к делу информация могут использоваться как источник классов анализа.Предметная область и область решения являются источником проектных классов.У проектных классов два источника:•Предметная область посредством уточнения классов анализа; этоуточнение включает добавление деталей реализации. В ходе этогопроцесса часто обнаруживается, что высокоабстрактный класс анализа необходимо разбить на два или более детализированных проектных класса. Реализацию класса анализа описывает отношение«trace», устанавливаемое между ним и одним или более проектнымиклассами.•Область решения – это царство библиотек утилитных классов и многократно используемых компонентов, таких как Time, Date, String,коллекции и т.

д. Здесь находится промежуточное программноеобеспечение (middleware), такое как коммуникационное ПО, базыданных (и реляционные, и объектные) и компонентные инфраструктуры, например .NET, CORBA или Enterprise JavaBeans, а такжесредства для построения GUI. Эта область предоставляет технические инструментальные средства для реализации системы.Это проиллюстрировано на рис. 17.3.При анализе моделируется, что должна делать система.

При проектировании моделируется то, как это поведение может быть реализовано.37317.3. Что такое проектные классы?Предметная областьКлассы анализаПроектные классыОбласть решенияjava.utilРис. 17.3. Два источника проектных классов: предметная областьи область решенияПочему класс анализа может быть уточнен в один или более проектных классов или интерфейсов? Это понятно, поскольку класс анализаописан на очень высоком уровне абстракции. Здесь нет полного набораатрибутов, а набор операций – это фактически только эскиз, отражающий ключевые сервисы, предлагаемые классом.При переходе к проектированию все операции и атрибуты класса должны быть полностью описаны, поэтому нередко он становится слишкомбольшим.

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

Это выясняется для каждого конкретного проекта индивидуально.Однако если предполагается использовать проектные классы для генерации кода с помощью соответствующим образом оснащенного инструментального средства моделирования, их описания должны бытьполными во всех отношениях. Генератор кода, в отличие от программиста, не может заполнять пробелы. Далее в этой главе обсуждениематериала ведется исходя из предположения, что требуется очень высокая степень детализации.374Глава 17.

Проектные классы17.4. Анатомия проектного классаС помощью классов анализа делается попытка зафиксировать требуемое поведение системы без рассмотрения его возможной реализации.В проектных классах необходимо точно определить, как каждыйкласс будет осуществлять свои обязанности. Для этого нужно сделатьследующее:•закончить набор атрибутов и полностью описать их, включая имя,тип, видимость и (необязательно) применяемое по умолчанию значение;•закончить набор операций и полностью описать их, включая имя,список параметров и возвращаемый тип.Этот процесс уточнения проиллюстрирован на рис. 17.4.Как было показано в главе 8, операция в классе анализа – это высокоуровневое логическое описание части функциональности, предлагаемой классом. В соответствующих проектных классах каждая операция класса анализа уточняется и превращается в одну или более детализированных и полностью описанных операций, которые могут бытьреализованы как исходный код.

Следовательно, одна высокоуровневая операция этапа анализа на самом деле может распадаться на однуили более проектных операций, которые можно реализовать. Эти детализированные операции уровня проектирования иногда называют методами.Для иллюстрации рассмотрим следующий пример. При анализе системы регистрации авиапассажиров можно определить высокоуровневуюоперацию checkIn() (зарегистрировать). Однако если вам когдалибоприходилось стоять в очереди на регистрацию на рейс, то вы знаете,что это довольно сложный бизнеспроцесс, включающий сбор и проверку достоверности определенной информации о пассажире, приеманализпроектированиеBankAccountBankAccountnamenumberbalancedeposit( )withdraw( )calculateInterest( )«trace»конструктор–name : String–number : String–balance : double = 0+BankAccount( name:String, number:String)+deposit( m:double ) : void+withdraw( m:double ) : boolean+calculateInterest( ) : double+getName( ) : String+setName( n:String ) : void+getAddress( ) : String+setAddress ( a:String ) : voi+getBalance( ) : doubleРис.

17.4. Детализация на этапе проектирования17.5. Правильно сформированные проектные классы375багажа и назначение посадочного места в самолете. Поэтому справедливо предполагать, что при подробном проектировании процесса высокоуровневая аналитическая операция checkIn() будет разбита на рядопераций, находящихся на более низком уровне абстракции. Высокоуровневая операция checkIn() может сохраниться, но на этапе проектирования она будет вызывать ряд «вспомогательных» операций, распределяя среди них свои обязанности. Может даже случиться так, чтодля реализации довольно сложного процесса регистрации необходимобудет ввести несколько новых вспомогательных классов, которые небыли обозначены при анализе.17.5.