Case средства разработки программного обеспечения. Применения CASE технологий. CASE средство: определения и общая характеристика

Что такое CASE-СРЕДСТВАCASE-средства (от англ.Computer-Aided Software
Engineering) -– это инструментальные средства
автоматизации проектирования ИС.
CASE-СРЕДСТВА это методы программной инженерии для
проектирования программного обеспечения, которые
позволяют обеспечить высокое качество программ,
отсутствие ошибок и простоту в обслуживании
программных продуктов.
Также под CASE понимают совокупность средств
проектирования информационных систем с
использованием CASE-инструментов.

Case средства

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

Функции проектирования, которые наиболее часто автоматизируемые в рамках CASE-средств:

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

Результат применения CASE-средств:

оптимизация структуры ИС;
снижение расходов на разработку;
повышение эффективности ИС;
снижение вероятности ошибок при
проектировании ИС.

Архитектура типового Case-средства

Репозиторий

Ядром любой системы проектирования ПО является репозиторий.
Репозиторий представляет собой специализированную БД,
которая используется для отображения состояния системы в любой момент
времени и содержит информацию о всех объектах проектной ИС:
Имена проектировщиков и их права доступа,
Организованные структуры,
Компоненты диаграмм и диаграммы в целом,
Структуры данных,
Взаимосвязи между диаграммами,
Программные модули, процедуры и библиотеки модулей.

Классификация Современных Case средств:

1. Классификация Case средств по
поддерживаемым методологиям:
-
функциональные или структурно-ориентированные;
-
объектно-ориентированные;
-
комплексно-ориентированные.

2. Классификация Современных Case средств по типам:

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

Примеры Case-средств различных типов:

Средства анализа (Design, BpWin);
Средства анализа и проектирования (Designer - Oracle);
Средства проектирования БД (ErWin, Designer - Oracle);
Средства разработки приложений (Developer – Oracle,
Delphi);
Средства реинженеринга (ErWin, Rational Rose).

3. Классификация Современных Case средств по категориям:

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

Другие виды классификации Case-средств:

4.
Классификация Case-средств по поддерживаем
графическим нотациям;
5.
Классификация Case-средств по степени
интегрированности отдельных инструментов;
6.
Классификация Case-средств по типу и архитектуре
используемой вычислительной техники;
7.
Классификация Case-средств по типу коллективной
разработки;
8.
Классификация Case-средств по типу используемой
операционной среды.

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

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

Case-средство Универсальный язык моделирования UML

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

Взаимосвязь диаграмм UML

Диаграмма вариантов
использования
Диаграмма
последовательности
Диаграмма
классов
Диаграмма
кооперации
Диаграмма
компонентов
Диаграмма
состояний
Диаграмма
развертывания
Диаграмма
видов деятельности

Case-средство IBM Rational Rose

Rational Rose - современное и мощное средство анализа,
моделирования и разработки программных систем,
охватывающее весь Жизненный цикл ПО
от анализа бизнес-процессов до кодогенерации на
заданном языке программирования.
Такой арсенал позволяет не только проектировать новую
информационную систему, но и доработать старую,
произведя процесс обратного проектирования.

Основные возможности пакета Rational Rose:

прямое и обратное проектирование на языках: ADA,
Java, С, C++, Basic;
поддержка технологий COM, DDL, XML;
возможность генерации схем БД Oracle и SQL.

Версии продукта Rational Rose:

Версия Rational Rose Modeler позволяет проводить анализ бизнес-процессов и
проектировать систему. Но не поддерживает кодогенерацию.
Версия Rational Rose Professional В зависимости от выбранного языка программирования
позволяет выполнять прямое и обратное проектирование. Заказывается только в
определенной конфигурации (например, Rose Professional С++ или Rose Professional С++
DataModeler). Не создает 100 % исполняемого кода. На выходе разработчик получает
каркасный код информационной системы на определенном (заказанном) языке
программирования, который впоследствии нужно еще дорабатывать.
Версия Rational Rose RealTime создана специально для получения 100 % исполняемого
кода в реальном масштабе времени, позволяет проводить прямое и обратное
проектирование на языках С или С++. На выходе модель автоматически компилируется
и собирается в исполняемый файл.
Версия Rational Rose Enterprise эта версия продукта покрывает весь спектр задач по
проектированию, анализу и кодогенерации. Поддерживаются все функции других
редакций, за исключением возможности 100 % кодогенерации.
Версия Rational Rose DataModeler вариант продукта по проектированию баз данных.
Функции DataModeler входят в состав Rose Enterprise или Professional.
В пакет MS Visual Studio 6.0 встроен Visual Modeler - усеченный вариант Rational Rose 98.

