Отправляет email-рассылки с помощью сервиса Sendsay

Создаем свой бизнес

  Все выпуски  

Создаем свою информационную систему


Создаем свою информационную систему


Структура информационной системы

Сегодня надо поднять два вопроса.  Первый я бы назвал так – общее и различное.

А второй в чем отличие похода, который я пропагандирую, от многих других.

 

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

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

 

Если конкретно, то я бы предложил следующую схему.

 

Информационная система «собирается» из следующих блоков:

 

1. Хранилище информации

2. Представление информации

3. Организация доступа

4. Импорт информации

5. Экспорт информации

6. Блок печати и экспорта отчетов

7. Блок взаимодействие с пассивными устройствами

8. Блок взаимодействия с активными устройствами

9. Программы для активных устройств

10. Блоки для манипулирования данными ( алгоритмы выходящие за рамки сохранения и непосредственного изменения)

11. Блоки синхронизации и репликации, сюда обычно относятся и локи для интеграции информационных систем

 

Ясно, что «классификация» блоков очень абстрактная. Но для меня суть в том,  что есть блоки строго уникальные, а есть блоки, общие.

 

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

 

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

 

Вернемся к «станартным» блокам.  Не смортря на то, что они условно  одинаковы, во всех системах, различия  огромны.  Ну примерно, как мышь отличается от слона, хотя все мы знаем, что с точки зрения днк, -  они почти братья.

 

Так и все системы, которые мы стараемся делать. Практически все близнеци батья, но…

Различия на уровне хранения сводятся к тому, что моно использовать базы данных различных форматов (MS SQL, ORACLE, Postgres, и т.п.)

Различия на уровне представления определяются, как формой реализации приложения (WEB /  WIN) , так и платформой взаимодействия. Хотя общий алгоритм доступа остается неизменным.

Про различия в структурах данных я просто не говорю, это мне кажется очевилным.

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

Импорт и экспорт встроен в уровень доступа к данным и часто его оказывается достаточно для задач, с которыми мы сталкиваемся.

Касательно отчетов, тут не все просто. Хотя есть механизм для автоматизации создания отчетов, его как правило не достаточно и мы  тратим на «удовлетворение» запросов для конкретных  систем существенное время. Но механизмы формирования отчетов остаются общими.

 

 

Теперь вторая часть. В чем существенная разница в подходе, который используем мы, и теми подходами, которые , что называется, «доступны».

 

Доступны на сегодня, фактически два подхода,  которые можно считать универсальными решениями.

  1. Моделирование струтктуры данных и получение скриптов базы данных, и, иногда слоя доступа к данным
  2. По имеющейся базе данных – получение кода для доступа, просмотра и редактирования.

 

Если интересно, я могу привести примеры и той и другой технологии, которые есть. Что-то  есть в Open Source варианте, что-то  коммерческое, но все в принципе доступно.

 

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

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

 

Итак, какой подход я пропагандирую:

  1. Создание модели настолько мощной, что она может описать структуру данных, жизненный цикл и ограничения как уровня базы данных, так и  уровня интерфейса пользователя.
  2. Расширение модели до уровня, когда она может описываеть не только отдельный объект, но и целиком функциональность рабочих мест
  3. Формирование полноценного пакета генераторов кода всех уровней (  генератор скрипта базы данных, слой доступа, GUI документа, Рабочее место, Инсталлятор), ну еще в качестве бонуса генераторы отчетов и документации.

 

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

 

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

Ведущий рассылки: Михаил М. Баранов
http://www.abolsoft.ru bami@abolsoft.ru

В избранное