Стандатризация программных средств

Основными компонентами диаграмм потоков данных являются:

· внешние сущности (рис.18);

· системы и подсистемы (рис.19);

· процессы (рис. 20);

· накопители данных (рис.21);

· потоки данных (рис.22).

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

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

Рис.18. Графическое изображение внешней сущности

При построении модели сложной ЭИС она может быть представлена в общем виде на так называемой контекстной диаграмме в виде одной системы как единого целого либо может быть декомпозирована на ряд подсистем.

Поле номера

Поле имени

Поле физической реализации

Рис.19. Изображение системы (подсистемы)

Процесс представляет собой преобразование входных потоков данных в выходные в соответствии с определенным алгоритмом.

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

Поле номера

Поле имени

Поле физической организации

Рис.20. Графическое изображение процесса

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

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

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

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

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

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

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

Отчетность по

подоходному

налогу

Рис. 22. Поток данных между процессом и внешней сущностью

Построение иерархии потоков данных

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

· Размещать на каждой диаграмме от 3 до 6-7 процессов. Верхняя граница соответствует человеческим возможностям одновременного восприятия и понимания структуры сложной системы с множеством внутренних связей, нижняя граница выбрана по соображениям здравого смысла: нет необходимости детализировать процесс диаграммой, содержащей всего один или два процесса.

· Не загромождать диаграммы не существенными на данном уровне деталями.

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

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

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

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

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

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

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

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

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

· Правило нумерации - при детализации процессов должна поддерживаться их иерархическая нумерация. Например, процессы, детализирующие процесс с номером 12, получают номера 12.1, 12.2, 12.3 и т.д.

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

Спецификация является конечной вершиной иерархии DFD . Решение о завершении детализации процесса и использовании спецификации принимается аналитиком исходя из следующих критериев:

· Наличия у процесса относительно небольшого количества входных и выходных потоков данных (2-3).

· Возможности описания преобразования данных процессом в виде последовательного алгоритма.

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

· Возможности описания логики процесса при помощи спецификации небольшого объема (не более 20-30 строк).

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

· Для каждого процесса нижнего уровня должна существовать одна и только одна спецификация.

· Спецификация должна определять способ преобразования входных потоков в выходные.

· Нет необходимости (по крайней мере на стадии формирования требований) определять метод реализации этого преобразования.

· Спецификация должна стремиться к ограничению избыточности - не следует переопределять то, что уже было определено на диаграмме.

· Набор конструкций для построения спецификаций должен быть простым и понятным.

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

Номер и/или имя процесса.

Списки входных и выходных данных.

Тело (описание процесса), являющееся спецификацией алгоритма или операции, трансформирующей входные потоки данных в выходные.

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

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

В состав языка входят следующие основные символы:

· глаголы, ориентированные на действие и применяемые к объектам;

· термины, определенные на любой стадии проекта ПО (например, задачи, процедуры, символы данных и т.д.);

· предлоги и союзы, используемые в логических отношениях;

· общеупотребительные математические, физические и технические термины;

· арифметические уравнения;

· таблицы, диаграммы, графы;

· комментарии.

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

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

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

глаголы должны быть активными, недвусмысленными и ориентированными на целевое действие (заполнить, вычислить, извлечь, а не модернизировать, обработать и т.д.);

логика процесса должна быть выражена четко и недвусмысленно.

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

Каждый объект должен состоять из элементов, являющихся его атрибутами. Структуры данных могут содержать альтернативы, условные вхождения и итерации. Условное вхождение показывает, что данный компонент может отсутствовать в структуре (например, структура «данные о страховании» для объекта «служащий»). Альтернатива означает, что в структуру может входить один из перечисленных элементов. Итерация предусматривает вхождение любого числа элементов в указанном диапазоне (например, элемент «имя ребенка» для объекта «служащий»).

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

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

Функциональные модели, используемые на стадии проектирования ПО, предназначены для описания функциональной структуры проектируемой системы. Построенные ранее DFD при этом уточняются, расширяются и дополняются новыми конструкциями.

Так, например, для DFD переход от модели бизнес - процессов организации к модели системных процессов может происходить следующим образом:

