CASE-средства проектирования информационных систем

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

· Виды блюд.

· Персонал.

· Должности.

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

· Заказы.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Лекция 16-1 CASE-ТЕХНОЛОГИИ В СОЗДАНИИ ИС

Решение задач проектирования больших размерностей требует применения соответствующих методов и моделей. Иерархические CASE-модели (Computer-Aided Software/System Engineering - проектирование программного обеспечения/ системы на основе компьютерной поддержки) во многом отвечают предъявляемым к ним требованиям.

Практически ни один крупный зарубежный программный продукт не создается в настоящее время без использования 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-технологии создания информационной системы является четкое разделение процесса создания системы на 4 стадии:

Предпроектную (стадию анализа, прототипирования, и построения модели требовании к системе);

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

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

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

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

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

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

Достоинства 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 и др.).

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

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

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

ЛЕКЦИЯ

CASE-технологии компьютерного проектирования

План

- 1. CASE-технологии

1. CASE-технологии

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

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

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

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

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

· необходимость интеграции существующих и вновь разрабатываемых приложений;

· функционирование в неоднородной среде на нескольких аппаратных платформах;

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

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

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

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

· неадекватная спецификация требований;

· неспособность обнаруживать ошибки в проектных решениях;

· низкое качество документации, снижающее эксплуатационные качества;

· затяжной цикл и неудовлетворительные результаты тестирования.

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

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

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

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

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

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

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

2. CASE-средства. Общая характеристика и классификация

разработчик информационный формализованный проектирование

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

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

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

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

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

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

Интегрированное CASE-средство (или комплекс средств, поддерживающих полный ЖЦ ПО) содержит следующие компоненты;

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

· графические средства анализа и проектирования, обеспечивающие создание и редактирование иерархически связанных диаграмм (DFD, ERD и др.), образующих модели ИС;

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

· средства конфигурационного управления;

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

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

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

· средства реинжиниринга.

Все современные CASE-средства могут быть классифицированы в основном по типам и категориям. Классификация по типам отражает функциональную ориентацию CASE-средств на те или иные процессы ЖЦ. Классификация по категориям определяет степень интегрированности по выполняемым функциям и включает отдельные локальные средства, решающие небольшие автономные задачи (tools), набор частично интегрированных средств, охватывающих большинство этапов жизненного цикла ИС (toolkit) и полностью интегрированные средства, поддерживающие весь ЖЦ ИС и связанные общим репозиторием. Помимо этого, CASE-средства можно классифицировать по следующим признакам:

· применяемым методологиям и моделям систем и БД;

· степени интегрированности с СУБД;

· доступным платформам.

Классификация по типам в основном совпадает с компонентным составом CASE-средств и включает следующие основные типы:

· средства анализа (Upper CASE), предназначенные для построения и анализа моделей предметной области (Design/IDEF (Meta Software), BPwin (Logic Works));

· средства анализа и проектирования (Middle CASE), поддерживающие наиболее распространенные методологии проектирования и использующиеся для создания проектных спецификаций (Vantage Team Builder (Cayenne), Designer/2000 (ORACLE), Silverrun (CSA), PRO-IV (McDonnell Douglas), CASE.Аналитик (МакроПроджект)). Выходом таких средств являются спецификации компонентов и интерфейсов системы, архитектуры системы, алгоритмов и структур данных;

· средства проектирования баз данных, обеспечивающие моделирование данных и генерацию схем баз данных (как правило, на языке SQL) для наиболее распространенных СУБД. К ним относятся ERwin (Logic Works), S-Designor (SDP) и DataBase Designer (ORACLE). Средства проектирования баз данных имеются также в составе CASE-средств Vantage Team Builder, Designer/2000, Silverrun и PRO-IV;

· средства разработки приложений. К ним относятся средства 4GL (Uniface (Compuware), JAM (JYACC), PowerBuilder (Sybase), Developer/2000 (ORACLE), New Era (Informix), SQL Windows (Gupta), Delphi (Borland) и др.) и генераторы кодов, входящие в состав Vantage Team Builder, PRO-IV и частично - в Silverrun;

· средства реинжиниринга, обеспечивающие анализ программных кодов и схем баз данных и формирование на их основе различных моделей и проектных спецификаций. Средства анализа схем БД и формирования ERD входят в состав Vantage Team Builder, PRO-IV, Silverrun, Designer/2000, ERwin и S-Designor. В области анализа программных кодов наибольшее распространение получают объектно-ориентированные CASE-средства, обеспечивающие реинжиниринг программ на языке С++ (Rational Rose (Rational Software), Object Team (Cayenne)).

Вспомогательные типы включают:

· средства планирования и управления проектом (SE Companion, Microsoft Project и др.);

