2.9 Табличные методы проектирования фпо

Цель – показать применение табличного метода проектирования программно-логических функций как инструмента, упрощающего разработку ФПО систем связи.

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

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

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

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

► «структура из функций»;

► «функции из структуры».

►Принцип «структура из функций». Самый распространённый эмпирический способ построения структур через описание функций системы, т.е. структура определяется перечислением функций, реализуемых ею. Описание ведется на языке функций, положительным свойством которого является простота структуры в виде набора функций. Однако структура такой системы является «жёсткой», не адаптируемой. Она плохо приспособлена к модернизации системы в процессе её «жизненного цикла». Для простых систем, содержащих небольшое количество функций, такой подход является приемлемым. Для систем, содержащих десятки и более функций и ориентированных на постоянную модернизацию в процессе «жизненного цикла», он явно не приемлем. Кроме того, существенным недостатком, даже при небольшом количестве функций, является невозможность видеть принцип построения функций. Структура такой системы отвечает на вопрос: что делает система? (какие её функции?). Более же важным на всех этапах разработки, и особенно при модернизации, является вопрос: как строятся функции? Его решение позволяет ответить на вопрос, какие вообще функции данного класса можно построить?

►Принцип «функции из структуры». Таким образом, построение структуры системы перечислением её функций, не даёт желаемого эффекта. Однако в ходе практической деятельности человека был создан другой – удобный и компактный способ построения структур в виде ограниченного числа элементов, с помощью которых, по заданным правилам их соединения (компоновки), строятся более крупные объекты. Например, буквы алфавита, из которых создаются слова, а из них строятся предложения; детские кубики, с помощью которых строятся рисунки.

Структура таких систем задаётся следующими компонентами:

♦ набора исходных компонент;

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

Описание функций здесь идёт на языке структуры. Достоинством таких структур, кроме их компактности, является и указание метода, как создать функции системы. Такая структура хорошо адаптируема, так как в ней заложен принцип построения её функций. Формально её можно задать в виде:

СТРУКТУРА = (ЭЛЕМЕНТЫ + СВЯЗИ) -> ЦЕЛОСТНОСТЬ

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

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

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

Как видно из описания, метод «структура из функций» затрагивает внешние компоненты системы (её функции).

Метод «функции из структуры», который даёт гибкую структуру, наоборот, для своей реализации требует глубинной проработки функций системы (т.е. внешне он «не виден»). Инструментом глубинных проработок систем является математика.

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

Таким образом, математическим методом построения функций из «кубиков» является аксиоматизация, в частности аксиоматизация класса программно-логических функций.

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

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

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

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

Абстрактный дискретный автомат. Абстрактный дискретный автомат (от греч. automatos – самодействующий) является математической конкретизацией ЧЯ. Он является базовой компонентой в теории автоматов, которая была разработана для логического описания электрических схем, содержащих логические элементы И, ИЛИ, НЕ.

Абстрактный дискретный автомат – объект, способ реализации которого не имеет значения (т.е.ЧЯ), и который описывается взаимосвязью множеств:

► входов X = {X₁, X_{2, ...,} X_i,…, X_m }

► выходов Y = {Y₁, Y_{2, ...,} Y_k …, Y_p }

► состояний S = {S₁, S_{2, ...,} S_j,…, S_n }

Задание работы автомата определяется указанием для каждой пары {Xi, Sj,}:

♦ входного сигнала Xi, который является причиной перехода состояния S(j-1) в состояние Sj;

♦ состояния Sr, в которое автомат переходит в результате отработки сигнала Xi;

♦ выходного сигнала Yk, который появляется на выходе автомата после отработки входного сигнала Xi;

В дискретном автомате приняты следующие допущения.

● Наличие произвольного числа отличных друг от друга состояний автомата.

● Переход из одного состояния в другое возможен не ранее чем через некоторый промежуток времени ∆ (∆>0 - интервал дискретности), т.е. автомат функционирует в дискретном времени t= 0,1,2,…

● Число различных входных и выходных сигналов конечно.

