Современная конкуренция на рынке систем автоматизации, высокая стоимость их разработки и дальнейшего сопровождения обострили ряд вопросов, связанных с подходами к проектированию таких комплексов. Появление инструментов для быстрой разработки приложений и средств визуального программирования, методологии объектно-ориентированного программирования (ООП), языка моделирования бизнес процессов (UML) значительно упростило и ускорило процесс создания программного обеспечения. Однако, решение следующих вопросов остается по-прежнему за разработчиком:
- Сколько и какие классы нужно определить для решения поставленной задачи?
- Как распределить обязанности между этими классами и каким образом они должны взаимодействовать между собой?
- Какие функции будут выполнять конкретные классы?
- Как использовать уже имеющиеся классы объектов в новых проектах, требующих от них новой функциональности и взаимодействия с новыми классами, и в то же время обеспечить совместимость с предыдущими наработками?
- И, наконец, каким образом обеспечить качественное после продажное обслуживание будущей системы с наименьшими затратами?
А что, если попытаться ответить на подобные вопросы с учетом совместной работы как визуальных, так и не визуальных классов, да еще учесть факторы, связанные с организацией командной разработки? Таким образом, уже одних этих вопросов вполне достаточно, чтобы понять, что затраты проекта начинают расти как снежный ком, даже при наличии у разработчика каких либо наработанных ранее библиотек процедур и функций.
Вывод один, без какого либо системного подхода к принципам разработки сложных, многофункциональных комплексов, другими словами без наличия технологии производства программного обеспечения, каждый начатый проект, с большой долей вероятности, может быть вообще не выполненным, или затянуться на неопределенный срок. Если провести аналогию с другим производственным процессом, допустим по сборке автомобилей, то предприятие вряд ли приступит к производству новой усовершенствованной модели автомобиля, пока не проведет достаточно кропотливую работу по технологической подготовке его производства и обеспечению гарантийного сервисного обслуживания.
Другими словами, нужна ТЕХНОЛОГИЯ проектирования программного обеспечения, или СИСТЕМА его разработки. Вопросы, связанные с дальнейшим обслуживанием уже выпущенного в свет программного обеспечения здесь не рассматриваются, однако, они послужили одной из веских причин для создания технологии PowerM.
На каких принципах строится технологический подход в проектировании? Ответ достаточно прост – стандартизация. Стандартизация всех элементов проектирования, начиная от имен и обозначений и заканчивая конечным набором визуальных объектов, а также их интерфейсов.
Цель создания системы проектирования
Перечислим основной набор требований, для реализации которых предназначена система проектирования PowerM:
- Открытость архитектуры приложения
- Гибкость настройки и адаптации к требованиям реального бизнеса
- Слабое связывание визуальных объектов и классов-обработчиков между собой
- Независимость от используемой СУБД (переносимость)
- Быстрое создание прототипа готового приложения
- Стандартизация пользовательского интерфейса
- Унификация команд по работе с визуальными моделями
- Сведение к минимуму необходимости дополнительного кодирования
- Максимум декларативного описания и динамической интерпретации таких настроек
- Поддержка мультидокументного интерфейса пользователя
- Обеспечение доступа к объектам проектирования на основе ролей пользователей