'

Необъектные модели предметной области

Понравилась презентация – покажи это...





Слайд 0

Необъектные модели предметной области Докладчик: Максим Цепков (M.Tsepkov@custis.ru) www.CUSTIS.ru Опыт CUSTIS


Слайд 1

О чем будет доклад? DDD – эффективный способ проектирования Объектная модель предметной области – понятно ? Необъектная модель Зачем? И что это такое? Чем они полезны? Рассмотрим на примерах… 2/39


Слайд 2

Немного истории Объектная модель – не первая Реляционная модель – вместе с базами данных Функциональная модель (Lisp) Исчисление предикатов (Prolog) Объектная модель проработана в начале 90-x является основной в настоящее время Появляются новые и композитные модели Модель взаимодействующих лиц с обменом сообщениями (Erlang) Модель многомерных показателей (гиперкубов) В объектную модель добавляют другие парадигмы (LINQ) И так далее, идет активное развитие… 3/39


Слайд 3

DDD – эффективный способ проектирования 4/39


Слайд 4

Что такое DDD Концептуальная книга Эрика Эванса на английском – в 2003 г. на русском – только в 2010 г. Практическая книга Джимми Нильссона на английском – в 2006 г. на русском – в 2007 г. (почти сразу!) Для знакомства – можно смотреть материалы, ссылки, слайды и видеозапись тренинга Андрея Бибичева: http://lib.custis.ru/ddd-training 5/39


Слайд 5

DDD – проектирование по модели Строим модель предметной области, вырабатываем для этого единый язык Воспроизводим модель в архитектуре программы и коде – соответствие должно быть очевидным Модель предметной области становится моделью системы 6/39


Слайд 6

Требования к модели Заказчик владеет единым языком и понимает модель без перевода Разработчик может реализовать модель в коде без дополнительного проектирования Модель можно проследить в бизнесе и в коде P.S. Аналитик тоже есть – он строит модель 7/39


Слайд 7

Парадигмы построения моделей 8/39


Слайд 8

Что есть парадигма моделирования на примере объектной модели… Элементы единого языка для предметной области и способ их соединения в сложные конструкции Объекты с атрибутами и методами Визуальный образ для эффективного представления Диаграмма классов и другие диаграммы UML Способ отражения модели в реализацию Объекты в программе 9/39


Слайд 9

Достоинства объектной модели ? Соответствует парадигме современных языков ? Понятна разработчикам и аналитикам ? Имеет эффективные визуальное представление ? Соответствует реальному миру и понимается заказчиком – если проектировать бизнес-объекты 10/39


Слайд 10

По опыту разработки корпоративных приложений Недостатки объектной модели ? Плохо представляет цикл жизни объекта ? Плохо подходит для отражения потоков ресурсов ? Плохо подходит для систем связанных показателей Если для области автоматизации эти аспекты важны, можно применять другие парадигмы 11/39


Слайд 11

Как отражать модель в реализацию Язык, реализующий парадигму Framework, часто с диаграммами например, MS Workflow Foundation для реализации документооборота DSL, лучше графический, с компилятором или интерпретатором Диаграммы и понятия единого языка и шаблоны их отражения в реализацию Для сложных областей Если нет готового – приходится разрабатывать 12/39


Слайд 12

Как сделать необъектную модель? Выбрать или придумать парадигму моделирования Объекты обмениваются сообщениями Ресурс выделяется действующим лицам Определить визуальный образ единого языка Диаграммы взаимодействия и синхронизации Образ разрезания пиццы Разработать правила отражения модели в код – иначе элементы модели не найти в реализации Лучше, если отражение будет по шаблонам 13/39


Слайд 13

Документооборот и State Entity 14/39


Слайд 14

Бизнес-задача – обобщенный документооборот Документ имеет несколько этапов обработки На каждом этапе определенные сотрудники могут совершать определенные действия Для передачи на следующий этап должны выполняться определенные условия 15/39


Слайд 15

Идея решения Документу приписываем состояние Состояние определяет этап документооборота: какие действия можно совершать над документом кто отвечает за обработку документ кто имеет права на совершение тех или иных действий Возможные изменения состояний документа образуют граф переходов Шаблон State Entity 16/39


Слайд 16

Язык модели Структура документов – объектная модель Действие над документом – вызов метода Состояния документа и методы- переходы между ними, Граф состояний – State machine diagram Названия состояний и переходов – на языке бизнеса UML 17/39


Слайд 17

Варианты шаблона реализации Из книги Нильссона Императивно в коде конкретных методов Императивно в едином методе смены состояния Декларативно – через таблицу переходов и состояний Через иерархию классов-состояний 18/39


Слайд 18

Что выбрать? Модель должна прозрачно отражаться в реализацию Используем декларативное описание (3) Или комбинацию (1) и (3): императивно изменяем состояние в методе перехода контролируем, что изменение соответствует декларативной разметке Таблица метаданных – декларативное описание – однозначно соответствует диаграмме состояний 19/39


Слайд 19

Почему не иерархия состояний? Иерархия классов-состояний – в объектной модели Полнее выразить реализацию в диаграмме классов Но поведение документа – за рамками, оно только в графе переходов Поэтому для единого языка, понимаемого заказчиком – не подходит Реализация через метаданные Таблица переходов отражает поведение документа в коде И однозначно соответствует диаграмме переходов Диаграмма переходов понимается заказчиком – единый язык При этом иерархия состояний становится излишней Однако, реализация требует выхода из объектной модели 20/39