· средства конфигурационного управления (PVCS (Intersolv));

· средства тестирования (Quality Works (Segue Software));

· средства документирования (SoDA (Rational Software)).

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

· Vantage Team Builder (Westmount I-CASE);

· Designer/2000;

· CASE.Аналитик.

Кроме того, на рынке постоянно появляются как новые для отечественных пользователей системы (например, CASE /4/0, PRO-IV, System Architect, Visible Analyst Workbench, EasyCASE), так и новые версии и модификации перечисленных систем.

3. Основы методологии проектирования ИС

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

Основным нормативным документом, регламентирующим ЖЦ ПО, является международный стандарт ISO/IEC 12207 (ISO - International Organization of Standardization - Международная организация по стандартизации, IEC - International Electrotechnical Commission - Международная комиссия по электротехнике). Он определяет структуру ЖЦ, содержащую процессы, действия и задачи, которые должны быть выполнены во время создания ПО.

Структура ЖЦ ПО по стандарту ISO/IEC 12207 базируется на трех группах процессов:

· основные процессы ЖЦ ПО (приобретение, поставка, разработка, эксплуатация, сопровождение);

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

· организационные процессы (управление проектами, создание инфраструктуры проекта, определение, оценка и улучшение самого ЖЦ, обучение).

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

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

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

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

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

4. Структурный подход к проектированию ИС CASE средствами

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

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

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

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

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

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

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

· принцип непротиворечивости - заключается в обоснованности и согласованности элементов;

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

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

· SADT (Structured Analysis and Design Technique) модели и соответствующие функциональные диаграммы;

· DFD (Data Flow Diagrams) диаграммы потоков данных;

· ERD (Entity-Relationship Diagrams) диаграммы "сущность-связь".

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

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

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

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

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

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

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

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

Особенности проектирования информационных систем основанных на базах данных. Использование CASE-средств и описание бизнес процессов в BP-Win. Этапы проектирования современных информационных систем, виды диаграмм и визуальное представление web-сайта.

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

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

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

Использование CASE-средств для поддержки процессов создания и сопровождения информационных систем. Задачи графического редактора диаграмм, документатора и администратора проекта. Основные возможности IBM Rational Professional Bundle и IBM Rational Rose.

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

Жизненный цикл автоматизированных информационных систем. Основы методологии проектирования автоматизированных систем на основе CASE-технологий. Фаза анализа и планирования, построения и внедрения автоматизированной системы. Каскадная и спиральная модель.

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

Склад і зміст робіт на стадії впровадження інформаційних систем. Технологія проектування систем за CASE-методом. Порівняльні характеристики інформаційних систем в менеджменті та СППР. Створення бази моделей. Визначення інформаційних систем управління.

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

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

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

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

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

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

Значительно лучше соответствуют большой размерности задачи иерархические 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-модели системы предусматривает декомпозицию системы и иерархическое упорядочивание декомпозированных подсистем.

Модель системы должна отражать:

Функциональную часть системы;

Отношения между данными;

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

2. Диаграммы „сущность-связь" - ERD (Entity Relationship Diagrams), показывающие отношения между данными.

Ведущая роль в моделировании принадлежит DFD.

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

Графическое представление диаграммы потоков данных на экране дисплея обеспечивает наглядность моделирования и удобство корректировки основных компонентов модели в интерактивном режиме.

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

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

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

Текстовое описание;

Естественный структурированный язык;

Таблицы решений;

Деревья решений;

Визуальные языки;

Языки программирования.

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

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

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

Содержимое каждого хранилища данных, представленного на диаграмме потока данных, описывается словарем данных и моделью данных ERD. В случае работы системы в реальном времени DFD дополняется STD.

Иерархическая структура CASE-модели представлена на рис. 11.9.

Предпроектную (стадию анализа, прототипирования, и построения модели требовании к системе);

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

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

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

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

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

Последовательность операций создания информационной системы на основе CASE-технологии представлена на рис. 11.10.

Рассмотрим факторы эффективности CASE-технологии.

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

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

4. Закрепление в формализированном виде требований к системе избавляет проектировщиков от необходимости многочисленных корректировок по новым требованиям пользователей.

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

Анализ и проектирование информационной системы;

Проектирование баз данных;

Программирование;

Сопровождение и реинжиниринг;

Управление процессом проектирования.

К таким средствам относятся: отечественный пакет CASE. Аналитик, Design/IDEF (Meta Software), The Developer (ASYST Technologies) и др.

Средства сопровождения и реижиниринга позволяют вносить изменения в систему на уровне моделей при меняющихся условиях бизнеса (Adpac CASE Tools фирмы Adpac и др.).

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