Введение

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

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

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

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

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

Концептуальные основы создания ИС предприятия

Основополагающая концепция

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

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

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

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

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

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

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

За последние несколько лет сформировалось новое направление в программотехнике - CASE (Computer Aided System/Software Engineering). Хотя в настоящее время не существует общепринятого определения CASE, и содержание этого понятия обычно определяется перечнем решаемых задач, а также совокупностью применяемых методов и средств, грубо можно сказать, что CASE представляет собой совокупность методологий анализа, разработки и сопровождения сложных систем (в основном заказных систем программного обеспечения АСУ), поддержанную комплексом взаимосвязанных средств автоматизации. CASE - это инструментарий для системных аналитиков и программистов, позволяющий автоматизировать процессы анализа, проектирования и реализации систем.

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

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

Основными пользователями CASE-систем являются:

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

Существует мнение, что CASE, наряду с системами визуального программирования, является наиболее перспективным направлением в программотехнике. С этим можно спорить, но то, что CASE - наиболее динамично развиваемое направление, является в настоящее время неоспоримым фактом. Практически не один серьезный американский или японский программный проект не осуществляется без использования CASE-средств. Известная методология структурного системного анализа SADT - Structured Analysis and Design Technique (точнее ее подмножество IDEF0) принята в качестве стандарта на разработку средств программного обеспечения Министерством обороны США. Более того, среди менеджеров и руководителей компьютерных фирм считается чуть ли не правилом хорошего тона знать основы SADT и при обсуждении каких-либо вопросов нарисовать простейшую диаграмму, поясняющую суть дела.

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

Жизненный цикл ИС

В основе деятельности по созданию и использованию ИС лежит понятие жизненного цикла.

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

Опыт создания и использования заказных ИС позволяет условно выделить следующие основные этапы их жизненного цикла:

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

Этапы разработки, тестирования и внедрения ИС обозначаются единым, объемлющим термином - реализация.

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

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

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

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

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

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

Структурный анализ

Анализ является первым этапом создания ИС, на котором требования заказчика уточняются, формализуются и документируются. Фактически на этом этапе дается ответ на вопрос: "Что должна делать будущая система?". Именно здесь лежит ключ к успеху всего проекта.

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

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

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

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

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

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

Заканчивается процесс разработкой "карты автоматизации", представляющей собой модель реорганизованной предметной области, на которой обозначены "границы автоматизации".

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

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

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

Принципы структурного анализа

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

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

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

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

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

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

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

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

1. Принцип концептуальной общности - заключается в следовании единой философии на всех этапах жизненного цикла.
2. Принцип полноты - заключается в контроле на присутствие лишних элементов.
3. Принцип непротиворечивости заключается в обоснованности и согласованности элементов системы.
4. Принцип абстрагирования - заключается в выделении существенных аспектов системы и отвлечение от несущественных с целью представления проблемы в более простом, общем виде.
5. Принцип упрятывания - заключается в упрятывании несущественной на конкретном этапе информации: каждая часть "знает" только необходимую ей информацию.
6. Принцип логической независимости заключается в концентрации внимания на логическом описании системы, обеспечении независимости от ее физической реализации.
7. Принцип независимости данных заключается в том, что модели данных могут быть проанализированы и спроектированы независимо от процессов их логической обработки, а также от их физической структуры и распределения.

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

Средства структурного анализа

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

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

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

Среди всего многообразия средств решения указанных задач в методологиях структурного анализа наиболее часто и эффективно применяемыми являются:

• FDD (Functional Decomposition Diagrams) - диаграммы функциональной декомпозиции;
• DFD (Data Flow Diagrams) - диаграммы потоков данных;
• ERD (Entity-Relationship Diagrams) - диаграммы "сущность-связь"

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

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

CASE-технология

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

1. Проведение функционального и информационного обследования системы управления (административно-управленческой деятельности) предприятия:

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

2. Разработка моделей деятельности структурных элементов и системы управления в целом:

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

3. Разработка информационных моделей структурных элементов и модели информационного пространства системы управления:

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

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

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

Построенная модель является законченным результатом по следующим причинам:

