20.Методологи dfd (диаграммы потоков данных)

DFD — общепринятое сокращение от англ. Data Flow Diagrams — диаграммы потоков данных. Так называется методология графического структурного анализа, описывающая внешние по отношению к системе источники и адресаты данных, логические функции, потоки данных и хранилища данных, к которым осуществляется доступ.

Диаграмма потоков данных (data flow diagram, DFD) — один из основных инструментов структурного анализа и проектирования информационных систем, существовавших до широкого распространения UML. Несмотря на имеющее место в современных условиях смещение акцентов от структурного к объектно-ориентированному подходу к анализу и проектированию систем, «старинные» структурные нотации по-прежнему широко и эффективно используются как в бизнес-анализе, так и в анализе информационных систем.

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

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

Кроме того, нотация DFD поддерживает понятие подсистемы — структурной компоненты разрабатываемой системы.

Нотация DFD — удобное средство для формирования контекстной диаграммы, то есть диаграммы, показывающей разрабатываемую АИС в коммуникации с внешней средой. Это — диаграмма верхнего уровня в иерархии диаграмм DFD. Ее назначение — ограничить рамки системы, определить, где заканчивается разрабатываемая система и начинается среда. Другие нотации, часто используемые при формировании контекстной диаграммы — диаграмма SADT, диаграмма.

21.ERD-диаграммы (диаграммы «сущность-связь»)

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

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

ОТНОШЕНИЕ в самом общем виде представляет собой связь между двумя и более сущностями. Именование отношения осуществляется с помощью грамматического оборота глагола (ИMEET, ОПРЕДЕЛЯЕТ, МОЖЕТ ВЛАДЕТЬ и т.п.).

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

• обеспечение хранения информации в единственном месте (даже если она используется в различных комбинациях);

• использование этой информации различными приложениями.

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

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

22.STD-диаграммы (диаграммы переходов состояний)

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

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

STD строится из следующих объектов.

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

Начальное состояние – узел STD, являющийся стартовой точкой для начального системного перехода.

Переход, который определяет перемещение моделируемой системы из одного состояния в другое.

Условие представляет собой событие, вызывающее переход и идентифицированное именем перехода..

Действие – это операция, которая может иметь место при выполнении перехода.

23.Требования к инструментальным средствам

Рассмотрим основные этапы проектирования ИС

1) описание бизнес-логики предметной области;

2) проектирование архитектуры ИС;

3) непосредственное создание;

4) тестирование;

5) сопровождение.

При выборе средств и методик проектирования необходимо учитывать следующее:

- ошибки, допущенные на предыдущей стадии проектирования, обходятся в 10 раз дороже, чем на текущей;

- жизненный цикл создания сложной ИС без использования инструментальных средств, сопоставим с ожидаемым временем ее эксплуатации;

- реализация проекта по созданию ИС предполагает коллективную работу;

- изменение внешних условий при проектировании ИС может потребовать внесения дорогостоящих изменений в проект.

^ Требования к инструментальным средствам:

1) средства должны автоматизировать начальные этапы проектирования;

2) средства должны в несколько раз уменьшать время на проектирование по сравнению с традиционными подходами;

3) средства должны быть достаточно гибкими к изменяющимся требованиям;

4) средства должны поддерживать коллективный режим работы.

24.BpWin

BPwin является мощным средством моделирования и документирования бизнес-процессов. Этот продукт использует технологию моделирования IDEF0 (Inte-gration Definition for Function Modeling) - наиболее распространенный стандарт, который принят для моделирования бизнес-процессов. Этот стандарт был разработан в лаборатории военно-воздушных сил США в 1981 году и успешно использовался для разработки систем противовоздушной обороны.

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

Основными элементами диаграммы являются активности и дуги (стрелки), которые изображают взаимосвязи и отношения активностей друг с другом. Дуги могут быть нескольких типов: вход, выход, управление и ресурсы. На каждой диаграмме обычно располагается от 3 до 6 активностей, это обусловлено тем, что такое количество активностей является оптимальным для восприятия сознанием. Модель BPwin представляет собой набор иерархически связанных и упорядоченных диаграмм, каждая из которых является конкретизацией (декомпозицией) активности предыдущего верхнего уровня. Каждая модель имеет одну диаграмму верхнего уровня, которая содержит только одну активность, определяющую общую функцию моделируемого процесса. Модели имеют так называемые "точки зрения" (point of view), определяющие ракурс, под которым рассматривается процесс. Например, для рассмотрения процесса может быть выбрана точка зрения начальника отдела компании, где происходит моделируемый процесс.

Кроме стандарта IDEF0, BPwin поддерживает также методологии моделирования DFD (data flow diagram) и IDEF3 (workflow). Методология DFD служит для описания потоков данных, которые возникают в результате деятельности компании. Методология IDEF3 служить для графического описания потока процессов (работ), взаимодействия процессов и объектов, которые изменяются этими процессами.

25.Классификация CASE-средств

Все CASE-средства делятся на типы, категории и уровни.

Классификация по типам отражает функциональную ориентацию CASE-средств в технологическом процессе:

1) анализ и проектирование. Средства данной группы используются для создания спецификаций системы и ее проектирования;

2) проектирование БД и файлов. Средства данной группы обеспечивают логическое моделирование данных.

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

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

5) окружение. Средства поддержки платформ для интеграции.

6) управление проектом. Средства, поддерживающие планирование, контроль, руководство, взаимодействие

Классификация по категориям определяет уровень интегрированности по выполняемым функциям и включает вспомогательные программы (tools), пакеты разработчика (toolkit) и инструментальные средства (workbench).

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

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

Категория workbench представляет собой интеграцию программных средств, которые поддерживают системный анализ, проектирование и разработку ПО;

Классификация по уровням связана с областью действия CASE в пределах жизненного цикла ПО.

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

Нижние (Lower) CASE являются средствами разработки ПО