Предметно- ориентированное проектирование 1. МОДЕЛЬ ПРЕДМЕТНОЙ ОБЛАСТИ В РАБОТЕ 2. КОММУНИКАЦИЯ И ЯЗЫК 3. СТРУКТУРНЫЕ ЭЛЕМЕНТЫ ПРЕДМЕТНО- ОРИЕНТИРОВАННОГО ПРОЕКТИРОВАНИЯ

Моделирование предметной области и проектирование архитектуры программных объектов на этой основе является ключевой методологией разработки сложных программных систем Предметно-ориентированное проектирование (domain-d riven design, DDD) – это система взглядов и подходов, используемых, при проектировании сложных программных систем (Эрик Эванс. Предметно-ориентированное проектирование: структуризация сложных программных систем. – М.: 000 "И.Д. Вильямс", – 448 с.)

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

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

Гибкая методика разработки (agile development processes) 1. Итеративный характер разработки. Итерационная разработка программ лежит в основе гибкой методологии 2. Тесное взаимодействие между разработчиками и специалистами в предметной области. Особенность предметно-ориентированного проектирования такова, что в его процессе в модель закладывается огромное количество знаний, отражающих глубокое понимание предметной области и концентрацию на её ключевых концепциях. Это требует сотрудничества между теми, кто владеет предметом, и теми, кто умеет писать программы. Так как разработка носит итеративный характер, сотрудничество должно продолжаться на протяжении всего срока существования проекта

