Глава 2 АНАЛИЗ ПРЕДМЕТНОЙ ОБЛАСТИ АИС С ПРИМЕНЕНИЕМ СИСТЕМ АВТОМАТИЗИРОВАННОГО ПРОЕКТИРОВАНИЯ

Глава 2 АНАЛИЗ ПРЕДМЕТНОЙ ОБЛАСТИ АИС С ПРИМЕНЕНИЕМ СИСТЕМ АВТОМАТИЗИРОВАННОГО ПРОЕКТИРОВАНИЯ

 

Этапы анализа предметной области

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

1. разработать стратегию комплексной автоматизации;

2. провести анализ деятельности предприятия;

3. рассмотреть вопросы реорганизации деятельности.

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

1. цели — области деятельности предприятия и последовательность, в которой они будут автоматизированы;

2. способ автоматизации — по участкам, направлениям, комплексная автоматизация;

3. долгосрочная техническая политика — комплекс внутренних стандартов, поддерживаемых на предприятии;

4. ограничения;

5. процедура управления изменениями плана.

Стратегия автоматизации в первую очередь должна соответствовать приоритетам и стратегии (задачам) бизнеса и определять пути достижения этого соответствия. Стратегический план автоматизации составляется с учетом:

1. среднего периода между сменой технологий основного производства;

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

3. анонсированных долгосрочных планов поставщиков технических решений в плане их развития;

4. сроков амортизации используемых систем;

5. стратегического плана развития предприятия, включая планы слияния и разделения, изменения численности и номенклатуры выпускаемой продукции;

6. планируемых изменений функций персонала.

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

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

1. снижение стоимости продукции;

2. увеличение количества или ассортимента;

3. сокращение цикла: разработка новых товаров и услуг, выход на рынок;

4. переход от производства «на склад» к производству «под конкретного заказчика» с учетом индивидуальных требований и т. д.

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

Автоматизация предприятия является инвестиционной деятельностью и к ней применимы все подходы оценки эффективности инвестиций.

К основным ограничениям, которые необходимо учитывать при выборе стратегии автоматизации, относятся:

1. финансовые;

2. временные;

3. ограничения, связанные с влиянием человеческого фактора;

4. технические.

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

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

К ограничениям, связанным с влиянием человеческого фактора, относятся корпоративная культура или отношение персонала к автоматизации и особенности рынка труда в части трудового законодательства.

Технические ограничения определяются степенью материального и морального износа технического парка предприятия (организации).

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

1. состоянием рынка информационных технологий;

2. определением эффективности инвестиций в информационные технологии;

3. необходимостью реорганизации деятельности предприятия при внедрении информационных технологий.

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

Реорганизация деятельности преследует, как правило, цель повышения эффективности деятельности предприятия в целом и может предусматривать применение методологий BSP, TQM или BPR.

Методология BSP (см. также гл. 1) определяется как «подход, помогающий предприятию определить план создания информационных систем, удовлетворяющих его ближайшим и перспективным информационным потребностям». Информация является одним из основных ресурсов и должна планироваться в масштабах всего предприятия, АИС должна проектироваться независимо от текущего состояния и структуры предприятия. BSP основывается на нисходящем анализе информационных объектов и регламентирует 13 этапов выполнения работ.

Подход TQM (Total Quality Management) успешно применялся при реорганизации предприятий еще в середине XX в. В основе подхода лежит очевидная концепция управления качеством выпускаемой продукции. Качество должно быть направлено на удовлетворение текущих и будущих потребностей потребителя как самого важного звена производственной линии. Достижение соответствующего уровня качества требует постоянного совершенствования производственных процессов. Для решения этой задачи Э. Демингом было предложено 14 принципов, в совокупности составляющих теорию управления качеством и применимых для предприятий произвольных типов и различных масштабов. Безусловно, этих принципов недостаточно для полного решения стоящих перед современными предприятиями проблем, тем не менее они являются основой трансформации промышленности Японии и США.

BPR (Business Process Reengineering) — реинжиниринг бизнес-процессов — определяется как фундаментальное переосмысление и радикальное перепланирование бизнес-процессов компаний, имеющее целью резкое улучшение показателей их деятельности, таких как затраты, качество, сервис и скорость. При этом используются следующие положения.

1. Несколько работ объединяются в одну.

2. Исполнителям делегируется право по принятию решений.

3. Этапы процесса выполняются в естественном порядке.

4. Реализуются различные версии процесса.

