Учебник Технология программирования. Технология программирования
 Скачать 7.85 Mb.
|
|
SPICE. Стандарт SPICE унаследовал многие черты более ранних стандартов, в том числе и уже упоминавшихся ISO 9001 и СММ. Больше всего SPICE напоминает СММ. Точно так же, как и в СММ, основной задачей организации является постоянное улучшение процесса разработки программного обеспечения. Кроме того, в SPICE тоже используется схема с различными уровнями возможностей (в SPICE определено 6 различных уровней), но эти уровни применяются не только к организации в целом, но и к отдельно взятым процессам. В основе стандарта лежит оценка процессов. Эта оценка выполняется путем сравнения процесса разработки программного обеспечения, существующего в данной организации, с описанной в стандарте моделью. Анализ ре- 43 зультатов, полученных на этом этапе, помогает определить сильные и слабые стороны процесса, а также внутренние риски, присущие данному процессу. Это помогает оценить эффективность процессов, определить причины ухудшения качества и связанные с этим издержки во времени или стоимости. Затем выполняется определение возможностей процесса, т.е. возможностей его улучшения. В результате в организации может появиться понимание необходимости улучшения того или иного процесса. К этому моменту цели совершенствования процесса уже четко сформулированы и остается только техническая реализация поставленных задач. После этого весь цикл работ начинается сначала. Безусловно, совершенствование процессов жизненного цикла программного обеспечения абсолютно необходимо. Однако следует иметь в виду, что построение «более зрелого» процесса разработки не обязательно обеспечивает создание более качественного программного обеспечения. Это хотя и связанные, но совершенно различные процессы. Использование формальных моделей и методов позволяет создавать понятные, непротиворечивые спецификации на разрабатываемое программное обеспечение. Конечно, внедрение таких методов имеет смысл, хотя оно весьма дорого и трудоемко, а возможности их применения весьма ограничены. Основная же проблема – проблема сложности разрабатываемого программного обеспечения с совершенствованием процессов разработки пока не разрешена. Создание программного обеспечения по-прежнему предъявляет повышенные требования к квалификации тех, кто этим занимается: проектировщикам программного обеспечения и непосредственно программистам. Контрольные вопросы 1. Что понимают под термином «технология программирования»? 2. Что называют подходом и чем подход отличается от метода? 3. Назовите основные периоды истории развития технологии программирования. Чем характеризуются эти периоды? Как изменялись основные подходы и используемые средства? 4. Дайте определение понятию «сложная иерархическая система». Какой подход используют при разработке таких систем? На каких характеристиках этих систем он основан? В чем особенность данного подхода при разработке программного обеспечения? 5. Что понимают под термином «жизненный цикл программного обеспечения»? Какие основные процессы включают в это понятие? 6. Назовите основные этапы разработки программного обеспечения. Какие основные задачи решаются на этих этапах? 44 7. Назовите основные модели жизненного цикла программного обеспечения. С чем связано появление новых моделей? 8. Какие технологии называют CASE-технологиями? Почему? 9. Назовите основные составляющие любой CASE-технологии. 10. Перечислите основные положения технологии RAD? Какие программные системы нельзя разрабатывать с использованием этой технологии? 11. Что понимают под моделями качества процессов разработки программного обеспечения? Для чего они разработаны? Что гарантирует сертификация качества процессов? Почему? 12. Почему мы говорим, что современный этап развития технологии программирования характеризуется переходом от ремесленного к промышленному производству программного обеспечения? 45 2. ПРИЕМЫ ОБЕСПЕЧЕНИЯ ТЕХНОЛОГИЧНОСТИ ПРОГРАММНЫХ ПРОДУКТОВ В условиях индустриального подхода к разработке и сопровождению программного обеспечения особый вес приобретают технологические характеристики разрабатываемых программ. Для обеспечения необходимых технологических свойств применяют специальные технологические приемы и следуют определенным методикам, сформулированным всем предыдущим опытом создания программного обеспечения. К таким приемам и методикам относят правила декомпозиции, методы проектирования, программирования и контроля качества, которые под общим названием «структурный подход к программированию» были сформулированы еще в 60-х годах XX в. В его основу были положены следующие основные концепции: • нисходящая разработка; • модульное программирование; • структурное программирование; • сквозной структурный контроль. 2.1. Понятие технологичности программного обеспечения Под технологичностью понимают качество проекта программного продукта, от которого зависят трудовые и материальные затраты на его реализацию и последующие модификации. Хороший проект сравнительно быстро и легко кодируется, тестируется, отлаживается и модифицируется. Из опыта нескольких поколений разработчиков программного обеспечения известно, что технологичность программного обеспечения определяется проработанностью его моделей, уровнем независимости модулей, стилем программирования и степенью повторного использования кодов. Чем лучше проработана модель разрабатываемого программного обеспечения, тем четче определены подзадачи и структуры данных, хранящие входную, промежуточную и выходную информацию, тем проще их проектирование и реализация и меньше вероятность ошибок, для исправления которых потребуется существенно изменять программу. 46 Чем выше независимость модулей, тем их легче понять, реализовывать, модифицировать, а также находить в них ошибки и исправлять их. Стиль программирования, под которым понимают стиль оформления программ и их «структурность», также существенно влияет на читаемость программного кода и количество ошибок программирования. Кризис 60-х годов XX в. был вызван в том числе и стилем программирования, при котором программа напоминала клубок спутанных ниток или блюдо спагетти, и отсутствием языковых конструкций поддержки «структурного» стиля. Увеличение степени повторного использования кодов предполагает как использование ранее разработанных библиотек подпрограмм или классов, так и унификацию кодов текущей разработки. Причем для данного критерия ситуация не так однозначна, как в предыдущих случаях: если степень повторного использования кодов повышается искусственно (например, путем разработки «суперуниверсальных» процедур), то технологичность проекта может существенно снизиться. Как следует из определения, высокая технологичность проекта особенно важна, если разрабатывается программный продукт, рассчитанный на многолетнее интенсивное использование, или необходимо обеспечить повышенные требования к его качеству. 2.2. Модули и их свойства При проектировании достаточно сложного программного обеспечения после определения его общей структуры выполняют декомпозицию компонентов в соответствии с выбранным подходом до получения элементов, которые, по мнению проектировщика, в дальнейшей декомпозиции не нуждаются. Как уже упоминалось раньше, в настоящее время используют два способа декомпозиции разрабатываемого программного обеспечения, связанные с соответствующим подходом: • процедурный (или структурный - по названию подхода); • объектный. Примечание. Помимо указанных способов декомпозиции, в теории программирования определяют и другие способы декомпозиции: логическую - на факты и правила, продукционную - на правила продукции и т.п. Эти способы декомпозиции используют в языках искусственного интеллекта, поэтому в настоящем учебнике они рассматриваться не будут. Результатом процедурной декомпозиции является иерархия подпрограмм (процедур), в которой функции, связанные с принятием решения, реализуются подпрограммами верхних уровней, а непосредственно обработка – подпрограммами нижних уровней. Это согласуется с принципом вертикального управления, который был сформулирован вместе с другими реко- 47 мендациями структурного подхода к программированию. Он также ограничивает возможные варианты передачи управления, требуя, чтобы любая подпрограмма возвращала управление той подпрограмме, которая ее вызвала. Результатом объектной декомпозиции является совокупность объектов, которые затем реализуют как переменные некоторых специально разрабатываемых типов (классов), представляющих собой совокупность полей данных и методов, работающих с этими полями. Таким образом, при любом способе декомпозиции получают набор связанных с соответствующими данными подпрограмм, которые в процессе реализации организуют в модули. Модули. Модулем называют автономно компилируемую программную единицу. Термин «модуль» традиционно используется в двух смыслах. Первоначально, когда размер программ был сравнительно невелик, и все подпрограммы компилировались отдельно, под модулем понималась подпрограмма, т.е. последовательность связанных фрагментов программы, обращение к которой выполняется по имени. Со временем, когда размер программ значительно вырос, и появилась возможность создавать библиотеки ресурсов: констант, переменных, описаний типов, классов и подпрограмм, термин «модуль» стал использоваться и в смысле автономно компилируемый набор программных ресурсов. Данные модуль может получать и/или возвращать через общие области памяти или параметры. Первоначально к модулям (еще понимаемым как подпрограммы) предъявлялись следующие требования: • отдельная компиляция; • одна точка входа; • одна точка выхода; • соответствие принципу вертикального управления; • возможность вызова других модулей; • небольшой размер (до 50-60 операторов языка); • независимость от истории вызовов; • выполнение одной функции. Требования одной точки входа, одной точки выхода, независимости от истории вызовов и соответствия принципу вертикального управления были вызваны тем, что в то время из-за серьезных ограничений на объем оперативной памяти программисты были вынуждены разрабатывать программы с максимально возможной повторяемостью кодов. В результате подпрограммы, имеющие несколько точек входа и выхода, были не только обычным явлением, но и считались высоким классом программирования. Следствием же было то, что программы было очень сложно не только модифицировать, но и понять, а иногда и просто полностью отладить. Со временем, когда основные требования структурного подхода стали поддерживаться языками программирования, и под модулем стали понимать 48 отдельно компилируемую библиотеку ресурсов, требование независимости модулей стало основным. Практика показала, что чем выше степень независимости модулей, тем: • легче разобраться в отдельном модуле и всей программе и, соответственно, тестировать, отлаживать и модифицировать ее; • меньше вероятность появления новых ошибок при исправлении старых или внесении изменений в программу, т. е. вероятность появления «волнового» эффекта; • проще организовать разработку программного обеспечения группой программистов и легче его сопровождать. Таким образом, уменьшение зависимости модулей улучшает технологичность проекта. Степень независимости модулей (как подпрограмм, так и библиотек) оценивают двумя критериями: сцеплением и связностью. Сцепление модулей. Сцепление является мерой взаимозависимости модулей, которая определяет, насколько хорошо модули отделены друг от друга. Модули независимы, если каждый из них не содержит о другом никакой информации. Чем больше информации о других модулях хранит модуль, тем больше он с ними сцеплен. Различают пять типов сцепления модулей: • по данным; • по образцу; • по управлению; • по общей области данных; • по содержимому. Сцепление по данным предполагает, что модули обмениваются данными, представленными скалярными значениями. При небольшом количестве передаваемых параметров этот тип обеспечивает наилучшие технологические характеристики программного обеспечения. Например, функция Мах предполагает сцепление по данным через параметры скалярного типа: Function Max(a, b: integer):integer; begin if a>b then Max:=a else Max: =b; end; Сцепление по образцу предполагает, что модули обмениваются данными, объединенными в структуры. Этот тип также обеспечивает неплохие характеристики, но они хуже, чем у предыдущего типа, так как конкретные передаваемые данные «спрятаны» в структуры, и потому уменьшается «прозрачность» связи между модулями. Кроме того, при изменении структуры 49 передаваемых данных необходимо модифицировать все использующие ее модули. Так, функция MaxEl, описанная ниже, предполагает сцепление по образцу (параметр а – открытый массив). Function МахEl(а:array of integer):integer; Var i:word; begin MaxEl: =a[0]; for i:=l to High(a) do if a[i]>MaxEl then MaxEl: =a[i]; end; При сцеплении по управлению один модуль посылает другому некоторый информационный объект (флаг), предназначенный для управления внутренней логикой модуля. Таким способом часто выполняют настройку режимов работы программного обеспечения. Подобные настройки также снижают наглядность взаимодействия модулей и потому обеспечивают еще худшие характеристики технологичности разрабатываемого программного обеспечения по сравнению с предыдущими типами связей. Например, функция MinMax предполагает сцепление по управлению, так как значение параметра flag влияет на логику программы: если функция MinMax получает значение параметра flag, равное true, то возвращает максимальное значение из двух, а если false, то минимальное: Function MinMax(a, b:integer; flag:boolean):integer; begin if (a>b) and (flag) then MinMax: =a else MinMax: =b; end; Сцепление по общей области данных предполагает, что модули работают с общей областью данных. Этот тип сцепления считается недопустимым, поскольку: • программы, использующие данный тип сцепления, очень сложны для понимания при сопровождении программного обеспечения; • ошибка одного модуля, приводящая к изменению общих данных, может проявиться при выполнении другого модуля, что существенно усложняет локализацию ошибок; • при ссылке к данным в общей области модули используют конкретные имена, что уменьшает гибкость разрабатываемого программного обеспечения. 50 Например, функция МахА, использующая глобальный массив А, сцеплена с основной программой по общей области: Function MaxA:integer; Var i:word; begin МахА: =a[Low(a)]; for i:= Low(a)+1 to High(a) do if a[i]>MaxA then MaxA:=a[i]; end; Следует иметь в виду, что «подпрограммы с памятью», действия которых зависят от истории вызовов, используют сцепление по общей области, что делает их работу в общем случае непредсказуемой. Именно этот вариант используют статические переменные С и C++. В случае сцепления по содержимому один модуль содержит обращения к внутренним компонентам другого (передает управление внутрь, читает и/или изменяет внутренние данные или сами коды), что полностью противоречит блочно-иерархическому подходу. Отдельный модуль в этом случае уже не является блоком («черным ящиком»): его содержимое должно учитываться в процессе разработки другого модуля. Современные универсальные языки процедурного программирования, например Pascal, данного типа сцепления в явном виде не поддерживают, но для языков низкого уровня, например Ассемблера, такой вид сцепления остается возможным. В табл. 2.1 приведены характеристики различных типов сцепления по экспертным оценкам [21, 30]. Допустимыми считают первые три типа сцепления, так как использование остальных приводит к резкому ухудшению технологичности программ. Таблица 2.1 Тип сцепления Сцепление, балл Устойчивость к ошибкам других модулей Наглядность (понятность) Возможность изменения Вероятность использования По данным 1 Хорошая* Хорошая Хорошая Большая По образцу 3 Средняя Хорошая* Средняя Средняя По управлению 4 Средняя Плохая Плохая Малая По общей области 6 Плохая Плохая Средняя Малая По содержимому 10 Плохая Плохая Плохая Малая * Зависит от количества параметров интерфейса. 51 Как правило, модули сцепляются между собой несколькими способами. Учитывая это, качество программного обеспечения принято определять по типу сцепления с худшими характеристиками. Так, если использовано сцепление по данным и сцепление по управлению, то определяющим считают сцепление по управлению. В некоторых случаях сцепление модулей можно уменьшить, удалив необязательные связи и структурировав необходимые связи. Примером может служить объектно- ориентированное программирование, в котором вместо большого количества параметров метод неявно получает адрес области (структуры), в которой расположены поля объекта, и явно – дополнительные параметры. В результате модули оказываются сцепленными по образцу. Связность модулей. Связность –мера прочности соединения функциональных и информационных объектов внутри одного модуля. Если сцепление характеризует качество отделения модулей, то связность характеризует степень взаимосвязи элементов, реализуемых одним модулем. Размещение сильно связанных элементов в одном модуле уменьшает межмодульные связи и, соответственно, взаимовлияние модулей. В то же время помещение сильно связанных элементов в разные модули не только усиливает межмодульные связи, но и усложняет понимание их взаимодействия. Объединение слабо связанных элементов также уменьшает технологичность модулей, так как такими элементами сложнее мысленно манипулировать. Различают следующие виды связности (в порядке убывания уровня): • функциональную; • последовательную; • информационную (коммуникативную); • процедурную; • временную; • логическую; • случайную. При функциональной связности все объекты модуля предназначены для выполнения одной функции (рис. 2.1, а): операции, объединяемые для выполнения одной функции, или данные, связанные с одной функцией. Модуль, элементы которого связаны функционально, имеет четко определенную цель, при его вызове выполняется одна задача, например, подпрограмма поиска минимального элемента массива. Такой модуль имеет максимальную связность, следствием которой являются его хорошие технологические качества: простота тестирования, модификации и сопровождения. Именно с этим связано одно из требований структурной декомпозиции «один модуль – одна функция». Из тех же соображений следует избегать неструктурированного распределения функции между модулями – библиотеками ресурсов. Например, если при проектировании текстового редактора предполагается функция редак- 52 тирования, то лучше организовать модуль – библиотеку функций редактирования, чем поместить часть функций в один модуль, а часть в другой. При последовательной связности функций выход одной функции служит исходными данными для другой функции (рис. 2.1, б). Как правило, такой модуль имеет одну точку входа, т.е. реализует одну подпрограмму, выполняющую две функции. Считают, что данные, используемые последовательными функциями, также связаны последовательно. Модуль с последовательной связностью функций можно разбить на два или более модулей, как с последовательной, так и с функциональной связностью. Такой модуль выполняет несколько функций, и, следовательно, его технологичность хуже: сложнее организовать тестирование, а при выполнении модификации мысленно приходится разделять функции модуля. Информационно связанными считают функции, обрабатывающие одни и те же данные (рис. 2.1, в). При использовании структурных языков программирования раздельное выполнение функций можно осуществить только, если каждая функция реализуется своей подпрограммой. Хотя раньше в подобных случаях обычно использовали разные точки входа в модуль, оформленный как одна подпрограмма. Несмотря на объединение нескольких функций, информационно связанный модуль имеет неплохие показатели технологичности. Это объясняется тем, что все функции, работающие с некоторыми данными, собраны в одно 53 место, что позволяет при изменении формата данных корректировать только один модуль. Информационно связанными также считают данные, которые обрабатываются одной функцией. Процедурно связаны функции или данные, которые являются частями одного процесса (рис. 2.1, г). Обычно модули с процедурной связностью функций получают, если в модуле объединены функции альтернативных частей программы. При процедурной связности отдельные элементы модуля связаны крайне слабо, так как реализуемые ими действия связаны лишь общим процессом, следовательно, технологичность данного вида связи ниже, чем предыдущего. Временная связность функций подразумевает, что эти функции выполняются параллельно или в течение некоторого периода времени (рис. 2.1, д). Временная связность данных означает, что они используются в некотором временном интервале. Например, временную связность имеют функции, выполняемые при инициализации некоторого процесса. Отличительной особенностью временной связности является то, что действия, реализуемые такими функциями, обычно могут выполняться в любом порядке. Содержание модуля с временной связностью функций имеет тенденцию меняться: в него могут включаться новые действия и/или исключаться старые. Большая вероятность модификации функции еще больше уменьшает показатели технологичности модулей данного вида по сравнению с предыдущим. Логическая связь базируется на объединении данных или функций в одну логическую группу (рис. 2.1, е). В качестве примера можно привести функции обработки текстовой информации или данные одного и того же типа. Модуль с логической связностью функций часто реализует альтернативные варианты одной операции, например, сложение целых чисел и сложение вещественных чисел. Из такого модуля всегда будет вызываться одна какая-либо его часть, при этом вызывающий и вызываемый модули будут связаны по управлению. Понять логику работы модулей, содержащих логически связанные компоненты, как правило, сложнее, чем модулей, использующих временную связность, следовательно их показатели технологичности еще ниже. В том случае, если связь между элементами мала или отсутствует, считают, что они имеют случайную связность. Модуль, элементы которого связаны случайно, имеет самые низкие показатели технологичности, так как элементы, объединенные в нем, вообще не связаны. Обратите внимание, что в трех предпоследних случаях связь между несколькими подпрограммами в модуле обусловлена внешними причинами. А в последнем – вообще отсутствует. Это соответствующим образом проецируется на технологические характеристики модулей. В табл. 2.2 представлены характеристики различных видов связности по экспертным оценкам [21, 30]. Анализ табл. 2.2 показывает, что на практике целесообразно использовать функциональную, последовательную и информационную связности. 54 Таблица 2.2 Вид связности Сцепление, балл Наглядность (понятность) Возможность изменения Сопровождаемость Функциональная 10 Хорошая Хорошая Хорошая Последовательная 9 Хорошая Хорошая Хорошая Информационная 8 Средняя Средняя Средняя Процедурная 5 Средняя Средняя Плохая Временная 3 Средняя Средняя Плохая Логическая 1 Плохая Плохая Плохая Случайная 0 Плохая Плохая Плохая Как правило, при хорошо продуманной декомпозиции модули верхних уровней иерархии имеют функциональную или последовательную связность функций и данных. Для модулей обслуживания данных характерна информационная связность функций. Данные таких модулей могут быть связаны по-разному. Так, модули, содержащие описание классов при объектно-ориентированном подходе, характеризуются информационной связностью методов и функциональной связностью данных. Получение в процессе декомпозиции модулей с другими видами связности, скорее всего, означает недостаточно продуманное проектирование. Исключением являются лишь библиотеки ресурсов. Библиотеки ресурсов. Различают библиотеки ресурсов двух типов: библиотеки подпрограмм и библиотеки классов. Библиотеки подпрограмм реализуют функции, близкие по назначению, например, библиотека графического вывода информации. Связность подпрограмм между собой в такой библиотеке – логическая, а связность самих подпрограмм – функциональная, так как каждая из них обычно реализует одну функцию. Библиотеки классов реализуют близкие по назначению классы. Связность элементов класса – информационная, связность классов между собой может быть функциональной - для родственных или ассоциированных классов и логической – для остальных. В качестве средства улучшения технологических характеристик библиотек ресурсов в настоящее время широко используют разделение тела модуля на интерфейсную часть и область реализации (секции Interface и Implementation – в Pascal, h и срр-файлы в C++ и в Java). Интерфейсная часть в данном случае содержит совокупность объявлений ресурсов (заголовков подпрограмм, имен переменных, типов, классов и 55 т.п.), которые данная библиотека предоставляет другим модулям. Ресурсы, объявление которых в интерфейсной части отсутствует, извне не доступны. Область реализации содержит тела подпрограмм и, возможно, внутренние ресурсы (подпрограммы, переменные, типы), используемые этими подпрограммами. При такой организации любые изменения реализации библиотеки, не затрагивающие ее интерфейс, не требуют пересмотра модулей, связанных с библиотекой, что улучшает технологические характеристики модулей- библиотек. Кроме того, подобные библиотеки, как правило, хорошо отлажены и продуманы, так как часто используются разными программами. 2.3. Нисходящая и восходящая разработка программного обеспечения При проектировании, реализации и тестировании компонентов структурной иерархии, полученной при декомпозиции, применяют два подхода: • восходящий; • нисходящий. В литературе встречается еще один подход, получивший название «расширение ядра». Он предполагает, что в первую очередь проектируют и разрабатывают некоторую основу – ядро программного обеспечения, например, структуры данных и процедуры, связанные с ними. В дальнейшем ядро наращивают, комбинируя восходящий и нисходящий методы. На практике данный подход в зависимости от уровня ядра практически сводится либо к нисходящему, либо к восходящему подходам. Восходящий подход. При использовании восходящего подхода сначала проектируют и реализуют компоненты нижнего уровня, затем предыдущего и т.д. По мере завершения тестирования и отладки компонентов осуществляют их сборку, причем компоненты нижнего уровня при таком подходе часто помещают в библиотеки компонентов. Для тестирования и отладки компонентов проектируют и реализуют специальные тестирующие программы. Подход имеет следующие недостатки: • увеличение вероятности несогласованности компонентов вследствие неполноты спецификаций; • наличие издержек на проектирование и реализацию тестирующих программ, которые нельзя преобразовать в компоненты; • позднее проектирование интерфейса, а соответственно невозможность продемонстрировать его заказчику для уточнения спецификаций и т.д. Исторически восходящий подход появился раньше, что связано с особенностью мышления программистов, которые в процессе обучения привыкают при написании небольших программ сначала детализировать компоненты нижних уровней (подпрограммы, классы). Это позволяет им лучше 56 осознавать процессы верхних уровней. При промышленном изготовлении программного обеспечения восходящий подход в настоящее время практически не используют. Нисходящий подход. Нисходящий подход предполагает, что проектирование и последующая реализация компонентов выполняется «сверху-вниз», т.е. вначале проектируют компоненты верхних уровней иерархии, затем следующих и так далее до самых нижних уровней. В той же последовательности выполняют и реализацию компонентов. При этом в процессе программирования компоненты нижних, еще не реализованных уровней заменяют специально разработанными отладочными модулями – «заглушками», что позволяет тестировать и отлаживать уже реализованную часть. При использовании нисходящего подхода применяют иерархический, операционный и комбинированный методы определения последовательности проектирования и реализации компонентов. Иерархический метод предполагает выполнение разработки строго по уровням. Исключения допускаются при наличии зависимости по данным, т.е. если обнаруживается, что некоторый модуль использует результаты другого, то его рекомендуется программировать после этого модуля. Основной проблемой данного метода является большое количество достаточно сложных заглушек. Кроме того, при использовании данного метода основная масса модулей разрабатывается и реализуется в конце работы над проектом, что затрудняет распределение человеческих ресурсов. Операционный метод связывает последовательность разработки модулей с порядком их выполнения при запуске программы. Применение метода усложняется тем, что порядок выполнения модулей может зависеть от данных. Кроме того, модули вывода результатов, несмотря на то, что они вызываются последними, должны разрабатываться одними из первых, чтобы не проектировать сложную заглушку, обеспечивающую вывод результатов при тестировании. С точки зрения распределения человеческих ресурсов сложным является начало работ, пока не закончены все модули, находящиеся на так называемом критическом пути. Комбинированный метод учитывает следующие факторы, влияющие на последовательность разработки: • достижимость модуля – наличие всех модулей в цепочке вызова данного модуля; • зависимость по данным – модули, формирующие некоторые данные, должны создаваться раньше обрабатывающих; • обеспечение возможности выдачи результатов – модули вывода результатов должны создаваться раньше обрабатывающих; • готовность вспомогательных модулей – вспомогательные модули, например, модули закрытия файлов, завершения программы, должны создаваться раньше обрабатывающих; • наличие необходимых ресурсов. 57 Кроме того, при прочих равных условиях сложные модули должны разрабатываться прежде простых, так как при их проектировании могут выявиться неточности в спецификациях, а чем раньше это произойдет, тем лучше. Нисходящий подход допускает нарушение нисходящей последовательности разработки компонентов в специально оговоренных случаях. Так, если некоторый компонент нижнего уровня используется многими компонентами более высоких уровней, то его рекомендуют проектировать и разрабатывать раньше, чем вызывающие его компоненты. И, наконец, в первую очередь проектируют и реализуют компоненты, обеспечивающие обработку правильных данных, оставляя компоненты обработки неправильных данных напоследок. Пример определения последовательности реализации модулей будет рассмотрен в § 5.2. Нисходящий подход обычно используют и при объектно-ориентированном программировании. В соответствии с рекомендациями подхода вначале проектируют и реализуют пользовательский интерфейс программного обеспечения, затем разрабатывают классы некоторых базовых объектов предметной области, а уже потом, используя эти объекты, проектируют и реализуют остальные компоненты. Нисходящий подход обеспечивает: • максимально полное определение спецификаций проектируемого компонента и согласованность компонентов между собой; • раннее определение интерфейса пользователя, демонстрация которого заказчику позволяет уточнить требования к создаваемому программному обеспечению; • возможность нисходящего тестирования и комплексной отладки (см. гл. 9). 2.4. Структурное и «неструктурное» программирование. Средства описания структурных алгоритмов Одним из способов обеспечения высокого уровня технологичности разрабатываемого программного обеспечения является структурное программирование. Различают три вида вычислительного процесса, реализуемого программами: линейный, разветвленный и циклический. Линейная структура процесса вычислений предполагает, что для получения результата необходимо выполнить некоторые операции в определенной последовательности. 58 Разветвленная структура процесса вычислений предполагает, что конкретная последовательность операций зависит от значений одной или нескольких переменных. Циклическая структура процесса вычислений предполагает, что для получения результата некоторые действия необходимо выполнить несколько раз. Для реализации указанных вычислительных процессов в программах используют соответствующие управляющие операторы. Первые процедурные языки программирования высокого уровня, такие, как FORTRAN, понятием «тип вычислительного процесса» не оперировали. Для изменения линейной последовательности операторов в них, как в языках низкого уровня, использовались команды условной (при выполнении некоторого условия) и безусловной передач управления. Потому и программы, написанные на этих языках, имели запутанную структуру, присущую в настоящее время только низкоуровневым (машинным) языкам. Именно для изображения схем алгоритмов таких программ в свое время был разработан ГОСТ 19.701-90, согласно которому каждой группе действий ставится в соответствие специальный блок (табл. 2.3). Хотя этот стандарт предусматривает блоки для обозначения циклов, он не запрещает и произвольной передачи управления, т.е. допускает использование команд условной и безусловной передачи управления при реализации алгоритма. В качестве примера, демонстрирующего особенности использования команд передачи управления для организации требуемого типа вычислительного процесса, рассмотрим программу на языке Ассемблера. Пример 2.1 (вариант 1). Реализовать на языке Ассемблера подпрограмму поиска минимального элемента массива а(n). На рис. 2.2 приведен пример неудачной реализации этой подпрограммы. Стрелками показаны передачи управления. Даже с комментариями и стрелками понять хорошо известный алгоритм достаточно сложно. загрузили адрес массива загрузили счетчик - количество элементов приняли элемент в качестве максимума уменьшили счетчик если все числа, то выход адрес следующего элемента сравниваем текущий элемент если меньше, то меняем максимум иначе переходим к следующему элементу. 59 После того, как в 60-х годах XX в. было доказано, что любой сколь угодно сложный алгоритм можно представить с использованием трех основных управляющих конструкций, в языках программирования высокого уровня появились управляющие операторы для реализации соответствующих конструкций. Эти три конструкции принято считать базовыми. К ним относят конструкции: • следование - обозначает последовательное выполнение действий (рис. 2.3, а); • ветвление - соответствует выбору одного из двух вариантов действий (рис.2.3, б); 60 • цикл-пока - определяет повторение действий, пока не будет нарушено некоторое условие, выполнение которого проверяется в начале цикла (рис. 2.3, в). Помимо базовых, процедурные языки программирования высокого уровня обычно используют еще три конструкции, которые можно составить из базовых: • выбор - обозначает выбор одного варианта из нескольких в зависимости от значения некоторой величины (рис. 2.4, а); • цикл-до - обозначает повторение некоторых действий до выполнения заданного условия, проверка которого осуществляется после выполнения действий в цикле (рис.2.4,б); • цикл с заданным числом повторений (счетный цикл) - обозначает повторение некоторых действий указанное количество раз (рис. 2.4, в). Любая из дополнительных конструкций легко реализуется через базовые. Перечисленные шесть конструкций были положены в основу структурного программирования. 61 Примечание. Слово «структурное» в данном названии подчеркивает тот факт, что при программировании использованы только перечисленные конструкции (структуры). Отсюда и понятие «программирование без go to». Программы, написанные с использованием только структурных операторов передачи управления, называют структурными, чтобы подчеркнуть их отличие от программ, при проектировании или реализации которых использовались низкоуровневые способы передачи управления. Несмотря на то, что Ассемблер не предусматривает соответствующих конструкций, «структурно» можно программировать и на нем. Вернемся к примеру 2.1. Пример 2.1 (вариант 2). Поскольку реализуемый цикл по типу «счетный» с количеством повторений n-1, используем соответствующую команду Ассемблера. Уберем и усложняющий понимание возврат на метку less, заменив его дубликатом команды сохранения текущего максимального элемента. Полученный в результате «структурированный» вариант программы поиска максимального элемента массива приведен на рис. 2.5. Единственный возврат реализует циклический процесс, а передача управления на следующие команды – ветвление. Представление алгоритма программы в виде схемы с точки зрения структурного программирования имеет два недостатка: • предполагает слишком низкий уровень детализации, что часто скрывает суть сложных алгоритмов; • позволяет использовать неструктурные способы передачи управления, причем часто на схеме алгоритма они выглядят проще, чем эквивалентные структурные. 62 Классическим примером последнего является организация поискового цикла с использованием неструктурной передачи управления (рис. 2.6, а) и эквивалентный структурный вариант (рис. 2.6, 6). Кроме схем, для описания алгоритмов можно использовать псевдокоды, Flow-формы и диаграммы Насси-Шнейдермана. Все перечисленные нотации с одной стороны базируются на тех же основных структурах, что и структурное программирование, а с другой – допускают разные уровни детализации. Псевдокоды. Псевдокод – формализованное текстовое описание алгоритма (текстовая нотация). В литературе были предложены несколько вариантов псевдокодов. Один из них приведен в табл. 2.4. Описать с помощью псевдокодов неструктурный алгоритм невозможно. Использование псевдокодов изначально ориентирует проектировщика только на структурные способы передачи управления, а потому требует более тщательного анализа разрабатываемого алгоритма. В отличие от схем алгоритмов, псевдокоды не ограничивают степень детализации проектируемых операций. Они позволяют соизмерять степень детализации действия с уровнем абстракции, на котором это действие рассматривают, и хорошо согласуются с основным методом структурного программирования – методом пошаговой детализации. 63 Таблица 2.4 Структура Псевдокод Структура Псевдокод Следование <действие 1> <действие 2> Выбор Выбор <код> <код 1>: <действие 1> <код 2>: <действие 2> Все-выбор Ветвление Если <условие> то <действие 1> иначе <действие 2> Все-если Цикл с заданным количеством повторений Для <индекс> = |