● Входные сигналы – причина перехода автомата из одного состояния в другое.

● Выходные сигналы – реакция автомата на входные сигналы, они относятся к моментам времени, определяемым соответствующими переходами автомата.

● Однозначность переходов: автомат, находящийся в некотором состоянии, под действием входного сигнала не может перейти более чем в одно состояние.

Формальное описание работы автомата во времени t задаётся на уровне его:

■ состояний (S);

■ выходных сигналов(Y).

В методологии рассматривается только описание работы автомата на уровне его состояний.

На уровне состояний формальное описание работы автомата во времени t задаётся в виде:

S(t) = Ψ [S(t- 1), X(t)] (1)

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

S(t) – одно из состояний в множестве S, в которое перешёл автомат в момент времени t;

S(t-1) – одно из состояний в множестве S, в котором находился автомат в момент времени (t – 1) (в момент, предыдущий перед t);

X(t) - один из входных сигналов в множестве X, приходящий в момент t.

Выражение .(1) задаёт следующее словесное описание работы автомата:

► если автомат в момент времени t находился в одном из своих состояний S(t-1)

► и пришёл входной сигнал X(t),

► то автомат перейдёт в состояние S(t).

Кроме функции перехода в абстрактном дискретном автомате используется и инструмент в виде таблицы переходов.

Таблицы переходов. Представим формально процесс одного из переходов S(t-1) в S(t) по функции в виде:

X(t) +S(t-1) ® S(t) (2)

Последовательность таких процессов в дискретные интервалы времени t = 1, 2, 3,…n дает описание алгоритма работы автомата. Таким образом, каждое состояние Sj в соответствующие дискретные моменты времени может быть или S(t-1) или S(t). Из этого следует, что для идентификации состояний их нужно нумеровать.

Например, фрагмент работы автомата имеет состояния S = {S₀, S₁, S₂, S₃, S₄}, входные сигналы X = {X₁, X₂, X₃} и 5 тактов (t1 - t5) работа фрагмента описываются следующим образом:

t = 1 X₁ + S₀ ® S₁ t = 4 X₃ + S₃ ® S₄

t = 2 X₃ + S₁ ® S₂ t = 5 X₂ + S₄ ® S₂

t = 3 X₂ + S₂ ® S₃ (3)

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

Такое описание при разработках различного типа систем или процессов удобно, т.к. требует только конкретизации в виде названий сигналов Xi и названий состояний алгоритма работы автомата Sj, ибо как реализуются (программно-аппаратный вид) эти компоненты на данном этапе значения не имеет. Недостатками такого описания являются:

● громоздкость (при большом количестве состояний и сигналов);

● абстрактность (для конкретного автомата нужно все время помнить как называются все Хi и Sj).

Представление автомата по (1) можно описываться в табличном виде. Такие таблицы называются таблицами переходов.

На рис.2.9.1 таблицей переходов описан фрагмент работы автомата по выражению (1).

В столбце «Названия сигналов» вписаны построчно обозначения входных сигналов X1, X2, X3 (названия сигналов и состояний в примере не даны). Столбцы S0, S1, S2, S3, S4 являются состояниями в S(t-1) по (1). В клетке на пересечении соответствующей строки с сигналом X(t) и столбца S(t-1) ставится состояние S(t). При разработке логических алгоритмов в табличном виде необходимо соблюдать все условия, данные для дискретных автоматов (см. раздел «абстрактный дискретный автомат»).

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

Названия сигналов	Названия состояний S0… S1… Sn….
	Состояние в S (t-1)
	S0	S1	S2	S3	S4
X1	S1
X2			S3		S2
X3		S2		S4

Рис.2.9.1 Фрагмент описания работы автомата таблицей переходов

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

Теория автоматов была разработана для электронных схем устройств, содержащих базовые логические схемы типа И,ИЛИ,НЕ. В них ясно, что подразумевалось под входными и выходными сигналами. Под состояниями схемы подразумевались состояния её электронных компонент от прихода входного сигнала до выдачи выходного сигнала. Для применения функции (1) как инструмента при разработке ФПО класса программно – логических функций необходима её интерпретация.

