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 Dia­grams), показывающие отношения между данными.

3. Диаграммы переходов состояний - STD (State Transitign Dia­grams) для отражения зависящего от времени поведения системы (в режиме реального времени).

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

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

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

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

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

Важным методологическим принципом CASE-технологии создания информационной системы является четкое разделение процесса созда­ния системы на 4 стадии:

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

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

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

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

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

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

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

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

Достоинства CASE-технологии:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Средства анализа и проектирования служат для построения CASE-модели как действующей, так и реализуемой системы управления. Они поддерживают графическое построение и контроль иерархической модели диаграмм потоков данных и описание ее компонентов. Эти сред­ства позволяют аналитикам и проектировщикам получить доступ к базе данных проектируемой системы. К таким средствам относятся: отечественный пакет CASE. Аналитик, Design/IDEF (Meta Software), The Developer (ASYST Technologies) и др.

Для согласования требований пользователей создаются прототи­пы пользовательских интерфейсов, включающих в себя меню, экран­ные формы и отчеты в виде таблиц или графиков. Примером является Developer/2000 (Oracle).

Средства проектирования баз данных обеспечивают логическое мо­делирование данных, автоматическое преобразование моделей данных в третью нормальную форму и генерацию схем баз данных. Примера­ми таких средств является Designer/2000 фирмы Oracle, ERWin (Logic Works) и др.

Средства программирования поддерживают автоматическую кодогенерацию из спецификаций процессов, тестирование и документирование программы. К их числу относятся Programmer/2000 (Oracle), DECASE (DEC), APS (Sage Software) и др.

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

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

Обзор некоторых CASE-систем.

Список производителей CASE - инструментов и ряд полезных ссылок можно найти по адресу http://sunny.aha.ru/~belikov/index.htm, вопросам использования CASE посвящена русскоязычная конференция news://fido7.su.dbms.case/, в Internet также доступна книга Вендрова А.М. CASE-технологии. Современные методы и средства проектирования информационных систем..

Power Designer компании Sybase.

В состав Power Designer входят следующие модули:

· Process Analyst - средство для функционального моделирования, поддерживает нотацию Йордона - ДеМарко, Гейна - Сарсона и несколько других. Имеется возможность описать элементы данных (имена, типы, форматы), связанные с потоками данных и хранилищами данных. Эт элементы передаются на следующий этап проектирования, причем хранилища данных могут быть автоматически преобразованыв сущности.

· Data Analyst - инструмент для построения модели "сущность-связь" и автоматической генерации на ее основе реляционной структуры. Исходные данные для модели "сущность-связь" могут быть получены из DFD-моделей, созданных в модуле Process Analyst. В ER-диаграммах допускаются только бинарные связи, задание атрибутов у связей не поддерживается. Поддерживаются диалекты языка SQL примерно для 30 реляционных СУБД, при этом могут быть сгенерированы таблицы, представления, индексы, триггеры и т.д. В результате порождается SQL-сценарий (последовательность команд CREATE), выполнение которого создает спроектированную схему базы данных. Имеется также возможность установить соединение с СУБД через интерфейс ODBC. Другие возможности: автоматическая проверка правильности модели, расчет размера базы данных, реинжиниринг (построение модельных диаграмм для уже существующих баз данных) и т.д.

· Application Modeler - инструмент для автоматической генерации прототипов программ обработки данных на основе реляционных моделей, построенных в Data Analyst. Может быть получен код для Visual Basic, Delphi, а также для таких систем разработки в архитектуре "клиент-сервер" как PowerBuilder, Uniface, Progress и др. Генерация кода осуществляется на основе шаблонов, соответственно управлять генерацией можно за счет изменения соответствующего шаблона.

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

Silverrun компании Silverrun Technologies Ltd.

CASE-система Silverrun состоит из следующих инструментов:

· BPM - построение DFD-диаграмм. Поддерживает нотации Йордона-ДеМарко, Гейна - Сарсона, Уорда-Меллора и многие другие. Данный инструмент позволяет автоматически проверить целостность построенной модели, причем список критериев проверки определяется пользователем (например: отсутствие имен у элементов модели, потоки данных типа "хранилище - хранилище" или "внешняя сущность - внешняя сущность" и т.д.)

