WWW.LIBRUS.DOBROTA.BIZ
БЕСПЛАТНАЯ  ИНТЕРНЕТ  БИБЛИОТЕКА - собрание публикаций
 

Pages:   || 2 | 3 | 4 | 5 |

«Мартина ФаУflера Предметно-ориентированное П оекти ОБ иие еТРУКТУРИ3АЦИЯ елО жныIx ПРО rPAMMHbIX СИ еТЕМ Domain -Driven Design TACKLING COMPLEXITY IN ТНЕ HEART OFSOFTWARE Eric Evans Addison-Wesley ...»

-- [ Страница 1 ] --

рик BaHC

Преgисловие

Мартина ФаУflера

Предметно-ориентированное

П оекти ОБ иие

еТРУКТУРИ3АЦИЯ елО жныIx

ПРО rPAMMHbIX СИ еТЕМ

Domain -Driven

Design

TACKLING COMPLEXITY IN ТНЕ HEART

OFSOFTWARE

Eric Evans

Addison-Wesley

.'"

• • •

Boston San Francisco New York Toronto

• • • •

Muntreal London Munich Paris Madrid • • • • Capetown Sydney Tokyo Singapore Mexico City Предметно-ориентированное П оекти ование

СТРУRТУРИ3АЦИЯ СЛОЖНЫХ

ПРО ГРАММНЫХ СИСТЕМ

3рик 3ванс • Издательский дом "Вильяме" Москва Санкт-Петербург Киев • • ББК 32.973.26-0 18.2.75 Э 14 УДК 68 1.3.07 Издательский дом "Вильяме" Зав. редакцией С.Н. Трuгуб Перевод с английского и редакция в.л. БродовОlО

По общим вопросам обращайтесь в Издательский дом "Вильяме" по адресу:

info@williamspublishing.com, http://www.williamspublishing.com Эванс, Эрик .

Э 14 Предметно-ориентированное проектирование (DDD): структуризация сложных программных систем. : Пер. с англ М.: 000 " И.Д. Вил. ьямс", 2011. - 448 с. : ил. Парал. тит. англ .

ISBN 978-5-8459- 1 597-9 ( рус.) ББК 32.973.26-018.2.75 Все на-шания прuграммных продуктов являются зарегистрированными торговыми марками соответствующих фирм .

Никакая часть настоящего издания ни в каких целях не может быть воспроизведена в какой бы то ни было форме и какими бы то ни было средствами, будь то электронные или механические, включая фотокопирование и эапись на маг­ нитный носитель, если на это нет письменного разрешения издательства Addison-Wesley PubIishing Сошрапу, Inc .

Authorized translation from the English language edition published Ьу Addison-Weslcy Publishillg Сатрапу, Iпс, Copyright © 2004 Ьу Eric Еvапs .

АН rights reserved. No part of this publication тау Ье reproduced, stored in а retrieval sуstеш, or transmitted, in апу fоrш, or Ьу апу шеапs, elcctrunic, mechanical, photocopying, recording, or otherwise, without the prior consent of the puhlisher .

Russian language edition pllblished Ьу Williams Publishing House according t:o the Agrcement witll R&I Enterprises International, Copyright © 2011

–  –  –

ЧАСТЬ 11. СТРУКТУРНЫЕ ЭЛЕМЕНТЫ

ПРЕДМЕТНО-ОРИЕНТИРОВАННОГО ПРОЕКТИРОВАНИЯ

Глава 4. Изоляция предметной области 79 Глава 5. Модель, выраженная в программе 89 Глав а 6. Цикл су ществования объектов модели 123 Глава 7. Работа с языком: расширенный пример 153

–  –  –

Глава 2. Коммуникация и язык 45 Единый язык оделирование вслух Одна команда - один язык Документация, диаграммы, схемы Письменная проектная документация Выполняемый код реша ет все Пояснительные модели Глава з .

Связь между моделью и реализацией 61 Проектирование по модели Парадигмы моделирования и средства программирования Анатомия модели: зачем мо дель нужна пользователю Моделировщики- практики

–  –  –

Глава 16. Крупномасштабная структура 375 Эволюционная организация Метафо рический об раз системы "Наивный образ": почему он нам не нужен Уровни разделения обязанностей Выбор подходящих уровней

–  –  –

Глава 17. Объединение стратегических подходов 411 Сочетание крупномасштабных структур и ограниченных контекстов Сочетание крупномасштабной структуры и дистилляции Первоначальная оценка Кому планировать стратегию Самозарождение структуры в ходе разработки 416 Смежная группа по разработке архитектуры Шесть принципов принятия решений при стратегическом проектировании То же верно и для технических сред проектирования Долой генеральный план Заключение

–  –  –





(KentBeck) "Эрик Эванс написал прекрасную книгу о том, как привести архитектуру программы в соответствие с умозрительной моделью той предметной области, для которой эта про­ грамма предназначена .

Его книга хорошо согласуется с идеями экстремального программирования. Суть книги - не в рисовании схем предметных областей, а в образе мышления, в использова­ нии правильного языка для их описания, в такой организации программы, которая бы отражала постоянно углуБЛЯIощееся понимание предмета. Эрик полагает, что узнать что­ то новое о предметной области равно возможно как в начале, так и в конце работы над проектом, поэтому в его методике значительную роль играет рефакторинг .

