Данная статья завершает цикл публикаций, подготовленных на основе докладов, отобранных из программы 1-й Всероссийской конференции «Стандарты в проектах современных информационных систем».

Данная статья завершает цикл публикаций, подготовленных на основе докладов, отобранных из программы 1-й Всероссийской конференции «Стандарты в проектах современных информационных систем» (Москва, апрель, 2001 год). С другой стороны, она служит продолжением темы CASE-технологий, возобновленной в №1 нашего журнала за 2002 год. В статье представлен интересный пример практического применения теории, а именно опыт реализации одной из отечественных компаний целостной CASE-технологии построения информационных систем.

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

Кренцлер Альберт Александрович, менеджер ОСИ холдинга «ЛАНИТ». На момент подготовки статьи к печати он работал в компании ИВС, г. Пермь. E-mail: Krencler@lanit.ru

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

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

Путь CASE-технологии как стандарта предприятия

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

Колчанов Андрей Александрович, руководитель технологического отдела ИВС, г. Пермь, E-mail: storm@ics.perm.ru

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

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

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

Основы STORM2000

Главными компонентами CASE-технологии STORM2000 являются три модели: команды, процесса и приложения, которые описаны ниже. В качестве основы для этих компонентов были выбраны следующие составляющие, являющиеся стандартами де-юре или де-факто (целиком или отдельные части).

Для модели команды:

  • Microsoft Solution Framework (MSF).

Для модели процесса:

  • Unified Modeling Language (UML);
  • Object Modeling Technique (OMT);
  • Microsoft Solution Framework (MSF);
  • Rational Unified Process (RUP);
  • Objectory.

Для модели приложения:

  • Distributed Component Object Model (DCOM/COM+);
  • Microsoft Solution Framework (MSF);
  • Structured Query Language (SQL).

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

Область применения технологии

CASE-технология ИВС STORM2000 включает в себя все аспекты процесса производства информационных систем, а именно она позволяет:

  • автоматизировать создание ИС, наладить их производство;
  • эффективно задействовать команду разработчиков заказных ИС или отдел АСУ предприятия;
  • получить унифицированные (стандартизованные на уровне предприятия) по архитектуре и интерфейсу, удовлетворяющие требованиям предприятия приложения.

Технология применяется для создания ИС под заказ.

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

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

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

Составляющие технологии

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

Модель команды

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

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

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

Не вдаваясь в детали, заострим внимание на том, что команда определяется тремя независимыми сторонами (людьми или группами людей):

  • стороной заказчика;
  • стороной разработчика;
  • стороной качества.

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

Модель процесса

Модель процесса позволяет эффективно организовать процесс создания ИС. Модель процесса — это совокупность стандартов уровня предприятия, которые зафиксированы в методическом обеспечении технологии. Методическое обеспечение представляет собой комплекс методик, определяющих выполняемые процессы на всех этапах жизненного цикла. Данная модель на методическом уровне тесно связана с моделью команды. Инструментально процесс поддержан промышленной CASE-средой, используемой практически на всех этапах в качестве единой рабочей среды проектной команды для фиксации всех анализируемых бизнес-процессов и проектных решений, генерации кода и документации, сборки дистрибутива и развертывания приложений ИС.

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

Укрупненно, процесс включает следующие этапы:

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

Основное внимание уделяется этапу анализа. Это очевидно: поскольку система должна автоматизировать предмет, ее необходимо предметно спроектировать. Аналитик создает модель системы в терминах предметной области. Используется язык UML, методология OMT и промышленная CASE-среда Telelogic Tau UML Suite.

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

Этапы анализа и объектного дизайна — самые продолжительные по времени. Генерация кода является самым коротким этапом. Экспериментально установлено, что на реальной системе (например, управление торговлей) методом генерации можно получить примерно 85% всего кода. Хотя это не определяет полностью реальную сложность и трудоемкость доработки системы, но характеризует, сколько времени разработчика экономит технология за счет стандарта на приложение. Генерируется код COM-компонентов для Microsoft Visual Basic и сценарии создания БД для СУБД Microsoft SQL Server или Oracle. Отметим, что генерируется код для всех уровней приложений ИС. Архитектура приложений задается моделью приложения, о которой речь пойдет ниже.

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

Последними идут этапы сборки дистрибутива системы и ее развертывание у заказчика, обучение пользователей и обслуживающего персонала системы. Все перечисленные этапы достаточно определены и стандартизованы.

Следует заметить, что между этапами «Анализ системы ?как есть?» и «Анализ системы ?как требуется?» можно провести реинжиниринг бизнес-процессов, поручив этот этап консалтинговой компании и передав ей модель ИС в виде документов, содержащих текстовые описания, диаграммы UML, прототип системы.

Разумеется, наличие модели процесса повышает качество ИС.

Модель приложения

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

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

Инструментальное обеспечение технологии включает общее программное ядро для всех приложений, сервисные подсистемы, автоматически включаемые в приложение, различные сервисные утилиты, средства отладки, оригинальный кодогенератор для промышленного CASE-средства Telelogic Tau UML Suite, который позволяет получать высококачественный и многократно оттестированный на проектах исходный код.