· внешние сущности на контекстной диаграмме заменяются или дополняются техническими устройствами (например, рабочими станциями, принтерами);

· для каждого потока данных определяется, посредством каких технических устройств информация передается или производится;

· процессы на диаграмме нулевого уровня заменяются соответствующими процессорами - обрабатывающими устройствами (процессорами могут быть как технические устройства - ПК конечных пользователей, рабочие станции, серверы баз данных, так и служащие - исполнители);

· определяется и изображается на диаграмме тип связи между процессорами (например, локальная сеть - LAN);

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

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

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

· на DFD выбираются интерактивные процессы нижнего уровня. Интерактивные процессы нуждаются в пользовательском интерфейсе, поэтому нужно определить экранную форму для каждого такого процесса;

· форма диаграммы изображается в виде прямоугольника для каждого интерактивного процесса на нижнем уровне диаграммы;

· определяется структура меню. Для этого интерактивные процессы группируются в меню (либо так же как в модели процессов, либо другим способом - по функциональным признакам или в зависимости от принадлежности к определенным объектам);

· формы с меню изображаются над формами, соответствующими интерактивным процессам, и соединяются с ними переходами в виде стрелок, направленных от меню к формам;

· определяется верхняя форма (главная форма приложения), связывающая все формы с меню.

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

Лекция 15. Моделирование данных

В CASE - средстве SILVERRUN для концептуального моделирования данных (на стадии формирования требований) используется один из вариантов нотации Чена (рис. 29). На ERD - диаграмме сущность обозначается прямоугольником, содержащим имя сущности, а связь - овалом, связанным линией с каждой из взаимодействующих сущностей. Числа над линиями означают степень и обязательность связи.

0,N 1,1

Рис.29. Обозначение сущностей и связей

В данном примере:

· физическое лицо может не иметь банковского счета (необязательная связь) либо иметь много счетов (степень связи N);

· каждый банковский счет может принадлежать одному (обязательная связь) и только одному физическому лицу (степень связи - 1).

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

Существуют следующие виды идентификаторов:

· Первичный/альтернативный: сущность может иметь несколько идентификаторов. Один должен являться основным (первичным), а другие - альтернативными. Первичный идентификатор на диаграмме подчеркивается. Альтернативные идентификаторы начинаются с символов <1> для первого альтернативного идентификатора, <2> - для второго и т.д. В реляционной модели, полученной из концептуальной модели данных, первичные ключи используются в качестве внешних ключей. Альтернативные идентификаторы не копируются в качестве внешних ключей в другие таблицы.

· Простой/составной: идентификатор, состоящий из одного атрибута, является простым, из нескольких атрибутов - составным (рис.31);

Абсолютный / относительный: если все атрибуты, составляющие идентификатор, принадлежат сущности, то идентификатор является абсолютным. Если один или более атрибутов идентификатора принадлежат другой сущности, то идентификатор является относительным. Когда первичный идентификатор является относительным, сущность определяется как зависимая сущность, поскольку ее идентификатор зависит от другой сущности (рис.32). В примере на рисунке ниже идентификатор сущности Строка-заказа является относительным. Он включает идентификатор сущности ЗАКАЗ, что показано на рисунке подчеркиванием 1,1.

Рис.32. Относительный идентификатор

Как и сущности, связи могу иметь атрибуты. Пример ниже показывает атрибуты связи. В этом примере для того, чтобы найти оценку студента, нужно знать не только идентификатор студента, но и номер курса. Оценка не является атрибутом студента или атрибутом курса; она является атрибутом обеих сущностей. Это атрибут связи между студентом и курсом, которая на примере называется регистрация (рис.33).

0,N 0,N

Рис. 33. Связь с атрибутами

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

В связи «супертип-подтип» общие атрибуты типа определяются в сущности- супертипе, сущность-подтип наследует все атрибуты супертипа (рис. 34). Экземпляр подтипа существует только при условии существования определенного экземпляра супертипа. Подтип не может иметь идентификатора (он импортирует его из супертипа).

Рис. 34. Связь «супертип-подтип»

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

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

ТЕМА 3. КАЧЕСТВО ПРОГРАММНЫХ СРЕДСТВ