Книгу легко читать. У Эрика в запасе много интересных историй, и языком он владе­ ет хорошо. Я считаю эту книгу необходимым чтением для разработчиков программ и будущей классикой." Ральф Джонсон (Ralph]ohnson), автор книги "Design Pattems" "Если вам кажется, что ваша ставка на объектно-ориентированное программирование не окупает себя, то из этой книги вы узнаете, чего же вам не хватает." - Уорд Каннингем (Ward Сиnninghат) "Эрику удалось "ухватить" суть того, что опытные проеКТИРОВIЦИКИ программных объектов всегда знали, но с блеском проваливали все попытки донести это знание до своих коллег в смежных областях. Мы охотно делимся отдельными секретами... но нико­ гда не заботились об организации и систематизации принципов построения логической Кайл Браун (Kyle структуры предметной области. Вот почему эта книга так важна." Brown), автор книги "Enterprise]ava Programming with [ВМ WebSphere" "Эрик Эванс убедительно доказывает важность моделирования предметной области, его опредеЛЯЮlцее значение для разработки программного проекта, а также предлагает солидную теоретическую основу и набор методов для этой цели. Это знание непреходя­ щей ценности, и оно останется в обиходе еlце долгое время после того, как отомрут все Дэйв Коллинз (Dave Collins), автор книги нынешние методологии-скороспелки."

"Desig"ning Object-Oriented User lnter faces" "Эрик обобщил реальный опыт архитектурного проектирования и реализации профес­ сиональных приложений в виде полезной и нужной книги. Выступая с позиций опытного специалиста-практика, он обогатил нашу профессию своими описаниями всеобщего языка, аргументами в пользу совместной с пользователями разработки моделей, методами сопро­ вождения объектов на протяжении всего их существования, физического и логического структурирования программ, процедурой и анализом результатов глубокого рефакторин­ га." Лl0К Хоман (Lиkе Hohmann), автор Кllиги "Beyond Software Аrсhitесtиrе" Посвящается маме u папе

ПРЕДИСЛОВИЕ

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

Главное - это естественная сложность предметной области, к которой относится решае­ мая задача. Всякий раз, когда при разработке программного обеспечения возникает не­ обходимость автоматизировать созданные человеком сложные системы, избежать этой сложности нельзя - ею можно только "овладеть" .

Для этого необходима хорошая предметно-ориентированная модель, проникающая значительно дальше поверхностного взгляда на проблему. Если в такой модели удастся правильно отразить внутреннюю структуру предметной области, то разработчики про­ граммного обеспечения получат именно тот инструмент, в котором они нуждаются. Хо­ рошая модель предметной области представляет огромную ценность, но построить ее не­ легко. Умеют это делать немногие, а научить других этому искусству очень трудно .

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

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

Эрик Эванс сумел сформулировать и закрепить многое из того, что мы постепенно осознавали годами. Прежде всего, в предметно-ориентированном моделировании нельзя отделять понятия (концепции) от их реализации. Специалист по моделированию пред­ метных областей способен не только чертить диаграммы вместе с экспертом-аналитиком, но и программировать на Java вместе с программистом. Частично это происходит пото­ му, что нельзя построить полезную концептуальную модель, не рассматривая вопросы ее реализации. Но основная причина единства понятия и ее реализации все же состоит в том, что модель предметной области приносит наибольшую пользу только тогда, когда она предоставляет специалисту в этой предметной области и инженеру-разработчику единый ЯЗЫ'К, на котором они могли бы разговаривать друг с другом .

Еще один урок, который можно почерпнуть из этой книги, таков: в моделях предмет­ ных областей на самом деле не разделяют архитектуру и реализацию. Как и многие дру­ гие, я пришел к отрицанию принципа поэтапности - "сначала строим модель, потом ду­ маем о реализации". Опыт Э. Эванса учит нас, что действительно МОIцные модели эво­ люционируют со временем, и даже высококвалифицированные специалисты иногда обнаруживают, что наилучшие идеи приходят к ним уже после первого выпуска соответ­ СТВУЮIЦИХ программных систем .

Я думаю (и надеюсь), что эта книга сделает в своей области очень важное дело: помо­ жет структурировать и разложить "по полочкам" весьма зыбкую и неопределенную об­ ласть знания, а также научит многих людей пользоваться этим ценным инструментом .

Модели предметных областей могут оказать огромное влияние на разработку программ­ ного обеспечения, какие бы среды и языки при этом не ИСПОЛЬЗ0Вались .

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

Важно то, что он смог научиться чему-то как на победах, так и на поражениях, и еще важнее для нас, что он смог передать эти уроки своим читателям .

–  –  –

ПРЕД И СЛ ОВИ Е

ПРЕДИСЛОВИЕ РЕДАКТОРА РУССКОГО ПЕРЕВОДА

Переводить KaKYlo бы то ни было классическую работу, завоеваВIlIУЮ всеобщее призна­ ние среди специалистов, - это большая ответственность. А книга Э. Эванса обладает спе­ цификой, которая накладывает еще большую ответственность и создает дополнительные трудности при ее переводе .

Основной этап в процесс е работы над программным обеспечением, по мнению автора, создание "единого языка" (Ubiquitous Language). Это система понятий, терминов, катего­ рий, в рамках которой должны общаться между собой все причастные к разработке - заня­ ты ли они построением абстрактной модели прикладной деятельности, написанием собст­ венно программного кода или же обеспечением инфраструктуры для разработки. В целях успеха проекта этим же языком должны овладеть и заказчики, для которых пишется про­ грамма - специалисты-прикладники в той или иной предметной области .

Автор строго следит (и предлагает программистам следовать его примеру), чтобы единый язык программного проекта не запутывался, не приобретал двусмысленности, не перегружался лишним и не терял необходимого. Можно сказать, книга учит читателя­ программиста, как добиться четкости и ясности не просто в управлении проектом, но и в собственном мышлении тоже, ибо язык - основа мышления. Этой цели служит и выбор имен программных объектов, и выбор терминов на диаграммах моделей или классов, и отбор необходимого минимума знаний из предметной области, и их структуризация .

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

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

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

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

Впрочем, русскоязыIномуy IT -сообществу, которое в своей работе активно пользуется и русским, и английским языками, это не должно составить большого труда .

–  –  –

Ведущие программисты считали моделирование предметных областей (domain modeling) и проектирование архитектуры программных объектов на этой основе (doтain design) ключевой методологией разработки сложных программных систем на протяжении вот уже более двадцати лет. Тем не менее за это время было написано удивительно мало об основных задачах (что делать) и методах (как делать) этой области знания. Но несмот­ ря на отсутствие четкой формализации, в профессиональной среде постепенно "вызрела" система взглядов и подходов, которую я называю предметно -ориентированное nроекти­ рова1-lие (doтain-driven design, ппп) .

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

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

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

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

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

Реализация сложных систем требует серьезного подхода к моделированию архитек­ туры предметной области. В начале своей трудовой деятельности мне посчастливилось принять участие в проекте, в котором работе с предметной областью действительно при­ давали большое значение. Этот проект, относящийся к области по крайней мере столь же сложной, как и первый, тоже начинался с создания несложной программы для институ­ циональных треЙдеров. Но в данном случае первоначальная версия получила самое ин­ тенсивное продолжение. На каждом новом этапе разработки открывались захватываю­ Iцие перспективы по объединению и усовершенствованию возможностей преДЫДУIЦИХ версий. Группа разработчиков сумела среагировать на потребности трейдеров с должной гибкостью и эффективностью. Этим взлетом они были непосредственно обязаны модели предметной области - глубоко и последовательно проработанной, поэтапно улучшае­ мой, четко отраженной в коде. По мере того как разработчики вникали в предмет, совер­ шенствовалась и модель. Улучшалось понимание не только между самими разработчи­ ками, но и между группами экспертов и разработчиков. И вместо того чтобы наклады­ вать на авторов тяжкое бремя поддержки и доработки программы, архитектура проекта становилась, напротив, все более удобной для модификации и расширения .

К сожалению, для столь полного успеха проекта недостаточно только серьезного под­ хода к моделированию. Один из проектов, которым я занимался в прошлом, имел весьма амбициозную цель - создание глобальной корпоративной системы управления на осно­ ве предметной модели. Но после нескольких лет разочарований ожидания стали самыми заурядными. У группы разработчиков были в наличии хорошие технические возможно­ сти и хорошее понимание предметной области; они также уделили должное внимание модели. Но неправильно организованное распределение труда разработчиков привело к отделению моделирования от реализации, и в результате при проектировании архитек­ туры не учитывал ась вся глубина проделанного анализа. По крайней мере, объекты при­ кладной модели были спроектированы недостаточно строго, чтобы обеспечить их взаи­ модействие в сложных приложениях. Несколько итераций доработки не внесли в код никаких улучшений из-за разброса в уровне квалификации разработчиков - они, в це­ лом, не владели неформальным стилистическим и техническим аппаратом для создания модельных объектов, которые бы одновременно представляли собой практичные, рабо­ тоспособные программы. Шли месяцы, процесс разработки все усложнялся и запутывал­ ся, группа потеряла целостное видение системы. После нескольких лет усилий проект все-таки выдал "на-гора" небольшую полезную систему, но в итоге группа разработчиков отказалась как от своих прежних амбиций, так и от самой модели .

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

Некоторые ВЛИЯЮlцие на проектирование программ факторы имеют технический харак­ тер. Много труда уходит на проектирование сетей, баз данных и другие технические аспекты программного обеспечения. О решении таких проблем написаны многие тома. Целые армии программистов оттачивают свои умения и осваивают каждое HOBIlIecTBo в этой сфере .

–  –  –

ная проработка технической инфраструктуры. Для успешного проектирования программ необходимо систематически подходить к этому основному аспекту программирования .

В этой книге развиваются две основополагаЮlцие идеи .

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

2. Архитектура сложного программного обеспечения должна основываться на моде­ ли предметной области .

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

Процессы проектир ования и р азр аботки Книги по проектированию и книги по методике реализации программных систем.. .

Почему-то эти книги нечасто ссылаются друг на друга. И та, и другая область знания достаточно сложна. Эта книга - о проектировании, но, по моему мнению, проектирова­ ние и реализация неотделимы друг от друга. Архитектурные концепции следует успешно воплощать в программах, иначе они выродятся в пустую теорию .

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

Эта книга не привязана к какой-то конкретной методологии, но в целом ориентиро­ вана на новое семейство гибких методик разработки (agile development processes). В част­ ности, всегда подразумевается использование в проектах двух подходов, являющихся необходимыми предпосылками для применимости всего того, о чем говорится в книге .

1. Итеративный характер разработки. Итерационная разработка программ пропа­ гандируется и практикуется уже не первое десятилетие. Этот подход лежит в осно­ ве гибкой методологии. По ней, а также по экстремальному программированию (extreme programming, ХР) есть много хорошей литературы. Можно назвать такие книги, как Sumiving Object-Oriented Projects (Cockburn, 1 998 ) и Extreme Programming Explained (Beck, 1999) .

2. Тесное взаимодействие между разработчиками и специалистами в предметной об­ ласти. Особенность предметно-ориентированного проектирования такова, что в его ВВЕДЕНИЕ процессе в модель закладывается огромное количество знаний, отражающих глубо­ кое понимание предметной области и концентрацию на ее ключевых концепциях .

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

Экстремальное программирование, авторами которого являются Кент Бек (Kent Beck), Уорд Каннингем (Ward Cunningharn) и др. (см. Extreme Programming Ех­ plained [5]) наиболее известная из гибких методологий разработки программ, с кото­ рой лично я работал больше всего. На протяжении этой книги для конкретизации изло­ жения я буд у использовать именно ее в качестве основы для рассмотрения взаимодейст­ вия между проектированием и разработкой. Приведенные принципы можно легко адаптировать к другим гибким методологиям разработки .

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

В экстремальном программировании признается важность принятия проектных ре­ шений, но категорически отрицается жесткое заблаговременное планирование с полной детализацией проекта (что называют upfront design). Вместо этого прилагаlОТСЯ большие усилия для обеспечения коммуникации и способности быстро менять на правленность проекта. Имея такую способность, разработчики могут на любом этапе проекта выбирать простейшее из работоспособных решений, а затем постоянно выполнять рефакторинг, внося много мелких проектных улучшений и постепенно приходя к архитектуре, которая будет удовлетворять действительные потребности клиента .

Такой минимализм уже послужил "лекарством" против некоторых ИЗЛИIlIеств энту­ зиастов архитектурного проектирования. Многие проекты в свое время утонули в море документации, толку от которой практически не было. Их подвел "мандраж" - члены группы разработчиков так боялись несовершенств архитектуры, что вообlце никуда не двигались. Надо было что-то менять .

К сожалению, некоторым из этих методических идей грозит неправильная интерпре­ тация. У каждого программиста есть свое понятие о том, что такое "простеЙIlIее" реПlе­ ние. Непрерывный рефакторинг это последовательность мелких и зменений проектной архитектуры. Разработчики, не имеющие четких ориентиров, могут произвести на свет базу кода, плохо понятную и не поддаюп{уюся доработке, - т.е. прямую противополож­ ность слову "гибкость" (agility), которое дало название методике. Да, страх перед непред­ виденными требованиями часто ведет к излишней детализации архитектуры, но попытки избежать жесткого планирования могут перейти в другую фобию страх вообп{е перед любой глубокой проработкой модели .

Фактически, методика экстремального программирования ЛУЧlпе всего подходит разра­ ботчикам "с обостренным чутьем" в области архитектурного проектирования. Эта методика предполагает, что архитектуру можно улучшить рефакторингом и что происходить это должно часто и быстро. Но принятые в прошлом проектные решения могут как облегчить, так и затруднить сам процесс рефакторинга. Методика экстремального программирования призвана активизировать коммуникацию в группе разработчиков, но на сам процесс ком­ муникации также влияют решения, принятые при моделировании и проектировании .

В этой книге проектирование архитектуры и разработка программного продукта пе­ реплетаются; на примерах показано, как предметно-ориентированное проектирование и 20 В ВЕДЕН И Е гибкая методология разработки помогают друг другу. Если в контексте гибкой методо­ логии еще и принимается серьезный подход к моделированию предметной области, то это позволяет значительно ускорить разработку. Взаимосвязь между методикой разра­ ботки и моделированием предметной области делает такой подход более практичным, чем любые оторванные от жизни "чистые" архитектурные проекты .

Структура книги Эта книга разделена на четыре больш ие части .

Часть 1, "Модель предметной области в работе", содержит основные постановки задач предметно-ориентированного проектирования. От этих постановок будут непосредст­ венно зависеть практические приемы в дальнейших разделах. Существует множество подходов к разработке программного обеспечения, поэтому в части 1 даются определения терминов, а также очерчивается тот неявный контекст, который порождается примене­ нием модели предметной области для целей коммуникации и проектирования .

Часть 11, "Структурные элементы предметно-ориентированного проектирования", обобщает опыт практического объектно-ориентированного моделирования предметных областей, сводя его к набору основных структурных элементов-"кирпичиков". В этой части основное внимание уделяется преодолению пропасти между абстрактными моде­ лями и конкретными работающими программами. Использование стандартных шабло­ нов привносит в проектирование упорядоченность, а члены группы разработчиков луч­ ше понимают работу друг друга. Стандартные шаблоны также позволяют обогатить об­ щий язык терминологией, с помощью которой все разработчики могут обсуждать модели и п роектные решения .

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

Часть 111, "Углубляющий рефакторинг", посвящена переходу от отдельных "кирпичиков" к задаче сборки их в практические модели, дающие в конце концов конечный результат .

Вместо того чтобы сразу изложить секретные принципы проектирования, в этой части кни­ ги делается акцент на исследовательском процессе. Действительно ценные модели не воз­ никаIОТ в один день; они требуют глубокого понимания предметной области. А такое пони­ мание приходит не иначе, как в ходе работы: вначале архитектура реализуется в первом приближении, основанном пока на примитивной и наивной модели, а затем она снова и снова подвергается преобразованиям. Всякий раз, когда группа разработчиков делает скачок в понимании предмета, модель преобразуется для учета новых знаний, после чего код подвергается рефакторингу для отражения усовершенствований модели и раскрытия ее возможностей в приложении. Поэтапное погружение в предметную область (наподобие послойной очистки луковицы) дает результат в виде прорыва на новый уровень моделиро­ вания, после чего следует серия кардинальных изменений в архитектуре .

Творчество исследователя неформально по своей природе, но не обязательно хаотично .

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

Часть IV, "Стратегическое проектирование", посвящена ситуациям, возникающим в сложных системах, больших организациях, а также при взаимодействии с внешними и устаревшими системами. В этой части книги рассматривается три принципа, примениВВЕДЕНИЕ 21 мых К системе в целом: соблюдение контекста, дистилляция (в смысле выделения сути, концентрации на логике приложения) и крупномасштабный подход. Стратегические проектные решения принимаются как на уровне групп разработчиков, так и на уровне взаимодействия между группами. Стратегическое проектирование делает возможной реализацию задач из части 1 в более крупном масштабе - масштабе системы или прило­ жения на уровне обширной и разветвленной корпоративной сети .

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

Значительная часть книги написана в виде набора "архитектурных шаблонов". Чита­ тели смогут понять материал и не задумываясь об этом, но тем из них, кто интересуется стилем и форматом таких шаблонов, рекомендуется прочитать приложение .

Дополнительные материалы можно найти на сайте http://doma indriven­ design. org, в том числе примеры кода и дискуссии в профессиональном сообществе .

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

Для чтения книги требуется некоторое знакомство с объектно-ориентированным мо­ делированием. В примерах используются диаграммы UML и код Java, так что полезно владеть хотя бы основами этих языков (хотя доскональное их знание и не требуется) .

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

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

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

Материал книги изложен последовательно - ее можно читать с начала до конца или же с любой главы. Читатели с различной профессиональной подготовкой могут выбрать свой порядок чтения, но я бы рекомендовал всем начать с введения к части 1, а также с главы 1. Помимо этого, основными можно считать главы 2, 3, 9 и 14. Те, кто уже до не­ которой степени владеет материалом, смогут определить главные моменты, читая заго­ ловки и текст жирным шрифтом. Высококвалифицированный читатель может пропус­ тить части 1 и 11 и перейти к, вероятно, наиболее интересным для него частям 111 и 1У .

В дополнение к основному кругу читателей, кое-что полезное из этой книги могут почерпнуть также аналитики и руководители проектов, частично занятые в технической В ВЕДЕН И Е части. Аналитиков может привлечь взаимосвязь между моделированием и проекти­ их рованием, что позволит им сделать более эффективный вклад в работу в контексте про­ ектов с гибкой методологией разработки. Стратегические принципы проектирования также могут помочь им в постановке задач и организации работ .

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

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

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

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

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

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

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

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

Наши координаты:

info@wi l l i amspub l i shing. сот

E-mail:

VVVVVV: http ://www.wi l l i amspub l i shing. com

Адреса для писем из:

127055, г. Москва, ул. Лесная, Д. 43, стр. 1

России:

03150, Киев, а/я 152

Украи ны:

БЛАГОДАРНОСТИ

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

Приношу свою благодарность всем тем, кто просмотрел рукопись и сделал свои заме­ чания. Без этой работы книга просто не могла бы появиться на свет. Некоторые рецен­ зенты удостоили мою работу особенно щедрым вниманием. Так, группа Silicon Уаllеу Patterns Group, возглавляемая Рассом Рафером (Russ Rufer) и Трейси Биалек (Tracy Bi­ alek) изучала мою первую законченную черновую версию книги в течение нескольких недель. Группа рецензентов из Иллинойского университета ( University of Illinois) под руководством Ральфа Джонсона (Ralph Johnson) также провела несколько недель над более поздним черновиком. Слушать долгие и оживленные дискуссии этих групп оказа­ лось чрезвычайно полезно. Кайл Браун (Kyle Brown) и Мартин Фаулер (Martin Fowler) способствовали успеху дела подробными замечаниями, ценными наблюдениями и бес­ ценной моральной поддержкой (на совместной рыбалке). Комментарии Уорда Каннин­ гема (Ward Cunningham) помогли укрепить самые существенные слабые места в изло­ жении. Алистер Кокберн (Alistair Cockburn) с самого начала поощрял мою работу и по­ мог проб иться сквозь все сложности процесса публикации. За это же следует сказать спасибо и Хилари Эванс (Hilary Evans). Благодаря Дэвиду Сигелу (David Siegel) и Юд­ жину Уоллингфорду (Eugene Wallingford) мне удалось не опозориться в технической части изложения. Вибху Мохиндра (Vibhu Mohindra) и Владимир Гитлевич (Vladirnir Gitlevich), не жалея себя, проверили все примеры кода .

Роб Ми (Rob Мее ) ознакомился с самыми ранними моими опытами по данной теме и участвовал в наших совместных "мозговых штурмах" всякий раз, когда мне позарез требовалось с кем-то обсудить предлагаемый стиль архитектурного проектирования .

Значительно позже он также сидел со мной над очередным черновиком книги .

Один из основных поворотных моментов в написании книги связан с именем Джоша Кериевского Uosh Kerjevsky): он убедил меня испробовать формат-шаблон Александера (Alexandrian pattem format), в итоге занявший центральное место в организации книги .

Также благодаря его помощи впервые обрел целостный вид материал, теперь содержа­ IЦИЙСЯ в части 11. Это случилось, когда он интенсивно наставлял меня на путь истинный в ходе подготовки к конференции PLoP (Pattem Lаngиаgеs о/ Programs, или "Языки оnи­ са1lUЯ шаблонов в разработке nрогра.м.м") в 1999 году. Тогда-то и было положено начало этой книге .

Еще я хотел бы поблагодарить Авада Фаддула (Awad Faddoul) за те сотни часов, что я провел над бумагой за столом в его замечательном кафе. Этот приют спокойствия, да еще "много виндсер(ринга" - вот что помогало мне держаться .

Моей признательности также заслуживают Мартин Жlоссе (Martine Jusset), Ричард Паселк (Richard Paselk) и Росс Венэйблз (Ross Venables) за создание прекрасных фото­ гра(р и й для ИЛЛIострации нескольких ключевых концепций (СМ. ссылки в разде­ ле "Фотографии") .

Пр ежде чем приступить к этой книге, мне пришлось выработать собственный взгляд на разработку программ и понимание этого процесса. Мое формирование как специалиста стало возможно во многом благодаря щедрости нескольких замечательных людей, которые были мне и неформальными наставниками, и друзьями. На мой образ мышле­ ния в области проектирования программ оказали наибольшее, пусть и различное, влия­ ние Дэвид Сигел (David Siegel), Эрик Голд (Eric Gold) и Исульт Уайт (Iseult White) .

Между тем Брюс Гордон (Bruce Gordon), Ричард Фрейберг (Richard Freyberg) и д-р Джудит Сегал (Dr. Judith Segal) помогли мне, также каждый по-своему, пробить себе до­ рогу в мир успешных реальных проектов .

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

Руководитель моей магистерской диссертации, д-р Бала Субраманьюм (Dr. Bala Subramanium), приобщил меня к математическому моделированию, которое мы приме­ няли в вопросах химической кинетики. Моделирование - всегда моделирование, так что и эта работа частично вывела меня на путь, "приведший" к этой книге .

А еще раньше мое мировоззрение формировали мои родители, Кэрол и Гэри Эванс (Carol & Gary Evans). Заложили нужные основы и пробудили во мне интерес несколько замечательных учителей, особенно учитель математики в старших классах Дейл Керриер (Dale Currier), учительница английской словесности Мэри Браун (Mary Brown) и учи­ тельница естественных наук в шестом классе Джозефина Макгламери Oosephine McGlamery) .

Наконец, хочу поблагодарить своих друзей и членов семьи, а также Фернандо Де Ле­ она (Fernando De Leon) за поддержку на протяжении всего этого времени .

26 БЛАГОДАРНОСТ И Модель предметной области работе в Эта китайская карта XVIII столетия изображает весь мир. В центре ее находится Китай, и он же занимает большую часть карты, так что остальным странам уделяется лишь са­ мое поверхностное внимание. Такова была модель мира, приемлемая для того общества, которое преднамеренно замкнулось в самом себе. Но взгляд на мир, который отражала эта карта, должно быть, не слишком помогал в отношениях с иностранцами. А уж совре­ менному Китаю он никак не подошел бы. Карты - это модели, а каждая модель пред­ ставляет определенный аспект действительности или какую-нибудь идею, представляю­ IЦУЮ интерес. Модель -- - это упрощение; это такая интерпретация реальности, при кото­ рой из явления извлекаются существенные для решения задачи аспекты, а лишние детали игнорируются .

Всякая компьютерная программа имеет применение в той или иной области деятель­ ности или интересов своего пользователя. Область знания или деятельности, в которой пользователь использует программное обеспечение, и есть его предметная область (domain). Некоторые предметные области связаны с физической реальностью. Напри­ мер, в предметной области программы онлайн-бронирования авиабилетов мы имеем де­ ло с реальными людьми, желающими лететь на реальных самолетах. Другие предметные области трудно осязаемы физически - например, для программы бухгалтерского учета зто деньги и финансовая деятельность. Предметные области программ в большинстве своем не относятся непосредственно к компыотерной технике, хотя есть и исключения .

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

Чтобы создать программу действительно ценную для пользователей из какой-либо области деятельности, группа разработчиков должна задействовать запас знаний, ОТно сящийся к этой области. Широта требуемого кругозора может оказаться пугающей, объ­ ем и сложность информации это инструменты, подавлять воображение. Модели Ч АСТЬ 1 п р едназначенные как раз для того, чтобы справиться с этой нагрузкой. Модель представ­ ляет собой специально отобранный и сознательно упрощенный запас знаний в структу­ р ир ованной форме. Правильная модель придает информации смысл и позволяет скон­ центр ироваться на проблеме .

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

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

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

1. Модель и арxuтектура 1 программ ы взаимно определяют друг друга. Именно тесная связь между моделью и ее программной реализацией определяет важность и нуж­ ность самой модели, а также гарантирует, что проделанный при ее разработке ана­ лиз отражен в конечном результате, Т.е. в работающей программе. Связь между моделью и реализацией помогает также в процессе дальнейшей доработки про­ граммы и выпуска ее новых версий, поскольку и сам программный код можно ин­ терпретировать, основываясь на понимании модели. (См. главу 3.)

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

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

3. Модель это дистиллированное знание2. Модель представляет собой согласован­ ный между разработчиками способ структуризации знаний из предметной области, а также выделения элементов, представляющих наибольший интерес. Модель пеИменно таков примерный смысл термина design, применяемого в книге. Это построение принципиальной схемы, объектной архитектуры программ, а также результат такого построения .

Но самый полный и точный смысл этого слова передается только совокупностью понятий архи­

- П тектурного проектирования, конструирования и реконструирования. рuмеч. перев .

2 Автор в дальнейшем часто употребляет слово distillation как термин, означаlОЩИЙ очищение совокупности информации от всего л ишнего, выделение самой сути. Это процесс, издавна лежа­ ЩИЙ, например, в основе математического моделирования. - Прuмеч. перев .

МОДЕЛЬ ПРЕДМЕТНОЙ ОБЛАСТИ В РАБОТЕ

редает наш способ мыслить о предмете, выраженный в выборе терминов, выделе­ нии понятий И установке связей между ними. Разработчики и специалисты в предметной области имеют возможность совместно переработать информацию в такую форму, поскольку для этого у них имеется общий язык. А связь между моде­ лью и реализацией позволяет использовать опыт разработки ранних версий про­ граммы для корректировки самого процесса моделирования. (См. главу 1.) В следующих трех главах последовательно рассматривается значение каждого из этих применений модели, а также взаимосвязь между ними. Правильное использование этих принципов помогает создавать программы с обширным набором функциональных воз­ можностей, что потребовало бы намного больших усилий, если бы разработка велась не систематически, а "в текущем порядке" (ad hoc developтent) .

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

Однако в большинстве программных проектов главные приоритеты совершенно дру­ гие. Самые талантливые программисты не очень-то рвутся узнать достаточно о той при­ кладной области, с которой они работают, не говоря уже о том, чтобы усовершенствовать свои навыки моделирования этой об ласти. "Технари" любят четко поставленные в коли­ чественных терминах задачи, на которых можно отточить свои технические умения .

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

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

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

В одном из интервью на телевидении комедийный актер Джон Клиз Oohn Cleese) рассказал об истории, которая произошла на съемках фильма "Монти Пайтон и Святой Грааль" (Monty Python and the Holy Grail). Одну из сцен фильма снимали много раз, но она почему-то не получалась смешной. Наконец Джон Клиз посоветовался с коллегой, Майклом Пэлином (Michael Palin), который также играл роль в этой сцене. Были внесе­ ны небольшие изменения, снят еще один дубль, и на этот раз сцена оказалась смешной на том и порешили .

3 Автор у потребляет выражение heart о/ so/tware ("сердце" или "мозговой центр" программы) .

Это словосочетание входит и в название книги " Tackling Complexity at the Неап о/ So/tware", кото­ рое можно по смыслу перевести как "систематическое упрощение кода алгоритмически сложных систем". Смысл выражения разъяснен автором - это очищенная от всего лишнего алгоритмиче­ ская суть программы, то, что она делает для пользователя, какую главн ую задачу решает. Поэтому П избран такой перевод. рu.меч. перев .

ЧАСТЬ 1 На следующее утро Клиз просматривал черновой монтаж фильма, который монтажер собрал из материалов предыдущего съемочного дня. Но при просмотре сцены, отнявшей стольк о сил, Клиз вдруг обнаружил, что она опять не смешная - для нее был взят один из более ранних дублей. Он спросил у монтажера, почему тот не взял последний дубль, как ему бьшо сказано. "Нет, нельзя было. Кто-то вошел в кадр", - ответил монтажер. Джон Клиз пересмотрел сцену еще несколько раз, но ничего не обнаружил. Наконец монтажер остановил фильм и показал рукав пальто, который был виден одно мгновение в кадре .

Монтажер этого фильма был сосредоточен на точном выполнении своих профессио­ нальных обязанностей. Его заботило, что сказали бы о его работе в чисто техническом смысле другие специалисты по киномонтажу. В итоге б ыла потеряна именно "алгоритмическая" часть процесса (передача "ТЬе Late Late Show with Craig Kilborn", CBS, сентябрь 200 1 г.). К счастью, смешную сцену восстановил режиссер фильма, кото­ рый понимал толк в комедии. Точно так же и руководители программных проектов, по­ нимающие ключевую роль предметной области, могут вернуть процесс разработки в нормальное русло, если участники проекта вдруг начнут игнорировать необходимость проработки модели, которая отражала бы глубокое понимание предмета .

В этой книге будет показано, что работа с предметной областью открывает широкие возможности для развития профессиональных навыков архитектурного проектирования программ. Нечеткость, недетерминированность большинства предметных областей, для которых пишутся программы, на самом деле ставит перед разработчиками интересные технические задачи. Фактически во многих отраслях науки их "сложность" стала одной из модных тем для обсуждения и исследования, по мере того как ученые все больше пы­ таются иметь дело с реальным миром. Перед программистом встает аналогичная задача, когда он сталкивается со сложной предметной областью, никогда раньше не подвергав­ шейся формализации. Разработать четкую и ясную модель, которая не оставит от слож­ ности предмета камня на камне, - что может быть интереснее?

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

МОДЕЛЬ ПРЕДМЕТН О Й О БЛАСТИ Б РАБ ОТЕ 31

ГЛАВА 1

–  –  –

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

М ы попытались добиться от инженеров подробного технического задания на то, что именно должна делать программа. Увы, мимо. Они были замечательными инженерами, но их представление о программировании ограничивалось считыванием текстового фай­ ла данных, сортировкой, выводом его с кое-какими дополнениями, и генерированием от­ чета. Это было не то, что требовалось для резкого повышения производительности труда, которого они ожидали от программы .

Первые несколько рабочих совещаний оказались бесполезны. Но тут вдруг забрезжи­ ла надежда: подсказку дали сами отчеты, которые хотели получить инженеры на выходе .

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

–  –  –

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

Рис. 1.2 .

Специалист 1. Здесь компоненты - не обязательно микросхемы (чипы, chips) .

Программи ст (я). Так что, называть их просто "компонентами"?

С пециалист 1. Мы их называем "элементами" 1. Б схеме может быть много одинако­ вых элементов, представляющих один и тот же тип КОМПОIента .

Спе циалист 2. И цепь тоже нарисована как элемент .

Специали ст 1. Он не пользуется нашими обозначениями. У него на схеме одни квад­ ратики .

Программи ст. Увы, это так. Давайте я ПОЯСНIО свои обозначения .

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

Специали ст 1. Недостаточно сказать, что сигнал прибывает на Ref-Des2, нужно еще знать вывод (pin) .

Программи ст. Какой еще Ref-Des?

Специалист 2. Это то же самое, что и элемент. Так он называется в одной программе, которой мы пользуемся .

Специалист 1. Б общем, цепь соединяет определенный вывод одного элемента с опре­ деленным выводом другого .

Программи ст. Бы хотите сказать, что вывод принадлежит только одному элементу и ПОДКЛIочается только к одной цепи?

Специалист 1. Да, именно так .

С пециали ст 2. А еще у каждой цепи есть топология, т.е. система, по которой соеди­ НЯIОТСЯ друг с другом элементы цепи .

Программи ст. Ладно, что скажете о такой схеме?

–  –  –

Чтобы сосредоточиться на главном, мы на время ограничились изучением одной кон­ кретной функции, а именно программного прозванивания цепи (probe simuZation) - от­ слеживания распространения сигнала с целыо обнаружения тех или иных проблем в принципиальной схеме .

Программи ст. Я понимаIО, как сигнал передается Цепью на все соединенные с ней BывдъJ (Pins) а вот идет ли он куда-нибудь дальше? Имеет ли к этому отношение То ­ пология (Тороl0gy)?

Специалист 2. Нет. Сигнал про пускает сквозь себя компонент .

–  –  –

ЧАСТЬ 1. МОДЕЛЬ ПРЕДМЕТНОЙ ОБЛАСТИ В РАБОТЕ

Программист. Мы, конечно же, не будем моделировать внутреннее устройство и ра­ боту микросхемы. Это слишком сложно .

С пециалист 2. А нам и не нужно. Можно сделать проще: составить список сигналь­ ных импульсов (pushes), передаваемых через компонент от одних BывдовB К другим .

Программист. Что-то вроде этого?

(Методом проб и ошибок мы наконец набросали примерный сценарий.)

–  –  –

Программист. А что, собственно, вы хотите узнать из этого расчета?

Специалист 2. Мы ищем долгие задержки сигнала - скажем, любой путь прохождения длиннее двух или трех переприемов (hops). Это основное правило. Если путь прохождения сигнала слишком длинный, сигнал может не успеть поступить за один такт частоты .

Программист. Длиннее трех переприемов... То есть, нужно вычислить длину пути про х ождения. А что такое "переприем"?

Специалист 2. Это один проход сигнала по Цепи .

Программист. То есть, мы можем передать количество переприемов, а Цепь увеличит его, например, так .

–  –  –

Программист. Единственное, что мне пока неясно это откуда возьмутся "сигнальные импульсы". Нам что же, придется хранить такие данные для каждого Элемента?

Специалист 2. Сигнальные импульсы будут одними и теми же для всех элементов одного компонентного типа .

–  –  –

Специалист 2. Я не все тут до конца понял, но могу согласиться, что сохранение на­ бора сигнальных импульсов для каждого компонента будет иметь примерно такой вид .

Программист. Прошу прощения, тут я немножко углубился в детали. Задумался и увлекся... Так где тут у нас участвует Топология?

С пециалист 1. В прозванивании топология не используется .

Программист. Тогда я пока ее опущу, хорошо? Когда дело дойдет до следующих функций, мы вернем ее на место .

И вот дело пошло (кстати, с гораздо большим числом заминок, чем здесь описано) .

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

–  –  –

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

Ч АСТЬ МОДЕЛЬ П РЕДМЕТНОЙ ОБЛАСТИ В РАБОТЕ

длины путей прохождения с помощью объектов J ava. Сами объекты выражали собой мо­ дель, которую мы построили совместно со специалистами в предметной области .

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

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

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

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

1. УстановШlИ связь между моделью и ее реализацией. Уже в самом грубом прототипе присутствовала существенная связь с действительностью, и после всех последую­ щих доработок эта связь сохранилась .

2. Ввели в обиход ЯЗЫК, основанный на модели. Вначале инженерам приходилось объяс­ нять мне элементарные понятия схемотехники, а мне - объяснять им, что такое схе­ ма взаимоотношений классов. Но по ходу проекта мы смогли вооружиться понятия­ ми, взятыми из самой модели, составить из них предложения, согласующиеся со структурой модели, и в результате достичь полного понимания без переводчика .

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

4. ЗанUМШlИСЪ дucmWULЯЦИей модели. По мере того как создание модели близилось к за­ вершению, в нее добавлялись важные понятия. Но также важно и то, что понятия, ока­ завшиеся бесполезными или второстепенными, были отброшены. Если бесполезное понятие было тесно связано с необходимым, то находилась новая модель, в которой су­ щественное понятие легко отделялось, а второстепенное отбрасывалось .

5. Экспериментировали и nроводwtи мозговые штурмы. Наличие общего языка, набро­ сков схем и готовности к интеллектуальным прорывам превратили наши дискуссии в ГЛАВА 1. ПЕРЕРАБ О ТКА ЗНАНИЙ 37 экспериментальную лабораторию по разработке модели, где "обкатывались" и оце­ нивались сотни опытных вариантов. В процессе пошагового исследования рабочих сценариев даже устные высказывания участников срабатывали как быстрые тесты на пригодность предлагаемой модели, поскольку ухо человека легко отличает ясность и простоту от косноязычия .

В общем, именно творческий процесс мозгового штурма и интенсивного эксперимен­ тирования, облеченный в форму единого языка модели и направляемый обратной свя­ зью от программной реализации, сделал возможным создание информоемкой модели и ее дистилляцию. Знания, имеющиеся у коллектива разработчиков, превращаются в ценные для работы модели именно в результате такого процесса переработки знаний (knowledge crunching)3 .

П ер ера ботка знаний Финансовые аналитики обрабатывают цифры. Они перелопачиваIОТ горы подробной документации с количественными данными, комбинируя числа так и эдак в поисках скрытого смысла, желая найти такую ПрОСТУIО форму для представления важнейшей су­ ти информации, чтобы она стала основой для принятия финансового решения .

Квалифицированные специалисты по моделированию предметных областей обраба­ TbIBaIoT и перерабатываIОТ знания. Они погружаются в поток информации и ищут в нем самую важную CTPYIO. Они испытывают один метод организации за другим, стараясь найти простое представление, которое бы придало смысл всему этому массиву данных .

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

Переработка знаний не осуществляется в одиночку. Для этой цели разработчики про­ граммы сотрудничаIОТ со специалистами в предметной области - как правило, руководя этим процессом. Вместе они привлекают информацию и перерабатываIОТ ее в удобную форму. Исходное информационное сырье приходит от специалистов в предметной об­ ласти, пользователей сущеСТВУIОЩИХ систем, из опыта технических сотрудников проекта по работе с аналогичными, более ранними системами или другими проектами в той же области знания. Информация поступает в виде проектной или деловой документации, а также бесконечных устных дискуссий. Ранние версии программ или их прототипы да­ ют группе обратную связь и помогают видоизменять ее взгляды на проблему .

В старой "каскадной методике" (waterfall тethod) специалисты по предметной облас­ ти выдавали информацию аналитикам; те ее поглощали и абстрагировали, а затем пере­ давали результат программистам, которые и писали программы. Этот подход неудачен, поскольку совершенно лишен обратной связи. Создание модели целиком возложено на аналитиков, а исходными данными им служит только информация от специалистов .

Аналитики не имеют возможности научиться чему-либо у программистов или проанали­ зировать результаты работы черновых версий программы. Знания протекаIОТ в одном направлении, но не накапливаются .

3 " Переработку" тут следует понимать как в словосочетании "перерабатывающая промышлен­ ность": из набора знаний, существующего в нескольких головах и источниках, изготавливается но­ В вый интеллектуальный продукт - строгая модель, систематизирующая эти знания. оригиналь­ ном словосочетании knolR.Jledge crunching имеется и несколько гастрономический оттенок пере­ жевывания и переваривания. - Прuмеч. перев .

ЧАСТЬ 1. МОДЕЛЬ ПРЕДМЕТНОЙ ОБЛАСТИ В РАБОТЕ

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

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

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

Так они приходят к пониманию того, какая строгость понятий нужна для реализации программного проекта .

Все это превращает группу разработчиков в квалифицированных "переработчиков знаний" (knowledge crunchers). Они отсеиваIОТ все лишнее и переделывают модель во все более полезную форму. Благодаря вкладу аналитиков и программистов модель имеет четкую организацию и должный уровень абстракции, что делает ее ценным инструмен­ том для программной реализации. Благодаря вкладу специалистов в предметной области модель отражает глубокие знания из этой области. Абстрагированные понятия модели точно соответствуют основным положениям предметной области .

По мере улучшения модели она сама становится средством организации информа­ ции, которая продолжает поступать для проекта. Она позволяет сосредоточить анализ технических требований на главном. Модель тесно связана с процессом программирова­ ния и архитектурного проектирования. В идеальном рабочем цикле такая модель углуб­ ляет знания членов группы о предметной области, дает им более ясное видение пробле­ мы и приводит К дальнейшему усовершенствованию самой же модели. Совершенства модели никогда не достигают, но они ЭВОЛЮЦИОНИРУIОТ. От них требуется практическая применимость при освоении прикладной области знаний, а также достаточная строгость, благодаря которой программный код был бы прост В реализации и понимании .

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

ГЛАВА 1. ПЕРЕРАБОТКА З НАНИЙ

и кажется не слишком сложной технически, она еще может преподнести сюрприз - за­ ранее не известно, что именно из нее мы не знаем. А невежество заставляет делать лож­ ные предположения .

Между тем в ЛIобом проекте существующая база знаний может "дать течь". Напри­ мер, уволились сотрудники, которые уже чему-то научились. Или рабочая группа реор­ ганизовалась, и накопленные ею знания снова стали фрагментарными. Или, скажем, критически важные подсистемы отданы для разработки субподрядчикам, и те присыла­ ют код, но не передают соответствующие знания, лежащие в его основе. Как правило, проектирование программ выполняется так, что ни код, ни документация не выражаIОТ знания, обретенные тяжкими трудами, в явной, понятной форме. Если по какой-то при­ чине прекращается устная передача знаний в группе, это означает их потерю .

Высокопроизводительные группы разработчиков наращивают свои знания созна­ тельно, практикуя 1lеnреРЫ8и0е обучение [ 1 6]. Для разработчиков программного обеспе­ чения это означает совершенствование своих технических навыков и знаний в области программирования, а также общих навыков моделирования предметных областей (например, таких, как описаны в этой книге). Но СIода же входит и серьезное изучение предметной области, с которой они работаIОТ в текущий момент .

Разработчики, склонные к самообразованию, образуют наиболее стабильное ядро группы, поэтому их ставят на самые ответственные этапы разработки. ( Более подробно об этом см. главу 15.) Накопленные этим ядром группы знания даIОТ возможность пере­ рабатывать дальнейшую информацию более эффективно .

В этом месте стоит остановиться и задать себе вопрос: вы узнали что-нибудь о проек­ тировании печатных плат из того, что было сказано выше? Пусть этот пример и был по­ верхностным, но при обсуждении модели всегда происходит обучение. Лично я узнал очень много нового. Я не стал инженером-схемотехником, но такая задача и не ставилась .

Зато я научился разговаривать со специалистами, овладел основными понятиями, суще­ ственными для работы программы, и проверил на прочность то, что мы создавали .

В действительности группа разработки вскоре узнала, что функция прозванивания цепей не относится к наиболее важным, и со временем от ее реализации вообще отказа­ ЛИСЬ. Вместе с ней отказались от тех элементов модели, которые описывали прохождение сигнальных импульсов через компоненты и подсчет количества переприемов. Основное смысловое ядро программы, как оказалось, состояло в другом. Поэтому модель измени­ лась так, чтобы на первое место вышли самые нужные аспекты. Специалисты тоже кое­ чему научились и более четко сформулировали цель работы программы. (Все это под­ робно рассматривается в главе 15.) Даже при этом работа, проделанная на первом этапе, не пропала впустую. Сохрани­ лись ключевые элементы модели, но что еще важнее, был запущен процесс переработки знаний, который сделал всю последующую работу эффективной: накопление знаний и разработчиками, и специалистами в предметной области, и другими членами группы;

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

Инф ормоемкая архитектура Та разновидность знания, которая заКЛIочена в модели из приведенного примера с проектированием печатных плат, далеко не ограничивается набором названий и опреде­ лений. Для предметной области не менее, чем объекты, важны операции и правила; во вся­ кой области знания имеIОТСЯ различные категории понятий. При правильной переработке знаний возникают модели, в которых все это учитывается. Параллельно с модификацией

ЧАСТЬ 1. МОДЕЛЬ ПРЕДМЕТНОЙ ОБЛАСТИ В РАБОТЕ

модели разработчики выполняют рефакторинг программной реализации для отражения это:й модели, Т.е. обрабатывают сформированные знания посредством программы .

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

Пример Извлечение CKpbIToro понятия Начнем с очень простой модели предметной области, которая могла бы стать основой ДЛЯ программы бронирования грузомест в корабельных рейсах .

–  –  –

Кто-то из клиентов обязательно отменит свой запрос перед самым рейсом, поэтому в .

индустрии грузоперевозок стало стандартным правилом принимать больше заказов на грузоместа, чем на самом дел может перевезти судно за один рейс. Такую ситуацию на­ зывают избыточным резервированием (overbooking) Иногда для этой цели просто при­ нимают заказы с избытком на фиксированный процент - например, на 1 1 0% от грузо­ подъемности судна. В других случаях применяют более сложные правила, отдавая пред­ почтение определенным категориям клиентов или грузов .

4 Тут и далее у автор а часто употребляется выражение business rule. Это соотношение между объектами, заданное ограничение или п р авило в соответствующей области знания. В тео р ии авто­ матизированных систем уп р авления (АСУ) есть термин "деловой регламент" (алгор итм реализа­ ции операций в рамках АСУ пр едприятия), поэтому business rule соответствует выражению

- Прuмеч. перев .

" правило делового р егламента" .

ГЛАВА 1. ПЕРЕРАБОТКА ЗНАНИЙ

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

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

Разрешить избыточное резервирование в размере 10% .

Диаграмма классов и код приобретут такой вид .

–  –  –

5 Нельзя согласиться с прямолинейным переводом этого слова как "политика", пусть даже кое­ где оно уже и прижилось. Это стратегия, методика, принятая процедура, образ действий, регла­

- Прuмеч. перев .

мент .

–  –  –

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

Следует отметить, что не рекомендуется nрu.менять столь придирчивый подход к nро­ екmuрованию каждой мелочи в программн ой реализации предметной области. В главе 1 5, посвященной дистилляции, будет подробно рассмотрен вопрос о том, как сосредоточить­ ся на главном и минимизировать или отделить все остальное. А этот пример призван по­ казать, что модель предметной области и соотвеТСТВУIощая архитектура программы по­ могают зафиксировать знание в доступной форме. Такой подход имеет следующие пре­ имущества .

1. Чтобы довести архитектуру до такого уровня, программистам и остальным участ­ никам проекта придется осознать, что, по сути, избыточное резервирование это четко сформулированное и важное регламентное правило, а не просто некая мало­ вразумительная вычислительная операция .

2. Программисты смогут показывать специалистам в предметной области свои тех­ нические наработки, вплоть до кода, и те поймут, о чем идет речь (конечно, при помощи и под руководством программистов). Этим самым будет замкнута цепь обратной связи .

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

ГЛАВА 1. П ЕРЕРАБОТКА 3НАн и tI 43 Приведенный выше пример в какой-то мере основан на одном из проектов, которым я занимался и которым воспользуюсь еще для нескольких примеров в этой книге: системе обслуживания контейнерных перевозок .

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

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

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

Углубленное понимание сути грузоперевозок не привело к удалеНИIО объекта мар ­ шрут, но модель изменилась очень сильно. Мы стали воспринимать перевозки не как пе­ ремещение контейнеров с места на место, а как передачу полномочий и ответственности за груз от одного Iоридического лица другому. Функции управления этой передачей больше не были "неуклюжими придатками" к операциям погрузки-разгрузки, а органич­ но поддержи вались в самой модели, которая и выросла из понимания существенной взаимосвязи между физическими операциями и юридической ответственностью .

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

–  –  –

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

Коммуникация на основе модели не ограничивается рисованием диаграмм на унифи­ цированном языке моделирования ( Uni/ied Modeling Lаngиаgе, UML). ДЛЯ наиболее эф­ фективного применения модели она должна буквально "пронизывать" все средства ком­ муникации проекта. Благодаря ей повышается полезность как текстовой документации, так и неформальных диаграмм или дискуссий, важность которых подчеркивается в гиб­ ких (agile) методологиях разработки. Улучшается качество коммуникации как для само­ го кода, так и для его тестов .

Итак, роль общего языка в проекте хотя и не всегда осознается, но является осново­ полагаIощеЙ .

Единый язык Ты должен фразу написать, Нарезать на слова, И как попало разбросать, Перемешав сперва .

Порядок слов не важен тут, И не нужна канва .

Льюис Кэрролл, "Poeta Fit, Non Nаsсitиr"6 Чтобы разработать гибкую, информоеМКУIО архитектуру программы, группе разра­ ботчиков необходимо иметь богатый возможностями общий язык и активно эксперимен­ тировать с ним, что редко происходит в программных проектах .

Специалисты в предметных областях не слишком хорошо понимаIОТ технический жарmн разработчиков, но сами при этом пользуются собственным профессиональным жаргоном даже несколькими его "диалектами". С другой стороны, разработчики могут понимать и об­ суждать систему в описательных и функциональных терминах, никак не привязываясь к тому смыслу, который в свой язык вкладывают специалисты. Могут они и создавать абстракции, полезные для проектирования программы, но непонятные специалистам-предметникам. Про­ граммисты, работаIощие над разными частями проекта, к тому же вырабатывают собственные архитектурные концепции и способы описания предметной области .

"Поэтами становятся, а не рождаются" (лат.). Перевод М. БородицкоЙ .

ГЛАВА 2. КОММУНИКАЦИЯ И Я З ЫК 45 Учитывая все эти языковые барьеры, специалисты с трудом могут описать, что же им нужно .

Программисты, пытаясь разобраться в новом для них предмете, с трудом их по­ нимаIОТ. Пусть нескольким членам группы и удается стать двуязычными, но они оказы­ ваются в роли узких теснин в бурном потоке информации, а их перевод не всегда оказы­ вается точным .

В проекте, в котором нет общего языка, программистам приходится служить перево­ дчиками для специалистов из предметной области. Специалисты выполняют перевод между программистами и другими специалистами. Программисты переводят даже друг для друга. Перевод затуманивает концепции модели, и в результате коду грозит разру­ шительный рефакторинг. Непрямой характер коммуникации скрадывает появление "еретиков" - разные члены группы употребляют термины в разном смысле, сами того не понимая. Программа от этого становится ненадежной, а разные ее части - плохо совмес­ тимыми друг с другом (см. главу 14). Необходимость в переводе ухудшает обмен зна­ ниями и идеями - основной источник глубокого понимания модели .

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

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

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

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

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

Словарь этого ЕДИНОГО ЯЗЫКА состоит из имен классов и основных операций. ЯЗЫК содержит термины для обсуждения правил, явно сформулированных в модели. Допол­ нением к ним служат термины из принципов высокоуровневой организации, которым подчинена модель (например, КАРТЫ КОНТЕКСТОВ и крупномасштабные структуры, рас­ сматриваемые в главах 14 и 1 6). Наконец, этот язык обогащается названиями шаблонов, которые группа разработчиков применяет к модели .

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

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

ЧАСТЬ I. МОДЕЛЬ ПРЕДМЕТНОЙ ОБЛАСТИ В РАБОТЕ

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

Может показаться, что возникает замкнутый круг. Но процесс переработки знаний может породить и более качественную модель, если разработчики в достаточной мере привержены единому языку на основе модели. Настойчивое употребление ЕДИНОГО ЯЗЫКА обязательно выявит слабые места в lVl0дели, и группа путем эксперимента найдет альтернативу неУКЛIОЖИМ понятиям или соотношениям. По мере обнаружения пробелов в языке будут появляться новые слова. Изменения в языке следует nриниматъ как изме­ нения в модели - соответственно группа разработчиков должна вносить изменения в диаграммы классов, переименовывать классы и методы в исходном коде или даже из­ менять функции программы при изменении значения того или иного термина .

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

Разумеется, специалисты в предметной области будут общаться не только на ЕДИНОМ ЯЗЫКЕ; это нужно для целей объяснения или создания более широкого контекста. Но в пределах области действия модели они должны пользоваться этим ЯЗЫКОМ и бить тре­ вогу, если язык оказывается неудобным или неполным, а то и неправильным. Постоянно пользуясь языком на основе модели и неустанно его совершенствуя, мы приближаемся к модели одновременно полной и доступной пониманию, составленной из простых эле­ ментов, сочетание которых способно выражать сложные идеи .

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

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

О сознайте, что изм ене ния в ЕДИНОМ ЯЗЫКЕ - суть изменения в моде ли .

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

При наличии ЕДИНОГО ЯЗЫКА модель перестает быть просто придатком к архитекту­ ре, а становится естественной средой для ЛIобых совместных действий программистов и специалистов. Язык есть носитель динамической формы знания. Дискуссии на этом ЯЗЫКЕ извлекают "на поверхность" смысл, заКЛIоченный в диаграммах и коде .

***

ГЛАВА 2. КОММУНИ КАЦИЯ И ЯЗЫК

В этом рассуждении о ЕДИНОМ ЯЗЫКЕ предполагается, что в работу вовлечена всего одна модель. В главе 1 4 рассматривается случай сосуществования нескольких разных моделей (и ЯЗЫКОВ), а также вопрос, как удержать модель от распада на части .

Единый ЯЗЫК это основной носитель тех аспектов архитектуры, которые не про­ являются в коде, а именно крупномасштабных структур, оргаНИЗУIОЩИХ всю систему (см .

главу 16), ОГРАНИЧЕННЫХ КОНТЕКСТОВ, которые определяют отношения между разны­ ми системами и моделями (см. главу 14), и других шаблонов, относящихся к модели и программной архитектуре .

Пример

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

–  –  –

Пользоват ель. Итак, если мы меняем пункт растаможивания, то нужно менять весь план перевозки .

Программист. Да. Тогда мы удаляем все строки в таблице отправки грузов с задан­ ным идентификатором груза, потом передаем пункт отправки, пункт назначения и новый пункт растаможивания в Маршрутизатор (Routing Servi ce) и он заполняет таблицу заново. В объект Груз (Cargo) надо добавить логический переключатель, указывающий, есть ли данные в таблице отправки .

Пользовате ль. Удаляем строки? Ладно, вам виднее. Так вот, если пункта растаможи­ вания не было вообще, то делается то же самое .

Программист. Разумеется, когда меняется пункт отправки, пункт назначения или пункт растаможивания (или же он вводится первый раз), мы проверяем, есть ли данные по отправке грузов, удаляем их и просим Маршрутизатор заново сгенерировать их .

ЧАСТЬ 1. МОДЕЛЬ ПРЕДМЕТНОЙ ОБЛАСТИ В РАБОТЕ

Пользователь. Но, конечно, если пункт растаможивания не менялся, то всего этого делать не нужно .

Прогр аммист. А, это не проблема. Легче просто заставить Naршрутизатор генериро­ вать список погрузок-выгрузок каждый раз заново .

Пользователь. Да, но это же лишняя работа, поэтому не надо заново составлять мар­ шрут, если этого не треБУIОТ внесенные изменения .

Программист. М-м-м... Ладно, если вы вводите пункт растаможивания впервые, нам придется послать в таблицу запрос на поиск старого пункта растаможивания, а потом сравнить его с новым. Так мы узнаем, нужно ли все переделывать .

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

Пр огр амми ст. Хорошо ! Не будем!

–  –  –

". .

–  –  –

Пользователь. Итак, если мы меняем пункт растаможивания, то нужно менять весь план перевозки .

Программист. Да. При изменении ЛIобого из атрибутов в Специфи:кации маршра (Route Speci fication) мы удаляем старый Маршр (Route) и просим Маршрутизатор (Routing Service) построить новый маршрут на основе новой Спецификации маршра .

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

в Программист. Разумеется, когда что-либо меняется Спецификации маршрута, Маршрут строится заново. Здесь учитывается и случай ввода информации первый раз .

Польз ователь. Но, конечно, если старый пункт растаможивания оказался правиль­ ным, то всего этого делать не нужно .

Программист. А это не проблема. Легче просто заставить Маршрутизатор строить Маршрут каждый раз заново .

Польз ователь. Да, но это же ЛИIlIНЯЯ работа - составлять все нужные планы для но­ вого Маршрута, поэтому не надо заново строить его, если этого не требуют внесенные изменения .

ГЛАВА 2. КОММУНИКАЦИЯ И ЯЗЫК 49 Программист .

Нужно добавить кое-какие новые функции в Спецификацию Мар ­ шрута, тогда при внесении любых изменений в Спецификацию мы смотрим, соответст­ вует ли все еще Маршрут этой Спецификации. Если не соответствует, то приказываем Маршрутиsатору построить Маршрут заново .

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

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

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

Эти два диалога были специально сконструированы похожими, параллельными .

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

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

Это утверждение может поначалу показаться сомнительным, ведь исключения дейст­ вительно бывают. Но попробуйте вслушаться в дискуссию на совещании по техническо­ му заданию или архитектурному проектированию. Вы услышите требования к програм­ ме на профессиональном жаргоне специалистов или же подражание этому жаргону из уст неспециалистов. Еще вы услышите названия программных объектов и конкретных функций программы. Конечно, встретятся вам и термины из модели предметной облас­ ти, особенно слова повседневного языка, перешедшие из профессионального жаргона в имена объектов и поэтому невольно упомянутые в дискуссии. Но услышите ли вы предложения, которые можно хотя бы приблизительно считать описаниями ОТНОIIlений и взаимодействий в текущей модели предметной области?

Один из лучших способов усовершенствовать модель - обкатывать ее на языке, опи­ сывая вслух разные конструкции из возможных вариантов модели. Шероховатости бу­ дут услышаны сразу же .

Если передать в Маршриэа!1!ОР пункт отправки, пункт назначения, время прибытия, то он найдет HYJICНыe остановки в пути следования груза, а потом, НУ... запишет их в базу данньа. (Расплывчато, с техническими подробностями.) Пункт отправки, пункт назначения и все такое... все это идет в марurpУ!1!И ­ эа!1!ОР, а оттуда получаем марurpУ!1!, в котором записано все, что нужно .

( Уже полнее, но многословно.) МаРUCPУ!1!иэа!1!ОР находит марurpУ!1!, удовлетворяющий Специфижации наРUCPУ!1!а. ( Кратко и точно.)

ЧАСТЬ 1. МОДЕЛЬ ПРЕДМЕТНОЙ ОБЛАСТИ В РАБОТЕ

so Жизненно важно для дела манипулировать словами и фразами, приспосабливая наши языковые способности к нуждам моделирования, точно так же как для рисования диаграмм и схем необходимо включать пространственное и визуальное воображение. В этом ряду можно назвать и аналитические способности, используемые для методичного анализа и проектирования, и загадочное "чувство" кода. Названные способы мышления дополняют друг друга, а для построения полезных моделей и ценных архитектур требуется привлекать сразу все. Из всего перечисленного экспериментирование с разговорным языком наиболее часто упускают из виду. ( В части 111 мы погрузимся в исследовательский процесс и проде­ монстрируем взаимодействие на примере нескольких диалогов.) По-видимому, наш мозг в известной степени приспособлен именно к восприятию сложного разговорного языка. ХОРОIПО об этом для непрофессионалов вроде меня напи­ сал Стивен Пинкер (Steven Pinker) в книге The Lаngиаg-е Instinct [2 1 ]. Например, если люди, происходящие из разных языковых сред, встречаются для ведения торговли, но не понимают языка друг друга, то выдумывают новый, именуемый "пиджин" (pidg-in). Этот пиджин-язык не столь богат и всеобъемлющ, как исходные языки сторон, но свою задачу он выполняет. Когда люди беседуют, они естественным образом открывают для себя различия в интерпретациях и значениях слов и так же естественно их разрешают. Они находят нестыковки в общении и сглаживают их .

Как-то я проходил интенсивный курс испанского языка в колледже. В аудитории царило правило: во время занятий ни слова по-англиЙски. Поначалу это раздражало, казалось неестественным и требовало самодисциплины. Но со временем мы с одно­ группниками сломали языковой барьер и достигли такого уровня владения языком, какого никогда не добились бы на бумаге .

В процессе использования ЕДИНОГО ЯЗЫКА модели предметной области в дискуссиях особенно в тех, в которых разработчики и специалисты "пережевывают" сценарии и требо­ вания - мы осваиваем язык все ЛУЧlпе и обучаем друг друга его нюансам. Естественным образом мы приходим к такому тесному совместному употреблению разговорного языка, какого никогда не бывает в письменной документации и диаграммах .

Внедрить ЕДИНЫЙ ЯЗЫК в проект по разработке ПрОllJаммноm обеспечения - это легче сказать, чем сделать. Для реализации этой цели приходится напрягать все способности. Точно так же, как способность человека к визуальному и пространетвенному мыIлениюю позволяет быстро передавать и обрабатывать информацию, так и его природный талант к употреблению осмысленного языка со своей грамматикой можно задействовать в моделировании .

Итак, в дополнение к характеризации ЕДИНОГО ЯЗЫКА .

Говоря о системе, на с л овах " и rрайте " с моде лью. Описывайте сценарии вс лух с испо льзо ваниемэлементов и взаимосвязей модели, комбинируя понятия такими спо­ собами, какие позволяет моде ль. Ищите бол ее простые спосо бы выразить то, что вы хотите выразить, и привносите найденные новые идеи в диаrраммы и в код .

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

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

ГЛАВА 2. КОММУНИКАЦИЯ И ЯЗЫК

Разумеется, существуют такие чисто технические составляющие архитектуры програм­ мы, которые не должны волновать специалистов в предметной области, но вот смысловое ядро модели должно обязательно их интересовать. Слишком абстрактно? Тогда откуда вам знать, что эти абстракции выбраны разумно? Понимаете ли вы предмет так хорошо, как специалисты? Иногда те или иные технические требования поступают от пользователей более низкого уровня, и для них может потребоваться наличие более конкретной терминологии, но специалист на то и специалист, чтобы иметь углубленное представление о своей области деятельности. Если 'Квалифицированные специалисты в своей области не понимают модель, то с этой моделью что-то не та'К .

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

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

Если специалисты станут использовать этот ЯЗЫК в дискуссиях между собой или с разработчиками, они быстро обнаружат области, в которых модель неадекватна их задачам или вообще неправильна. Специалисты (при помощи программистов) также найдут и такие места, в которых благодаря точности языка, основанного на модели, обнаружатся противоречия или нечеткость в их способе мышления .

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

Специалисты в предметной области могут воспользоваться языком модели для написания сценариев использования7 (иsе cases), а могут работать с моделью и еще более непосредственно, разрабатывая приемочные тесты .

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

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

В ходе этой эволюции должно выполняться и переопределение требований на постоянно совершенствующемся ЕДИНОМ ЯЗЫКЕ .

–  –  –

ЧАСТЬ 1. МОДЕЛЬ ПРЕДМЕТНОЙ ОБЛАСТИ В РАБОТЕ

Необходимость иметь несколько языков в проекте возникает не так уж редко, но из-за этогоне должен возникать языковой барьер между специалистами и разработчиками. (Па­ раллельное существование нескольких моделей в проекте рассматривается в главе 1 2.) Конечно, программисты не обойдутся без применения технической терминологии, непонятной специалистам предметной области. Для обсуждения технических аспектов системы у них есть свой богатый жаргон. Почти наверняка и у пользователей тоже есть специализированный жаргон, далеко выходящий за узкие рамки одной программы и уровня понимания программистов. Но это только дОnОЛ1lе1lUЯ к единому языку. Эти диалекты не должны содержать альтернативные словари для той же области, для которой уже составлены четкие модели .

–  –  –

–  –  –

-

–  –  –

Рис. 2.3. Единый язык рождается "на пересечении " технических жаргонов При наличии ЕДИНОГО ЯЗЫКА дискуссии в среде программистов, обсуждения в среде специалистов и выражения в самом коде будут реализовываться в одной и той же языко­ вой среде, созданной на основе совместно используемой модели предметной области .

Документация, диаграммы, схе мы Ни на одном рабочем совещании, где обсуждается архитектура программного обеспе­ чения, я не могу обойтись без рисования схем на доске или на бумаге. 3начитеЛЬНУIО часть этих схем составляют диаграммы на языке UML - в основном диаграммы классов или взаимодействия объектов .

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

ГЛАВА 2. КОММУНИКА ЦИЯ И ЯЗЫК S3 Простые, неформальные UМ L-диаграммы вполне могут оказаться "объединяющим центром" дискуссии .

Набросайте схему из трех-пяти основных объектов, относящихся к обсуждаемому вопросу, и никто из присутствующих не останется в стороне. Всем будет доступна картина взаимоотношений между объектами и, что важно, имена или названия этих объектов. Устное обсуждение много выиграет от такой поддержки. Диаграмму можно изменять по ходу "мысленных экспериментов" участников, так что графическая схема в какой-то мере даже приобретет динамичность устной речи и займет органичное место в дискуссии. В конце концов, UML ведь означает унифицированный язык модели­ рования ( Unified Modeling Lаng·иаgе) .

Неприятности возникают, когда участники процесса считаIОТ себя обязанными переда­ вать всю модель или архитектуру программы средствами U ML. Если объектных диаграмм слишком много, то одновременно возникает и избыток, и недостаток информации. Избы­ ток - оттого, что все до единого объекты для будущей программы помещаются в модель .

А недостаток - оттого, что из-за обилия деталей за деревьями можно не заметить леса .

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

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

U M L не слишком хорош также и в роли языка программирования. Всякая известная мне попытка воспользоваться средствами генерирования кода, имеющимися в этом ин­ струменте моделирования, оканчивалась плачевно. Если ограничить себя рамками UML, часто приходится опускать самую важную часть модели просто потому, что выражаемое ею правило нельзя описать одними лишь средствами блок-схемы. А генератор кода, ко­ нечно, не может воспользоваться текстовыми аннотациями. Если у вас даже и есть тех­ нология, позволяющая писать выполняемые программы на схематическом языке напо­ добие UML, то диаграмма UML сводится просто к другому способу изображения самой программы, и теряется сам смысл понятия "модель". Если использовать UML в качестве языка непосредственной реализации, то все равно не обойтись без других средств изо­ бражения и обсуждения модели, не "загроможденной подробностями" .

Диаграммы - это средства коммуникации и наглядного объяснения, которые облег­ чают "мозговой штурм" проблемы. Лучше всего они служат этим целям, когда содержат минимум элементов. От обширных схем целой объектной модели нет никакой пользы при обсуждении или объяснениях; они утомляют читателя деталями и лишены ясного смысла. Поэтому мы не будем связываться с полными диаграммами объектных моделей

–  –  –

ЧАСТЬ 1. МОДЕЛЬ ПРЕДМЕТНОЙ ОБЛАСТИ В РАБОТЕ

и даже хранилищами данных U M L. Наш инструмент - упрощенные схемы концепту­ ально важных частей объектной модели, существенных для понимания архитектуры программы. Именно такие схемы и диаграммы, как показано в этой книге, я использую в реальных проектах. Они призваны упрощать и пояснять, и даже содержат кое-какие не­ стандартные обозначения, если это нужно для облегчения пони мания задачи. В них по­ казаны ограничения и связи, но это не детализированные проектные спецификации. Это только идейный костяк проекта .

Все существенные подробности архитектуры nроекта заключены в его исходном коде .

Хорошо написанная программная реализация должна быть "прозрачной" и отражать мо­ дель, лежащую в ее основе. ( Как этого добиться, обсуждается в следующей главе и в зна­ чительной части прочих глав книги.) Вспомогательные диаграммы и документы способ­ ны привлечь внимание людей к проблеме, а дискуссия на естественном языке - рас­ крыть смысловые нюансы. Вот почему я предпочитаю поступать прямо противоположно типичной идеологии UМL-диаграмм. Вместо того чтобы составлять схему, аннотирован­ ную текстовыми пояснениями, я пишу текстовый документ, избирательно иллюстриро­ ванный упрощенными схемами .

Всегда помните, что модель - это не схема. Назначение схемы или диаграммы состо­ ит в том, чтобы помочь в общении и объяснении модели. А вот код способен хранить подробности реализации архитектурного проекта. Хорошо написанный код на Java в своем роде так же выразителен, как диаграмма UML. Тщательно отобранные и постро­ енные схемы помогают сосредоточить внимание и следить за мыслью, если только на­ вязчивая идея автора выразить в них всю целиком модель и архитектуру не лишила их всякой полезности .

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

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

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

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

В экстремальном программировании акцент сделан исключительно на активных эле­ ментах программы и выполняемых тестах. Даже комментарии, добавляемые в код, не влияют на работу программы, так что им никогда не удается "идти в ногу" с активным ко­ дом и стоящей за ним моделью. Внешняя документация и диаграммы не влияют на работу ГЛ АВ А 2. КОММУНИКА ЦИЯ И яз ык программы, так что и они тоже не синхронизированы с кодом. С другой стороны, устные обсуждения и схемы, нарисованные на доске, не фИКСИРУIОТСЯ достаточно надолго, чтобы создать путаницу. Разработчики полагаются на код как на среду коммуникации в проекте, и это побуждает их поддерживать код стилистически чистым и прозрачным по смыслу .

Но у кода, как у вида проектной документации, все-таки есть свои пределы. Его чита­ тель вполне может утонуть в деталях. Работа про граммы однозначна и недвусмысленна, но это не делает ее код очевидным. Да и смысл выполняемой работы не обязательно лег­ ко понятен. Другими словами, документирование только посредством самого кода имеет примерно те же недостатки, что использование всеобъемлющих UМL-диаграмм. Конеч­ но, интенсивные устные дискуссии в пределах группы разработчиков задают контекст и помогают ориентироваться в коде, но все это временно и слишком локально. К тому же разработчики - не единственные люди, которым необходимо понимать модель .

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

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

Докум ентация должна активно работать и не о тставать от nр оцесса .

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

А создавать именно такое ощущение - это правильно, поскольку и сами идеи нашей мо­ дели обладают теми же свойствами .

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

Документ должен активно участвовать в работе nроекта. Самый простой способ проверить это - проследить за взаимосвязью документа и ЕДИНОГО ЯЗЫКА. Написан ли документ на языке, на котором в настоящее время говорят разработчики? Написан ли он на языке, внедренном в код?

Вслушайтесь в ЕДИНЫЙ ЯЗЫК и процесс его изменения. Если термины, определенные в проектном документе, не начинают появляться в дискуссиях и в коде, значит, документ не выполняет своей задачи. Может быть, он слишком обширный или сложный. Может быть, он не сосредоточен на достаточно важной теме. Либо этот документ не читают, ли­ бо не находят убедительным. Если документация никак не влияет на ЕДИНЫЙ ЯЗЫК, зна­ чит, что-то здесь неправильно .

И наоборот, в проекте можно услышать, как видоизменяется естественным образом ЕДИНЫЙ ЯЗЫК, а документация остается "далеко позади". Очевидно, такой документ ли­ бо не кажется разработчикам полезным для дела, либо ему не придают достаточного знаЧАСТЬ 1. МОДЕЛЬ ПРЕДМЕТНОЙ ОБЛАСТИ В РАБОТЕ чения, чтобы вовремя обновлять. Его можно положить в архив для истории, но в актив­ ном состоянии он может вызвать путаницу и навредить проекту. А если документ не иг­ рает реальной роли, то применять дисциплинарные меры, чтобы заставить дорабатывать и обновлять его - это пустая трата сил .

Наличие ЕДИНОГО ЯЗЫКА дает возможность сократить и сделать более строгими дру­ гие документы, такие как технические задания (спецификации требований). По мере то­ го как модель предметной области приходит к отражению наиболее существенных зна­ нии об этой области, технические требования к программе превращаются в сценарии в пределах модели, и описание таких сценариев можно давать на ЕДИНОМ ЯЗЫКЕ в таких терминах, которые непосредственно связаны с ПРОЕКТИРОВАНИЕМ АРХИТЕКТУРЫ ПО МОДЕли9 (см. главу 3). В результате технические задания можно будет писать в более простой форме, поскольку они не обязаны передавать все профессиональные знания, лежащие в основе модели .

Сохраняя в документации лишь минимально необходимое и ставя перед ней задачу дополнения кода и устных дискуссий, можно сохранить тесную связь документации с проектом. Пусть ЕДИНЫЙ ЯЗЫК и его эволюция станут теми факторами, которые помо­ гут отобрать наиболее активные и необходимые для реализации проекта документы .

Выполняемый код решает все Рассмотрим подробнее выбор, сделанный сторонниками "экстремального" програм­ мирования (и не только) - полагаться в работе практически целиком на выполняемый код и его тесты. Значительная часть этой книги посвящена тому, как сделать код передающим смысл посредством ПРОЕКТИРОВАНИЯ ПО МОДЕЛИ (см. главу 3). Хорошо написанный код может быть очень информативным, но сама информация, которую он несет, не обязательно безупречно точна. О, разумеется, работа той или иной части кода не оставляет места для двусмысленностей. Но вот имя метода может быть двусмысленным, дезориентирующим или устаревшим по сравнению с его внутренним устройством. Результаты тестов - вещь строгая и однозначная, но информация, которую можно почерпнуть из имен переменных и организации кода - вовсе нет. Хороший стиль программирования предполагает максимально понятную связь между организацией кода и его работой, но все-таки это требует известной самодисциплины. Нужно быть достаточно привередливым и педантичным, чтобы писать код, который не только делает то, что нужно, но и сообщает в письменном виде то, что нужно .

у странение подобных противоречий - это главный козырь таких методик, как дек­ ларативное программирование (см. главу 1 0), в котором объявление о предназначении того или иного элемента программы определяет его фактическое поведение в ходе рабо­ ты программы. Частично этим стремлением объясняются и попытки генерировать код из диаграмм UML, хотя пока из них ничего хорошего не вышло .

И все же, хотя даже код способен вводить в заблуждение, он намного ближе к греш­ ной земле, чем прочие виды документации. Привести в соответствие фактическое пове­ дение, смысловое содержание и внешнюю форму кода с помощью предписанной в дан­ ный момент стандартной технологии - все это требует дисциплины и определенного взгляда на архитектурное проектирование программы (см. часть III). ДЛЯ успешной пе­ редачи смысла код должен основываться на том же языке, на котором написаны техниче­ ские задания т.е. на том же, на котором между собой общаются разработчики и спе­ циалисты в предметной области .

В оригинале mode/-dn"oen design. - " Примеч. перев .

ГЛАВА 2. КОММУНИКАЦИЯ И ЯЗЫК 57 П ояснитель ные м одели Основной акцент в нашей книге сделан на то, что в основе программной реализации, архитектурного проектирования и взаимодействия в группе разработчиков должна ле­ жать одна и та же модель .

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

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

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

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

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

Пример

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

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

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

–  –  –

*.... .

.

–  –  –

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

ГЛАВА 2. КОММУНИКАЦИЯ И ЯЗЫК

[ЛАБА З

–  –  –

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

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

Когда программисты начали программную реализацию, они обнаружили, что пере­ плетение ассоциативных связей, пусть и более-менее обозримое для аналитика-человека, никак не получается превратить в хранимые и вызываемые модули, которыми можно было бы манипулировать с соблюдением транзакционной целостности. Прошу обратить внимание, что в проекте использовалась объектно-ориентированная база данных, так что разработчикам даже не пришлось решать задачу преобразования ot?ьeKToB в реляцион­ ные таблицы. Но на самом фундаментальном уровне модель была неспособна обеспечить управление программной реализацией .

Поскольку модель была "правильной", Т.е. результатом интенсивного сотрудничества между техническими аналитиками и специалистами в предметной области, разработчи­ ки пришли к выводу, что на основе концептуально проработанных объектов архитектуру приложения спроектировать невозможно, и перешли к несистематической (ad hoc) раз­ работке. Б их архитектуре еще использовались некоторые из ранее принятых имен клас­ сов и атрибутов для целей хранения данных, но программа больше не была основана ни на старой, ни на какой-либо другой модели .

Итак, в проекте модель была, но что толку от ее наличия на бумаге, если она не влия­ ет напрямую на процесс разработки реального кода?

Несколько лет спустя мне довелось наблюдать такой же конечный результат в совер­ шенно ином процессе. Проект состоял в замене существующей программы на языке С++ новой архитектурой, реализованной иа Jаvа. Старое приложение было "склепано" без ка­ кого бы то ни было объектного моделирования. Архитектуру этой старой программы, ес­ ли ее вообще можно так назвать, строили, громоздя одну функциональную возможность на другую без какого-либо заметного глазу обобщения или абстрагирования .

Поразительно, что конечные результаты в обоих случаях были очень похожи по сво­ ему характеру! Обе программы выполняли свои функции, но были неестественно раздуГЛАВА 3. Связь М ЕЖДУ МОДЕЛЬ Ю И Р Е АЛИЗАЦИ Е Й 61 ты, плохо понятны для чтения, и в конечном счете не поддавались дальнейшему разви­ тию и доработке. Хотя программные реализации в отдельных местах демонстрировали некую прямую связь с задачей, назначение системы нельзя было толком выяснить, читая код. Ни в одном из проектов фактически не были использованы преимущества объект­ ной парадигмы (если не считать хитроумных структур данных), предоставляемой имеющимися средствами разработки .

Модели имеют множество разновидностей и могут играть множество ролей даже в ог­ раниченном контексте проекта по разработке программного обеспечения. Предметно­ ориентированное проектирование программ (DDD) требует применения модели, которая не просто помогает в предварительном анализе проблемы, но является прочным фундамен­ том для архитектуры. Такой подход оказывает существенное влияние на структуру полу­ чающегося в итоге кода. Но менее очевидно, что предметно-ориентированное проектирова­ ние требует также и другого подхода к самому моделированию .

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

Ср едневе ковый астрономич е ский калькулятор Астролябию изобрели древнегреческие астрономы и усовеРlпенствовали ученые средне­ векового мусульманского Востока. Вращающаяся решетка (или сетка) представляла по­ ложения неподвижных звезд на небесной сфере. Сменные пластины с выгравированной на них местной сферической системой координат представляли виды неба с различных ного неба в любое время и день года. И наоборот, зная положение звезд или Солнца, мож­ широт. Вращая сетку относительно пластины, можно было вычислить положение звезд­ но было вычислить время. Астролябия была механической реализацией объектпо­ ориентированной модели неба .

–  –  –

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

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

Эта связь может порваться по разным причинам, но довольно часто ее разрывают созна­ тельно. Во многих методологиях проектирования предполагается использование аналити­ ческой модели (analysis model), не имеющей ничего общего с архитектурой программы и разрабатывающейся, как правило, совершенно другими людьми. Ее называют аналитиче­ ской моделью потому, что она является результатом анализа и систематизации прикладной предметной области, безо всякого учета той роли, которую она будет играть в программной системе. Аналитическая модель задумывается исключительно как средство для понимания предметной области; считается, что примешивать к ней вопросы реализации программы это мутить воду и вносить путаницу. Позже разрабатывается программная архитектура, которая может иметь лишь самое отдаленное сходство с аналитической моделью. Аналити­ ческую модель разрабатывают, не учитывая потребностей проектирования приложения, и поэтому она, скорее всего, будет малопригодна для этой цели .

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

Чисто аналитическая модель нередко не решает даже свою основную задачу - помочь в понимании предметной области, потому что ключевые открытия всегда делаются в хо­ де работ по проектированию и реализации приложения. Неизбежно возникают специ­ фические проблемы, которые нельзя было предвидеть заранее. Модель, которую полно­ стью проработали заблаговременно, нередко тонет в несущественных деталях, тогда как важные моменты в ней могут оказаться пропущенными. А кое-что окажется представле­ но таким способом, от которого нет никакой пользы для программной реализации. В ре­ зультате работа над чисто аналитическими моделями прекращается вскоре после начала написания кода, и большую часть вопросов приходится решать заново. Но повторюсь еще раз: если разработчики воспринимают анализ как отдельную процедуру, тогда и мо­ делирование выполняется менее строго. А если руководство воспринимает анализ как отдельную процедуру, то группа разработчиков может не получить нужного ей доступа к специалистам в предметной области .

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

ГЛАВА 3. С вязь М ЕЖД У МОД ЕЛЬ Ю И РЕАЛИЗАЦИЕЙ 63 Если архитектура программы или хотя бы некая ее центральная часть, не соответ ­ ств ует структуре модели предметной области, то такая модель практически бесполез­ на, и правильность работы программы тоже нужно поставить под подозрение .

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

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

ПРОЕКТИРОВАНИЕ ПО МОДЕЛИ предметной области ( MODEL-DRIVEN DESIGN) ликви­ дирует разрыв между аналитической моделью и архитектурой, поскольку в ходе него ищется такая модель, которая бы служила обеим целям. Если не вдаваться в чисто тех­ нические подробности, каждый объект в программной архитектуре играет концептуаль­ ную роль, определенную в модели. Это требует от нас большей придирчивости в выборе модели, поскольку она должна выполнять две совершенно различные задачи .

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

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

ИМ'ператив тесной связи между моделью предметной области и архитектурой порож­ дает дополнительный критерий выбора наиболее полезных моделей из всех возможных .

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

Спроектируйте часть программной системы так, чтобы она отражала модель пред­ метной области самым буквальным образом - соответствие между ними должно быть очевидным. В ернитесь к модели и измените ее так, чтобы она наиболее естественно реализовалась в программе, даже если вы хотите еще и как можно глубже отразить в не й суть предметной области. Доб ивайтесь построения одной модели, хорошо служа­ ще й об еим целям, и к тому же поддерживающей надежный ЕДИНЫЙ ЯЗЫК .

" Выводите " из модеJDI терминологию, используемую в проектировании программы, и примерное распределение обязанностей. Код при таком подходе является выражением модеJDI, так что изменения в коде будут и изменениями модеJDI, а влияние таки х измене­ ний должно расходиться, как круги по воде, по всем видам работ в проекте .

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

Ч АСТЬ 1. МОДЕЛЬ П РЕДМЕТНОЙ ОБЛАСТИ В РАБОТЕ

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

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

Как архитектура, так и сам код имеют те же свойства информативности, что и сама модель .

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

Следует применять такие средства проектирования и реализации, чтобы получающийся код эффективно выражал сущность модели (см. часть 11). Для этого и нужны переработ­ чики знаний (knowledge crunchers), чтобы изучить возможности и варианты моделирова­ ния, а затем "выплавить" из этого "сырья" эффективную программную реализацию. Раз­ работка становится итерационным процессом пошагового усовершенствования модели, архитектуры и кода как единого целого (см. часть 111) .

Пар адигмы м оделиров ания и ср едств а программиро в ания Чтобы ПРОЕКТИРОБАНИЕ ПО МОДЕЛИ имел? смысл, соответствие архитектуры и мо­ дели должно быть буквальным и точным в пределах естественной человеческой погреш­ ности. Для того чтобы столь близкое соответствие стало возможным, приходится факти­ чески ограничивать себя границами той парадигмы моделирования, которую поддержи­ вают имеющиеся средства программирования. Это необходимо для создания прямых программных аналогов объектам и концепциям модели .

Puс. З. 1 .

Объектно-ориентированное программирование является мощным инструментом, по­ скольку основывается на парадигме моделирования и предлагает конкретные реализа­ ции построения моделей. Если же смотреть под тем углом зрения, который интересует программиста, объекты действительно существуют в памяти, связаны с другими объек­ тами, организованы в классы и выполняют операции, обмениваясь данными. Хотя мно­ гие разработчики пользуются лишь техническими возможностями объектов для органи­ зации кода, настоящая сила объектного подхода проявляется тогда, когда код выражает концепции модели. Язык Java и многие другие инструментальные средства программиГЛАВА 3. СВЯЗЬ МЕ ЖДУ МОДЕЛЬ Ю И РЕАЛИЗАЦИЕЙ рования допускают создание объектов и взаимосвязей между ними, имеющих прямые аналогии в концептуальных объектных моделях .

Язык Prolog, пусть и не достигший такой же массовой популярности, как объектно­ ориентированные языки, естественным образом приспособлен к ПРОЕКТИРОВАНИЮ ПО МОДЕЛИ. В его случае парадигмой является логика, а моделью - набор логических пра­ вил и фактов, которыми они оперируют .

Возможности ПРОЕКТИРОВАНИЯ ПО МОДЕЛИ ограничены, если используется такой язык, как С, поскольку не существует парадигмы моделирования, соответствующей чисто процедурному языку. Процедурные языки отличаются тем, что в них программист прика­ зывает компьютеру выполнить последовательность шагов. Хотя программист может при этом держать в уме понятия некоторой предметной области, программа, тем не менее, пред­ ставляет собой последовательность технических операций над данными. В результате мо­ жет получиться нечто полезное, но вот сама суть, смысл в программе практически не отра­ жается. В процедурных языках часто поддерживаются сложные типы данных, которые на­ чинают даже соответствовать естественным понятиям предметной области, но эти типы все-таки не более чем организованные данные, и активные операционные аспекты предмет­ ной области в них не отражены. В итоге программы, написанные на процедурных языках, состоят из функций, соединенных в одно целое на основе предполагаемых цепочек выпол­ нения операций, а не концептуальных связей в модели предметной области .

Прежде чем вообще узнать о существовании объектно-ориентированного программи­ рования, я писал реализации математических моделей на языке FORTRAN именно в этой области данный язык превосходно зарекомендовал себя. Математические функции являются главными концептуальными компонентами таких моделей, и они вполне четко выражаются средствами этого языка. Однако в нем не существует средств для выражения смысла более высокого уровня, стоящего за такими функциями. Большинство предметных областей, не относящихея к области математики, не поддается ПРОЕКТИРОВАНИЮ ПО МОДЕЛИ на процедурных языках, потому что эти области нельзя свести ни к совокупности математических функций, ни к последовательности шагов процедуры .

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

Пример

От процедурного подхода к модельно - ориентированному Как рассказывалось в главе 1, электронную печатную плату (ПП) можно представить в виде совокупности электрических проводников (цепей, nets), соединяющих выводы или контакты (pins) различных компонентов. Нередко количество таких цепей достигает десят­ ков тысяч. Специальные программы автоматической трассировки печатных плат находят способ физического размещения всех цепей, чтобы они не пересекались друг с другом и не мешали работе друг друга. Выполняется оптимизация дорожек на плате с одновременным удовлетворением огромного количества условий, наложенных проектировщиками и огра­ ничивающих способы расположения цепей. Хотя программы автотрассировки ПП реали­ зуют весьма сложные алгоритмы, у них все-таки есть недостатки .

Одна из проблем состоит в том, что у каждой из тысяч цепей имеется собственный набор правил трассировки. Инженеры-схемотехники группируют многие цепи по есте­ ственному критерию удовлетворения одних и тех же правил. Например, некоторые цепи в совокупности образуют шины (Ьиsеs) .

–  –  –

Группируя цепи в шины, например, по 8, 16 или 256 штук, инженер уменьшает объем работы до более обозримого, повышая производительность труда и снижая вероятность ошибки. Но беда в том, что в программе трассировки нет такого понятия, как шина. Пра­ вила приходится ассоциировать поочередно с каждой из десятков тысяч цепей .

Механистический ПОДХОД Инженеры-схемотехники, которых такое положение не устраивает, пытаются обойти это ограничение в программе автотрассировки. Для этого они разрабатывают сценарии, анализирующие файлы данных автотрассировщика и вставляющие правила непосредст­ венно в файл, что позволяет применять их сразу к целой шине .

Автотрассировщик хранит все электрические соединения в файле списка цепей, кото­ рый выглядит примерно так .

цепь Комп о н е н т. Выв од

–  –  –

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

ГЛАВА 3. С вязь МЕЖДУ МОДЕЛ ЬЮ И РЕАЛ ИЗАЦИЕЙ

1. Отсортировать файл списка цепей по именам цепей .

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

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

4. Добавить имя цепи с текстом правила в конец файла правил .

5. Повторить, начиная с п. 3, пока левая часть строки не перестанет соответствовать имени IПИНЫ .

Пусть на вход поступает следующее правило для шины .

П а р ам е тры П р а в ил о Шин а

–  –  –

Могу себе представить, что перед автором первоначального сценария стояла только эта несложная задача, и если бы это требование так и осталось единственным, то от этого сценария было бы много пользы. Но на практике теперь ИСПОЛЬЗУIОТСЯ десятки сценари­ ев. Их, конечно, можно подвергнуть рефакторингу хотя бы для совместного использова­ ния функций сортировки и сравнения строк. А если бы в языке сценариев еще и поддер­ живались функциональные вызовы, в которые можно было бы "спрятать" детали реали­ зации, то сценарии уже читались бы практически как приведенная выше процедура. Но все равно еще остаются манипуляции с файлами. Стоит изменить формат файла (а их существует несколько), и потребуется писать все заново, пусть даже концепции группи­ ровки шин и применения правил к ним останутся неизменными. Если бы понадобились более обширные функциональные возможности или ЛУЧПIая интерактивность, их реали­ зация потребовала бы непомерных трудозатрат .

Авторы выполняемых сценариев пытались дополнить модель предметной области понятием "шины". В их реализации неявно предполагается существование такого поня­ тия, для чего и выполняются сортировка и сравнение строк. Однако в явном виде это по­ нятие не фигурирует .

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

Если эти объекты определить на каком-нибудь объектно-ориентированном языке, то основные функции программы становятся практически тривиальными в реализации .

–  –  –

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

Для приложения понадобится реализация системы импортирования-экспортирования, которую мы инкапсулируем в нескольких простых службах .

1 В переводе сохранены и ор игинальные названия (потому что от них происходят имена клас­ СОВ) и их пер еводы на ру сский язык (потому что они должны естественно вписываться в словесное описание модели). Все это совершенно в духе пр едлагаемого в книге подхода "единого языка" .

Правда, в скобках оказывается то одно, то другое в зависимости от близости предложения либо к естественном у языку, либо к техническом у оп ределению. - Прu.меч. перев .

–  –  –

a s s e rtTrue ( a O. a s s i gnedRu l e s ( ). c ont ains ( rninWi dth4 ) ) ;

a s s e rt Equa l s ( rninWidth4, a O. getRul e ( MIN_WIDTH ) ) ;

a s s e r t Equa l s ( rninW i dth4, a l. ge t Rul e ( MIN_WIDTH ) ) ;

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

–  –  –

Здесь служба запрашивает у каждой Цепи (Net) назначенные ей правила (assignedRules ( ) ) и записывает их в полностью развернутом виде .

Конечно, если бы требовалось выполнять только одну операцию (как в примере), то и сценария было бы достаточно. Но на самом деле необходимо реализовать более двадца­ ти операций. При ПРОЕКТИРОВАНИИ ПО МОДЕЛИ масштабирование выполняется легко и позволяет также вводить ограничения на комбинирование правил .

Во второй архитектуре также учитывается тестирование. У ее компонентов имеются хорошо определенные интерфейсы, которые можно подвергать модульному тестирова­ нию (unit testing). Единственный же способ протестировать сценарий - это прогнать че­ рез него тестовый файл с заранее известным выходным результатом .

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

Анатомия м одели : заче м модель нужна пользователю Теоретически пользователю можно предъявить любую наглядную модель системы, не заботясь о том, что на самом деле находится в глубине. Но на практике несоответствие представления и сути вызывает в лучшем случае путаницу, а в худшем - реальные ошибки. Рассмотрим очень простой пример того, как пользователей вводят в заблужде­ ние поверхностные теоретические модели: закладки веб-сайтов в современных версиях браузера Мiсrоsоft Internet Explorer2 .

Пользователь Internet Explorer считает "Избранное" ("Favorites") списком имен веб­ сайтов, который сохраняется между сеансами работы. Но в программной реализации за­ кладка из "Избранного" является файлом, содержащим URL-адрес. Имя этого файла по­ мещается в папку с именем Favo r i t e s (ИЗбра н н о е ). Вот тут-то и возникает проблема, если заголовок веб-страницы содержит символы, недопустимые в именах файлов систе­ мы Windows. Предположим, пользователь хочет сохранить закладку и вводит для нее следующее имя: " Л е н ь : с е кре т сч а с т ь я ". Появится сообщение об ошибке: "Имя файла не может содержать следующие символы: \ / : * ? 1 ". Какое еще имя файла?

Причем тут имя файла? С другой стороны, если заголовок веб-страницы уже содержит недопустимые символы, то Internet Explorer просто уберет их оттуда, вот и все. Такая по­ теря данных в этом случае вполне терпима, но это не совсем то, чего хотел пользователь .

Автоматическое изменение данных "исподтишка" совершенно недопустимо в большин­ стве программ .

ПРОЕКТИРОВАНИЕ ПО МОДЕЛИ требует работы только с одной моделью (внутри од­ ного контекста, см. главу 14). Большая часть изложенной теории и примеров относится к проблемам, связанным с наличием различных моделей для анализа предметной области 2 Об этом при мере сообщил мне Брайан Марик (Brian Marick) .

ГЛАВА 3. С ВЯЗЬ МЕЖДУ М ОДЕЛЬ Ю И РЕАЛИ ЗАЦИЕЙ

и для проектирования архитектуры. А здесь у нас проблема возникла из-за наличия дру­ гой пары разных моделей: модели представлений пользователя и модели для проектиро­ вания/реализации программы .

Конечно, голая модель предметной области в большинстве случаев удобной для поль­ зователя не будет. Но попытка создания в пользовательском интерфейсе некоей иллю­ зорной модели, отличаIОlцейся от модели предметной области, приведет к путанице ­ если только иллюзия не доведена до совершенства. Если список закладок веб-сайтов на самом деле представляет собой совокупность файлов с адресами, надо сообlЦИТЬ об этом факте пользоватеЛIО и "убрать с глаз долой" альтернативную модель, которая только ме­ шает. Это не только сделает даННУIО функцию программы более IIОНЯТНОЙ, но еще и даст пользоватеЛIО возможность применить свои знания файловой системы при манипуляци­ ях с " Избранным". I-Iапример, пользователь сможет реорганизовать закладки через фай­ ловый менеджер, а не через неУКЛIожие встроенные средства браузера. Хорошо инфор­ мированные пользователи смогут активнее использовать TaKYIo гиБКУIО возможность программы, как расположение файлов веб-ссылок в ЛIобом месте файловой системы .

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

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

Если архитектура программы проектируется на основе модели, отражающей основные потребности и проблемы как пользователей, так и специалистов в предметной области, то ее "анатомию" можно смело показывать пользоватеЛIО в гораздо большей степени, чем в других методологиях программирования. Показ "изнанки" модели дает пользователю возможность лучше понять потенциал программы, ведет к более единообразному и управ­ ляемому ее использоваНИIО .

одеЛИРОВIЦики -практики Разработку программного обеспечения принято метафорически сравнивать с процес­ сом фабричного производства. В этой метафоре скрыта одна неявная посылка: высоко­ квалифицированные инженеры проектируют и конструируют, а менее квалифицирован­ ные рабочие собираIОТ ПрОДУКЦИIО. Эта метафора загубила множество программных про­ ектов по одной простой причине: разработка программ целиком состоит из проектиро­ вания/конструирования. Во всех группах разработчиков есть распределение по специа­ лизированным ролям, но слишком резкое разделение ответственности за анализ, моде­ лирование, проектирование и программирование вступает в противоречие с принципом

ПРОЕКТИРОВАНИЯ ПО МОДЕЛИ (MODEL- DRIVEN DESIGN) .

В одном из проектов мои обязанности состояли в координировании нескольких рабо­ чих групп и помощи им в разработке модели предметной области, которая бы лежала в основе проектирования архитектуры. Но руководство реIПИЛО, что те, кто моделирует, должны только моделировать, и что заставить их программировать означает ПУСТУIО тра­ ту сил. В итоге мне фактически запретили писать код или прорабатывать детали вместе с программистами .

ЧАСТЬ 1. МОДЕЛЬ IIРЕДМЕТНОЙ ОБЛАСТИ В РАБОТЕ

Некоторое время все llIЛО как будто нормально. Работая со специалистами и руково­ дителями разных групп разработчиков, мы осуществили переработку знаний и вырабо­ тали неплохую предмеТНУIО модель. Но она так и не заработала по двум причинам .

Во-первых, часть достоинств модели потерялась из-за эффекта "испорченного теле­ фона". ОБIЦая эффективность модели сильно зависит от деталей (эта тема будет рас­ смотрена в частях 11 и 111), и эти детали не всегда легко уловить в UМL-диаграммах или общей дискуссии. Если бы я мог, закатав рукава, трудиться непосредственно рядом с программистами, писать кое-какой код в качестве примеров и обеспечивать прямую под­ держку на месте, то группа разработчиков овладела бы абстракциями модели и следова­ ла бы им в программной реализации .

Во-вторых, имела место лишь косвенная обратная связь от взаимодействия модели с нрограммной реализацией и технологиями программирования. Например, некоторые ас­ пекты модели оказались совершенно неэффективными на нашей технологической плат­ форме, но полная информация о последствиях этого "просочилась" ко мне только через многие месяцы. Вначале проблему могли бы решить сравнительно небольшие изменения, но к тому времени это было уже неважно. Программисты уже изрядно продвинулись в на­ писании программы, которая бы просто работала, - притом безо всякой модели. Вернее, там, где эта модель вообще использовалась, она свелась просто к структуре данных. Про­ граммисты выплеснули с водой ребенка, но что еще им было делать? Они не могли дальше рисковать, подставляя шею под ярмо мудрствующего архитектора-теоретика .

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

Если сотрудники, пи шущие код, не чувствуют своей ответственности за модель или не понимают, зачем она нужна при написании программы, то модель не имеет никакого отношения к проrpамме. Если программисты не понимают, что изменение кода должно приводить к изменению модели, то их рефакторинг будет ухудшать модель, а не улуч ­ шать ее. Помимо этого, если моделировщик отстранен от процесса программной реа­ лизации, то он не приобретает или быстро теряет интуитивное понимание требований и о собенностей реализации. О сновное требование ПРОЕКТИРОВАНИЯ ПО МОДЕЛИ по­ мощь со стороны модели в эффективной проrpаммной реализации и абстрагирование ею ключевых знаний предметной области - выполняется лишь частично, и в итоге мо­ дель теряет практическую ценность. В конце концов знания и навыки опытных проек­ тир овщиков перестают передаваться другим разработчикам, если разделение труда мешает тому виду сотрудничества, который сохраняет особенности проrpаммирования на основе ПРОЕКТИРОВАНИЯ ПО МОДЕЛИ .

Потребность в модеЛИРОВIциках-практиках не означает отсутствия специализации в группе разработчиков. Во всякой методологии гибкой разработки программ (agile­ методологии), в том числе и в экстремальном программировании, между членами груп­ пы распределяются роли, и естественным образом возникают неформальные специали­ зации. Проблема возникает тогда, когда раздеЛЯIОТСЯ две задачи, которые согласно прин­ ципу ПРОЕКТИРОВАI--I ИЯ ПО МОДЕЛИ должны "идти в связке" - моделирование и про­ граммная реализация .

Эффективность всего процесса проектирования сильно зависит от качества и согла­ сованности множества мелких проектных и технических решений. В ПРОЕКТИРОВАНИИ

ГЛАВА 3. СВЯЗЬ МЕ ЖД У МОДЕЛЬ Ю И РЕАЛ И ЗА ЦИ ЕЙ 73

ПО МОДЕЛИ фрагмент кода есть выражение модели; если меняется код - надо менять модель. Программисты являются одновременно и моделировщиками, нравится это кому­ то или нет. Поэтому лучше организовать проект так, чтобы программисты имели воз­ можность заниматься моделированием .

Технический сотрудник, делаюЩИЙ свой вклад в модель, должен некоторое время работать над кодом, какую бы главенствующую роль он не играл в проекте. Любой, кому позволено вносить изменения в код, должен научиться выражать модель в этом коде. Каждый разработчик должен участвовать на каком-то уровне в дискуссиях о модели и иметь контакты со специалистами в предметной области. Те, кто работает над проектом в любом другом качестве, должны сознательно привлекать программистов, напрямую работающих с кодом, к динамичному обмену идеями модели посредством ЕДИНОГО ЯЗЫКА .

*** Резкое разграничение моделирования и программирования неэффективно, однако в больших проектах не обойтись без технических руководителей, которые бы координи­ ровали проектирование и моделирование высокого уровня, помогая в выработке наибо­ лее трудных, критических решений. В части IV, "Стратегическое проектирование", рас­ сматриваются такие решения и поощряется выработка идей насчет наиболее продуктив­ ных способов распределения ролей и ответственности в верхнем эшелоне технических сотрудников программных проектов .

Предметно-ориентированное проектирование (DDD) ставит своей задачей применение модели для решения задач, стоящих перед приложением. Посредством переработки знаний группа разработчиков фильтрует (дuстwmирует) поток хаотической информации и делает из него работоспособную модель. ПРОЕКТИРОВАНИЕ ПО МОДЕЛИ (MODEL-DRIVEN DESIGN) создает тесную связь между моделью и реализацией. А ЕДИНЫЙ ЯЗЫК является каналом, по которому вся нужная информация расходится между программистами, специалистами в предметной области и непосредственно программным продуктом .

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

Как уже говорилось, успех ПРОЕКТИРОВАНИЯ ПО МОДЕЛИ зависит от многочислен­ ных деталей проектных решений, о чем и пойдет речь в нескольких слеДУЮIЦИХ главах .

Ч АСТЬ 1. М ОДЕЛЬ ПРЕДМЕТНО Й ОБЛАСТИ В РАБОТЕ

Структурные элементы предметно- ориентированного проектирования Чтобы реализация программной системы велась четко и шла "в ногу" с моделью, несмотря на суровую хаотическую реальность, необходимо применять наиболее надежные и проверенные методы моделирования и проектирования. Эта книга не представляет собой введение в объектно-ориентированное проектирование программ, не предлагает она и ка­ кой-то радикальной теории. В предметно-ориентированном nрое'Ктировании (domain-driven design) просто смещаются акценты некоторых общепринятых идей .

Чтобы модель и ее реализация не отставали одна от другой, усиливая эффективность друг друга, необходимо принимать определенные виды решений. Синхронизация модели и про­ граммной реализации требует внимания к деталям отдельных структурных элементов про­ граммы. Тщательность проработки в мелком масштабе дает разработчикам тверДУIО основу, на которой можно применять стратегии и приемы моделирования из частей 111 и IV .

Стиль архитектурного проектирования программ в этой книге во многом следует принципу "проектирование по ответственности" (responsibility-driven design), выдвину­ том в [24] и доработанном в [25]. Очень сильное влияние, особенно в части 111, оказали также идеи "контрактного проектирования" (design Ьу contract), изложенные в [ 1 9 ]. Все это согласуется с общими принципами других распространенных методологий объектно­ ориентированного проектирования, описанными в таких книгах, как [ 1 7] .

Если проект сталкивается с какими-либо препятствиями, большими или малыми, программистам начинает казаться, что упомянутые принципы неприменимы в тех или иных ситуациях. Чтобы сделать процесс предметно-ориентированного проектирования достаточно гибким, разработчикам необходимо понять, 'Как именно общеизвестные фун­ даментальные принципы реализуются в ПРОЕКТИРОВАНИИ ПО МОДЕЛИ (MODEL-DRIVEN DESIGN) - тогда можно будет идти на компромисс, не отходя от основ .

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

Схема, приведенная далее, - это карта-путеводитель. Она демонстрирует шаблоны­ образцы, которые будут представлены в этом разделе, и некоторые разновидности взаи­ мосвязей между ними .

–  –  –

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

Следование проверенным образцам для отдельных элементов помогает создать модель, удоБНУJО для реализации на практике .

Модели оБIНИРНЫХ предметных областей способны не утонуть в сложности только n том случае, если уделяется должное внимание самим основам - Т.е. если детально про­ рабатываются элементы, которые группа разработчиков сможет затем уверенно объеди­ нить в одно целое .

–  –  –

Т а часть программы, которая собственно и решает задачи из предметной облас­ ти, - это, как правило, лишь небольшой фрагмент всей программной системы, хотя его значение далеко превосходит размеры. Чтобы применить наиболее эффектив­ ные подходы, необходимо посмотреть на элементы модели как на систему. Не следует поддаваться тенденции просто выдергивать их из значительно большей совокупности объектов, наподобие выделения созвездий на ночном небе. I-Iеобходимо отграничить объекты предметной области от остальных функций системы и тем самым избежать пу­ таницы между понятиям и этой области и программными технологиями, а то и опасности вовсе потерять видение предмета в общей массе системы .

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

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

–  –  –

Для реализации в программе обслуживания грузоперевозок простого действия поль­ зователя - выбора места назначения груза из списка городов - необходим программный КОД, который бы ( 1 ) выводил на экран некий интерфейс для диалога с пользователем, (2) запрашивал в базе данных список городов, (3) интерпретировал и проверял инфор­ мацию, введенную пользователем, (4) ассоциировал выбранный город с грузом и (5) от­ ражал сделанное изменение в базе данных. Весь этот код принадлежит одной программе, но к собственно грузоперевозкам относится лишь небольшая часть его .

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

В объект но-ориентированной программе код для реализации и нтерфейса пользова­ теля, обраще ни й к базе данных и других техниче ских задач нередко вписывают на­ прямую в объекты прикладной модели (business ob jects). Кроме того, часть приклад­ но й логики (business logic), т. е. алгоритмиче ско й части программы, часто реализуется прямо в элементах интерфейса пользователя и сце нариях баз данных. Это происходит потому, что так легче всего работать на бли жнюю перспективу .

Когда код, относящийся к операциям предметн ой области, размазан по огром ным объ емам другого кода, его становится оче нь трудно разыскивать и анализи ровать. По ­ верхнос тные изменен ия в и нтерф ейс е пользователя могут случайно затронуть и опе­ раци и алгоритмической части. А чтобы изменить какие -либо правила делового регла ­ ме нта (business rnles), потре буетс я тщательная трассировка кода интерфейса, обра­ щен и й к баз е данных и других элеме нтов программы. Реали зация л огичес ки последовательных, основанных на модели объектов становится непрактичноЙ. Автома­ тизированное те стирование оказывается неудобным. Учитьmая объем технологий и опе ­ раций в каждом из этих видов работ, программу следует " удерживать " в максимально упроще нном виде, иначе понять ее станет невозможно .

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

Существует много способов членения программной системы, но по накопленному в программной индустрии опыту и неписаным соглашениям преимущество отдается МНОГОУРОВНЕВОЙ АРХИТЕКТУРЕ ( LAYERED ARCHITECTURE), состоящей из нескольких достаточно стандартных уровней. Метафора многоуровневости настолько широко распространена, что большинство программистов воспринимают ее естественно, ин­ туитивно. В литературе о многоуровневой архитектуре написано достаточно много и хорошо, иногда даже в формате шаблона ( например, [ 7 ] ). ВажнеЙПIИЙ принцип много­ уровневости состоит в том, что ЛIобой элемент какого-нибудь уровня зависит от рабо­ ты только других элементов того же уровня или элементов более низких уровней. Пе­ редача информации наверх должна выполняться косвенными способами, о чем еще будет говориться .

Ценность многоуровневости состоит в том, что каждый уровень специализируется на конкретном аспекте программы. Такая специализация позволяет выполнять более связ­ ное проектирование каждого аспекта, и получаЮIЦУIОСЯ архитектуру намного легче ин­ терпретировать. Конечно, жизненно важно выбирать уровни так, чтобы в них изолиро­ вались наиболее важные аспекты связной архитектуры. Здесь опыт также привел к опре­ деленным соглашениям в отрасли. В наиболее успешных архитектурах используются, в том или ином виде, следующие четыре концептуальных уровня (со многими возмож­ ными вариациями) .

–  –  –

Б некоторых проектах не делают четкого разграничения между уровнями пользова­ тельского интерфейса и прикладных операций. В других есть несколько инфраструктур­ ных уровней. НО ПРОЕКТИРОВАНИ Е ПО МОДЕЛИ ( MODEL-DRIVEN DESIGN) становится возможным только в том случае, если четко отделен уровень предметной области .

Р азбейте сложную программу на уровни. Внутри каждого уровня разработайте связную структуру, полагающуюся только на нижние уровни и зависящую только от них. Чтобы о бе спечить связь с в е рхни ми уровнями, использу йте стандартные архи­ тектурные ша блоны. Сосредоточьте весь код, относящийся к предметной модели, в одно м уровн е, и изолируйте его от кода ин тер фей са пользователя, прикладных опера­ ций и инфраструктуры. Объе кты пр едметной области, из бавле нные от необходимости выводить самих себ я на экран, хранить в базах данных, распр еделять задачи и т.п., мо жно соср е доточить на выраж е нии модели этой области. Это позволяет модели разГЛ АВА 4. Изоляция ПРЕДМЕТНОЙ ОБЛАСТИ виться до достаточно сложной и в т о же время достато чно понятной, что бы заключить в се бе существе нные з н ан и я о предмете и э ффективно их применить .

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

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

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

Пример

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

Чтобы не перегружать этот пример, я опустил все основные технические подробно­ сти, в частности вопросы безопасности. Структура предметной области тоже изрядно упроrдена. (В условиях реальной сложности потребность в многоуровневой архитектуре только возросла бы.) Более того, и подразумеваемая в примере инфраструктура специ­ ально задумана как простая и ясная, чтобы не усложнять пример, - в действительности для такой программы требуется совершенно другая структура. Обязанности же остав­ шихся частей программы будут распределены по уровням, как показано на рис. 4. 1 .

Обратите внимание, что за реализацию деловых регламентов (business rules) отвечает не уровень прикладных операций (application), а уровень предметной области (domain) .

В данном случае правило регламента выражается так: "Для всякого кредита найдется со­ ответствующий дебет" .

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

Фактически рис. 4. 1 в какой-то мере иллюстрирует проблемы, которые возникают из-за 1lеuзолuрова1l1l0сmu предметной области. Так как на рисунке нужно было пока­ зать все операции от запроса до управления транзакцией, уровень предметной области пришлось упростить, чтобы вся работа системы в целом осталась обозримой. А вот ес­ ли сосредоточиться на проектировании только изолированного предметного уровня, то и на странице, и в головах у нас хватило бы места для модели, которая лучше пред­ ставляет логику модели - даже содержит объекты главной книги, дебета и кредита, валютных транзакций .

–  –  –

( 1( 1

–  –  –

Рис. 4. 1. Объекты наделены обязанностями, соответствующими их уровню, и связаны С дРУlими объектами CBoelO уровня Связь между уровнями До сих пор речь у нас шла о разделении уровней и усовершенствовании архитектуры частей и аспектов программы, в частности уровня предметной области (domain всех layer), благодаря этому разделению. Но, разумеется, между уровнями должна также су­ ществовать связь. Как установить такую связь и не потерять преимуществ разделения этой проблемой задавались создатели многочисленных архитектурных шаблонов .

Уровни должны быть связаны нежестко, и зависимость проектирования одного уровня от другого должна быть направлена только в одну сторону. Верхние уровни могут использовать элементы нижних или манипулировать ими напрямую: путем вы­ зова их общедоступных (public) интерфейсов, хранения ссылок на них (хотя бы вре­ менного) или каким-нибудь другим обычным для программ способом. Но если объек­ ту нижнего уровня требуется связь с верхним (причем связь, не вписывающаяся в рамки простого ответа на прямой запрос ), то для этого нужен другой механизм, ос­ нованный на таких архитектурных шаблонах взаимодействующих слоев, как уведомле­ ние (callback) или НАБЛЮДАТЕЛЬ (OBSERVER) [ 1 4 ] .

"Дедушка всех шаблонов", связывающих интерфейс пользователя с уровнями при­ кладных операций и предметной области, - это моделъ-nредсmавленuе-конmРОJUlер (model-view-controller, MVC). Его впервые ввели в мире Smalltalk еще в 1970-е, и с тех пор на его основе было создано множество архитектур интерфейсов. В [ 1 3] рассматривается этот шаблон и несколько полезных вариаций на тему. В [ 1 7 ] эти проблемы нашли осве­

щение в ШАБЛОНЕ РАЗДЕЛЕНИЯ МОДЕЛИ И ПРЕДСТАВЛЕНИЯ (MODEL-VIEW SEPARATION

PATTERN); там же предлагается один из вариантов связи с операционным уровнем,

КООРД ИНАТОР ПРИКЛАдНЫХ ОПЕРАЦИЙ (APPLICATION COORDINATOR) .

ГЛАВА 4. Из оляция ПРЕДМЕТ НО Й ОБЛАСТИ Суrцсствуют и другие способы организации связи между интерфейсом и операцион­ ным уровнем. Для наших целей подходят все эти способы, если они обеспечиваIОТ изоля­ цию предметной области и позволяют проектировать ее объекты, не думая о пользова­ тельском интерфейсе и его возможных обраrцениях к этим объектам .

Инфраструктурный уровень обычно не инициирует никаких операций на уровне пред­ метной области. Находясь "ниже" предметной области, он не обязан знать ничего конкрет­ ного об объектах, которые он обслуживает. Такие технические возможности чаще всего предоставляются в виде СЛУЖБ (SERVICES). Например, если приложению нужно послать письмо по электронной почте, то на инфраструктурном уровне найдется для этих целей не­ кий почтовый интерфейс, а элементы операционного уровня смогут запросить передачу со­ обlцения. Такое разграничение дает дополнительную гибкость. почтовыIй интерфейс может подключаться к модулю отправки электронной почты, модулю отправки факсов или ЛIО­ бому другому аналогичному средству. Но главное преимуrцество заключается в упрощении операционного уровня, сосредоточении его на выполнении узкого круга обязанностей: он знает, когда послать сообrцение, но ему не нужно знать, как это сделать .

Итак, уровни прикладных операций (application) и предметной области (domain ) об­ ращаются к СЛУЖБАМ (SERVICES), предоставляемым инфраструктурным (infrastructure) уровнем. Если область действия СЛУЖБЫ выбрана удачно, а ее интерфейс хоропrо спро­ ектирован, то вызывающая сторона привязана к ней очень слабо и не подвержена влия­ нию той сложной функциональности, которая может стоять за интерфейсом СЛ УЖБЫ .

НО не вся инфраструктура сводится к СЛ УЖБАМ, вызываемым с верхних уровней .

Некоторые технические компоненты проектируются так, чтобы напрямую поддерживать функционирование других уровней (например, предоставлять абстрактный базовый класс для всех объектов предметной области) и механизм, через которьrй они взаимодей­ ствуют (например, реализации МУС и т.п.). Такая архитектурная среда (archi{ectura!

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

Архитектурные среды Если инфраструктура реализована в форме СЛУЖБ (SERVICES), вызываемых через интерфейсы, то многоуровневость и разделение уровней достигается вполне естественно, без принципиальных затруднений. Но некоторые технические проблемы треБУIОТ более "навязчивых" форм инфраструктуры. В подобных инфраструктурных средах Urameworks) реализуются в интегрированной форме НУ)JПI ые функции инфраструктуры, и одновременно эти среды навязывают другим уровням определенные способы реализа­ ции например, в виде подклассов одного из классов средь] или с заранее заданными сигнатурами методов. (Может показаться неестественным, что подкласс находится на уровне выше, чем родительский класс, но следует учесть, в каком из классов содержится больше знания о другом.) Лучшие архитектурные среды решаIОТ сложные технические задачи и при этом позволяют разработчику уровня предметной области сосредоточиться на выражении модели. Но среды могут и помеlпать работе: либо накладывая слишком много ограничений, сужающих выбор проектных решений в предметной области, либо делая реализацию столь тяжеловесной, что это тормозит разработчиков .

Обычно для работы требуется архитектурная среда в каком-то виде (кстати, группа разработчиков вполне может выбрать и такую среду, которая сослужит ей ПЛОХУIО служ­ бу). Используя среду, разработчики не должны забывать о своей цели: строить про­ граммную реализацию, выражающую модель предметной области, и реlпать с ее помо­ IЦЬЮ ваЖНУIО прикладную задачу. Группа должна применять среду в той мере, в какой ЧАСТЬ 1 1. СТРУКТУРН ЫЕ ЭЛЕМЕНТЫ ПРЕДМЕТНО-ОРИЕНТИРОВАННОГО.. .

решается главная задача, пусть при этом задействуются и не все имеющиеся возможно­ сти. Например, в ранних приложениях на основе J2EE все объекты предметной области часто реализовывались в виде хранимых объектов Entity Beans. Эта методика снижала как быстродействие, так и темпы разработки. В настоящее время хорошим стилем счита­ ется использовать среду J2EE дЛЯ более крупномасштабных объектов, реализуя боль­ ШУIО часть прикладной модели в виде оригинальных объектов Java. Большинства недос­ татков архитектурных сред удается избежать, если применять их избирательно для пре­ одоления трудных мест, а не искать одно общее готовое решение. Скрупулезный отбор только наиболее ценных в каждом случае функций среды снижает зависимость про­ граммной реализации от этой среды, давая большую гибкость в выборе будущих проект­ ных решений. Что еще важнее, учитывая высокую сложность работы со многими совре­ менными средами, такой минимализм помогает сохранять объекты прикладной модели выразительными и доступными для чтения .

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

Уровень пр едметной обла сти - вместилищ е модели МНОГОУРОВНЕВАЯ АРХИТЕКТУРА (LAYERED ARCHITECTURE) используется сейчас в большинстве систем с различными вариациями на тему многоуровневости. Во многих стилях программирования также в той или иной мере пользуются разделением на уров­ ни. А вот в предметно-ориентированном проектировании программ требуется обяза­ тельное наличие только одного конкретного уровня .

Модель предметной области (domain model) - это набор понятий (концепций). Уро­ вень предметной области (domain layer) - это выражение данной модели и все элементы программной архитектуры, непосредственно имеющие к ней отношение. Уровень пред­ метной области образуется путем проектирования и реализации всей совокупности по­ нятий И связей в предметной области (business logic). В ПРОЕКТИРОВАНИИ ПО МОДЕЛИ (MODEL-DRIVEN DESIGN) программные конструкции уровня предметной области непо­ средственно отражают концепции модели .

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

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

ГЛАВА 4. Изоляц ия ПРЕДМЕТНОЙ ОБЛАСТИ 85 Во многих программных проектах принимается и должен приниматься в дальнейшем намного менее структурированный подход к проектированию, который я называю ИНТЕЛЛЕКТУАЛЬНЫЙ ИНТЕРФЕЙС ПОЛЬЗОВАТЕЛЯ (SMART UI) .

Это подход, альтерна­ тивный предметно-ориентированному проектированию (DDD) и категорически с ним несовместимыЙ. Если принимается именно он, большую часть написанного в этой книге можно выбросить. Меня интересуют ситуации, в которых ИНТЕЛЛЕКТУАЛЬНЫЙ ИНТЕРФЕЙС ПОЛЬЗОВАТЕЛЯ (SMART UI) неприменим, поэтому я иронично называю его "антишаблоном". Но обсуждение этого подхода создает полезный контраст и помогает прояснить, как и почему выбирается более трудный путь, которому посвящена вся ос­ тальная часть книги .

*** Пусть в программном проекте должны быть реализованы простые функции, сводя­ щиеся в основном к вводу и отображению данных, практически без сложной прикладной логики. В состав группы разработчиков не входят высококвалифицированные модели­ РОВIЦИКИ объектов .

Если низкоквали фицированная группа разработчиков, работая над простым проек­ том, решает применить ПРОЕКТИРОВАНИЕ ПО МОДЕЛИ ( MODEL-DRIVEN DESIGN) с М НОГОУРОВНЕВОЙ АРХИТЕКТУРОЙ, то е й предстоит трудный процесс обучения. Разра ­ ботчикам придется осваивать новые сложные технологии, на каждом шагу спотыкаясь при изучении объектного моделирования ( а это дело сложное, даже с пом ощью нашей книги ! ). Лишние зат раты на управление инфраструктурой и уровнями значительно за ­ тягивают реализацию простых задач. Простым проектам ставятся сжатые сроки реа­ лизации, и многого от них не требуется. Проект могут закрыть значительно раньше, чем разработчики закончат задачу, не говоря уже о том, что бы продемонстрировать блестящие преимущества свое й методологии .

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

С ложные функциональные возможности от нее не тре бовались с самого начала .

Будь квалификация разработчиков повыше, на такие жертвы идти не пришлось бы .

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

И так, как действовать, когда этого требуют обстоятельства .

Поместите реализацию прикладной модели (business logic) прямо в интерфейс пользователя. Разбейте приложение на не большие функции и реализу йте их в виде от ­ дельных пользовательских интерф ейсов, помещая правила деловых ре гламентов (business rules) непосредственно в них. Для хранения данных используйте общую ре­ ляционную базу. Пользуйтесь наиболее автоматизированными средствами построения интер фе йса и визуального программирования .

Ересь! Истинное учение гласит (повсеместно, в том числе и в остальных частях этой книги), что предметная область и интерфейс должны быть отделены друг от друга! Факти­ чески без такого разделения трудно применить какие бы то ни было методы, рассматривае­ мые в нашей книге далее. Поэтому ИНТЕЛЛЕКТУАЛЬНЫЙ ИНТЕРФЕЙС ПОЛЬЗОВАТЕЛЯ ( SMART UI) можно считать "анти-шаблоном" в контексте предметно-ориентированного проектирования программ. Но в некоторых других контекстах он вполне допустим. По

11. СТРУКТУРНЫЕ ЭЛЕМЕНТЫ ПРЕДМЕТНО-ОРИЕНТИРОВАННОГО.. .

86 ЧАСТЬ правде говоря, он даже имеет некоторые преимущества, а в некоторых ситуациях просто незаменим - в частности, поэтому он столь широко распространен. Здесь мы рассмотре­ ли его для того, чтобы понять, почему нужно отделять уровень прикладных операций от предметной области, а также, что немаловажно, в каких случаях этого делать не нужно .

Преимущества .

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

• Менее квалифицированным разработчикам практически не требуется дополни­ • тельное обучение, чтобы при ступить к работе .

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

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

Реляционные базы данных справляются с задачей и обеспечивают интеграцию на •

–  –  –

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

Недостатки .

Сложно осуществить интеграцию приложений - разве что через базу данных .

• Отсутствует переносимость функциональных модулей и абстракция прикладных • моделей. Правила прикладной модели (Ьиsinеss rules) приходится дублировать в каждой операции, связанной с ними .

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

Сложность такой системы быстро похоронит все надежды, так что развитие воз­ • можно только в сторону дополнительных простых приложений. Невозможно "изящно" реализовать сложные функции и сложное поведение системы .

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

Большинство гибких языков программирования (таких как Java) для подобных про­ ектов слишком изощренны, и их применение дорого обойдется. Следует пользоваться чем-то в стиле 4GL .

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

ГЛАВА 4. ИЗ ОЛЯЦИЯ ПРЕДМЕТ НО Й ОБЛАСТИ

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

Аналогично, если разработчики привержены принципам ПРОЕКТИРОВАНИЯ ПО МОДЕЛИ (MODEL-DRIVEN DESIGN), то им следует работать по ним с самого начала. Разу­ меется, даже опытные коллективы с большими амбициями должны начинать с самых простых функций и двигаться вперед в режиме последовательных приближений. Но все эти приближения, пусть предварительные, будут построены на модели с изолированным уровнем предметной области, иначе проект так и застрянет на стадии ИI-IТЕЛЛЕКТУ АЛЬ­ J-IОfО ИНТЕРФЕЙСА (SMART UI) .

*** Шаблоп ИНТЕЛЛЕКТУАЛЬНОГО ИНТЕРФЕЙСА (SMART UI) рассматривается здесь только с целью прояснить, почему и когда для изоляции предметной области необходи­ мо применять такой шаблон, как МНОГОУРОВНЕВАЯ АРХИТЕКТУРА ( LAYERED AR­ CHITECTURE) .

Существуют и другие архитектурные решения в промежутке между ИНТЕЛЛЕК­

ТУАЛЬНЫМ ИНТЕРФЕЙСОМ (SMART UI) и МНОГОУРОВНЕВОЙ АРХИТЕКТУРОЙ (LAYERED

ARCHITECTURE). Например, в [ 1 3] описан ТРАН3АКЦИОНI-IЫЙ СЦЕНАРИЙ (TRANSACTION SCRIPT), который отделяет интерфейс от уровня прикладных операций, но не предназна­ чен для реализации объектной модели. Так что, подводя итог, надо сказать слеДУIощее .

Если та или иная архитектура изолирует код предметной области таким образом, что внутренне связную реализацию предметной области МОЖ1-l0 без труда выделить из ос­ талЪ1-l0Й части системы, то такая архитектура, вероят1-l0, сможет nоддер.живать nредмет1-l0-0рие1-lтирова1-l1-lое nроектирова1-lие .

Другие стили программирования тоже имеют свое место под солнцем, и нужно пра­ вильно выбирать подход, балансируя на грани сложности и гибкости. Отказ от четкого выделения предметной области при определенных условиях может обернуться катаст­ рофой. Если задача предстоит сложная и принято решение следовать принципам ПРОЕКТИРОВАНИЯ ПО МОДЕЛИ (MODEL-DRIVEN DESIGN), то стисните зубы, пригласите нужных специалистов и избегайте ИНТЕЛЛЕКТУАЛЬНОГО ИНТЕРФЕЙСА (SMART UI) .

Други е виды изоляции ксожалению, повредить хрупкому организму модели предметной области могут не только инфраструктура и интерфейс пользователя. Приходится иметь дело с другими компонентами предметной области, которые не вполне интегрированы в модель. Прихо­ дится работать с другими группами разработчиков, которые используют другую модель той же предметной области. Эти и другие факторы могут испортить модель и лишить ее полезности. В главе 1 4 рассматривается именно этот вопрос; там вводятся такие lIIабло­ ны, как ОГРАНИЧЕННЫЙ КОНТЕКСТ ( BOUNDED CONTEXT) и ПРЕДОХРАНИТЕЛЬНЫЙ УРОВЕНЬ (ANTICORRUPTION LAYER). Очень сложная модель предметной области сама по себе может стать громоздкой и неповоротливоЙ. В главе 15 рассматривается проблема, как проводить различение и разграничение в пределах уровня предметной модели, чтобы не путать наиболее существенные понятия с второстепенными подробностями .

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

–  –  –

Ч тобы суметь найти компромиссы в программной реализации и при этом не по­ терять преимуu(еств ПРОЕКТИРОВАНИЯ ПО МОДЕЛИ (MODEL- DRIVEN DESIGN), ну)кно начинать с пересмотра азов. Связь между моделью и реализацией необходимо прорабатывать на уровне деталей. В этой главе мы сосредоточимся на отдельных элемен­ тах МО/lСJlИ и придадим им форму, для того чтобы иметь возможность двигаться дальше в СJ1СДУIОIЦ ИХ главах .

Начнем с вuпросов проектирования и рационализации ассоциаций. Ассоциации меж­ ду объектами легко себе представить и нетрудно нарисовать на схеме, но их реализация может завести Бог знает куда. Именно ассоциации показывают, насколько важно в ПРОЕКТИРОВАНИИ ПО МОДЕЛИ принимать детализированные проектные решения .

Переходя к самим объектам, но при этом продолжая "препарировать" соотношения IСЖ/lУ детализированными реIllениями в модели и вопросами программной реализации, м ы сосрсдоточимся на различиях между тремя lпаблонами элементов модели, которые ее выражаlОТ: СУЩНОСТЯМ И (ENTITIES), ЗНАЧЕНИЯМИ (VALUE OBJECTS) и СЛУЖБАМИ (SERVICES) .

Определение объектов, заключаюrцих в себе понятия модели, поначалу кажется ин­ туитивно очевидным, по оттенки смысловых значений могут заставить всерьез задумать­ ся. СУIдествуют определенные нюансы, которые проясняют смысл элементов модели и в совокупности образуют методы проектирования специфических типов объектов .

Представляет ли объект собою нечто, имеющее протяженность и обособленность ­ то, что :\tlОЖНО проследить в разных его состояниях или даже разных реализациях? Или же это атрибут, который описывает состояние какого-то другого объекта? В этом и со­ стоит основное различие между СУЩНОСТЬЮ (ENTITY) и ОБЪЕКТОМ -3ВА ЧЕНИЕМ (У ALUE OBJ ECT). Объявление объектов в четком соответствии с одним или другим шаблоном устраняет двусмыIлепностьь и многозначность, прокладывая путь к надежным проект­ ным реIII СНИЯМ .

Есть и такие аспекты предметной области, которые выражаются более удобно в виде ;еЙСТRИ Й или операций, а не объектов. Несмотря на некоторый отход от традиций объект­ но-ориентированного моделирования, такие аспекты лучше выражать в виде СЛУЖБ (SERVICES), а не навязывать ответственность за эти операции суrцностям или объектам­ значениям. СЛУЖБА (SERVICE) это нечто, срабатывающее в ответ на запрос клиента. На технических урuвнях программного обеспечения суrцествует множество служб. Появляют­ ся они и па уровне предметной области при моделировании некоей деятельности, которая соо гветствует операциям программы, но не ассоциируется ни с каким ее состоянием .

Неизбежно возникают ситуации, в которых приходится идти на компромисс и отхо­ ДИТЬ от "чистой" объектной модели - например, для хранения данных в реляционной ба­ зе данн ы х. В этой главе будут даны некоторые рекомендации, как не свернуть с правиль­ ного пути в обстоятельствах, когда приходится иметь дело с суровой реальностью .

Наконец, в разговоре о МОДУЛЯХ (MODULES) мы поймем, почему каждое проектное реше­ ние должно основываться на умозаключении, выведенном из модели. Идеи высокой внутрен­ ней связности (high cohesion) и низкой внешней зависимости (low соирling), которые часто ОТ­ носят исключительно к техническим аспектам программирования, можно применять и к са­ мим понятиям модели. В методологии проектирования по модели МОДУЛИ составляют часть модели, поэтому должны отражать понятия предметной области .

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

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

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

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

Например, ассоциацию "один ко многим" можно реализовать в виде коллекции в пе­ ременной-экземпляре. Но вовсе не обязательно делать это так прямолинейно. Коллек­ ции может и не быть; вместо этого метод доступа к атрибуту может запрашивать в базе данных поиск соответствующих записей и создавать экземпляры объектов на их основе .

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

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

Существует как минимум три способа сделать ассоциации более удобными и управ­ ляемыми .

1. Свести отношения к однонаправленным, прослеживаемым в одном направлении .

2. Добавить квалификаторы, тем самым снижая кратность .

3. Устранить несущественные ассоциации .

Важно ограничить взаимосвязи до минимума. Двунаправленные ассоциации означа­ ют, что два объекта можно понять только совместно, как одно целое. Если техническое задание непосредственно не требует двунаправленных отношений в том или ином слуЧ А СТЬ 1 1. СТРУКТУРНЫЕ ЭЛЕМЕНТЫ ПРЕДМЕТНО-ОРИЕНТИРОВАННОГО.. .

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

В США, как и в других странах, было много президентов. Это двунаправленное отно­ шение "один ко многим". И все-таки мы редко начинаем с имени "Джордж ВашинП'он" и задаем вопрос "Президентом какой страны он был?". С практической точки зрения эту связь можно считать однонаправленной ассоциацией, прослеживаемой от страны к прези­ денту. Это усовершенствование отражает как лучшее понимание модели, так и практич­ ность архитектуры. В нем заключено утверждение, что одно из направлений ассоциации более важно и значимо, чем другое. При этом класс Человек (Person) оказывается неза­ БИСИМЫМ от значительно менее фундаментального понятия Президент (President) .

–  –  –

Очень часто углубленное понимание модели порождает квалификатор к той или иной ассоциации. Если глубже задуматься над примером с президентами, то можно сде­ лать вывод, что в стране может быть одновременно не более одного президента (если не считать времена гражданской войны). Этот квалификатор уменьшает кратность до от­ ношения "один к одному" и внедряет это правило в модель явным образом. Теперь во­ прос: кто был президентом США в 1 790 году? Ответ: Джордж Вашингтон .

–  –  –

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

Если последовательно ограничить ассоциации с тем, чтобы выразить eCTecTBeHHYIo асим метрию предметной области, это не только УПрОlдает программную реализацию и делает их более информативными, но и придает большую значимость оставшимся двуГЛ АВА 5. МОДЕЛЬ, ВЫРАЖ ЕННАЯ В П РОГРАММЕ 91 направленным ассоциациям. Если двунаправленность ассоциации является семантиче­ ской характеристикой явления, если она СУlцественна для функционирования програм­ Mb.I, то такую ассоциацию стоит сохранить .

Самым "сильным" УПрОlцением, конечно, будет полное устранение ассоциации, если она несущественна для работы или фундаментального понимания объектов модели .

–  –  –

проекте.) Давайте усовершенствуем модель, добавив квалификатор к ассоциации между Бро ­ KepcKим счетом (Brokerage Account) и Инвестицией ( Inves tment) с целью уменьшить ее кратность. Квалификатор гласит: разрешается только одна инвестиция на од ну акцию .

Это не будет справедливо во всех рабочих ситуациях (например, при работе с лотами ­ партиями ценных бумаг). Но независимо от конкретных правил, по мере обнаружения ог­ раничений на ассоциации их следует добавлять в модель и в реализацию. От этого модель становится более точной, а программная реализация - более удобной в работе .

Реализация на Java могла бы выглядеть так .

pub l i c c l a s s B roke rageAc count S t r i ng a c c ountNumb e r j Cu s t omer custome r j Мар inve s tment s j

–  –  –

Реализация с применением SQL будет такой .

pub l i c c l a s s BrokerageAccount { S t ring accountNumber ;

S t r ing cus t omerSoc i a 1 8 ecuri tyNumber ;

–  –  –

большой шаг к П РОЕКТИРОВАНИЮ ПО МОДЕЛИ (MODEL-DRIVEN DESIGN). Теперь обра­ тимся к самим объектам. Существуют нюансы, которые делают модель более понятной и одновременно ведут к более практичной реализации .

Ч АСТЬ 11. СТРУКТУРНЫЕ ЭЛЕМЕНТЫ ПРЕДМЕТНО-ОР И ЕНТИРОВАННОГО .

. .

Сущно сти (указуемые объ екты )

–  –  –

На меня как-то подала в суд домовладелица, желая взыскать возмещение ущерба, причиненного ее имуществу. Предоставленные мне документы описывали квартиру с дырами в стенах, с пятнами на ковре, с какой-то ядовитой жидкостью в раковине, от ед­ КИХ испарений которой на кухне облезли обои. В судебных документах меня именовали квартиросъемщиком, несущим ответственность за этот ущерб, и обозначали по имени и тогдашнему адресу. Это было непонятно, так как я никогда в жизни не бывал в постра­ давшей квартире .

Но почти сразу же я догадался, что меня, должно быть, просто приняли за другого че­ ловека. Я позвонил истице и объяснил ей это, но она не поверила. Бывший жилец не­ сколько месяцев скрывался от нее. Как я мог доказать, что я не тот человек, из-за которо­ го она понесла такие убытки? Ведь я был единственным Эриком Эвансом в телефонном справочнике .

ЧТО ж, именно телефонная книга и стала моим спасением. Я жил в одной и той же квартире уже два года, поэтому спросил истицу, есть ли у нее справочник прошлого года .

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

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

Здесь имеются некоторые проблемы технического характера, о которых будет сказано позже, а пока рассмотрим фундаментальную теоретическую проблему: многие веIЦИ оп­ ределяются не частными атрибутами, а индивидуальным, неповторимым СУlцествовани­ ем. В нашем обычном понимании человек (если продолжить наш нетехнический пример ) имеет индивидуальное существование, которое продолжается от рождения до смерти

–  –  –

ГЛАВА 5. МОДЕЛЬ, ВЫРАЖ ЕННАЯ В ПРОГРАММЕ 95 и даже после нее .

Физические атрибуты человека изменяются, а со временем и вовсе ис­ чезают. Может измениться его имя. Завязываются и обрываются финансовые взаимоот­ ношения. У человеческой личности нет ни единого атрибута, который бы не мог изме­ ниться, а вот его индивидуальность сохраняется. Тот ли я человек, которым был в пяти­ летнем возрасте? Подобный метафизический вопрос немаловажен при поиске эqJфективных моделей предметных областей. Если слегка перефразировать: имеет ли для пользователя nрограммы значение, был или не был я тем же человеком в свои пять лет?

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

Каждая из этих форм объекта-клиента реализуется по-разному, с применением раз­ ных языков и технологий программирования. Но когда нужно поднять трубку и предъя­ вить денеЖНУIО претензию, необходимо знать: тот ли это клиент, на счету которого за­ фиксированы нарушения? Тот ли это клиент, о котором Джек (конкретный агент) соби­ рает информаЦИIО уже несколько недель? Или же это совершенно новый клиент?

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

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

В объектном моделировании главное внимание обычно фокусируется на атрибутах объекта, но для фундаментального понятия СУЩНОСТИ главное - не атрибуты, а абст­ рактное непрерывное существование в течение всего жизненного цикла, даже с перехо­ дом в различные формы .

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

Логически целостный объект, определяемый совокупностью индивидуальных черт, называется СУЩНОСТЬЮ ( ENTITY) 3. ДЛЯ таких объектов существуют особые принципы моделирования и проектирования. На протяжении их цикла существования у них может радикально меняться и форма, и содержание, но непрерывность этого существования 3 Модель объекта ENTITY это совсем не то, что объект entity Ьеаn в ]ava. Последний задумы­ валея как основа для реализации объектов-единиц, но так и не стал таковой. Большинство сущно­ стей-еntitу реалиэуются в виде обыкновенных объектов. Но независимо от способа реализации, та­ кие сущнос ги являются принципиально важными в модели предметной области .

Ч АСТЬ 11. СТРУКТУРНЫЕ ЭЛЕМЕНТЫ ПРЕДМЕТНО-ОРИЕНТИРО ВАННОГО .

. .

обязана поддерживаться. Они должны идентифицироваться таким образом, чтобы их мо)кно было однозначно отследить. Определения классов, обязанностей, атрибутов и ас­ социаци й для таких объектов следует строить вокруг их смыслового значения, а не при­ своенных им атрибутов. Но даже если некоторые объекты-сУЩНОСТИ не подвергаются таким радикальным изменениям или не имеют такого сложного цикла существования, их все равно полезно отнести к этой семантической категории, потому что такие модели будут более ясными, а их реализации - более надежными .

Большинство логических "сущностей" в программной системе не представляют собой физические или юридические лица4. СУщность это все то, что сохраняет свое инди­ видуальное суrцествование и отличие на протяжении срока "жизни", независимо от ат­ рибутов, важных для пользователя приложения. Это может быть человек, город, автомо­ биль, лотерейный билет или банковская транзакция .

С другой стороны, отчетливо индивидуальным существованием бывают наделены да­ леко не все объекты модели. Этот важный момент "затуманивается" тем фактом, что в объектно-ориентированных языках операции проверки идентичности (например, " = = " B Java) автоматически встраиваются в каждый объект. Эти операции определяют, указы­ вают ли две ссылки на один и тот же объект, сравнивая их положение в памяти или ис­ пользуя какой-нибудь другой механизм. В этом смысле любой экземпляр объекта явля­ ется индивидуальной логической единицей, сущностью. Если предметная область - это, скажем, создание исполняемой среды Java или технических средств для поддержки ло­ кального кэширования удаленных объектов, то каждый экземпляр объектов в них дейст­ вительно будет сущностью. Но в других прикладных областях такой механизм инди­ видуальной идентификации значит весьма мало. Индивидуальное существование - это ТОНКИЙ смысловой атрибут СУЩНОСТЕЙ, который невозможно превратить в стандартное автоматизированное средство языка .

Рассмотрим транзакции в банковских операциях. Два депозита на одну и ту же сумму в один и тот же день являются различными транзакциями, у них есть индивидуальность, и поэтому они сущности. С другой стороны, атрибуты "сумма" в этих двух транзак­ циях, скорее всего, представляют собой экземпляры некоего объекта "деньги". У этих значений никакого индивидуального существования нет, потому что различать их нико­ му не надо. Фактически два объекта могут не иметь индивидуальных отличий друг от друга, даже если у них нет одинаковых атрибутов; более того, они могут даже не принад­ лежать одному классу. Когда клиент банка сверяет транзакции из банковского баланса с расчетными операциями, зафиксированными в его собственных учетных документах, перед ним стоит задача найти одинаковые транзакции, пусть даже они фиксировались разными людьми в разные дни (конечно, при условии, что баланс подсчитан после всех взаимных расчетов). Уникальным идентификатором для этой цели призван служить но­ мер чека - неважно, выполняется обработка данных вручную или программно. Снятие наличных и помещение средств на депозит при отсутствии такого идентификационного номера представляют большие трудности, но принцип здесь тот же: каждая транзак­ ция это СУЩНОСТЬ, проявляющаяся как минимум в двух формах .

Индивидуальность объекта-сУЩНОСТИ, как правило, является весомым фактором и за пределами компьютерных систем, - например, в приведенных примерах банковских тран­ закций и квартиросъемщиков. Но иногда индивидуальное существование возможно только в контексте программной системы, - например, в виде вычислительного процесса .

–  –  –

ГЛАВА 5. МОДЕЛЬ, ВЫ Р АЖЕННАЯ В ПРОГРАММЕ 97 Если объект определяется ун икальным и н дивидуальным существован ием, а не на­ бором атрибутов, это свойство следует с читать главным при определении объекта в модели .

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

Индивидуальность, индивидуальное существование - это не имманентное свойство вещей в природе, а качество, всего лишь приписываемое им из-за его полезности. На са­ мом деле одна и та же реально существующая в природе вещь может как представляться, так и не представляться объеКТОМ-СУЩI-IОСТЬЮ в модели предметной области .

Например, в программе резервирования мест на стадионе как зрители, так и места могут считаться СУЩНОСТЯМИ. В случае билетов с местами, где на каждом билете напе­ чатан номер строго определенного места, это место действительно является сущностыо .

Идентификатор этой сущности - номер места, и в рамках данного стадиона он уникален .

Место может иметь много других атрибутов, таких как точное местоположение, качество вида на игровое поле, цену, но только номер места (или пара "ряд-место" ) может исполь­ зоваться для точного определения и различения мест .

е другой стороны, если билеты продаются без места, т.е. купившие их зрители садят­ ся на любые еще не занятые места, различать отдельные места нет никакой необходимо­ сти. Значение имеет только общее количество мест. Хотя номера мест по-прежнему фи­ зически нанесены на сиденья, программа не обязана за ними следить. Вообще-то, в этом случае ассоциировать номера мест с билетами в модели было бы прямой ошибкой, пото­ му что при продаже билетов "без мест" такое требование отсутствует. Здесь места не яв­ ляются СУЩНОСТЯМИ, и идентификатор для них не нужен .

*** Моделирование СУЩНОСТЕЙ При моделировании объекта совершенно естественно думать о его атрибутах, и очень важно думать о его поведении, рабочих функциях. Но основная функция СУЩНОСТИ ­ поддерживать непрерывность своего существования таким образом, чтобы ее поведение было понятным и предсказуемым. Лучший способ добиться этого - умеренность и эконо­ мия. Вместо того чтобы сосредоточиться на атрибутах или даже на рабочих функциях объ­ екта, следует ограничить определение объекта-сУЩНОСТИ наиболее неотъемлемыми его характеристиками, т.е. теми, которые однозначно выделяют его среди других и обычно ис­ пользуются для его поиска и сравнения. Задавайте только те рабочие функции, которые существенны для создания понятия об объекте, и только те атрибуты, которых требуют эти функции. Все атрибуты и функции, которые выходят за эти рамки, старайтесь выносить в другие объекты, ассоциированные с главной СУЩНОСТЬЮ. Некоторые из них тоже будут СУЩНОСТЯМИ, а некоторые ОБЪЕКТАМИ-ЗНАЧЕНИЯМИ (VALUE OBJECTS); это следующий шаблон, который мы рассматриваем в этой главе. Кроме индивидуальности и непрерывно­ сти существования, дЛЯ СУЩНОСТЕЙ часто характерно то, что они выполняют свои функ­ ции, координируя операции объектов, которые им принадлежат .

–  –  –

(Cus tomer) на рис. 5.5, но для поиска или сопоставления личности Клиен'Ж'а может также использоваться номер телефона или адрес. Имя ие определяет индивидуальность человека, но входит в число средств, позволяющих проверить ее подлинность. В данном примере ат­ рибуты номера телефона и адреса помещены в объект Клиен'Ж', но в реальном проекте для такого решения были бы приняты во внимание типичные способы различения или сопос­ тавления клиентов. Например, если у Клиен'Ж'а есть много номеров телефонов для разных целей, то номер нельзя ассоциировать с индивидуальной личностью клиента, и его следует вынести в Деловые кон'ж'ак'жIы (Sales Contact) .

Проектирование операций идентификации Для каждого объекта-СУЩНОСТИ должен быть задан способ сопоставления его с дру­ гим объектом - такой, который бы позволял различать их даже в случае совпадения описательных атрибутов. Идентифицирующий атрибут должен гарантированно оста­ ваться уникальным в пределах системы, независимо от способа ее определения - даже в распределенной системе, даже в архиве .

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

Даже если у нас есть среда программирования, упрощающая решение технических задач, остается принципиальный вопрос: как узнать, представляют ли два объекта одну и ту же концептуальную СУЩНОСТЬ? Определение идентичности возникает из модели .

Чтобы построить такое определение, нужно понимать предметную область .

Иногда некоторые атрибуты данных или комбинации атрибутов гарантированно яв­ ляются уникальными в пределах системы, - например, в силу наложенных на них треГЛАВА 5. МОДЕЛЬ, ВЫРАЖЕННАЯ В ПРОГРАММЕ 99 бованиЙ. При таком подходе у СУЩНОСТИ есть неповторимый ключ, который ее одно­ значно идентифицирует. Например, ежедневную газету можно идентифицировать по на­ званию, городу и дате выпуска. ( Если не считать внеочередных выпусков и возможных изменений названия.) Если из атрибутов объекта нельзя составить действительно уникальный ключ, то есть другое типовое решение - каждому экземпляру присвоить символ-идентификатор (число или текстовую строку), не повторяюrцийся в пределах класса. После создания идентификатора и помещения его в атрибут СУЩНОСТИ его следует сделать неизменяе­ мым. Он никогда не должен изменяться, даже если среда программирования не может напрямую принудить программу к выполнению этого требования. Например, такой идентификатор сохраняется, когда объект упаковывают в базу данных, а затем извлека­ ют оттуда. Иногда технические средства программирования могут помочь в этом, но в других случаях приходится полагаться на дисциплинированность разработчика .

Идентификаторы часто генерируются системой автоматически. Алгоритм генериро­ вания должен гарантировать уникальность в пределах системы, что для параллельных вычислений и распределенных систем может оказаться непростой задачей. Генерирова­ ние таких идентификаторов может потребовать приемов и технологий, далеко ВЫХОДЯ­ щих за пределы тематики нашей книги. Здесь хотелось бы только указать, когда именно возникает необходимость рассмотрения таких вопросов, чтобы разработчики были в курсе существования проблемы и могли сузить поиск решения до самой критической области. Главное здесь - осознать, что ВОПРОСЫ идентификации связаны со специфиче­ скими аспектами самой модели. Создание средств идентификации часто требует тща­ тельного изучения предметной области .

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

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

Б некоторых случаях уникальность идентификатора не должна ограничиваться пре­ делами компьютерной системы. Например, если между ДВУМЯ больницами, имеIОЩИМИ отдельные компьютерные системы управления, идет обмен медицинскими картами, то в идеале каждая система должна была бы обозначать пациента одним и тем же иденти­ фикационным кодом. Но это сложно сделать, если они сами генерируют свои идентифи­ каторы. В таких системах часто используются идентификаторы, выпущенные какой­ нибудь другой организацией - как правило, государственной. В США в качестве иден­ тификаторов для пациентов больниц часто применяются номера социального страхова­ ния (Social Security). Впрочем, такие методы не дают полной гарантии. Например, не у всех есть номера социального страхования (в частности, их нет у детей и у иностран­ ных граждан), и многие граждане протестуют против использования этих номеров по со­ ображениям сохранения личной тайны .

Ч АСТЬ 11. СТРУКТУРНЫЕ ЭЛЕМЕНТЫ ПРЕДМЕТНО-ОРИЕНТИРОВАННОГО .

. .

В менее формальных ситуациях (например, в видеопрокате) идентификаторами могут служить номера телефонов. Но один телефон может использоваться несколькими людьми .

К тому же номер может измениться или его могут даже передать другому абоненту .

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

Встречаясь с таким обилием технических проблем, легко потерять из виду концепту­ альные задачи, лежащие на более глубоком уровне. Что означает по сути "одинаковость" двух объектов? Легко пометить каждый объект идентификатором или написать опера­ цию сравнения двух экземпляров, но если эти идентификаторы или операции не соот­ ветствуют никакому смысловому аспекту в модели, они только приведут к путанице. Вот почему операции назначения индивидуальных идентификационных данных часто тре­ буют обязательного ввода пользователем каких-либо данных. Например, программы учета личных финансов могут найти и предложить приблизительные соответствия меж­ ду платежами, но окончательное решение они ожидают от пользователя .

Объекты-зн ачения

–  –  –

Когда ребенок рисует, его интересует цвет карандаша или фломастера, а также, воз­ можно, острота его грифеля. Но если есть два карандаша одинакового цвета и формы, ему, вероятно, будет все равно, каким рисовать. Если карандаш потерялся и его при­ шлось заменить таким же из новой коробки, малыш может продолжить работу, нисколь­ ко не отвлекаясь на сам (ракт замены .

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

ГЛА В А 5. М ОДЕЛЬ, В ЫРА ЖЕННАЯ В ПР ОГРА ММЕ

Самые важные объекты в модели обычно представляют собой СУЩНОСТИ. Каждую такую сущность очень важно правильно идентифицировать и отслеживать. Естествен­ ным образом возникает желание сделать все объекты области индивидуальными. Дейст­ вительно, в некоторых средах программирования каждому объекту присваивается уни­ кальный идентификатор .

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

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

Смотря для кого. В программе для фирмы, ТОРГУIощей по почте, адрес необходим для под­ Является ли адрес объектом-значением?

–  –  –

пределах "подстроятся" под это изменение. Здесь адрес является СУЩНОСТЬЮ .

сами. Такие адресные объекты наслеДУIОТ свой почтовый индекс от родительского объекта в иерархии, и если почтовое управление решит изменить индексные зоны, все адреса в их В программе для коммунальной электрической компании адрес соответствует месту, к ко­ тире позвонят и по отдельности закажут какие-то работы, фирме нужно знать, что они на­ торому подведены кабельные линии и где оказываIОТСЯ услуги. Если два соседа по квар­

–  –  –

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

Проектирование программного обеспечения - это постоянная битва за простоту .

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

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

ОБЪЕКТОМ -3НА ЧЕНИЕМ (v ALUE OBJECT) называется объект, который представляет описательный аспект предметной области и не имеет индивидуального существования, тех элементов проекта, о которых достаточно знать только, что они собой представляют, собственной идентичности. Такие объекты создаются в программе для представления но не кем имеиио они ЯВЛЯIОТСЯ .

ЧАСТЬ 11. СТРУКТУРНЫЕ ЭЛЕМЕНТЫ ПРЕДМЕТНО-ОРИЕНТИРОВАННОГО .

. .

В базовых библиотеках многих современных систем разработки программ представ­ лены такие ОБЪЕКТЫ-ЗНАЧЕНИЯ, как цвета, а также строки и числа. (Кому нужно разли­ чать отдельные четверки или буквы Q?) ЭТО совсем простые примеры, но реальные объ­ екты-показатели не обязательно бывают такими простыми. Например, программа анали­ за и генерирования цветов может иметь в своей основе сложную модель, в которой объекты-цвета можно смешивать для получения новых цветов. Для получения нового объекта-значения таким образом могут применяться сложные алгоритмы .

ОБЪЕКТ-ЗНАЧЕНИЕ может представлять собой совокупность других объектов. В про­ граммах архитектурного проектирования жилых домов для любого стиля окон можно создать отдельный объект. Этот "стиль окна" можно инкорпорировать в объект "окно" наряду с атрибутами ширины и высоты, а также правилами изменения и комбинирова­ ния. Такие окна - сложные ОБЪЕКТЫ-ЗНАЧЕНИЯ, составленные из других ОБЪЕКТОВ­ ЗНАЧЕНИЙ. Они, в свою очередь, могут инкорпорироваться в еще большие составные элементы плана здания - например, объекты-"стены" .

ОБЪЕКТЫ-ЗНАЧЕНИЯ могут даже ссылаться на СУЩНОСТИ. Например, если я запро­ шу картографическую онлайн-службу проложить мне живописный маршрут из Сан­ Франциско в Лос-Анджелес, то она может сгенерировать объект маршрут (Route), со­ единяющий эти два города по шоссе Pacific Coast Highway. Этот объект будет ЗНА­ ЧЕНИЕМ, пусть даже все три объекта, на которые он ссылается (два города и шоссе), яв­ ляются СУЩНОСТЯМИ .

ОБЪЕКТЫ-ЗНАЧЕНИЯ часто передаются в качестве параметров в сообщениях между объектами. Нередко они носят временный характер - создаются для конкретной опера­ ции и тут же уничтожаются. ОБЪЕКТЫ-ЗНАЧЕНИЯ могут использоваться в виде атрибу­ тов СУЩНОСТЕЙ (и других ЗНАЧЕНИЙ). Так, человек, в целом, может представляться ин­ дивидуальной СУЩНОСТЬЮ, но его имя будет ОБЪЕКТОМ-ЗНАЧЕНИЕМ .

Если элемент модели полностью определяется своими атрибутами, то его следует в него атрибутов и придайте ему соответствующую функциональность. Считайте такой считать ОБЪЕКТОМ-ЗНАЧЕНИЕМ. Сделайте так, чтобы он отражал смысл заложенных объект неизменяющимся. Не давайте ему индивидуальности, вообще избегайте любых сложностей, неизбежных при программном управлении СУЩНОСТЯМИ .

Атрибуты, образующие в совокупности ОБЪЕКТ-ЗНАЧЕНИЕ, должны быть единым концептуальным целымS. Например, улица, город и почтовый индекс не должны быть отдельными атрибутами объекта Человек (Person). Они входят как составные части в адрес, что делает проще устройство объекта Человек и больше соответствует концеп­ ции ОБЪЕКТА-ЗНАЧЕНИЯ .

* ** Пр оектирование ОБЪЕКТОВ-ЗНАЧЕНИЙ Нам все равно, какой именно экземпляр ОБЪЕКТА-ЗНАЧЕНИЯ (VALUE OBJECT) у нас имеется. Такая вольность дает проектировщику достаточно места для маневров по уп­ рощению архитектуры и оптимизации быстродействия. При этом приходится принимать решения по части копирования, совместного использования и неизменяемости .

Если двое людей имеют одно и то же имя, они от этого не становятся одним и тем же человеком; не становятся они и взаимозаменяемыми. Но вот объект, представляющий имя, - вполне заменяем, лишь бы имя было написано правильно. Объект имя (Name) можно смело 'Копировать из первого объекта Человек (Person) во второй .

5 Шаблон WHOLE VALUE (целостный объект-знач ение), автор Уорд Каннингем (Ward Cun­ ningham) .

–  –  –

ЧАСТЬ 11. СТРУКТУРНЫЕ ЭЛЕМЕНТЫ ПРЕДМЕТНО-ОРИЕНТИРОВАННОГО .

. .

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

• если занимаемый объем памяти или количество объектов в базе данных являются критическими параметрами;

• если дополнительные затраты на пересылку по сети невелики (например, на цен­ трализованном сервере);

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

–  –  –

в ОБЪЕКТЫ-ЗНАЧЕНИЯ .

модификации существующего ОБЪЕКТА-ЗНАЧЕНИЯ просто используется новый. Но бывают случаи, когда из соображений быстродействия лучше разрешить вносить изменения

В пользу этого обычно говорят следующие факторы:

• частые изменения значения объекта (т.е. собственно ОБЪЕКТА-ЗНАЧЕНИЯ) ;

• затратность создания и уничтожения объекта;

казано в предыдущем примере;

• опасность замены (вместо модификации) при группировании объектов, как было по­

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

–  –  –

Атрибут или объект в некоторых языках и средах программирования можно объявить нсизменяемым, а в других - нет. Если такая возможность есть, это помогает выразить при­ пятое проектное решение в явной форме, но если ее нет - ничего страшного. Многие осо­ бенности, присутствующие в модели, невозможно определить явно в программной реали­ зации с СУПJ;ествующих средств и языков программирования. Например, нельзя ПОМОIЦЬЮ так объявить объект-сУЩНОСТЬ, чтобы ему при этом автоматически назначалась операция проверки идентичности. Но если для концептуальной особенности модели не СУlцествует прямой поддержки в языке, это еще не значит, что сама особенность бесполезна. Если су­ ществуют только неявные способы для ее реализации, это всего лишь потребует от разра­ ботчика большей "стилистической дисциплины". Здесь должны пойти в ход соглашения об именах, Тlцательность подготовки документации и постоянное обсуждение проблемы .

Если ОБЪЕКТ-ЗНАЧЕНИЕ объявлен неизменяемым, то управлять его изменениями очень просто. Единственный способ изменения полная замена. Неизменяемые объек­ ты можно предоставлять в совместный доступ, как в примере с электрическим выводом .

(garbage collection) Если "сборка мусора" работает надежно, то удаление всего ЛИIllЬ

–  –  –

ГЛАВА 5. МОДЕЛЬ, ВЫРАЖЕННАЯ В ПРОГРАММЕ

Определение ОБЪЕКТОВ-ЗНАЧЕНИЙ и объявление их неизменяемыми - это частный случай общего правила, которое состоит в следующем. Чтобы иметь возможность техни­ чески оптимизировать быстродействие, разработчики должны избегать лишних связей­ ограничений в модели. А если явно определить все существенные ограничения, это дает возможность оптимизировать архитектуру, не боясь нарушить работу важнейших алго­ ритмических частей программы. Такая оптимизация архитектуры часто зависит от кон­ кретной технологии, используемой в проекте .

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

Если на объект ссылается много других объектов, то не все из них обязательно распола­ гаются близко от него (на той же странице), и поэтому для получения данных требуется дополнительная физическая операция. Но если экземпляр ОБЪЕКТА-ЗНАЧЕНИЯ, который служит атрибутом нескольких СУЩНОСТЕЙ, физически скопировать, а не просто поставить ссылку на него, то такой объект можно будет разместить на той же странице, что и любую из использующих его СУЩНОСТЕЙ. Этот прием размножения копий одних и тех же данных называется де1l0рмалuзацией и часто используется тогда, когда время обращения к данн ы м важнее, чем экономия дискового пространства или удобство обслуживания базы .

В реляционной базе данных можно поместить ОБЪЕКТ-ЗНАЧЕНИЕ в таблицу объекта­ СУЩНОСТИ, который им владеет, а не создавать ассоциативную связь с отдельной табли­ цей. Если в распределенной системе хранить ссылку на ОБЪЕКТ-ЗНАЧЕНИЕ на другом сервере, от этого наверняка замедлится передача сообщений. Поэтому лучше передать на другой сервер полную копию объекта. Таких копий можно сделать сколько угодно, по­ скольку мы имеем дело с ОБЪЕКТАМИ-ЗНАЧЕНИЯМИ .

Пр оектирование ассо циаций с помощью ОБЪЕКТОВ-3НАЧЕНИЙ Многое, что было раньше сказано об ассоциациях, относится как к СУЩНОСТЯМ (ENTITIES), так и к ОБЪЕКТАМ-ЗНАЧЕНИЯМ (VALUE OB]ECTS). Чем меньше в модели ассо­ циаций и чем они проще, тем лучше .

В то время как двунаправленные ассоциации между СУЩНОСТЯМИ бывает трудно поддерживать, двунаправленные ассоциации между ОБЪЕКТАМИ-ЗНАЧЕIIИЯМИ вообще не имеют смысла. При отсутствии индивидуальности у объектов бессмысленно говорить, что тот или иной объект ссылается на тот же ОБЪЕКТ-ЗНАЧЕНИЕ, который ссылается на него. Можно разве что сказать так: первый объект ссылается на другой, эквивалентный тому, который сам ссылается на первый. Но и этот инвариант надо как-то принудительна задать в другом месте. Хотя можно было бы теоретически сделать указатели в обе сторо­ ны, трудно придумать примеры, в которых этот прием был бы уместен. Поэтому старай­ тесь избегать двунаправленных ассоциаций между ОБЪЕКТАМИ-ЗНАЧЕНИЯМИ. Если же такие ассоциации кажутся необходимыми в модели, пересмотрите само решение сделать эти объекты значениями. Может быть, у них есть своеобразная индивидуальность, кото­ рую вы до сих пор не заметили .

–  –  –

(SERVICES) .

Службы все на свете сводится к вещам и предметам .

I--Ie В некоторых случаях самые четкие и практичпые программные архитектуры содер­ жат операции, которые по своей сути не принадлежат ни одному конкретному объекту .

Чем выкручиваться из этого положения искусственными методами, можно последовать естественному ходу событий и включить в модель так называемые СЛУЖБЫ (SERVICES) .

* * * в прикладной предметной области бывают такие операции, которым нельзя найти ес­ тественное место в объекте типа СУIЦНОСТИ (ENTITY) или ЗНАЧЕНИЯ (VALUE ОВ]ЕСТ) .

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

