ВЫСОКОУРОВНЕВЫЕ МЕТОДЫ ПРОГРАММИРОВАНИЯ

ВЫСОКОУРОВНЕВЫЕ МЕТОДЫ ПРОГРАММИРОВАНИЯ
ЛЕКЦИЯ 1. ВВЕДЕНИЕ В ВЫСОКОУРОВНЕВЫЕ МЕТОДЫ ПРОГРАММИРОВАНИЯ
План лекции
1. Предварительные замечания
2. Эволюция разработки программного обеспечения
1. Предварительные замечания
Осмысленное использование высокоуровневых языков программирования и методов построения программ невозможно
без глубокого понимания основ объектно-ориентированного анализа (ООА). Этот небольшой курс лекций дает
возможность ознакомиться с фундаментальными понятиями одних из самых распространенных методов высокоуровнего
программирования – структурным, основанным на структурной методологии, и объектно-ориентированным, основанным на
методологии ООА.
Два подхода объективно сложились в настоящее время в области развития и повышения эффективности
программирования – структурный и объектно-ориентированный. Каждый из этих подходов поддерживается
приблизительно равными по мощности языками. Выбор того или другого подходов сложен. Отсюда серия мифов,
представляющих собой типичные заблуждения в отношении
- противопоставления структурного и объектно-ориентированного анализа;
- первичности функциональной или информационной моделей;
- диаграмм потоков данных и структурных диаграмм SADT (Struktured Analysis and Design Technique).
Корни этих заблуждений лежат в недостаточно ясном понимании тонкостей технологии этих двух подходов, что
обусловлено неравенством в возможностях изучения этих тонкостей. Классический структурный анализ,
предусматривающий расчленение процесса на функциональные модели легко воспринимается участниками всех уровней
любого бизнес-процесса. Однако, такие понятия ООА, как наследование, инкапсуляция, полиморфизм и др. понимает
далеко не каждый. Однако достаточно очевидно, что объектно-ориентированная модель наиболее адекватно отражает
реальный мир, представляющий собой в целом совокупность взаимодействующих посредством обмена сообщениями
объектов.
В настоящее время число программных продуктов, поддерживающих ООподход быстро растет, и всем надо быть готовым
к восприятию технологий на основе ООА, а в конечном счете реинжиниринга бизнес-процессов. Для этого надо овладеть
языком ООА в той же мере, что и языком структурных методологий.
2. Эволюция разработки программного обеспечения
С момента появления первых электронно-вычислительных машин разработка программного обеспечения прошла большой
путь: от -факта возможности написать хоть какую-нибудь программу до осознания того, что именно технология разработки
программного обеспечения определяет прогресс в вычислительной технике.
Ранее развитие вычислительной техники было сосредоточено на решении технических проблем. Предметом забот была
прежде все-го аппаратура, вычислительная машина как таковая. Казалось вполне естественным, что программы для таких
машин должны были разрабатываться в двоичных кодах. Программирование было уделом энтузиастов.
По мере того как вычислительные машины становились мощнее и надежнее, значение программного обеспечения
осознавалось все большим количеством ученых и практиков. Важнейший прорыв произошел в конце 50-х годов, когда
появились языки программирования высокого уровня: Фортран, Алгол и др. Появление языков программирования высокого
уровня было обусловлено прежде всего тем, что написание программ без них становилось все более сложной задачей.
Решив текущие проблемы, эти языки создали новые. Ускорив и упростив программирование, языки программирования
существенно расширили круг задач, которые стали решаться с помощью ЭВМ. Новые задачи, более сложные, чем
решавшиеся раньше, привели к тому, что имеющихся средств снова стало недостаточно для успешного их решения.
Такое развитие характерно для всей истории применения компьютеров вплоть до настоящего времени. Вычислительная
техника все время используется на пределе своих возможностей. Каждое новое достижение в аппаратном либо в
программном обеспечении приводит к попыткам расширить сферу применения ЭВМ, тем самым ставит новые задачи, для
решения которых нужны новые возможности.
Прежде всего усилия были сосредоточены на создании новых языков программирования. Появился язык Кобол, который
должен был решать задачи обработки экономической информации. Он создавался таким образом, чтобы программа на
нем выглядела почти как текст на английском языке. Появился язык PL/1, призванный объединить все возможности,
которые только можно представить себе в языке программирования.
Языки, которые мы уже упоминали (Фортран, Алгол, PL/1) поддерживают процедурный стиль программирования.
Программа разрабатывается в терминах тех действий, которые, она выполняет. Основной единицей программы является
процедура. Процедуры вызывают другие процедуры, все вместе они работают по определенному алгоритму, который
ведет к решению задачи. Алгоритм - -это точная последовательность действий для получения необходимого результата.
Появление таких языков вытекало из круга задач, которые решались с помощью вычислительной техники. Это прежде
всего вычислительные задачи. Основными пользователями ЭВМ были физики и инженеры, которые интересовались
возможностью быстро вычислить необходимый результат.
Слово «алгоритм» (algoNthmi, algorismus) произошло от латинской транслитерации имени среднеазиатского математика
аль-Хорезми, который описал точную последовательность действий для вычисления наибольшего общего делителя .
Применение ЭВМ для решения задач искусственного интеллекта и обработки текстов привело к созданию
функциональных языков, в частности языка Лисп. Эти языки имеют также хорошо проработанное математическое
основание: лямбда-исчисление. В отличие от языков типа Алгола, в которых действия в основном выражаются в виде
итерации — повторения какого-либо фрагмента программы несколько раз, — в языке Лисп вычисления производятся с
помощью рекурсии — вызова функцией самой себя, а основная структура данных — это список.
В 60-е годы многими теоретиками и практиками было осознано, что только лишь создание новых, более совершенных
языков программирования не может решить все проблемы разработки программ. Начались интенсивные исследования в
области тестирования программ, организации процесса разработки программного обеспечения и др.
Первой, пожалуй, была осознана проблема ошибок. Сравнивая программирование с другими инженерными дисциплинами,
многие задавались вопросом: почему можно добиться безошибочной работы радиоприемника или даже процессора ЭВМ,
но чрезвычайно сложно добиться безошибочной работы программы- Нельзя ли так организовать тестирование и проверку
программ, чтобы добиться 100-процентной уверенности в ее правильностиОчевидно, что, лишь подавая некоторые данные на вход программы и наблюдая результат, это сделать невозможно хотя
бы в силу слишком большого количества вариантов исходных данных. Первое, что нужно сделать, — это попытаться
упорядочить процесс тестирования.
Работы по организации процесса тестирования начали появляться в конце 60-х годов. Примерно к середине 70-х годов
были заложены основы организации тестирования, которыми в основ-ном пользуются в настоящее время. В монографии
Майерса, переведенной на русский язык, исследуются как сами методы тестирования, такие, как модульное тестирование,
внешнее тестирование, нисходящее и восходящее тестирование, анализ передачи управления в программе при
тестировании, так и принципы проектирования и разработки надежных программных систем.
В 70 — 80-х годах бурно развивалась теория доказательства правильности программ. Она основывалась на том, что текст
программы задает все, что она делает. Утверждалось, что, имея формальное описание семантики всех конструкций языка,
можно на основе анализа текста строго математически вывести заключение о правильности или неправильности
программы.
Прежде всего, было необходимо создать строгое описание не только синтаксиса языка, но и смысла всех его конструкций.
Если с синтаксисом принципиально проблема была решена еще в конце 50-х годов созданием формальной теории
грамматики языка Хомского и способа записи грамматики Бэкуса — Каура, то с семантикой оказалось сложнее. Было
разработано несколько методов описания семантик: W-грамматики, аксиоматический подход, денотационный метод,
атрибутные грамматики, Венский метод описания и ряд других. С помощью этих методов было описано несколько
реальных языков программирования: PL/1, Алгол-68, Паскаль и др.
Методы доказательства развивались, и с их помощью можно было сделать выводы о корректности небольших учебных
примеров. Однако дальше встали две проблемы, которые фактически похоронили возможность широкого практического
применения доказательства программ: определение, что такое корректная программа, и сложность реальных программ.
Формально определить, каков правильный результат программы, можно только для небольшого круга математически
сформулированных проблем. Для большинства реальных программ строгое описание того, что программа должна делать,
существенно больше по объему самой программы и требует очень высокой математической квалификации программиста.
Для большого количества программ описание в принципе неформализуемо. Для примера посмотрите на объем
руководства, например, текстового редактора (которое довольно не строго).
Именно поэтому результаты теории доказательств нашли применение в очень ограниченных областях программирования
(например, в разработке компиляторов). Для массового программирования они оказались неприменимы. Попытка Э.
Дейкстры соединить структурное программирование с методами доказательства программ осталась изящным
упражнением, образцом для восхищения, но не для подражания.
Замечание. Работы по развитию формальных методов доказательства программ продолжаются. Одним из недавних
достижений в этой области стала разработка системы управления парижским метрополитеном, полностью доказанная с
помощью В-метода. Этот пример подтверждает как мощность математического доказательства программ, так и то, что
трудоемкость проекта оказывается до сих пор слишком высокой для широкого применения формальных методов — только
лемм было доказано около тридцати тысяч.
Усилия преобразовать программирование из эмпирического процесса в более упорядоченный, придать ему более
«инженерный» характер вылились в создание методик программирования. Это был очень существенный шаг. Разработка
методов построения программ, с одной стороны, создавала основу для массового промышленного программирования, а с
другой стороны, обобщая и анализируя текущее состояние программного обеспечения, давала мощный импульс созданию
новых языков программирования, операционных систем, сред программирования.
Одной из наиболее широко применяемых методик программирования стало структурное программирование (подробнее о
нем см. следующий параграф).
Следствием интенсивных исследований в области методов программирования явилось появление большого числа
средств автоматизации разработки программ (CASE-средств, Computer Aided Software Engineering). Предполагалось, что
после записи задачи на каком-либо высокоуровневом языке эти системы автоматически (или хотя бы с минимальным
участием человека) сгенерируют готовую, правильно работающую программу, которая адекватно решает поставленную
задачу.
В целом САЗЕ-средства не смогли достичь обещанного: либо описание задачи по сложности оказывалось сравнимым с
результирующей программой, либо решался крайне ограниченный круг сравнительно простых задач, либо качество
генерируемой программы оказывалось слишком низким.
Несмотря на провал при достижении основной цели, опыт разработки САЗЕ-средств дал очень много для развития
методов программирования. Небольшая часть систем используется напрямую (например, генераторы компиляторов lex и
уасс), часть идей была использована в современных средствах быстрой разработки программ (RAD, Rapid Application
Development), таких, как JBuilder, Delphi, Powerbuilder и др. Кроме того, методы анализа и проектирования программ очень
много унаследовали от методов, использовавшихся при разработке средств автоматизированного программирования.
По мере увеличения сложности решаемых задач и соответственно увеличения размеров программных систем все
большее значение приобретали вопросы организации процесса разработки программного обеспечения. Широко известна
(и не потеряла своего значения до сих пор) книга Брукса. Автор — один из руководителей разработки операционной
системы OS/360 для ЭВМ IBM/360 — показал значение организации работы программистских коллективов для успеха (или
провала) проекта. Ценность этой книги даже не в том, что приведены конкретные организационные структуры (например,
метод хирургических бригад не нашел широкого применения), а в том, что она развеяла миф о человеко-месяцев.
Механическое увеличение количества людей, работающих над программой, не ускорит процесса ее разработки.
В 70-е годы была сформулирована модель процесса разработки. Эта модель выделяла несколько фаз процесса: анализ,
дизайн, кодирование, тестирование, внедрение. Каждая последующая стадия «вытекает» из предыдущей, поэтому и
модель получила название каскадной.
Последующее развитие привело к модификации этой модели к виду спирали, при которой стадии разработки итеративно
повторялись, но каждый раз на новом уровне, с учетом предыдущей разработки. Осознание исключительной важности
организации разработки привело к построению всеохватывающих моделей и даже международных стандартов.
Приведенный исторический экскурс развития методологии программирования иллюстрирует то, что все время
программирование «боролось» за возможность решать все более сложные задачи, создавать все более сложные
программные системы и делать это как можно быстрее. Периодически то или иное достижение объявлялось панацеей
(будь то структурное программирование, САSЕ-средства или что-либо еще). С той же закономерностью оказывалось, что
широко разрекламированное средство не способно решить все проблемы.
ЛЕКЦИЯ 2.МОДУЛЬНОЕ ПРОГРАММИРОВАНИЕ
1. Понятие программного модуля.
2. Основные характеристики программного модуля.
3. Методы разработки структуры программы.
4. Спецификация программного модуля.
5. Контроль структуры программы.
1. Понятие программного модуля.
С момента своего возникновения программирование боролось за возможность решать все более сложные задачи,
создавать все более сложные программные системы и делать это как можно быстрее.
В процессе разработки программ модульное программирование явилось воплощением общих методов борьбы со
сложностью, обеспечения независимости компонент системы и использования иерархических структур.
Метод разработки программ по частям называют модульным программированием. Программный модуль - это любой
фрагмент описания процесса, оформляемый как самостоятельный программный продукт, пригодный для использования в
других описаниях процесса.
2. Основные характеристики программного модуля.
Критерии приемлемости выделенного модуля (по Хольту):
* хороший модуль снаружи проще, чем внутри;
* хороший модуль проще использовать, чем построить.
Критерии приемлемости выделенного модуля (по Майерсу
* размер модуля,
* прочность модуля,
* сцепление с другими модулями,
* рутинность модуля (независимость от предыстории обращений к нему).
Размер модуля измеряется числом содержащихся в нем операторов или строк. Обычно рекомендуются программные
модули размером от нескольких десятков до нескольких сотен операторов.
Прочность модуля - это мера его внутренних связей. Чем выше прочность модуля, тем больше связей он может спрятать
от внешней по отношению к нему части программы и, следовательно, тем больший вклад в упрощение программы он
может внести. Для оценки степени прочности модуля Майерс предлагает упорядоченный по степени прочности набор из
семи классов модулей. Для использования рекомендуются только два высших по прочности класса модулей.
Функционально прочный модуль - это модуль, реализующий одну какую-либо определенную функцию. При реализации
этой функции такой модуль может использовать и другие модули.
Информационно прочный модуль - это модуль, выполняющий (реализующий) несколько операций (функций) над одной и
той же структурой данных (информационным объектом), которая считается неизвестной вне этого модуля. Для каждой из
этих операций в таком модуле имеется свой вход со своей формой обращения к нему.
Сцепление модуля - это мера его зависимости по данным от других модулей. Характеризуется способом передачи данных.
Единственным видом сцепления модулей, который рекомендуется для использования современной технологией
программирования, является параметрическое сцепление (сцепление по данным по Майерсу) - данные передаются
модулю либо при обращении к нему как значения его параметров, либо как результат его обращения к другому модулю
для вычисления некоторой функции. Такой вид сцепления модулей реализуется на языках программирования при
использовании обращений к процедурам (функциям).
Рутинность модуля - это его независимость от предыстории обращений к нему. Модуль будем называть рутинным, если
результат (эффект) обращения к нему зависит только от значений его параметров (и не зависит от предыстории
обращений к нему). Модуль будем называть зависящим от предыстории, если результат (эффект) обращения к нему
зависит от внутреннего состояния этого модуля, изменяемого в результате предыдущих обращений к нему. Приемлема
следующая рекомендация:
* всегда следует использовать рутинный модуль, если это не приводит к плохим (не рекомендуемым) сцеплениям
модулей;
* зависящие от предыстории модули следует использовать только в случае, когда это необходимо для обеспечения
параметрического сцепления;
* в спецификации зависящего от предыстории модуля должна быть четко сформулирована эта зависимость таким
образом, чтобы было возможно прогнозировать поведение (эффект выполнения) данного модуля при разных
последующих обращениях к нему.
3. Методы разработки структуры программы.
В качестве модульной структуры программы принято использовать древовидную структуру, включая деревья со
сросшимися ветвями. В узлах такого дерева размещаются программные модули, а направленные дуги (стрелки)
показывают статическую подчиненность модулей, т.е. каждая дуга показывает, что в тексте модуля, из которого она
исходит, имеется ссылка на модуль, в который она входит. Спецификация программного модуля содержит
* синтаксическую спецификацию его входов, позволяющую построить на используемом языке программирования
синтаксически правильное обращение к нему (к любому его входу),
* функциональную спецификацию модуля (описание семантики функций, выполняемых этим модулем по каждому из его
входов).
Функциональная спецификация модуля строится так же, как и функциональная спецификация ПС.
В процессе разработки программы ее модульная структура может по-разному формироваться и использоваться для
определения порядка программирования и отладки модулей, указанных в этой структуре.
Метод восходящей разработки. Сначала строится модульная структура программы в виде дерева. Затем поочередно
программируются модули программы, начиная с модулей самого нижнего уровня (листья дерева модульной структуры
программы), в таком порядке, чтобы для каждого программируемого модуля были уже запрограммированы все модули, к
которым он может обращаться. После того, как все модули программы запрограммированы, производится их поочередное
тестирование и отладка в принципе в таком же (восходящем) порядке, в каком велось их программирование. Но,
современная технология не рекомендует такой порядок разработки программы.
Метод нисходящей разработки. Как и в предыдущем методе сначала строится модульная структура программы в виде
дерева. Затем поочередно программируются модули программы, начиная с модуля самого верхнего уровня (головного),
переходя к программированию какого-либо другого модуля только в том случае, если уже запрограммирован модуль,
который к нему обращается. После того, как все модули программы запрограммированы, производится их поочередное
тестирование и отладка в таком же (нисходящем) порядке. При этом первым тестируется головной модуль программы,
который представляет всю тестируемую программу и поэтому тестируется при «естественном» состоянии
информационной среды, при котором начинает выполняться эта программа. При этом те модули, к которым может
обращаться головной, заменяются их имитаторами (так называемыми заглушками).
Особенностью рассмотренных методов восходящей и нисходящей разработок (которые мы будем называть
классическими) является требование, чтобы модульная структура программы была разработана до начала
программирования (кодирования) модулей. Однако эти методы вызывают ряд возражений: представляется сомнительным,
чтобы до программирования модулей можно было разработать структуру программы достаточно точно и содержательно.
На самом деле это делать не обязательно, если несколько модернизировать водопадный подход.
Рис. 2.1. Шаг 1 формирования модульной структуры программы при конструктивном
подходе.
Конструктивный подход к
разработке программы
представляет собой модификацию
нисходящей разработки, при
которой модульная древовидная
структура программы формируется
в процессе программирования
модулей. Разработка программы
при конструктивном подходе
начинается с программирования
головного модуля, исходя из
спецификации программы в целом.
При этом спецификация
программы принимается в
качестве спецификации ее
головного модуля, который
полностью берет на себя
ответственность за выполнение
функций программы.
В процессе программирования головного модуля, в случае, если эта программа достаточно большая, выделяются
подзадачи (внутренние функции), в терминах которых программируется головной модуль. Таким образом, на первом шаге
разработки программы (при программировании ее головного модуля) формируется верхняя начальная часть дерева,
например, такая, которая показана на рис. 2.1.
Аналогичные действия производятся при
программировании любого другого модуля, который
выбирается из текущего состояния дерева программы из
числа специфицированных, но пока еще не
запрограммированных модулей. В результате этого
производится очередное доформирование дерева
программы, например, такое, которое показано на рис. 2.2.
Архитектурный подход к разработке программы
представляет собой модификацию восходящей разработки,
при которой модульная структура программы формируется
в процессе программирования модуля. Но при этом
ставится существенно другая цель разработки: повышение
уровня используемого языка программирования, а не
разработка конкретной программы.
Рис. 2.2. Второй шаг формирования модульной структуры
программы при конструктивном подходе.
В классическом методе нисходящей разработки
рекомендуется сначала все модули разрабатываемой
программы запрограммировать, а уж затем начинать
нисходящее их тестирование, что опять-таки находится в
полном соответствии с водопадным подходом. Более
рациональным представляется другой порядок разработки
программы, известный в литературе как метод нисходящей
реализации, что представляет некоторую модификацию
водопадного подхода. В этом методе каждый
запрограммированный модуль начинают сразу же
тестировать до перехода к программированию другого
модуля.
Все эти методы имеют еще различные разновидности в
зависимости от того, в какой последовательности обходятся
узлы (модули) древовидной структуры программы в
процессе ее разработки. Обход дерева программы
производится с целью кратчайшим путем реализовать тот
или иной вариант (сначала самый простейший) нормально
действующей программы. В связи с этим такая
разновидность конструктивной реализации получила
название метода целенаправленной конструктивной
реализации. Достоинством этого метода является то, что
уже на достаточно ранней стадии создается работающий
вариант разрабатываемой программы. На рис.2.3
представлена общая классификация рассмотренных
методов разработки структуры программы.
Рис. 2.3. Классификация методов разработки структуры
программ.
4. Контроль структуры программы.
Для контроля структуры программы можно использовать три метода:
* статический контроль,
* смежный контроль,
* сквозной контроль.
Статический контроль состоит в оценке структуры программы, насколько хорошо программа разбита на модули с учетом
значений рассмотренных выше основных характеристик модуля.
Смежный контроль сверху - это контроль со стороны разработчиков архитектуры и внешнего описания ПС. Смежный
контроль снизу - это контроль спецификации модулей со стороны разработчиков этих модулей.
Сквозной контроль - это мысленное прокручивание (проверка) структуры программы при выполнении заранее
разработанных тестов. Является видом динамического контроля так же, как и ручная имитация функциональной
спецификации или архитектуры ПС.
Следует заметить, что указанный контроль структуры программы производится в рамках водопадного подхода разработки
ПС, т.е. при классическом подходе. При конструктивном и архитектурном подходах контроль структуры программы
осуществляется в процессе программирования (кодирования) модулей в подходящие моменты времени.
Лекция 3.Элементы структурного программирования
План лекции
1. ПОРЯДОК РАЗРАБОТКИ ПРОГРАММНОГО МОДУЛЯ.
2. СТРУКТУРНОЕ ПРОГРАММИРОВАНИЕ.
3. ПОШАГОВАЯ ДЕТАЛИЗАЦИЯ И ПОНЯТИЕ О ПСЕВДОКОДЕ.
4. КОНТРОЛЬ ПРОГРАММНОГО МОДУЛЯ
1. ПОРЯДОК РАЗРАБОТКИ ПРОГРАММНОГО МОДУЛЯ.
1. Изучение и проверка спецификации модуля, выбор языка программирования.
2. Выбор алгоритма и структуры данных.
3. Программирование (кодирование) модуля.
4. Шлифовка текста модуля.
5. Проверка модуля.
6. Компиляция модуля.
Первый шаг разработки программного модуля в значительной степени представляет собой смежный контроль структуры
программы снизу. В завершении этого шага выбирается язык программирования.
На втором шаге разработки программного модуля необходимо выяснить, не известны ли уже какие-либо алгоритмы для
решения поставленной и или близкой к ней задачи. И если найдется подходящий алгоритм, то целесообразно им
воспользоваться..
На третьем шаге осуществляется построение текста модуля на выбранном языке программирования. Весьма важно для
построения текста модуля пользоваться технологически обоснованной и практически проверенной дисциплиной
программирования.
Следующий шаг разработки модуля связан с приведением текста модуля к завершенному виду в соответствии со
спецификацией качества ПС. При шлифовке текста модуля разработчик должен отредактировать имеющиеся в тексте
комментарии и, возможно, включить в него дополнительные комментарии с целью обеспечить требуемые примитивы
качества. С этой же целью производится редактирование текста программы для выполнения стилистических требований.
Шаг проверки модуля представляет собой ручную проверку внутренней логики модуля до начала его отладки
(использующей выполнение его на компьютере), реализует общий принцип, сформулированный для обсуждаемой
технологии программирования, о необходимости контроля принимаемых решений на каждом этапе разработки ПС.
И, наконец, последний шаг разработки модуля означает завершение проверки модуля (с помощью компилятора) и переход
к процессу отладки модуля.
2. СТРУКТУРНОЕ ПРОГРАММИРОВАНИЕ.
Создателем структурного подхода к программированию считается Э. Дейкстра. Фактически это первый законченный метод
программирования, предлагающий путь от задачи до ее воплощения в программе. Этот метод применялся очень широко в
практическом программировании и по сей день не потерял своего значения для определенного класса задач.
Структурный подход базируется на двух основополагающих принципах: первый - это использование процедурного стиля
программирования, второй – это последовательная декомпозиция алгоритма задачи сверху вниз.
Для облегчения понимания программы Дейкстра предложил строить ее как композицию из нескольких типов управляющих
конструкций (структур), которые позволяют сильно повысить понимаемость логики работы программы.
Основными конструкциями структурного
программирования являются: следование,
разветвление и повторение (см. Рис. 3.1).
Компонентами этих конструкций являются
обобщенные операторы (узлы обработки) S, S1, S2 и
условие (предикат) P. В качестве обобщенного
оператора может быть либо простой оператор
используемого языка программирования (операторы
присваивания, ввода, вывода, обращения к
процедуре), либо фрагмент программы, являющийся
композицией основных управляющих конструкций
структурного программирования. Существенно, что
каждая из этих конструкций имеет по управлению
только один вход и один выход. Тем самым, и
обобщенный оператор имеет только один вход и
один выход.
Рис. 3.1. Основные управляющие конструкции структурного
программирования.
3. ПОШАГОВАЯ ДЕТАЛИЗАЦИЯ И ПОНЯТИЕ О ПСЕВДОКОДЕ.
В качестве основного метода построения текста модуля современная технология программирования рекомендует
пошаговую детализацию. На первом шаге описывается общая схема работы модуля в обозримой линейной текстовой
форме. На каждом следующем шаге производится уточнение и детализация одного из понятий (будем называть его
уточняемым), в каком либо описании, разработанном на одном из предыдущих шагов. В результате такого шага создается
описание выбранного уточняемого понятия либо в терминах базового языка программирования, либо в такой же форме,
что и на первом шаге. Этот процесс завершается, когда все уточняемые понятия будут уточнения (т.е. в конечном счете
будут выражены на базовом языке программирования). Последним шагом является получение текста модуля на базовом
языке программирования.
Пошаговая детализация связана с использованием частично формализованного языка для представления указанных
описаний, который получил название псевдокода.
Головным описанием на псевдокоде можно считать внешнее оформление модуля на базовом языке программирования:
* начало модуля на базовом языке, т.е. первое предложение или заголовок (спецификацию) этого модуля;
* раздел (совокупность) описаний на базовом языке, причем вместо описаний процедур и функций - только их внешнее
оформление;
* неформальное обозначение последовательности операторов тела модуля как одного обобщенного оператора (см. ниже),
а также неформальное обозначение тела каждого описания процедуры или функции как одного обобщенного оператора;
* последнее предложение (конец) модуля на базовом языке.
Внешнее оформление описания процедуры или функции представляется аналогично. Впрочем, если следовать Дейкстре,
раздел описаний лучше также представить здесь неформальным обозначением, произведя его детализацию в виде
отдельного описания.
Неформальное обозначение обобщенного оператора на псевдокоде производится на естественном языке произвольным
предложением, раскрывающим в общих чертах его содержание.
Следование:
обобщенный_оператор
обобщенный_оператор
Разветвление:
ЕСЛИ условие ТО
обобщенный_оператор
ИНАЧЕ
обобщенный_оператор
ВСЕ ЕСЛИ
Повторение:
ПОКА условие ДЕЛАТЬ
обобщенный_оператор
ВСЕ ПОКА
Рис. 3.2. Основные конструкции структурного программирования на псевдокоде.
Для каждого неформального обобщенного оператора должно быть создано отдельное описание, выражающее логику его
работы (детализирующее его содержание) с помощью композиции основных конструкций структурного программирования
и других обобщенных операторов. В качестве заголовка такого описания должно быть неформальное обозначение
детализируемого обобщенного оператора. Основные конструкции структурного программирования могут быть
представлены в следующем виде (см. рис. 3.2). Здесь условие может быть либо явно задано на базовом языке
программирования в качестве булевского выражения, либо неформально представлено на естественном языке некоторым
фрагментом, раскрывающим в общих чертах смысл этого условия. В последнем случае должно быть создано отдельное
описание, детализирующее это условие, с указанием в качестве заголовка обозначения этого условия (фрагмента на
естественном языке).
В качестве обобщенного оператора на псевдокоде можно использовать частные случаи оператора перехода.
Последовательность обработчиков исключительных ситуаций (исключений) задается в конце модуля или описания
процедуры (функции).
Каждый такой обработчик имеет вид:
ИСКЛЮЧЕНИЕ имя_исключения
обобщенный_оператор
ВСЕ ИСКЛЮЧЕНИЕ
Отличие обработчика исключительной ситуации от процедуры без параметров заключается в следующем: после
выполнения процедуры управление возвращается к оператору, следующему за обращением к ней, а после выполнения
исключения управление возвращается к оператору, следующему за обращением к модулю или процедуре (функции), в
конце которого (которой) помещено данное исключение.
Идею пошаговой детализации приписывают иногда Дейкстре, но он предлагал иной метод построения текста модуля:
более глубокий и перспективный. Во-первых, вместе с уточнением операторов он предлагал постепенно (по шагам)
уточнять (детализировать) и используемые структуры данных. Во-вторых, на каждом шаге он предлагал создавать
некоторую виртуальную машину для детализации и в ее терминах производить детализацию всех уточняемых понятий,
для которых эта машина позволяет это сделать.
4. КОНТРОЛЬ ПРОГРАММНОГО МОДУЛЯ.
Применяются следующие методы контроля программного модуля:
* статическая проверка текста модуля;
* сквозное прослеживание;
* доказательство свойств программного модуля.
При статической проверке текста модуля этот текст просматривается с начала до конца с целью найти ошибки в модуле.
Сквозное прослеживание представляет собой один из видов динамического контроля модуля. В нем участвуют несколько
программистов, которые вручную прокручивают выполнение модуля на некотором наборе тестов.
Доказательство свойств программ требует от программиста высокой математической подготовки, а его трудоемкость и
сложность порой оказываются выше трудоемкости и сложности разработки самой программы. Поэтому этот метод
применяется пока очень редко.
Лекция 4.ОБЪЕКТНО-ОРИЕНТИРОВАННЫЙ ПОДХОД В РАЗРАБОТКЕ ПРОГРАММ
План лекции
1. ПРОБЛЕМЫ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
2. ОСНОВНЫЕ ПОНЯТИЯ ООП
3. ОБЪЕКТЫ
1. ПРОБЛЕМЫ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
Объектно-ориентированное программирование родилось и получило широкое распространение ввиду осознания трех
важнейших проблем программирования.
1. Развитие языков и методов программирования не успевало за растущими с большей скоростью потребностями в
программах. Единственным методом ускорения разработки ПО оставался метод многократного использования
разработанных ранее модулей. Хотя процедурное программирование предоставляло способ разработки функций, которые
могли служить блоками для построения программ, тем не менее ни гибкость этого метода, ни масштабы его использования
не позволяли существенно ускорить массовое программирование.
2. Второй проблемой являлась необходимость упрощения сопровождения и модификации разработанных систем, которые
требуют не меньших усилий, чем собственно разработка. Требовалось радикально изменить способ построения
программных систем, чтобы локальные модификации не могли нарушать работоспособность всей системы и было бы
легче производить изменения поведения системы.
3. Далеко не все задачи поддаются алгоритмическому описанию и алгоритмической декомпозиции, как того требует
структурное программирование. Требовалось приблизить структуру программ к структуре решаемых задач и сократить
семантический разрыв между структурой решаемой задачи и структурой программы (т.е. понятия, лежащие в основе языка
задачи и средств ее решения различны). Поэтому при решении требуется перевести одни понятия в другие.
Решение этих проблем в объектно-ориентированной технологии выставлялось ее сторонниками как три основных
достоинства технологии.
2. ОСНОВНЫЕ ПОНЯТИЯ ООП
Объектно-ориентированное программирование (сокращенно ООП) является методом программирования, имитирующим
то, как человек выполняет какую-либо работу. Объектно-ориентированное программирование - результат естественной
эволюции более ранних методологий программирования: оно более структурировано и более модульное и абстрактное,
чем традиционное программирование. Эта технология является по существу прагматическим воплощением к 1980 году
идеи абстрактных типов данных как идеальной основы в программной индустрии в наше время.
Считается, что первой полной реализацией абстрактных типов данных в языках программирования является язык Симула,
который опирался на языки Модула, CLU, Euclid и др.
Появление объектно-ориентированного метода произошло на основе всего предыдущего развития методов разработки
ПО, а также других отраслей науки (развитие вычислительной техники, построение функционально и объектноориентированных операционных систем, достижения в методологии программирования, развитие теории построения и
моделирования систем управления базами данных (построение отношений между объектами), исследования в области
систем с искусственным интеллектом (теория фреймов) позволили лучше осознать механизмы абстракции, развитие
философии и теории познания, концепция образцов и шаблонов теории архитектуры и строительства).
Семь основных признаков характеризуют объектно-ориентированную технологию программирования:
1. ОБЪЕКТЫ. Базовым понятием в объектном подходе является понятие КЛАССА объектов - такого множества предметов
реального мира, что все предметы в нем имеют одни и те же характеристики (данные) и правила поведения (методы
обработки данных). Тогда ОБЪЕКТ - это типичный представитель (экземпляр, абстрактный представитель) своего класса.
2. ИНКАПСУЛЯЦИЯ. Данные скомбинированы и объединены с процедурами и функциями, которые манипулируют этими
данными, в единую целостную структуру для получения нового типа данных - объекта.
3. НАСЛЕДОВАНИЕ. Это определение объекта и затем использование его для построения иерархии производных
объектов, причем каждый производный объект ("потомок") наследует доступ к коду и данным всех своих "прародителей".
Создать новые классы можно наследуя уже существующие (иерархическое наследование)
4. ОГРАНИЧЕНИЕ ДОСТУПА. При наследовании свойств базовых классов часть методов и характеристик можно спрятать
внутри реализации класса, так что обратиться к этим характеристикам и методам можно будет только из методов данного
или производных от него классов.
5. ПОЛИМОРФИЗМ. Некоторому действию придается одно имя, которое совместно используется объектами всей
иерархии, причем каждый объект иерархии реализует это действие своим собственным, подходящим для него, образом.
6. АБСТРАГИРОВАНИЕ - создание абстрактных классов, имеющих не реализованные методы, которые используют в
качестве базовых классов для образования других, имеющих тот же набор методов, но уже переопределенных.
7. УСТОЙЧИВОСТЬ. Под устойчивостью понимают продолжительное время существования объектов в системе. Это
свойство реализуется в основном в языках объектно-ориентированных баз данных.
Объектно-ориентированное программирование имеет свой собственный "арсенал" концепций, Это частично обусловлено
появлением ООП в (несколько замкнутой) сфере исследовательских разработок, но в основном просто нетрадиционным и
новаторским характером объектно-ориентированного программирования.
В объектно-ориентированном программировании предпринимается попытка смоделировать компоненты проблемы в
едином целом, а не в качестве отдельных логических абстракций. Все элементы, которые наполняют нашу жизнь, от
тостеров и цветов, до махровых полотенец, имеют свойства (данные или атрибуты) и типы поведения (правила). Свойства
тостера могут включать требуемое для его работы напряжение, количество ломтиков, которое он зажаривает,
расположение кнопок на нем, цвет тостера, его марку и т.п. Типы его поведения включают закладку ломтиков хлеба,
поджаривание ломтиков хлеба и выталкивание поджаренных кусочков.
Если мы хотим написать программу, имитирующую функционирование кухни, то самым лучшим способом это сделать
было бы моделирование различных кухонных приспособлений в качестве объектов, чьи свойства и типы поведения были
бы закодированы в поля данных и правила. Так в действительности и было сделано: самый первый объектноориентированный язык (Simula-67) был создан для написания подобных прогрaмм-имитaторов.
Первым «настоящим» объектно-ориентированным языком программирования принято считать Смолтолк, разработанный в
лаборатории компании Ксерокс. Затем появились и другие ОО языки (Си++, Паскаль, CLOS, Эйффель, Java и др.).
В качестве критерия применимости ООП можно использовать количество выделенных абстрактных типов с общими
свойствами таких, что эта общность может быть использована в механизме наследования свойств. Однако поиск общих
свойств среди типов далеко не тривиальный процесс. Он требует от разработчика системного склада мышления. Во время
проектирования системы общность должна быть все время перед глазами, как при спецификации классов, так и при
анализе того, обладают ли классы общими свойствами. Если общих свойств не находится, абстракция данных теряет
смысл. Снижается эффективность и применения ООП.
3. ОБЪЕКТЫ
Предположим, нам надо описать яблоко в терминах программирования. Первое, что вам, вероятно, захочется сделать, разломить яблоко: пусть S обозначает площадь кожицы; J - жидкий объем сока, который содержит яблоко; F - вес фрукта, а
D - количество семян...
Это неверный путь мышления. Надо думать как художник. Он видит яблоко и рисует его. Рисунок яблока - это не яблоко, а
символ, графическая модель яблока на плоской поверхности. Но он не абстрагирован до нескольких чисел, каждое из
которых стоит отдельно и независимо в кaком-либо сегменте данных. Его компоненты связаны в единое целое,
воспринимаемое нашим мозгом как яблоко.
Объекты моделируют свойства и поведение компонентов мира, в котором мы живем. Они являются и конечной
абстракцией данных. Объекты связывают в единое целое свои свойства и поведение и обладают спецификой целого.
Яблоко может быть разломлено, но после этого оно перестает быть яблоком. Отношения частей к целому и к другим
частям более ясны, когда все связано вместе в одной оболочке. Это называется инкапсуляцией и представляет собой
очень важное явление. Объекты - части мира, они же и конечные абстракции в ООП. Объектно-ориентированный подход
предлагает описывать реальность в виде взаимодействия объектов (например, «клиент Иванов», «банкомат Агробанка»,
«счет № 1111», « корабль Геркулес», «автомобиль Петрова»).
Хотя из приведенных примеров интуитивно ясно, что такое объект, дать его четкое и приемлемое для всех определение
достаточно сложно. Например, Гради Буч дает такое определение: «объект – это что-то, с чем можно оперировать. У
объекта есть состояние, поведение и возможность отличить его от других объектов». Якобсон пишет: « Объект – это
сущность, способная сохранять свое состояние (информацию) и обеспечивающая набор операций для проверки и
изменения этого состояния».
Можно сказать, что объект – это модель или абстракция реальной сущности в программной системе. Предмет
моделирования при построении объекта может быть различным. Можно выделить несколько типов абстракций,
используемых при построении объекта:
- абстракция понятия: объект – это модель какого-то понятия предметной области;
- абстракция действия: объект – это набор операций для выполнения какой-либо функции;
- абстракция виртуальной машины: объект объединяет операции, которые используются другими, более высокими
уровнями абстракции;
- случайная абстракция: объект объединяет не связанные между собой операции.
Таким образом, объект может быть получен из чего угодно. Однако можно выделить следующие часто встречающиеся
категории объектов:
1. РЕАЛЬНЫЕ ОБЪЕКТЫ - абстракции фактического существования некоторых предметов в физическом мире (Труба,
Насос, Бак, Самолет).
2. РОЛИ - абстракции цели или назначения человека, части оборудования или организации (Студент, Изоляционный
клапан, Налогоплательщик, Избиратель)
3. ИНЦИДЕНТЫ - абстракция чего-то происшедшего или случившегося (Несчастный случай, Землетрясение, Выборы,
Поставка).
4. ВЗАИМОДЕЙСТВИЯ - объекты, получаемые из отношений между другими объектами (Соединение, Контракт,
Перекресток).
5. СПЕЦИФИКАЦИИ - используются для представления правил, стандартов или критериев качества (например, Рецепт правило для приготовления определенного количества определенной пищи, в отличие от порции этой самой пищи).
Не менее значимым является и тот факт, что объекты могут наследовать свойства и поведение от того, что называют
"объектами - прародителями".
Объекты идентифицируются уникальным и значимым именем, необходимым для корреляции его с другими объектами.
Многие объектные модели предлагают встроенные методы идентификации объектов. При создании любого нового объекта
ему присваивается уникальный идентификатор, отличающийся от всех остальных имеющихся в системе идентификаторов.
Особое значение правильность идентификации объектов приобретает в распределенных системах, в которых программы
на разных компьютерах независимо друг от друга в произвольное время создают и уничтожают объекты.
Каждый объект характеризуется своим состоянием. Состояние объекта определяется текущими значениями его атрибутов.
Атрибутами могут быть не только простые величины (числа, логические значения и т.п.), но и сложные величины, объекты.
Часть атрибутов объекта может изменяться, часть – хранить неизменяемые значения.
Важнейшей характеристикой объекта является описание того, как он может взаимодействовать с окружающим миром. Это
описание называется интерфейсом объекта. Принято считать, что объекты взаимодействуют между собой с помощью
сообщений. Принимая сообщение. Объект выполняет соответствующее действие. Эти действия называются методами.
Интерфейс – это внешнее описание объекта. При разработке объекта мы решаем вопрос, является ли данный атрибут
информацией, необходимой другим объектам- Если да, то необходимо объекту добавить метод, который сообщает
значение данного атрибута другим объектам. Этот метод и будет составлять интерфейс объекта. Аналогично решается
вопрос и с другими атрибутами. Однако сами атрибуты могут не являться непосредственно частью интерфейса. Тогда
другие объекты могут обратиться к ним только опосредованно, с помощью соответствующих методов.
Возможно, что для некоторых объектов разрешены любые операции с некоторыми атрибутами, например, координатами
графической фигуры. Мы можем поместить эти атрибуты в интерфейс объекта. Тогда любые другие объекты могут
непосредственно изменять координаты, перемещая объект по экрану. Фактически в таком случае интерфейс объекта
состоит из методов «сообщить значение х», «установить значение х», «сообщить значение у», «установить значение у».
Помимо интерфейса у объекта могут быть методы или атрибуты, предназначенные только для использования в самом
объекте. В этом случае внутренняя структура объекта скрыта (свойство инкапсуляции данных). Поэтому внутреннюю
структуру объекта становится возможным изменять независимо от других взаимодействующих с ним объектов.
Объектно-ориентированная программа состоит из набора объектов, у каждого из которых есть свои атрибуты и методы.
Объекты взаимодействуют посредством сообщений. Проблема состоит в том, чтобы понять, какие объекты нужны
программе и какими свойствами и методами они должны обладать.
Лекция 5. КЛАССЫ В ОБЪЕКТНО-ОРИЕНТИРОВАННОМ ПРОГРАММИРОВАНИИ
План лекции
1. ПОНЯТИЕ КЛАССА
2. ВИДЫ КЛАССОВ
3. ВИДЫ МЕТОДОВ
4. ПЕРЕГРУЗКА МЕТОДОВ
5. ИМЕНОВАНИЕ КЛАССОВ, АТРИБУТОВ И МЕТОДОВ
1. ПОНЯТИЕ КЛАССА
Класс можно рассматривать как шаблон, по которому составляются инструкции одни и те же для всех объектов. Самое
полезное свойство этого шаблона - единообразный способ организации всех характеристик объекта.
В объектно-ориентированной терминологии шаблон, на котором основаны похожие объекты называется классом. Когда
программа создает объект какого-либо класса, она указывает значения его атрибутов. Затем объект может пользоваться
методами, написанными для его класса. Все объекты одного и того же класса имеют идентичный набор методов. Типы их
внутренних данных также одинаковы, но значения могут различаться, как различаются, скажем, имена людей.
Класс является также и типом данных. Фактически класс - это реализация абстрактного типа данных, то есть другое
название типа данных, определяемого пользователем. Поскольку класс - это тип данных, его можно использовать в
качестве типа атрибута.
Предположим, к примеру, что вы разрабатываете класс для обработки данных о служащих своей организации. В состав
атрибутов такого класса может входить идентификатор служащего, его имя, фамилия и адрес. Адрес же состоит из
почтового индекса и названия улицы, города, штата. Поэтому было бы разумно создать класс с такими атрибутами и
вместо того, чтобы дублировать их в классе служащего, просто указать, что объект класса служащего включает в себя
объект другого класса, с помощью которого представляется адрес служащего.
2. ВИДЫ КЛАССОВ
В объектно-ориентированной программе встречаются классы трех основных видов:
- управляющие классы (Control classes). Они не занимаются обработкой данных и не продуцируют видимого результата.
Вместо этого они управляют ходом выполнения программы. Например, классы приложения представляют саму программу.
В большинстве случаев каждая программа создает ровно один класс приложения. В его задачи входит запуск программы,
обнаружение факта выбора из меню и выполнение кода программы в соответствии с запросами пользователя;
- предметные классы (Entity classes). Они используются для создания объектов, занимающихся обработкой данных.
Например, класс Счет относится к предметным. Классы, представляющие людей, материальные объекты и события
(например, деловые совещания) являются предметными. В большинстве объектно-ориентированных программ есть хотя
бы один предметный класс, по которому создаются объекты. На самом деле в простейшем случае объектноориентированная модель данных строится из представления связей между объектами, созданными на основе предметных
классов.
- интерфейсные классы (Interface classes) Они занимаются вводом и выводом информации. Например, при работе с
графическим пользовательским интерфейсом, то каждое окно или меню, встречающееся в программе, является объектом
интерфейсного класса.
В объектно-ориентированной программе предметные классы не выполняют собственно ввод и вывод. Ввод с клавиатуры
обеспечивают интерфейсные объекты. Они принимают данные и посылают их предметным объектам для хранения и
обработки. Вывод на экран или печать форматируются интерфейсными объектами, получающими данные от других.
Почему необходимо отделять манипулирование данными от ввода/вывода- Не проще было бы поручить предметному
объекту самому управлять вводом/выводом- Может быть, и проще, но тогда, если вы решите изменить размещение
информации на экране, придется модифицировать весь предметный класс. А при разделении обязанностей процедуры
манипулирования данными не зависят от способа их ввода и вывода, так что перестроить их можно независимо друг от
друга. В большой программе это поможет не только сэкономить массу времени, но и избежать ошибок.
Во многих объектно-ориентированных программах используется еще четвертый вид классов - контейнерный (Container
classes). Контейнерные классы служат вместилищем нескольких объектов одного и того же класса. Поскольку они
собирают объекты вместе, иногда их называют также агрегатами. Контейнерный класс отвечал бы за хранение объектов в
определенном порядке, их перебор и, возможно, поиск. Они предоставляют доступ ко всем объектам одного и того же
класса.
3. ВИДЫ МЕТОДОВ
В классах используются следующие виды методов:
- конструктор (Constructor) - метод, имя которого совпадает с именем класса. Он выполняется при создании объекта.
Поэтому конструктор обычно содержит инструкции по инициализации переменных объекта;
- деструктор (Destructor) - метод, выполняемый при уничтожении объекта. Не во всех объектно-ориентированных языках
есть деструкторы. Обычно они применяются для освобождения системных ресурсов - например, оперативной памяти, занимаемых объектом;
- методы чтения (Accessors) - еще их называют get-методами - возвращают значение закрытого атрибута объекта. Именно
так внешние объекты обычно получают доступ к инкапсулированным данным.
- методы изменения (Mutators), set-методы, устанавливают новое значение атрибута. Таким образом, внешние объекты
изменяют инкапсулированные данные.
Прочие методы, определенные в классе, зависят от назначения класса, то есть от действий, которые он призван
выполнять.
4. ПЕРЕГРУЗКА МЕТОДОВ
Одной из характерных особенностей класса является возможность определять в нем перегруженные методы, то есть
методы с одним и тем же именем, но разными входными данными. Поскольку типы данных различны, то различен и
открытый интерфейс таких методов.
Предположим, что в программе кадрового учета есть контейнерный класс с именем AllEmployees, агрегирующий все
объекты класса Employee (Служащий). Программы, пользующиеся классом AllEmployees, создают один объект этого
класса, а затем ассоциируют с ним все объекты, представляющие служащих, применяя ту или иную структуру данных
(например, массив, связанный список или двоичное дерево).
Чтобы наличие контейнерного класса имело смысл, должен существовать какой-то способ искать в нем конкретные
объекты. Возможно, вам понадобится поиск по идентификатору служащего, по имени и фамилии либо по номеру
телефона. Поэтому класс AllEmployees содержит три метода с именем find. Одному из них передается целое число (код
служащего), второму - две строки (имя и фамилия), а третьему - одна строка (номер телефона). Хотя все методы названы
одинаково, но их открытые интерфейсы различны, поскольку разграничены комбинации имени и типов входных данных.
У многих классов есть перегруженные конструкторы. Один может запрашивать у пользователя ввод интерактивно, другой читать из файла, третий - получать входные данные, копируя их из другого объекта (копирующий конструктор). Например,
в большинстве объектно-ориентированных сред имеется класс Date, поддерживающий инициализацию объекта даты
строкой, другим объектом Date и т.д.
Преимущество перегрузки методов в том, что программисту предоставляется единообразный интерфейс. Если
необходимо найти служащего, то программист знает, что надо применить метод find. А тогда остается лишь
воспользоваться тем из трех методов, который больше всего подходит в данной ситуации. Объектно-ориентированная
программа отыщет нужный метод по его открытому интерфейсу (сигнатуре), составленному из имени и типов входных
данных.
5. ИМЕНОВАНИЕ КЛАССОВ, АТРИБУТОВ И МЕТОДОВ
В объектно-ориентированном программировании имеется несколько соглашений об именовании. Хотя никто не заставляет
вас называть свои классы, атрибуты и методы именно так, а не иначе, следование общепринятым правилам обеспечит
взаимопонимание с другими программистами и проектировщиками баз данных:
- имена классов начинаются с заглавной буквы, за которой следуют строчные. Если имя класса состоит из нескольких слов,
то они разделяются либо символом подчеркивания, например Merchandise_item, либо внутренними заглавными буквами,
например Merchandiseltem;
- имена атрибутов и методов начинаются со строчной буквы и могут содержать заглавные или строчные буквы, а также
цифры. Если имя атрибута или метода состоит из нескольких слов, то они разделяются либо символом подчеркивания,
например product_numb или display_label, либо -внутренними заглавными буквами, например productNumb или displayLabel;
- имена методов чтения начинаются со слова get, а за ним следует имя атрибута, значение которого считывается.
Например, метод для получения номера изделия будет называться getProductNumber;
- имена методов изменения начинаются со слова set, а после него пишется имя атрибута, значение которого изменяется,
например setProductNumber.
Лекция 6. ОСНОВНЫЕ СРЕДСТВА РАЗРАБОТКИ КЛАССОВ
План лекции
1. Наследование
2. Полиморфизм
3. Композиция
4. Наполнение
1. Наследование
По мере разработки объектно-ориентированной программы вы часто будете сталкиваться с ситуациями, когда нужны
похожие, но не в точности одинаковые классы. Если эти классы обладают неким общим поведением, то можно
воспользоваться одним из основных свойств объектно-ориентированной парадигмы - наследованием.
Наследование атрибутов
Рассмотрим наследование на примере программы для управления зоомагазином. Одним из предметных классов будет
класс Животное для представления любого животного из тех, которыми торгует магазин. Среди данных, описывающих
объекты класса Животное, будут русское и латинское названия животного, его возраст и пол. Однако подбор остальных
сведений уже зависит от конкретного вида животного. Так, важная информация о рептилиях - длина, а о млекопитающих вес. Ни вес, ни длина рыб не представляют интереса, однако важен цвет. В описаниях всех животных, которые продаются
в магазине, есть некоторые общие данные, а также данные, специфичные для конкретных подгрупп.
Эти связи можно представить на диаграмме (см. рис.4.1). Класс Животное содержит данные, общие для всех видов
животных. Подгруппы - Млекопитающее, Рептилия и Рыба - добавляют к этому классу специфичную информацию.
Повторять в них общие данные необязательно, так как они наследуются от класса Животное. Другими словами, классы
Млекопитающее, Рептилия и Рыба включают и те четыре атрибута,
которые определены в классе Животное.
Если вы внимательно посмотрите на рис. 4.1, то заметите, что
линии направлены от подгрупп к классу Животное. Это вроде бы
противоречит реальному положению дел, ведь данные из класса
Животное распространяются вниз к подгруппам. Такое направление
стрелок диктуется принятым соглашением, хотя это и противоречит
интуиции.
В объектно-ориентированной терминологии подгруппы называются
подклассами или производными классами. Класс Животное
является по отношению к ним суперклассом, или базовым классом.
Для усвоения понятия наследования надо помнить, что подклассы
Рис.4.1. Связи между классами в программе для
являются
зоомагазина
специализ
ациями
суперкласса. Таким образом, отношение между базовым и
Производным классом можно выразить словом «является»:
- млекопитающее является животным;
- рептилия является животным;
- рыба является животным.
Если слово «является» неадекватно описывает ситуацию, то вы
имеете дело не с наследованием. Предположим, к примеру, что
вы пишете программу для учета оборудования в пункте проката
лыж. Вы создаете класс для товара общего вида и его подклассы
для представления конкретных типов сдаваемых напрокат
товаров, как показано в первых четырех прямоугольниках на рис.
4.2. Наследование здесь вполне применимо, поскольку и лыжи, и
ботинки, и палки являются частными случаями товара.
Однако, когда вы переходите к рассмотрению товаров и клиентов,
берущих их в аренду, возникают проблемы. Хотя между
арендатором и товаром существует непосредственная связь, это
не наследование: ведь словом «является» ее не описать. Взятый
напрокат товар не является арендатором!
Рис.4. 2. Наследование и отсутствие наследования в
программе для пункта проката лыж
Ситуация с товарами и сдаваемым напрокат инвентарем сложнее. Классы Инвентарь, Лыжи, Ботинки и Палки описывают
типы товаров, но не материальные предметы. Например, в пункте проката может быть много пар однотипных лыж и много
пар ботинок одной модели и размера. Поэтому конкретный сдаваемый напрокат предмет описывается классом Предмет
проката.
Предметом проката могут быть лыжи, ботинки или палки. Это может быть только один предмет, а не три, как показано на
рис 4.2. Поэтому предмет проката – это не пара лыж, не пара ботинок, и не пара палок. (Кстати, проблема еще и в том, что
нет класса, который содержал бы информацию о размере и/или длине предмета.)
Одно из возможных решений состоит в том, чтобы создать отдельный класс предмета проката для каждого типа товара,
как показано на рис. 4.3. Обратите внимание на направление стрелок. Физическое расположение элементов на диаграмме
не соответствует направлению наследования. Помните, что по соглашению стрелки направлены от производного класса к
базовому.
Класс Пара лыж наследует информацию о типе предмета от класса
Лыжи. Он также получает данные о сдаваемом напрокат предмете от
класса Предмет проката. Объект класса Пара лыж отражает пару лыж, а
также сдаваемый напрокат предмет.
В таком виде структура классов проходит тест на соответствие
отношению «является» и, стало быть, удовлетворяет условиям
правильного наследования. (Необходимо отметить, что попутно вы
получили класс, содержащий такую информацию, как длина и размер
инвентаря.) Класс Арендатор вообще не принимает участия в иерархии
наследования.
В таком виде структура классов проходит тест на соответствие
отношению «является» и, стало быть, удовлетворяет условиям
правильного наследования. (Необходимо отметить, что попутно вы
получили класс, содержащий такую информацию, как длина и размер
инвентаря.) Класс Арендатор вообще не принимает участия в иерархии
наследования.
Множественное наследование
Когда некий класс наследует информацию более чем одного базового
класса, следует говорить о множественном наследовании. Различные
языки программирования и СУБД поддерживают множественное
наследование в разной степени.
Не каждый класс в иерархии наследования непременно используется для
создания объектов. Например, маловероятно, что будут создаваться
объекты класса Инвентарь или Предмет проката (см. рис. 4.3). Эти
классы присутствуют только для того, чтобы предоставить общий набор
атрибутов и методов своим производным классам.
Рис. 4.3. Множественное наследование в
программе для пункта проката лыж
Такого рода классы называются абстрактными или виртуальными.
Напротив, классы, из которых создаются объекты, называются
конкретными.
Интерфейсы
Некоторые объектно-ориентированные языки (прежде всего Java) не поддерживают множественного наследования. Они
допускают наличие только одного базового класса, но зато разрешают реализовывптъ разные интерфейсы.
Интерфейс (Interface) - это спецификация класса, методы которого не хранят никакого кода. Другими словами, в классе
определены сигнатуры всех методов, но нет их реализации. Предоставить осуществление каждого метода входит в
обязанности класса, реализующего интерфейс. Последний может содержать методы и атрибуты или только методы или
только атрибуты.
В большинстве случае интерфейс проектируется для того, чтобы придать классу дополнительную функциональность.
Например, если бы иерархию, изображенную на рис. 4.3, нужно было использовать в среде, не поддерживающей
множественное наследование, то класс Пара ботинок мог бы наследовать классу Ботинки и реализовывать интерфейс
Предмет проката. В последнем были бы атрибуты, описывающие прокат инвентаря, а также методы, необходимые для
выдачи, вычисления арендной платы и времени возврата арендованного инвентаря. Любой класс, представляющий
инвентарь, должен был бы реализовать этот интерфейс, описав тем самым поведение, которым должен обладать
сдаваемый напрокат объект.
2. Полиморфизм
В общем случае методы наследуются подклассами от своих суперклассов. Подкласс может применять методы базового
класса как свои собственные. Однако иногда невозможно написать метод, достаточно общий для использования всеми
подклассами. Предположим, например, что класс Инвентарь из предыдущего примера имеет метод printCatalogEntry.
предназначенный для красивой печати каталожного описания одного вида товаров. Но одни подклассы класса Инвентарь
имеют атрибуты, отсутствующие в других подклассах, поэтому метод printCatalogEntry по-разному реализуется в каждом
подклассе.
Для решения этой проблемы можно воспользоваться преимуществами, которые дает полиморфизм (Polymorphism), а
именно возможностью иметь разные тела у методов с одним и тем же именем, но принадлежащих различным классам в
одной иерархии наследования. Класс Инвентарь включает в себя прототип метода printCatalogEntry, который лишь
описывает его открытый интерфейс. В этом классе у метода нет тела, то есть не сказано, какие конкретные действия он
должен выполнить (такой метод называется абстрактным). В каждом подклассе он переопределяется - пишется
необходимый код.
Удобство полиморфизма в том, что программист может ожидать наличия методов с одним и тем же именем и семантикой
выполняемой процедуры во всех подклассах одного и того же базового класса. Но при этом каждый подкласс может
выполнять операцию так, как ему нужно. Инкапсуляция скрывает детали реализации от всех объектов вне данной
иерархии.
Очень легко спутать полиморфизм с перегрузкой. Надо помнить, что перегрузка относится к методам одного и того же
класса, имеющим одно имя, но разные сигнатуры, тогда как полиморфизм применим к разным подклассам одного базового
класса, в которых есть методы с одинаковой сигнатурой, но разной реализацией.
Лекция 7. ОТЛАДКА, ТЕСТИРОВАНИЕ И ДОКУМЕНТИРОВАНИЕ ПРОГРАММ
План лекции
1. ОСНОВНЫЕ ПОНЯТИЯ
2. ВИДЫ ОТЛАДКИ ПРОГРАММНОГО СРЕДСТВА
3. ПРИНЦИПЫ ОТЛАДКИ ПРОГРАММНОГО СРЕДСТВА.
4. АВТОНОМНАЯ ОТЛАДКА ПРОГРАММНОГО СРЕДСТВА.
5. КОМПЛЕКСНАЯ ОТЛАДКА ПРОГРАММНОГО СРЕДСТВА
6. ОРГАНИЗАЦИЯ ТЕСТИРОВАНИЯ В ОБЪЕКТНО-ОРИЕНТИРОВАННЫХ СИСТЕМАХ
1. ОСНОВНЫЕ ПОНЯТИЯ
Отладка ПС - деятельность по обнаружению и исправлению ошибок в ПС с использованием процессов выполнения его
программ. Тестирование ПС - процесс выполнения его программ на некотором наборе данных, для которого заранее
известен результат применения или известны правила поведения этих программ. Этот набор данных называется тестовым
или просто тестом.
Отладка = Тестирование + Поиск ошибок + Редактирование.
2. ВИДЫ ОТЛАДКИ ПРОГРАММНОГО СРЕДСТВА
Задачи отладки программных средств.
1. Подготовить такой набор тестов и применить к ним ПС, чтобы обнаружить в нем по возможности большее число ошибок.
2. Определить момент окончания отладки ПС (или отдельной его компоненты).
Для оптимизации набора тестов, необходимо заранее планировать этот набор и использовать рациональную стратегию
планирования тестов. Проектирование тестов можно начинать сразу же после завершения этапа внешнего описания ПС.
Возможны разные подходы к выработке стратегии проектирования тестов, которые можно условно графически разместить
(см. рис.1) между следующими двумя крайними подходами.
Рис. 1. Спектр подходов к проектированию тестов.
Оптимальная стратегия проектирования тестов расположена внутри интервала между этими крайними подходами, но
ближе к левому краю. При этом в первом случае эта стратегия базируется на принципах:
* на каждую используемую функцию или возможность - хотя бы один тест,
* на каждую область и на каждую границу изменения какой-либо входной величины - хотя бы один тест,
* на каждую особую (исключительную) ситуацию, указанную в спецификациях, - хотя бы один тест.
Во втором случае эта стратегия базируется на принципе: каждая команда каждой программы ПС должна проработать хотя
бы на одном тесте.
В нашей стране различаются два основных вида отладки (включая тестирование):
Автономная отладка ПС - последовательное раздельное тестирование различных частей программ с поиском и
исправлением в них фиксируемых при тестировании ошибок. Комплексная отладка - тестирование ПС в целом с поиском и
исправлением фиксируемых при тестировании ошибок во всех документах.
3. ПРИНЦИПЫ ОТЛАДКИ ПРОГРАММНОГО СРЕДСТВА.
Отметим феномен - по мере роста числа обнаруженных и исправленных ошибок в ПС растет также относительная
вероятность существования в нем необнаруженных ошибок.
Принцип 1. Считайте тестирование ключевой задачей разработки ПС, поручайте его самым квалифицированным и
одаренным программистам; нежелательно тестировать свою собственную программу.
Принцип 2. Хорош тот тест, для которого высока вероятность обнаружить ошибку, а не тот, который демонстрирует
правильную работу программы.
Принцип 3. Готовьте тесты как для правильных, так и для неправильных данных.
Принцип 4. Документируйте пропуск тестов через компьютер; детально изучайте результаты каждого теста; избегайте
тестов, пропуск которых нельзя повторить.
Принцип 5. Каждый модуль подключайте к программе только один раз; никогда не изменяйте программу, чтобы облегчить
ее тестирование.
Принцип 6. Пропускайте заново все тесты, связанные с проверкой работы какой-либо программы ПС или ее
взаимодействия с другими программами, если в нее были внесены изменения (например, в результате устранения
ошибки).
4. АВТОНОМНАЯ ОТЛАДКА ПРОГРАММНОГО СРЕДСТВА.
При автономной отладке тестируется всегда некоторая программа (тестируемая программа), построенная специально для
тестирования отлаживаемого модуля. В процессе автономной отладки ПС производится наращивание тестируемой
программы отлаженными модулями (интеграция программы).
При восходящем тестировании окружение содержит только один отладочный модуль, головной в тестируемой программе ведущий (или драйвер). Ведущий отладочный модуль подготавливает информационную среду для тестирования
отлаживаемого модуля, осуществляет обращение к отлаживаемому модулю и выдает необходимые сообщения.
При нисходящем тестировании окружение в качестве отладочных содержит отладочные имитаторы (заглушки) некоторых
еще не отлаженных модулей. Некоторые из этих имитаторов при отладке одного модуля могут изменяться для разных
тестов.
На практике в окружении отлаживаемого модуля могут содержаться отладочные модули обоих типов, если используется
смешанная стратегия тестирования.
Достоинства восходящего тестирования:
1) простота подготовки тестов,
2) возможность полной реализации плана тестирования модуля.
Недостатки восходящего тестирования:
1) тестовые данные готовятся, как правило, не в той форме, которая рассчитана на пользователя;
2) большой объем отладочного программирования;
3) необходимость специального тестирования сопряжения модулей.
Достоинства нисходящего тестирования:
1) большинство тестов готовится в форме, рассчитанной на пользователя;
2) во многих случаях относительно небольшой объем отладочного программирования;
3) отпадает необходимость тестирования сопряжения модулей.
Недостатком нисходящего тестирования является то, что тестовое состояние информационной среды перед обращением к
отлаживаемому модулю готовится косвенно - оно является результатом применения уже отлаженных модулей к тестовым
данным или данным, выдаваемым имитаторами.
Прежде всего, необходимо организовать отладку программы таким образом, чтобы как можно раньше были отлажены
модули, осуществляющие ввод данных. Пока модули, осуществляющие ввод данных, не отлажены, тестовые данные
поставляются некоторыми имитаторами: они либо включаются в имитатор как его часть, либо вводятся этим имитатором.
При нисходящем тестировании некоторые состояния информационной среды, при которых требуется тестировать
отлаживаемый модуль, могут не возникать при выполнении отлаживаемой программы ни при каких входных данных. Чаще
же пользуются модифицированным вариантом нисходящего тестирования, при котором отлаживаемые модули перед их
интеграцией предварительно тестируются отдельно. Однако, представляется более целесообразной другая модификация
нисходящего тестирования: после завершения нисходящего тестирования отлаживаемого модуля для достижимых
тестовых состояний информационной среды следует его отдельно протестировать для остальных требуемых состояний
информационной среды.
Часто применяют также комбинацию восходящего и нисходящего тестирования, которую называют методом сандвича.
Сущность этого метода заключается в одновременном осуществлении как восходящего, так и нисходящего тестирования,
пока эти два процесса тестирования не встретятся на каком-либо модуле где-то в середине структуры отлаживаемой
программы.
Весьма важным при автономной отладке является тестирование
сопряжения модулей. При нисходящем тестировании тестирование сопряжения осуществляется попутно каждым
пропускаемым тестом, что считают достоинством нисходящего тестирования. При восходящем тестировании обращение к
отлаживаемому модулю производится не из модулей отлаживаемой программы, а из ведущего отладочного модуля.
Автономное тестирование модуля целесообразно осуществлять в четыре последовательно выполняемых шага.
Шаг 1. На основании спецификации отлаживаемого модуля подготовьте тесты для каждой возможности и каждой ситуации,
для каждой границы областей допустимых значений всех входных данных, для каждой области изменения данных, для
каждой области недопустимых значений всех входных данных и каждого недопустимого условия.
Шаг 2. Проверьте текст модуля, чтобы убедиться, что каждое направление любого разветвления будет пройдено хотя бы
на одном тесте. Добавьте недостающие тесты.
Шаг 3. Проверьте текст модуля, чтобы убедиться, что для каждого цикла существуют тесты, обеспечивающие, по крайней
мере, три следующие ситуации: тело цикла не выполняется ни разу, тело цикла выполняется один раз и тело цикла
выполняется максимальное число раз. Добавьте недостающие тесты.
Шаг 4. Проверьте текст модуля, чтобы убедиться, что существуют тесты, проверяющие чувствительность к отдельным
особым значениям входных данных. Добавьте недостающие тесты.
5. КОМПЛЕКСНАЯ ОТЛАДКА ПРОГРАММНОГО СРЕДСТВА
Тестирование при комплексной отладке - применение ПС к конкретным данным, которые могут возникнуть у пользователя,
но, возможно, в моделируемой (а не в реальной) среде.
Тестирование архитектуры ПС. Целью тестирования является поиск несоответствия между описанием архитектуры и
совокупностью программ ПС. К моменту начала тестирования архитектуры ПС должна быть уже закончена автономная
отладка каждой подсистемы.
Тестирование внешних функций. Целью тестирования является поиск расхождений между функциональной
спецификацией и совокупностью программ ПС. Несмотря на то, что все эти программы автономно уже отлажены,
указанные расхождения могут быть,
Тестирование качества ПС. Целью тестирования является поиск нарушений требований качества, сформулированных в
спецификации качества ПС. Завершенность ПС проверяется уже при тестировании внешних функций.
Тестирование документации по применению ПС. Целью тестирования является поиск несогласованности документации по
применению и совокупностью программ ПС, а также выявление неудобств, возникающих при применении ПС. Этот этап
непосредственно предшествует подключению пользователя к завершению разработки ПС (тестированию определения
требований к ПС и аттестации ПС).
Тестирование определения требований к ПС. Целью тестирования является выяснение, в какой мере ПС не соответствует
предъявленному определению требований к нему. Особенность этого вида тестирования заключается в том, что его
осуществляет организация-покупатель или организация-пользователь. Обычно производится с помощью контрольных
задач - типовых задач, для которых известен результат решения.
6. ОРГАНИЗАЦИЯ ТЕСТИРОВАНИЯ В ОБЪЕКТНО-ОРИЕНТИРОВАННЫХ СИСТЕМАХ
Тестирование является достаточно независимым процессом, применимым к программному обеспечению, разработанному
с помощью любого метода проектирования. Тем не менее объектно-ориентированный подход привносит свои особенности.
Традиционно тестирование делится на тестирование элементов, интеграционное тестирование и системное тестирование.
На уровне элементов тестирование объектно-ориентированных программ отличается по следующим показателям:
• определение единиц тестирования;
• тестирование наследования;
• тестирование полиморфизма.
Естественной единицей тестирования является класс. Разбиение его на более мелкие элементы (методы)
нецелесообразно, поскольку они не существуют отдельно от классов. Иногда за единицу тестирования принимается тесно
связанная группа классов.
Тестирование наследования состоит в тестировании методов, унаследованных классом от своего базового класса. Если
базовый класс уже прошел тестирование, нужно ли повторять тестирование для унаследованных методов- Вопреки
достаточно распространенным надеждам программистов перетестирование необходимо. Основная причина та, что методы
выполняются в новом контексте.
Применимость тестовых сценариев базового класса для тестирования производного класса зависит от того, является ли
наследование классификацией. Если нет, то даже для унаследованных методов необходимо разрабатывать новые
тестовые сценарии.
Тестирование полиморфизма сходно с тестированием наследования в том, что в тестовых сценариях необходимо
предусмотреть все варианты связывания, т.е. все варианты конкретной реализации полиморфизма.
Интеграционное тестирование представляет собой тестирование того, как отдельные элементы программы работают
вместе. Свойства объектно-ориентированных языков исключают целый ряд возможных ошибок, прежде всего за счет
строгого определения внешних интерфейсов классов и объектов. Однако это не означает, что интеграционное
тестирование становится легче. Планирование интеграционного тестирования немного отличается.
При традиционном тестировании имеется такая характеристика, как степень покрытия кода. При тестировании по принципу
открытого, или белого ящика (т.е. в случае, когда тестирующему известна структура кода) необходимо обеспечить
прохождение управления по всем ответвлениям программы. Иными словами, требуется выполнить как можно больший
процент инструкций, имеющихся в программе. Наряду с этой характеристикой планирование тестов для объектноориентированной программы должно включать «покрытие состояний».
То, что объект соединяет в себе состояние и поведение, обусловливает необходимость проверки всех возможных
переходов из состояния в состояние. В планировании таких тестов должна помочь модель состояний класса, построенная
на этапе анализа и проектирования.
Системное тестирование проверяет всю программную систему целиком и строится в большинстве случаев по принципу
«черного ящика». Тестирующий знает только внешние характеристики системы, но не знает, как она работает.
Построение требований к системе в форме вариантов использования обеспечивает естественный и простой способ
планирования системного тестирования. Фактически система вариантов использования становится основой плана тестов
на этапе системного тестирования.
Лекция 8. ОРГАНИЗАЦИЯ РАЗРАБОТКИ ПРОГРАММНЫХ СИСТЕМ
План лекции
1.Назначение управления разработкой программного средства и его основные процессы.
2.Структура управления разработкой программных средств. Подходы к организации бригад разработчиков.
3.Управление качеством программного средства.
4. Аттестация программного средства и характеристика методов оценки качества программного средства.
1. Назначение управления разработкой программного средства и его основные процессы.
Управление разработкой ПС (software management) – это деятельность, направленная на обеспечение необходимых
условий для работы коллектива разработчиков ПС, на планирование и контроль деятельности этого коллектива с целью
обеспечения требуемого качества ПС, выполнения сроков и бюджета разработки ПС. Финальной частью этой
деятельности является организация и проведения аттестации (сертификации) ПС, которой завершается стадия разработки
ПС.
Выделим общие процессы по управлению разработкой ПС:
* составление плана-проспекта по разработке ПС;
* планирование и составление расписаний по разработке ПС;
* управление издержками по разработке ПС;
* текущий контроль и документирование деятельности коллектива по разработке ПС.
* подбор и оценка персонала коллектива разработчиков ПС.
Составление плана-проспекта по разработке ПС включает формулирование предложений о том, как выполнять разработку
ПС. Прежде всего, должно быть зафиксировано, для кого разрабатывается ПС:
* для внешнего заказчика,
* для других подразделений той же организации,
* или является инициативной внутренней разработкой.
В плане-проспекте должны быть установлены общие очертания работ по создания ПС и оценена стоимость разработки, а
также предоставляемые для разработки ПС материально-финансовые ресурсы и временные ограничения.
Планирование и составление расписаний по разработке ПС – это деятельность, связанная с распределением работ между
исполнителями и по времени их выполнения в рамках намеченных сроков и имеющихся ресурсов.
Управление издержками по разработке ПС – это деятельность, направленная на обеспечение подходящей стоимости
разработки в рамках выделенного бюджета. Она включает оценивание стоимости разработки проекта в целом или
отдельных его частей, контроль выполнения бюджета, выбор подходящих вариантов расходования бюджета. Эта
деятельность тесно связана с планированием и составлением расписаний в течение всего периода выполнения проекта.
Основными источниками издержек являются
* затраты на аппаратное оборудование (hardware);
* затраты на вербовку и обучение персонала;
* затраты на оплату труда разработчиков.
Текущий контроль и документирование деятельности коллектива по разработке ПС – это непрерывный процесс слежения
за ходом развития проекта, сравнения действительных состояния и издержек с запланированными, а также
документирования различных аспектов развития проекта. Этот процесс помогает вовремя обнаружить затруднения и
предсказать возможные проблемы в развитии проекта.
Подбор и оценка персонала коллектива разработчиков ПС – это деятельность, связанная с формированием коллектива
разработчиков ПС.
2. Структура управления разработкой программных средств.
Разработка ПС обычно производится в организации, в которой одновременно могут вестись разработки ряда других
программных средств. Для управления всеми этими программными проектами используется иерархическая структура
управления.
Во главе этой иерархии находится директор (или вице-президент) программистской организации, отвечающий за
управление всеми разработками программных средств.
Менеджер сферы разработок отвечает за управление разработками программных средств (систем) определенного типа,
например, программные системы в сфере бизнеса, экспертные системы, программные инструменты и инструментальные
системы, поддерживающие процессы разработки программных средств, и другие. Ему непосредственно подчинены
менеджеры проектов, относящихся к его сфере.
По каждому программному проекту назначается свой менеджер, который управляет развитием этого проекта. Ему
непосредственно подчинены лидеры бригад разработчиков. Менеджер проекта осуществляет планирование и составление
расписаний работы этих бригад по разработке соответствующего ПС (см. следующий раздел).
Обычно большой проект разбивается на несколько относительно независимых подпроектов таким образом, чтобы каждый
подпроект мог быть выполнен отдельной небольшой бригадой разработчиков.
Наиболее употребительны три подхода к организации бригад разработчиков:
* обычные бригады,
* неформальные демократические бригады,
* бригады ведущего программиста.
Существенную роль в управлении качеством ПС играют программные (софтверные) стандарты. Они фиксируют удачный
опыт высоко квалифицированных специалистов по разработке ПС для различных их классов и для разных моделей их
качества. Различают два вида таких стандартов:
* стандарты ПС (программного продукта),
* стандарты процесса создания и использования ПС.
Уже отмечалось, что эти стандарты могут быть как международными или национальными, так и специально созданными
для организации, в которой ведется разработка ПС. Разработка последних стандартов является одной из функций
управления обеспечением качества ПС.
Бригада по контролю качества состоит из ассистентов (рецензентов) по качеству ПС. Она проводит смотры тех или иных
частей ПС или всего ПС в целом с целью поиска возникающих проблем в процессе его разработки.
3. Управление качеством программного средства.
Планирование и составление расписаний по разработке ПС представляет собой итеративный процесс, который
заканчивается только после прекращения работ по самому программному проекту.
В начале этого описания оцениваются общий срок разработки ПС, используемые штаты исполнителей, предельный
бюджет и другие ограничения (условия) разработки. Должны быть также определены “вехи развития проекта” и их сроки.
Веха развития проекта (project progress milestone) – это конечная точка некоторого этапа или процесса, с которой
связывается выдача некоторого промежуточного продукта, представляющего собой некоторый четко определенный
документ.
Далее начинается итерационный процесс, основу которого составляет повторяющиеся составления расписаний.
Составление расписания заключается
* в разделении всей работы, необходимой для выполнения проекта, на отдельные самостоятельно выполняемые задания;
* в составлении сетевого графика выполнения заданий;
* в составлении гистограммы выполнения заданий;
* в расстановке исполнителей заданий.
При выделении самостоятельных заданий для каждого из них оценивается время его выполнения и его зависимость от
других заданий с точки зрения порядка выполнения. Сетевой график представляет собой схему (сеть) путей выполнения
заданий с указанием времени выполнения каждого задания и с расстановкой вех развития проекта. В сетевом графике
должен быть определен критический путь, представляющий собой такой путь заданий, суммарное время выполнения
которых является наибольшим. Гистограмма выполнения заданий (activity bar chart) содержит для каждого задания свою
временн-ю полосу от момента, когда выполнение этого задания может быть начато, и до момента, когда выполнение этого
задания должно быть закончено.
Спустя некоторое время (обычно 2-3 недели) после активизации процессов, указанных в расписании, производится
обозрение (просмотр) хода развития проекта и отмечаются возникшие противоречия. С учетом этого производится
пересмотр (уточнение) параметров проекта и оценивается влияние измененных параметров на расписание проекта. В том
случае, когда заказчик не может пойти на подходящие изменения, производится технический пересмотр проекта с целью
поиска альтернативных подходов к разработке ПС.
4 Аттестации программного средства.
Завершающим этапом разработки ПС - аттестация (certification) ПС - авторитетное подтверждение качества ПС.
Аттестационная комиссия проводит приемо-сдаточные испытания ПС с целью получения необходимой информации для
оценки его качества. Под испытанием ПС - процесс проведения комплекса мероприятий, исследующих пригодность ПС для
успешной его эксплуатации (применения и сопровождения) в соответствии с требованиями заказчика. На основе
полученной информации комиссия должна установить, в какой степени ПС выполняет декларированные функции и в какой
степени ПС обладает декларированными примитивами и критериями качества. Решение аттестационной комиссии о
произведенной оценке качества ПС фиксируется в соответствующем документе (сертификате), который подписывается
членами комиссии.
Таким образом, оценка качества ПС является основным содержанием процесса аттестации. Различают следующие группы
методов оценки примитивов качества ПС:
* непосредственное измерение показателей примитива качества;
* тестирование программ ПС;
* экспертная оценка на основании изучения программ и документации ПС.
Непосредственное измерение показателей примитива качества производится путем проверки соответствия предъявленной
документации (включая тексты программ на языке программирования) стандартам или явным требованиям, указанным в
спецификации качества ПС, а также путем измерения времени работы различных устройств и используемых ресурсов при
выполнении контрольных (тестовых) задач.
Для оценки некоторых примитивов качества ПС используется тестирование. В некоторых случаях для оценки качества ПС
проводятся дополнительные полевые или промышленные испытания. Полевые испытания ПС – это демонстрация ПС
вместе с технической системой, которой управляет эта ПС, с обеспечением тщательного наблюдения за поведением ПС.
Промышленные испытания ПС – это процесс передачи ПС в постоянную эксплуатацию пользователям, представляющий
собой опытную эксплуатацию ПС пользователями со сбором информации об особенностях поведения ПС и ее
эксплуатационных характеристиках.
Многие примитивы качества ПС трудно уловимы с точки зрения их (объективной) оценки. В этих случаях иногда применяют
метод экспертных оценок. Этот метод заключается в следующем. Назначается группа экспертов и каждый из этих
экспертов в результате изучения представленной документации составляет свое мнение об обладании ПС требуемым
примитивом качества.
Аттестация ПС похожа на смотр различных компонент ПС в процессе управления качеством ПС, однако, имеются и
существенные различия. Во-первых, смотр проводится менее представительной группой специалистов. Во-вторых, в
процессе смотра не производится полной оценки качества ПС. Целью же аттестации является проверка и фиксация
реальных показателей качества предъявленного ПС. Аттестационная комиссия, подписывая документ о произведенной
оценке качества ПС, принимает на себя определенную ответственность за гарантию качества этого ПС. Но здесь имеются
определенные правовые проблемы, обсуждение которых выходит за рамки темы этой лекции.
Лекция 9. ИНСТРУМЕНТАЛЬНЫЕ И ЯЗЫКОВЫЕ СРЕДСТВА ПОДДЕРЖКИ И
АВТОМАТИЗАЦИИ ПРОЕКТИРОВАНИЯ ПРОГРАММНЫХ СИСТЕМ
План лекции
1. ПРЕДВАРИТЕЛЬНЫЕ ЗАМЕЧАНИЯ
2. ПОДДЕРЖКА ПРОЦЕССА ЖИЗНЕННОГО ЦИКЛА ПС С ПОМОЩЬЮ МЕТОДОВ МОДЕЛИРОВАНИЯ
3. ИНСТРУМЕНТАЛЬНЫЕ СРЕДСТВА АВТОМАТИЗАЦИИ РАЗРАБОТКИ ПС
Программные инструменты в жизненном цикле программных средств. Инструментальные среды и инструментальные
системы поддержки разработки программных средств, их классификация. Компьютерная технология (CASE-технология)
разработки программных средств и ее рабочие места. Общая архитектура инструментальных систем технологии
программирования
1. ПРЕДВАРИТЕЛЬНЫЕ ЗАМЕЧАНИЯ
В настоящее время существуют несколько сред программирования «под Windows», использующих объектноориентированный подход и включающих мощные библиотеки объектов. В качестве примеров можно назвать среды
разработки Visual C++, Delphi, C++Builder, которые позволяют сравнительно легко создавать сложнейшие приложения
Windows. Эти пакеты автоматизируют многие операции создания приложения, предлагая разработчику большое
количество различных шаблонов и заготовок, начиная от заготовки будущего приложения.
Примечание. Visual C++ является наиболее универсальным из названных трех пакетов, но и, соответственно, самым
сложным. Он использует развитую объектную модель C++ и имеет более мощную по сравнению с Delphi и C++Builder
библиотеку объектов. Интерфейс и средства Visual C++ ориентированы на профессиональные разработки высокого уровня
и далее в настоящем курсе рассматриваться не будут.
Delphi и C++Builder используют идентичные среды и одну и ту же библиотеку объектов VCL (Visual Component Library библиотека визуальных компонент). Практически эти среды различаются только языком разработки: Delphi использует
язык на основе Object Pascal, a C++Builder, как указано в названии, C++. Используемые объектные модели также во многом
похожи.
2. ПОДДЕРЖКА ПРОЦЕССА ЖИЗНЕННОГО ЦИКЛА ПС С ПОМОЩЬЮ МЕТОДОВ МОДЕЛИРОВАНИЯ
Любое приложение, созданное в этих средах, состоит как минимум из трех объектов: объекта-приложения, объекта-формы
(окна) и объекта-экрана. В большинстве случаев разработчик использует те варианты объекта-приложения и объектаэкрана, которые ему предоставляются средой. Основное внимание в процессе разработки сосредоточивается на создании
объектов-форм и соответствующих оконных функций. При этом широко используются стандартные классы библиотеки
VCL.
3. ИНСТРУМЕНТАЛЬНЫЕ СРЕДСТВА РАЗРАБОТКИ И СОПРОВОЖДЕНИЯ ПРОГРАММНЫХ СРЕДСТВ
ПС, предназначенное для поддержки разработки других ПС, будем называть программным инструментом разработки ПС, а
устройство компьютера, специально предназначенное для поддержки разработки ПС, будем называть аппаратным
инструментом разработки ПС.
С точки зрения функций, которые инструменты выполняют при разработке ПС, их можно разбить на следующие четыре
группы:
* редакторы,
* анализаторы,
* преобразователи,
* инструменты, поддерживающие процесс выполнения программ.
16.2. Инструментальные среды разработки и сопровождения программных средств и принципы их
классификации.
Компьютерная поддержка процессов разработки и сопровождения ПС может производиться не только за счет
использования отдельных инструментов (например, компилятора), но и за счет использования некоторой логически
связанной совокупности программных и аппаратных инструментов. Такую совокупность будем называть инструментальной
средой разработки и сопровождения ПС.
Часто разработка ПС производится на том же компьютере, на котором оно будет применяться. Это достаточно удобно. Вопервых, в этом случае разработчик имеет дело только с компьютерами одного типа. А, во-вторых, в разрабатываемое ПС
могут включаться компоненты самой инструментальной среды. Однако, это не всегда возможно. Например, компьютер, на
котором должно применяться ПС, может быть неудобен для поддержки разработки ПС или его мощность недостаточна для
обеспечения функционирования требуемой инструментальной среды. Кроме того, такой компьютер может быть недоступен
для разработчиков этого ПС (например, он постоянно занят другой работой, которую нельзя прерывать, или он находится
еще в стадии разработки). В таких случаях применяется так называемый инструментально-объектный подход. Сущность
его заключается в том, что ПС разрабатывается на одном компьютере, называемым инструментальным, а применяться
будет на другом компьютере, называемым целевым (или объектным).
Инструментальная среда не обязательно должна функционировать на том компьютере, на котором должно будет
применяться разрабатываемое с помощью ее ПС.
Совокупность инструментальных сред можно разбивать на разные классы, которые различаются значением следующих
признаков:
* ориентированность на конкретный язык программирования,
* специализированность,
* комплексность,
* ориентированность на конкретную технологию программирования,
* ориентированность на коллективную разработку,
* интегрированность.
Инструментальную среду, интегрированную хотя бы по данным или по действиям, будем называть инструментальной
системой. При этом интегрированность по данным предполагает наличие в системе специализированной базы данных,
называемой репозиторием. Под репозиторием будем понимать центральное компьютерное хранилище информации,
связанной с проектом (разработкой) ПС в течение всего его жизненного цикла.
16.3. Основные классы инструментальных сред разработки и сопровождения программных средств.
В настоящее время выделяют три основных класса инструментальных сред разработки и сопровождения ПС:
* инструментальные среды программирования,
* рабочие места компьютерной технологии,
* инструментальные системы технологии программирования.
16.3. Инструментальные среды программирования.
Инструментальная среда программирования включает, прежде всего, текстовый редактор, позволяющий конструировать
программы на заданном языке программирования, а также инструменты, позволяющие компилировать или
интерпретировать программы на этом языке, тестировать и отлаживать полученные программы. Различают следующие
классы инструментальных сред программирования:
* среды общего назначения,
* языково-ориентированные среды.
16.4. Понятие компьютерной технологии разработки программных средств и ее рабочие места.
Имеются некоторые трудности в выработке строгого определения CASE-технологии (компьютерной технологии разработки
ПС). CASE - это абревиатура от английского Computer-Aided Software Engineering (Компьютерно-Помогаемая Инженерия
Программирования). Под CASE может пониматься и инженерия всего жизненного цикла ПС (включая и его
сопровождение), но только в том случае, когда программы частично или полностью генерируются по документам,
полученным на указанных ранних этапах разработки. В этом случае CASE-технология стала принципиально отличаться от
ручной (традиционной) технологии разработки ПС: изменилось не только содержание технологических процессов, но и
сама их совокупность.
В настоящее время компьютерную технологию разработки ПС можно характеризовать использованием
* программной поддержки для разработки графических требований и графических спецификаций ПС,
* автоматической генерации программ на каком-либо языке программирования или в машинном коде (частично или
полностью),
* программной поддержки прототипирования.
Из проведенного обсуждения можно определить компьютерную технологию разработки ПС как технологию
программирования, в которой используются программные инструменты для разработки формализованных спецификаций
программ и других документов (включая и графические спецификации) с последующей автоматической генерацией
программ и документов (или хотя бы значительной их части) по этим спецификациям.
Теперь становятся понятными и основные изменения в жизненном цикле ПС для компьютерной технологии. Если при
использовании ручной технологии основные усилия по разработке ПС делались на этапах собственно программирования
(кодирования) и отладки (тестирования), то при использовании компьютерной технологии - на ранних этапах разработки
ПС (определения требований и функциональной спецификации, разработки архитектуры). При этом существенно
изменился характер документации. Вместо целой цепочки неформальных документов, ориентированной на передачу
информации от заказчика (пользователя) к различным категориям разработчикам, формируются прототип ПС,
поддерживающий выбранный пользовательский интерфейс, и формальные функциональные спецификации (иногда и
формальные спецификации архитектуры ПС), достаточные для автоматического синтеза (генерации) программ ПС (или
хотя бы значительной их части). При этом появилась возможность автоматической генерации части документации,
необходимой разработчикам и пользователям. Вместо ручного программирования (кодирования) - автоматическая
генерация программ, что делает не нужной автономную отладку и тестирование программ: вместо нее добавляется
достаточно глубокий автоматический семантический контроль документации. Появляется возможность автоматической
генерации тестов по формальным спецификациям для комплексной (системной) отладки ПС. Существенно изменяется и
характер сопровождения ПС: все изменения разработчиком-сопроводителем вносятся только в спецификации (включая и
прототип), остальные изменения в ПС осуществляются автоматически.
14.5. Инструментальные системы технологии программирования.
Инструментальная система технологии программирования - это интегрированная совокупность программных и аппаратных
инструментов, поддерживающая все процессы разработки и сопровождения больших ПС в течение всего его жизненного
цикла в рамках определенной технологии.
С учетом обсужденных свойств инструментальных систем технологии программирования можно выделить три их основные
компоненты:
* репозиторий,
* инструментарий,
* интерфейсы.
Инструментарий - набор инструментов, определяющий возможности, предоставляемые системой коллективу
разработчиков..
Интерфейсы разделяются на пользовательский и системные. Пользовательский интерфейс обеспечивает доступ
разработчикам к инструментарию. Он реализуется оболочкой системы. Системные интерфейсы обеспечивают
взаимодействие между инструментами и их общими частями. Системные интерфейсы выделяются как архитектурные
компоненты в связи с открытостью системы - их обязаны использовать новые (импортируемые) инструменты, включаемые
в систему.
Различают два класса инструментальных систем технологии программирования: инструментальные системы поддержки
проекта и языково-зависимые инструментальные системы.
Инструментальная система поддержки проекта - это открытая система, способная поддерживать разработку ПС на разных
языках программирования после соответствующего ее расширения программными инструментами, ориентированными на
выбранный язык.
Языково-зависимая инструментальная система - это система поддержки разработки ПС на каком-либо одном языке
программирования, существенно использующая в организации своей работы специфику этого языка.
Лекция 10. Документирование программных средств
1. Документация, создаваемая и используемая в процессе разработки программных средств.
При разработке ПС создается и используется большой объем разнообразной документации. Она необходима как средство
передачи информации между разработчиками ПС, как средство управления разработкой ПС и как средство передачи
пользователям информации, необходимой для применения и сопровождения ПС. На создание этой документации
приходится большая доля стоимости ПС.
Эту документацию можно разбить на две группы:
* Документы управления разработкой ПС.
* Документы, входящие в состав ПС.
Документы управления разработкой ПС (software process documentation) управляют и протоколируют процессы разработки
и сопровождения ПС, обеспечивая связи внутри коллектива разработчиков ПС и между коллективом разработчиков и
менеджерами ПС (software managers) - лицами, управляющими разработкой ПС. Эти документы могут быть следующих
типов:
* Планы, оценки, расписания. Эти документы создаются менеджерами для прогнозирования и управления процессами
разработки и сопровождения ПС.
* Отчеты об использовании ресурсов в процессе разработки. Создаются менеджерами.
* Стандарты. Эти документы предписывают разработчикам, каким принципам, правилам, соглашениям они должны
следовать в процессе разработки ПС. Эти стандарты могут быть как международными или национальными, так и
специально созданными для организации, в которой ведется разработка ПС.
* Рабочие документы. Это основные технические документы, обеспечивающие связь между разработчиками. Они содержат
фиксацию идей и проблем, возникающих в процессе разработки, описание используемых стратегий и подходов, а также
рабочие (временные) версии документов, которые должны войти в ПС.
* Заметки и переписка. Эти документы фиксируют различные детали взаимодействия между менеджерами и
разработчиками.
Документы, входящие в состав ПС (software product documentation), описывают программы ПС как с точки зрения их
применения пользователями, так и с точки зрения их разработчиков и сопроводителей (в соответствии с назначением ПС).
Здесь следует отметить, что эти документы будут использоваться не только на стадии эксплуатации ПС (в ее фазах
применения и сопровождения), но и на стадии разработки для управления процессом разработки (вместе с рабочими
документами) - во всяком случае, они должны быть проверены (протестированы) на соответствие программам ПС. Эти
документы образуют два комплекта с разным назначением:
* Пользовательская документация ПС (П-документация).
* Документация по сопровождению ПС (С-документация).
2. Пользовательская документация программных средств.
Пользовательская документация ПС (user documentation) объясняет пользователям, как они должны действовать, чтобы
применить разрабатываемое ПС. Она необходима, если ПС предполагает какое-либо взаимодействие с пользователями. К
такой документации относятся документы, которыми должен руководствоваться пользователь при инсталляции ПС (при
установке ПС с соответствующей настройкой на среду применения ПС), при применении ПС для решения своих задач и
при управлении ПС (например, когда разрабатываемое ПС будет взаимодействовать с другими системами). Эти
документы частично затрагивают вопросы сопровождения ПС, но не касаются вопросов, связанных с модификацией
программ.
В связи с этим следует различать две категории пользователей ПС: ординарных пользователей ПС и администраторов
ПС. Ординарный пользователь ПС (end-user) использует ПС для решения своих задач (в своей предметной области). Это
может быть инженер, проектирующий техническое устройство, или кассир, продающий железнодорожные билеты с
помощью ПС. Он может и не знать многих деталей работы компьютера или принципов программирования. Администратор
ПС (system administrator) управляет использованием ПС ординарными пользователями и осуществляет сопровождение
ПС, не связанное с модификацией программ. Например, он может регулировать права доступа к ПС между ординарными
пользователями, поддерживать связь с поставщиками ПС или выполнять определенные действия, чтобы поддерживать
ПС в рабочем состоянии, если оно включено как часть в другую систему.
Состав пользовательской документации зависит от аудиторий пользователей, на которые ориентировано
разрабатываемое ПС, и от режима использования документов. Под аудиторией здесь понимается контингент
пользователей ПС, у которого есть необходимость в определенной пользовательской документации ПС. Удачный
пользовательский документ существенно зависит от точного определения аудитории, для которой он предназначен.
Пользовательская документация должна содержать информацию, необходимую для каждой аудитории. Под режимом
использования документа понимается способ, определяющий, каким образом используется этот документ. Обычно
пользователю достаточно больших программных систем требуются либо документы для изучения ПС (использование в
виде инструкции), либо для уточнения некоторой информации (использование в виде справочника).
В соответствии с работами можно считать типичным следующий состав пользовательской документации для достаточно
больших ПС:
* Общее функциональное описание ПС. Дает краткую характеристику функциональных возможностей ПС. Предназначено
для пользователей, которые должны решить, насколько необходимо им данное ПС.
* Руководство по инсталяции ПС. Предназначено для администраторов ПС. Оно должно детально предписывать, как
устанавливать системы в конкретной среде, в частности, должно содержать описание компьютерно-считываемого
носителя, на котором поставляется ПС, файлы, представляющие ПС, и требования к минимальной конфигурации
аппаратуры.
* Инструкция по применению ПС. Предназначена для ординарных пользователей. Содержит необходимую информацию по
применению ПС, организованную в форме удобной для ее изучения.
* Справочник по применению ПС. Предназначен для ординарных пользователей. Содержит необходимую информацию по
применению ПС, организованную в форме удобной для избирательного поиска отдельных деталей.
* Руководство по управлению ПС. Предназначено для администраторов ПС. Оно должно описывать сообщения,
генерируемые, когда ПС взаимодействует с другими системами, и как должен реагировать администратор на эти
сообщения. Кроме того, если ПС использует системную аппаратуру, этот документ может объяснять, как сопровождать эту
аппаратуру.
Как уже говорилось ранее, разработка пользовательской документации начинается сразу после создания внешнего
описания. Качество этой документации может существенно определять успех ПС. Она должна быть достаточно проста и
удобна для пользователя (в противном случае это ПС, вообще, не стоило создавать). Поэтому, хотя черновые варианты
(наброски) пользовательских документов создаются основными разработчиками ПС, к созданию их окончательных
вариантов часто привлекаются профессиональные технические писатели. Кроме того, для обеспечения качества
пользовательской документации разработан ряд стандартов, в которых предписывается порядок разработки этой
документации, формулируются требования к каждому виду пользовательских документов и определяются их структура и
содержание.
3. Документация по сопровождению программных средств.
Документация по сопровождению ПС (system documentation) описывает ПС с точки зрения ее разработки. Эта
документация необходима, если ПС предполагает изучение того, как оно устроена (сконструирована), и модернизацию его
программ. Как уже отмечалось, сопровождение - это продолжающаяся разработка. Поэтому в случае необходимости
модернизации ПС к этой работе привлекается специальная команда разработчиков-сопроводителей. Этой команде
придется иметь дело с такой же документацией, которая определяла деятельность команды первоначальных (основных)
разработчиков ПС, - с той лишь разницей, что эта документация для команды разработчиков-сопроводителей будет, как
правило, чужой (она создавалась другой командой). Чтобы понять строение и процесс разработки модернизируемого ПС,
команда разработчиков-сопроводителей должна изучить эту документацию, а затем внести в нее необходимые изменения,
повторяя в значительной степени технологические процессы, с помощью которых создавалось первоначальное ПС.
Документация по сопровождению ПС можно разбить на две группы:
1. документация, определяющая строение программ и структур данных ПС и технологию их разработки;
2. документацию, помогающую вносить изменения в ПС.
Документация первой группы содержит итоговые документы каждого технологического этапа разработки ПС. Она включает
следующие документы:
* Внешнее описание ПС (Requirements document).
* Описание архитектуры ПС (description of the system architecture), включая внешнюю спецификацию каждой ее программы
(подсистемы).
* Для каждой программы ПС - описание ее модульной структуры, включая внешнюю спецификацию каждого включенного в
нее модуля.
* Для каждого модуля - его спецификация и описание его строения (design description).
* Тексты модулей на выбранном языке программирования (program source code listings).
* Документы установления достоверности ПС (validation documents), описывающие, как устанавливалась достоверность
каждой программы ПС и как информация об установлении достоверности связывалась с требованиями к ПС.
Документы установления достоверности ПС включают, прежде всего, документацию по тестированию (схема тестирования
и описание комплекта тестов), но могут включать и результаты других видов проверки ПС, например, доказательства
свойств программ. Для обеспечения приемлемого качества этой документации полезно следовать общепринятым
рекомендациям и стандартам.
Документация второй группы содержит
* Руководство по сопровождению ПС (system maintenance guide), которое описывает особенности реализации ПС (в
частности, трудности, которые пришлось преодолевать) и как учтены возможности развития ПС в его строении
(конструкции). В нем также фиксируются, какие части ПС являются аппаратно- и программно-зависимыми.
Общая проблема сопровождения ПС - обеспечить, чтобы все его представления шли в ногу (оставались согласованными),
когда ПС изменяется. Чтобы этому помочь, связи и зависимости между документами и их частями должны быть отражены
в руководстве по сопровождению, и зафиксированы в базе данных управления конфигурацией.