tehnologia (Г.С. Иванова - Учебник - Технология программирования), страница 9

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

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

Что понимают под термином «технология программирования»?2. Что называют подходом и чем подход отличается от метода?3. Назовите основные периоды истории развития технологии программирования. Чемхарактеризуются эти периоды? Как изменялись основные подходы и используемые средства?4. Дайте определение понятию «сложная иерархическая система». Какой подход используют приразработке таких систем? На каких характеристиках этих систем он основан? В чем особенностьданного подхода при разработке программного обеспечения?5. Что понимают под термином «жизненный цикл программного обеспечения»? Какие основныепроцессы включают в это понятие?6.

Назовите основные этапы разработки программного обеспечения. Какие основные задачирешаются на этих этапах?437. Назовите основные модели жизненного цикла программного обеспечения. С чем связанопоявление новых моделей?8. Какие технологии называют CASE-технологиями? Почему?9.

Назовите основные составляющие любой CASE-технологии.10. Перечислите основные положения технологии RAD? Какие программные системы нельзяразрабатывать с использованием этой технологии?11. Что понимают под моделями качества процессов разработки программного обеспечения? Длячего они разработаны? Что гарантирует сертификация качества процессов? Почему?12. Почему мы говорим, что современный этап развития технологии программированияхарактеризуется переходом от ремесленного к промышленному производству программногообеспечения?442.

ПРИЕМЫ ОБЕСПЕЧЕНИЯ ТЕХНОЛОГИЧНОСТИПРОГРАММНЫХ ПРОДУКТОВВ условиях индустриального подхода к разработке и сопровождению программногообеспечения особый вес приобретают технологические характеристики разрабатываемыхпрограмм. Для обеспечения необходимых технологических свойств применяют специальныетехнологические приемы и следуют определенным методикам, сформулированным всемпредыдущим опытом создания программного обеспечения. К таким приемам и методикамотносят правила декомпозиции, методы проектирования, программирования и контролякачества, которые под общим названием «структурный подход к программированию» былисформулированы еще в 60-х годах XX в.

В его основу были положены следующие основныеконцепции:• нисходящая разработка;• модульное программирование;• структурное программирование;• сквозной структурный контроль.2.1. Понятие технологичности программного обеспеченияПод технологичностью понимают качество проекта программного продукта, откоторого зависят трудовые и материальные затраты на его реализацию и последующиемодификации. Хороший проект сравнительно быстро и легко кодируется, тестируется,отлаживается и модифицируется.Из опыта нескольких поколений разработчиков программного обеспечения известно, чтотехнологичность программного обеспечения определяется проработанностью его моделей,уровнем независимости модулей, стилем программирования и степенью повторногоиспользования кодов.Чем лучше проработана модель разрабатываемого программного обеспечения, тем четчеопределены подзадачи и структуры данных, хранящие входную, промежуточную ивыходную информацию, тем проще их проектирование и реализация и меньше вероятностьошибок, для исправления которых потребуется существенно изменять программу.45Чем выше независимость модулей, тем их легче понять, реализовывать,модифицировать, а также находить в них ошибки и исправлять их.Стиль программирования, под которым понимают стиль оформления программ и их«структурность», также существенно влияет на читаемость программного кода и количествоошибок программирования.

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

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

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

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

Модулем называют автономно компилируемую программную единицу. Термин«модуль» традиционно используется в двух смыслах. Первоначально, когда размерпрограмм был сравнительно невелик, и все подпрограммы компилировались отдельно, подмодулем понималась подпрограмма, т.е. последовательность связанных фрагментовпрограммы, обращение к которой выполняется по имени. Со временем, когда размерпрограмм значительно вырос, и появилась возможность создавать библиотеки ресурсов:констант, переменных, описаний типов, классов и подпрограмм, термин «модуль» сталиспользоваться и в смысле автономно компилируемый набор программных ресурсов.Данные модуль может получать и/или возвращать через общие области памяти илипараметры.Первоначально к модулям (еще понимаемым как подпрограммы) предъявлялисьследующие требования:• отдельная компиляция;• одна точка входа;• одна точка выхода;• соответствие принципу вертикального управления;• возможность вызова других модулей;• небольшой размер (до 50-60 операторов языка);• независимость от истории вызовов;• выполнение одной функции.Требования одной точки входа, одной точки выхода, независимости от истории вызовови соответствия принципу вертикального управления были вызваны тем, что в то время из-засерьезных ограничений на объем оперативной памяти программисты были вынужденыразрабатывать программы с максимально возможной повторяемостью кодов.

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

е. вероятность появления «волнового» эффекта;• проще организовать разработку программного обеспечения группой программистов илегче его сопровождать.Таким образом, уменьшение зависимости модулей улучшает технологичность проекта.Степень независимости модулей (как подпрограмм, так и библиотек) оценивают двумякритериями: сцеплением и связностью.Сцепление модулей. Сцепление является мерой взаимозависимости модулей, котораяопределяет, насколько хорошо модули отделены друг от друга. Модули независимы, есликаждый из них не содержит о другом никакой информации. Чем больше информации одругих модулях хранит модуль, тем больше он с ними сцеплен.Различают пять типов сцепления модулей:• по данным;• по образцу;• по управлению;• по общей области данных;• по содержимому.Сцепление по данным предполагает, что модули обмениваются данными,представленными скалярными значениями.

При небольшом количестве передаваемыхпараметров этот тип обеспечивает наилучшие технологические характеристикипрограммного обеспечения.Например, функция Мах предполагает сцепление по данным через параметры скалярноготипа:Function Max(a, b: integer):integer;beginif a>b then Max:=aelse Max: =b;end;Сцепление по образцу предполагает, что модули обмениваются данными,объединенными в структуры.

Этот тип также обеспечивает неплохие характеристики, но онихуже, чем у предыдущего типа, так как конкретные передаваемые данные «спрятаны» вструктуры, и потому уменьшается «прозрачность» связи между модулями. Кроме того, приизменении структуры48передаваемых данных необходимо модифицировать все использующие ее модули.Так, функция MaxEl, описанная ниже, предполагает сцепление по образцу (параметр а –открытый массив).Function МахEl(а:array of integer):integer;Var i:word;beginMaxEl: =a[0];for i:=l to High(a) doif a[i]>MaxEl then MaxEl: =a[i];end;При сцеплении по управлению один модуль посылает другому некоторыйинформационный объект (флаг), предназначенный для управления внутренней логикоймодуля. Таким способом часто выполняют настройку режимов работы программногообеспечения.