tehnologia (1018792), страница 20
Текст из файла (страница 20)
При этомодна часть спецификаций (функциональные) описывает функции разрабатываемогопрограммного обеспечения, а другая часть (эксплуатационные) определяет требования ктехническим средствам, надежности, информационной безопасности и т.д.Определение отражает главные требования к спецификациям. Применительно кфункциональным спецификациям подразумевается, что:• требование полноты означает, что спецификации должны содержать всюсущественную информацию, где ничего важного не было бы упущено, и отсутствуетнесущественная информация, например детали реализации, чтобы не препятствоватьразработчику в выборе наиболее эффективных решений;• требование точности означает, что спецификации должны однозначновосприниматься как заказчиком, так и разработчиком.Последнее требование выполнить достаточно сложно в силу того, что естественный языкдля описания спецификаций не подходит: даже подробные103спецификации на естественном языке не обеспечивают необходимой точности.
Точныеспецификации можно определить, только разработав некоторую формальную модельразрабатываемого программного обеспечения.Формальные модели, используемые на этапе определения спецификаций можноразделить на две группы: модели, зависящие от подхода к разработке (структурного илиобъектно-ориентированного), и модели, не зависящие от него. Так диаграммы переходовсостояний, которые демонстрируют особенности поведения разрабатываемого программногообеспечения при получении тех или иных сигналов извне (см. § 4.2), и математическиемодели предметной области (см. § 4.6) используют при любом подходе к разработке.В рамках структурного подхода на этапе анализа и определения спецификацийиспользуют три типа моделей: ориентированные на функции, ориентированные на данные иориентированные на потоки данных.
Каждую модель целесообразно использовать для своегоспецифического класса программных разработок.На рис. 4.1 показана классификация моделей разрабатываемого программногообеспечения, используемых на этапе определения спецификаций.Следует иметь в виду, что все функциональные спецификации описывают одни и те жехарактеристики разрабатываемого программного обеспечения: перечень функций и составобрабатываемых данных. Они различаются104только системой приоритетов (акцентов), которая используется разработчиком в процессеанализа требований и определения спецификаций.
Диаграммы переходов состоянийопределяют основные аспекты поведения программного обеспечения во времени, диаграммыпотоков данных – направление и структуру потоков данных, а концептуальные диаграммыклассов – отношение между основными понятиями предметной области.Поскольку разные модели описывают проектируемое программное обеспечение сразных сторон, рекомендуется использовать сразу несколько моделей и сопровождать ихтекстами: словарями, описаниями и т.п., которые поясняют соответствующие диаграммы.Так методологии структурного анализа и проектирования, основанные намоделировании потоков данных, обычно используют комплексное представлениепроектируемого программного обеспечения в виде совокупности моделей:• диаграмм потоков данных (DFD – Data Flow Diagrams), описывающихвзаимодействие источников и потребителей информации через процессы, которые должныбыть реализованы в системе (см.
§ 4.4);• диаграмм «сущность-связь» (ERD – Entity-Relationship Diagrams), описывающихбазы данных разрабатываемой системы (см. § 4.5);• диаграмм переходов состояний (STD – State Transition Diagrams), характеризующихповедение системы во времени (см. § 4.2);• спецификаций процессов;• словаря терминов.Взаимосвязь элементов такой обобщенной модели показана на рис. 4.2.Спецификации процессов.
Спецификации процессов обычно представляют в видекраткого текстового описания, схем алгоритмов, псевдокодов, Flow-форм или диаграммНасси-Шнейдермана. Поскольку описание процесса должно быть кратким и понятным какразработчику, так и заказчику, для их спецификации чаще всего используют псевдокоды.Словарь терминов. Словарь терминов представляет собой краткое описаниеосновных понятий, используемых при составлении спецификаций. Он должен включатьопределение основных понятий предметной области, описание структур элементов данных,их типов и форматов, а также всех сокращений и условных обозначений. Он предназначендля повышения степени понимания предметной области и исключения риска возникновенияразногласий при обсуждении моделей между заказчиками и разработчиками.Обычно описание термина в словаре выполняют по следующей схеме:• термин;• категория (понятие предметной области, элемент данных, условное обозначение ит.д.);• краткое описание.105В качестве примера приведем описание одного из терминов системы решениякомбинаторно-оптимизационных задач:Термин ........
…АлгоритмКатегория .... …Понятие предметной областиОписание .... …В настоящем проекте используется для обозначения обобщенногопонятия «реализация процедуры решения конкретной задачи выбраннымметодом»Кроме указанных моделей в состав полной спецификации при любом подходе могутвходить математические модели описания объектов предметной области, которые позволяютуточнить основные соотношения анализируемых величин и накладываемые на нихограничения.
Перейдем к более подробному рассмотрению перечисленных моделей.1064.2. Диаграммы переходов состоянийДиаграмма переходов состояний является графической формой предоставленияконечного автомата – математической абстракции, используемой для моделированиядетерминированного поведения технических объектов или объектов реального мира.На этапе анализа требований и определения спецификаций диаграмма переходовсостояний демонстрирует поведение разрабатываемой программной системы при полученииуправляющих воздействий. Под управляющими воздействиями или сигналами в данномслучае понимают управляющую информацию, получаемую системой извне. Например,управляющими воздействиями считают команды пользователя и сигналы датчиков,подключенных к компьютерной системе. Получив такое управляющее воздействие,разрабатываемая система должна выполнить определенные действия и или остаться в том жесостоянии, или перейти в другое состояние взаимодействия с внешней средой.Для построения диаграммы переходов состояний необходимо в соответствии с теориейконечных автоматов определить: основные состояния, управляющие воздействия (илиусловия перехода), выполняемые действия и возможные варианты переходов из одногосостояния в другое.
Условные обозначения, используемые при построении диаграммпереходов состояний, показаны на рис. 4.3.Если программная система в процессе функционирования активно не взаимодействуетс окружающей средой (пользователем или датчиками), например, использует примитивныйинтерфейс и выполняет некоторые вычисления по заданным исходным данным, то диаграммапереходов состояний обычно интереса не представляет.
В этом случае она демонстрируеттолько последовательно выполняемые переходы: из исходного состояния в состояние вводаданных, затем после выполнения вычислений – в состояние вывода и, наконец, в состояниезавершения работы (рис. 4.4).107Для интерактивного программного обеспечения с развитым пользовательскиминтерфейсом основные управляющие воздействия – команды пользователя, для программногообеспечения реального времени – сигналы от датчиков и/или оператора производственногопроцесса.
Общим для этих типов программного обеспечения является наличие состоянияожидания, когда программное обеспечение приостанавливает работу до полученияочередного управляющего воздействия. Для интерактивного программного обеспечениянаиболее характерно получение команд различных типов(рис. 4.5), а если это еще и программное обеспечениереального времени – однотипных сигналов (либо отмногих датчиков, либо требующих продолжительнойобработки).В отличие от интерактивных систем для системреального времени обычно установлено более жесткоеограничение на время обработки полученного сигналапрограммного обеспечения.
Такое ограничение частотребует выполнения дополнительных исследованийповедения системы во времени, например, сиспользованием сетей Петри или марковских процессов.К программному обеспечению, требующемууточненияособенностейповеденияпосредствомпостроения диаграммы переходов состояний, относится ипрограммное обеспечение, ориентированное на работу всети (см.
§1.1). При этом отдельно строят моделиповедения сервера и клиента, представляя сообщения,передаваемые между ними, в виде управляющихвоздействий.108Пример 4.1. Рассмотрим диаграмму переходов состояний для программы построенияграфиков функций одной переменной, техническое задание на которую представлено в § 3.4.Программа относится к классу интерактивных, соответственно на этапе анализа иопределения спецификаций целесообразно уточнить поведение программы на уровнеинтерфейса с пользователем, тем более, что наличие простого интерфейса оговорено втехническом задании. Один из возможных вариантов диаграммы переходов состоянийпрограммы представлен на рис. 4.6.Полученную диаграмму переходов состояний следует согласовать с заказчикомпрограммного обеспечения.4.3. Функциональные диаграммыФункциональными называют диаграммы, в первую очередь отражающие взаимосвязифункций разрабатываемого программного обеспечения. В качестве примера функциональноймодели рассмотрим активностную модель, предложенную Д.
Россом в составе методологиифункционального моделирования SADT (Structured Analysis and Design Technique технология структурного анализа и проектирования) в 1973 г. [58].Примечание. Методология SADT предполагает, что модель может основываться либо на функциях системы,либо на ее предметах (данных, оборудовании, информации и т. п.). В обоих случаях используют схожиеграфические нотации, но в первом случае блок соответствует109функции, а во втором - элементу данных. Соответствующие модели принято называть активностнымимоделями и моделями данных. Полная модель включает построение обеих моделей, обеспечивающих болееполное описание программного обеспечения, однако широкое распространение получили только активностные(функциональные) модели.
На основе методологии SADT в дальнейшем была построена известная методологияописания сложных систем IDEFO (Icam DEFinition - нотация ICAM), которая является основной частьюпрограммы ICAM (Integrated Computer-Aided Manufacturing - интегрированная компьютеризация производства),проводимой по инициативе ВВС США.Отображение взаимосвязи функций активностной модели осуществляетсяпосредствомпостроенияиерархиифункциональныхдиаграмм,схематическипредставляющих взаимосвязи нескольких функций. Каждый блок такой диаграммысоответствует некоторой функции, для которой должны быть определены: исходные данные,результаты, управляющая информация и механизмы ее осуществления - человек илитехнические средства.Все перечисленные выше связи функции представляются дугами, причем тип связи иее направление строго регламентированы.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