· ERX - построение диаграмм "сущность-связь". Поддерживаются не только бинарные связи, но и связи более высоких порядков, имеется возможность определения атрибутов у связей. Построенные ER-модели с помощью внешней утилиты могут быть сконвертированы в реляционный структуры (в той версии, с которой я работал, при этом, к сожалению, терялись атрибуты связей).

· RDM - инструмент реляционного моделирования, позволяет генерировать SQL-скрипты для создания таблиц и индексов примерно для 25 целевых СУБД.

Следует отметить, что компания Silverrun Technologies Ltd является не только разработчиком CASE - инструментария, но также создала собственную методологию создания информационных систем, получившую название Datarun. Эта методология включает описание всех этапов жизненного цикла информационной системы, перечень и последовательность работ, требования к содержанию и оформлению документов и многое другое.

Ознакомительную версию Silverrun, можно скачать с сервера комании Argussoft. В этой версии имеются ограничения на количество элементов в создаваемых моделях.

BPWin и ERWin компании LogicWorks.

LogickWorks выпускает два взаимнодополняющих инструмента проектирования информационных систем:

· BPWin - функциональное моделирование на основе методологии IDEF0. Допускается также использовние нотации IDEF3 и DFD в нотации Йордона - ДеМарко. Имеется возможность экспорта построенных моделей в системы функционально-стоимостного анализа (ABC - Activity Based Costing) и информационного моделирования ERWin.

· ERWin - средство информационного моделирования, используется нотация IDEF1X. Поддерживаются свыше 20 целевых СУБД, имеется возможность генерации прототипов прикладных программ для Visual Basic, Delphi и т.д.

Использование SilverRun

Методология

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

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

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

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

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

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

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

· небольшую команду программистов (от 2 до 10 человек);

· короткий, но тщательно проработанный производственный график (от 2 до 6 мес.);

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

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

Жизненный цикл ПО по методологии RAD состоит из четырех фаз:

· фаза анализа и планирования требований;

· фаза проектирования;

· фаза построения;

· фаза внедрения.

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

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

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

· общая информационная модель системы;

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

· точно определенные с помощью CASE-средства интерфейсы между автономно разрабатываемыми подсистемами;

· построенные прототипы экранов, отчетов, диалогов.

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

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

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

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

· определяется необходимость распределения данных;

· производится анализ использования данных;

· производится физическое проектирование базы данных;

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

· определяются способы увеличения производительности;

· завершается разработка документации проекта.

Результатом фазы является готовая система, удовлетворяющая всем согласованным требованиям.

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

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

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

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

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

В качестве итога перечислим основные принципы методологии RAD:

· разработка приложений итерациями;

· необязательность полного завершения работ на каждом из этапов жизненного цикла;

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

· необходимое применение CASE-средств, обеспечивающих целостность проекта;

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

· необходимое использование генераторов кода;

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

· тестирование и развитие проекта, осуществляемые одновременно с разработкой;

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

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

Структурный подход

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Лекция 8. Case средства разработки информационных систем

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

хорошую работу на сайт">

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

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

Автоматизированное проектирование ИС (CASE-технология)

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

Основные черты CASE-технологии

Назначение : автоматизация проектирования сложных информационных систем.

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

CASE-средства охватывают все стадии ЖЦ ИС (анализ, проектирование, разработка, сопровождение).

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

Цели использования CASE-технологии в индустриальном проектировании ИС

Улучшение качества разрабатываемой ИС за счет автоматического контроля и генерации отдельных элементов;

Возможность повторного использования компонентов разработки;

Повышение уровня адаптивности и качества сопровождения ИС;

Использование методологии прототипного проектирования;

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

Возможность коллективной разработки ИС в режиме реального времени.

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

Метод - процедура или техника генерации описания компонентов ИС (например, метод проектирования потоков данных).

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

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

Инструментальные средства - CASE-средства

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

Общая архитектура системы CASE-средств включает в себя следующие элементы:

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