Слайд 20

Сравним модели… Диаграмма состояний Диаграмма классов Модель Это – лишнее 21/39


Слайд 21

Реализация на разных платформах Отдельный проект Инициализация таблицы переходов для каждого документа Общая функция проверки перехода для всех методов (вместе с логом) Таблица допустимых действий для каждого состояния (тоже с логом) Собственный объектный framework в Oracle Таблица переходов и прав в метаданных Вызов процедур-методов динамически с проверками 1998 22/39


Слайд 22

Реализация на разных платформах Собственный ORM на C# Разметка методов метаданными – состояния, права Описание в метаданных графа состояний и условий Обработка на посткомпиляции при создании реализации Об описании графа и условий доклад Гребнева и Алексеева на ADD-2010 http://lib.custis.ru/217-Static-checking-with-DDD-add-2010 2008 [Method(AutoSave = true)] [StateRestriction(RequestForShipmentState.New)] [StateTransition(RequestForShipmentState.New, RequestForShipmentState.Created)] [GrantInvocation(RmsRole.Manager)] public virtual void PrepareForShipment() { State = RequestForShipmentState.Created; ... 23/39


Слайд 23

Учет модель и реализация 24/39


Слайд 24

Бизнес-задача: учет остатков и потоков товаров, денег, других ресурсов Исполнение документов изменяет учетные показатели – остатки и обороты в разрезе аналитик (товаров, клиентов) Учетные показатели влияют на обработку документов и решения пользователей Нужно в большинстве управленческих систем, а не только в бухгалтерии 25/39


Слайд 25

Примеры показателей Остаток на складе по ответственным Поступление товара за период Поставка в магазины за месяц 26/39


Слайд 26

Учетная модель – не объектная Сложность объектного представления учета Нет идентификации единичного объекта Работа идет с показателями, текущее значение которых меняется Изменение числового значения может менять состояние с точки зрения принятия бизнес-решения Часто интерес представляют агрегаты, а не отдельные значения Представление учета оказалось за рамками UML И вообще эффективного представления ? 27/39


Слайд 27

Что входит в учетную модель Элементы учета Синтетические счета и их аналитика Проводки Показатели – остатки и обороты Для представления учетной модели мы придумали Диаграммы учета Диаграммы показывают как проводки перемещают ресурсы по синтетическим счетам какая аналитика счетов по каким переходам исполняются проводки 28/39


Слайд 28

Диаграммы учета Показывают, как отражается движение ресурсов в учете 29/39


Слайд 29

Подробно о диаграммах учета К сожалению, подробного описания нет ? Есть выступления на конференциях ЛАФ-2010 – http://lib.custis.ru/Accounting-diagrams «Диаграммы планов счетов – средство моделирования и проектирования учета» SECR-2010 – http://lib.custis.ru/Simplify-security-accounting «Учет ценных бумаг – сделать сложное простым» Презентация и видео Презентация и статья 30/39


Слайд 30

Способ реализации учета Есть Patterns for Accounting Мартина Фаулера – отражение учета в объектную реализацию учетные счета и проводки источник проводок – события У нас – более развитая реализация хранение аналитических признаков на счетах и проводках ведение остатков и оборотов учетных счетов ведение детальных и агрегированных показателей Есть собственный язык описания – GL-XML Наш метод 31/39


Слайд 31

Реализация учета – классы Реализация учета выполняется по шаблону Классы и таблицы имеют стандартную структуру Она порождается по описанию на GL-XML Диаграмма классов – не интересна 32/39


Слайд 32

Реализация учета разработчиком Сделать реализацию по диаграмме учета – описать набор счетов, аналитику счетов и проводок Описать хранимые показатели Обеспечить создание проводок на учетных событиях – переходах документов, императивно или декларативно GL-XML GL-XML 33/39


Слайд 33

А специальные учетные системы? Специальные учетные системы – это фреймворки Счета, аналитики настраиваются (декларативно) Проводки – шаблонами или на встроенном языке Можно строить модель учета, используя диаграммы учета, меняется лишь отражение в реализацию Например, 1С 34/39


Слайд 34

Модель или иллюстрация? Эванс выделяет диаграммы – иллюстрации, не образующие модель 35/39


Слайд 35

Диаграмма – не всегда модель В процессе проектирования часто используют диаграммы, описывающие предметную область Когда диаграммы становятся моделью? Они входят в единый язык, их понимают разработчики Их можно сопоставить с реализацией, то есть кодом Проектирование реализации по диаграмме носит технический характер, часто это применение шаблона Иначе это не модель, а иллюстративные диаграммы 36/39


Слайд 36

ЗАКЛЮЧЕНИЕ (что я хотел сказать) 37/39


Слайд 37

Модель – основа взаимопонимания Используйте модели, понятные заказчику Шаблоны – способ перевода с языка модели в код Необъектные модели – эффективно, хотя непривычно Программисты – умные и поймут незнакомые модели! 38/39


Слайд 38

Спасибо! Вопросы? Максим Цепков (M.Tsepkov@custis.ru) 39/39


×

HTML:





Ссылка: