Файл: Инфрам.pdf

138 граммной системы является сложным, трудоемким и достаточно затрат- ным процессом, требующим проведения в ряде случаев серьезных на- учных и инженерных исследований.
Проектирование любой программной системы (ПС) включает не- сколько различных процессов. При хорошо поставленном руководстве проектом эти процессы явно выражены, так что могут быть установле- ны контрольные сроки, выбрана методология и по завершении каждого процесса можно проверить “доброкачественность его результатов”.
На рис. 4.1 представлена модель процессов проектирования типич- ной большой программной системы, предложенная Г. Майерсом, кото- рая и сейчас не потеряла актуальности [11]. Заметим, что модель не за- висит от методологии проектирования, все указанные в ней действия должны выполняться в той или иной форме независимо от языка про- граммирования, писал ли исходные требования пользователь или заказ- чик, использовалось ли технология ООП, CASE-средства и т.д.
На первом шаге составляется перечень требований, т.е. четкое опре- деление того, что пользователь ожидает от готового продукта. Часто заказчик (пользователь) составляет этот перечень самостоятельно. В ряде случаев это делает разработчик в результате бесед с пользовате- лем, или исследуя его потребности, или оценивая эти потребности са- мостоятельно. Здесь заключены большие возможности для ошибок. На- пример, заказчик не может адекватно сформулировать свои потребно- сти, они могут быть неправильно поняты разработчиком или не учтены в полном объеме.
Следующий шаг – постановка целей – задач, которые ставятся перед окончательным результатом, т.е. программным продуктом и самим про- ектом. Здесь требуется выявить и оценить ряд компромиссных решений.
Могут быть ошибки из-за неправильной интерпретации требований или невыявления всего того, что требует компромиссных решений.
Третий шаг – выполнение предварительного внешнего проекта вы- сокого уровня. На этом шаге определяется взаимодействие с пользова- телем (оператором), но не рассматриваются многие детали проекта, на- пример, такие как форматы ввода-вывода данных. На этом шаге цели программного продукта и проекта преобразуются во внешние специфи- кации, т.е. точное описание поведения всей системы с точки зрения пользователя.
Внешний проект приводит к двум параллельным процессам:
1. Детальное внешнее проектирование – определение взаимодействия с
пользователем до мельчайших подробностей.
2. Разработка архитектуры системы – разложение ее на множество подсистем, программ или компонентов и определение сопряжений между ними.
Эти два шага ведут к процессу проектирования структуры про- граммной системы, в котором проектируются подсистемы, компоненты подсистем, модули и их сопряжения, а также взаимосвязи для каждой программы. Следующий процесс – внешнее проектирование каждого модуля – это точное определение всех сопряжений модулей. Заключи-

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

140 постановки задачи и заканчивающихся набором подробных инструкций, управляющих компьютером при решении задачи. Создание ПС в этом случае представляет собой совокупность процессов трансляции, т.е. перевода исходной задачи в различные промежуточные решения, пока, наконец, не будет получен подробный набор команд. Поэтому схему, изображенную на рис. 4.1 можно назвать макромоделью перевода сле- дующего вида [13]:
< Z, L
z
, P
z
>
PR
1
< TR
s
, L
TR
>
PR
2
< C s
, L
c
>
PR
3
…
< A s
, L
A
>
…
PR
N
< S, P
s
, L
м
> (4.1)
Здесь приняты следующие обозначения:
Z – предварительная постановка задачи на разработку ПС;
P
z
– параметры (характеристика) задачи;
L
z
– язык описания задачи;
PR
i
– процедура трансляции на i-ом этапе перевода, i = 1, 2, …, N;
N – количество различных этапов проектирования;
TR
s
– требования, предъявляемые к программной системе;
TR
s
= TR
F
TR
NF
;
TR
F
–функциональные требования, предъявляемые к системе;
TR
NF
– нефункциональные требования, предъявляемые к системе;
L
TR
– язык описания требований;
C
s
– цели программной системы (программного продукта);
L
c
– язык описания целей;
A s
– архитектура программной системы;
L
A
– язык описания архитектуры программной системы;
S – код разработанной программной системы;
P
s
– параметры кода программной системы;
L
м
– машинный язык.
Заметим, что на каждом этапе процесса создания ПС предполагается использование определенного языка описания (постановки) задачи.
Степень формализации этого языка растет по мере продвижения от од- ного этапа к следующему. Если на начальном этапе постановка задачи на разработку ПС заказчик использует чаще всего естественный разго- ворный язык, то с каждым следующим этапом язык становится все бо- лее формализованным, и наконец, созданный программный продукт на машинном языке исключает его неоднозначную трактовку. Отсюда ста- новится ясными следующие три положения, характерные для разработ- ки ПС:
1) недопонимание и разногласия между заказчиком и разработчиком связаны не только с неумением заказчика сформулировать проблему и незнанием предметной области разработчиком, но и низкой фор- мализацией языка описания проблемы, которая приводит к неодно- значной трактовке задачи;
2) наиболее крупные ошибки и просчеты допускаются на начальных этапах разработки ПС, их сложнее и дороже устранить, особенно на последующих этапах;

