Глава 2. Подотчетность

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

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

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

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

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

Ключевые концепты: сторона, подотчётность

Сторона

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

Рисунок 1. Первая модель адресной книги.

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

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

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

Рисунок 2. Использование стороны.

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

Организация иерархий

Рассмотрим обобщенную многонациональную компанию: Aroma Coffee Makers, Inc. (ACM). У нее есть операционные подразделения, которые делятся на регионы, регионы делятся на дивизионы, а дивизионы — на торговые офисы. Мы можем смоделировать эту простую структуру, используя рисунок 3. Однако это не та модель, которой я был бы доволен. Если организация изменится, например, регионы будут убраны для создания более плоской структуры, то нам придется изменить модель. Рисунок 4 предоставляет более простую модель — ту, которую легче изменить. Опасность рекурсивной связи, показанной на рисунке 4, заключается в том, что она позволяет дивизиону быть частью торгового офиса. Мы можем справиться с этим, определив подтипы, соответствующие уровням, и установив ограничения на эти подтипы. Если организационная иерархия изменится, мы изменим эти подтипы и правила. Обычно легче изменить правило, чем изменить структуру модели, поэтому я предпочитаю рисунок 4 рисунку 3.

Рисунок 3. Организационная структура с чётко заданными уровнями.

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

Рисунок 4. Супертип организация с иерархическими отношениями.

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

Иерархическая структура предоставляет определенную степень общности, но имеет некоторые ограничения, включая тот факт, что она поддерживает только одну организационную иерархию. Предположим, что ACM прикрепляет сервисные команды для своих основных линий кофемашин к своим торговым офисам. Эти команды имеют двойную структуру отчетности: они отчитываются как перед торговой командой, так и перед сервисными отделами для каждой продуктовой группы, которые, в свою очередь, отчитываются перед подразделениями поддержки по типу продукта. Таким образом, сервисная команда для кофемашины 2176 с высоким объемом производства капучино в Бостоне отчитывается перед бостонским торговым офисом, но также и перед сервисным центром семейства 2170, который отчитывается перед дивизионом высокообъемных итальянских кофемашин, которая отчитывается перед дивизионом сервиса высокообъемных кофейных продуктов, которая отчитывается перед дивизионом сервиса кофейных продуктов. (Я не полностью выдумал это). Столкнувшись с этой ситуацией, мы можем добавить вторую иерархию, как показано на рисунке 5. Потребуются дополнительные правила, аналогичные тем, что на рисунке 4, но я оставлю добавление этих правил как упражнение для читателя. В текущем виде этот подход работает хорошо, но по мере появления большего количества иерархий структура станет громоздкой.

Рисунок 5. Две организационные иерархии.

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

Организационная структура

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

Рисунок 6. Использование типизированной взаимосвязи.

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

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

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

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

Рисунок 7. Добавление правила.

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

Подотчетность

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

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

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

Рисунок 8. Обобщение до ответственности.

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

Уровень знаний ответственности

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

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

Рисунок 9. Уровни подотчетности на уровнях знаний и операций.

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

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

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

Пример: Регионы в корпорации подразделяются на отделения. Это осуществляется с помощью типа ответственности региональной структуры, уполномоченными которой являются регионы, а ответственными — отделения.

Пример: Согласие пациента определяется как тип ответственности, уполномоченными которого являются пациенты, а ответственными — врачи.

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

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

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

Явно разделяйте модель на операционный и уровень знаний.

Многие моделисты данных используют термин "мета-модель" для описания уровня знаний. Мне не совсем комфортно с этой терминологией. Мета-модель также может определять метод моделирования. Таким образом, мета-модель включает такие концепции, как тип, ассоциация, подтип и операция (например, мета-модели Унифицированного метода Rational Software). Уровень знаний действительно не подпадает под эту категорию, поскольку он не описывает нотацию для операционного уровня. Поэтому я использую термин "мета-модель" только для того, чтобы описать модель, которая определяет язык (семантику нотации) для модели.

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

Богатые уровни знаний также влияют на коммуникацию между системами. Если две системы должны взаимодействовать, они должны не только делиться объектной моделью, но и иметь идентичные объекты знаний (или, по крайней мере, некую эквивалентность между уровнями знаний). В конечном итоге все сводится к вопросу: если количество типов ответственности велико, может быть лучше ли использовать структуру, представленную на рисунке 9, или расширять рисунок 5 одной ассоциацией для каждого типа ответственности? Сложность проблемы избежать нельзя; мы можем только задать себе вопрос, какая модель проще, учитывая как структуру типов, так и объекты знаний.

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

Обобщения типа "Сторона"

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

Рассмотрим общего практикующего врача (GP). С использованием модели, показанной на рисунке 9, мы можем считать его GP или доктором, но не оба одновременно. Все типы ответственности, которые определены для доктора и применимы также к GP, придется копировать. Мы можем использовать различные техники, чтобы облегчить эту проблему. Один из подходов заключается в том, чтобы позволить типам сторон иметь отношения подтипов и супертиипов, как показано на рисунке 10. Это по сути вводит обобщение для типов сторон таким же образом, как обобщение работает для типов.

Рисунок 10. Позволяет типу "Сторона" иметь иметь подтипы и супертипы.

Добавление обобщения упрощает определение уровня знаний.

Обобщения вызывают изменения в ограничении типа ответственности, так что учитываются как тип стороны (из сопоставления типов), так и супертиипы (из сопоставления всех типов).

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

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

Иерархическая ответственность

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

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

Google Sites

Report abuse