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

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

5. 
   Группы средств структурного анализа в SADT
   

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

На протяжении первых трех фаз (стадия разработки) закладываются характеристики качества будущего ПИ, проявляющиеся на стадии его эксплуатации. Этот факт можно проиллюстрировать таблицей 1, отражающей распределение трудозатрат по этапам ЖЦ ПО.
Таблица 1 - Распределение трудозатрат по этапам ЖЦ ПО

Способ разработки	Анализ	Проекти-рование	Коди-рование	Тести-рование
Традиционная разработка	20%	15%	20%	45%
Использование структурных методологий	30%	30%	15%	25%
Использование CASE-технологий	40%	40%	5%	15%

---

---

3.4Диаграммы потоков данных

Нотация диаграмм потоков данных (Data Flow Diagrams) принадлежит к классу средств моделирования функциональных требований к проектируемой системе. С помощью средств данного класса требования разбиваются на функциональные компоненты (процессы) и представляются в виде сети, связанной потоками данных. Главная цель таких средств – продемонстрировать, как каждый процесс преобразует входные данные в выходные, выявить отношения между процессами.

Рассмотрим DFD в нотации Гейна – Сарсона (Gane - Sarson), используемой в CASE-средстве BPWin.

3.4.1Основные символы DFD

На диаграммах потоков данных функциональные требования представляются с помощью процессов и хранилищ, связанных потоками данных (рис.6).

6. 
   О
   сновные символы DFD
   

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

Процесс – производит выходные потоки из входных в соответствии с действием, задаваемым именем процесса. Имя должно содержать глагол в неопределенной форме с последующим дополнением (например, ВЫЧИСЛИТЬ МАКСИМАЛЬНУЮ ВЫСОТУ). Кроме того, каждый процесс должен иметь уникальный номер для ссылок на него внутри диаграммы. Номер может использоваться совместно с номером диаграммы для получения уникального индекса процесса во всей модели.

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

---

Внешняя сущность (терминатор) представляет сущность вне контекста системы, являющуюся источником или приемником данных системы. Имя внешней сущности должно содержать существительное (например, СКЛАД ТОВАРОВ). Узлы, изображаемые внешними сущностями, не должны участвовать ни в какой обработке данных.

3.4.2Контекстная диаграмма и детализация процессов

Декомпозиция DFD осуществляется путем раскрытия процессов при помощи DFD нижнего уровня.

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

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

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

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

• 
  Контекстный процесс – не нумеруется, или имеет номер 1.
  
• 
  Процессы диаграммы первого уровня – имеют номера 1.1, 1.2, 1.3 и т.д.
  
• 
  Процессы диаграммы второго уровня, раскрывающей процесс 1.1 нумеруются 1.1.1, 1.1.2, 1.1.3 и т.д.
  
• 
  Процессы диаграммы второго уровня, раскрывающей процесс 1.2 нумеруются 1.2.1, 1.2.2, 1.2.3 и т.д.
  

3.4.3Декомпозиция и слияние данных

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

---

Смысл разветвления или слияния передается наименованием каждой ветви потока. Существуют правила присвоения имен потокам в такой ситуации.

• 
  Если поток именован до разветвления, а после разветвления ни одна ветвь не именована, следовательно, каждая ветвь моделирует те же данные что и до разветвления.
  
• 
  Если поток именован до разветвления, а после разветвления часть ветвей именована, а часть – нет, подразумевается, что именованные ветви соответствуют наименованию, а неименованные ветви моделируют те же данные, что и до разветвления.
  
• 
  Недопустима ситуация, когда поток до разветвления не именован, а после разветвления не именована какая-либо ветвь.
  
• 
  Правила именования потоков при слиянии – аналогичны.
  
• 
  При слиянии потоков недопустима ситуация, когда не именована какая-либо из ветвей до слияния и поток после слияния.
  

3.4.4Построение модели

Главная цель построения модели в DFD заключается в том, чтобы сделать требования к системе ясными и понятными на каждом уровне детализации, а также разбить требования на части с четко определенными отношениями между ними.

Для достижения этой цели следует пользоваться следующими рекомендациями:

• 
  На каждой диаграмме – 2-7 процессов.
  
• 
  Не загромождать диаграмму несущественными на данном уровне деталями.
  
• 
  Декомпозицию потоков данных осуществлять параллельно с декомпозицией процессов, обе эти работы ведутся параллельно, а не одна после другой.
  
• 
  Для улучшения понимаемости модели выбирать ясные, отражающие суть дела имена объектов модели, стараться не использовать аббревиатуры.
  
• 
  Однократно определять функционально идентичные процессы на самом верхнем уровне, где такой процесс необходим, и ссылаться на него на нижних уровнях.
  
• 
  Использовать простейшие диаграммные техники: если что-то можно описать при помощи DFD, то это и следует сделать, а не использовать более сложные методы.
  

В соответствии с данными рекомендациями процесс построения модели разбивается на следующие этапы:

1. 
   Расчленение множества требований и организация их в основные функциональные группы.
   
2. 
   Идентификация внешних объектов, с которыми должна быть связана система.
   
3. 
   Идентификация основных видов информации, циркулирующих между системой и внешней средой.
   
4. 
   Разработка предварительной контекстной диаграммы. Функциональные группы представляются процессами, внешние объекты – внешними сущностями, основные виды информации – потоками данных между процессами и внешними сущностями.
   
5. 
   Верификация предварительной контекстной диаграммы, внесение в нее изменений по результатам ответов на возникающие вопросы.
   
6. 
   Построение контекстной диаграммы путем слияния всех процессов предварительной диаграммы в один процесс, а также группировки потоков.
   
7. 
   Формирование DFD первого уровня на базе процессов предварительной контекстной диаграммы.
   
8. 
   Проверка основных требований по DFD первого уровня.
   
9. 
   Декомпозиция каждого процесса текущей DFD с помощью детализирующей диаграммы или спецификации процесса.
   
10. 
    Проверка основных требований по DFD соответствующего уровня.
    
11. 
    Добавление определений новых потоков в словарь данных при каждом их появлении на диаграммах.
    
12. 
    Параллельное с процессом декомпозиции изучение требований (в том числе и вновь поступающих), разбиение их на элементарные и идентификация процессов или спецификаций процессов, соответствующих этим требованиям.
    
13. 
    После построения каждых 2-3 уровней – ревизия модели с целью проверки ее корректности и улучшения понимаемости.
    
14. 
    Построение спецификаций процессов в тех случаях, когда нет необходимости или возможности раскрывать их при помощи DFD.
    

---