Дополнительная информация по пакету Rational Rose:

Бесплатной версии продукта Rational Rose не
существует;
для образовательных учреждений все программное
обеспечение IBM доступно бесплатно;
бесплатное использованиея в учебных целях возможно
в рамках программы IBM Academic Initiative.

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

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

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

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

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

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

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

CASE-технологии предлагают новый, основанный на автоматизации подход к концепции ЖЦ ПО. При использовании CASE изменяются все фазы ЖЦ, при этом наибольшие изменения касаются фаз анализа и проектирования.

В табл. 3.1 приведены оценки трудозатрат по фазам ЖЦ. В табл. 3.2 представлены основные изменения в ЖЦ при использовании CASE-технологий сравнению с традиционной разработкой.

Таблица 3.1

Оценки трудозатрат по базам жизненного цикла изделия. %

Таблица 3.2

Основные изменения в жизненном цикле изделия при использовании

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

Традиционная разработка	CASE-технология
Основные усилия направлены на кодирование и тестирование	Основные усилия направлены на анализ и проектирование
Бумажные спецификации	Быстрое итеративное прототипирование
Ручное кодирование	Автоматическая кодогенерация
Ручное документирование	Автоматическая генерация документации
Тестирование кодов	Автоматический контроль проекта
Сопровождение кодов	Сопровождение спецификаций проектирования

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

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

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

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

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

широкое использование базовых программных средств, получивших массовое распространение в других приложениях (БД и СУ БД, компиляторы с различных языков программирования, отладчики, документаторы, издательские системы, оболочки экспертных систем и базы знаний, языки четвертого поколения и др.);

автоматизированная или автоматическая кодогенерация, выполняющая несколько видов генерации кодов: преобразования для получения документации, формирования БД, ввода/модификации данных, получения выполняемых машинных кодов из спецификаций ПО, автоматической сборки модулей из словарей и моделей данных и повторно используемых программ, автоматической конверсии ранее используемых файлов в форматы, соответствующие новым требованиям;

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

доступность для разных категорий пользователей;

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

Интегрированный CASE-пакет в совокупности должен:

поддерживать графические модели;

контролировать ошибки;

организовывать и поддерживать репозитарии;

Поддерживать процесс проектирования и разработки.

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

Для CASE существенны четыре типа диаграмм:

диаграммы функционального проектирования (для этих целей наиболее часто употребляются DFD-диаграммы потоков данных);

диаграммы моделирования данных (как правило, ERD-диа- граммы "сущность-связь");

3) диаграммы моделирования поведения (как правило, STD-диаграммы переходов состояний);

4) структурные диаграммы (карты), применяемые на этапе про ектирования и описывающие отношения между модулями и внутри- модульную структуру,

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

Важность контроля ошибок на этапах анализа требований и проектирования спецификаций обусловлена возможностью их автоматического обнаружения на ранних этапах ЖЦ, CASE-средства обеспечивают автоматическую верификацию и контроль проекта на полноту и состоятельность на ранних этапах ЖЦ, что влияет на успех разработки в целом. В подтверждение можно привести следующие статистические данные, основанные на отчетах фирмы "TRW" по анализу пяти крупных проектов: при традиционной организации работ ошибки проектирования и кодирования составляют 64 и 32% от общего числа ошибок, соответственно. Обнаружить ошибки проектирования на этапе сопровождения ПО в 100 раз труднее, чем на этапах анализа требований и проектирования спецификаций.

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

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

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

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

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

корректное использование шагов обработки в методологиях.

Кодогенерация осуществляется на основе репозитария и позволяет автоматически построить до 80...90% объектных кодов или текстов программ на языках высокого уровня. Все CASE-средства делятся на типы, категории и уровни. Классификация по типам отражает функциональную ориентацию CASE-средств в технологическом процессе.

