Анализ ТЗ и его проектирование
На данных этапах применяются графические модели:
Модели по:
1Не зависящие от подхода
2Структурный: функциональные диограммы(IDEF), структурные(DFD), диаграмма отношения компонентов данных(ERD), структурные схемы и функциональные схемы.
3ООП: диаграмма вариантов использовния, диаграмма классов, диаграмма деятельности, последовательности, диаграмма компонентов, размещения.
Структурный подход
Анализ ТЗ содержит: функциональный диаграммы или диаграммы потоков данных, переходов состояний, диаграмму отношений компонентов данных. На этапе проектирования добавляются структурные и функциональные схемы, кроме того этап реализации включает реализацию процессов.
Термин — веб -сайт. Категория — интернет программирование.
Описание.
Совокупность веб-страниц с повторяющтмся дизайном, объединенных по смыслу и навигационно. Физически находящихся на одном сервере.
Диаграмма переходов состояний(STD State Transition Diagrams) демонстрирует поведение разрабатываемой программной системой при получении управляющих воздействий. Исп для проектирования графа диалога с пользователем. В STD диаграммах узлы соответствуют состоянию системе. Дуги соответствуют переходу системы из одлного состояния в другое.
|
| | |||||
 | |||||
 | |||||
Пример
1STD ПО выполняемого в пакетном режиме(не взамиодействует с окружающей средой).
|
|
|
 | |||||
 | |||||
 | |||||