1. Она включает в себя модель существующей неавтоматизированной технологии, принятой на предприятии. Формальный анализ этой модели позволяет выявить узкие места в управлении предприятием и сформулировать рекомендации по его улучшению (независимо от того, предполагается ли дальнейшая разработка автоматизированной системы или нет).
2. Она независима и отделяема от конкретных разработчиков, не требует сопровождения и может быть безболезненно передана другим лицам. Более того, если по каким-либо причинам предприятие не готово к реализации проекта в данный момент времени, модель может быть "положена на полку" до тех пор, пока в ней не возникнет необходимость.
3. Она позволяет осуществлять эффективное обучение новых работников конкретным направлениям деятельности предприятия, так как соответствующие технологии содержатся в модели.
4. С ее помощью можно осуществлять предварительное моделирование перспективных направлений деятельности предприятия с целью выявления новых потоков данных, взаимодействующих процессов и структурных элементов.
5. Она обеспечивает распространение накопленного опыта на других предприятиях, дает возможность унифицировать административно-управленческую и финансовую деятельность этих предприятий.

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

2.1. Общие положения

Основу современной CASE-технологии анализа и проектирования информационных систем составляют:

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

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

2.2. Краткая характеристика CASE-системы Visible Analyst Workbench

Система Visible Analyst Workbench (VAW) относится к сетевым многопользовательским CASE-системам, предназначенным для поддержки процесса создания ИС от этапов анализа текущей деятельности системы управления предприятия до создания законченных моделей ее реорганизованной деятельности, а также разработки конечных приложений в технологии "клиент-сервер". Продукт реализует широкий набор методов структурного системного анализа.

Централизованная база данных проекта

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

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

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

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

Возможность импорта-экспорта

VAW снабжен мощными встроенными средствами импорта-экспорта. Поддерживается связь с такими популярными средами проектирования конечных приложений, как PowerBuilder и SQL Windows. Так же поддерживается возможность импорта-экспорта данных для таких CASE-средств, как KnowledgeWare и Excelerator.

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

Связь с системами управления базами данных

VAW с помощью встроенных средств может взаимодействовать со следующими СУБД: SQLBase, Oracle, Sybase.

Возможность реверс-инжиниринга

Средствами VAW можно проводить реинжиниринг баз данных, поддерживаемых следующими СУБД: SQLBase, Oracle, Sybase.

Нотации, поддерживаемые системой

VAW поддерживает следующие нотации для построения моделей: Yordon, Gane&Sarson, SDM, IE. Однако система не позволяет изменять во время работы выбранный для проекта формализм.

Средства верификации моделей

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

Среда функционирования

MS Windows 3.x, 95/98, NT.

Требования к аппаратной части

Требования, выдвигаемые системой к аппаратуре, обусловлены средой функционирования MS Windows. Для использования системы требуется IBM совместимый компьютер, оснащенный как минимум процессором Intel 486, ОЗУ емкостью не менее 8 Мб и жестким диском с объемом свободного пространства не менее 6Мб.

Документируемость моделей

VAW поддерживает различные настраиваемые типы отчетов. Пользователь может определить область проекта, по которой нужно дать отчет; типы элементов и их характеристики; задать сортировку отбираемых элементов.

2.3. Процесс структурного анализа с применением CASE-системы Visible Analyst Workbench

В соответствии с общей технологией и архитектурой CASE-систем при работе с VAW выделяются следующие основные этапы процесса разработки информационной системы:

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

Рассмотрим перечисленные этапы подробно.

Моделирование и анализ функционирования существующей системы

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

Построение и анализ информационной модели предметной области

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

Разработка концептуальной модели базы данных новой системы

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

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

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

Первоначальный вариант СУБД-ориентированной реляционной базы данных может быть получен автоматически с помощью специальных утилит на основании спроектированной концептуальной модели базы данных новой системы, представленной в виде ER-диаграммы. Результаты проектирования программных модулей приложений служат основанием для совершенствования структуры базы данных. Принятие соответствующих решений по ее совершенствованию должно фиксироваться в виде модификации ER-диаграммы базы данных.

Проектирование функциональной структуры новой системы

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

Проектирование процессов обработки данных новой системы

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

Проектирование и реализация приложений

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