Анализ и проектирование. Средства этой группы используют для создания спецификаций системы и ее проектирования; они поддерживают широко известные методологии проектирования. К таким средствам относятся CASE. Аналитик (Эйтэкс), The Developer (ASYST Technologies), POSE (Computer Systems Advisers), ProKit *Workbench (McDonnell Douglas), Excelerator (Index Technology), Design-Aid (Nastec), Design Machine (Optima), MicroStep (Meta Systems), VS Designer (Visual Software), Analist/Designer (Yourdon), Design/IDEE (Meta Software), BPWin (Logic Works), SELECT (Select Software Tools), System Architect (Popkin Software & Systems), Westmount I-CASE Yourdon (West-mount Technology B. V. & CADRE Technologies), CASE/4/0 (mic-roTOOL GmbH). Их цель заключается в определении системных требований и свойств, которыми должна обладать система, а также создание проекта системы, удовлетворяющей этим требованиям и обладающей соответствующими свойствами. На выходе продуцируются спецификации компонентов системы и интерфейсов, связывающих эти компоненты, а также "калька" архитектуры системы и детальная "калька" проекта, включающая алгоритмы и определения структур данных.

Проектирование баз данных и файлов. Средства этой группы обеспечивают логическое моделирование данных, автоматическое преобразование моделей данных в форму, обеспечивающую автоматическую генерацию схем БД и описаний форматов файлов на уровне программного кода. В число таких средств входят: ERWin (Logic Works), Chen Toolkit (Chen & Associates), S-Designer (SDP), Designer/2000 (Oracle), Silverrun (Computer Systems Advisers).

Программирование. Средства этой группы поддерживают этапы программирования и тестирования, а также автоматическую кодогенерацию из спецификаций, получая полностью документированную выполняемую программу: COBOL 2/Workbench (Mikro Focus), DECASE (DEC), NETRON/CAP (Netron), APS (Sage Software). Помимо диаграммеров различного назначения и средств поддержки работы с репозитарием, в эту группу средств включены и традиционные генераторы кодов, анализаторы кодов (как в статике, так и в динамике), генераторы наборов тестов, анализаторы покрытия тестами, отладчики.

Сопровождение и реинжениринг. К таким средствам относятся документаторы, анализаторы программ, средства реструктурирования и реинжениринга: Adpac CASE Tools (Adpac), Scan/COBOL и Superstructure (Computer Data Systems), Inspector/Recoder (Language Technology). Их цель -корректировка, изменение, анализ, преобразование и реинжениринг существующей системы. Средства позволяют осуществлять поддержку всей системной документации (включая коды, спецификации, наборы тестов); контролировать покрытие тестами для оценки полноты тестируемости; управлять функционированием системы и т.п. Особый интерес представляют средства обеспечения мобильности (в CASE они получили название средств миграции) и реинжениринга.

Управление проектом. К этим средствам относятся поддерживающие планирование, контроль, руководство, взаимодействие, т.е. функции, необходимые в процессе разработки и сопровождения проектов: Project Workbench (Applied Business Technology).

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

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

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

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

· Виды блюд.

· Персонал.

· Должности.

· Постоянные клиенты.

· Заказы.

Модель строим на логическом уровне (см. рис. 2). Из рисунка 2 видно, что в модели проставлены связи. Рассмотрим их подробнее:

Таблица «Виды блюд» и таблица «Блюда» - установлена связь «один-ко-многим» при помощи первичного ключа «Код вида»;

Таблица «Должности» и таблица «Персонал» - установлена связь «один-ко-многим» при помощи первичного ключа «Код должности»;

Таблица «Блюда» и таблица «Заказы» - установлена связь «один-ко-многим» при помощи первичного ключа «Код блюда»;

Таблица «Персонал» и таблица «Заказы» - установлена связь «один-ко-многим» при помощи первичного ключа «Код работника»;

Таблица «Постоянные клиенты» и таблица «Заказы» - установлена связь «один-ко-многим» при помощи первичного ключа «Код клиента».

Рис. 2. Концептуальная модель данных

2.3 Разработка логической модели информационной системы

Базы данных и программные средства их создания и ведения (СУБД) имеют многоуровневую архитектуру, представление о которой можно получить из рисунка 1.

Схема 1 - Многоуровневое представление данных БД под

управлением СУБД

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

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

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

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

Проектирование базы данных состоит в построении комплекса взаимосвязанных данных. На рисунке 2 условно отображены этапы процесса проектирования базы данных.

Схема 2 - Этапы процесса проектирования базы данных

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

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

При связи один ко многим (1:М) одному экземпляру информации А соответствует 0, 1 или более экземпляров объекта В, но каждый экземпляр объекта В связан не более чем с одним экземпляром объекта А.

Примером связи 1:М служит связь между информационными объектами Фамилия – Оклад:

Фамилия Оклад

В базе данных информация хранится в виде двумерных таблиц. Можно так же импортировать и связывать таблицы из других СУБД или систем управления электронными таблицами. Одновременно могут быть открыты 1024 таблицы.

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

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

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

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

Е.Коддом выделены три нормальные формы отношений и предложен механизм, позволяющий любое отношение преобразовать к третьей (самой совершенной) нормальной форме.

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

Вторая нормальная форма. Чтобы рассмотреть вопрос приведения отношений ко второй нормальной форме, необходимо дать пояснения к таким понятиям, как функциональная зависимость и полная функциональная зависимость.

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

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

Такое определение функциональной зависимости позволяет при анализе всех взаимосвязей реквизитов предметной области выделить самостоятельные информационные объекты. В качестве примера рассмотрим графическое изображение функциональных зависимостей реквизитов работников, приведенное на рисунке 5, на котором ключевой реквизит указан звёздочкой.

Рисунок 1 - Графическое изображение функциональной зависимости реквизитов

В случае составного ключа вводится понятие функционально полной зависимости.

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

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

Третья нормальная форма. Понятие третьей нормальной формы основывается на понятии не транзитивной зависимости.

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

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

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

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

Целью работы является создание базы данных, обеспечивающей:

быстрый ввод новых данных;

хранения и поиск уже введённых данных;

печать необходимого количества персональных отчётов.

Данными являются:

Фамилия, имя, отчество;

Дата рождения;

Занимаемая должность;

Должностной оклад;

Количество фактических дней отработанных за месяц.

Рассмотрев определенные выше задачи можно спроектировать основные таблицы базы данных.

Для этого будем пользоваться средствами Database Desktop

В этой среде создадим все необходимые таблицы для разрабатываемой базы данных. Атрибутами в этой таблице будет:

Фамилия, Имя, Отчество, Дата принятия, Адрес, Телефон, Смены, Не выходы на работу, Ставка, зарплата.

Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.

Размещено на http://www.allbest.ru/

План

1. CASE средство: определения и общая характеристика

2. Применения CASE технологий: преимущества и недостатки

3. Внедрение CASE-средств

4. Примеры CASE-средств и их характеристики

1 . CASE средство: определения и общая характеристика

Аббревиатура CASE расшифровывается как Computer Aided Software Engineering. Этот термин широко используется в настоящее время. На этапе появления подобных средств, термин CASE употреблялся лишь в отношении автоматизации разработки программного обеспечения. Сегодня CASE средства подразумевают процесс разработки сложных ИС в целом: создание и сопровождение ИС, анализ, формулировка требований, проектирование прикладного ПО и баз данных, генерацию кода, тестирование, документирование, обеспечение качества, конфигурационное управление и управление проектом, а также другие процессы. Таким образом, CASE-технологии образуют целую среду разработки ИС. Итак, CASE-технология представляет собой методологию проектирования программных систем, а также набор инструментальных средств, позволяющих в наглядной форме моделировать предметную область, анализировать эту модель на всех этапах разработки и сопровождения ИС и разрабатывать приложения в соответствии с информационными потребностями пользователей. Большинство существующих CASE-средств основано на методологиях структурного или объектно-ориентированного анализа и проектирования, использующих спецификации в виде диаграмм или текстов для описания внешних требований, связей между моделями системы, динамики поведения системы и архитектуры программных средств. Главные составляющие CASE-продукта таковы:

· методология (Method Diagrams) , которая задает единый графический язык и правила работы с ним.

· графические редакторы (Graphic Editors) , которые помогают рисовать диаграммы; возникли с распространением PC и GUI, так называемых "upper case технологий

· генератор : по графическому представлению модели можно сгенерировать исходный код для различных платформ (так называемая low case часть CASE-технологии).

· репозиторий , своеобразная база данных для хранения результатов работы программистов

2 . Применения CASE технологий: преимущества и недостатки

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

Единая БД проекта. Основа CASE-технологии - использование базы данных проекта (репозитория) для хранения всей информации о проекте, которая может разделяться между разработчиками в соответствии с их правами доступа. Содержимое репозитория включает не только информационные объекты различных типов, но и отношения между их компонентами, а также правила использования или обработки этих компонентов. Репозиторий может хранить свыше 100 типов объектов: структурные диаграммы, определения экранов и меню, проекты отчетов, описания данных, логика обработки, модели данных, их организации и обработки, исходные коды, элементы данных и т. п.

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

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

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

Генерация документации. Вся документация по проекту генерируется автоматически на базе репозитория (как правило, в соответствии с требованиями действующих стандартов). Несомненное достоинство CASE-технологии заключается в том, что документация всегда отвечает текущему состоянию дел, поскольку любые изменения в проекте автоматически отражаются в репозитории (известно, что при традиционных подходах к разработке ПО документация в лучшем случае запаздывает, а ряд модификаций вообще не находит в ней отражения). Верификация проекта. CASE-технология обеспечивает автоматическую верификацию и контроль проекта на полноту и состоятельность на ранних этапах разработки, что влияет на успех разработки в целом - по статистическим данным анализа пяти крупных проектов фирмы TRW (США) ошибки проектирования и кодирования составляют соответственно 64% и 32% от общего числа ошибок, а ошибки проектирования в 100 раз труднее обнаружить на этапе сопровождения ПО, чем на этапе анализа требований. Автоматическая генерация объектного код а. Генерация программ в машинном коде осуществляется на основе репозитория и позволяет автоматически построить до 85-90% объектного кода или текстов на языках высокого уровня. Сопровождение и реинжинирин г. Сопровождение системы в рамках CASE-технологии характеризуется сопровождением проекта, а не программных кодов. Средства реинжиниринга и обратного инжиниринга позволяют создавать модель системы из ее кодов и интегрировать полученные модели в проект, автоматически обновлять документацию при изменении кодов и т. п.

Таблица 1

Традиционная технология разработки	Разработка с помощью CASE-технологий
Основные усилия - на кодирование и тестирование	Основные усилия - на анализ и проектирование
"Бумажные" спецификации	Быстрое итеративное макетирование
Ручное кодирование	Автоматическая генерация машинного кода
Тестирование ПО	Автоматический контроль проекта
Сопровождение программного кода	Сопровождение проекта

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

Таблица 2

