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