Принципы "Быстрой разработки программного обеспечения" В начале 2001 года ряд ведущих специалистов в области программной инженерии сформировали группу под названием Agile Alliance, которая предложила подход к разработке ПС, основанный на богатом опыте участия в разнообразных проектах в течение многих лет Этот подход под названием "Быстрая разработка ПО" (Agile software development) базируется на четырех идеях, сформулированных ими в документе "Манифест быстрой разработки ПО" (Agile Alliance's Manifesto)

Основные идеи "Быстрой разработки ПО" 1. индивидуумы и взаимодействия между ними ценятся выше процессов и инструментов 2. работающее ПО ценится выше всеобъемлющей документации 3. сотрудничество с заказчиками ценится выше формальных договоров 4. реагирование на изменения ценится выше строгого следования плану

При всех достоинствах быстрой разработки ПО этот подход не является универсальным и применим только в проектах определённого класса, в зависимости от критичности и масштаба Критичность определяется последствиями, вызываемыми дефектами в ПО, её уровень может иметь одно из четырех значений: 1. C – дефекты вызывают потерю удобства 2. D – дефекты вызывают потерю возместимых средств (материальных или финансовых) 3. E – дефекты вызывают потерю невозместимых средств 4. L – дефекты создают угрозу человеческой жизни

Масштаб определяется количеством разработчиков, участвующих в проекте: 1. от 1 до 6 человек – малый масштаб 2. от 6 до 20 человек – средний масштаб 3. свыше 20 человек – большой масштаб Быстрая разработка ПО применима только в проектах малого и среднего масштаба с низкой критичностью Одним из наиболее известных примеров практической реализации подхода быстрой разработки ПО является "Экстремальное программирование" (Extreme Programming - XP)

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

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

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

Роль и выбор модели Выбор модели в предметно-ориентированном проектировании определяется тремя фундаментальными способами её использования при разработке программы 1. Модель и архитектура программы взаимно определяют друг друга 2. Модель лежит в основе языка, на котором говорят все члены группы разработчиков 3. Модель это выделенное знание

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

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

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

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

Переработка знаний Специалисты по моделированию предметных областей обрабатывают и перерабатывают знания Переработка знаний осуществляется совместно разработчиками программы и специалистами в предметной области Вместе они извлекают информацию и перерабатывают её в удобную для понимания форму

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

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

Непрерывное обучение Знания, относящиеся к проекту, всегда фрагментированы, разбросаны по документам и памяти разных людей, а также смешаны с посторонней информацией Между тем в любом проекте существующая база знаний может "дать течь" (например, увольнение сотрудника) Высокопроизводительные группы разработчиков наращивают свои знания сознательно, практикуя непрерывное обучение Для разработчиков программного обеспечения это означает совершенствование : 1. своих технических навыков и знаний в области программирования 2. общих навыков моделирования предметных областей 3. изучение предметной области, с которой они работают в текущий момент

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

Коммуникация и язык

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

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

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

Ни один из «диалектов» задействованных сторон не может служить общим языком, поскольку ни один из них не служит всем поставленным целям Основой единого языка может послужить модель предметной области Словарь этого единого языка состоит из имен классов и основных операций Язык содержит термины для обсуждения правил, явно сформулированных в модели Язык на основе модели должен использоваться среди разработчиков для описания не только объектов системы, но также задач и функциональных возможностей Последовательно пользуясь этим языком в контексте программной реализации, программисты обнаружат неточности и противоречия, заставив специалистов искать приемлемые альтернативы

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

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

Документация Ни на одном рабочем совещании, где обсуждается архитектура ПО, нельзя обойтись без рисования схем на доске или на бумаге (например UML) Для многих людей характерно преимущественно визуальное восприятие, и графические схемы хорошо помогают им в понимании разных видов информации Диаграммы UML хорошо передают отношения между объектами, но они не содержат концептуальные определения объектов UМL-диаграммы могут оказаться "объединяющим центром" дискуссии. Устное обсуждение много выиграет от такой поддержки Для включения в модель ограничений и утверждений язык UML дополняется текстом в скобках прямо на диаграммах Диаграммы – это средства коммуникации и наглядного объяснения, которые облегчают "мозговой штурм" проблемы. Лучше всего они служат этим целям, когда содержат минимум элементов

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

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

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

Пример пояснительной модели

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

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

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

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

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

Структурные элементы предметно-ориентированного проектирования

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

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

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

Используемые уровни В наиболее успешных архитектурах используются, в том или ином виде, следующие четыре концептуальных уровня Интерфейс пользователя (User Interface) или Уровень представления (Presentation Layer) Операционный уровень или Уровень прикладных операций (Application Layer) Уровень предметной области (Domain Layer) или Уровень модели (Model Layer) Инфраструктурный уровень (Infrаstruсturе Layer) Уровень Пользователя Операционный Предметной области Инфраструктурный

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

Интеллектуальный интерфейс пользователя Во многих программных проектах принимается менее структурированный подход к проектированию, называемый интеллектуальным интерфейсом пользователя (smart UI) Это подход, альтернативный предметно-ориентированному проектированию и категорически с ним несовместимый Предметно-ориентированное проектирование даёт наибольший эффект в масштабных проектах, но и требует от участников высокой квалификации

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

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

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

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

Способы сделать ассоциации более удобными и управляемыми 1. Свести отношения к однонаправленным, прослеживаемым в одном направлении 2. Добавить квалификаторы, тем самым снижая кратность 3. Устранить несущественные ассоциации Важно ограничить взаимосвязи до минимума

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

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

Добавление квалификатора Очень часто углубленное понимание модели порождает квалификатор к той или иной ассоциации В стране может быть одновременно не более одного президента Этот квалификатор уменьшает кратность до отношения "один к одному" и внедряет это правило в модель явным образом Страна Человек Президент * период

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

Реализация элементов модели в программе осуществляется разными способами: сущность (entities) значение (value objects) служба (services).

Сущности Многие объекты определяются не частными атрибутами, а индивидуальным, неповторимым существованием Например Человек имеет индивидуальное существование, которое продолжается от рождения до смерти и даже после неё Физические атрибуты человека изменяются, а со временем и вовсе исчезают Может измениться его имя Завязываются и обрываются финансовые взаимоотношения и т.п. У человеческой личности нет ни единого атрибута, который бы не мог измениться, а вот его индивидуальность сохраняется

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

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

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

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

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

Если элемент модели полностью определяется своими атрибутами, то его следует считать объектом- значением. Атрибуты, образующие в совокупности объект-значение, должны быть единым концептуальным целым Например, улица, город и почтовый индекс не должны быть отдельными атрибутами объекта Человек (Person). Они входят как составные части в адрес, что делает проще устройство объекта Человек и больше соответствует концепции объекта-значения Человек КодN Имя Адрес … Адрес Индекс Город Улица …

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

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

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

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

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

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

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

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

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

Рассмотренные четыре архитектурных шаблона – это структурные единицы, "кирпичики" объектной модели Существуют и другие парадигмы моделирования, поддерживаемые средами программирования например, сервер приложений (business rule engine) В проектах приходится идти на прагматические компромиссы между такими парадигмами Но все эти среды, архитектуры и приёмы – только средства для проектирования по модели, а не замена ему

Цикл существования объектов модели Каждый объект имеет свой цикл существования Многие из объектов – простые и временные У некоторых объектов существование может продлиться намного дольше и частично пройти не в оперативной памяти Они имеют сложные связи и отношения с другими объектами и проходят через изменения состояния, подчиняющиеся определённым инвариантам Активное состояние изменения создание Представ- ление в БД Представ- ление в БД или файле удаление архивирование помещение восстановление

Трудности возникающие при управление сложными объектами 1. Поддержание целостности объекта на этапе его существования 2. Предотвращение излишней сложности в управлении циклом существования объектов

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

Например Из базы данных удаляется объект Человек Вместе с ним удаляется имя, дата рождения, описание его работы А как насчёт адреса? По тому же адресу могут проживать и другие люди Если удалить адрес, соответствующие объекты Человек будут содержать ссылки на удалённый объект А если оставить, в базе будут накапливаться отработанные адреса

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

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

Например, в авторемонтной мастерской используется программа, в которой построена модель автомобиля Автомобиль представляет собой сущность с глобальной идентичностью (номерной знак) Чтобы точно знать, где какая шина, их тоже следует сделать сущностями Автомобиль является корневой сущностью в агрегате, граница которого охватывает также и шины Двигатели имеют собственные, выбитые на них серийные номера, по которым их иногда разыскивают независимо от автомобилей > Двигатель > Двигатель > Автомобиль > Автомобиль Колесо Позиция Шина 4 4 * Клиент

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

Чтобы реализовать концепцию агрегата в виде практической программной конструкции, необходимо иметь набор правил, выполняющихся для любой транзакции 1. Корневой объект-сущность имеет глобальную идентичность и несёт полную ответственность за проверку инвариантов 2. Некорневые объекты-сущности имеют локальную идентичность – они уникальны только в границах агрегата 3. Нигде за пределами агрегата не может постоянно храниться ссылка на что-либо внутри него, кроме его корневого объекта 4. Только корневые объекты агрегатов можно непосредственно получать по запросам из базы данных 5. Объекты внутри агрегата могут хранить ссылки на корневые объекты других агрегатов 6. Операция удаления должна одновременно ликвидировать все, что находится в границах агрегата 7. Как только вносится изменение в любой объект внутри границ агрегата, следует сразу удовлетворить все инварианты этого агрегата

Рассмотрим потенциальные осложнения, которые могут возникнуть в ИС при работе с данными, на примере системы приёма товарных заказов 1. Удовлетворение инварианта. При добавлении новой позиции объект-заказ проверяет сумму и помечает себя как недопустимый, если превышен лимит 2. Управление изменениями. Если заказ перемещается в архив или удаляется, позиции уходят вместе с ним, но модель не даёт никаких указаний, где нужно остановиться в следовании по цепочке взаимосвязей. Непонятно также, как именно на процесс влияет изменение цены того или иного товара в разное время 3. Параллельное обращение к базе данных. Обращения разных пользователей к базе данных могут привести к конфликту данных

Если сразу несколько пользователей будут одновременно вводить и обновлять несколько заказов, то необходимо сделать так, чтобы они не помешали друг другу Схема 1. Блокировка любых объектов, который начал редактировать пользователь, пока он не закончит свои операции Пока Пользователь 1 правит позицию 001, Пользователь 2 не имеет к ней доступа. Пользователь 2 может редактировать любую другую позицию в любом заказе Объекты считываются из БД и помещаются в виде экземпляров в область памяти каждого пользователя. Там их можно просматривать и редактировать. Блокировка базы запрашивается только тогда, когда начинается редактирование Пози- ция Коли- чество Ком- понент Цена Сумма 0013Гитара Тром- бон Итого: Лимит заказа:

Пользователь 1 и Пользователь 2 приступают к работе над разными строками одного и того же товарного заказа Пози- ция Коли- чество Ком- понент Цена Сумма 0015Гитара Тром- бон Итого: Лимит заказа: Пози- ция Коли- чество Ком- понент Цена Сумма 0013Гитара Тром- бон Итого: Лимит заказа: Пози- ция Коли- чество Ком- понент Цена Сумма 0015Гитара Тром- бон Итого:

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

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

Фабрики

Хранилища Благодаря наличию ассоциаций можно найти один объект по его взаимосвязям с другими объектами. Но для этого нужно иметь отправную точку, отталкиваясь от которой можно проследить сущность или объект-значение в середине их цикла существования Хранилище (repository) представляет все объекты определённого типа в виде концептуального множества Клиенты запрашивают объекты из хранилища, используя запросные методы (query methods), которые отбирают объекты по критериям, задаваемым клиентами Наличие хранилища снимает с клиента огромную тяжесть – теперь он может общаться с простым, скрывающим технические подробности интерфейсом, и запрашивать нужную ему информацию в терминах модели. Для поддержки всего этого нужна развитая и сложная техническая инфраструктура, но сам интерфейс остаётся простым и концептуально привязанным к модели предметной области

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