5. Работа выполняется там, где ее целесообразно делать (выход работы за границы организационных структур).

6. Снижаются доли работ по проверке и контролю.

7. Минимизируется количество согласований.

8. Ответственный менеджер является единственной точкой контакта с клиентом процесса.

9. Используются и централизованные и децентрализованные операции.

Для того чтобы выполнить пп. 1—9, необходимо использовать так называемый «инжиниринговый подход» [2].

Методология ARIS

Одной из современных методологий бизнес-моделирования, получившей широкое распространение в России, является методология ARIS (Architecture of Integrated Information Systems) — проектирование интегрированных АИС [2, 8]. В настоящий момент методология ARIS является наиболее объемной и содержит около 100 различных бизнес-моделей, используемых для описания, анализа и оптимизации различных аспектов деятельности организации. Часть моделей используется в настроечном модуле интегрированной АИС SAP/R3, который применяется при внедрении системы и ее настройки в соответствии с деятельностью компании.

Методология ARIS предусматривает четыре группы бизнес-моделей (рис. 2.12).

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

2. «Функции» состоят из моделей, используемых для описания стратегических целей компании, функций и прочих элементов функциональной деятельности организации.

3. «Информация» состоит из моделей, с помощью которых описывается информация, используемая в деятельности организации.

Рис. 2.12. Группы моделей методологии ARIS

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

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

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

Несмотря на большое число моделей в методологии ARIS, в проектах по описанию и оптимизации деятельности в общем случае их используется не более десяти. Методология ARIS позиционирует себя как конструктор, из которого под конкретный проект в зависимости от его целей и задач разрабатывается локальная методология, состоящая из небольшого количества требуемых бизнес-моделей и объектов. Наиболее часто используемые в проектах модели приведены в табл. 2.2 [8].

Таблица 2.2. Наиболее часто используемые на практике модели методологии ARIS

Модель «Диаграмма целей» — OD — применяется для описания стратегических целей компании, их иерархической упорядоченности, а также взаимосвязи целей с продуктами и услугами, производимыми компанией, и бизнес-процессами, поддерживающими их производство (рис. 2.13) [8].

Рис. 2.13. Модель «Диаграмма целей» — OD/ARIS

Модель «Дерево продуктов и услуг» — PST — применяется для описания продуктов и услуг, производимых в компании, а также для взаимосвязи со стратегическими целями компании, бизнес-процессами, поддерживающими их производство (рис. 2.14) [8].

Модель «Дерево функций» — FT — описывает функции, выполняемые в компании, и их иерархию. Модель часто применяется для построения дерева бизнес-процессов компании (рис. 2.15) [8].

Модель «Диаграмма окружения процесса» — FAD — позволяет описать окружение или границы бизнес-процесса, показывая его входы, выходы, поставщиков и клиентов (рис. 2.16).

Модель «Диаграмма цепочки добавленной стоимости» — VACD — является прототипом классического DFD-стандарта и используется для описания бизнес-процессов верхнего уровня. Существенным различием этой и других процессных моделей является то, что информационные и материальные потоки на схеме VACD изображаются не стрелками, а объектами. При этом для каждого типа потока используется свой объект. В отличие от классического подхода здесь также используются логические связи между работами, которые позволяют отобразить логическую последовательность выполнения работ. В качестве одного из вариантов логической последовательности может выступать временная последовательность выполнения работ, что характерно для классического подхода WFD (рис. 2.17) [8].

 

Рис. 2.14. Модель «Дерево продуктов и услуг» — PST/ARIS

Рис. 2.15. Модель «Дерево функций» — FT/ARIS

Рис. 2.16. Модель «Диаграмма окружения процесса» — FAD/ARIS

Рис. 2.17. Модель «Диаграмма цепочки добавленной стоимости» — VACD/ARIS

Модель «Матрица выбора процесса» — PSM — является прототипом классического DFD-стандарта и используется как альтернатива VACD-модели. Матрица выбора процессов по отношению к диаграмме цепочки добавленной стоимости является, с одной стороны, более упрощенным вариантом описания процесса, с другой — содержит дополнительные объекты, позволяющие выявить другие аспекты бизнес-процесса. Простота матрицы выбора бизнес-процессов в том, что на этой модели не отражаются информационные и материальные потоки. Что касается других аспектов, то данная модель позволяет на одной схеме компактно и наглядно показать различные варианты выполнения описываемого бизнес-процесса.

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