141 3) необходимо повышать уровень формализации языка постановки за- дачи каждого этапа разработки системы с целью исключения или снижения ее неоднозначной трактовки всеми заинтересованными лицами.
Сложность – основная причина ошибок перевода и одна из главных причин ненадежности программных систем [5, 11]. В общем случае сложность объекта является функцией взаимодействия между его ком- понентами. Сложность архитектуры системы определяется связями ме- жду подсистемами. Сложность проекта ПС – функция связи между мо- дулями (как ее оценить, рассмотрим ниже). Сложность отдельного мо- дуля – функция связи между его командами.
В борьбе со сложностью применимы две концепции общей теории систем. Первая – независимость. В соответствии с этой концепцией для минимизации сложности необходимо усилить независимость компонен- тов системы. По существу это означает такое разбиение системы, что- бы высокочастотная динамика (взаимодействие) системы была заклю- чена в единых компонентах, а межкомпонентные взаимодействия пред- ставляли лишь низкочастотную динамику системы.
Вторая концепция – иерархическая структура. Иерархия позволяет стратифицировать систему по уровням понимания. Каждый уровень представляет собой совокупность структурных отношений между эле- ментами нижних уровней. Концепция уровней позволяет понять систе- му, скрывая несущественные уровни детализации. Иерархия позволяет проектировать, описывать и понимать сложные системы.
К этим двум концепциям Г. Майерс [11] предлагает добавить тре- тью: проявление связей всюду, где они возникают, (точнее сказать – выявление результатов или возможных последствий этих связей). Ос- новная проблема многих больших ПС – огромное количество независи- мых побочных эффектов, создаваемых компонентами системы. Из-за них систему зачастую невозможно понять. И можно быть уверенным, что систему, в которой нельзя разобраться, трудно проектировать даже с минимальной гарантией надежности.
Проектное решение любого уровня имеет некоторую внутреннюю организацию, или форму. Для минимизации сложности нужен метод проявления этой формы, с тем, чтобы в соответствии с ней разбить про- ект на части. При внешнем проектировании разбиение системы в соот- ветствии с ее внутренней формой в [6] считается концептуальной цело- стностью системы.
Две самые распространенные ошибки при работе над программными проектами – это отказ от вовлечения пользователя системы в процессы принятия решений и неспособность (нежелание) понять его культурный уровень (подготовленность) и окружающую его обстановку. Имеется тенденция умышленно исключать пользователя из процесса принятия решения. Основная причина заключается в том, что разработчик чувст- вует: если привлечь пользователя, то тот никогда не придет к оконча- тельному решению, его требования будут постоянно меняться. Действи-

142 тельно, для такой тревоги есть основания, но преимущества от участия пользователя значительно превышают возможные неудобства.
Вторая ошибка программных проектов – разработчик слабо знает обстановку (или вовсе не знает), в которой находится пользователь, с какими трудностями он сталкивается, и как будет применять программ- ную систему. Бывает, что в проектировании операционной системы участвуют люди, никогда не использовавшие такие системы. Есть раз- работчики языков высокого уровня, никогда не пробовавшие реализо- вать прикладную программу на языке высокого уровня [11]. Это может привести к серьезным ошибкам в программной системе. Единственный способ избежать этих ошибок – поддерживать прочный контакт с поль- зователем в течение всего цикла разработки системы.
4.2. Методология решения задач проектирования
ПС по Г. Майерсу
Хотя, может быть, что в этом разделе читатель не увидит ничего принципиально нового, стоит обратить на него внимание.
Большинство процессов разработки программного обеспечения – это процессы решения некоторых задач. Например, в схеме по рис. 4.1 внешнее проектирование сводится к решению такой задачи: “Переведи- те множество целей системы во внешние спецификации”, где цели – исходные данные, а внешние спецификации – неизвестные. В задаче проектирования логики модуля даны внешние спецификации, а неиз- вестное – текст его программы.
Удивительно, по словам Г. Майерса, что разработчики программных систем не получили никакой специальной подготовки по общим мето- дам решения задач. В наше время, по происшествии 30 лет с момента издания его книги, ситуация практически не изменилась. По мнению Г.
Майерса, общая схема решения задачи может быть следующей.
Решение задачи
1. Поймите задачу: изучите данные; изучите неизвестные; достаточно ли данных для решения? не противоречивы ли они?
2. Составьте план: чего вы должны добиваться? какие методы проектирования будут использоваться? встречалась ил вам уже такая задача? не знаете ли вы близкой (подобной) задачи? можете ли вы воспользоваться ее результатом? можете ли вы решить более специализированную или аналогичную задачу? можете ли вы решить часть задачи?
3. Выполните план:

143 следуйте своему плану решения задачи; проверяйте правильность каждого шага.
4. Проанализируйте решение: все ли данные вы использовали? проверьте правильность решения; можете ли вы воспользоваться полученным результатом или приме- ненным методом при решении других задач?
Рассмотрим кратко элементы этой схемы. Худшая из ошибок, кото- рые могут быть сделаны при решении задачи, – не вполне разобраться в ее постановке. Чтобы хорошо понять задачу нужно уяснить два ее ком- понента – данные и неизвестное. Данные – это все факты, касающиеся задачи, и связи между фактами неизвестными. Уяснение всех данных о сложной задаче – абсолютно неизбежная и большая работа. При этом в первую очередь необходимо охватить “общую картину” данных без де- талей, которые, однако, тоже запоминаются “в сторонке”, чтобы их можно было легко вспомнить позже. Это позволяет увидеть общую кар- тину и определить место каждой детали.
Вторая часть задачи – неизвестное. Проектировщику следует пони- мать, какую форму должно иметь решение. Если, например, задача – детальное внешнее проектирование, то проектировщик должен ясно представлять назначение внешних спецификаций, их потенциальных читателей, формат представления результатов и т. д.
Прежде чем приступить к решению, следует разработать его план.
Отсутствие плана – очень распространенная ошибка. В плане нужно определить, чего вы хотите добиться. Десять человек могут иметь де- сять разных мнений относительно правильного ответа на задачу проек- тирования. Идея целей проекта (рассмотрим ее дальше) является реше- нием этой проблемы. Ее суть состоит в том, что на уровне всего проекта определяются общие цели, которыми следует руководствоваться во всех решениях при проектировании.
Ключевым компонентом успешного проектирования является мето- дология, выбор которой для каждого процесса проектирования должен быть зафиксирован в качестве одной их составляющих плана. Накоп- ленный опыт, образование и имеющиеся решения проблем также влия- ют на успех дела. Обычно проектировщик крайне редко сталкивается с задачей, которая уже не была бы решена полностью или частично. Даже если решение найти не удается, вероятно, когда-то была решена близкая задача. Если и этого не удается найти, может оказаться эффективным решение более специализированной задачи или части задачи. Наконец можно упростить задачу, найти ее решение, которое поможет лучше увидеть решение полной задачи. После этого можно прекратить зани- маться упрощенным вариантом и начать решение сначала (рис. 4.2).
Следующий шаг – решение в соответствии с запланированным под- ходом. Поскольку решение состоит из последовательности действий, разработчик должен проверять правильность каждого шага.
После получения результата нужно еще его проверить. Разработчик должен просмотреть все данные, чтобы убедиться, что учтено все, что

144 имеет отношение к проекту. Для этого полезно перечитать буквально каждое слово постановки задачи, вычеркивая каждый использованный в решении факт, а затем проверить, насколько существенно для задачи то, что осталось незачеркнутым.
Рис. 4.2. Последовательность решения задачи
Явно выделенным этапом всякого процесса проектирования должна быть проверка правильности результатов, т.е. попытка найти ошибки перевода, возникшие в этом процессе. Стоимость исправления ошибки тем ниже, чем раньше она обнаружена [5, 6]. К тому же вероятность правильного исправления ошибки на ранней стадии работы над проек- том значительно выше, чем в случае обнаружения ошибки на более поздних этапах.
Майерс предлагает сформулировать общую философию проверки в виде правила N плюс - минус один. Вопрос первостепенной важности при проверке – привлечение к этому “подходящих” людей. Наиболее подходящие люди – это те, в чьих интересах обнаружить все ошибки.
Правило “N плюс - минус один” состоит в следующем: проверка пра- вильности фазы N проекта должна осуществляться проектировщиками фаз N + 1 и N – 1. В основе философии правильности проверки лежит утверждение, что всякий процесс проверки правильности (тестирова- ния) должен иметь разрушительный, даже садистский характер [11].
Цель должна состоять в том, чтобы обнаружить любой мыслимый де- фект, любую слабость в проекте, а не в том, чтобы просмотреть проект и показать, что он правилен.

145