Файл: Учебное пособие по курсу Технология разработки программного обеспечения для студентов.doc

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

Приведем примеры словаря сущностей и атрибутов для банковской задачи, рассмотренной в предыдущей лекции:

• 
  Кредитная карта:
  
  • 
    Пароль.
    
  • 
    Лимит денег.
    
  • 
    Детали клиента.
    
• 
  Протокол обслуживания:
  
  • 
    Обработанная документация.
    
  • 
    Денежная сумма.
    
  • 
    Данные по истории запроса.
    

6Спецификации процессов

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

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

Основные символы и виды связей диаграммы IDEF3 изображены на рисунке 10.

10. 
    Основные символы и виды связей на диаграмме IDEF3
    

Единица работы (Unit Of Work, UOW), синоним терминов «Процесс», «Функция». При наименовании процессов следует соблюдать следующее правило: поскольку сценарий описывает цель и рамки модели, работы необходимо именовать отглагольным существительным либо фразой, содержащей такое существительное (например, «Изготовление изделия», «Осуществить сборку изделия»). Нумерация UOW ведется в таком же порядке, как в DFD.

Перекресток (

---

Junction) – используется для отображения логики взаимодействия потоков при слиянии или разветвлении, а также для отображения множества событий, которые должны быть завершены перед началом следующей работы. Перекресток может быть использован для слияния или разветвления потоков, но не одновременно и для того и для другого.
Существуют следующие виды перекрестков:

Наименование	Смысл при слиянии потоков	Смысл при разветвлении потоков
1	2	3
Асинхронное «И»	Все предшествующие процессы должны быть завершены	Будут запущены все последующие процессы
Синхронное «И»	Все предшествующие процессы должны быть завершены одновременно	Все последующие процессы будут запущены одновременно
Асинхронное «ИЛИ»	Как минимум один из предшествующих процессов должен быть завершен	Будет запущен как минимум один из последующих процессов
Синхронное «ИЛИ»	Один или несколько предшествующих процессов завершено одновременно	Один или несколько после-дующих процессов будут запущены одновременно
Исключающее «ИЛИ»	Завершен точно один из предшествующих процессов	Запустится точно один из последующих процессов

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

При внесении ссылочных объектов помимо их имени следует указывать тип ссылочного объекта.

Тип ссылочного объекта	Способ использования
OBJECT	Описывает участие в работе важного объекта
GOTO	Инструмент циклического перехода (в повторяющейся последовательности работ), возможно на текущей диаграмме, но не обязательно. Если все работы цикла присутствуют на данной диаграмме он может быть также изображен потоком, уходящим к начальной работе. GOTO может ссылаться на перекресток.
UOB (Unit Of Behavior)	Применяется в случае, когда необходимо подчеркнуть множественное использование какой-либо работы, но без использования цикла. Например, работа «Контроль качества» может быть использована в процессе «Изготовление детали» несколько раз, после каждой единичной операции. Данный тип ссылки, как правило, не используется для моделирования работ, запускающихся автоматически.
NOTE	Используется для документирования важной информации по какому-либо из объектов диаграммы. Является альтернативой внесения на диаграмму текстовой информации.
ELAB (Elaboration)	Используется для усовершенствования графиков или их более детального описания. Обычно используется для детального описания разветвления и слияния стрелок на перекрестках.

---

Связи показывают взаимоотношения работ между собой. Связи в IDEF3 однонаправлены. Правилом хорошего тона считается направлять связи слева направо и сверху вниз. В IDEF3 используются следующие виды связей:

• 
  Старшая (Precedence). Связывает работы, отражает тот факт, что работа – источник должна закончиться прежде, чем начнется работа – приемник.
  
• 
  Связь отношения (Relational Link). Служит для установления связи между двумя работами или между работой и ссылочным объектом.
  
• 
  Поток объектов (Object Flow). Отражает тот факт, что объект используется более чем в одной работе. Например, может использоваться когда объект порождается в одной работе, а используется в другой. Пример диаграммы IDEF3 для процесса 1 «Получить пароль» приведен на рис. 11.
  

11. 
    Спецификация процесса 1 «Получить пароль» в виде диаграммы IDEF3
    

---

7Методология функционального моделирования SADT (IDEF0)

7.1Structured Analysis and Design Technique

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

В основу методологии положены следующие концепции:

• 
  Моделируемая система рассматривается как произвольное подмножество Вселенной;
  
• 
  Система имеет границу, отделяющую ее от остальной вселенной. Взаимодействие системы с окружающим миром описывается следующими терминами:
  
  • 
    Вход (нечто перерабатываемое системой);
    
  • 
    Выход (результат деятельности системы);
    
  • 
    Управление (стратегии и процедуры, под управлением которых производится работа);
    
  • 
    Механизм (ресурсы, необходимые для проведения работы).
    
• 
  Находясь под управлением, система преобразует входы в выходы с использованием механизмов.
  
• 
  Графическое представление функциональной модели. В модели SADT функция представляется в виде блока, а интерфейсы входа-выхода представляются дугами. Взаимодействие блоков друг с другом описывается при помощи интерфейсных дуг, выражающих ограничения в выполнении и управлении функций.
  
• 
  Строгость и точность. Правила SADT включают:
  
  • 
    Ограничение числа блоков на каждой диаграмме (2 – 8 блоков).
    
  • 
    Связность диаграмм (структурная нумерация блоков).
    
  • 
    Уникальность меток и наименований.
    
  • 
    Синтаксические правила для графики (блоков и дуг).
    
  • 
    Разделение входов и управлений (определение роли данных).
    
• 
  Отделение организации от функции, то есть исключение влияния организационной структуры на функциональную модель.
  

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

---

, посредством которых они выполняются.

Перед построением модели следует определить область моделирования (Scope), которая включает в себя позицию, с которой рассматривается система (View Point) и цель моделирования (Purpose). При описании области моделирования ее следует ограничить по широте (решить, что входит контекст системы, а что останется за ним) и по глубине (решить, на каком уровне детализации модель будет завершена).

Цель моделирования. Модель не может быть построена без четко сформулированной цели. Цель должна отвечать на вопросы:

• 
  Почему эту систему надо моделировать?
  
• 
  Что должна показывать модель?
  
• 
  Что может получить читатель от модели?
  

Формулировка цели позволяет аналитикам сфокусировать усилия в нужном направлении. Примеры целей: «Идентифицировать роли и ответственность служащих для написания должностных инструкций», «Описать деятельность предприятия с целью создания спецификации информационной системы».

Точка зрения. Несмотря на то, что при моделировании системы учитываются мнения различных людей, модель должна строиться, исходя из единой точки зрения. Точка зрения может быть представлена как взгляд человека, который видит систему в нужном для моделирования аспекте. Точка зрения должна соответствовать цели моделирования. Точка зрения различных, участвующих в работе специалистов (например, финансистов и технологов) может быть различной, поэтому важно в процессе моделирования оставаться на единой точке зрения. Как правило, выбирается точка зрения лица, ответственного за моделируемую работу в целом. Если при выборе точки зрения необходимо задокументировать дополнительные альтернативные точки зрения, для этого используется диаграмма FEO (For Exposition Only).

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

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

1. 
   Создание модели As-Is.
   
2. 
   Ее анализ и улучшение бизнес-процессов (создание модели To-Be).
   
3. 
   На основе модели To-Be – построение модели данных, прототипов и окончательных версий информационной системы.
   

---