Значительно лучше соответствуют большой размерности задачи иерархические CASE-модели. Аббревиатура CASE (Computer-Aided Software/System Engineering) означает проектирование программного обеспечения или системы на основе компьютерной поддержки.
CASE-технология - актуальное и интенсивно развивающееся направление создания САПР в области программных продуктов и систем обработки информации. Практически ни один крупный зарубежный программный продукт не создается в настоящее время без использования CASE-средств.
Среди отечественных систем, созданных с использованием CASE-средств, следует отметить систему БОСС-КОРПОРАЦИЯ фирмы АйТи. На всех стадиях создания этой системы использовались средства разработки, относящиеся к семейству Oracle 2000 (Designer/2000, Developer/200, Programmer/2000).
Область применения CASE-технологий относится к созданию, прежде всего, экономических информационных систем, что объясняется массовостью этих систем.
Следует отметить, что CASE-технологий применяются не только для создания автоматизированных систем управления, но и для разработки моделей систем, помогающих в принятии решений в области стратегического планирования, управления финансами фирмы, обучения персонала и т.д. Это направление применения CASE-технологий получило свое собственное название - бизнес-анализ.
CASE-технологий применяются также там, где проблематика предметной области отличается большой сложностью, например, в разработке системного программного обеспечения.
Рассмотрим методологические основы CASE-технологий.
Основой CASE-методологии является моделирование. CASE-технология - это модельный метод автоматизации проектирования системы.
CASE-технология основана на парадигме: методология - метод - нотации - средства
Методология определяет общие подходы к оценке и выбору варианта системы, последовательность стадий и этапов проектирования, подходы к выбору методов.
Метод конкретизирует порядок проектирования отдельных компонентов системы (например, известны методы проектирования потоков данных в системе, задания спецификаций (описаний) процессов, представления структур данных в хранилище и т.д.).
Нотации - это графические средства обозначения и правила, предназначенные для описания структуры системы, этапов обработки информации, структуры данных и т. д. Нотации включают графы, диаграммы, таблицы, блок-схемы, формальные и естественные языки.
Наконец, средства - это инструментарии, средства автоматизации проектирования в виде программных продуктов для обеспечения интерактивного режима проектирования (создание и редактирование графического проекта информационной системы) и кодогенерацни программ (автоматического создания кодов программ системы).
Методология проектирования на основе компьютерной поддержки, очевидно, требует построения формализованного описания информационной системы в виде информационной модели. Построение CASE-модели системы предусматривает декомпозицию системы и иерархическое упорядочивание декомпозированных подсистем.
Модель системы должна отражать:
Функциональную часть системы;
Отношения между данными;
Переходы состояний системы при работе в реальном времени. Для моделирования информационной системы в трех указанных аспектах используются три разновидности графических средств с определенными нотациями.
1. Диаграммы потоков данных - DFD (Data Flow Diagrams). Они используются совместно со словарями данных и спецификациями процессов.
2. Диаграммы „сущность-связь" - ERD (Entity Relationship Diagrams), показывающие отношения между данными.
3. Диаграммы переходов состояний - STD (State Transitign Diagrams) для отражения зависящего от времени поведения системы (в режиме реального времени).
Ведущая роль в моделировании принадлежит DFD.
DFD предназначена для отражения взаимосвязей источников и приемников данных (так называемых внешних сущностей по отношению к информационной системе), потоков данных, процессов обработки (вычислительных процессов, соответствующих функциям системы), хранилищ данных (накопителей).
Графическое представление диаграммы потоков данных на экране дисплея обеспечивает наглядность моделирования и удобство корректировки основных компонентов модели в интерактивном режиме.
Поскольку графического представления недостаточно для точного определения компонентов DFD, используются текстовые описания и другие средства конкретизации процессов обработки и структуры данных.
Так, потоки данных конкретизируются в части их структуры в словарях данных. Каждый процесс (функция системы) может быть детализирована с помощью DFD нижнего уровня, где он разделяется на несколько процессов с одновременной детализацией потоков данных.
Детализация процессов заканчивается, когда описание каждого детализированного процесса может быть сделано с помощью выбранного метода написания алгоритма процесса. Спецификация процесса содержит номер и имя процесса, списки имен входных и выходных данных из словаря данных и алгоритм процесса, трансформирующий входные потоки данных во входные. В CASE-технологии используются такие методы задания алгоритмов процессов, как:
Текстовое описание;
Естественный структурированный язык;
Таблицы решений;
Деревья решений;
Визуальные языки;
Языки программирования.
Языки программирования (С, Cobol и др.) вызывают затруднения в написании алгоритмов применительно к DFD, поскольку требуют использования, помимо потоков данных, словарей данных, и требуют синхронной корректировки спецификаций процессов при корректировке DFD.
Структурированный естественный язык легко понимается не только проектировщиками и программистами, но и конечными пользователями. В этом его достоинство. Однако он не обеспечивает автоматической кодогенерации из-за наличия неоднозначностей.
Таблицы и деревья решений, наглядно отражая связь комбинации условий с необходимыми действиями, не обладают процедурными возможностями для кодогенерации программ.
Визуальные языки обеспечивают автоматическую кодогенерацию, но представленные с их помощью спецификации процессов сложно корректировать.
Содержимое каждого хранилища данных, представленного на диаграмме потока данных, описывается словарем данных и моделью данных ERD. В случае работы системы в реальном времени DFD дополняется STD.
Иерархическая структура CASE-модели представлена на рис. 11.9.
Важным методологическим принципом CASE-технологии создания информационной системы является четкое разделение процесса создания системы на 4 стадии:
Предпроектную (стадию анализа, прототипирования, и построения модели требовании к системе);
Проектную, предполагающую логическое проектирование системы (без программирования);
Стадию программирования (включая проектирование физической базы данных);
Послепроектную, включающую в себя ввод в действие, эксплуатацию и сопровождение системы.
На предпроектной стадии строится модель требований к системе, т. е. подробное описание того, что она должна делать, без указания путей реализации требований.
На проектной стадии происходит уточнение модели требований (разработка подробной иерархической модели на основе DFD и спецификаций процессов) и расширение ее до модели реализации на логическом уровне. В заключение этой стадии происходит тщательный контроль проекта на уровне логической модели реализации.
На следующей стадии (программирования) осуществляется физическое проектирование системы. Эта стадия предусматривает автоматическую кодогенерацию по спецификациям процессов программного обеспечения системы и физическое проектирование базы данных.
Заключительная послепроектная стадия начинается с приемосдаточных испытаний. Далее следуют ввод в постоянную эксплуатацию, сопровождение и развитие системы.
Последовательность операций создания информационной системы на основе CASE-технологии представлена на рис. 11.10.
Рассмотрим факторы эффективности CASE-технологии.
1. Следует отметить, что CASE-технология создает возможность и предусматривает перенос центра тяжести в трудоемкости создания системы на предпроектную и проектную стадии. Тщательная проработка этих стадий в интерактивном режиме с компьютерной поддержкой уменьшает число возможных ошибок в проектировании, исправлять которые на последующих стадиях затруднительно.
2. Доступная для понимания пользователей-непрограммистов графическая форма представления модели позволяет осуществить принцип пользовательского проектирования, предусматривающий участие пользователей в создании системы. CASE-модель позволяет достичь взаимопонимания между всеми участниками создания системы (заказчиками, пользователями, проектировщиками, программистами).
3. Наличие формализованной модели системы на предпроектной стадии создает возможность для многовариантного анализа с прототипированием и ориентировочной оценкой эффективности вариантов. Анализ прототипа системы позволяет скорректировать будущую систему до того, как она будет реализована физически. Этот подход ускоряет и удешевляет создание системы.
4. Закрепление в формализированном виде требований к системе избавляет проектировщиков от необходимости многочисленных корректировок по новым требованиям пользователей.
5. Отделение проектирования системы от программирования создает устойчивость проектных решений для реализации на разных программно-технических платформах.
6. Наличие формализованной модели реализации системы и соответствующих средств автоматизации позволяет осуществить автоматическую кодогенерацию программного обеспечения системы и создать рациональную структуру базы данных.
7. На стадии эксплуатации системы появляется возможность внесения изменений на уровне модели, не обращаясь к текстам программ, возможно, силами специалистов отдела автоматизации фирмы.
8. Модель системы может использоваться не только как основа ее создания, но и в целях автоматизированного обучения персонала с использованием диаграмм.
9. На основе модели действующей системы может выполняться бизнес-анализ для поддержки управленческих решений и бизнес-реинжиниринг при изменении направления деятельности фирмы.
Рассмотрим программные средства, обеспечивающие CASE-техно-логию. В зависимости от функционального назначения они подразделяются на следующие классификационные группировки, обеспечивающие:
Анализ и проектирование информационной системы;
Проектирование баз данных;
Программирование;
Сопровождение и реинжиниринг;
Управление процессом проектирования.
Средства анализа и проектирования служат для построения CASE-модели как действующей, так и реализуемой системы управления. Они поддерживают графическое построение и контроль иерархической модели диаграмм потоков данных и описание ее компонентов. Эти средства позволяют аналитикам и проектировщикам получить доступ к базе данных проектируемой системы (репозитарию).
К таким средствам относятся: отечественный пакет CASE. Аналитик, Design/IDEF (Meta Software), The Developer (ASYST Technologies) и др.
Для согласования требований пользователей создаются прототипы пользовательских интерфейсов, включающих в себя меню, экранные формы и отчеты в виде таблиц или графиков. Примером программного средства создания пользовательского интерфейса является Developer/2000 (Oracle).
Средства проектирования баз данных обеспечивают логическое моделирование данных, автоматическое преобразование моделей данных в третью нормальную форму и генерацию схем баз данных. Примерами таких средств является Designer/2000 фирмы Oracle, ERWin (Logic Works) и др.
Средства программирования поддерживают автоматическую кодогенерацию из спецификаций процессов, тестирование и документирование программы. К их числу относятся Programmer/2000 (Oracle), DECASE (DEC), APS (Sage Software) и др.
Средства сопровождения и реижиниринга позволяют вносить изменения в систему на уровне моделей при меняющихся условиях бизнеса (Adpac CASE Tools фирмы Adpac и др.).
Средства управления процессом проектирования поддерживают планирование и контроль выполнения комплекса проектных работ, а также взаимодействие аналитиков, проектировщиков и программистов на основе общей базы данных проекта (например, Project Workbench фирмы Applied Business Technology). Очевидна актуальность создания интегрированного пакета инструментальных средств поддержки CASE-технологии на всех этапах жизненного цикла информационной системы.
Что такое CASE-СРЕДСТВАCASE-средства (от англ.Computer-Aided Software
Engineering) -– это инструментальные средства
автоматизации проектирования ИС.
CASE-СРЕДСТВА это методы программной инженерии для
проектирования программного обеспечения, которые
позволяют обеспечить высокое качество программ,
отсутствие ошибок и простоту в обслуживании
программных продуктов.
Также под CASE понимают совокупность средств
проектирования информационных систем с
использованием CASE-инструментов.
CASE-средства позволяют не только создавать "правильные" продукты, но и обеспечить "правильный" процесс их создания. Основная цель CASE состоит в том, чтобы отделить проектирование ИС от его кодирования и последующих этапов разработки, а также скрыть от разработчиков все детали среды разработки и функционирования ИС. При использовании CASE-технологий изменяются все этапы жизненного цикла программного обеспечения (подробнее об этом будет сказано ниже) информационной системы, при этом наибольшие изменения касаются этапов анализа и проектирования. Большинство существующих CASE-средств основано на методологиях структурного (в основном) или объектно-ориентированного анализа и проектирования, использующих специ-фикации в виде диаграмм или текстов для описания внешних требований, связей между моделями системы, динамики поведения системы и архитектуры программных средств. Такие методологии обеспечивают строгое и наглядное описание про-ектируемой системы, которое начинается с ее общего обзора и затем детализируется, приобретая иерархическую структуру со все большим числом уровней. CASE-технологии успешно применяются для построения практически всех типов ИС, однако устойчивое положение они занимают в следующих областях:
Помимо автоматизации структурных методологий и, как следствие, возможности применения современных методов системной и программной инженерии, CASE-средства обладают следующими основными достоинствами:
Необходимо понимать, что успешное применение CASE-средств невозможно без понимания базовой технологии, на которой эти средства основаны. Сами по себе программные CASE-средства являются средствами автоматизации процес-сов проектирования и сопровождения информационных систем. Без понимания методологии проектирования ИС невозможно применение CASE-средств.
^
Характеристика современных CASE-средств
Современные CASE-средства охватывают обширную область поддержки многочисленных технологий проектирования ИС: от простых средств анализа и документирования до полномасштабных средств автоматизации, покрывающих весь жизненный цикл (ЖЦ) ИС.
Наиболее трудоемкими этапами разработки ИС являются этапы анализа и проектирования, в процессе которых CASE-средства обеспечивают качество принимаемых техни-ческих решений и подготовку проектной документации. При этом большую роль играют методы визуального представления информации. Это предполагает построение структурных или иных диаграмм в реальном масштабе времени, использование многообразной цветовой палитры, сквозную проверку синтаксических правил. Графические средства моделирова-ния предметной области позволяют разработчикам в наглядном виде изучать существующую ИС, перестраивать ее в соответствии с поставленными целями и имеющимися ограничениями.
В разряд CASE-средств попадают как относительно дешевые системы для персональных компьютеров с весьма ограниченными возможностями, так и дорогостоящие системы для неоднородных вычислительных платформ и операционных сред. Так, современный рынок программных средств насчитывает около 300 различных CASE-средств, наиболее мощные из которых, так или иначе, используются практически всеми ведущими западными фирмами.
Обычно к CASE-средствам относят любое программное средство, автоматизирующее ту или иную совокупность процессов жизненного цикла ИС и обладающее следующими основными характерными особенностями:
Охарактеризуем основные возможности CASE-средств на примере имеющей широкое распространение системы Silverrun.
CASE-средство Silverrun американской фирмы Computer Systems Advisers, Inc. (CSA) используется для анализа и про-ектирования ИС бизнес-класса и ориентировано в большей степени на спиральную модель ЖЦ. Оно применимо для поддержки любой методологии, основанной на раздельном построении функциональной и информационной моделей (диаграмм потоков данных и диаграмм "сущность-связь").
Настройка на конкретную методологию обеспечивается выбором требуемой графической нотации моделей и набора правил проверки проектных спецификаций. В системе имеются готовые настройки для наиболее распространенных методологий: DATARUN (основная методология, поддерживае-мая Silverrun), Gane/Sarson, Yourdon/DeMarco, Merise, Ward/Mellor, Information Engineering. Для каждого понятия, введенного в проекте, имеется возможность добавления собственных описателей. Архитектура Silverrun позволяет наращивать среду разработки по мере необходимости.
Silverrun имеет модульную структуру и состоит из четырех модулей, каждый из которых является самостоятельным продуктом и может приобретаться и использоваться без связи с остальными модулями.
Модуль построения моделей бизнес-процессов в форме диаграмм потоков данных (ВРМ - Business Process Modeler) позволяет моделировать функционирование обследуемой организации или создаваемой ИС. В модуле ВРМ обеспечена возможность работы с моделями большой сложности: автома-тическая перенумерация, работа с деревом процессов (вклю-чая визуальное перетаскивание ветвей), отсоединение и при-соединение частей модели для коллективной разработки. Диаграммы могут изображаться в нескольких предопределенных нотациях, включая Yourdon/DeMarco и Gane/Sarson. Имеется также возможность создавать собственные нотации, в том числе добавлять в число изображаемых на схеме дескрипторов определенные пользователем поля.
Модуль концептуального моделирования данных (ERX - Entity-Relationship eXpert) обеспечивает построение моделей данных "сущность-связь", не привязанных к конкретной реализации. Этот модуль имеет встроенную экспертную систему, позволяющую создать корректную нормализованную модель данных посредством ответов на содержательные вопросы о взаимосвязи данных. Возможно автоматическое построение модели данных из описаний структур данных. Анализ функциональных зависимостей атрибутов дает возможность проверить соответствие модели требованиям третьей нормальной формы и обеспечить их выполнение. Проверенная модель передается в модуль RDM.
Модуль реляционного моделирования (RDM- Relational Data Modeler) позволяет создавать детализированные модели "сущность-связь", предназначенные для реализации в ре-ляционной базе данных. В этом модуле документируются все конструкции, связанные с построением базы данных: индексы, триггеры, хранимые процедуры и т. д. Гибкая изменяемая нотация и расширяемость репозитория позволяют работать по любой методологии. Возможность создавать подсхемы соответствует подходу ANSI SPARC к представлению схемы базы данных . На языке подсхем моделируются как узлы распределенной обработки, так и пользовательские представле-ния. Этот модуль обеспечивает проектирование и полное документирование реляционных баз данных.
^ Менеджер репозитория рабочей группы (WRM - Workgroup Repository Manager) применяется как словарь данных для хранения общей для всех моделей информации, а также обеспечивает интеграцию модулей Silverrun в единую среду проектирования.
Платой за высокую гибкость и разнообразие изобразительных средств построения моделей является такой недостаток Silverrun, как отсутствие жесткого взаимного контроля между компонентами различных моделей (например, возможности автоматического распространения изменений между DFD различных уровней декомпозиции). Следует, однако, отметить, что этот недостаток может иметь существенное значение только в случае использования каскадной модели ЖЦ ИС.
Для автоматической генерации схем баз данных у Silverrun существуют мосты к наиболее распространенным СУБД: Oracle, Informix, DB2, Ingres, Progress, SQL Server, SQLBase, Sybase. Для передачи данных в средства разработки приложений имеются мосты к языкам 4GL: JAM, PowerBuilder, SQL Windows, Uniface, NewEra, Delphi. Все мосты позволяют загрузить в Silverrun RDM информацию из каталогов соответствующих СУБД или языков 4GL. Это позволяет доку-ментировать, перепроектировать или переносить на новые платформы уже находящиеся в эксплуатации базы данных и прикладные системы. При использовании моста Silverrun расширяет свой внутренний репозиторий специфичными для целевой системы атрибутами. После определения значений этих атрибутов генератор приложений переносит их во внутренний каталог среды разработки или использует при генерации кода на языке SQL. Таким образом, можно полностью определить ядро базы данных с использованием всех воз-можностей конкретной СУБД: триггеров, хранимых процедур, ограничений ссылочной целостности. При создании приложения на языке 4GL данные, перенесенные из репозитория Silverrun, используются либо для автоматической генерации интерфейсных объектов, либо для быстрого их создания вручную.
Для обмена данными с другими средствами автоматиза-ции проектирования, создания специализированных проце-дур анализа и проверки проектных спецификаций, составле-ния специализированных отчетов в соответствии с различными стандартами в системе Silverrun имеются три способа выдачи проектной информации во внешние файлы:
Помимо системы Silverrun, укажем назначение и дру-гих популярных CASE-средств и их групп.
Vantage Team Builder представляет собой интегрирован-ный программный продукт, ориентированный на реализацию каскадной модели ЖЦ ИС и поддержку полного ЖЦ ИС.
Uniface 6.1 – продукт фирмы Compuware (США) - представляет собой среду разработки крупномасштабных прило-жений в архитектуре "клиент-сервер".
CASE-средство Designer/2000 2.0 фирмы Oracle является интегрированным CASE-средством, обеспечивающим в со-вокупности со средствами разработки приложений Developer/ 2000 поддержку полного ЖЦ ИС для систем, использующих СУБД Oracle.
Пакет CASE/4/0 (microTOOL GmbH), включающий структурные средства системного анализа, проектирования и программирования, обеспечивает поддержку всего жизненного цикла разработки (вплоть до сопровождения), на основе сете-вого репозитория, контролирующего целостность проекта и поддерживающего согласованную работу всех его участников (системных аналитиков, проектировщиков, программистов).
^
Локальные средства
Пакет ERWin (Logic Works) используется при моделировании и создании баз данных произвольной сложности на ос-нове диаграмм "сущность-связь". В настоящее время ERWin является наиболее популярным пакетом моделирований дан-ных благодаря поддержке широкого спектра СУБД самых различных классов - SQL-серверов (Oracle, Informix, Sybase SQL Server, MS SQL Server, Progress, DB2, SQLBase, Ingress, Rdb и др.) и "настольных" СУБД типа xBase (Clipper, dBase, FoxPro, MS Access, Paradox и др.).
BPWin - средство функционального моделирования, реализующее методологию IDEFO. Модель в BPWin представляет собой совокупность SADT-диаграмм, каждая из которых описывает отдельный процесс, разбивая его на шаги и подпроцессы.
S-Designer 4.2 (Sybase/Powersoft) представляет собой CASE-средство для проектирования реляционных баз данных. По своим функциональным возможностям и стоимости он близок к CASE-средству ERWin, отличаясь внешне ис-пользуемой на диаграммах нотацией. S-Designer реализует стандартную методологию моделирования данных и генери-рует описание БД для таких СУБД, как Oracle, Informix, Ingres, Sybase, DB2, Microsoft SQL Server и др.
CASE-Аналитик 1.1 (Эйтекс) является практически един-ственным в настоящее время конкурентоспособным отече-ственным CASE-средством функционального моделирования и реализует построение диаграмм потоков данных в соответ-ствии с описанной ранее методологией.
^
Объектно-ориентированные CASE-средства
Rational Rose - CASE-средство фирмы Rational Software Corporation (США) - предназначено для автоматизации этапов анализа и проектирования ИС, а также для генерации кодов на различных языках и выпуска проектной документа-ции. Rational Rose использует синтез-методологию объектно-ориентированного анализа и проектирования, основанную на подходах трех ведущих специалистов в данной области: Буча, Рамбо и Джекобсона. Разработанная ими универсальная нотация для моделирования объектов (язык UML - Unified Modeling Language) является в настоящее время и, очевид-но, останется в будущем общепринятым стандартом в области объектно-ориентированного анализа и проектирования. Конкретный вариант Rational Rose определяется языком, на котором генерируются коды программ (C++, Smalltalk, PowerBuilder, Ada, SQLWindows и ObjectPro). Основной вариант – Rational Rose/C++ - позволяет разрабатывать проектную документацию в виде диаграмм и спецификаций, а также генерировать программные коды на C++. Кроме того, Rational Rose содержит средства реинжиниринга программ, обеспечивающие повторное использование программных компонент в новых проектах.
^
Средства конфигурационного управления
Цель конфигурационного управления (КУ) - обеспечить управляемость и контролируемость процессов разработки и сопровождения ИС. Для этого необходима точная и достоверная информация о состоянии ИС и его компонент в каждый момент времени, а также о всех предполагаемых и выполненных изменениях.
Для решения задач КУ применяются методы и средства, обеспечивающие идентификацию состояния компонент, учет номенклатуры всех компонент и модификаций системы в це-лом, контроль за вносимыми изменениями в компоненты, структуру системы и ее функции, а также координирован-ное управление развитием функций и улучшением характеристик системы.
Наиболее распространенным средством КУ является PVCS фирмы Intersolv (США), включающее ряд самостоятельных продуктов: PVCS Version Manager, PVCS Tracker, PVCS Configuration Builder и PVCS Notify.
^
Средства документирования
Для создания документации в процессе разработки АИС используются разнообразные средства формирования отчетов, а также компоненты издательских систем. Обычно средства документирования встроены в конкретные CASE-средства. Исключением являются некоторые пакеты, предоставляющие дополнительный сервис при документировании. Из них наиболее активно используется SoDA (Software Document Automation).
Продукт SoDA предназначен для автоматизации разработки проектной документации на всех фазах ЖЦ ИС. Он позволяет автоматически извлекать разнообразную информацию, получаемую на разных стадиях разработки проекта, и включать ее в выходные документы. При этом контролируется соответствие документации проекту, взаимосвязь документов, обеспечивается их своевременное обновление. Результи-рующая документация автоматически формируется из множества источников, число которых не ограничено.
Пакет включает в себя графический редактор для подготовки шаблонов документов. Он позволяет задавать необходимый стиль, фон, шрифт, определять расположение заголовков, резервировать места, где будет размещаться извлекаемая из разнообразных источников информация. Изменения автоматически вносятся только в те части документации, на которые они повлияли в программе. Это сокращает время подготовки документации за счет отказа от перегенерации всей документации.
SoDA реализована на базе издательской системы FrameBuilder и предоставляет полный набор средств по редактированию и верстке выпускаемой документации.
Итоговым результатом работы системы SoDA является готовый документ (или книга). Документ может храниться в файле формата SoDA (Frame Builder), который получается в результате генерации документа. Вывод на печать этого до-кумента (или его части) возможен из системы SoDA.
Среда функционирования SoDA - ОС типа UNIX на рабочих станциях Sun SPARCstation, IBM RISC System/6000 или Hewlett Packard HP 9000 700/800.
^
Средства тестирования
Под тестированием понимается процесс исполнения программы с целью обнаружения ошибок. Регрессионное тести-рование - это тестирование, проводимое после усовершен-ствования функций программы или внесения в нее изменений.
Одно из наиболее развитых средств тестирования QA (новое название – Quality Works) представляет собой интег-рированную, многоплатформенную среду для разработки автоматизированных тестов любого уровня, включая тесты регрессии для приложений с графическим интерфейсом пользователя.
QA позволяет начинать тестирование на любой фазе ЖЦ, планировать и управлять процессом тестирования, отображать изменения в приложении и повторно использовать тесты для более чем 25 различных платформ.
В заключение приведем пример комплекса CASE-средств, обеспечивающего поддержку полного ЖЦ ИС. Нецелесообразно сравнивать отдельно взятые CASE-средства, поскольку ни одно из них не решает в целом все проблемы создания и сопровождения ИС. Это подтверждается также полным набором критериев оценки и выбора, которые затрагивают все этапы ЖЦ ИС. Сравниваться могут комплексы методоло-гически и технологически согласованных инструментальных средств, поддерживающие полный ЖЦ ИС и обеспеченные необходимой технической и методической поддержкой со стороны фирм-поставщиков (отметим, что рациональное комплексирование инструментальных средств разработки ИС является важнейшим условием обеспечения качества этой ИС, причем это замечание справедливо для всех предметных областей).
Лекция №8
Многоуровневая архитектура 9
Интернет/интранет-технологии 10
Требования, предъявляемые к информационным системам 10
Гибкость 11
Надежность 11
Эффективность 11
Безопасность 12
Жизненный цикл информационных систем 16
Общие сведения об управлении проектами 17
^ Классификация проектов 18
Основные фазы проектирования информационной системы 18
Концептуальная фаза 19
Подготовка технического предложения 19
Проектирование 19
Разработка 20
Ввод системы в эксплуатацию 20
Процессы, протекающие на протяжении жизненного цикла информационной системы 21
^ Основные процессы жизненного цикла 21
Разработка 21
Эксплуатация 21
Сопровождение 22
Вспомогательные процессы жизненного цикла 23
Организационные процессы 23
Структура жизненного цикла информационной системы 23
Начальная стадия 24
Стадия уточнения 24
^ Стадия конструирования 24
Стадия передачи в эксплуатацию 24
Жизненный цикл информационных систем 28
Модели жизненного цикла информационной системы 28
^ Каскадная модель жизненного цикла информационной системы 29
Основные этапы разработки по каскадной модели 29
Основные достоинства каскадной модели 29
Недостатки каскадной модели 30
^ Спиральная модель жизненного цикла 31
Итерации 31
Преимущества спиральной модели 32
Недостатки спиральной модели 33
Методология и технология разработки информационных систем 37
Методология RAD 40
Основные особенности методологии RAD 40
^ Объектно-ориентированный подход 41
Визуальное программирование 42
Событийное программирование 43
Фазы жизненного цикла в рамках методологии RAD 44
Фаза анализа и планирования требований 44
Фаза проектирования 44
Фаза построения 45
Фаза внедрения 46
^ Ограничения методологии RAD 46
Методология и технология разработки информационных систем 51
Профили открытых информационных систем 51
Понятие профиля информационной системы 52
Принципы формирования профиля информационной системы 53
^ Структура профилей информационных систем 55
Профиль прикладного программного обеспечения 57
Профиль среды информационной системы 57
Профиль защиты информации 58
Профиль инструментальных средств 58
^ Методология и технология разработки информационных систем 63
Стандарты и методики 63
Виды стандартов 64
Методика CDM фирмы Oracle 65
Общая структура 66
Особенности методики СDМ 68
^ Международный стандарт ISO/IEC 12207: 1995-08-01 69
Общая структура 69
Основные и вспомогательные процессы ЖЦ 69
Особенности стандарта ISO 12207 71
CASE-технологии проектирования информационных систем 77
Характеристика современных CASE-средств 80
^ Локальные средства 86
Объектно-ориентированные CASE-средства 87
Средства конфигурационного управления 87
Средства документирования 87
Средства тестирования 88
Принципы построения и этапы проектирования баз данных 93
Основные понятия и определения 93
Описательная модель предметной области 99
^ Принципы построения и этапы проектирования баз данных 111
Концептуальные модели данных 111
Типы структур данных 112
Операции над данными 113
^ Ограничения целостности 114
Иерархическая модель данных 115
Сетевая модель данных 117
Реляционная модель данных 118
Бинарная модель данных 119
Семантическая сеть 119
Технология моделирования информационных систем 124
Методы моделирования систем 124
^ Математическая модель системы 126
Классификация математических моделей 128
Имитационные модели информационных систем 136
Методологические основы применения метода имитационного моделирования 136
^ Имитационные модели информационных систем 146
Классификация имитационных моделей 146
Структура типовой имитационной модели с календарем событий 153
^ Имитационные модели информационных систем 161
Технология моделирования случайных факторов 161
Генерация псевдослучайных чисел (ПСЧ) 161
Мультипликативный метод 163
Аддитивный метод 164
Смешанный метод 164
^ Моделирование случайных событий 165
Последовательное моделирование 167
Моделирование после предварительных расчетов 167
Имитационные модели информационных систем 172
Технология моделирования случайных факторов 172
^ Моделирование случайных величин 172
Моделирование непрерывных случайных величин 173
Метод обратной функции 173
Метод исключения (Неймана) 174
Метод композиции 176
Моделирование дискретных случайных величин 177
Метод последовательных сравнений 177
Метод интерпретации 178
^ Моделирование случайных векторов 178
Метод условных распределений 179
Метод исключения (Неймана) 180
Метод линейных преобразований 181
Имитационные модели информационных систем 187
Основы организации имитационного моделирования 187
^ Этапы имитационного моделирования 187
Испытание имитационной модели 188
Задание исходной информации 189
Верификация имитационной модели 189
Проверка адекватности модели 189
Калибровка имитационной модели 190
Исследование свойств имитационной модели 190
Оценка погрешности имитации, связанной с использованием в модели генераторов псевдослучайных чисел (ПСЧ) 190
Определение длительности переходного режима 191
Оценка устойчивости результатов имитации 192
Исследование чувствительности модели 192
^
Языки моделирования 193
На сегодняшний день проблема выбора наиболее подходящего и полностью удовлетворяющего поставленным целям и задачам CASE-средства представляется максимально актуальной в виду их широкого разнообразия и огромного спектра решений, который готов предложить разработчик для удовлетворения потребностей автоматизации. Целью данной статьи является ознакомление с существующими средствами, а также выделение наиболее значимых критериев для проведения сравнительного анализа.
Сравнение рассмотренных подходов в соответствии с выделенными критериями
Сравнение наиболее популярных в России CASE-средств
Среди индивидуальных особенностей каждого из средств можно охарактеризовать: возможность выдачи тремя способами проектной информации во внешние файлы для Silverrun , ориентацию на каскадную модель средства от компании Westmount – Vantage Team Builder, преимущество быстрого прототипирования, при взаимодействии этого средства с Uniface. Средства компании Oracle (Designer/Developer) обеспечивают полную поддержку ЖЦ. ERwin и BPwin, являясь средствами локальной автоматизации, имеют упрощенную структуру и имеют целевую направленность, в результате представляются одним из самых простых и удобный решений автоматизации. Объектно-ориентированные средства, такие как Rational Rose на сегодняшний день наиболее полно удовлетворяют задачам групповой работы.
В результате сравнения продуктов, можно сделать вывод о том, что средства, отвечающие структурному подходу (ERwin, BPwin), в основном находят свое применение на этапах определения требований к ИС. Такие средства подходят для осуществления глубокого анализа рассматриваемых процессов (Vantage Team Builder), позволяют максимально рационально расходовать ресурсы, вследствие независимости отельных компонент ПО (Oracle). Что касается объектно-ориентированных средств, стоит отметить, что методика их применения позволяет осуществлять проектирование любого типа, по средству универсальности и наглядности языка UML , который используется в рамках Rational Rose и Power Designer и является достаточно удобным инструментом для оперирования специалистами любого уровня подготовки.
Позиционирование подходов также можно провести по отношению к решению задачи моделирования бизнес-процессов на этапе анализа и проектирования (в соответствии с проведенным выше анализом) следующим образом:
В заключении, хочу сказать, что в силу распростарнения стандарта UML, возможно сейчас такой анализ уже не выглядит максимально актуальным, как это было несколько лет назад. Однако он достаточно наглядно отражает плюсы и минусы тех или иных средств в разрезе определенной методологии проектирования.
Теги: CASE-средства, CASE, проектирование, подход, методология, информационные системы, анализ, сравнение, критерии
Подходы к проектированию ИС.
Можно выделить два основных подхода к проектированию информационных систем:
· структурный
· процессный .
Структурный подход основан на использовании организационной структуры компании, когда проектирование системы идет по структурным подразделениям. Технологии деятельности в этом случае описываются через технологии работы структурных подразделений и их взаимодействия.
Если компания представляет собой сложную структуру типа холдинга, или предприятие-сеть, то необходимо также иметь модель взаимодействия всех входящих в него элементов, в которой будут отражены не только технологические, но также финансовые и юридические моменты.
Главным недостатком структурного подхода является привязка к организационной структуре, которая очень быстро меняется, поэтому в Системный проект информационной системы приходится часто вносить изменения. А изменение готовой ИС, как правило, достаточно трудоемкий, длительный и утомительный процесс.
Процессный подход ориентирован не на организационную структуру, а на бизнес-процессы, т.е. например фирма занимается поставкой оборудования, поставкой комплектующих и запасных частей, обслуживанием оборудования и т.д. Это и будут ее бизнес-процессы, которые должны быть проанализированы на 1-ом этапе проектирования ИС.
Процессный подход является более перспективным, т.к. бизнес-процессы, в отличие от организационной структуры, меняются реже. Причем основных бизнес-процессов на предприятии немного, обычно не более десяти.
В условиях современности сложность создания информационных систем очень высока. Поэтому при проектировании ИС в настоящее время стало широко использоваться CASE-технология.
CASE-технология – это программный комплекс, автоматизирующий весь технологический процесс анализа, проектирования, разработки и сопровождения сложных программных средств.
Современные CASE-средства охватывают обширную область поддержки многочисленных технологий проектирования ИС: от простых средств анализа и документирования до полномасштабных средств автоматизации, покрывающих весь жизненный цикл ПО.
Наиболее трудоемкими этапами разработки ИС являются этапы анализа и проектирования, в процессе которых CASE-средства обеспечивают высокое качество принимаемых технических решений и подготовку проектной документации. При этом большую роль играют графические средства моделирования предметной области, которые позволяют разработчикам в наглядном виде изучать существующую ИС, перестраивать ее в соответствии с поставленными целями и имеющимися ограничениями.
Интегрированные CASE-средства обладают следующими характерными особенностями :
· обеспечение управления процессом разработки ИС;
· использование специальным образом организованного хранилища проектных метаданных (репозитория).
Интегрированные CASE-средства содержат следующие компоненты:
· графические средства анализа и проектирования, используемые для описания и документирования ИС;
· средства разработки приложений, включая языки программирования и генераторы кодов;
· репозиторий, который обеспечивает хранение версий разрабатываемого проекта и его отдельных компонентов, синхронизацию поступления информации от различных разработчиков при групповой разработке, контроль метаданных на полноту и непротиворечивость;
· средства управления процессом разработки ИС;
· средства документирования;
· средства тестирования;
· средства реинжиниринга, обеспечивающие анализ программных кодов и схем баз данных и формирование на их основе различных моделей и проектных спецификаций.
Все современные CASE-средства делятся на две группы. Первую группу организуют средства встроенные в систему реализации, в которых все решения по проектированию и реализации привязаны к выбранной системе управления базами данных. Вторую группу организуют средства независимые от системы реализации, в которых все решения по проектированию ориентированы на унификацию начальных этапов жизненного цикла и средств их документирования. Данные средства обеспечивают большую гибкость в выборе средств реализации.
Основное достоинство CASE-технологии – поддержка коллективной работы над проектом за счет возможности работы в локальной сети, экспорта и импорта отдельных фрагментов проекта между разработчиками, организованного управления проектом.
В качестве этапов создания программных продуктов для информационных систем можно выделить следующие:
1. Определяется среда функционирования. На этом этапе определяются набор процессов жизненного цикла ИС, определяется область примененияИС, определяется размер поддерживаемых приложений, т.е. задается ограничения на такие величины, как количество строк программного кода, размер базы данных, количество элементов данных, количество объектов управления и т.д.
2. Производится построение диаграмм и графический анализ. На этом этапе строятся диаграммы, устанавливающие связь с источниками информации и потребителями, определяющие процессы преобразования данных и места их хранения.
3. Определяются спецификации и требования, предъявляемые к системе (вид интерфейса, тип данных, структура системы, качества, производительности, технические средства, общие затраты и т.д.).
4. Выполняется моделирование данных, т.е. вводится информация, описывающая элементы данных системы и их отношения.
5. Выполняетсямоделирование процессов, т.е. вводится информация, описывающая процессы системы и их отношения.
6. Выполняется проектирование архитектуры будущего ПО.
7. Выполняется имитационное моделирование, т.е. моделирование различных аспектов функционирования системы на основе спецификаций требований и/или проектных спецификаций.
8. Прототипирование, т.е. создается предварительный вариант всей системы или ее отдельных компонент.
9. Трассировка, выполняется анализ функционирования системы от спецификации требований до конечных результатов.
10. Выполняется генерация программного кода, его компиляция и отладка.
11. Тестирование полученных программных средств. Анализ и оценка полученных результатов.