Знакомство с технологией структурного анализа и проектирования SADT, на примере CASE-системы BPWin 4.0

Лабораторная  работа 3. Знакомство с технологией  структурного анализа и проектирования SADT, на примере CASE-системы BPWin 4.0.

 

Требования к программному обеспечению:

 

Logic Works BPWin версия 3.51 или выше (например, Computer Associates BPWin 4.0)

 

 

Теоретические сведения:

1. Введение.

Для анализа и проектирования деятельности предприятия используются различные методологии структурного анализа и проектирования.

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

В настоящее время  широко используются методологии:

• SADT (Structured Analysis and Design)
• структурного системного анализа Гейна-Сарсона
• структурного анализа и проектирования Йодана/де Марко,
• развития систем Джексона

и т.д.

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

В дальнейшем, диаграммы, отражающие спецификации поведения, структуры  данных для блоков программного обеспечения, транслируются в шаблоны программного кода. Это достигается использованием для проектирования так называемых средств быстрого прототипирования, известных также под названием CASE (Computer-Aided Software/System Engineering)–систем.

2. SADT - технология структурного анализа и проектирования.

SADT – одна из самых известных методологий анализа и проектирования систем, введенная в 1973 года Россом. Используется повсеместно.

Модель, по SADT, может быть одного из двух типов:

• модель активностей системы (другие названия – бизнес-функции, работы)– основывается на функциях системы/блока
• модель данных системы – основывается на подробном описании предметов системы, которые взаимодействуют между собой посредством функций.

Основным элементом  в модели по SADT является диаграмма. Модель может объединять несколько диаграмм в одну иерархию. Чем глубже диаграмма находится в иерархии, тем более она детализована, т.е. тем более подробно отображает данные или активности системы или блока.

Пример диаграммы самого высокого уровня показан на рис. 1. Такие  диаграммы называются контекстными. В контекст входит описание цели моделирования, области (описания того, что будет рассматриваться как компонент системы, а что как внешнее воздействие) и точки зрения (позиции, с которой будет строиться модель). Обычно в качестве точки зрения выбирается точка зрения лица или объекта, ответственного за работу моделируемой системы в целом.

 

Рисунок 1 - Первая диаграмма  в иерархии - контекстная - изображает функционирование системы в целом.

 

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

На рис. 2 изображена диаграмма, раскрывающая содержание контекстной  диаграммы из рис.1.

 

Рисунок 2 - Пример диаграммы  декомпозиции

 

Блоки на диаграмме размещаются  по «ступенчатой» схеме в соответствии с их доминированием – влиянием, которое один блок оказывает на другие. Часто блоки еще и нумеруют, также в соответствии с доминированием.

3. Нотация IDEF0

Нотация IDEF0 (Integration Definition for Function Modeling) была разработана на основе методологии структурного анализа и проектирования SADT, утверждена в качестве стандарта США и успешно эксплуатируется во многих проектах, связанных с описанием деятельности предприятий.

IDEF0 может быть использована  для моделирования широкого класса  систем.

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

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

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

 

В таблице 1 приведены  основные «строительные блоки» для  диаграмм IDEF0.

 

 

Таблица 1.

№	Наименование	Описание элемента IDEF0 диаграммы	Графическое представление
1	Модуль поведения (UOB)	Объект служит для описания функций (процедур, работ), выполняемых подразделениями/сотрудниками предприятия.
2	Стрелка слева	Стрелка описывает входящие документы, информацию, материальные ресурсы, необходимые для выполнения функции.
3	Стрелка справа	Стрелка описывает исходящие документы, информацию, материальные ресурсы, являющиеся результатом выполнения функции.
4	Стрелка сверху	Стрелка описывает управляющее воздействия, например распоряжение, нормативный документ и т.д. В нотации IDEF0 каждая процедура должна обязательно иметь не менее одной стрелки сверху, отражающей управляющее воздействие.
5	Стрелка снизу	Стрелка снизу описывает т.н. механизмы, т.е. ресурсы, необходимые для выполнения процедуры, но не изменяющие в процессе ее выполнения свое состояние. Примеры: сотрудник, станок и т.д.
6	Стрелка вниз	Стрелка вниз изображает связь между разными диаграммами или моделями, указывая на некоторую диаграмму, где данная работа рассмотрена более подробно.

Все работы и стрелки  должны быть именованы.

4. Нотация IDEF3

Нотация IDEF3 была разработана  с целью более удобного описания рабочих процессов (workflow), для которых важно отразить логическую последовательность выполнения процедур.

Наличие в диаграммах DFD элементов для описания источников, приемников и хранилищ данных позволяет  точно описать процесс документооборота. Однако для описания логики взаимодействия информационных потоков модель дополняют диаграммами еще одной методологии – IDEF3, также называемой workflow diagramming. Методология моделирования IDEF3 позволяет графически описать и задокументировать процессы, фокусируя внимание на течении этих процессов и на отношениях процессов и важных объектов, являющихся частями этих процессов.

IDEF3 предполагает построение  двух типов моделей: модель  может отражать некоторые процессы  в их логической последовательности, позволяя увидеть, как функционирует организация, или же модель может показывать “сеть переходных состояний объекта”, предлагая вниманию аналитика последовательность состояний, в которых может оказаться объект при прохождении через определенный процесс.

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

 

В таблице 2 приведены  основные «строительные блоки» для  диаграмм IDEF3.

 

Таблица 2.