В :этом месте легко совершить распространенную ошибку: отказаться от попытки по­ местить операцию в ПОДХОДЯIЦИЙ дЛЯ нее объект, и таким образом прийти к процедурно­ МУ программироваНИIО. Но если насильно поместить операЦИIО в объект с чуждым ей оп­ и рефакторинга. Если в простом объекте реализовать много сложных операций, он МО­ ределением, от этого сам объект утратит чистоту замысла, станет труднее для понимания )кет прсвратиться в непонятно что, занятое непонятно чем. В таких операциях часто уча­ ствуют другие объекты предметной области, и между ними выполняется согласование для выполнения совместной задачи. Дополнительная ответственность создает цепочки зависимости между объектами, смешивая понятия, которые можно было бы рассматри­ вать независимо .

Часто службы выступают под личиной объектов модели, не наполненных никаким особым смыслом, кроме выполнения определенной операции. Эти "исполнители" в кон­ це концов получают имена наподобие "диспетчер (manager) чего-нибудь". У них нет ни собственного характерного состояния, ни другой роли в предметной области, кроме реализации конкретной операции. Но, по крайней мере, при таком решении характерные действия, выполняемые в модели, куда-то помещены и не загромождают настоящие, смысловые объекты модели .

ГЛАВА 5. МОДЕЛЬ, ВЫРАЖЕННАЯ В П Р О ГРАММЕ 1 07 Некоторые понятия модели неестественны в роли объектов .