В табл. 2 приведены оценки трудозатрат по фазам жизненного цикла программного обеспечения (ПО). Первая строка таблицы соответствует традиционной технологии разработки, вторая - разработке с использованием структурных методологий вручную, третья - разработке с использованием CASE-технологий. Для успешного внедрения CASE-средств организация должна обладать следующими качествами: * Технология. Понимание ограниченности существующих возможностей и способность принять новую технологию; * Культура. Готовность к внедрению новых процессов и взаимоотношений между разработчиками и пользователями; * Управление. Четкое руководство и организованность по отношению к наиболее важным этапам и процессам внедрения. Если организация не обладает хотя бы одним из перечисленных качеств, то внедрение CASE-средств может закончиться неудачей, независимо от степени тщательности следования различным рекомендациям по внедрению. Для того чтобы принять взвешенное решение относительно инвестиций в CASE-технологию, пользователи вынуждены производить оценку отдельных CASE-средств, опираясь на неполные и противоречивые данные. Эта проблема зачастую усугубляется недостаточным знанием всех возможных "подводных камней" использования CASE-средств. Среди наиболее важных проблем выделяют следующие: * достоверная оценка отдачи от инвестиций в CASE-средства затруднительна ввиду отсутствия приемлемых метрик и данных по проектам и процессам разработки ПО; * внедрение CASE-средств может представлять длительный процесс и не принести немедленной отдачи. Возможно даже краткосрочное снижение продуктивности в результате усилий, затрачиваемых на внедрение. Вследствие этого руководство организации-пользователя может утратить интерес к CASE-средствам и прекратить поддержку их внедрения; * отсутствие полного соответствия между теми процессами и методами, которые поддерживаются CASE-средствами, и теми, что используются в данной организации, может привести к дополнительным трудностям; * CASE-средства зачастую трудно использовать в комплексе с другими подобными средствами. Это объясняется как различными парадигмами, поддерживаемыми разнообразными средствами, так и проблемами передачи данных и управления от одного средства к другому; * некоторые CASE-средства требуют слишком много усилий для того, чтобы оправдать их использование в небольшом проекте, тем не менее, можно извлечь выгоду из той дисциплины, к которой обязывает их применение; * негативное отношение персонала к внедрению новой CASE-технологии может быть главной причиной провала проекта. Пользователи CASE-средств должны быть готовы к необходимости долгосрочных затрат на эксплуатацию, частому появлению новых версий и возможному быстрому моральному старению средств, а также постоянным затратам на обучение и повышение квалификации персонала. программный код репозиторий графический

3 . Внедрение CASE-средств

Процесс внедрения состоит из следующих этапов: * определение потребностей в CASE-средствах; * оценка и выбор CASE-средств; * выполнение пилотного проекта; * практическое внедрение CASE-средств. Определение потребностей в CASE-средствах можно проиллюстрировать следующей диаграммой. Данный этап включает достижение понимания потребностей организации и технологии последующего процесса внедрения CASE-средств. Он должен привести к выделению тех областей деятельности организации, в которых применение CASE-средств может принести реальную пользу. Результатом данного этапа является документ, определяющий стратегию внедрения. Процесс оценки и выбора CASE-средств можно рассмотреть в виде модели. Этот процесс может преследовать несколько целей и включать:* оценку нескольких CASE-средств и выбор одного или более из них; * оценку одного или более CASE-средств и сохранение результатов для последующего использования; * выбор одного или более CASE-средств с использованием результатов предыдущих оценок. Ниже приведена диаграмма, описывающая наиболее общую ситуацию оценки и выбора, а также показывает зависимость между ними. Входной информацией для процесса оценки является: * определение пользовательских потребностей; * цели и ограничения проекта; * данные о доступных CASE-средствах; * список критериев, используемых в процессе оценки. Результаты оценки могут включать результаты предыдущих оценок. При этом не следует забывать, что набор критериев, использовавшихся при предыдущей оценке, должен быть совместимым с текущим набором. Конкретный вариант реализации процесса (оценка и выбор, оценка для будущего выбора или выбор, основанный на предыдущих оценках) определяется перечисленными выше целями. Элементы процесса включают: * цели, предположения и ограничения, которые могут уточняться в ходе процесса; * потребности пользователей, отражающие количественные и качественные требования пользователей к CASE-средствам; * критерии, определяющие набор параметров, в соответствии с которыми производится оценка и принятие решения о выборе; * формализованные результаты оценок одного или более средств; * рекомендуемое решение (обычно либо решение о выборе, либо дальнейшая оценка). Перед полномасштабным внедрением выбранного CASE-средства в организации выполняется пилотный проект. Его цель - экспериментальная проверка правильности решений, принятых на предыдущих этапах, и подготовка к внедрению. Пилотный проект представляет собой первоначальное реальное использование CASE-средства и обычно подразумевает более широкий масштаб использования CASE-средства по отношению к тому, который был достигнут во время оценки. Пилотный проект должен обладать многими из характеристик реальных проектов, для которых предназначено данное средство. Он преследует следующие цели: * подтвердить достоверность результатов оценки и выбора;* определить, действительно ли CASE-средство годится для использования в данной организации, и если да, то определить наиболее подходящую область его применения; * собрать информацию, необходимую для разработки плана практического внедрения; * приобрести собственный опыт использования CASE-средства. Пилотный проект позволяет получить важную информацию, необходимую для оценки качества функционирования CASE-средства и его поддержки со стороны поставщика после того, как средство установлено. Его реализацию можно проиллюстрировать следующей схемой. Важной функцией пилотного проекта является принятие решения относительно приобретения или отказа от использования CASE-средства. Провал пилотного проекта позволяет избежать более значительных и дорогостоящих неудач в дальнейшем, поскольку он обычно связан с приобретением относительно небольшого количества лицензий и обучением узкого круга специалистов. Ну и, наконец, наступает переход к практическому использованию CASE-средств. Он начинается с разработки и последующей реализации плана перехода. План перехода должен включать следующее: * Информацию относительно целей, критериев оценки, графика и возможных рисков, связанных с реализацией плана. * Информацию относительно приобретения, установки и настройки CASE-средств. * Информацию относительно интеграции каждого средства с существующими средствами, включая как интеграцию CASE-средств друг с другом, так и их интеграцию в процессы разработки и эксплуатации ПО, существующие в организации. * Ожидаемые потребности в обучении и ресурсы, используемые в течение и после завершения процесса перехода. * Определение стандартных процедур использования средств. Реализация плана перехода требует постоянного мониторинга использования CASE-средств, обеспечения текущей поддержки, сопровождения и обновления средств по мере необходимости. Достигнутые результаты должны периодически подвергаться экспертизе в соответствии с графиком, а план перехода - корректироваться при необходимости. Необходимо постоянно уделять внимание удовлетворению потребностей организации и критериям успешного внедрения CASE-средств. Значимой и неотъемлемой частью реализации плана является также обучение и переобучение. Каждая категория сотрудников (например, администраторы средств, служба поддержки рабочих мест, интеграторы средств, служба сопровождения и разработчики приложений) нуждается в различном обучении. Обучение не должно замыкаться только на пользователях CASE-средств, обучаться должны и те сотрудники, на деятельность которых, так или иначе, оказывает влияние использование CASE-средств. При дальнейшем применении CASE-средств организация должна ориентироваться на обучение как сотрудников, вновь принятых на работу, так и специалистов, выполняющих проекты с использованием данных средств. Именно поэтому обучение должно стать неотъемлемой частью нормативных материалов, касающихся деятельности организации, которые предлагаются новым сотрудникам. Итогом данного этапа является внедрение CASE-средств в повседневную практику организации, при этом больше не требуется какого-либо специального планирования. Кроме того, поддержка CASE-средств включается в план текущей поддержки ПО в данной организации.