|
|
|
|
|
|
| |
|
| |
|
| |
- Классификация моделей разрабатываемого программного обеспечения
10. Структурный подход. Диаграммы переходов состояний
Диаграмма переходов состояний является графической формой предоставления конечного
автомата - математической абстракции, используемой для моделирования детерминированного
поведения технических объектов или объектов реального мира.
На этапе анализа требований и определения спецификаций диаграмма переходов состояний
демонстрирует поведение разрабатываемой программной системы при получении управляющих
воздействий. Под управляющими воздействиями или сигналами в данном случае понимают
управляющую информацию, получаемую системой извне. Например, управляющими воздей-
ствиями считают команды пользователя и сигналы датчиков, подключенных к компьютерной
|
|
|
системе. Получив такое управляющее воздействие, разрабатываемая система должна выполнить
определенные действия и или остаться в том же состоянии, или перейти в другое состояние
взаимодействия с внешней средой.
Для построения диаграммы переходов состояний необходимо в соответствии с теорией
конечных автоматов определить: основные состояния, управляющие воздействия (или условия
перехода), выполняемые действия и возможные варианты переходов из одного состояния в другое.
Условные обозначения, используемые при построении диаграмм переходов состояний, показаны
на рис. 4.3.
Если программная система в процессе функционирования активно не взаимодействует с
окружающей средой (пользователем или датчиками), например, использует примитивный
интерфейс и выполняет некоторые вычисления по заданным исходным данным, то диаграмма
переходов состояний обычно интереса не представляет. В этом случае она демонстрирует только
последовательно выполняемые переходы: из исходного состояния в состояние ввода данных,
затем после выполнения вычислений - в состояние вывода и, наконец, в состояние завершения
работы (рис. 4.4).
Для интерактивного программного обеспечения с развитым пользовательским интерфейсом
|
|
|
основные управляющие воздействия - команды пользователя, для программного обеспечения
реального времени — сигналы от датчиков и/или оператора производственного процесса. Общим
для этих типов программного обеспечения является наличие состояния ожидания, когда
программное обеспечение приостанавливает работу до получения очередного управляющего
воздействия. Для интерактивного программного обеспечения наиболее характерно получение
команд различных типов (рис. 4.5), а если это еще и программное обеспечение реального времени
- однотипных сигналов (либо от многих датчиков, либо требующих продолжительной обработки).
В отличие от интерактивных систем для систем реального времени обычно установлено более
жесткое ограничение на время обработки полученного сигнала программного обеспечения. Такое
ограничение часто требует выполнения дополнительных исследований поведения системы во
времени, например, с использованием сетей Петри или марковских процессов.
К программному обеспечению, требующему уточнения особенностей поведения посредством
построения диаграммы переходов состояний, относится и программное обеспечение,
|
|
|
ориентированное на работу в сети (см. § 1.1). При этом отдельно строят модели поведения сервера
и клиента, представляя сообщения, передаваемые между ними, в виде управляющих воздействий.
11. Структурный подход. Функциональные диаграммы
Функциональными называют диаграммы, в первую очередь отражающие взаимосвязи функций
разрабатываемого программного обеспечения. В качестве примера функциональной модели
рассмотрим активностную модель, предложенную Д. Россом в составе методологии
функционального моделирования SADT (Structured Analysis and Design Technique - технология
структурного анализа и проектирования) в 1973 г. [58].
Примечание. Методология SADT предполагает, что модель может основываться либо на
функциях системы, либо на ее предметах (данных, оборудовании, информации и т. п.). В обоих
случаях используют схожие графические нотации, но в первом случае блок соответствует
функции, а во втором — элементу данных. Соответствующие модели принято называть актив-
ностными моделями и моделями данных. Полная модель включает построение обеих моделей,
обеспечивающих более полное описание программного обеспечения, однако широкое
распространение получили только активностные (функциональные) модели. На основе мето-
дологии SADT в дальнейшем была построена известная методология описания сложных систем
IDEFO (Icam DEFinition - нотация ICAM), которая является основной частью программы ICAM
(Integrated Computer-Aided Manufacturing - интегрированная компьютеризация производства),
проводимой по инициативе ВВС США.
Отображение взаимосвязи функций активностной модели осуществляется посредством
построения иерархии функциональных диаграмм, схематически представляющих взаимосвязи
нескольких функций. Каждый блок такой диаграммы соответствует некоторой функции, для
которой должны быть определены: исходные данные, результаты, управляющая информация и ме-
ханизмы ее осуществления — человек или технические средства.
Все перечисленные выше связи функции представляются дугами, причем тип связи и ее
направление строго регламентированы. Дуги, изображающие каждый тип связей, должны
подходить к блоку с определенной стороны (рис. 4.7), а направление связи должно указываться
стрелкой в конце дуги.
Физически дуги исходных данных, результатов и управления представляют собой наборы
данных, передаваемые между функциями. Дуги, определяющие механизм выполнения функции, в
основном используются при описании спецификаций сложных информационных систем, которые
включают как автоматизированные, так и ручные операции. Блоки и дуги маркируются текстами
на естественном языке.
Блоки на диаграмме размещают по «ступенчатой» схеме в соответствии с
последовательностью их работы или доминированием, которое понимается как влияние,
оказываемое одним блоком на другие. В функциональных диаграммах SADT различают пять
типов влияний блоков друг на друга:
• вход - выход блока подается на вход блока с меньшим доминированием, т. е. Следующего
(рис. 4.8, а);
• управление - выход блока используется как управление для блока с меньшим
доминированием (следующего) (рис. 4.8, б);
• обратная связь по входу - выход блока подается на вход блока с большим доминированием
(предыдущего) (рис. 4.8, в);
• обратная связь по управлению — выход блока используется как управляющая информация
• выход-исполнитель - выход блока используется как механизм для другого блока (рис. 4.8, д).
для блока с большим до 
минированием (предыдущего) (рис:4.8,г);
Дуги могут разветвляться и соединяться вместе различными способами. Разветвление
означает, что часть или вся информация может использоваться в каждом ответвлении дуги. Дуга
всегда помечается до ветвления, чтобы идентифицировать передаваемый набор данных. Если
ветвь дуги после ветвления непомечена, то непомеченная ветвь содержит весь набор данных.
Каждая метка ветви уточняет, что именно содержит данная ветвь (рис. 4.9). Дуги могут разветвляться и соединяться вместе различными способами. Разветвление
означает, что часть или вся информация может использоваться в каждом ответвлении дуги. Дуга
всегда помечается до ветвления, чтобы идентифицировать передаваемый набор данных. Если
ветвь дуги после ветвления непомечена, то непомеченная ветвь содержит весь набор данных.
Каждая метка ветви уточняет, что именно содержит данная ветвь (рис. 4.9).
Дуги могут разветвляться и соединяться вместе различными способами. Разветвление
означает, что часть или вся информация может использоваться в каждом ответвлении дуги. Дуга
всегда помечается до ветвления, чтобы идентифицировать передаваемый набор данных. Если
ветвь дуги после ветвления непомечена, то непомеченная ветвь содержит весь набор данных.
Каждая метка ветви уточняет, что именно содержит данная ветвь (рис. 4.9).
Построение иерархии функциональных диаграмм ведется поэтапно с увеличением уровня
детализации: диаграммы каждого следующего уровня уточняют структуру родительского блока.
Построение модели начинают с единственного блока, для которого определяют исходные данные,
результаты, управление и механизмы реализации. Затем он последовательно детализируется с
использованием метода пошаговой детализации (см. § 1.3). При этом рекомендуется каждую
функцию представлять не более чем 3—7-ю блоками. Во всех случаях каждая подфункция
может использовать или продуцировать только те элементы данных, которые использованы
или продуцируются родительской функцией, причем никакие элементы не могут быть опущены,
что обеспечивает непротиворечивость построенной
Стрелки, приходящие с родительской диаграммы или уходящие на нее, нумеруют, используя
символы и числа. Символ обозначает тип связи: I -входная, С - управляющая, М - механизм, R -
результат. Число - номер связи по соответствующей стороне родительского блока, считая сверху
вниз и слева направо.
Все диаграммы связывают друг с другом иерархической нумерацией блоков: первый уровень -
АО, второй - А1, А2 и т. п., третий - All, A12, А13 и т. п., где первые цифры — номер
родительского блока, а последняя — номер конкретного субблока родительского блока.
Детализацию завершают после получения функций, назначение которых хорошо понятно как
заказчику, так и разработчику. Эти функции описывают, используя естественный язык или
псевдокоды.
В процессе построения иерархии диаграмм фиксируют всю уточняющую информацию и
строят словарь данных, в котором определяют структуры и элементы данных, показанных на
диаграммах.
Таким образом, в результате получают спецификацию, которая состоит из иерархии
функциональных диаграмм, спецификаций функций нижнего уровня и словаря, имеющих ссылки
друг на друга.
12. Структурный подход. Диаграммы потоков данных
Диаграммы потоков данных позволяют специфицировать как функции разрабатываемого
программного обеспечения, так и обрабатываемые им данные. При использовании этой модели
систему представляют в виде иерархии диаграмм потоков данных, описывающих асинхронный
процесс преобразования информации с момента ввода в систему до выдачи пользователю. На
каждом следующем уровне иерархий происходит уточнение процессов, пока очередной процесс
не будет признан элементарным.
Примечание. Модели потоков данных были независимо предложены сначала Е. Йорданом
(1975), затем Ч. Гейном и Т. Сарсоном (1979). На этих моделях основаны классические
методологии структурного анализа и проектирования программного обеспечения соответственно
Йордана-Де Марка и Гейна-Сарсона. Та же модель используется в методологии структурного
анализа и проектирования SSADM (Structured Systems Analysis and Design Method) принятой в
Великобритании в качестве национального стандарта разработки информационных систем.
В основе модели лежат понятия внешней сущности, процесса, хранилища (накопителя)
данных и потока данных.
Внешняя сущность - материальный объект или физическое лицо, выступающие в качестве
источников или приемников информации, например, заказчики, персонал, поставщики, клиенты,
банк и т. п.
Процесс - преобразование входных потоков данных в выходные в соответствии с
определенным алгоритмом. Каждый процесс в системе имеет свой номер и связан с исполнителем,
который осуществляет данное преобразование. Как в случае функциональных диаграмм,
физически преобразование может осуществляться компьютерами, вручную или специальными
устройствами. На верхних уровнях иерархии, когда процессы еще не определены, вместо понятия
«процесс» используют понятия «система» и «подсистема», которые обозначают соответственно
систему в целом или ее функционально законченную часть.
Хранилище данных - абстрактное устройство для хранения информации. Тип устройства и
способы помещения, извлечения и хранения для такого устройства не детализируют. Физически
это может быть база данных, файл, таблица в оперативной памяти, картотека на бумаге и т. п.
Поток данных — процесс передачи некоторой информации от источника к приемнику.
Физически процесс передачи информации может происходить по кабелям под управлением
программы или программной системы или вручную при участии устройств или людей вне
проектируемой системы.
Таким образом, диаграмма иллюстрирует как потоки данных, порожденные некоторыми
внешними сущностями, трансформируются соответствующими процессами (или подсистемами),
сохраняются накопителями данных и передаются другим внешним сущностям — приемникам
информации. В результате мы получаем сетевую модель хранения/обработки информации.
Для изображения диаграмм потоков данных традиционно используют два вида нотаций:
нотации Йордана и Гейна-Сарсона (табл. 4.1).
Над линией потока, направление которого обозначают стрелкой, указывают, какая конкретно
информация в данном случае передается (рис. 4.11).
Построение иерархии диаграмм потоков данных начинают с диаграммы особого вида -
контекстной диаграммы, которая определяет наиболее общий вид системы. На такой диаграмме
показывают, как разрабатываемая система будет взаимодействовать с приемниками и
источниками информации без указания исполнителей, т. е. описывают интерфейс между системой
и внешним миром. Обычно начальная контекстная диаграмма имеет форму звезды.
Если проектируемая система содержит большое количество внешних сущностей (более 10-ти),
имеет распределенную природу или включает уже существующие подсистемы, то строят иерархии
контекстных диаграмм.
При разработке контекстных диаграмм происходит детализация функциональной структуры
будущей системы, что особенно важно, если разработка ведется несколькими коллективами
разработчиков.
Полученную таким образом модель системы проверяют на полноту исходных данных об
объектах системы и изолированность объектов (отсутствие информационных связей с другими
объектами).
На следующем этапе каждую подсистему контекстной диаграммы детализируют при помощи
диаграмм потоков данных. В процессе детализации соблюдают правило б а л а н с и р о в к и - при
детализации подсистемы можно использовать компоненты только тех подсистем, с которыми
у разрабатываемой подсистемы существует информационная связь (т. е. с которыми она связана
потоками данных).
Решение о завершении детализации процесса принимают в следующих случаях:
• процесс взаимодействует с 2-3-мя потоками данных;
• возможно описание процесса последовательным алгоритмом;
• процесс выполняет единственную логическую функцию преобразования входной
информации в выходную.
На недетализируемые процессы составляют спецификации, которые должны содержать
описание логики (функций) данного процесса. Такое описание может, выполняться: на
естественном языке, с применением структурированного естественного языка (псевдокодов), с
применением таблиц и деревьев решений, в виде схем алгоритмов, в том числе flow-форм и
диаграмм Насси-Шнейдермана (см. § 2.4).
Для облегчения восприятия процессы детализируемой подсистемы нумеруют, соблюдая
иерархию номеров: так процессы, полученные при детализации процесса или подсистемы «1»,
должны нумероваться «1.1», «1.2» и т. д. Кроме этого желательно размещать на каждой диаграмме
от 3-х до 6-7-ми процессов и не загромождать диаграммы деталями, не существенными на данном
уровне.
Декомпозицию потоков данных необходимо осуществлять параллельно с декомпозицией
процессов.
Окончательно разработку модели выполняют в два этапа.
1 этап - построение контекстной диаграммы - включает выполнение следующих действий:
• классификацию множества требований и организацию их в основные функциональные
группы — процессы;
• идентификацию внешних объектов - внешних сущностей, с которыми система должна быть
связана;
• идентификацию основных видов информации - потоков данных, циркулирующей между
системой и внешними объектами;
• предварительную разработку контекстной диаграммы;
• изучение предварительной контекстной диаграммы и внесение в нее изменений по
результатам ответов на возникающие при изучении вопросы по всем ее частям;
• построение контекстной диаграммы путем объединения всех процессов предварительной
диаграммы в один процесс, а также группирования потоков.
2 этап - формирование иерархии диаграмм потоков данных – включает для каждого уровня:
• проверку и изучение основных требований по диаграмме соответствующего уровня (для
первого уровня - по контекстной диаграмме);
• декомпозицию каждого процесса текущей диаграммы потоков данных с помощью
детализирующей диаграммы или — если некоторую функцию сложно или невозможно выразить
комбинацией процессов, построение спецификации процесса;
• добавление определений новых потоков в словарь данных при каждом появлении их на
диаграмме;
• проведение ревизии с целью проверки корректности и улучшения наглядности модели после
построения двух-трех уровней.
Полная спецификация процессов включает также описание структур данных, используемых
как при передаче информации & потоке, так и при хранении в накопителе. Описываемые
структуры данных могут содержать альтернативы, условные вхождения и итерации. Условное
вхождение означает, что соответствующие элементы данных в структуре могут отсутствовать.
Альтернатива означает, что в структуру может входить один из перечисленных элементов.
Итерация означает, что элемент может повторяться некоторое количество раз (см. § 4.5).
Кроме того, для данных должен быть указан тип: непрерывное или дискретное значение. Для
непрерывных данных могут определяться единицы измерений, диапазон значений, точность
представления и форма физического кодирования. Для дискретных - может __________указываться таблица
допустимых значений.
Полученную законченную модель необходимо проверить на полноту и согласованность. Под
согласованностью модели в данном случае понимают выполнение для всех потоков данных
правила сохранения информации: все поступающие куда-либо данные должны быть считаны и
записаны.
Дата добавления: 2019-02-12; просмотров: 410; Мы поможем в написании вашей работы! |
Мы поможем в написании ваших работ!