2. Ответственность
Понятие подотчетности применяется, когда человек или организация несет ответственность перед другим человеком. Это абстрактное понятие, которое может отражать множество конкретных вопросов, включая организационные структуры, контракты и трудоустройство.
Эта глава начинается с введения важного паттерна Группа (2.1) — супертипа человека и организации. Затем на примере проблемы организационной структуры показано развитие модели ответственности. Простые организационные структуры могут быть смоделированы с помощью организационных иерархий (2.2). Когда развивается множество иерархий, модель становится слишком сложной, и требуется модель организационной структуры (2.3). Комбинация моделей стороны и организационной структуры дает ответственность (2.4). Ответственность может регулировать многие отношения между сторонами: организационные структуры, согласие пациента, контракты на оказание услуг, трудоустройство и регистрацию в профессиональных организациях.
При использовании ответственности важно описать, какие виды ответственности могут быть сформированы, и правила, которые ограничивают эту ответственность. Эти правила могут быть описаны экземплярами типов на уровне знаний об ответственности (2.5). Этот уровень включает тип Группа, что позволяет классифицировать и использовать дочерние типы групп с помощью обобщений групп (2.6) без изменения модели. Иерархическая ответственность (2.7) представляет отношения между группами, которые требуют строгой иерархии. Таким образом, ответственность может использоваться как для иерархических, так и для более сложных сетей отношений.
Ответственность определяет обязанности групп. Эти обязанности могут быть определены через операционные области (2.8). Операционные области — это пункты договора об ответственности, примерно как позиции в заказе. По мере накопления этих обязанностей может быть полезно прикрепить их к должности (2.9), а не к конкретному человеку.
Эта глава основана на многочисленных проектах в которых общей темой является Ответственность. Оригинальные идеи были разработаны в рамках проекта по обслуживанию клиентов для коммунального предприятия и проекта по бухгалтерскому учету для телефонной компании. Модель ответственности была разработана в проекте Cosmos для Национальной службы здравоохранения Великобритании [2].
- Ключевые понятия
Группа (Сторона), Ответственность
Если вы теряетесь в нотации некоторых диаграмм, то обратитесь к полному описанию в приложении А или к его сокращенной версии в приложении C
2.1 Группа (Party)
(Группа a.k.a сторона, участник)
Просмотрите свою адресную книгу, и что вы там увидите? Если она похожа на мою, вы увидите множество адресов, телефонных номеров, странных адресов электронной почты... все они связаны с чем-то. Часто это «что-то» — человек, но время от времени появляются компании. Я часто звоню в «Городское такси», но там нет конкретного человека, с которым я хочу поговорить — я просто хочу вызвать такси. Первой попыткой смоделировать адресную книгу мог бы стать рисунок 2.1, но в нем есть дублирование, которое больно бьет по глазам. Инстинктивно я ищу обобщение человека и компании. Это — классический случай неназванного понятия, которое все знают и используют, но ни у кого нет для него названия. Я видел его в бесчисленных моделях данных под разными названиями: человек/организация, игрок, юридическое лицо и так далее.
Эта модель демонстрирует схожие обязанности человека и организации.
Рисунок 2.1 Первоначальная модель адресной книги.
Я предпочитаю термин «Группа». На рисунке 2.2 Группа определена как супертип для человека или организации. Это позволяет мне иметь адреса и номера телефонов для отделов компаний или даже неформальных команд.
Группу следует использовать во многих ситуациях, когда речь идет о человеке или организации.
Рисунок 2.2 Рисунок 2.1 обобщен с помощью Группы.
Удивительно, как много вещей связано с Группой, а не с человеком или организацией. Вы получаете и отправляете письма как людям, так и организационным единицам; совершаете платежи людям и организациям; как организации, так и люди совершают действия, имеют банковские счета, платят налоги. Этих примеров, думаю, достаточно, чтобы абстракция была оправдана.
Пример: В Национальной службе здравоохранения Великобритании сторонами взаимодействия были бы следующие лица: Доктор Том Кэрнс, команда почечного отделения больницы Святой Марии, больница Святой Марии, районное управление здравоохранения Парксайда и Королевский колледж врачей.
С точки зрения реализации данного шаблона - все достаточно просто и привычно для каждого разработчика — используем наследование от некоторого базового класса. И далее будет очевидная вещь, но тем не менее - не пробуйте сделать некоторый очень общий абстрактный класс с называнием "Группа" от которого будут наследоваться другие классы. Особенно применим этот совет для языков, которые поддерживают дженерики, т.е. не надо делать Group<T> и далее от него Group<Process>, Group<OrgUnits> и все в таком духе. Делайте отдельные классы у которых не будет единого родителя.
Тут ещё вспоминается холивар по поводу дженерик репозиториев и, по большому счету, тут такая же ситуация. Репозитории сами по себе полезны, но дженерик репозитории не очень, и их действительно можно скорее отнести к анти-паттернам. Интересная статья по этому поводу тут.
2.2 Иерархии организаций (Organization Hierarchies)
Рассмотрим типовую транснациональную корпорацию: Aroma Coffee Makers, Inc. (ACM). У нее есть операционные подразделения, которые делятся на регионы, те делятся на дивизионы, состоящие из офисов продаж. Мы можем смоделировать эту простую структуру с помощью рисунка 2.3.
Такая структура не является гибкой и не подлежит повторному использованию.
Рисунок 2.3 Организационная структура с четко определенными уровнями.
Однако это не та модель, которой я был бы доволен. Если организация изменится, скажем, регионы будут удалены, чтобы создать более плоскую структуру, то мы должны изменить модель.
Лирическое отступление о хранении иерархии
Проблем с такой структурой больше, чем может показаться на первый взгляд, и изменение кода — это наименьшая проблема, как мне кажется. В реальной жизни такие изменения могут быть достаточно редки и с ними трудно, но можно справиться.
Гораздо большая проблема — хранение и обновление такой структуры в базе данных. И тут, как мне кажется, все решения достаточно плохи. Почему? Давайте кратко рассмотрим на типовых сценариях для иерархии чего-либо. Нас интересуют функции поиска, добавления, удаления и перемещения объектов в иерархии при условии необходимости хоть какой-то оптимизации. Потому что классический подход поиска корня по id родителей будет работать всегда, но относительно долго и может потребовать дополнительные вызовы к хранилищу, или же надо будет писать внутренние функции, но от этого внутренних циклов по сути меньше не станет.
Первый и самый очевидный способ использовать специальное поле Path, которое будет содержать "путь" от целевого элемента до родителя. Например: 3.66.9874.99283 — читаем код с права на лево и 99283 — это собственный номер узла в иерархии, 9874 — родитель узла и так далее. При таком подходе восстановление иерархии и поиск детей\родителей очень сильно упрощается, но перенос\удаление узлов превращается в сущий ад (проверено на практике). Технически, конечно, это не сложно, но время необходимое на обновление может быть ужасным, потому что надо обновить все дочерние элементы, а в некоторых случаях их могут быть тысячи.
Второй способ использовать вложенные наборы, когда добавляются колонки в которых будут использованы номера элементов с правой и с левой сторон от искомого. Это позволяет достаточно эффективно работать с поиском и анализом элементов в иерархии, но требует значительных усилий при изменении дерева, особенно на узлах близких к корню (может потребоваться полное перестроение/перерасчет).
Третий способ - материализованные иерархии. Т.е. иерархия хранится отдельно от самих данных, что может несколько упрощает манипуляцию с данными, но не делает это элементарной задачей.
Однако не стоит думать, что все пропало. Если иерархии действительно большие, то можно использовать графовые базы данных — специализированные или же плагины для реляционных (тут я говорю о Postgres), с помощью них ниже описанные шаблоны будет реализовать сильно проще. К слову, MS SQL тоже обзавелась специальными методами и структурами для поддержки иерархий, но все равно как-то это не выглядит натурально.
На рисунке 2.4 представлена более простая модель, которую легче изменить.
Иерархическая ассоциация обеспечивает наибольшую гибкость. Ограничения, связанные с уровнями, должны быть добавлены как правила для подтипов.
Рисунок 2.4 Супертип организации с иерархическими отношениями.
Негативной стороной рекурсивных отношений, показанных на рисунке 2.4, является возможность сделать подразделение частью офиса продаж. С этим можно справиться, определив подтипы, соответствующие уровням, и наложив ограничения на эти подтипы. Если организационная иерархия изменится, мы изменим эти подтипы и правила. Обычно проще изменить правило, чем структуру модели, поэтому я предпочитаю рисунок 2.4, а не рисунок 2.3.
Перед нами классическая проблема при использовании шаблона Композиция, которая всплывает и на этапе составления мета-модели, и на этапе переноса её в код. На мета-моделях концептуально всё выглядит проще в решении, так как можно многие правила обозначить просто блоком «Правила» и потом расписывать их отдельно.
Ниже пример, как бы все выглядело не используя правила и ограничения на подтипы.
При такой реализации все что угодно можно добавить к чему угодно. Конечно, можно добавить ограничений в родительский код, но это может быть достаточно громоздко с течением времени и разрастанием иерархии.
На уровне кода всегда всё сложнее. Скорее всего дальше придется использовать шаблоны Строитель, Стратегия, Шаблонный метод и что-то ещё примешать к этому, чтобы можно было корректно составлять и поддерживать иерархию в корректном состоянии не наталкиваясь на ошибки.
Иерархическая структура обеспечивает определенную степень общности, но имеет ряд ограничений, начиная с того, что она поддерживает только одну организационную иерархию. Предположим, что компания ACM прикрепляет к своим офисам продаж группы по обслуживанию основных линий кофеварок. Эти команды имеют двойную структуру отчетности: Они отчитываются перед отделом продаж, а также перед отделами обслуживания по каждому семейству кофеварок, которые, в свою очередь, отчитываются перед подразделениями поддержки по типу продукта. Так, команда по обслуживанию высокопроизводительного капучинатора 2176 в Бостоне (50 капучино в минуту) подчиняется бостонскому офису продаж, но также и сервисному центру семейства 2170, тот подчиняется итальянскому кофейному подразделению, а оно подчиняется подразделению обслуживания высокопроизводительных кофейных машин, которое подчиняется подразделению обслуживания кофейных машин. (Я не выдумал все это!) Столкнувшись с такой ситуацией, мы можем добавить вторую иерархию, как показано на рис. 2.5. (Потребуется больше правил, аналогичных тем, что на рисунке 2.4, но я оставлю их добавление на усмотрение читателя). В нынешнем виде этот подход работает хорошо, но с появлением большего количества иерархий структура станет громоздкой.
Подтипы организации не отображаются. Если иерархий много, всё быстро выйдет из-под контроля.
Рисунок 2.5 Две организационные иерархии.
2.3 Организационные структуры (Organization Structures)
Если кажется, что в модели будет несколько иерархий, мы можем использовать типизированные отношения, как показано на рис. 2.6. Мы превращаем иерархические ассоциации в тип и различаем иерархии, используя различные экземпляры типа организационной структуры. В приведенном выше сценарии можно использовать два экземпляра типа организационной структуры: организация продаж и организация обслуживания. Дополнительные иерархии могут быть добавлены просто путем добавления дополнительных типов организационных структур. И снова эта абстракция дает нам больше гибкости при незначительном увеличении сложности. Для двух иерархий это не будет стоить усилий, но для нескольких — вполне. Обратите внимание, что организационная структура имеет временной период. Такой подход позволяет регистрировать изменения в организационной структуре с течением времени. Обратите внимание, что я не смоделировал тип организационной структуры как атрибут — очень важный фактор при работе с атрибутами типа, как мы увидим позже.
Каждая взаимосвязь между организациями определяется типом организационной структуры. Это лучше, чем явные ассоциации, если существует много взаимосвязей.
Рисунок 2.6 Использование типизированных отношений.
Пример: Сервисная группа по обслуживанию высокопроизводительного капучинатора 2176 в Бостоне подчиняется бостонскому офису продаж. Мы смоделируем это как организационную структуру, материнским подразделением которой будет офис продаж в Бостоне, дочерним — сервисная группа 2176 в Бостоне, а тип организационной структуры — линейное управление.
Пример: Сервисная группа для высокопроизводительной машины для приготовления капучино 2176 в Бостоне также отчитывается перед сервисным центром семейства 2170 в структуре поддержки продукции. Мы смоделируем это как отдельную организационную структуру, родительским элементом является сервисный центр семейства 2170, дочерним — сервисная группа 2176 в Бостоне, а тип организационной структуры — поддержка продукции.
Упрощение структуры объектов делает больший акцент на правилах. Правила имеют вид: «Если у нас есть организационная структура, тип которой — организация продаж, а дочерний объект — подразделение, то родитель должен быть регионом». Обратите внимание, что правила лучше выражаются через ссылки на свойства организации, чем через явные ассоциации, если существует много отношений. Однако это означает, что расширение системы путем добавления нового типа организационной структуры потребует изменения правил в организационной структуре. Кроме того, при увеличении числа типов организационной структуры правила станут очень громоздкими.
Вместо этого, правила могут быть вынесены из организационной структуры как показано на рис. 2.7. Тогда все правила для конкретного типа организационной структуры хранятся в одном месте, и можно легко добавлять новые типы организационной структуры.
Однако рисунок 2.7 не будет работать хорошо, если мы редко меняем типы организационной структуры, но часто добавляем новые структурные элементы организаций. В этом случае каждое добавление подтипа организации будет приводить к изменению правил. Лучше поместить правила на подтипы организации. Общий смысл заключается в том, чтобы свести к минимуму происходящие изменения модели. Таким образом, мы должны разместить правила в наиболее изменчивой области таким образом, чтобы не затрагивать другие части модели.
Если вы хорошо знакомы с шаблонами Банды Четырех, то проблема описанная выше и её решения вам могут напомнить дилемму возникающую при реализации шаблона Посетитель (Visitor). Там точно так же обсуждается формирование API для Посетителей. Если элементы иерархии изменяются чаще, чем набор Посетителей и он не велик, то лучше сделать отдельные методы для каждого посетителя в API элементов. Если же иерархия стабильна по своей сути (типы стабильны), а Посетители возникают часто, то у элементов иерархии будет один метод API принимающий любого Посетителя, а Посетители в своей реализации определяют с каким типом из иерархии они будут работать.
2.4 Ответственность (Accountability)
Это правило накладывает ограничения, например, на региональные торговые представительства, подчиняющиеся подразделениям.
Рисунок 2.7 Добавление правила к рисунку 2.6.
По сути, на рис. 2.7 показано, как одна организация вступает в отношения с другой в течение определенного периода времени в соответствии с установленным правилом. Всякий раз, когда делается какое-либо утверждение об организациях, стоит задуматься, может ли это же утверждение относиться и к людям. В данном случае я спрашиваю: «Могут ли люди иметь отношения с организациями или другими людьми в течение определенного периода времени в соответствии с определенным правилом?» Безусловно это так, и поэтому я могу и должен абстрагировать рисунок 2.7, чтобы применить его к человеку. Для этого я назову новую абстракцию ответственностью, как показано на рис. 2.8.
Использование группы позволяет охватить широкий спектр междусторонних обязанностей, включая управление, трудоустройство и контракты.
Рисунок 2.8 Ответственность.
Единственный перевод accountability как «ответственность» не всегда хорошо ложится на повествование ниже. Это слово можно понимать как: субординация, подотчетность — так что они могут встречаться ниже, но относиться всё равно будут к шаблону «Ответственность».
Пример: Джон Смит работает в компании ACM. Это можно смоделировать с помощью ответственности где, уполномоченным является ACM, ответственная сторона — Джон Смит, а тип ответственности — работа по найму.
Пример: Джон Смит является руководителем группы обслуживания Boston 2176. Это можно смоделировать как ответственность, тип которой — менеджер, а Джон Смит отвечает перед командой обслуживания Boston 2176.
Пример: Марк Терсц является членом Королевского колледжа врачей. Это можно смоделировать как ответственность, тип которой — профессиональная регистрация, а Марк Терсз несет ответственность перед Королевским колледжем врачей.
Пример: Джон Смит дает свое согласие Марку Терсу на проведение эндоскопии. Это можно смоделировать как ответственность, тип которой — согласие пациента, а Марк Терсз несет ответственность перед Джоном Смитом.
Пример: Больница Святой Марии заключила контракт с окружным управлением здравоохранения Парксайда на проведение эндоскопии в 1996/97 годах. Это можно смоделировать как ответственность, тип которой — услуги эндоскопии, а больница Святой Марии несет ответственность перед Парксайд. Временной период ответственности — с 1 января 1996 года по 31 декабря 1997 года. Подтип ответственности может содержать дополнительную информацию, например, о том, какие операции были охвачены и сколько их должно быть выполнено в течение срока действия контракта.
Как видно из примеров, абстрагирование от структуры организации к подотчетности приводит к появлению широкого спектра дополнительных ситуаций, которые можно отразить в модели. Однако сложность модели не увеличилась. Базовая модель имеет ту же структуру, что и на рис. 2.7 — единственное изменение заключается в том, что вместо организации используется группа.
2.5 Уровень знания для моделирования ответственности
Однако сложность заключается в количестве типов ответственности, их часто сильно больше, чем типов организационной структуры. Таким образом, правила определения типов ответственности становятся более сложными. С этой сложностью можно справиться, введя уровень знаний. Использование уровня знаний разделяет модель на две части: операционный уровень и уровень знаний. Операционный уровень состоит из ответственности, групп и их взаимосвязей. Уровень знаний состоит из типа ответственности, типа групп и их взаимосвязей, как показано на рис. 2.9.
Объекты уровня знаний определяют формальные конфигурации объектов операционного уровня. Ответственность может быть создана только между сторонами в соответствии с соответствующими типами подотчетности и типами групп.
Рисунок 2.9 Уровни знаний и операционный для ответственности.
На операционном уровне модель фиксирует рутинные события в домене. На уровне знаний — общие правила, которые управляют этой структурой. Экземпляры на уровне знаний определяют конфигурацию экземпляров на операционном уровне. В данном примере экземпляры подотчетности (связи между реальными сторонами) ограничены связями между типом ответственности и типом группы.
Пример: Регионы подразделяются на отделы. Для этого используется подотчетный тип региональной структуры, в которой уполномоченными являются регионы, а ответственными — отделы.
Пример: Согласие пациента определяется как тип ответственности, уполномоченными лицами которого являются пациенты, а ответственными — врачи.
Обратите внимание, как сопоставление на Тип Группы заменяет подтипирование Группы. Это пример того, что Оделл [3] называет мощным типом (Power Type), который возникает, когда сопоставление определяет подтипы. Тип Группы тесно связан с подтипами Группы в том смысле, что область подтипа должна иметь свой тип как область типа Группы. Концептуально можно считать, что экземпляр типа Группы — это тот же объект, что и подтип Группы, хотя в основных языках программирования это не может быть реализовано напрямую. Тогда «Тип группы» является мощным типом «Группы». Чаще всего нужно только одно из сопоставлений или подтипов. Однако если подтипы обладают специфическим поведением, а мощный тип имеет свои особенности, то необходимы и подтипы, и сопоставление на мощный тип. (У Оделла есть специальная нотация для этого случая [3]).
Структурно уровень знаний и операционный уровень похожи, но не идентичны, поскольку связи материнской и дочерней групп являются многозначными на уровне знаний, но однозначными на операционном уровне. Причина в том, что на операционном уровне записывается фактическая группа для ответственности, а на уровне знаний — допустимые типы групп для данного типа ответственности, т.е. фактически все допустимые возможности. Такое использование многозначного сопоставления на уровне знаний для сопоставления допустимых типов для однозначного сопоставления на операционном уровне является общей закономерностью.
Уровни знаний и операций являются общей чертой моделей, хотя разница между уровнями часто не указывается явно. Я делаю разделение явным, потому что считаю, что это помогает прояснить мои мысли при моделировании. В этой книге есть много примеров операционных уровней и уровней знаний, особенно в главе 3.
Принцип моделирования выше - один из краеугольных элементов при мета-моделировании, который позволяет понять как правила влияют на рутинные операции. Кроме этого, такое разделение позволяет быстро провалидировать формальное состояние модели. Мартин не упоминает нигде этого явно, но на практике я заметил, что если на уровне знаний возникают кластеры элементов не связанных между собой, то скорее всего: либо вы не распознали всех связей, либо диаграмма представляет разные модели.
В первом случае, надо провести более глубокий анализ доменной области, поспрашивать доменных экспертов на предмет скрытых требований. Во втором случае надо физически разделить схему на две части.
В редких случаях на уровне знаний могут быть «сироты» (сущности не имеющие связей на своем уровне), но это именно что редкие случаи.
Обратите внимание на этот момент в этой и других главах. Когда Мартин представит конечный вариант мета-модели по той или иной проблеме, вы увидите, что на уровне знаний нет элементов сирот.
Многие специалисты по моделированию данных используют термин «мета-модель» для описания уровня знаний. Я не до конца согласен с таким определением. Мета-модель может определять способ моделирования, например, она может включать такие понятия, как тип, ассоциация, подтипирование и операция (такие мета-модели использует Rational Software's Unified Method [1]). Уровень знаний на самом деле не попадает в эту категорию, потому что он не описывает нотацию для операционного уровня. Поэтому я использую термин «мета-модель» только для обозначения модели описывающей язык (семантику обозначений) для модели. (Конечно, если бы я сделал диаграмму, которая показывала бы экземпляры типа ответственности и типа стороны, то уровень знаний выступал бы в качестве мета-модели для этой диаграммы. Такой вид диаграммы может быть полезен при наличии сложной сети типов подотчетности).
Я на практике все концептуальные модели называю мета-моделями, потому что как-то так вышло, что окружающие легче воспринимают такой термин и понимают его как модель описывающая модели. Корректно составленная модель покрывает очень широкий спектр возможных изменений системы и требует перерисовки гораздо реже нежели любые другие архитектурные диаграммы.
Подотчетность представляет собой довольно сложную абстракцию, и, чем выше наши абстракции, тем чаще надо останавливаться, чтобы перевести дух и посмотреть на результат с точки зрения целесообразности. Хотя на операционном уровне модели мы имеем очень простую структуру, множество правил скрыто в экземплярах уровня знаний. Поэтому, чтобы все работало, недостаточно реализовать объектную модель; уровень знаний также должен быть инстанцирован. Инстанцирование уровня знаний — это эффективное конфигурирование системы, которое представляет собой ограниченную, а значит, более простую форму программирования. Однако это все равно программирование, поэтому вам следует подумать о том, как вы собираетесь его тестировать.
Богатые уровни знаний также влияют на взаимодействие между системами. Если две системы хотят взаимодействовать, они должны не только иметь общую объектную модель, но и идентичные объекты знаний (или хотя бы некоторую эквивалентность между уровнями знаний, как обсуждается в разделе 5.4). В итоге все сводится к вопросу: если количество типов ответственностей велико, проще ли использовать структуру рис. 2.9 или расширить рис. 2.5, добавив по одной ассоциации для каждого типа ответственности? Сложности в такой задаче не избежать. Мы можем только спросить себя, какая модель проще, принимая во внимание как структуру типов, так и объекты знаний.
Необходимо соблюдать осторожность с «произвольным» (any), не накладывающим ограничений типом взаимосвязи, чтобы он не стал базовым для описания ответственностей между сторонами. Например, «биологический родитель» не подойдет в качестве одного из типов ответственности, потому что очень сложно определить реальную ответственность в зависимости от времени. И время тоже автоматически никак тут не определяется. А если ту же сущность назвать «Законный опекун», то тут уже можно обозначить более конкретно, конечно, в зависимости от контекста. Т.е. биологический родитель является законным опекуном для ребенка от момента рождения до достижения возраста совершеннолетия и несет ответственность в течении этого срока.
2.6 Обобщения по типам сторон (Party Type Generalization)
Модель в ее нынешнем виде довольно мощная, но некоторые полезные вариации добавят ей еще больше гибкости. Эти варианты полезны для любой модели, использующей разделение на знания и операции.
Рассмотрим врача общей практики (ВОП), доктора Эдвардса. Используя модель, показанную на рис. 2.9, мы можем считать его терапевтом или врачом, но не тем и другим. Любые типы подотчетности, определенные для доктора, которые будут применяться и к ВОП, придется скопировать. Мы можем использовать различные методы для решения этой проблемы. Один из подходов заключается в том, чтобы позволить типам сторон иметь отношения суб- и супертипов, как показано на рис. 2.10.
Добавление обобщения к типам сторон упрощает определение уровня знаний.
Рисунок 2.10 Разрешение типам сторон иметь под- и супертипы.
По сути, это вводит обобщение для типов сторон аналогично тому, как обобщение работает с типами. Обобщения приводят к изменению ограничений на тип ответственности, так что учитывается как тип группы (на основе сопоставления типов), так и супертипы (сопоставление всех типов).
На рисунке 2.10 представлена единственная иерархия наследования для типов участников. Множественное наследование можно поддерживать, позволяя отображению супертипа быть многозначным. Кроме того, рисунок 2.10 поддерживает только одну классификацию. Это означает, что если доктор Эдвардс является одновременно терапевтом и педиатром, мы можем записать это только путем создания специального типа группы « ВОП \педиатр», в котором ВОП и педиатр являются супертипами. Множественная классификация позволяет назначить группе несколько типов вне обобщающей структуры. Это можно сделать, позволив мультизначное приведение типов для группы.
Обсуждение взаимосвязей между уровнем знаний и операционным уровнем во многом напоминает отношения между объектом и типом при создании метамоделей.
2.7 Иерархическая ответственность (Hierarchic Accountability)
Получающаяся гибкая структура ответственностей, требует больше усилий для соблюдения ограничений для некоторых типов подотчетности. Например, организационная структура, показанная на рисунке 2.3, определяет строгий ряд уровней: операционные подразделения делятся на регионы, которые делятся на дивизионы, а те делятся на офисы продаж. Можно определить тип подотчетности региональной структуры, но как обеспечить соблюдение строгих правил рисунка 2.3?
Первая проблема заключается в том, что на рисунке 2.3 описана иерархическая структура. В моделях подотчетности нет правила, обеспечивающего соблюдение такой иерархии. Проблему можно решить, создав подтип для типа ответственности с дополнительным ограничением, как показано на рисунке 2.11. Это ограничение действует вместе с обычным ограничением на типы ответственности, чтобы обеспечить иерархическую природу структуры операционного уровня. Аналогичный элемент может быть использован, чтобы обеспечить получение направленного ациклического графа.
Дополнительное ограничение означает, что стороны, связанные обязательствами этого типа, должны образовывать иерархию.
Рисунок 2.11 Иерархический тип ответственности.
Используя рисунок 2.11, мы можем подкрепить пример из рисунка 2.3, серией типов подотчетности. В типе ответственности региональной структуры уровня 1 регионы будут отвечать за операционные подразделения, в региональной структуре уровня 2 дивизионы будут отвечать за регионы, и так далее. Такой подход работает, но выглядит несколько неуклюже. Альтернативой может быть использование уровневого типа подотчетности, как показано на рис. 2.12. В этом случае будет существовать только один тип ответственности региональной структуры. Отображение уровней будет соответствовать списку типов групп — операционное подразделение, регион, подразделение и офис продаж. Такая модель упрощает добавление новых уровневых типов подотчетности и изменение уровней в тех структурах, которые в этом нуждаются. Иерархический тип подотчетности отражает ответственность сторон, образующих иерархию, а уровневый тип подотчетности отражает ответственность фиксированной последовательности типов сторон. Тип ответственности региональной структуры может быть как уровневым, так и иерархическим.
Уровневая ответственность поддерживает фиксированные уровни, такие как офис продаж, подразделение, регион.
Рисунок 2.12 Тип ответственности используя уровни.
Ограничения, накладываемые на подтипы, действуют вместе с ограничениями для типа ответственности, в соответствии с принципами проектирования по контракту [4]. В случае с уровневым типом подотчетности ограничения поглощают ограничения супертипа и делают отображения уполномоченных и ответственных излишними. Такое рассуждение приводит к модели, представленной на рисунке 2.13. Важно отметить, что рисунок 2.12 не является неверным. Тип ответственности с уровнями является вполне хорошим вариантом модели ответственности, поскольку ограничения типа ответственности все равно будут действовать для типа подотчетности с уровнями. Отношения уполномоченных и ответственных также сохранятся, хотя они будут получены из взаимодействия уровней. Я бы склонялся к тому, чтобы придерживаться рисунка 2.12. Тип ответственности с уровнями не всегда нужен и может быть легко добавлен без нарушения модели. Преимущество рисунка 2.12 также в том, что он делает отношения между знаниями и операциями более явными.
Улучшенный способ организации иерархии типов ответственности.
Рисунок 2.13 Перераспределение подтипов ответственности.
2.8 Зона ответственности (Operating Scopes)
Подотчетность в ее нынешнем виде представляет собой ценный способ описания отношений сторон друг с другом. Тип ответственности описывает, какого рода отношения между ними существуют. Однако обычно есть и другие детали, которые в большей степени описывают смысл подотчетности. Рассмотрим врача, который может быть нанят в качестве хирурга по печени для проведения 20 операций по пересадке печени в юго-восточном Лондоне в 1997 году. В больнице группу по работе с диабетом могут попросить позаботиться о пациентах с инсулинозависимым диабетом в западном Массачусетсе для организации Red Shield HMD (Health Management Organization).
Такие детали являются операционными областями ответственности, как показано на рис. 2.14. Каждая область действия определяет часть последствий применения ответственности для стороны. Сложно перечислить атрибуты операционной области в абстрактном виде. Однако, мы видим, что у подотчетности есть несколько операционных областей, каждая из которых является некоторым подтипом, описывающим фактические характеристики.
Операционные области определяют обязанности ответственного лица. Их можно использовать для описания должностных обязанностей.
Рисунок 2.14 Область применения.
Пример Хирург, который отвечает за 20 трансплантаций печени в год в юго-восточном Лондоне, имеет протокол о трудовой ответственности с количеством 20, протоколом трансплантации печени и местоположением юго-восточного Лондона.
Пример Группа по уходу за диабетиками подотчетна компании Red Shield. В рамках этой ответственности будет осуществляться клинический уход, концепция наблюдения которого — инсулинозависимый диабет, а местонахождение — западная часть штата Массачусетс.
Пример ACM заключила контракт с индонезийскими экспортерами кофе (ICE) на поставку 3000 тонн Явы и 2000 тонн Суматры в течение года. Он описывается договором между ACM и ICE с временным периодом в год и двумя положениями о ресурсах: 3000 тонн/год Явы и 2000 тонн/год Суматры.
Пример Джон Смит продает для ACM кофемашины семейств 1100 и 2170. Он продает семейства 1100 и 2170 в Новой Англии, семейство 2170 — в Нью-Йорке. У него есть трудовые обязательства перед ACM с территориями продаж 1100 в Новой Англии, 2170 в Новой Англии и 2170 в Нью-Йорке.
При использовании операционных областей для конкретной организации необходимо определить виды существующих операционных областей и их свойства. Абстрактно обобщать операционные области очень сложно, но общим фактором является местоположение. Подтипы операционных областей могут образовывать собственную иерархию наследования, если их много. В особо сложных случаях можно встретить тип операционной области (В этом случае экземпляры типа операционной области должны соответствовать подтипам операционной области. Таким образом, тип операционной области является мощным типом [3].), размещенный на уровне знаний, чтобы показать, какие типы подотчетности могут иметь те или иные типы области действия.
Обсуждаемый шаблон можно рассматривать как некоторое ограничение при котором может сработать отношение ответственности между сторонами. Обычно «область применения» появляется на схеме, когда выразить ограничение другими средствами сложнее. Например, можно взять ситуацию ответственности работодателя за технику безопасности работников на время работы. Такое ограничение можно промоделировать с помощью сущностей Место и Время, которые будут задавать что-то в духе: Цех-1 с 6 до 14. Но, как вы догадываетесь, не все может быть выражено так просто, тогда как раз и наступает время для «области применения».
Другим примером может служить система прав доступа\принятии решений на основе атрибутов. Некоторый сотрудник может просматривать данные, но не редактировать их. Т.е. область действия будет обозначена как «чтение данных». Или же сотрудник может быть уполномочен вести переговоры, но принятие окончательного решения будет в зоне ответственности другого человека.
2.9 Пост (Post)
Зачастую круг обязанностей сотрудника — его ответственность, в том числе и подотчетность — определяется заранее в его должностной инструкции. Когда человек уходит с работы или в отпуск, его заместитель может унаследовать полный набор обязанностей. Эти обязанности привязаны к должности, а не к человеку.
Мы можем справиться с этой ситуацией, введя должность в качестве третьего подтипа участника, как показано на рис. 2.15. Любые обязанности, неизменные для данной должности, кто бы ее ни занимал, привязаны к ней. Человек занимает должность, неся ответственность за нее. Это означает, что человек несет ответственность за обязанности, связанные с должностью, в течение периода времени, на который он назначен на эту должность.
Должности используются в тех случаях, когда обязанности и сферы ответственности определяются должностью и не меняются при смене ее владельца. Назначения на должности — это подотчетность.
Рисунок 2.15 Пост.
Пример: Пол Смит — руководитель группы разработки крупносерийной продукции. Мы можем описать это с помощью должности руководителя группы разработки крупносерийной продукции. Она имеет управленческую подотчетность перед группой разработки крупносерийной продукции (сторона). Пол Смит имеет отдельную подотчетность (типа назначение) на эту должность.
Пример: Должность хирурга-трансплантолога в больнице содержит в своей должностной инструкции требование выполнить 50 трансплантаций почек и 20 трансплантаций печени в год. Эта должность подотчетна больнице, и протокол предусматривает 50 трансплантаций почек и 20 трансплантаций печени.
Должности не следует использовать постоянно. Они значительно усложняют операционный уровень за счет дополнительного уровня непрямолинейности. Используйте должности только в тех случаях, когда есть значительные обязанности, которые статичны для должности, и люди достаточно часто меняются между должностями. Должности не нужны в моделях, в которых все обязанности могут быть закреплены за человеком.
Ссылки
Booch, G., and J. Rumbaugh. Unified Method for Object-Oriented Development Rational Software Corporation, Version 0.8, 1995.
Cairns, T., A. Casey, M. Fowler, M. Thursz, and H. Timimi. The Cosmos Clinical Process Model. National Health Service, Information Management Centre, 15 Frederick Rd, Birmingham, B15 11D, England. Report ECBS20A & ECBS20B, http://www.sm.ic.ac.uk/medicine/cpm, 1992.
Martin, J., and J. Odell. Object-Oriented Methods: A Foundation. Englewood Cliffs, NJ: Prentice-Hall, 1995.
Meyer, B. Applying ‘Design by Contract,’ IEEE Computer, 25, 10 (1992), pp. 40–51.