Решение проблемы дополнения и масштабирования программной

системы посредством создания контекста проектирования

 

А.И. Разумовский,

с.н.с., к.т.н.,

ИПУ им. В.А. Трапезникова РАН, г. Москва

 

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

Известно, что тем, кто занимается практическим программированием, часто не хватает понимания важности теоретических моделей и исследований в области разработки языков и технологий программирования. Более того, степень абстрагирования от реальной задачи, которая необходима на начальной стадии построения теоретической модели, иногда приводит к такому упрощению этой задачи, что теряется весь ее смысл. Как указывают в своей работе Т. Пратт и М. Зелковиц: «Надо сказать, что довольно часто так и происходит. Выбрав неверную теоретическую модель, можно ее исследовать и получить какие-то результаты, которые, однако, невозможно будет преобразовать в решение исходной практической задачи.» [1]

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

Решение такой непростой задачи следует искать в поисках путей формирования контекста проектирования (КП).

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

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

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

 

Создание контекста проектирования

 

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

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

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

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

Итак, необходимо стремиться на каждом этапе проектирования ограничить число единиц восприятия. Сузить число компонентов, оказывающих влияние на проектировщика  в плане выбора и определения структуры хранения, передачи данных или функциональных особенностей с теми или иными свойствами. То есть принимающими тот или иной набор параметров и возвращающих в результате определенные категории результатов. Количество таких элементов программы (алгоритма) должно быть сведено к минимуму в соответствии с "магическим числом" Миллера, число одновременно воспринимаемых человеком элементов пространства, - 7 плюс минус 2 [2].

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

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

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

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

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

Итак, в качестве примера, пусть имеется задача   2*2=4.

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

Элементами КП здесь являются два множителя и знак операции, к которым теперь добавляется результат:

.

Такой подход, очевидно, является адекватным традиционному человеческому мышлению, стремящемуся зафиксировать решение, изначально «выхватить» сущность задачи, то есть в первую очередь выделить крайние, основные, видимые элементы - исходные данные и результат.

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

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

 

Принципы организации КП алгоритма

 

1) Ориентация на результат.

 

                                                  (1)

Результат – это следствие применения оператора к  имеющемуся множеству элементов проектирования.

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

2) Фиксация действительных , а не предполагаемых связей между элементами в алгоритме. Следовательно, при изменение только одного из связанных элементов должно верифицировать всю фактологию связности в множестве  .

3) Результат, определяемый как (1), может быть использован в множестве , например так:

, тогда

                                        (2)

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

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

Далее, в соответствии со сформулированными принципами построения КП, следует вернуться к рассмотрению более сложного примера.

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

Очевидно, данная задача превращается в задачу пересчета ширины имеющегося окна в ширину строки символов.

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

Итак, первоначально имеется  два элемента КП: исходная S-строка, а также R- результат, выражаемый тройкой :

 - что означает, что результат определяется исходя из строки S и ее дополнений (или может быть, уместно было бы их назвать: фокусами) – k – начало отсчета, d – общее количество символов.

Следовательно, функционально,  результат является подстрокой, частью исходной строки:

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

Взаимодействие между элементами алгоритма изображается на рисунке 1.

 

 

Рис. 1

 

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

Изменяемость того или иного элемента КП алгоритма удобно сопрягается с понятием множественности, то есть при определении результата следует разграничить его так:

 

Тем самым, легко обнаруживается дискретность решений наряду с дискретностью свойств, то есть элементов КП – S, k и d. Схема КП тогда приобретает вид, показанный на рисунке 2., где хорошо заметно появление совокупных групп, независимых друг от друга. Можно также обратить внимание, что каждая из  таких групп элементов КП определяет достижимость результата.

 

Рис. 2

 

Подобная дискретность результатов обнаруживается через изменяемость элементов k и d.

Таким образом, можно всегда выбрать наиболее удовлетворяющий конкретным условиям

Если же строка – является изменчивым элементом, тогда результат будет определяться так:

Следовательно, для каждой измененной строки  существуют соответствующие ей  и , в совокупности определяющие  (рис. 2).

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

.

Таким образом, требуется создание условий верификации КП произвольного алгоритма.

Верификация контекста проектирования

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

-             мониторинг состава и содержания элементов КП, который включает контроль над сохранением соответствия абстрактной и описательной частей системы;

-             критику размерности структуры данных, что обеспечивает проектирование структуры данных с возможностью ее расширения – добавление «нижних» полей в структуре;

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

-             критику возможностей доступа. Когда каждый элемент системы доступен изначально каждому прочему элементу. Доступность определяется наличием в процедуре доступа ссылки на соответствующий элемент;

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

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

 

Заключение.

 

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

2.      Без КП нет полноты понимания индивидуального качества элементов алгоритма, а также порядка их размещения между смежными элементами проекта.

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

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

Литература

1.      Т. Пратт, М. Зелковиц Языки программирования: разработка и реализация, Питер, 2002 г.

2.      Miller, G. March. The Magical Number Seven,  Plus or Minus Two: Some Limits on Our Capacity for Processing Information.  The Psychological Review vol.63(2), p.86., 1956.