47889 (608403), страница 13

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

Текст из файла (страница 13)

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

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

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

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

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 поддерживает два уровня представления и моделирования – логический и физический. На логическом уровне модель БД описывается в терминах, наиболее приближенных к предметной области, не определяются типы данных, не подразумевается использование конкретной СУБД. Типы данных, целевая СУБД и т.д. определяются на физическом уровне.

1.3.4 Реинженеринг бизнес-процессов и проектирование корпоративной ИС

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

Основы реинженеринга бизнес-процессов на основе корпоративной ИС

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

Рис.3. Материальные, финансовые и информационные потоки бизнес-процесса

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

Разработка корпоративных ИС, встраиваемых новых ИТ в бизнес-процессы организация, привело к возникновению так называемых киберкорпораций (рис. 3.1), постоянно и гибко реконструирующих свой бизнес.

Это встраивание является основанием для переосмысления и переконструктизации самих бизнес-процессов дают возможность поведения инженеринга и реинженеринга бизнес-процессов (РБП).

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

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

Капитал корпорации

Основные фонды, оборотные средства, связи с партнёрами, нематериальные активы

Бизнес-платформа

корпорации

Миссия предприятия, бизнес-стратегия, рынки, технология основного производства

ИС как

основная

действу

ю

Сотрудники (директор, менеджер, консультант и др.)

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

ИТ-платформы и ИТ-архитектура, в том числе:

АРМы сотрудников (функции: ведение учёта, справки, документооборот, поддержка принятия решений, планирование, доступ ко всей нужной информации), обеспечение АРМов: БД, сети, серверы и другие компоненты ИТ-архитектуры

щая

Характеристики

Список файлов курсовой работы