Это объясняется множеством причин, субъективных и объективных, которые носят самый различный характер: организационный, научно-технический, технологический и пр. Обзор этих причин выходит далеко за рамки данной статьи. Однако общепризнанно, что едва ли не решающим фактором успеха разработки является качество проектирования. Мы попытаемся рассказать об опыте использования новейших технологий проектирования техническим отделом нашей фирмы масштаба предприятия. В качестве примера рассмотрен фрагмент из проекта, выполненного фирмой Астро Софт для САО ╚Росгосстрах≈Санкт-Петербург╩.

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

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

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

Microsoft Solutions Framework ≈ это набор концепций и рекомендуемых моделей, которые позволяют разрабатывать и внедрять распределенные информационные системы масштаба предприятия на основе технологий и инструментальных средств фирмы Microsoft. Многие концепции MSF достаточно хорошо известны. Основное достоинство MSF ≈ это систематизация и структуризация информации в форме базы знаний, удобной для ознакомления и использования.

Составной частью MSF является дисциплина проектирования √ Solution Development Discipline (SDD), концепции которой мы и используем в своих проектах. Другие части касаются разработки компонент приложения, архитектуры предприятия и не относятся к теме данной статьи.

Первая ≈ концептуальное проектирование ≈ представляет собой описание бизнес-проблемы (проблем) и общее видение решения. На этой стадии проектировщики должны понять, что нужно пользователю. Концептуальный проект отражает точку зрения пользователя.

Вторая ≈ логическое проектирование ≈ подробно описывает то, что получит пользователь. Логический проект ≈ это точка зрения проектировщиков на приложение, она не учитывает (по-возможности, конечно) особенности реализации.

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

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

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

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

• Определение существа проблемы, подлежащей решению.
• Определение границ бизнес-процессов, которые покрывают разрабатываемое решение, причем, как внешних границ (область желаемого ≈ Vision), так и внутренних (область абсолютно необходимого ≈ Scope).
• Классификация пользователей.
• Составление сценариев ⌠Как есть■ и ⌠Как должно быть■. Сценарий ≈ это фиксация на языке, в равной мере понятном как пользователям, так и разработчикам, существа бизнес-процесса, для которого разрабатывается решение. Если речь не идет о разработке абсолютно нового приложения, то сценарий ⌠Как есть■ является наиболее надежным средством установления взаимопонимания между пользователями и разработчиками.

Составление сценариев является ключевым моментом концептуального проектирования. Для описания сценариев могут использоваться самые разнообразные средства:

• Контекстные модели для описания организационных, административных, юридических и т.п. факторов, влияющих на бизнес-процесс.
• Потоковые схемы для описания документооборота.
• Блок-схемы процедур пошагового выполнения бизнес-процессов.
• Схема физического размещения оборудования, если это существенно.

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

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

РИСУНОК 1. Фрагмент схемы потоков данных разрабатываемого приложения

РИСУНОК═2. Логическая схема взаимосвязи служб приложения

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

В рассматриваемом примере спроектированные объекты естественным образом пакуются в пять компонент, которые выполняются на трех компьютерах.

• Insurance.exe и User.dll поддерживают интерфейс пользователя, ввод, проверку и отображение информации. Они выполняются на рабочей станции пользователя.
• Business.exe и Data.dll обеспечивают основную обработку данных и преобразование форматов и выполняются на сервере приложений.
• UniData.exe обеспечивает унифицированный доступ к данным и выполняется на сервере данных.