Автоматизированное проектирование ИС (CASE-ТЕХНОЛОГИЯ)

1.3.3 Автоматизированное проектирование ИС (CASE-ТЕХНОЛОГИЯ)

Основные понятия и классификация CASE-технологий

Термин CASE (Computer Aided System/Software Engineering) используется в довольно

широком смысле. Первоначальное значение термина CASE, ограниченное вопросами

автоматизации разработки только лишь программного обеспечения, в настоящее время

приобрело новый смысл, охватывающий процесс разработки сложных ИС в целом.

С самого начала CASE-технологии развивались с целью преодоления ограничений при

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

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

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

Преимущества CASE-технологии по сравнению с традиционной технологией оригинального проектирования

сводятся к следующему:

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

контроля и генерации;

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

- поддерживание адаптивности и сопровождения ИС;

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

прототип будущие системы и оценить его;

- освобождение разработчиков от рутинной работы по документированию проекта, так как при этом

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

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

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

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

Метод - это процедура или техника генерации описаний компонентов ЭИС (например, проектирование

потоков и структур данных).

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

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

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

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

- создавать элементы диаграмм и взаимосвязи между ними;

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

- задавать описания связей между элементами диаграмм;

- редактировать элементы диаграмм, их взаимосвязи и описания.

Верификатор диаграмм служит для контроля правильности построения диаграмм в заданной методологии

проектирования ЭИС. Он выполняет следующие функции:

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

- диагностику и выдачу сообщений об ошибках;

- выделение на диаграмме ошибочных элементов.

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

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

Администратор проекта представляет собой инструменты, необходимые для выполнения следующих функции:

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

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

- назначения и изменения прав доступа к элементам проекта;

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

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

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

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

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

Наиболее известными CASE-средствами для моделирования деловых процессов относятся ERwin, BPwin, Silverrun,

Oracle Designer, Rational Rose и др. Основы функциональной возможности инструментальных средств структурного

моделирования деловых процессов будут рассмотрены на примере CASE-средства BPwin.

Моделирование в BPwin.

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

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

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

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

Процесс моделирования системы IDEFO начинается с создания контексной диаграммы - диаграммы наиболее абстрактного уровня описания системы в целом (рис.5.1).

DFD (Data Flow Diagraming)- движение потоков информации (документооборота) в системе. Диаграммы DFD могут дополнить то, что уже отражено в модели IDEF0 , поскольку они описывают потоки данных, позволяя проследить, каким образом происходит

 обмен информации между функцими внутри системы.

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

Моделирование данных

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

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

Разработка БД выполняется с помощью моделирования данных. Цель моделирования данных состоит в обеспечении разработки ИС концептуальной схемы БД в форме одной модели или нескольких локальных моделей, которые относительно легко могут быть отражены в любую систему БД. Наиболее распространенным средством моделирования данных (представления БД) является диаграмма «сущность-связь» (Entity-Relationship), которая также известна как ER- диаграмма (или ERD).

ER- диаграммы был приняты в качестве основы для создания стандарта IDEFIX. Предварительный вариант этого стандарта был разработан в военно-воздушных силах США и предназначен для увеличения производительности при разработке компьютерных систем. В 1981 г. Этот стандарт был формализован и опубликован организацией ICAM (Integrated Computed Aided Manufacturing), и с тех пор является наиболее распространенным стандартом для создания моделей БД по всему миру.

Базовые понятия ERD

Сущность (Entity) – множество экземпляров реальных или абстрактных объектов (людей, событий, состояний, идей, предметов и др.), обладающих общими атрибутами или характеристиками. Любой объект системы может быть представлен только одной сущностью, которая должна быть уникально идентифицирована. При этом имя сущности должно отражать тип или класс объекта, а не его конкретный экземпляр (например, АЭРОПОРТ, а не ВНУКОВО).

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

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

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

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

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

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