Если принудительно реализовать нужные функции модели в объекте-сущности или объекте-значении, это либо исказит определение объекта из модели, либо добавит в модель лишних, искусст­ венно сконструированных объектов .

СЛУЖБА (SERVICE) - это операция, предлагаемая в модели в виде обособленного ИН­ терфейса, который, в отличие от СУЩНОСТЕЙ и ОБЪЕКТОВ-ЗНАЧЕНИЙ, не инкапсулирует никакого состояния. СЛУЖБА это обычный шаблон в технических средах программи­ рования, но службы применимы и на уровне предметной области .

тов. В отличие от СУЩНОСТЕЙ и ОБЪЕКТОВ-ЗНАЧЕНИЙ, она определяется только тем, что Само название служба подчеркивает положение, подчиненное нуждам других объек­ умеет делать для клиента. Соответственно, и имя СЛУЖБЕ обычно дают по ее функции, а не сути - это глагол, а не существительное. Определение у нее, тем не менее, может быть достаточно абстрактным, но с другим оттенком по сравнению с объектом. На СЛУЖБУ должны возлагаться конкретные обязанности, и они вместе с интерфейсом должны определяться в составе модели. Имена операций следует взять из ЕДИНОГО ЯЗЫКА (UBIQUITOUS LANGUAGE) или ввести в него. Параметрами и результатами работы СЛУЖБЫ должны быть объекты модели .