В результате применения этого стандарта прикладные ИС, создаваемые по CASE-технологии STORM2000, автоматически обладают следующими характеристиками.

  • Многопользовательская система.
  • Общее программное (Run-Time) ядро, общий, универсальный графический пользовательский интерфейс, обеспечивающий полный набор базовых операций (списки, формы, редактирование, изменение, сохранение, печать, поиски, наложение ограничений и т. п.).
  • Встроенные подсистемы полномочий (оперируют на уровне бизнес-объектов, то есть так, как нарисовано в CASE на диаграммах, а не на уровне СУБД или компонентной технологии), пользовательских настроек (обеспечивается независимость от рабочей станции), фильтров и отчетов (интегрировано с MS Office), удаленная установка и обновление рабочих мест, единая административная консоль.
  • Трехуровневая распределенная компонентная архитектура, включающая уровни хранения данных, бизнес-логики и представления. Система может быть реализована как в классической архитектуре с обычным клиентом, так и в архитектуре c Web-клиентом.
  • Управление транзакциями на уровне бизнес-сервера.
  • Многопоточное выполнение операций (не блокирующее конкретный экземпляр клиентского приложения).
  • Открытая система.

Компонентный подход, основанный на стандарте Microsoft DCOM/COM+, который используется при построении систем, позволяет независимо работать с компонентами, прозрачно заменять и повторно их использовать, распределять эффективно загрузку каждого слоя системы.

Управление транзакциями в системе происходит на достаточно высоком уровне — уровне бизнес-процессов. Это дает возможность эффективно и быстро создавать систему, в отличие от управления транзакциями на уровне данных. Доработка системы разработчиками также производится в терминах бизнес-объектов и бизнес-методов, что обеспечивает разработчикам изолированность на понятийном уровне от СУБД, например от транзакций в смысле СУБД.

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

Преимущества от использования единой архитектуры приложения очевидны. Это:

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

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

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

Рис. 1. Диаграмма классов для простейшего примера «Учет книг (как сборников произведений)»

Именно подобные модели (только реальные, а значит, гораздо более сложные) служат источником для генерации исходного кода. В частности, пользовательский интерфейс для ввода объектов класса «Книга» выглядит так, как показано на рис. 2.

Рис. 2. Форма пользовательского интерфейса для ввода данных об объектах класса «Книга»

Видно, что ассоциация «Книги» с «Издательством» превратилась на форме в элемент выбора связанного объекта. «Произведения», которые были агрегированы на диаграмме в «Книгу», являются строками. Для получения этой формы не было вручную написано ни одной строчки кода. Единственное, что сделал разработчик, — это переместил, «переразмерил» элементы управления, сменил надписи.

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

Условия и метод применения

Кроме использования выстроенного комплекса стандартов в рамках компании «ИВС», ее вполне можно применять вне одной компании. CASE-технология STORM2000 ориентирована на использование:

  • ИТ-подразделениями предприятий и корпораций, ведущих крупные проекты построения ИС;
  • ИТ-компанией для построения заказных ИС.

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

  • подбор команды;
  • обучение команды;
  • совместный с ИВС пилотный проект построения «легко обозримой» системы;
  • дальнейший консалтинг и техническую поддержку.

Конечно, внедрение CASE-технологии на предприятии — это очень сложная задача. По мнению специалистов ИВС, основными трудностями являются:

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

Сегодня на базе CASE-технологии STORM2000 разработаны, разрабатываются, развиваются системы на следующих, предприятиях:

  • ОАО «Пермэнерго» (снабжение);
  • ОАО «Пермагроснаб» (торговля, бухучет, лизинговые операции);
  • ООО «ЛУКОЙЛ-Пермнефтеоргсинтез» (снабжение; бюджетирование);
  • ЗАО «ИВС-Сети» (торговля, производство, бухучет);
  • Департамент образования и науки Пермской области (система мониторинга образования);
  • ОАО «Пермский мукомольный завод» (бухучет, снабжение, сбыт, производство, ремонт, бюджетирование).

Положительные и отрицательные стороны использования

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

Положительные стороны:

  • высокая технологичность и автоматизация производства ИС (отсюда высокое качество систем, низкая стоимость);
  • высокое качество ведения проектов (отсюда укладывание в сроки, высокое качество процесса и систем, занятость персонала);
  • низкая совокупная стоимость владения ИС.

Отрицательные стороны:

  • повышение уровня требований к квалификации кадрового состава предприятия;
  • непонимание заказчиком диаграммных моделей;
  • «психологическая ломка» для разработчиков этого предприятия.

Заключение

Авторам представляется интересным продолжить открытое рассмотрение опыта пермской компании по практическому использованию CASE-технологии. Компания ИВС приглашает для такого обсуждения всех, кому интересен данный опыт, предлагает ознакомиться с действующей CASE-технологией STORM2000, с построенными по этой технологии прикладными системами, пообщаться со специалистами компании, готовыми продемонстрировать применение продукта «живьем» и представить самые новые разработки в рамках развития технологии, такие как, например, Web-клиент и другие.