|
|
СИСТЕМЫ УПРАВЛЕНИЯ БАЗАМИ ДАННЫХ #02/97
|
|
В настоящее время CASE-системы прочно вошли в практику программной индустрии. При этом они используются не только (и не столько) как комплексные технологические конвейеры для производства программных систем, но и как мощный инструмент решения исследовательских и проектных задач, связанных с начальными этапами разработки, таких как анализ предметной области, разработка проектных спецификаций, выпуск проектной документации, планирование и контроль разработок, моделирование деловых приложений с целью решения задач оперативного и стратегического планирования и управления ресурсами и т. п.
К настоящему моменту наиболее интенсивное развитие получили два главных направления применения CASE-средств.
1) BPR (business process reengineering) - перепроектирование бизнес-процессов. Под перепроектированием понимается "фундаментальное переосмысление и радикальное перепланирование критических бизнес-процессов, имеющее целью резко улучшить их выполнение с точки зрения затрат, качества обслуживания и скорости". При этом бизнес-процесс представляет собой некоторую деятельность, получающую входные данные одного или нескольких типов и выдающую результат, имеющий ценность для клиента. Например, процесс выполнения заказа на входе получает заказ и выдает в качестве результата заказанные товары. Другими словами, доставка заказанных товаров клиенту и есть та ценность, которую создает процесс.
2) Системный анализ и проектирование, включающее функциональное, информационное и событийное моделирование как вновь создаваемой, так и существующей системы.
Необходимо отметить, что такое разбиение является весьма условным, поскольку при анализе организации и разработке проекта ее автоматизации используются элементы BPR (более того, теоретически BPR должно быть первым этапом разработки), в то же время необходимым этапом перепроектирования является по крайней мере создание функциональной модели бизнес-процесса.
В таблице 1 приведен перечень доступных на российским рынке CASE-средств и поддерживаемые ими виды проектной деятельности.
Таблица 1.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Для моделирования бизнес-процессов обычно используется методология SADT (точнее, ее подмножество IDEF0), поддерживаемая пакетами BPWin и Design/IDEF. Однако статическая SADT-модель не обеспечивает полного решения задач перепроектирования, необходимо иметь возможность исследования динамических характеристик бизнес-процессов. Одним из решений является использование системы динамического моделирования Design/CPN, основанной на цветных (раскрашенных) сетях Петри. Фактически Design/IDEF и Design/CPN являются компонентами интегрированной методологии перепроектирования: статические SADT-диаграммы автоматически преобразуются в прообраз динамической модели, которая дорабатывается вручную и затем исполняется в различных режимах с целью получения соответствующих оценок.
Другой возможный подход реализуется пакетом Designer/2000: моделирование бизнес-процессов является первым этапом разработки системы, а соответствующая модель является основой для разработки концептуальных моделей и проектирования системы. Нотация для моделирования бизнес-процессов включает следующие элементы: базовый процесс, шаг процесса, хранилище, поток, событие и организационная единица. Для каждого элемента можно задать разнообразные количественные параметры (временные затраты, ресурсы и т. п.), а затем с помощью специальной процедуры анимации проследить поведение модели в динамике с учетом введенных параметров. Использование средств мультимедиа, включая визуализацию, видеоизображение, звуковое сопровождение и т. п., позволяет существенно повысить выразительность построенной бизнес-модели.
Следует отметить, что не существует принципиальных ограничений в использовании в качестве средства построения статических моделей бизнес-процессов и традиционных диаграмм потоков данных (DFD - data flow diagrams). Более того, в настоящий момент за рубежом доступен ряд продуктов динамического моделирования (INCOME Mobile, CPN-AMI и др.), базирующихся на сетях Петри различного вида и интегрируемых с DFD-моделью, которые позволяют успешно решать задачи перепроектирования.
Для решения задачи функционального моделирования на базе структурного анализа традиционно применяются два типа моделей: SADT-диаграммы и диаграммы потоков данных. В случае наличия в моделируемой системе программной/программируемой части (т. е. практически всегда) предпочтение, как правило, отдается DFD по следующим соображениям.
1) DFD с самого начала создавались как средство проектирования программных систем (тогда как SADT - как средство проектирования систем вообще) и имеют более богатый набор элементов, адекватно отражающих их специфику (например, хранилища данных являются прообразами файлов или баз данных).
2) Наличие мини-спецификаций DFD-процессов нижнего уровня позволяет преодолеть логическую незавершенность SADT (а именно обрыв модели на некотором достаточно низком уровне, когда дальнейшая ее детализация становится бессмысленной) и построить полную функциональную спецификацию разрабатываемой системы.
3) Существуют (и поддерживаются рядом CASE-пакетов) алгоритмы автоматического преобразования иерархии DFD в структурные карты, демонстрирующие межмодульные и внутримодульные связи, а также иерархию модулей, что в совокупности с мини-спецификациями является завершенным заданием для программиста.
Наконец, в части автоматизированной поддержки моделей приблизительно 85-90% существующих CASE-пакетов поддерживают DFD и лишь 2-3% - SADT.
Традиционный подход к моделированию аспектов поведения системы основывается на расширении диаграмм потоков данных за счет введения управляющих потоков (сигналов) и управляющих процессов, фактически являющихся интерфейсом между DFD и спецификациями управления, собственно моделирующими поведение. Наиболее часто спецификации управления формализуются с помощью диаграмм переходов состояний (STD - state transition diagrams), позволяющих задавать состояния различных объектов системы (например, лицевой счет может иметь состояния ОТКРЫТ, ЗАКРЫТ, ЗАБЛОКИРОВАН и т. п.), условия переходов из одного состояния в другое (как внешние по отношению к системе, так и внутренние, возникающие в самой системе), а также совершаемые при переходах действия.
В таблице 2 приведен перечень пакетов, поддерживающих DFD, и основные составляющие функциональных моделей.
Таблица 2.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Для целей информационного моделирования на сегодняшний день не существует альтернативы диаграммам "сущность-связь" (ERD - entity-relationship diagrams). Практически все из приведенных в таблице 1 пакетов поддерживают ту или иную нотацию ERD. При этом разработка информационной модели в рассматриваемых средах включает в себя не только проектирование логической модели, но и преобразование ее в физическую модель с последующей генерацией схемы БД с учетом специфики конкретной СУБД.
Одно только перечисление факторов, влияющих на выбор CASE-пакетов для выполнения проектных работ, составило бы не менее 2-3 страниц текста. В данном разделе приводится ряд рекомендаций, помогающих обойти лишь некоторые из подводных камней, неизбежно возникающих при переходе к новым технологиям.
1) Поддержка методологий структурного (а не объектно-ориентированного) анализа и проектирования на начальных этапах проекта. Если вы при общении с руководством или экспертом предметной области (например, с бухгалтером) будете употреблять слова "наследование", "инкапсуляция", "полиморфизм" и т. п., то в лучшем случае столкнетесь с непониманием.
2) Поддержка классических методов структурного анализа и проектирования. Это позволит вам в случае неудовлетворенности пакетом относительно легко подобрать новый, не переделывая, а лишь перерисовывая (в худшем случае) наработанные модели.
3) Выбор в качестве первого опыта недорогих продуктов с учетом информации о реальных проектах, выполненных с их использованием. Например, известен ряд фирм и банков, использующих на начальных этапах проектирования автоматизированных банковских систем пакеты CASE. Аналитик для построения функциональной, а ERWin для построения информационной моделей.
4) Наличие средств экспорта/импорта фрагментов проекта, что при коллективной работе поможет избежать множества проблем, связанных с мультипользовательским доступом.
5) Обязательная поддержка автоматической верификации на полноту и состоятельность проекта и генерации отчетов по верификации.
6) Автоматическая генерация проектной документации в соответствии с общепринятыми стандартами (отечественных заказчиков вполне удовлетворяют ГОСТы, зарубежных - DOD STD-2167A).
7) Для функционального моделирования - наличие мини-спецификаций процессов нижнего уровня (задаваемых общепринятыми методами), а не возможности задавать аналогичную информацию в качестве комментария при определении процессов. Это позволит полностью охватить технологии, применяемые заказчиком, и расширит возможности созданного проекта (например, его можно будет использовать для автоматизированного и быстрого обучения новых работников конкретному направлению деятельности).
8) Для информационного моделирования - наличие средств генерации схем БД для широкого спектра СУБД, а также поддержки обратного проектирования (reverse engineering), т. е. создания информационных моделей из существующих БД.
|
|