Рис. 2.18. Модель «Матрица выбора процессов» — PSM/AR1S

Модель «Расширенная цепочка процессов, управляемая событиями» — еЕРС — является прототипом классического WFD-стандарта и используется для описания бизнес-процессов нижнего уровня. Существенным отличием еЕРС-модели от классической WFD-схемы является наличие в модели объекта, который называется событием. С помощью событий изображается факт, время или событие, инициирующие начало выполнения работ процесса, а также факт или время их завершения (рис. 2.19) [8].

Модель «Организационная структура» — ORG — используется для описания организационной структуры компании; отображает структурные подразделения, группы, должности, роли и прочие элементы организационной структуры и связи между ними (рис. 2.20) [8].

Модель «Диаграмма типов информационных систем» — ASTD — используется для описания структуры информационных систем, применяемых в компании. Здесь отображаются типы и модули информационных систем, программные продукты, взаимосвязь между ними и автоматизируемыми бизнес-процессами организации (рис. 2.21) [8].

 

Рис. 2.19. Модель «Расширенная цепочка процессов, управляемая событиями» - eEPC/ARIS

Рис. 2.20. Модель «Организационная структура» — ORG/AR1S

Рис. 2.21. Модель «Диаграмма типов информационных систем» — ASTD/ARIS

Этапы развития CASE-систем

За последнее десятилетие сформировалось новое направление в проектировании информационных систем — автоматизированное проектирование с помощью CASE-средств. Термин CASE (Computer Aided System/Software Engineering) первоначально относился только к автоматизации разработки программного обеспечения; сейчас он охватывает процесс разработки сложных АИС в целом [11, 15, 16].

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

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

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

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

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

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

При грамотном применении CASE-инструментария достигается значительный рост производительности труда, составляющий (по оценкам зарубежных фирм пользователей CASE-технологий) от 100 до 600 % в зависимости от объема, сложности работ и опыта работы с CASE. При этом изменяются все фазы жизненного цикла АИС, но наибольшие изменения касаются фаз анализа и проектирования (табл. 2.5, 2.6) [11, 15, 16].

Таблица 2.5. Оценки трудозатрат по фазам жизненного цикла АИС

Таблица 2.6. Сравнение использования CASE и традиционной разработки

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

1. улучшает качество разрабатываемого программного обеспечения за счет средств автоматической генерации и контроля;

2. позволяет уменьшить время создания прототипа АИС, что дает возможность на ранних этапах оценить качество и эффективность проекта;

3. ускоряет процесс проектирования и разработки;

4. позволяет многократно использовать разработанные компоненты;

5. поддерживает сопровождение АИС;

6. освобождает от рутинной работы по документированию проекта, так как использует встроенный документатор;

7. • облегчает коллективную работу над проектом.

Рис. 2.22. Преимущества разработки АИС с использованием CASE-технологий: а — коэффициент уменьшения стоимости проекта; б — коэффициент уменьше­ния временных затрат на разработку

В основе большинства CASE-средств лежат четыре главных понятия: методология, метод, нотация, средство [ 11, 15, 16].

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

Методы — процедуры генерации компонентов и их описаний.

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

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

Классификация CASE-средств

До сих пор не существует устойчивой классификации CASE-средств, определены только подходы к классификации в зависимости от различных классификационных признаков. Ниже приведены некоторые из них [11, 12].

Ориентация на технологические этапы и процессы жизненного цикла АИС:

1. средства анализа и проектирования. Используются для создания спецификаций системы и ее проектирования. Они поддерживают широко известные методологии проектирования;

2. средства проектирования баз данных. Обеспечивают логическое моделирование данных, генерацию структур БД;

3. средства управления требованиями;

4. средства управления конфигурацией программного обеспечения. Поддерживают программирование, тестирование, автоматическую генерацию ПО из спецификаций;

5. средства документирования;

6. средства тестирования;

7. средства управления проектом. Поддерживают планирова­ние, контроль, взаимодействие;

8. средства реверсного инжиниринга, предназначенные для переноса существующей системы в новую среду.

Поддерживаемые методологии проектирования [ 11, 12, 15, 16]:

1. функционально-ориентированные (структурно-ориентированные);

2. объектно-ориентированные;

3. комплексно-ориентированные (набор методологий проектирования).

Поддерживаемые графические нотации построения диаграмм:

1. с фиксированной нотацией;

2. с отдельными нотациями;

3. с наиболее распространенными нотациями.