4 . Примеры CASE-средств и их характеристики

Silverrun

CASE-средство Silverrun американской фирмы Computer Systems Advisers, Inc. используется для анализа и проектирования ИС бизнес-класса. Оно применимо для поддержки любой методологии, основанной на раздельном построении функциональной и информационной моделей. Silverrun имеет модульную структуру и состоит из четырех модулей, каждый из которых является самостоятельным продуктом и может приобретаться и использоваться без связи с остальными модулями: модуль построения моделей бизнес-процессов, модуль концептуального моделирования данных, модуль реляционного моделирования и менеджер репозитория рабочей группы. Платой за высокую гибкость и разнообразие изобразительных средств построения моделей является такой недостаток Silverrun, как отсутствие жесткого взаимного контроля между компонентами различных моделей

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

· Ядро системы;

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

· JAM/RW - модуль генератора отчетов;

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

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

· Jterm - специализированный эмулятор X-терминала.

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

Vantage Team Builder

Vantage Team Builder представляет собой интегрированный программный продукт, ориентированный на реализацию каскадной модели ЖЦ ПО и поддержку полного ЖЦ ПО. Наличие универсальной системы генерации кода, основанной на специфицированных средствах доступа к репозиторию проекта, позволяет поддерживать высокий уровень исполнения проектной дисциплины разработчиками: жесткий порядок формирования моделей; жесткая структура и содержимое документации; автоматическая генерация исходных кодов программ и т.д. - все это обеспечивает повышение качества и надежности разрабатываемых ИС.

Локальные средства (ERwin, BPwin, S-Designor)

ERwin - средство концептуального моделирования БД, использующее методологию IDEF1X. ERwin реализует проектирование схемы БД, генерацию ее описания на языке целевой СУБД и реинжиниринг существующей БД. ERwin выпускается в нескольких различных конфигурациях, ориентированных на наиболее распространенные средства разработки приложений 4GL. Для ряда средств разработки приложений (PowerBuilder, SQLWindows, Delphi, Visual Basic) выполняется генерация форм и прототипов приложений. BPwin - средство функционального моделирования, реализующее методологию IDEF0. S-Designor представляет собой CASE-средство для проектирования реляционных баз данных. По своим функциональным возможностям и стоимости он близок к CASE-средству ERwin, отличаясь внешне используемой на диаграммах нотацией. S-Designor реализует стандартную методологию моделирования данных и генерирует описание БД для таких СУБД, как ORACLE, Informix, Ingres, Sybase, DB/2, Microsoft SQL Server и др.

Объектно-ориентированные CASE-средства (Rational Rose)

Rational Rose - CASE-средство фирмы Rational Software Corporation - предназначено для автоматизации этапов анализа и проектирования ПО, а также для генерации кодов на различных языках и выпуска проектной документации. Rational Rose использует синтез-методологию объектно-ориентированного анализа и проектирования, основанную на подходах трех ведущих специалистов в данной области: Буча, Рамбо и Джекобсона. Разработанная ими универсальная нотация для моделирования объектов (UML - Unified Modeling Language) претендует на роль стандарта в области объектно-ориентированного анализа и проектирования. Конкретный вариант Rational Rose определяется языком, на котором генерируются коды программ (C++, Smalltalk, PowerBuilder, Ada, SQLWindows и ObjectPro). Основной вариант - Rational Rose/C++ - позволяет разрабатывать проектную документацию в виде диаграмм и спецификаций, а также генерировать программные коды на С++. Кроме того, Rational Rose содержит средства реинжиниринга программ, обеспечивающие повторное использование программных компонент в новых проектах.

Размещено на Allbest.ru

Подобные документы

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

контрольная работа , добавлен 03.01.2011

Исследование объектно-ориентированного подхода к проектированию программного обеспечения будильника. Модель программного обеспечения. Взаимодействие между пользователями и системой. Диаграммы и генерация программного кода при помощи средств Rational Rose.

курсовая работа , добавлен 26.09.2014

Типы документации на программное обеспечение. Особенности создания документации в EA. Изучение метода генерации документации в формате RTF. Шаблоны как инструмент для настройки пользовательских требований и стилизации документации программного продукта.

реферат , добавлен 31.05.2013

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

отчет по практике , добавлен 29.12.2014

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

курсовая работа , добавлен 20.01.2010

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

дипломная работа , добавлен 03.05.2018

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

отчет по практике , добавлен 12.04.2015

Разработка программно-аппаратного комплекса на базе ПЭВМ типа Pentium IV, включающего в себя периферийное устройство для генерации сигнала в виде напряжения, меняющегося во времени, и программного обеспечения для управления процессом генерации.

дипломная работа , добавлен 30.06.2012

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

курсовая работа , добавлен 20.12.2012

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

Подходы к проектированию ИС.

Можно выделить два основных подхода к проектированию информационных систем:

· структурный

· процессный .

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

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

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

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

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

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

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

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

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

Интегрированные CASE-средства обладают следующими характерными особенностями :

· обеспечение управления процессом разработки ИС;

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

Интегрированные CASE-средства содержат следующие компоненты:

· графические средства анализа и проектирования, используемые для описания и документирования ИС;

· средства разработки приложений, включая языки программирования и генераторы кодов;

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

· средства управления процессом разработки ИС;

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

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

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

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

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

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

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

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

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

4. Выполняется моделирование данных, т.е. вводится информация, описывающая элементы данных системы и их отношения.

5. Выполняетсямоделирование процессов, т.е. вводится информация, описывающая процессы системы и их отношения.

6. Выполняется проектирование архитектуры будущего ПО.

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

8. Прототипирование, т.е. создается предварительный вариант всей системы или ее отдельных компонент.

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

10. Выполняется генерация программного кода, его компиляция и отладка.

11. Тестирование полученных программных средств. Анализ и оценка полученных результатов.