№	Наименование	Описание	Графическое представление
1	Единица работы (Unit of Work)	Объект служит для описания функций (процедур, работ), выполняемых подразделениями/сотрудниками предприятия.
2	Объект ссылки (Referents)	Объект, используемый для  описания ссылок на другие диаграммы  модели, циклические переходы в рамках одной модели, различные комментарии  к функциям.
Связи (Links) - Связи, изображаемые стрелками, показывают взаимоотношения работ. В IDEF3 различают три типа связей.
	Связь предшествования (Precedence)	Показывает, что прежде чем начнется работа-приемник, должна завершиться работа-источник. Обозначается сплошной линией.
	Связь отношения (Relational)	Показывает связь между двумя работами или между работой и объектом ссылки. Обозначается пунктирной линией.
	Поток объектов (Object Flow)	Показывает участие некоторого объекта в двух или более работах, как, например, если объект производится в ходе выполнения одной работы и потребляется другой работой. Обозначается стрелкой с двумя наконечниками
Перекрестки (Junctions) - перекрестки используются в диаграммах IDEF3, чтобы показать ветвления логической схемы моделируемого процесса и альтернативные пути развития процесса могущие возникнуть во время его выполнения.
	Перекресток слияния (Fan-in Junction)	Узел, собирающий множество  стрелок в одну, указывая на необходимость  условия завершенности работ-источников стрелок для продолжения процесса.
	Перекресток ветвления (Fan-out Junction)	Узел, в котором единственная входящая в него стрелка ветвится, показывая, что работы, следующие  за перекрестком, выполняются параллельно  или альтернативно.
3	Логическое «И»	Логический оператор, определяющий связи между функциями в рамках процесса. Позволяет описать ветвление процесса.
4	Логическое «ИЛИ»	Логический оператор, определяющий связи между функциями  в рамках процесса. Позволяет описать  ветвление процесса.
5	Логическое исключающее  «ИЛИ»	Логический оператор, определяющий связи функциями в  рамках процесса. Позволяет описать  ветвление процесса.

 

На рис. 3 показан пример диаграммы в нотации IDEF3.

Рассмотрим эту диаграмму. Первой работой является «Обработка заявок». Эта работа использует два  объекта ссылок – «Заказы клиентов» и «Склад» - причем на диаграмме они показаны без деталей, т.к. не являются центральными для данной диаграммы. Работа «Обработка заявок» требует выполнения одной из двух работ – либо «Оформление документов», либо «Дооформление заявок» (в случае, если заявка неверно оформлена). Работа «Дооформление заявок» использует ссылочный объект «Клиенты».  Работа «Оформление документов» передает управление на две параллельные работы: «Формирование партии» и «Составление отчетности», причем работа «Формирование партии» также обращается к ссылочному объекту «Заказы клиентов».

Как видно, на диаграмме  есть два перекрестка ветвления, перекресток с ветвлением по логическому  исключающему «ИЛИ», и перекресток  с ветвлением по «И», означающим выполнение двух работ параллельно.

Рисунок 3 – Пример диаграммы  в нотации IDEF3.

5. Нотация DFD (Data Flow Diagramming)

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

 

Элементы DFD диаграмм показаны в таблице 3.

 

Таблица 3.

№	Наименование	Описание	Графическое представление
1	Работа (Activity)	Объект обозначает функции или процессы, которые обрабатывают и изменяют информацию.
2	Информационный поток (Precedence)	Объект обозначает информационный поток от объекта-источника к  объекту-приемнику.
3	Внешняя ссылка (External reference)	Указывают на место, организацию  или человека, которые участвуют  в процессе обмена информацией с  системой, но располагаются за рамками  этой диаграммы.
4	Хранилище данных (Data store)	Хранилища данных представляют собой собственно данные, к которым осуществляется доступ, эти данные также могут быть созданы или изменены работами. На одной диаграмме может присутствовать несколько копий одного и того же хранилища данных.

 

На рис.4 представлена DFD диаграмма для внешнего объекта «Заказы клиентов».

 
Рисунок 4 - Пример диаграммы DFD.

 

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

6. BPWin

BPwin поддерживает три методологии: IDEF0, DFD и IDEF3, позволяющие анализировать деятельность предприятия с трех ключевых точек зрения:

• С точки зрения функциональности системы. В рамках методологии IDEF0 бизнес-процесс представляется в виде набора элементов-работ, которые взаимодействуют между собой, а также показывается информационные, людские и производственные ресурсы, потребляемые каждой работой.
• С точки зрения потоков информации (документооборота) в системе. Диаграммы DFD могут дополнить то, что уже отражено в модели IDEF3, поскольку они описывают потоки данных, позволяя проследить, каким образом происходит обмен информацией между бизнес-функциями внутри системы. В тоже время диаграммы DFD оставляют без внимания взаимодействие между бизнес-функциями.
• С точки зрения последовательности выполняемых работ. Более точную картину можно получить, дополнив модель диаграммами IDEF3. Этот метод привлекает внимание к очередности выполнения событий. В IDEF3 включены элементы логики, что позволяет моделировать и анализировать альтернативные сценарии развития бизнес-процесса.

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

BPwin обладает удобным  инструментом для навигации по  уровням декомпозиции модели. Это  Model Explorer (см. рис. 5), который по организации очень похож на привычный всем проводник Windows.

Работы IDEF0 показываются в Model Explorer зеленым цветом, DFD – желтым и IDEF3 – синим. Щелкая мышкой по любой  из работ, представленных в проводнике, пользователь может переходить на диаграмму, содержащую выбранную работу.

 

Важно заметить, что BPWin тесно  связан с другим программным продуктом, ERWin. В частности, те хранилища данных, которые были указаны в DFD диаграммах, можно синхронизировать со схемами реляционных баз данных, созданными в ERWin.