Не стоит, однако, и злоупотреблять СЛУЖБАМИ, лишая СУЩНОСТИ и ОБЪЕКТЫ­ ЗНАЧЕНИЯ всякой функциональной нагрузки. В то время как операция это важное по­ ПРОЕКТИРОВАНИЯ ПО МОДЕЛИ. Если операция объявлена в модели СЛУЖБОЙ, а не нятие предметной области, СЛУЖБА является естественным элементом в рамках "липовым" объектом, ничего реального не представляющим, то она никого не введет в заблуждение .

Хорошая СЛУЖБА обладает тремя свойствами .

Выполняемая ею операция соответствует понятию модели, не ЯВЛЯlощемуся естественной частью объекта-сущности или объекта-значения .

Интерфейс службы определен через другие элементы модели предметной области .

2 .

Операция не имеет собственного состояния .

3 .

Последний пункт - отсутствие состояния - означает, что любой клиент может вос­ пользоваться любым экземпляром нужной ему СЛУЖБЫ, не обращая внимания на инди­ видуальную предысторию ее работы. При работе СЛУЖБЫ может использоваться (и даже подвергаться изменениям) информация, доступная глобально, поэтому возможны по­ бочные эффекты. НО СЛУЖБА не хранит данных о своем собственном состоянии, которое влияло бы на ее работу, в отличие от большинства объектов модели .