Входные сигналы X(t) интерпретируются как сигналы начала процесса по переводу любого состояния функции S(t-1) в состояние S(t). Например: действия абонентов на телефонном аппарате или мобильном телефоне (МТ); различные действия операторов на пультах (в том числе и проверка какой – либо информации, появляющейся на пульте, после которой необходимо провести какие – либо действия), отработка / не отработка устройства и т.д.

Окончание процесса перехода интерпретируется как переход в состояние S(t). Например: окончание какой–либо части реализуемой функции после нажатия клавиши на МТ; окончание какой-либо части процесса после прихода сигнала; «отклик» из оборудования после посылки в него входного сигнала; различного рода высветки, появляющиеся на пультах операторов после проведения каких – либо действий; и т.д.

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

Аналитическое представление автомата, как указано выше, даётся в виде функции переходов:

S(t) = Ψ [S(t- 1), X(t)] (3)

Семантика (смысл) компонент функции переходов (3) в данной интерпретации задаётся в виде:

♦ X(t) – множество входных сигналов, которые интерпретируются как действия абонентов;

♦ S – множество состояний алгоритма конкретной программно–логической функции;

♦ S(t- 1) – состояние функции до прихода xi сигнала из множества X(t), т.е. до действия абонента;

♦ S(t) – состояние функции после прихода и отработки xi сигнала из множества X(t), т.е. после обработки действия абонента;

♦ t – время, принимающее дискретные значения: 0, 1, 2…., n. В данной интерпретации каждая дискрета это время программной реализации алгоритма, переводящего состояние S(t- 1) в S(t);

♦ Ψ – функция, реализующая выражение (2). В данной интерпретации это, пока неизвестные алгоритмы, на основе которых будут реализованы программы перехода из состояния S(t- 1) в состояние S(t) под действием сигнала из множества X(t).

На уровне состояний реализация программно – логических функций по (2) во времени t описывается в виде:

● если алгоритм функции во время (t-1) был в состоянии S(t-1) и затем

● во время t пришёл сигнал X(t),

● то алгоритм функции переходит в состояние S(t).

Описание функций с такой интерпретацией ведётся с помощью таблицы переходов.

Стратегия разработки ФПО с использованием таблиц. Применение таблиц в программировании для описания логических процессов существенно меняет стратегию разработки ФПО. На рис.2.9.2 показаны схемы разработок программного обеспечения традиционным методом (рис.2.9.2а) и табличным (рис.2.9.2б) на уровне «функции - алгоритм – программы».

Ф П О

…

Ф П О

…

Функция 1

Функция k

Функция 1

Функция k

АЛГОРИТМЫ

…

Аксиоматика

функций

Функция 1

Функция k

табличный

шаблон

КОМПЬЮТЕР

КОМПЛЕКС ПРОГРАММ

…

…

программа1

программа k

КОМПЬЮТЕР

…

Функция 1

(таблица)

Функция 1

(таблица)

Функция k

(таблица)

Комплекс программ переходов состояний

S(t-1) в St

а)

Комплекс обработки

таблиц

б)

Рис. 2.9.2 Схема разработок ФПО традиционным и табличным методами

При традиционном методе ФПО делится на функции, затем разрабатываются их алгоритмы, после чего они программируются. Таким образом, получается столько программ сколько функций. В больших программных СРВ, где ОУ не компьютер, алгоритмы и программы разрабатываются, как правило, разными типами специалистов. При этом каждый тип специалистов, мысля в терминах своей предметной области, вынужден вникать в смысл другой области, в которой он не специалист. В таких системах непонимание между ними – основной источник ошибок.

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

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

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

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

На рис.2.9.3 дана принципиальная методологическая схема разработки программно-логических функций.

Рис.2.9.3 Методологическая схема разработки программно – логических функций

В схеме на рис.2.9.3 обозначены следующие этапы разработки:

Э1 – выделение функций реализуемого объекта с их описанием реализации.