Степень интегрированности:

1. вспомогательные программы (Tools), самостоятельно решающие автономную задачу;

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

3. наборы интегрированных средств, связанных общей базой проектных данных — репозиторием, автоматизирующие все или часть работ разных этапов создания АИС (Workbench).

Коллективная разработка проекта:

1. без поддержки коллективной разработки;

2. ориентированные на разработку проекта в режиме реального времени;

3. ориентированные на режим объединения подпроектов.

Типы CASE-средств:

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

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

3. средства разработки ПО (Lower); поддерживают системы разработки программного обеспечения АИС. Содержат системные словари и графические средства, исключающие необходимость разработки физических спецификаций — имеются системные спецификации, которые непосредственно переводятся в программные коды разрабатываемой системы (при этом автоматически генерируется до 80 % кодов). Главными преимуществами нижних CASE-средств являются значительное уменьшение времени на разработку, облегчение модификаций, поддержка возможностей работы с прототипами.

CASE-средства, кроме того, классифицируют по типу и архитектуре вычислительной техники, а также по типу операционной системы [11, 12, 16].

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

Характеристики CASE-средств

Silverrun. CASE-средство Silverrun американской фирмы Computer Systems Advisers, Inc. (CSA) используется для анализа и проектирования АИС бизнес-класса и ориентировано вбольшей степени на спиральную модель ЖЦ. Оно применимо для поддержки любой методологии, основанной на раздельном построении функциональной и информационной моделей (диаграмм потоков данных и диаграмм «сущность—связь») [7, 11, 16].

Настройка на конкретную методологию обеспечивается выбором требуемой графической нотации моделей и набора правил проверки проектных спецификаций. В системе имеются готовые настройки для наиболее распространенных методологий: DATARUN (основная методология, поддерживаемая Silverrun), Gane/Sarson, Yourdon/DeMarco, Merise, Ward/Mellor, Information Engineering. Для каждого понятия, введенного в проекте, имеется возможность добавления собственных описателей. Архитектуpa Silverrun позволяет наращивать среду разработки по мере необходимости.

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

1. Модуль построения моделей бизнес-процессов в форме диаграмм потоков данных Business Process Modeler (BPM) позволяет моделировать функционирование автоматизируемой организации или создаваемой АИС. Возможность работы с моделями большой сложности обеспечена функциями автоматической перенумерации, работы с деревом процессов (включая визуальное перетаскивание ветвей), отсоединения и присоединения частей модели для коллективной разработки. Диаграммы могут изображаться в нескольких предопределенных нотациях, включая Yourdon/DeMarco и Gane/Sarson. Имеется также возможность создавать собственные нотации, например в число изображаемых на схеме дескрипторов добавлять определенные пользователем поля.

2. Модуль концептуального моделирования данных Entity-Relationship eXpert (ERX) обеспечивает построение моделей данных «сущность—связь», не привязанных к конкретной реализации. Встроенная экспертная система позволяет создавать корректную нормализованную модель данных посредством ответов на содержательные вопросы о взаимосвязи данных. Предусмотрено автоматическое построение модели данных из описаний структур данных. Анализ функциональных зависимостей атрибутов дает возможность проверить соответствие модели требованиям третьей нормальной формы и обеспечить их выполнение. Проверенная модель передается в модуль Relational Data Modeler.

3. Модуль реляционного моделирования Relational Data Modeler (RDM) позволяет создавать детализированные модели «сущность—связь», предназначенные для реализации в реляционной БД. В этом модуле документируются все конструкции, связанные с построением базы данных: индексы, триггеры, хранимые процедуры и т. д. Гибкая изменяемая нотация и расширяемость репозитория позволяют работать по любой методологии. Возможность создавать подсхемы соответствует подходу ANSI SPARC к представлению схемы БД. На языке подсхем моделируются как узлы распределенной обработки, так и пользовательские представления. Этот модуль обеспечивает проектирование и полное документирование реляционных БД.

4. Менеджер репозитория рабочей группы Workgroup Repository Manager (WRM) применяется как словарь данных для хранения общей для всех моделей информации, а также обеспечивает интеграцию модулей Silverrun в единую среду проектирования.

Достоинством CASE-средства Silverrun являются высокая гибкость и разнообразие изобразительных средств построения моделей, а недостатком — отсутствие жесткого взаимного контроля между компонентами различных моделей (например, возможности автоматического распространения изменений между DFD различных уровней декомпозиции). Следует, однако, отметить, что этот недостаток может иметь существенное значение только в случае использования каскадной модели жизненного цикла [7, 11, 16].