Если существенно важный процесс или преобразование в модели не относится к ес­ тественным обязанностям о бъекта-сУЩНОСТИ или ЗНАЧЕНИЯ, добавьте в модель эту операцию с отдельным интерфейсом и назовите ее СЛУЖБОЙ. Определите интерфейс на языке модели и сделайте имя операции элементом ЕДИНОГО ЯЗЫКА. У СЛУЖБЫ не должно быть собственного состояния .

** * Службы и из оляция ур овня предметной о бласти В основе этого шаблона лежат такие СЛУЖБЫ, которые сами по себе много значат для предметной области. Но, конечно, их применение не ограничивается одним этим уров­ нем. Не так уж легко отличить СЛУЖБЫ, принадлежащие к уровню предметной области, от СЛУЖБ других уровней, и соответственно разделить обязанности, чтобы четко обозна­ чить это различие .

ЧАСТЬ 11. СТРУКТУРНЫЕ ЭЛЕМЕНТЫ ПРЕДМЕТНО-ОРИЕНТИРОВАННОГО .

. .

и принадлежит инфраструктурному уровню. СЛУЖБЫ уровней модели и прикладных Большинство описанных в литературе СЛУЖБ имеет чисто технический характер операций взаимодействуют с инфраструктурными СЛУЖБАМИ. Например, в банке может работать программа, которая отсылает клиенту письмо по электронной почте всякий раз, когда баланс на его счету падает ниже определенного порога. Интерфейс, инкапсули­ рующий ПОЧТОВУIО систему, а с нею, возможно, и другие способы извещения клиента, об­ разует СЛУЖБУ на инфраструктурном уровне .

