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

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

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

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

Страницы: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24