В Silverrun включены средства:

1. автоматической генерации схем баз данных для наиболее распространенных СУБД: Oracle, Informix, DB2, Ingres, Progress, SQL Server, SQLBase, Sybase;

2. передачи данных средствам разработки приложений: JAM, PowerBuilder, SQL Windows, Uniface, NewEra, Delphi.

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

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

1. Система отчетов. Отчеты выводятся в текстовые файлы.

2. Система экспорта/импорта. Задается не только содержимое экспортного файла, но и разделители записей, полей в записях, маркеры начала и конца текстовых полей. Такие экспортные файлы можно формировать и загружать в репозиторий. Это дает возможность обмениваться данными с различными системами: другими CASE-средствами, СУБД, текстовыми редакторами и электронными таблицами.

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

Silverrun поддерживает два способа групповой работы:

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

2) сетевая версия Silverrun позволяет вести параллельную групповую работу с моделями, хранящимися в сетевом репози-тории на базе СУБД Oracle, Sybase или Informix. При этом несколько разработчиков могут работать с одной и той же моделью, так как блокировка объектов происходит на уровне отдельных элементов модели.

JAM. Средство разработки приложений JYACC's Application Manager (JAM) — продукт фирмы JYACC. Главной особенностью является соответствие методологии RAD, так как JAM позволяет достаточно быстро реализовать цикл разработки приложения, заключающийся в формировании очередной версии прототипа приложения с учетом требований, выявленных на предыдущем шаге, и предъявить его пользователю [7, 11, 16].

JAM имеет модульную структуру и состоит из следующих компонентов:

1. ядра системы;

2. JAM/DBi — специализированных модулей интерфейса к СУБД (JAM/DBi-Oracle, JAM/DBi-Informix, JAM/DBi-ODBC и т. д.);

3. JAM/RW — модуля генератора отчетов;

4. JAM/CASEi — специализированных модулей интерфейса к CASE-средствам (JAM/CASE-TeamWork, JAM/CASE-Inno-vator и т. д.);

5. JAM/TPi — специализированных модулей интерфейса к ме­неджерам транзакций (например, JAM/TPi-Server TUXEDO и т. д.);

6. Jterm — специализированного эмулятора Х-терминала.

Ядро системы является законченным продуктом и может самостоятельно использоваться для разработки приложений. Все остальные модули — дополнительные и самостоятельно использоваться не могут.

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

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

2. редактор меню;

3. набор вспомогательных утилит;

4. средства изготовления промышленной версии приложения.

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

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

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

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

Утилиты JAM включают три группы:

1) конверторы файлов экранов JAM в текстовые. JAM сохра­няет экраны в виде двоичных файлов собственного формата;

2) конфигурирование устройств ввода-вывода. JAM и приложения, построенные с его помощью, не работают непосредственно с устройствами ввода-вывода. Вместо этого JAM обраща ется к логическим устройствам ввода-вывода (клавиатура, терминал, отчет);

3) обслуживание библиотек экранов.

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

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

JAM содержит встроенный язык программирования JPL (JAM Procedural Language), с помощью которого в случае необходимости могут быть написаны модули, реализующие специфические действия. Данный язык является интерпретируемым. Существует возможность обмена информацией между средой визуально построенного приложения и такими модулями. Кроме того, в JAM реализована возможность подключения внешних модулей, написанных на языках, совместимых по вызовам функций с языком С.

JAM является событийно-ориентированной системой, состоящей из набора событий — открытие и закрытие окон, нажатие клавиши клавиатуры, срабатывание системного таймера, получение и передача управления каждым элементом экрана. Разработчик реализует логику приложения путем определения обработчика каждого события.

Обработчиками событий в JAM могут быть как встроенные функции JAM, так и функции, написанные разработчиком на С или JPL. Набор встроенных функций включает более 200 функций различного назначения; они доступны для вызовов из функций, написанных как на JPL, так и на С.

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

1. исполняемого модуля интерпретатора приложения;

2. экранов, составляющих приложение (поставляются в виде отдельных файлов, в составе библиотек экранов или встраиваются в тело интерпретатора);

3. внешних JPL-модулей (поставляются в виде текстовых файлов или в прекомпилированном виде; прекомпилиро-

1234Следующая ⇒

Поделиться: