Главная
Архив новостей
Шаблоны
Студенту
Статьи по стандартам
Файлы
Ссылки
Форум
О проекте
История проекта

Многомерное представление модели приложения

Среди студентов физфака МГУ существовала притча: "когда студентам физфака и технического ВУЗа предложили задачу расчета устойчивости табурета на 3 ножках, студент-технарь полистал справочники и решил задачу за 1 день. Студент физфака решил задачу за месяц, но он создал теорию устойчивости табурета на N ножках, а 3 - это просто частный случай!"

Цель данной статьи - попытка описать базовый элемент информационной системы, реализация которого позволит создавать гибкие и легко модифицируемые приложения. В основу положено представление элемента модели как композитного объекта.

Введение

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

Первая аналогия: создание приложения подобно проектированию здания архитектором. И главное здесь – правильно выбрать «строительный материал» - те строительные блоки, из которых будет возводиться здание! Если наши «кирпичики» будут стандартного размера, с одинаковыми свойствами и легко «скрепляться» друг с другом – тогда и здание будет построено быстро и получится прочным и красивым.

Начнем по порядку... В первую очередь мы должны сформулировать наши требования к «кирпичикам», то есть выработать определенные правила, которым должны подчиняются объекты проектируемой системы.

Правило 1. Объекты должны иметь имя.

Реализация : унаследуем все объекты от абстрактного класса NamedObject.

Преимущества : вынесение интерфейса обращения с именем в одно место - реализацию абстрактного класса NamedObject.

Правило 2. Имя объекта «наследуется». То есть, если объект не имеет собственного имени, используется имя владельца.

Пример : ярлык - ссылка на объект. Если имя не задано явно, используется имя владельца - объекта, на который он ссылается.

Преимущества : возможно использование составных имен (как пути к файлу).

http://www.howtodothings.com/ViewArticle.aspx?Article=15

Мы ввели понятие «владельца» . Значит, объекты в системе могут быть связаны с другими?

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

Тогда ...

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

Аналогия: Очень легко это понять на примере файловой системы. Одиночный объект - файл, композитный объект - папка, которая может содержать другие папки и файлы. Желательно добавить еще один объект - ярлык. Это ссылка на композитный объект. Для каждого объекта можно добавить атрибут - "счетчик ссылок", который содержит количество связей с объектом. Счетчик меняется при добавлении/удалении связи. Удаление объекта допускается только при значении счетчика=0 (можно удалить только пустую папку или объект, не имеющий ярлыков).

Реализация : применим шаблон проектирования компоновщик (Composite).

[ Э. Гамма и др. "Приемы объектно-ориентированного проектирования. Паттерны проектирования"].

http://ooad.asf.ru/patterns/patterninfo.asp?id=11.

Назначение шаблона

Компонует объекты в древовидные структуры для представления иерархии часть-целое. Позволяет системе единообразно трактовать индивидуальные и составные объекты.

Преимущества : единый интерфейс обработки иерархических структур.

Если ввести в систему объекты «Папка» и «Ярлык», можно предоставить пользователям создавать собственную иерархию документов. К примеру, в системе документооборота можно представить, что документ лежит в папке «Входящие», ярлык на него лежит в папке «К исполнению», еще один ярлык – в папке «На подписи».

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

Правило 4. Каждый объект может быть связан с множеством объектов.

Реализация : свяжем ассоциациями наши композитные объекты.

Все, можно проектировать интерфейс! Форма редактирования списка предприятий, форма редактирования списка накладных, форма редактирования списка… Короче, очень много форм. Да и довольно скоро модель приложения становится похожа на паутину! Что-то не так. Продолжим проектирование модели…

Рассуждаем дальше. Мы моделируем объектное пространство ! А пространство многомерно ! И если взглянуть на модель не как на плоскую, а как на n-мерный куб, то все становится легко и просто! Каждый объект может быть связан с множеством объектов, но в каждый конкретный момент мы работаем с отображением (проекцией) нашей n-мерной модели на плоскость по определенным осям координат (в нашем случае, ассоциаций).

Приведу пример: товар в торговой системе связан ассоциацией с производителем, с накладной, со складом, с маркой, и т.д. Мы можем рассматривать проекцию по осям координат товар-производитель, товар-накладная и т.п. Это все двумерные проекции нашего n-мерного пространства! То есть то, какую проекцию использовать, зависит от контекста, в котором мы рассматриваем объект! Контекст определяется ассоциациями! Добавляя новую ассоциацию, мы увеличиваем размерность нашего пространства. Если мы дадим обобщающее понятие для этого контекста, мы облегчим понимание. А имя ему - роль ! Представление объекта зависит от роли, которую он играет в паре ассоциаций! Роль - это те оси координат, по которой мы делаем проекцию. Но как сделать наш шаблон компоновщик многомерным? Очень легко - надо сделать ассоциацию типа n-n и создать класс ассоциации Role.

Правило 5. Представление объекта определяется ролью, которую он играет в ассоциации.

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

Реализация : сделаем ассоциацию типа n-n и подключим к ней класс ассоциации Role. Свяжем его с таблицей типов ролей.

http://www.martinfowler.com/apsupp/roles.pdf .

http://www.jot.fm/issues/issue_2002_09/column2

Преимущества: добавление новой роли не приводит к изменению модели. Добавляется только новый тип роли. Можно создать одну форму редактирования, и менять только названия формы, полей и кнопок в зависимости от типа роли. Можно пойти дальше – все названия хранить в таблице типов ролей. Гибкость существенная!

Что у нас получилось? Мы представили нашу модель многомерной, и теперь практически любой объект системы можно унаследовать от "многомерного" композитного объекта. При создании объекта мы можем задавать ему роли определенного типа, удалять и добавлять роли. Все просто великолепно! Но как определить, когда какая роль допустима для этого объекта? Чего не хватает нашему многомерному пространству? Еще одной координаты - времени ! Объекты не статические элементы системы, а динамические. И поведение объекта определяется не только его ролью, но и общим состоянием системы! Состояние - это ось времени, но имеющая фиксированные точки. Система переходит из одного состояния в другое по конкретным правилам. Теперь сформулируем…

Правило 6. Система может находиться в одном из состояний. Переход в другое состояние производится по правилам перехода.

Что это напоминает?

Автомат с конечным числом состояний! Отсюда

Реализация : применим шаблон State. http://ooad.asf.ru/patterns/patterninfo.asp?id=24

 

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

 

Возможные состояния системы хранятся в таблице StateTable. Состояния связаны

друг с другом (это и есть таблица переходов). Переход производится при наступлении события Event .

Пример: состояние «Редактирование накладной». Реакция на событие «Добавить товар» - переход в состояние «Добавление товара». Реакция на событие «Товар добавлен» - переход в состояние «Редактирование накладной».

Преимущества: добавление нового состояния не приводит к изменению модели. Добавляются только новые правила переходов. Система приобретает исключительную гибкость! Можно перестроить ее для решения других задач только изменением внешних настроек!

Выводы

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

 Developing.ru  - клуб программистов Клуб разработчиков программных систем Rambler's Top100 Рейтинг@Mail.ru Каталог ресурсов ListTop.Ru Яндекс цитирования Rambler's Top100
© 2001-2017. Сopyright by "Отдел автоматизации и разработки ПО"
Перепечатка любых материалов без разрешения авторов сайта запрещена.
Сергей Мякишев©, o'Xana - Дизайн и разработка сайта
Kost - Программирование, Системное Администрирование