Атрибут (Atribute) – любая характеристика сущности, значимая для рассматриваемой предметной области и предназначена для квалификации, идентификации, классификации, количественной характеристики или выражения состояния сущности. Атрибут представляет тип характеристик или свойств, ассоциированных с множеством реальных или абстрактных объектов (людей, мест, событий, состояний, идей, предметов и т.д.). Экземпляр атрибута – это определенная характеристика отдельного элемента множества. Экземпляр атрибута определяется типом характеристики и ее значением, называемым значением атрибута. На диаграмме «сущность-связь» атрибуты ассоциируются с конкретными сущностями. Таким образом, экземпляр сущности должен обладать единственным определенным значением для ассоциативного атрибута.

Проектирование БД при помощи Erwin

Наиболее распространенными методами для построения ERD является метод Баркера и мтод IDEF1.

Метод Баркера основан на нотации, предложенной автором, и используется в case- средства Oracle Designer.

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

IDEFIX –диаграммы используются в ряде распространенных case-средств, в частности Erwin, Design/IDEF/

Функциональная модель бизнес-процесса, представленная в BPwin, является основой для построения модели данных. Хорошим инструментом для такого построения является ErWin – средство разработки структуры БД. При этом функциональная ERWinмодель используется в качестве проектной документации.

ERWin имеет удобный графическтй Windows-интерфейс, инструменты для построения ER-диаграмм, редакторы для создания логического и физического описания модели данных, а также поддержку многих реляционных СУБД (в том числе и Access)/ ERWin поддерживает два уровня представления и моделирования – логический и физический. На логическом уровне модель БД описывается в терминах, наиболее приближенных к предметной области, не определяются типы данных, не подразумевается использование конкретной СУБД. Типы данных, целевая СУБД и т.д. определяются на физическом уровне.

Похожие работы

Математическое обеспечение комплекса задач “Автоматизированная система документооборота учереждения

Скачать

200314

8

2

... , практически, не используются. Проблема информатизации Минторга может быть решена путем создания Автоматизированной Информационной системы Министерства Торговли РФ (АИС МТ РФ) в соответствии с настоящим Техническим предложением.   ГЛАВА 2. МАТЕМАТИЧЕСКОЕ ОБЕСПЕЧЕНИЕ КОМПЛЕКСА ЗАДАЧ "СИСТЕМА ДОКУМЕНТООБОРОТА УЧЕРЕЖДЕНИЯ”. функции поиска и архивации 2.1. Постановка задачи и её спецификация ...

Обеспечение системы документооборота

Скачать

164313

27

1

... . В качестве средств разработки необходимо использование Borland C++ Builder 3.0 ClientServer, Microsoft Visual Basic for Applications. ГЛАВА 2. МАТЕМАТИЧЕСКОЕ ОБЕСПЕЧЕНИЕ СИСТЕМЫ ДОКУМЕНТООБОРОТА МИНТОРГА РФ. РЕШЕНИЕ ЗАДАЧ ИНФОРМАЦИОННОЙ БЕЗОПАСНОСТИ 2.1 Постановка задачи и её спецификация 2.1.1. Понятие информационной безопасности применительно к системе документооборота Минторга РФ Под ...

АСУ целевыми программами в некоммерческой организации

Скачать

194189

21

0

... 1 - 13 ВВЕДЕНИЕ Представленный дипломный проект является частью комплексного проекта по разработке автоматизированной системы управления процессом формирования и реализации целевых программ в некоммерческой организации. И содержит предложения по решению задачи автоматизации учета и документооборота в рамках разрабатываемой темы. Обратим внимание на актуальность автоматизации именно общей ...

Учет расчетов с персоналом по оплате труда и анализ эффективности использования средств на оплату труда в торговой организации

Скачать

162009

28

0

... заполнения этих регистров подсчитывают итоги и выводят конечные сальдо, на основе чего заполняют Главную Книгу и балансы. Методика и организация учета расчетов с персоналом по оплате труда в ОАО «Ивица» проводится на должном уровне, за исключением того, что учет трудовых ресурсов и средств на оплату труда не атоматизирован полностью. Поэтому для облегчения труда бухгалтера, а также ...