От первой части ко второй


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


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


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


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


Позиционирование проблемы


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


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


Взгляд на преимущества автоматизации процессов создания программных продуктов
На наш взгляд, одно из решений перечисленных выше проблем -это создание собственной среды разработки приложений, использующей декларативный подход. Такая среда является надстройкой над существующими RAD (Delphi, C++ Builder, VisualBasic) и может обеспечить следующие преимущества:

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

Взгляд на структуру среды разработки приложений для автоматизации бизнес-процессов


Определим приоритеты создаваемой системы:

  • производительность;
  • расширяемость;
  • гибкость.

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


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


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


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

  • Диспетчер - основной управляющий и коммуникационный элемент. Существующий в единственном экземпляре объект этого класса в программе отвечает за создание и регистрацию объектов, их дальнейшее взаимодействие при помощи посылки сообщений.
  • Хранилище настроек. Единственный экземпляр этого класса в приложении обеспечивает доступ к декларативным данным, определенным в DesinTime. Это позволяет создавать силами диспетчера прикладные объекты программы. Хранилище отвечает также и за сохранение и восстановление текущего состояния элементов пользовательского интерфейса.
  • Адаптер. Число объектов этого типа определяется числом одновременных подключений к различным базам данных (БД). Введение этого класса призвано обеспечить независимость механизмов доступа к данным от типа используемых БД и продиктовано необходимостью использовать среду разработки и приложения, созданные с ее помощью, на предприятиях различных масштабов.

Наметив основные инфраструктурные элементы, перейдем к понятиям, связанным непосредственно с предметной областью.

  • Бизнес-объект - реальные или воображаемые объекты, имеющие существенное значение для рассматриваемой предметной области. Состояние Бизнес-объекта, характеризующееся значениями его свойств, подлежит хранению. Описание прикладных задач выполняется в терминах Бизнес-объектов, из которых складывается систематизированный свод знаний о предприятии.
  • Форма данных - класс, объекты которого предназначены для взаимодействия с пользователем. С помощью форм данных пользователь имеет возможность получать информацию о состоянии Бизнес-объектов и изменять их. Отчеты (как производные от форм данных) служат для отображения состояния одного или нескольких взаимодействующих Бизнес-объектов.

Любое взаимодействие осуществляется путем посылки сообщения от объекта-источника Диспетчеру с указанием адреса объекта-получателя.

 

 

Предприняв попытку объединить в рамках одной архитектуры объектно-ориентированный и функциональный подход введем понятие Сценарий, который реализуется как совокупность взаимосвязанных функций (действий), использующих в качестве параметров состояния Бизнес-объектов.


Практические вопросы построения среды разработки приложений для автоматизации бизнес процессов


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

  1. Диспетчер - как центральный элемент системы - создается при запуске приложения. При создании Диспетчера сразу должны быть загружены настройки: либо хранящиеся непосредственно в исполняемом коде, либо из внешнего источника (ini-файла, системного реестра, командной строки и т. д.). В соответствии с настройками создаются объекты, совокупность которых обеспечивает развертывание описанной в Design Time логики приложения. При отсутствии в описании прикладных объектов (Адаптер, Бизнес-объект, Форма данных, Отчет, Сценарий) программа завершает работу. Неотъемлемой частью Диспетчера является активный список динамически созданных объектов и механизм передачи сообщений между ними.
  2. Хранилище настроек. Механизм управления данными Хранилища настроек может реализовываться как с помощью СУБД-приложения, так и с помощью независимых внешних структур (DBF, XML и т. д.).
  3. Адаптер проецирует набор методов Бизнес-объектов, работающих с данными предметной области, на конкретную реализацию - в зависимости от используемой СУБД или прочих методов доступа к данным. В перечень стандартных методов включены методы отбора, добавления, изменения и удаления данных (конкретного экземпляра Бизнес-объекта).
  4. Бизнес-объект - ключевой элемент системы; их совокупность образует логическую модель описываемой предметной области. Реализация Бизнес-объекта представляет собой набор данных, к нему применимы стандартные методы этого понятия.
  5. Сценарий. При создании Сценарий выполняет загрузку из Хранилища настроек информации обо всех доступных ранее зарегистрированных методах (функциях, процедурах и т. д.), принадлежащих элементам системы. Сценарий являет собой последовательность вызовов методов, которым в качестве параметров передаются текущие состояния Бизнес-объектов.
  6. Форма. Выступает в качестве элемента взаимодействия пользователя с Бизнес-объектом. Форма работает с клоном Бизнес-объекта, который может быть отфильтрован, отсортирован и т. п. независимо от родителя. Изменение состояния клона приводит к изменению состояния Бизнес-объекта. Это может оказаться полезным при использовании Бизнес-объектом нескольких форм для взаимодействия с одной. При построении интерфейса пользователя в системах автоматизации финансово- хозяйственной деятельности к подавляющему большинству форм предъявляются сходные функциональные требования (добавить, удалить, откорректировать, отобрать, найти и т. п.), что стимулирует к унификации пользовательского интерфейса и сокращению времени на его разработку. В процессе эксплуатации системы создается коллекция унифицированных форм, и при проектировании прикладной системы достаточно лишь выбирать из галереи необходимую форму.
  7. Отчет. В настоящее время существует большое количество программных продуктов, позволяющих создавать и использовать Отчеты. Поэтому логично использовать тот же подход, что и для Форм. То есть создать галерею необходимых модулей отчетов, состоящих из дизайнера и исполняющей RUN TIME подсистемы, и подключать их в зависимости от потребностей прикладной системы.
2004.06.25
19.03.2009
В IV квартале 2008 г. украинский рынок серверов по сравнению с аналогичным периодом прошлого года сократился в денежном выражении на 34% – до $30 млн (в ценах для конечных пользователей), а за весь календарный год – более чем на 5%, до 132 млн долл.


12.03.2009
4 марта в Киеве компания Telco провела конференцию "Инновационные телекоммуникации", посвященную новым эффективным телекоммуникационным технологиям для решения задач современного бизнеса.


05.03.2009
25 февраля в Киеве компания IBM, при информационной поддержке "1С" и Canonical, провела конференцию "Как сохранить деньги в условиях кризиса?"


26.02.2009
18-19 февраля в Киеве прошел юбилейный съезд ИТ-директоров Украины. Участниками данного мероприятия стали ИТ-директора, ИТ-менеджеры, поставщики ИТ-решений из Киева, Николаева, Днепропетровска, Чернигова и других городов Украины...


19.02.2009
10 февраля в Киеве состоялась пресс-конференция, посвященная итогам деятельности компании "DiaWest – Комп’ютерний світ" в 2008 году.


12.02.2009
С 5 февраля 2009 г. в Киеве начали работу учебные курсы по использованию услуг "электронного предприятия/ учреждения" на базе сети информационно-маркетинговых центров (ИМЦ).


04.02.2009
29 января 2009 года в редакции еженедельника "Computer World/Украина" состоялось награждение победителей акции "Оформи подписку – получи приз!".


29.01.2009
22 января в Киеве компания "МУК" и представительство компании Cisco в Украине провели семинар для партнеров "Обзор продуктов и решений Cisco Small Business"

 

 
 
Copyright © 1997-2008 ИД "Комиздат".