Проектировщиков и их прав доступа к различным компонентам системы;

Организационных структур;

Диаграмм, компонентов диаграмм и связей между диаграммами;

Структур данных;

Программных модулей, процедур, библиотек и т.п.

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

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

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

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

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

Инициализация проекта;

Задание начальных параметров проекта;

Назначение и управление правами доступа к отдельным элементам проекта;

Мониторинг выполнения проекта.

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

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

По области действия в пределах ЖЦ ИС

Upper CASE - средства, используемые на стадии анализа предметной области;

Middle CASE - средства, используемые на стадии анализа и проектирования структуры ИС;

Примечание. В настоящее время в зарубежной литературе имеет место тенденция объединять средства Upper и Middle CASE в одну группу (Upper CASE).

Lower CASE - средства, используемые на стадиях разработки и внедрения (тестирования).

I-CASE - интегрированная система CASE-средств, которая может использоваться как на ранних, так и на поздних стадиях ЖЦ ИС (т.е. объединяет возможности Upper- и Lower- CASE).

По функциональному назначению:

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

Средства проектирования баз данных (моделирование данных и генерация схем БД);

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

Средства обратного инжиниринга (построение моделей действующей ИС для ее переноса в другую среду);

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

Средства управления тестированием ПО;

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

По поддерживаемым методологиям проектирования:

Функционально-ориентированные;

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

Комплексные (поддерживают различные методологии).

По степени интеграции:

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

Частично интегрированные наборы средств, охватывающие несколько стадий разработки ИС;

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

По реализованной архитектуре:

Локальные;

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

Методологии проектирования ИС с использованием CASE-средств

В настоящее время существует два основных подхода к проектированию, которые мы уже упоминали:

Функционально-ориентированный (структурный);

Объектно-ориентированный.

В основе функционально-ориентированного подхода лежат две идеи:

Декомпозиция;

Графическое представление.

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

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

Диаграммы SADT (диаграммы работ и объектов).

Диаграммы потоков данных (DFD).

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

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

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

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

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

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

все ли состояния определены и имеют уникальное имя?

все ли состояния достижимы?

все ли состояния имеют выход?

реагирует ли система соответствующим об-разом на все возможные условия (особенно на ненормальные)?

все ли входные (выходные) потоки управляющего процесса отражены в условиях диаграммы?

Примеры диаграммы переходов состояний

Диаграммы состояний UML.

Диаграммы инфологических моделей «сущность-связь».

System Structure Diagram (SSD) - Диаграммы структуры программного приложения ИС. Представляют собой иерархическую взаимосвязь программных модулей, которые реализуют ИС. Диаграмма SSD служит «мостом» для перехода от системных требований, которые отображены в таких диаграммах, как BFD, DFD, ERD и STD, к реализации информационной системы.

Основные черты объектно-ориентированного проектирования

Предметная область моделируется как совокупность взаимодействующих во времени объектов;

Процесс обработки информации представляется как последовательность взаимодействий этих объектов;

Данные и операции моделируются совместно (неразрывно друг от друга);

За основу принимается спиральная модель проектирования. Модели предметной области накапливаются в репозитории и постепенно уточняются.

На основе сформированных моделей может быть автоматически сгенерирована система классов для программного приложения ИС;

Для моделирования широко используется унифицированный язык моделирования UML (Unified Modeling Language).

Самостоятельно:

Изучить, какие основные диаграммы включает в себя система объектно-ориентированных моделей в соответствии с нотациями UML;

Изучить общую характеристику и назначение каждой диаграммы;

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

Рассмотреть общую схему проектирования экономических ИС в рамках объектно-ориентированного подхода.

case проектирование информационный система

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

Рис.1 . Пример диаграммы перехода состояний.

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

...

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

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

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


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

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


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

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


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

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


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

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


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

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


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

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


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

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


Основные методологии проектирования, модели жизненного цикла локальных систем, сущность структурного подхода. Моделирование потоков процессов и программные средства поддержки их жизненного цикла. Характеристика и технология внедрения CASE средств.

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


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