Заключительный этап создания ИХ предполагает комплексное тестирование всех компонентов ИХ (G1 - G3) с исправлением всех возникающих ошибок (G4 - G6), последующим обучением пользователей и постоянным администрированием в соответствии с установленными правилами и документацией проекта (Д8).
Вопросы для самопроверки
1. Что понимается под клиент-серверной архитектурой? Что такое сервер и клиент?
2. Какие существуют уровни представления клиент-серверной архитектуры?
3. Какие существуют варианты клиент-серверной архитектуры?
4. Какие преимущества обеспечивает клиент-серверная архитектура?
5. Что такое репликация данных и какие существуют режимы ее осуществления?
6. Какие операции выполняются на стадии техно-рабочего проектирования клиент-серверной архитектуры?
7. Какие операции включает проектирование базы данных в клиент-серверной среде?
8. Что представляет собой система оперативной обработки транзакций (OLTP-система)?
9. Каковы особенности создания систем управления рабочими потоками?
10. Каковы особенности создания Интернет-приложений?
11. Что представляет собой система оперативного анализа данных (OLAP-система)?
12. Каковы особенности организации информации в информационных хранилищах?
13. Какие требования предъявляются к архитектуре информационных хранилищ?
14. Каковы основные компоненты архитектуры информационного хранилища?
15. Каковы основные технологические операции проектирования информационного хранилища?
Глава 13. АВТОМАТИЗИРОВАННОЕ ПРОЕКТИРОВАНИЕ ЭИС (CASE-ТЕХНОЛОГИЯ)
Основные понятия и классификация CASE-технологий
Термин CASE (Computer Aided System/Software Engineering) используется в довольно широком смысле. Первоначальное значение термина CASE, ограниченное вопросами автоматизации разработки только лишь программного обеспечения, в настоящее время приобрело новый смысл, охватывающий процесс разработки сложных ЭИС в целом. С самого начала CASE-технологии развивались с целью преодоления ограничений при использовании структурной методологии проектирования (сложности понимания, высокой трудоемкости и стоимости использования, трудности внесения изменений в проектные спецификации и т.д.) за счет ее автоматизации и интеграции поддерживающих средств. Таким образом, CASE-технологии не могут считаться самостоятельными, они только обеспечивают, как минимум, высокую эффективность их применения, а в некоторых случаях и принципиальную возможность применения соответствующей методологии. Большинство существующих CASE-систем ориентировано на автоматизацию проектирования программного обеспечения и основано на методологиях структурного (в основном) или объектно-ориентированного проектирования и программирования, использующих спецификации в виде диаграмм или текстов для описания системных требований, связей между моделями системы, динамики поведения системы и архитектуры программных средств. В последнее время стали появляться CASE-системы, уделяющие основное внимание проблемам спецификации и моделирования технических средств.
Наибольшая потребность в использовании CASE-систем испытывается на начальных этапах разработки, а именно на этапах анализа и спецификации требований к ЭИС. Это объясняется тем, что цена ошибок, допущенных на начальных этапах, на несколько порядков превышает цену ошибок, выявленных на более поздних этапах разработки.
Появлению CASE-технологии предшествовали исследования в области методологии программирования. Программирование обрело черты системного подхода с разработкой и внедрением языков высокого уровня, методов структурного и модульного программирования, языков проектирования и средств их поддержки, формальных и неформальных языков описания системных требований и спецификаций и т.д. Кроме того, этому способствовали перечисленные ниже факторы:
· подготовка аналитиков и программистов, восприимчивых к концепциям модульного и структурного программирования;
· широкое внедрение и постоянный рост производительности компьютеров, позволяющих использовать эффективные графические средства и автоматизировать большинство этапов проектирования;
· внедрение сетевой технологии, предоставившей возможность объединения усилий отдельных исполнителей в единый процесс проектирования путем использования разделяемой базы данных, содержащей необходимую информацию о проекте.
Преимущества CASE-технологии по сравнению с традиционной технологией оригинального проектирования сводятся к следующему:
· улучшение качества разрабатываемого программного приложения за счет средств автоматического контроля и генерации;
· возможность повторного использования компонентов разработки;
· поддержание адаптивности и сопровождения ЭИС;
· снижение времени создания системы, что позволяет на ранних стадиях проектирования получить прототип будущей системы и оценить его;
· освобождение разработчиков от рутинной работы по документированию проекта, так как при этом используется встроенный документатор;
· возможность коллективной разработки ЭИС в режиме реального времени.
CASE-технология в рамках методологии включает в себя методы, с помощью которых на основе графической нотации строятся диаграммы, поддерживаемые инструментальной средой.
Методология определяет шаги и этапность реализации проекта, а также правила использования методов, с помощью которых разрабатывается проект.
Метод - это процедура или техника генерации описаний компонентов ЭИС (например, проектирование потоков и структур данных).
Нотация - отображение структуры системы, элементов данных, этапов обработки с помощью специальных графических символов диаграмм, а также описание проекта системы на формальных и естественных языках.
Инструментальные средства CASE - специальные программы, которые поддерживают одну или несколько методологий анализа и проектирования ИС.
Рассмотрим архитектуру CASE-средства, которая представлена на рис. 13.1.
Рис. 13.1. Архитектура CASE-средства
Ядром системы является база данных проекта - репозиторий (словарь данных). Он представляет собой специализированную базу данных, предназначенную для отображения состояния проектируемой ЭИС в каждый момент времени. Объекты всех диаграмм синхронизированы на основе общей информации словаря данных.
Репозиторий содержит информацию об объектах проектируемой ЭИС и взаимосвязях между ними, все подсистемы обмениваются данными с ним. В репозитории хранятся описания следу ющих объектов:
· проектировщиков и их прав доступа к различным компонентам системы;
· организационных структур;
· диаграмм;
· компонентов диаграмм;
· связей между диаграммами;
· структур данных;
· программных модулей;
· процедур;
· библиотеки модулей и т.д.
Графические средства моделирования предметной области позволяют разработчикам автоматизированных ИС в наглядном виде изучать существующую информационную систему, перестраивать ее в соответствии с поставленными целями и имеющимися ограничениями. Все модификации диаграмм, выполняемых разработчиками в интерактивном (диалоговом) режиме, вводятся в словарь данных, контролируются с общесистемной точки зрения и могут использоваться для дальнейшей генерации действующих функциональных приложений. В любой момент времени диаграммы могут быть распечатаны для включения в техническую документацию проекта.
Графический редактор диаграмм предназначен для отображения в графическом виде в заданной нотации проектируемой ЭИС. Он позволяет выполнять следующие операции:
· создавать элементы диаграмм и взаимосвязи между ними;
· задавать описания элементов диаграмм;
· задавать описания связей между элементами диаграмм;
· редактировать элементы диаграмм, их взаимосвязи и описания.
Верификатор диаграмм служит для контроля правильности построения диаграмм в заданной методологии проектирования ЭИС. Он выполняет следующие функции:
· мониторинг правильности построения диаграмм;
· диагностику и выдачу сообщений об ошибках;
· выделение на диаграмме ошибочных элементов.
Документатор проекта позволяет получать информацию о состоянии проекта в виде различных отчетов. Отчеты могут строиться по нескольким признакам, например по времени, автору, элементам диаграмм, диаграмме или проекту в целом.
Администратор проекта представляет собой инструменты, необходимые для выполнения следующих административных функций:
· инициализации проекта;
· задания начальных параметров проекта;
· назначения и изменения прав доступа к элементам проекта;
· мониторинга выполнения проекта.
Сервис представляет собой набор системных утилит по обслуживанию репозитория. Данные утилиты выполняют функции архивации данных, восстановления данных и создания нового репозитория.
Современные CASE-системы классифицируются по следующим признакам:
1) по поддерживаемым методологиям проектирования: функционально (структурно)-ориентированные, объектно-ориентированные и комплексно-ориентированные (набор методологий проектирования);
2) по поддерживаемым графическим нотациям построения диаграмм: с фиксированной нотацией, с отдельными нотациями и наиболее распространенными нотациями;
3) по степени интегрированности: tools (отдельные локальные средства), toolkit (набор неинтегрированных средств, охватывающих большинство этапов разработки ЭИС) и workbench (полностью интегрированные средства, связанные общей базой проектных данных - репозиторием);
4) по типу и архитектуре вычислительной техники: ориентированные на компьютеры, ориентированные на локальную вычислительную сеть (ЛВС), ориентированные на глобальную вычислительную сеть (ГВС) и смешанного типа;
5) по режиму коллективной разработки проекта: не поддерживающие коллективную разработку, ориентированные на режим реального времени разработки проекта, ориентированные на режим объединения подпроектов;
6) по типу операционной системы (ОС): работающие под управлением WINDOWS 3.11 и выше; работающие под управлением UNIX и работающие под управлением различных ОС (WINDOWS, UNIX, OS/2 и др.).
В разряд CASE-систем попадают как относительно дешевые системы для персональных компьютеров с ограниченными возможностями (такие, как редакторы диаграмм), так и дорогостоящие системы для больших компьютеров.
Современные CASE-системы охватывают обширную область поддержки различных технологий проектирования и программирования: от простых средств анализа и документирования ИС до полномасштабных средств автоматизации, покрывающих весь жизненный цикл ИС.
Помимо поддержки начальных этапов разработки важное значение приобретают CASE-системы, ориентированные на проектирование и генерацию баз данных и пользовательских интерфейсов.
Генерация интерфейсов с базами данных и возможность преобразования (конвертирования) между различными концептуальными схемами и моделями данных увеличивает мобильность прикладных систем при переходе в другие операционные среды. Генерация кода и (или) таблиц, описывающих интерфейс прикладной системы с базой данных, не только позволяет сократить время разработки, но и дает возможность отделить разработку приложений от ведения архива проектной документации.
Наиболее трудоемкими этапами разработки ЭИС являются этапы анализа и проектирования, поэтому CASE-системы, как правило, предназначены для автоматизации отслеживания качества принимаемых проектных решений и подготовки документации. При этом большую роль играют методы визуального представления информации. Это предполагает построение структурных или иных диаграмм в реальном масштабе времени, использование многообразной цветовой палитры, сквозную проверку синтаксических правил.
Стратегия выбора CASE-систем для конкретного применения зависит как от целей и потребностей самого проекта, так и от квалификации вовлеченных в процесс проектирования специалистов. В большинстве случаев одно средство не может обеспечить все потребности проекта. Разработчики, как правило, применяют набор средств. Например, одно средство наилучшим образом подходит для анализа, а другое - для проектирования систем. В общем случае при выборе CASE-системы необходимо учитывать следующие аспекты.
· Наличие базы проектных данных, архива или словаря. СУБД и словари данных обеспечивают высокую степень интеграции данных и предоставляют широкие возможности для централизованного сбора, хранения и распределения проектной информации между различными этапами проекта и выполняемыми операциями.
· Интерфейсы с другими CASE-системами. В процессе проектирования ЭИС могут использоваться различные методологии, поэтому важно, чтобы используемые CASE-системы предоставляли возможности для эффективного использования нескольких методов. При этом должна быть обеспечена терминологическая совместимость различных методологий.
· Возможности экспорта/импорта. Спецификации, полученные на этапах анализа, проектирования и кодирования для одной ЭИС, могут быть использованы для проектирования другой системы. Повторное проектирование и кодирование могут быть обеспечены при помощи средств экспорта/импорта спецификаций в различные CASE-системы.
· Многопользовательский режим. Развитые CASE-системы должны обладать возможностями разделения полномочий персонала разработчиков и объединения отдельных работ в общий проект.
· Открытая архитектура. Открытая к доступу проектировщиков информация об используемых форматах файлов и интерфейсах должна позволять безболезненно переходить от одной CASE-системы к другой.
· Расширение новыми методологиями. Как и любое программное средство, CASE-система должна обладать возможностью совершенствоваться с учетом появления новых требований или новых предметных областей.
· Наличие графических средств поддержки методологий проектирования. Большинство CASE-систем базируется на графическом отображении методологий. Графические элементы структурных диаграмм и объекты словаря должны позволять декомпозировать различные компоненты проекта и детализировать изображения с той степенью, с какой это необходимо для понимания проектных решений.
· Обеспечение качества проектной документации. Это требование относится к возможностям CASE-системы анализировать и проверять описания и документацию на полноту и непротиворечивость, а также на соответствие принятым в данной методологии стандартам и правилам. В результате анализа должна формироваться информация, указывающая на имеющиеся противоречия или неполноту проектной документации, находящейся в архиве или словаре.
· Автоматическая генерация отчетов о проектных решениях. Решения (спецификации), созданные в процессе проектирования, служат источником документирования системы. Часто возникает потребность получения твердой копии спецификаций в текстовой или графической форме.
· Генерация кодов программ. CASE-системы с жесткой ориентацией на конкретные СУБД должны обеспечивать возможность генерации программ в среде этих СУБД.
· Планирование и управление проектом. Использование CASE-систем не исключает потребности в эффективном управлении проектом. Многие развитые CASE-системы имеют в своем составе средства планирования и управления проектом. Спецификации, которые используются этими средствами, представляют собой опорные точки управления, позволяющие определять сроки разработки.
