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 поддерживает два уровня представления и моделирования – логический и физический. На логическом уровне модель БД описывается в терминах, наиболее приближенных к предметной области, не определяются типы данных, не подразумевается использование конкретной СУБД. Типы данных, целевая СУБД и т.д. определяются на физическом уровне.
... , практически, не используются. Проблема информатизации Минторга может быть решена путем создания Автоматизированной Информационной системы Министерства Торговли РФ (АИС МТ РФ) в соответствии с настоящим Техническим предложением. ГЛАВА 2. МАТЕМАТИЧЕСКОЕ ОБЕСПЕЧЕНИЕ КОМПЛЕКСА ЗАДАЧ "СИСТЕМА ДОКУМЕНТООБОРОТА УЧЕРЕЖДЕНИЯ”. функции поиска и архивации 2.1. Постановка задачи и её спецификация ...
... . В качестве средств разработки необходимо использование Borland C++ Builder 3.0 ClientServer, Microsoft Visual Basic for Applications. ГЛАВА 2. МАТЕМАТИЧЕСКОЕ ОБЕСПЕЧЕНИЕ СИСТЕМЫ ДОКУМЕНТООБОРОТА МИНТОРГА РФ. РЕШЕНИЕ ЗАДАЧ ИНФОРМАЦИОННОЙ БЕЗОПАСНОСТИ 2.1 Постановка задачи и её спецификация 2.1.1. Понятие информационной безопасности применительно к системе документооборота Минторга РФ Под ...
... 1 - 13 ВВЕДЕНИЕ Представленный дипломный проект является частью комплексного проекта по разработке автоматизированной системы управления процессом формирования и реализации целевых программ в некоммерческой организации. И содержит предложения по решению задачи автоматизации учета и документооборота в рамках разрабатываемой темы. Обратим внимание на актуальность автоматизации именно общей ...
... заполнения этих регистров подсчитывают итоги и выводят конечные сальдо, на основе чего заполняют Главную Книгу и балансы. Методика и организация учета расчетов с персоналом по оплате труда в ОАО «Ивица» проводится на должном уровне, за исключением того, что учет трудовых ресурсов и средств на оплату труда не атоматизирован полностью. Поэтому для облегчения труда бухгалтера, а также ...
0 комментариев