А вот отличить СЛУЖБЫ операционного уровня от уровня предметной области (модели) бывает труднее. Операционный уровень отвечает за то, чтобы отдать приказ об извещении клиента. А уровень модели определяет, достигнут ли порог - правда, эта за­ дача не требует отдельной СЛУЖБЫ, а скорее, входит в полномочия объекта "банковский счет". Та же самая банковская программа, возможно, занимается и переводом денежных средств. Если сконструировать СЛУЖБУ, отвечающую за подведение дебета и кредита в процесс е перевода, то она будет принадлежать уровню предметной области. Перевод ная операция предметной области. В технических же службах никакие понятия при­ денег - это смысловой элемент банковского дела, а его реализация - это фундаменталь­ кладной модели вообще не должны упоминаться .



Pages:   || 2 | 3 | 4 | 5 |



Похожие работы:

«ЕВРАЗИЙСКИЙ НАУЧНЫЙ ЖУРНАЛ №9 сентябрь, 2018 Ежемесячное научное издание "Редакция Евразийского научного журнала" Санкт-Петербург 2018 (ISSN) 2410-7255 Евразийский научный журнал №9 сентябрь,...»

«Министерство образования и науки Российской Федерации федеральное государственное автономное образовательное учреждение высшего образования "НАЦИОНАЛЬНЫЙ ИССЛЕДОВАТЕЛЬСКИЙ ТОМСКИЙ ПОЛИТЕХНИЧЕСКИЙ УНИВЕРСИТЕТ" Школа инженерного предпринимательства Направление подготовки: БАКАЛАВРСКАЯ РАБОТА Тема работы "Основные нап...»

