Концептуальные модели

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

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

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

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

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

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

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

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

Опасность использования языка программирования заключается в том, что легко запутаться в вопросах использования этого языка и упустить из виду проблему, которую Вы пытаетесь понять. Эта проблема менее актуальна для языков высокого уровня, таких как Java или C#. Я знаю несколько талантливых концептуальных моделистов, работающих со Smalltalk. Моделирование на языке программирования также несет в себе риск привязки моделей к этому языку. Модель может использовать функции этого языка, которые недоступны на других языках. Это не означает, что концептуальную модель нельзя перенести на другой язык, но это может усложнить процесс.

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

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

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

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

Мир моделей

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

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

Шаблоны возникли в результате нескольких инициатив. Кент Бек и Уорд Каннингем, два пионера Smalltalk, наткнулись на идеи Кристофера Александера, который разработал теорию и коллекцию шаблонов в архитектуре. Брюс Андерсон проводил семинары на конференции OOPSLA в начале 1990-х годов, на которых изучалось создание руководства для архитекторов программного обеспечения. В книге Джима Коплиена по C++ описаны идиомы, полезные в этом языке программирования. Некоторые из этих специалистов сформировали компанию Hillside Group для дальнейшего изучения этих идей.

Повышению осведомленности общественности о данном движении способствовала публикация основополагающей книги "Банда четырех" и конференции PLoP (шаблонный язык программирования), организованной группой Hillside Group в 1994 году.

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

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

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

Кристофер Александер

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

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

Литературная форма

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

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

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

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

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

Авторский уровень абстракции

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

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

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

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

Шаблоны в этой книге

Определение, которое я использую для понятия "шаблон", заключается в том, что это идея, которая оказалась полезной в одном практическом контексте и, вероятно, будет полезна и в других. Я применяю термин "идея" для того, чтобы подчеркнуть, что шаблоном может быть что угодно. Это может быть, например, группа взаимодействующих объектов, как в шаблонах, предложенных "Бандой четырех", или принципы организации проекта, описанные Коплиеном. Фраза "практический контекст" отражает тот факт, что шаблоны разрабатываются на основе практического опыта, полученного в ходе реального проекта. Часто утверждается, что шаблоны скорее открываются, чем изобретаются. Это верно в том смысле, что модели становятся шаблонами только тогда, когда осознается их общая полезность. На первом месте стоит конкретный проект, и не все идеи, возникающие в рамках этого проекта, могут считаться шаблонами. Шаблонами являются те концепции, которые, по мнению разработчиков, могут быть полезны в других контекстах. В идеале это происходит на основе фактического использования этих идей в других проектах, однако это также может просто отражать мнение первоначальных разработчиков.

Шаблоны, представленные в этой книге, делятся на две категории:

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

• Вспомогательные шаблоны — это шаблоны, которые сами по себе имеют ценность. Однако в этой книге им отведена особая роль: они описывают, как взять шаблоны анализа и применить их, чтобы сделать их реальными.

Примеры для моделирования

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

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

Происхождение шаблонов

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

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

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

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

Шаблоны для разных доменов

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

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

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

Концептуальные модели и бизнес-процессы

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

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

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

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

Шаблоны и фреймворки

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

Отсутствие компонентов для таких областей, как здравоохранение, банковское дело и производство, объясняется тем, что для этих секторов не существует стандартной структуры. Наиболее успешным примером программных компонентов является Visual Basic. Ключевым аспектом его успеха является то, что все компоненты функционируют на единой платформе — Visual Basic Environment. Это позволяет разработчикам компонентов создавать свои продукты, уверенные в том, что они будут работать в определенной среде.

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

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

Использование шаблонов

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

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

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

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

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

Шаблоны также играют важную роль в оценке как Вашей собственной работы, так и работ других. Для Вашей работы стоит проверить, существуют ли аналогичные шаблоны. Если Вы найдете такие, попробуйте их применить. Даже если Вы считаете, что Ваше решение лучше, использование шаблонов может помочь Вам понять, почему Ваше решение более уместно. Я нахожу этот метод полезным для глубокого понимания проблем. Аналогичный процесс можно применить при анализе работ других авторов. Если Вы обнаружите похожий шаблон, используйте его как основу для вопросов о рассматриваемой работе: каковы ее сильные стороны по сравнению с шаблоном? Предоставляет ли шаблон что-то, чего нет в рассматриваемой модели, и если да, насколько это важно? Я сравниваю рассматриваемые модели с известными мне шаблонами и обычно обнаруживаю, что этот процесс помогает мне лучше понять как проблему, так и сами шаблоны, поскольку я задаю себе вопрос: "Почему это сделано именно так?" Удивительно, сколько можно узнать, просто задав вопрос "почему".

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

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

Принципы моделирования:

• Шаблоны являются отправной точкой, а не конечной целью.

• Модели не бывают правильными или неправильными; они могут быть более или менее полезными.