Э2 – разработка конкретных элементов аксиоматики («кубиков») для выделенного объекта /создание логико-математической модели объекта проектирования/.

Э3 – выбор табличной формы для «связывания» элементов аксиоматики.

Э4 – описание реализуемого объекта с использованием компонент из Э2 и Э3.

Разработка по схеме на рис.2.9.2 заключается в следующем.

На этапе Э1 Выделяется объект проектирования т.е. как функция(и), так и её(их) описание их реализации в терминах ОУ. Например, для сотового телефона это будут реализуемые функции (каждая функция – это объект). Выбранный объект является «входными данными» для этапа Э2.

На этапе Э2 проводится разработка на основе интерпретации абстрактного автомата для реализации программно - логических функций конкретных компонент описания выделенного объекта. Например, для сотового телефона это будут действия абонента МТ (мобильного телефона), которые, как бы «разрезают» реализуемые функции на состояния (Sj)./кубики/ Этот этап является наиболее креативным, использующим принцип «что есть что?». Этап заканчивается выделением компонент выбранного объекта. Выходные данные этапа являются «входными данными» для этапа Э3 и как одна из компонент «входных данных» для этапа Э4.

На этапе Э3 проводится выбор одной из табличных форм для «связывания» компонент, полученных на этапе Э3. Здесь это таблица переходов. Табличная форма, помимо простоты «связывания» компонент, имеет и простую программную реализацию. Выбранная форма является одной из компонент «входных данных» для этапа Э4. Здесь также начинается разработка комплекса обработки выбранного типа таблиц. (Так как табличная форма выбирается для класса функций, то уже после реализации в табличном виде первой функции этот этап пропускается для всех остальных функций).

Полученные на этапах Э2 и Э3 компоненты в совокупности есть ни что иное как инструмент для реализации этапа Э4.

На этапе Э4 проводится табличное описание выбранного объекта с использованием инструмента, компоненты которого разработаны на этапах Э2 и Э3.

Место методологии в процессе проектирования. Данная методология в пособии обозначается как табличный метод проектирования алгоритмов класса программно - логических функций. Рассмотрим место данной методологии в процессе проектирования.

Разработка ПО СРВ характеризуется понятием «жизненный цикл», одним из компонентов которого является проектирование ПО, которое должно представляться в виде двух фаз (этапов):

♦ архитектурное проектирование (проектирование верхнего уровня);

♦ рабочее проектирование (детальное или проектирование нижнего уровня).

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

На этапе рабочего проектирования (РП) общее архитектурное описание детализируется до уровня реализации на соответствующем языке программирования.

Принципиальное отличие АП от РП состоит в том, что АП указывает направление конкретной разработки программ (т.е. направление достижения цели), а РП, согласно этому направлению реализует достижение поставленной цели в заданном направлении. /Образное различие АП с РП можно представить в виде следующей аналогии: поставлена задача (цель) – «прибыть из Санкт–Петербурга в Москву». На этапе АП решается задача выбора направления поездки: любой вид транспорта (поезд, самолёт, электричка, автомобиль) непосредственно от Санкт – Петербурга до Москвы, или, например, через Копенгаген и Париж (Санкт - Петербург - Копенгаген, Копенгаген – Париж, Париж – Москва). На этапе РП выбранное направление реализуется. Как видно из примера, если будет выбран путь через Копенгаген, Париж, то на этапе РП поездка «влетит в копеечку», не говоря уже о времени. Такой алогичный пример выбран специально, чтобы показать важность этапа АП. К сожалению, в программных разработках иногда выбирается путь через Копенгаген и Париж, ведь это не география, которую знают все/.

Табличный метод проектирования алгоритмов класса программно - логических функций для больших программных СРВ принадлежит к фазе АП, ибо он задаёт направление разработки алгоритмов с помощью таблиц. На фазе РП такое направление резко снижает объёмы работы, ибо вместо разработки массы программ, реализующих заданный класс алгоритмов функций, разрабатываются таблицы алгоритмов и один комплекс обработки всех таблиц, реализующих этот класс.

64