«ПБ68 Декларация: ТР ТС № RU Д-RU.ИМ43.В.00912 Сертификат: № РОСС RU.31653.04СПБ0.П04.029 Сертификат: № C-RU.ПБ68.В.03036 Сирена радиоканальная "SRC-01" 433 МГц Паспорт Идентификационный номер прибора 1. Общие сведения Сирена радиоканальная "SRC-01...»

«Руководство пользователя FindMe F2 Volt. Расширенная версия Уважаемый пользователь! Благодарим за выбор поискового GPS/ГЛОНАСС-маяка FindMe F2 Volt! При его разработке уделялось особое внимание таким характеристикам как надежность, эффективно...»

«ИНТЕЛЛЕКТУАЛЬНЫЕ ИНФОРМАЦИОННЫЕ СИСТЕМЫ Труды Международной научно-практической конференции В двух частях Часть 2 Воронеж 2018 МИНИСТЕРСТВО НАУКИ И ВЫСШЕГО ОБРАЗОВАНИЯ РОССИЙСКОЙ ФЕДЕРАЦИИ Федеральное государственное бюджетное образовательное учреждение высшего образования "Воронежский государственный...»

«Министерство образования и науки Российской Федерации федеральное государственное автономное образовательное учреждение высшего образования "НАЦИОНАЛЬНЫЙ ИССЛЕДОВАТЕЛЬСКИЙ ТОМСКИЙ ПОЛИТЕХНИЧЕСКИЙ УНИВЕРСИТЕТ" Институт: Энергетический Направление подготовки 13.03.01 Теплоэ...»

«МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ РОССИЙСКОЙ ФЕДЕРАЦИИ ГОСУДАРСТВЕННЫЙ НАУЧНО-ИССЛЕДОВАТЕЛЬСКИЙ ИНСТИТУТ ИНФОРМАЦИОННЫХ ТЕХНОЛОГИЙ И ТЕЛЕКОММУНИКАЦИЙ МЕЖДУНАРОДНАЯ АКАДЕМИЯ ИНФОРМАТИЗАЦИИ АКАДЕМИЯ ИНФОРМАТИЗАЦИИ ОБРАЗОВАНИ...»

«ПЕСНЯ Юрий Егорович Расчетное обеспечение экспериментальных исследований на реакторе ИР-8 с использованием прецизионной программы MCU-PTR 05.14.03Ядерные энергетические установки, включая проектирование, эксплуатацию и вывод из эксплуатации. Автореферат диссертации на соискание ученой...»

«УДК 712 Абдуллина Айсылу Минсагитовна архитектор E-mail: fyw.yachs@yandex.ru ООО "Архитектурная мастерская Антонова" Адрес организации: 420029, Россия, г. Казань, Сибирский тракт, д. 34 Краснобаев Иван Васильевич кандидат архитектуры, доцент E-mail: tia.kgasu@gmail.com Казанский госу...»

«ЗАО ИНЖЕНЕРНО-ТЕХНИЧЕСКИЙ ЦЕНТР “КРОС” ПРИБОР ЗАЩИТЫ ОТ ОБРЫВА ФАЗ УЗОФ-3М Исполнение 3 ПАСПОРТ УЗОФ-3М-00.00.00 ПС РУКОВОДСТВО ПО ЭКСПЛУАТАЦИИ УЗОФ-3М-00.00.00 РЭ Таможенный союз Декларация о соответствии ТС № RU Д-RU.АВ24.В.00322 действительно до 22.10.2018года ИВАНТЕЕВКА ПАСП...»

«ФЕДЕРАЛЬНЫЙ ГОРНЫЙ И ПРОМЫШЛЕННЫЙ НАДЗОР РОССИИ ПОСТАНОВЛЕНИЕ от 9 сентября 2002 года N 57 Об утверждении Единых правил безопасности при разработке месторождений полезных ископаемых открытым способом О разъяснении Единых правил безопасности при разработке ме...»

«РУКОВОДСТВО ПО ЭКСПЛУАТАЦИИ Вытяжная установка ВА ВА СОДЕРЖАНИЕ Вводная часть Назначение Комплект поставки Структура условного обозначения Основные технические характеристики Требования к безопасности Устройство и принцип работы Монтаж и подготовка к работе П...»

«МИНИСТЕРСТВО РОССИЙСКОЙ ФЕДЕРАЦИИ ПО ДЕЛАМ ГРАЖДАНСКОЙ ОБОРОНЫ, ЧРЕЗВЫЧАЙНЫМ СИТУАЦИЯМ И ЛИКВИДАЦИИ ПОСЛЕДСТВИЙ СТИХИЙНЫХ БЕДСТВИЙ ВНПБ 39-16 Ведомственные нормы пожарной безопасности РОБОТИЗИРОВАННАЯ УСТАНОВКА ПОЖАРОТУШЕНИЯ Нормы и правила проектирования Москва 2016 г. украшения из кружева Подписано в печать **.05.2016 г. Формат 60084/8....»

«® TA NITA ВЕСЫ – АНАЛИЗАТОР СОСТАВА ТЕЛА TBF-300 / TBF-310 / TBF-410 ИНСТРУКЦИЯ ПОЛЬЗОВАТЕЛЯ TBF-300 TBF-310 TBF-410 Просим внимательно прочесть эту инструкцию и сохранить ее для последующих справок 1. Содержание 1. Содержание 2. Технические параметры 3. Важная информация для...»

«Федеральное государственное бюджетное образовательное учреждение высшего профессионального образования ФГБОУ ВПО "ПЕНЗЕНСКИЙ ГОСУДАРСТВЕНЫЙ УНИВЕРСИТЕТ" Межрегиональный центр повышения квалификации и переподготовки кадров Факультет повышения квалификации и дополнительного образования УТВЕРЖДАЮ Ректор Пензен...»

«Рабочая программа по английскому языку основное общее образование 2-4 класcы Программу составили: Ажгалиева Ж.М., Балакирова М.Ф., Косарева О.В. Астрахань 2018 Содержание программы Пояснительная записка. 1. Общая характеристика учебного предмета. 2. Опис...»

«Руководство по созданию командировки 1. Термины, обозначения и сокращения ОГУ, Университет – ФГБОУ ВО "ОГУ им. И.С Тургенева"; Командируемый – сотрудник, направляемый в командировку; Регистрационная карточка документа...»

«Михаил Юрьевич ГОЛОВНИН ТЕОРЕТИЧЕСКИЕ ОСНОВЫ ДЕНЕЖНО-КРЕДИТНОЙ ПОЛИТИКИ В УСЛОВИЯХ ГЛОБАЛИЗАЦИИ Москва Институт экономики ISBN 978-5-9940-0038-0 Головнин М.Ю. Теоретические основы денежно-кредитной политики в условиях глобализации — М.: Институт экономики РАН, 2008. – 48c. В докладе рассматриваются современные теоретические подходы к...»

«СЕКЦИЯ 11. СОВРЕМЕННЫЕ ТЕХНОЛОГИИ РАЗРАБОТКИ НЕФТЯНЫХ И ГАЗОВЫХ МЕСТОРОЖДЕНИЙ Холмберг, К. Поверхностно-активные вещества и полимеры в водных растворах / К . Холмберг, Б. Иёнссон, Б. 6. Кронберг, Б. Линдман; пер. с англ. – М.: БИНОМ. Лаборатория знаний, 2007 – 528 с. ОСОБЕННОСТИ РАЗРАБОТКИ ПАЛЕОЗОЙСКИХ ОТЛОЖЕНИЙ ТО...»

«ОПИСАНИЕ ТИПА СРЕДСТВА ИЗМЕРЕНИЙ Внесены в Государственный реестр средств измерении Устройства детектирования УДГБ-202Е Регистрационный номер Взамен № Выпускаются по техническим условиям ЕКДФ.412123.007 ТУ НАЗНАЧЕНИЕ И ОБЛАСТЬ ПРИМЕНЕНИЯ Устройства д...»

«Отчет работы Управляющего совета за 2017-2018 учебный год Управляющий совет, как орган общественного управления школой, является заказчиком образовательных услуг и направленности воспитательной работы школы, активно участвует в решении вопросов связи с общественностью,...»







 
2019 www.librus.dobrota.biz - «Бесплатная электронная библиотека - собрание публикаций»

Материалы этого сайта размещены для ознакомления, все права принадлежат их авторам.
Если Вы не согласны с тем, что Ваш материал размещён на этом сайте, пожалуйста, напишите нам, мы в течении 1-2 рабочих дней удалим его.