1. Основные понятия объектно-ориентированного программирования.
Объектно-ориентированное программирование (ООП) родилось и
получило широкое распространение ввиду осознания трех важнейших
проблем программирования.
1. Развитие языков и методов программирования не успевало за
растущими с большей скоростью потребностями в программах. Единственным
методом ускорения разработки ПО оставался метод многократного
использования разработанных ранее модулей. Хотя процедурное
программирование предоставляло способ разработки функций, которые
могли служить блоками для построения программ, тем не менее ни гибкость
этого метода, ни масштабы его использования не позволяли существенно
ускорить массовое программирование.
2. Второй проблемой являлась необходимость упрощения
сопровождения и модификации разработанных систем, которые требуют не
меньших усилий, чем собственно разработка. Требовалось радикально
изменить способ построения программных систем, чтобы локальные
модификации не могли нарушать работоспособность всей системы и было бы
легче производить изменения поведения системы.
3. Далеко не все задачи поддаются алгоритмическому описанию и
алгоритмической декомпозиции, как того требует структурное
программирование. Требовалось приблизить структуру программ к структуре
решаемых задач и сократить семантический разрыв между структурой
решаемой задачи и структурой программы (т.е. понятия, лежащие в основе
языка задачи и средств ее решения различны). Поэтому при решении
требуется перевести одни понятия в другие.
Решение этих проблем в объектно-ориентированной технологии
выставлялось ее сторонниками как три основных достоинства технологии.
ОСНОВНЫЕ ПОНЯТИЯ ООП
ООП является методом программирования, имитирующим то, как
человек выполняет кaкую-либо работу. ООП - результат естественной
эволюции более ранних методологий программирования: оно более
структурировано и более модульное и абстрактное, чем традиционное
программирование. Эта технология является по существу прагматическим
воплощением к 1980 году идеи абстрактных типов данных как идеальной
основы в программной индустрии в наше время.
Считается, что первой полной реализацией абстрактных типов данных в
языках программирования является язык Симула, который опирался на
языки Модула, CLU, Euclid и др.
Появление объектно-ориентированного метода произошло на основе
всего предыдущего развития методов разработки ПО, а также других
отраслей науки (развитие вычислительной техники, построение
функционально и объектно-ориентированных операционных систем,
достижения в методологии программирования, развитие теории построения и
моделирования систем управления базами данных (построение отношений
между объектами), исследования в области систем с искусственным
интеллектом (теория фреймов) позволили лучше осознать механизмы
абстракции, развитие философии и теории познания, концепция образцов и
шаблонов теории архитектуры и строительства).
Семь основных признаков характеризуют объектно-ориентировaнную
технологию программирования:
1. ОБЪЕКТЫ. Базовым понятием в объектном подходе является
понятие КЛАССА объектов - такого множества предметов реального мира, что
все предметы в нем имеют одни и те же характеристики (данные) и правила
поведения (методы обработки данных). Тогда ОБЪЕКТ - это типичный
представитель (экземпляр, абстрактный представитель) своего класса.
2. ИНКАПСУЛЯЦИЯ. Данные скомбинированы и объединены с
процедурами и функциями, которые манипулируют этими данными, в единую
целостную структуру для получения нового типа данных - объекта.
3. НАСЛЕДОВАНИЕ. Это определение объекта и затем использование
его для построения иерархии производных объектов, причем каждый
производный объект ("потомок") наследует доступ к коду и данным всех
своих "прародителей". Создать новые классы можно наследуя уже
существующие (иерархическое наследование)
4. ОГРАНИЧЕНИЕ ДОСТУПА. При наследовании свойств базовых
классов часть методов и характеристик можно спрятать внутри реализации
класса, так что обратиться к этим характеристикам и методам можно будет
только из методов данного или производных от него классов.
5. ПОЛИМОРФИЗМ. Некоторому действию придается одно имя,
которое совместно используется объектами всей иерархии, причем каждый
объект иерархии реализует это действие своим собственным, подходящим
для него, образом.
6. АБСТРАГИРОВАНИЕ - создание абстрактных классов, имеющих не
реализованные методы, которые используют в качестве базовых классов для
образования других, имеющих тот же набор методов, но уже
переопределенных.
7. УСТОЙЧИВОСТЬ. Под устойчивостью понимают продолжительное
время существования объектов в системе. Это свойство реализуется в
основном в языках объектно-ориентированных баз данных.
ООП имеет свой собственный "арсенал" концепций, Это частично
обусловлено появлением ООП в (несколько замкнутой) сфере
исследовательских разработок, но в основном просто нетрадиционным и
новаторским характером ООП.
В ООП предпринимается попытка смоделировать компоненты проблемы
в едином целом, а не в качестве отдельных логических абстракций. Все
элементы, которые наполняют нашу жизнь, от тостеров и цветов, до
махровых полотенец, имеют свойства (данные или атрибуты) и типы
поведения (правила). Свойства тостера могут включать требуемое для его
работы напряжение, количество ломтиков, которое он зажаривает,
расположение кнопок на нем, цвет тостера, его марку и т.п. Типы его
поведения включают закладку ломтиков хлеба, поджаривание ломтиков
хлеба и выталкивание поджаренных кусочков.
Если мы хотим написать программу, имитирующую функционирование
кухни, то самым лучшим способом это сделать было бы моделирование
различных кухонных приспособлений в качестве объектов, чьи свойства и
типы поведения были бы закодированы в поля данных и правила. Так в
действительности и было сделано: самый первый объектно-ориентировaнный
язык (Simula-67) был создан для написания подобных прогрaмм-имитaторов.
Первым «настоящим» объектно-ориентированным языком
программирования принято считать Смолтолк, разработанный в лаборатории
компании Ксерокс. Затем появились и другие ОО языки (Си++, Паскаль,
CLOS, Эйффель, Java и др.).
В качестве критерия применимости ООП можно использовать
количество выделенных абстрактных типов с общими свойствами таких, что
эта общность может быть использована в механизме наследования свойств.
Однако поиск общих свойств среди типов далеко не тривиальный процесс.
Он требует от разработчика системного склада мышления. Во время
проектирования системы общность должна быть все время перед глазами,
как при спецификации классов, так и при анализе того, обладают ли классы
общими свойствами. Если общих свойств не находится, абстракция данных
теряет смысл. Снижается эффективность и применения ООП.
Лекция 3. ОБЪЕКТНО-ОРИЕНТИРОВАННЫЙ ПОДХОД В РАЗРАБОТКЕ
ПРОГРАММ
2. Объекты.
Предположим, нам надо описать яблоко в терминах программирования.
Первое, что вам, вероятно, захочется сделать, - разломить яблоко: пусть S
обозначает площадь кожицы; J - жидкий объем сока, который содержит
яблоко; F - вес фрукта, а D - количество семян...
Это неверный путь мышления. Надо думать как художник. Он видит
яблоко и рисует его. Рисунок яблока - это не яблоко, а символ, графическая
модель яблока на плоской поверхности. Но он не абстрагирован до
нескольких чисел, каждое из которых стоит отдельно и независимо в кaком-
либо сегменте данных. Его компоненты связаны в единое целое,
воспринимаемое нашим мозгом как яблоко.
Объекты моделируют свойства и поведение компонентов мира, в
котором мы живем. Они являются и конечной абстракцией данных. Объекты
связывают в единое целое свои свойства и поведение и обладают
спецификой целого. Яблоко может быть разломлено, но после этого оно
перестает быть яблоком. Отношения частей к целому и к другим частям
более ясны, когда все связано вместе в одной оболочке. Это называется
инкапсуляцией и представляет собой очень важное явление. Объекты -
части мира, они же и конечные абстракции в ООП. Объектно-
ориентированный подход предлагает описывать реальность в виде
взаимодействия объектов (например, «клиент Иванов», «банкомат
Агробанка», «счет № 1111», «корабль Геркулес», «автомобиль Петрова»).
Хотя из приведенных примеров интуитивно ясно, что такое объект,
дать его четкое и приемлемое для всех определение достаточно сложно.
Например,Гради Буч дает такое определение: «объект – это что-то, с чем можно
оперировать. У объекта есть состояние, поведение и возможность отличить
его от других объектов».
Якобсон пишет: « Объект – это сущность, способная сохранять свое
состояние (информацию) и обеспечивающая набор операций для проверки и
изменения этого состояния».
Можно сказать, что объект – это модель или абстракция реальной
сущности в программной системе. Предмет моделирования при построении
объекта может быть различным. Можно выделить несколько типов
абстракций, используемых при построении объекта:
абстракция понятия: объект – это модель какого-то понятия
предметной области;
абстракция действия: объект – это набор операций для
выполнения какой-либо функции;
абстракция виртуальной машины: объект объединяет операции,
которые используются другими, более высокими уровнями абстракции;
случайная абстракция: объект объединяет не связанные между
собой операции.
Таким образом, объект может быть получен из чего угодно. Однако
можно выделить следующие часто встречающиеся категории объектов:
1. РЕАЛЬНЫЕ ОБЪЕКТЫ - абстракции фактического существования
некоторых предметов в физическом мире (Труба, Насос, Бак, Самолет).
2. РОЛИ - абстракции цели или назначения человека, части
оборудования или организации (Студент, Изоляционный клапан,
Налогоплательщик, Избиратель)
3. ИНЦИДЕНТЫ - абстракция чего-то происшедшего или
случившегося (Несчастный случай, Землетрясение, Выборы, Поставка).
4. ВЗАИМОДЕЙСТВИЯ - объекты, получаемые из отношений между
другими объектами (Соединение, Контракт, Перекресток).
5. СПЕЦИФИКАЦИИ - используются для представления правил,
стандартов или критериев качества (например, Рецепт - правило для
приготовления определенного количества определенной пищи, в отличие от
порции этой самой пищи).
Не менее значимым является и тот факт, что объекты могут
наследовать свойства и поведение от того, что называют "объектами -
прародителями".
Объекты идентифицируются уникальным и значимым именем,
необходимым для корреляции его с другими объектами. Многие объектные
модели предлагают встроенные методы идентификации объектов. При
создании любого нового объекта ему присваивается уникальный
идентификатор, отличающийся от всех остальных имеющихся в системе
идентификаторов. Особое значение правильность идентификации объектов
приобретает в распределенных системах, в которых программы на разных
компьютерах независимо друг от друга в произвольное время создают и
уничтожают объекты.
Каждый объект характеризуется своим состоянием. Состояние объекта
определяется текущими значениями его атрибутов. Атрибутами могут быть
не только простые величины (числа, логические значения и т.п.), но и
сложные величины, объекты. Часть атрибутов объекта может изменяться,
часть – хранить неизменяемые значения.
Важнейшей характеристикой объекта является описание того, как он
может взаимодействовать с окружающим миром. Это описание называется
интерфейсом объекта. Принято считать, что объекты взаимодействуют между
собой с помощью сообщений. Принимая сообщение. Объект выполняет
соответствующее действие. Эти действия называются методами.
Интерфейс – это внешнее описание объекта. При разработке объекта
мы решаем вопрос, является ли данный атрибут информацией, необходимой
другим объектам- Если да, то необходимо объекту добавить метод, который
сообщает значение данного атрибута другим объектам. Этот метод и будет
составлять интерфейс объекта. Аналогично решается вопрос и с другими
атрибутами. Однако сами атрибуты могут не являться непосредственно
частью интерфейса. Тогда другие объекты могут обратиться к ним только
опосредованно, с помощью соответствующих методов.
Возможно, что для некоторых объектов разрешены любые операции с
некоторыми атрибутами, например, координатами графической фигуры. Мы
можем поместить эти атрибуты в интерфейс объекта. Тогда любые другие
объекты могут непосредственно изменять координаты, перемещая объект по
экрану. Фактически в таком случае интерфейс объекта состоит из методов
«сообщить значение х», «установить значение х», «сообщить значение у»,
«установить значение у».
Помимо интерфейса у объекта могут быть методы или атрибуты,
предназначенные только для использования в самом объекте. В этом случае
внутренняя структура объекта скрыта (свойство инкапсуляции данных).
Поэтому внутреннюю структуру объекта становится возможным изменять
независимо от других взаимодействующих с ним объектов.
Объектно-ориентированная программа состоит из набора объектов, у
каждого из которых есть свои атрибуты и методы. Объекты взаимодействуют
посредством сообщений. Проблема состоит в том, чтобы понять, какие
объекты нужны программе и какими свойствами и методами они должны
обладать.
Лекция 4. КЛАССЫ В ОБЪЕКТНО-ОРИЕНТИРОВАННОМ
ПРОГРАММИРОВАНИИ
1. Понятие класса. Виды классов и методов.
Понятие класса
Класс можно рассматривать как шаблон, по которому составляются
инструкции одни и те же для всех объектов. Самое полезное свойство этого
шаблона - единообразный способ организации всех характеристик объекта.
В объектно-ориентированной терминологии шаблон, на котором
основаны похожие объекты называется классом. Когда программа создает
объект какого-либо класса, она указывает значения его атрибутов. Затем
объект может пользоваться методами, написанными для его класса. Все
объекты одного и того же класса имеют идентичный набор методов. Типы их
внутренних данных также одинаковы, но значения могут различаться, как
различаются, скажем, имена людей.
Класс является также и типом данных. Фактически класс - это
реализация абстрактного типа данных, то есть другое название типа данных,
определяемого пользователем. Поскольку класс - это тип данных, его можно
использовать в качестве типа атрибута.
Предположим, к примеру, что вы разрабатываете класс для обработки
данных о служащих своей организации. В состав атрибутов такого класса
может входить идентификатор служащего, его имя, фамилия и адрес. Адрес
же состоит из почтового индекса и названия улицы, города, штата. Поэтому
было бы разумно создать класс с такими атрибутами и вместо того, чтобы
дублировать их в классе служащего, просто указать, что объект класса
служащего включает в себя объект другого класса, с помощью которого
представляется адрес служащего.
Виды классов
В объектно-ориентированной программе встречаются классы трех
основных видов:
- управляющие классы (Control classes). Они не занимаются
обработкой данных и не продуцируют видимого результата. Вместо этого они
управляют ходом выполнения программы. Например, классы приложения
представляют саму программу. В большинстве случаев каждая программа
создает ровно один класс приложения. В его задачи входит запуск
программы, обнаружение факта выбора из меню и выполнение кода
программы в соответствии с запросами пользователя;
- предметные классы (Entity classes). Они используются для создания
объектов, занимающихся обработкой данных. Например, класс Счет
относится к предметным. Классы, представляющие людей, материальные
объекты и события (например, деловые совещания) являются предметными.
В большинстве объектно-ориентированных программ есть хотя бы один
предметный класс, по которому создаются объекты. На самом деле в
простейшем случае объектно-ориентированная модель данных строится из
представления связей между объектами, созданными на основе предметных
классов.
- интерфейсные классы (Interface classes). Они занимаются вводом и
выводом информации. Например, при работе с графическим
пользовательским интерфейсом, то каждое окно или меню, встречающееся в
программе, является объектом интерфейсного класса.
В объектно-ориентированной программе предметные классы не
выполняют собственно ввод и вывод. Ввод с клавиатуры обеспечивают
интерфейсные объекты. Они принимают данные и посылают их предметным
объектам для хранения и обработки. Вывод на экран или печать
форматируются интерфейсными объектами, получающими данные от других.
Почему необходимо отделять манипулирование данными от ввода/вывода.
Не проще было бы, поручить предметному объекту самому управлять
вводом/выводом. Может быть, и проще, но тогда, если вы решите изменить
размещение информации на экране, придется модифицировать весь
предметный класс. А при разделении обязанностей процедуры
манипулирования данными не зависят от способа их ввода и вывода, так что
перестроить их можно независимо друг от друга. В большой программе это
поможет не только сэкономить массу времени, но и избежать ошибок.
Во многих объектно-ориентированных программах используется еще
четвертый вид классов
- контейнерный (Container classes). Контейнерные классы служат
вместилищем нескольких объектов одного и того же класса. Поскольку они
собирают объекты вместе, иногда их называют также агрегатами.
Контейнерный класс отвечал бы за хранение объектов в определенном
порядке, их перебор и, возможно, поиск. Они предоставляют доступ ко всем
объектам одного и того же класса.
Виды методов
В классах используются следующие виды методов:
- конструктор (Constructor) - метод, имя которого совпадает с именем
класса. Он выполняется при создании объекта. Поэтому конструктор обычно
содержит инструкции по инициализации переменных объекта;
- деструктор (Destructor) - метод, выполняемый при уничтожении
объекта. Не во всех объектно-ориентированных языках есть деструкторы.
Обычно они применяются для освобождения системных ресурсов - например,
оперативной памяти, - занимаемых объектом;
- методы чтения (Accessors) - еще их называют get-методами -
возвращают значение закрытого атрибута объекта. Именно так внешние
объекты обычно получают доступ к инкапсулированным данным.
- методы изменения (Mutators), set-методы, устанавливают новое
значение атрибута. Таким образом, внешние объекты изменяют
инкапсулированные данные.
Прочие методы, определенные в классе, зависят от назначения класса,
то есть от действий, которые он призван выполнять.
Лекция 4. КЛАССЫ В ОБЪЕКТНО-ОРИЕНТИРОВАННОМ
ПРОГРАММИРОВАНИИ
2. Перегрузка классов и методов. Именование классов,
атрибутов и методов.
Перегрузка классов и методов
Одной из характерных особенностей класса является возможность
определять в нем перегруженные методы, то есть методы с одним и тем же
именем, но разными входными данными. Поскольку типы данных различны,
то различен и открытый интерфейс таких методов.
Предположим, что в программе кадрового учета есть контейнерный
класс с именем AllEmployees, агрегирующий все объекты класса Employee
(Служащий). Программы, пользующиеся классом AllEmployees, создают один
объект этого класса, а затем ассоциируют с ним все объекты,
представляющие служащих, применяя ту или иную структуру данных
(например, массив, связанный список или двоичное дерево).
Чтобы наличие контейнерного класса имело смысл, должен
существовать какой-то способ искать в нем конкретные объекты. Возможно,
вам понадобится поиск по идентификатору служащего, по имени и фамилии
либо по номеру телефона. Поэтому класс AllEmployees содержит три метода с
именем find. Одному из них передается целое число (код служащего),
второму - две строки (имя и фамилия), а третьему - одна строка (номер
телефона). Хотя все методы названы одинаково, но их открытые интерфейсы
различны, поскольку разграничены комбинации имени и типов входных
данных.
У многих классов есть перегруженные конструкторы. Один может
запрашивать у пользователя ввод интерактивно, другой - читать из файла,
третий - получать входные данные, копируя их из другого объекта
(копирующий конструктор). Например, в большинстве объектно-
ориентированных сред имеется класс Date, поддерживающий инициализацию
объекта даты строкой, другим объектом Date и т.д.
Преимущество перегрузки методов в том, что программисту
предоставляется единообразный интерфейс. Если необходимо найти
служащего, то программист знает, что надо применить метод find. А тогда
остается лишь воспользоваться тем из трех методов, который больше всего
подходит в данной ситуации. Объектно-ориентированная программа отыщет
нужный метод по его открытому интерфейсу (сигнатуре), составленному из
имени и типов входных данных.
Именование классов, атрибутов и методов
В объектно-ориентированном программировании имеется несколько
соглашений об именовании. Хотя никто не заставляет вас называть свои
классы, атрибуты и методы именно так, а не иначе, следование
общепринятым правилам обеспечит взаимопонимание с другими
программистами и проектировщиками баз данных:
- имена классов начинаются с заглавной буквы, за которой следуют
строчные. Если имя класса состоит из нескольких слов, то они разделяются
либо символом подчеркивания, например Merchandise_item, либо
внутренними заглавными буквами, например Merchandiseltem;
- имена атрибутов и методов начинаются со строчной буквы и могут
содержать заглавные или строчные буквы, а также цифры. Если имя
атрибута или метода состоит из нескольких слов, то они разделяются либо
символом подчеркивания, например product_numb или display_label, либо -
внутренними заглавными буквами, например productNumb или displayLabel;
- имена методов чтения начинаются со слова get, а за ним следует имя
атрибута, значение которого считывается. Например, метод для получения
номера изделия будет называться getProductNumber;
- имена методов изменения начинаются со слова set, а после него
пишется имя атрибута, значение которого изменяется, например
setProductNumber.
Лекция 4. КЛАССЫ В ОБЪЕКТНО-ОРИЕНТИРОВАННОМ
ПРОГРАММИРОВАНИИ
3. Основные средства разработки классов.
Наследование
По мере разработки объектно-ориентированной программы вы часто
будете сталкиваться с ситуациями, когда нужны похожие, но не в точности
одинаковые классы. Если эти классы обладают неким общим поведением, то
можно воспользоваться одним из основных свойств объектно-
ориентированной парадигмы - наследованием.
Наследование атрибутов
Рассмотрим наследование на примере программы для управления
зоомагазином. Одним из предметных классов будет класс Животное для
представления любого животного из тех, которыми торгует магазин. Среди
данных, описывающих объекты класса Животное, будут русское и латинское
названия животного, его возраст и пол. Однако подбор остальных сведений
уже зависит от конкретного вида животного. Так, важная информация о
рептилиях - длина, а о млекопитающих - вес. Ни вес, ни длина рыб не
представляют интереса, однако важен цвет. В описаниях всех животных,
которые продаются в магазине, есть некоторые общие данные, а также
данные, специфичные для конкретных подгрупп.
Эти связи можно представить на диаграмме (см. рис.4.1). Класс
Животное содержит данные, общие для всех видов животных. Подгруппы -
Млекопитающее, Рептилия и Рыба - добавляют к этому классу специфичную
информацию. Повторять в них общие данные необязательно, так как они
наследуются от класса Животное. Другими словами, классы Млекопитающее,
Рептилия и Рыба включают и те четыре атрибута, которые определены в
классе Животное.
Если вы внимательно посмотрите на рис. 4.1, то заметите, что линии
направлены от подгрупп к классу Животное. Это вроде бы противоречит
реальному положению дел, ведь данные из класса Животное
распространяются вниз к подгруппам. Такое направление стрелок диктуется
принятым соглашением, хотя это и противоречит интуиции.
В объектно-ориентированной терминологии подгруппы называются
подклассами или производными классами. Класс Животное является по
отношению к ним суперклассом, или базовым классом. Для усвоения понятия
наследования надо помнить, что подклассы являются специализациями
суперкласса. Таким образом, отношение между базовым и Производным
классом можно выразить словом «является»:
- млекопитающее является животным;
- рептилия является животным;
- рыба является животным.
Рис.4.1. Связи между классами в программе для зоомагазина
Если слово «является» неадекватно описывает ситуацию, то вы имеете
дело не с наследованием. Предположим, к примеру, что вы пишете
программу для учета оборудования в пункте проката лыж. Вы создаете класс
для товара общего вида и его подклассы для представления конкретных
типов сдаваемых напрокат товаров, как показано в первых четырех
прямоугольниках на рис. 4.2. Наследование здесь вполне применимо,
поскольку и лыжи, и ботинки, и палки являются частными случаями товара.
Рис.4. 2. Наследование и отсутствие наследования в программе для
пункта проката лыж.
Однако, когда вы переходите к рассмотрению товаров и клиентов,
берущих их в аренду, возникают проблемы. Хотя между арендатором и
товаром существует непосредственная связь, это не наследование: ведь
словом «является» ее не описать. Взятый напрокат товар не является
арендатором!
Ситуация с товарами и сдаваемым напрокат инвентарем сложнее.
Классы Инвентарь, Лыжи, Ботинки и Палки описывают типы товаров, но не
материальные предметы. Например, в пункте проката может быть много пар
однотипных лыж и много пар ботинок одной модели и размера. Поэтому
конкретный сдаваемый напрокат предмет описывается классом Предмет
проката.
Предметом проката могут быть лыжи, ботинки или палки. Это может
быть только один предмет, а не три, как показано на рис 4.2. Поэтому
предмет проката – это не пара лыж, не пара ботинок, и не пара палок.
(Кстати, проблема еще и в том, что нет класса, который содержал бы
информацию о размере и/или длине предмета.)
Рис. 4.3. Множественное наследование в программе для пункта проката
лыж.
Одно из возможных решений состоит в том, чтобы создать отдельный
класс предмета проката для каждого типа товара, как показано на рис. 4.3.
Обратите внимание на направление стрелок. Физическое расположение
элементов на диаграмме не соответствует направлению наследования.
Помните, что по соглашению стрелки направлены от производного класса к
базовому.
Класс Пара лыж наследует информацию о типе предмета от класса
Лыжи. Он также получает данные о сдаваемом напрокат предмете от класса
Предмет проката. Объект класса Пара лыж отражает пару лыж, а также
сдаваемый напрокат предмет.
В таком виде структура классов проходит тест на соответствие
отношению «является» и, стало быть, удовлетворяет условиям правильного
наследования. (Необходимо отметить, что попутно вы получили класс,
содержащий такую информацию, как длина и размер инвентаря.) Класс
Арендатор вообще не принимает участия в иерархии наследования.
В таком виде структура классов проходит тест на соответствие
отношению «является» и, стало быть, удовлетворяет условиям правильного
наследования. (Необходимо отметить, что попутно вы получили класс,
содержащий такую информацию, как длина и размер инвентаря.) Класс
Арендатор вообще не принимает участия в иерархии наследования.
Множественное наследование
Когда некий класс наследует информацию более чем одного базового
класса, следует говорить о множественном наследовании. Различные языки
программирования и СУБД поддерживают множественное наследование в
разной степени.
Не каждый класс в иерархии наследования непременно используется
для создания объектов. Например, маловероятно, что будут создаваться
объекты класса Инвентарь или Предмет проката (см. рис. 4.3). Эти классы
присутствуют только для того, чтобы предоставить общий набор атрибутов и
методов своим производным классам. Такого рода классы называются
абстрактными или виртуальными. Напротив, классы, из которых создаются
объекты, называются конкретными.
Интерфейсы
Некоторые объектно-ориентированные языки (прежде всего Java) не
поддерживают множественного наследования. Они допускают наличие
только одного базового класса, но зато разрешают реализовывать разные
интерфейсы.
Интерфейс (Interface) - это спецификация класса, методы которого не
хранят никакого кода. Другими словами, в классе определены сигнатуры
всех методов, но нет их реализации. Предоставить осуществление каждого
метода входит в обязанности класса, реализующего интерфейс. Последний
может содержать методы и атрибуты или только методы или только атрибуты.
В большинстве случае интерфейс проектируется для того, чтобы
придать классу дополнительную функциональность. Например, если бы
иерархию, изображенную на рис. 4.3, нужно было использовать в среде, не
поддерживающей множественное наследование, то класс Пара ботинок мог
бы наследовать классу Ботинки и реализовывать интерфейс Предмет
проката. В последнем были бы атрибуты, описывающие прокат инвентаря, а
также методы, необходимые для выдачи, вычисления арендной платы и
времени возврата арендованного инвентаря. Любой класс, представляющий
инвентарь, должен был бы реализовать этот интерфейс, описав тем самым
поведение, которым должен обладать сдаваемый напрокат объект.
Полиморфизм
В общем случае методы наследуются подклассами от своих
суперклассов. Подкласс может применять методы базового класса как свои
собственные. Однако иногда невозможно написать метод, достаточно общий
для использования всеми подклассами. Предположим, например, что класс
Инвентарь из предыдущего примера имеет метод printCatalogEntry.
предназначенный для красивой печати каталожного описания одного вида
товаров. Но одни подклассы класса Инвентарь имеют атрибуты,
отсутствующие в других подклассах, поэтому метод printCatalogEntry по-
разному реализуется в каждом подклассе.
Для решения этой проблемы можно воспользоваться преимуществами,
которые дает полиморфизм (Polymorphism), а именно возможностью иметь
разные тела у методов с одним и тем же именем, но принадлежащих
различным классам в одной иерархии наследования. Класс Инвентарь
включает в себя прототип метода printCatalogEntry, который лишь описывает
его открытый интерфейс. В этом классе у метода нет тела, то есть не
сказано, какие конкретные действия он должен выполнить (такой метод
называется абстрактным). В каждом подклассе он переопределяется -
пишется необходимый код.
Удобство полиморфизма в том, что программист может ожидать наличия
методов с одним и тем же именем и семантикой выполняемой процедуры во
всех подклассах одного и того же базового класса. Но при этом каждый
подкласс может выполнять операцию так, как ему нужно. Инкапсуляция
скрывает детали реализации от всех объектов вне данной иерархии.
Очень легко спутать полиморфизм с перегрузкой. Надо помнить, что
перегрузка относится к методам одного и того же класса, имеющим одно имя,
но разные сигнатуры, тогда как полиморфизм применим к разным подклассам
одного базового класса, в которых есть методы с одинаковой сигнатурой, но
разной реализацией.
Лекция 5. ОТЛАДКА, ТЕСТИРОВАНИЕ И ДОКУМЕНТИРОВАНИЕ
ПРОГРАММ
5.1. Виды и принципы отладки программного средства (ПС).
Отладка ПС - деятельность по обнаружению и исправлению ошибок в
ПС с использованием процессов выполнения его программ.
Тестирование ПС - процесс выполнения его программ на некотором
наборе данных, для которого заранее известен результат применения или
известны правила поведения этих программ.
Этот набор данных называется тестовым или просто тестом.
Отладка = Тестирование + Поиск ошибок + Редактирование.
Виды ПС.
Задачи отладки программных средств.
1. Подготовить такой набор тестов и применить к ним ПС, чтобы
обнаружить в нем по возможности большее число ошибок.
2. Определить момент окончания отладки ПС (или отдельной его
компоненты).
Для оптимизации набора тестов, необходимо заранее планировать этот
набор и использовать рациональную стратегию планирования тестов.
Проектирование тестов можно начинать сразу же после завершения этапа
внешнего описания ПС. Возможны разные подходы к выработке стратегии
проектирования тестов, которые можно условно графически разместить (см.
рис. 5.1) между следующими двумя крайними подходами.
Рис. 5.1. Спектр подходов к проектированию тестов.
Оптимальная стратегия проектирования тестов расположена внутри
интервала между этими крайними подходами, но ближе к левому краю.
При этом в первом случае эта стратегия базируется на принципах:
на каждую используемую функцию или возможность - хотя бы
один тест,
на каждую область и на каждую границу изменения какой-либо
входной величины - хотя бы один тест,
на каждую особую (исключительную) ситуацию, указанную в
спецификациях, - хотя бы один тест.
Во втором случае эта стратегия базируется на принципе: каждая
команда каждой программы ПС должна проработать хотя бы на одном тесте.
В нашей стране различаются два основных вида отладки (включая
тестирование):
Автономная отладка ПС - последовательное раздельное тестирование
различных частей программ с поиском и исправлением в них фиксируемых
при тестировании ошибок. Комплексная отладка - тестирование ПС в целом с
поиском и исправлением фиксируемых при тестировании ошибок во всех
документах.
Принципы отладки ПС
Отметим феномен - по мере роста числа обнаруженных и исправленных
ошибок в ПС растет также относительная вероятность существования в нем
необнаруженных ошибок.
Принцип 1. Считайте тестирование ключевой задачей разработки ПС,
поручайте его самым квалифицированным и одаренным программистам;
нежелательно тестировать свою собственную программу.
Принцип 2. Хорош тот тест, для которого высока вероятность
обнаружить ошибку, а не тот, который демонстрирует правильную работу
программы.
Принцип 3. Готовьте тесты как для правильных, так и для
неправильных данных.
Принцип 4. Документируйте пропуск тестов через компьютер; детально
изучайте результаты каждого теста; избегайте тестов, пропуск которых
нельзя повторить.
Принцип 5. Каждый модуль подключайте к программе только один раз;
никогда не изменяйте программу, чтобы облегчить ее тестирование.
Принцип 6. Пропускайте заново все тесты, связанные с проверкой
работы какой-либо программы ПС или ее взаимодействия с другими
программами, если в нее были внесены изменения (например, в результате
устранения ошибки).
Лекция 5. ОТЛАДКА, ТЕСТИРОВАНИЕ И ДОКУМЕНТИРОВАНИЕ
ПРОГРАММ
5.2. Автономная отладка ПС.
При автономной отладке тестируется всегда некоторая программа
(тестируемая программа), построенная специально для тестирования
отлаживаемого модуля. В процессе автономной отладки ПС производится
наращивание тестируемой программы отлаженными модулями (интеграция
программы).
При восходящем тестировании окружение содержит только один
отладочный модуль, головной в тестируемой программе - ведущий (или
драйвер). Ведущий отладочный модуль подготавливает информационную
среду для тестирования отлаживаемого модуля, осуществляет обращение к
отлаживаемому модулю и выдает необходимые сообщения.
При нисходящем тестировании окружение в качестве отладочных
содержит отладочные имитаторы (заглушки) некоторых еще не отлаженных
модулей. Некоторые из этих имитаторов при отладке одного модуля могут
изменяться для разных тестов.
На практике в окружении отлаживаемого модуля могут содержаться
отладочные модули обоих типов, если используется смешанная стратегия
тестирования.
Достоинства восходящего тестирования:
1) простота подготовки тестов,
2) возможность полной реализации плана тестирования модуля.
Недостатки восходящего тестирования:
1) тестовые данные готовятся, как правило, не в той форме, которая
рассчитана на пользователя;
2) большой объем отладочного программирования;
3) необходимость специального тестирования сопряжения модулей.
Достоинства нисходящего тестирования:
1) большинство тестов готовится в форме, рассчитанной на
пользователя;
2) во многих случаях относительно небольшой объем отладочного
программирования;
3) отпадает необходимость тестирования сопряжения модулей.
Недостатком нисходящего тестирования: является то, что тестовое
состояние информационной среды перед обращением к отлаживаемому
модулю готовится косвенно - оно является результатом применения уже
отлаженных модулей к тестовым данным или данным, выдаваемым
имитаторами.
Прежде всего, необходимо организовать отладку программы таким
образом, чтобы как можно раньше были отлажены модули, осуществляющие
ввод данных. Пока модули, осуществляющие ввод данных, не отлажены,
тестовые данные поставляются некоторыми имитаторами: они либо
включаются в имитатор как его часть, либо вводятся этим имитатором.
При нисходящем тестировании некоторые состояния информационной
среды, при которых требуется тестировать отлаживаемый модуль, могут не
возникать при выполнении отлаживаемой программы ни при каких входных
данных. Чаще же пользуются модифицированным вариантом нисходящего
тестирования, при котором отлаживаемые модули перед их интеграцией
предварительно тестируются отдельно. Однако, представляется более
целесообразной другая модификация нисходящего тестирования: после
завершения нисходящего тестирования отлаживаемого модуля для
достижимых тестовых состояний информационной среды следует его
отдельно протестировать для остальных требуемых состояний
информационной среды.
Часто применяют также комбинацию восходящего и нисходящего
тестирования, которую называют методом сандвича. Сущность этого метода
заключается в одновременном осуществлении как восходящего, так и
нисходящего тестирования, пока эти два процесса тестирования не
встретятся на каком-либо модуле где-то в середине структуры отлаживаемой
программы.
Весьма важным при автономной отладке является тестирование
сопряжения модулей.
При нисходящем тестировании тестирование сопряжения
осуществляется попутно каждым пропускаемым тестом, что считают
достоинством нисходящего тестирования.
При восходящем тестировании обращение к отлаживаемому модулю
производится не из модулей отлаживаемой программы, а из ведущего
отладочного модуля.
Автономное тестирование модуля целесообразно осуществлять в четыре
последовательно выполняемых шага.
Шаг 1. На основании спецификации отлаживаемого модуля подготовьте
тесты для каждой возможности и каждой ситуации, для каждой границы
областей допустимых значений всех входных данных, для каждой области
изменения данных, для каждой области недопустимых значений всех
входных данных и каждого недопустимого условия.
Шаг 2. Проверьте текст модуля, чтобы убедиться, что каждое
направление любого разветвления будет пройдено хотя бы на одном тесте.
Добавьте недостающие тесты.
Шаг 3. Проверьте текст модуля, чтобы убедиться, что для каждого
цикла существуют тесты, обеспечивающие, по крайней мере, три следующие
ситуации: тело цикла не выполняется ни разу, тело цикла выполняется один
раз и тело цикла выполняется максимальное число раз. Добавьте
недостающие тесты.
Шаг 4. Проверьте текст модуля, чтобы убедиться, что существуют
тесты, проверяющие чувствительность к отдельным особым значениям
входных данных. Добавьте недостающие тесты.
Лекция 5. ОТЛАДКА, ТЕСТИРОВАНИЕ И ДОКУМЕНТИРОВАНИЕ
ПРОГРАММ
5.3. Комплексная отладка ПС. Организация тестирования в
объектно-ориентированных системах.
Комплексная отладка ПС
Тестирование при комплексной отладке - применение ПС к
конкретным данным, которые могут возникнуть у пользователя, но,
возможно, в моделируемой (а не в реальной) среде.
Тестирование архитектуры ПС. Целью тестирования является поиск
несоответствия между описанием архитектуры и совокупностью программ ПС.
К моменту начала тестирования архитектуры ПС должна быть уже закончена
автономная отладка каждой подсистемы.
Тестирование внешних функций. Целью тестирования является поиск
расхождений между функциональной спецификацией и совокупностью
программ ПС. Несмотря на то, что все эти программы автономно уже
отлажены, указанные расхождения могут быть,
Тестирование качества ПС. Целью тестирования является поиск
нарушений требований качества, сформулированных в спецификации
качества ПС. Завершенность ПС проверяется уже при тестировании внешних
функций.
Тестирование документации по применению ПС. Целью тестирования
является поиск несогласованности документации по применению и
совокупностью программ ПС, а также выявление неудобств, возникающих
при применении ПС. Этот этап непосредственно предшествует подключению
пользователя к завершению разработки ПС (тестированию определения
требований к ПС и аттестации ПС).
Тестирование определения требований к ПС. Целью тестирования
является выяснение, в какой мере ПС не соответствует предъявленному
определению требований к нему. Особенность этого вида тестирования
заключается в том, что его осуществляет организация-покупатель или
организация-пользователь. Обычно производится с помощью контрольных
задач - типовых задач, для которых известен результат решения.
Тестирования в объектно-ориентированных системах.
Тестирование является достаточно независимым процессом,
применимым к программному обеспечению, разработанному с помощью
любого метода проектирования. Тем не менее объектно-ориентированный
подход привносит свои особенности.
Традиционно тестирование делится на тестирование элементов,
интеграционное тестирование и системное тестирование.
На уровне элементов тестирование объектно-ориентированных
программ отличается по следующим показателям:
определение единиц тестирования;
тестирование наследования;
тестирование полиморфизма.
Естественной единицей тестирования является класс. Разбиение его на
более мелкие элементы (методы) нецелесообразно, поскольку они не
существуют отдельно от классов. Иногда за единицу тестирования
принимается тесно связанная группа классов.
Тестирование наследования состоит в тестировании методов,
унаследованных классом от своего базового класса. Если базовый класс уже
прошел тестирование, нужно ли повторять тестирование для унаследованных
методов- Вопреки достаточно распространенным надеждам программистов
перетестирование необходимо. Основная причина та, что методы
выполняются в новом контексте.
Применимость тестовых сценариев базового класса для тестирования
производного класса зависит от того, является ли наследование
классификацией. Если нет, то даже для унаследованных методов необходимо
разрабатывать новые тестовые сценарии.
Тестирование полиморфизма сходно с тестированием наследования в
том, что в тестовых сценариях необходимо предусмотреть все варианты
связывания, т.е. все варианты конкретной реализации полиморфизма.
Интеграционное тестирование представляет собой тестирование того,
как отдельные элементы программы работают вместе. Свойства объектно-
ориентированных языков исключают целый ряд возможных ошибок, прежде
всего за счет строгого определения внешних интерфейсов классов и
объектов. Однако это не означает, что интеграционное тестирование
становится легче. Планирование интеграционного тестирования немного
отличается.
При традиционном тестировании имеется такая характеристика, как
степень покрытия кода. При тестировании по принципу открытого, или
белого ящика (т.е. в случае, когда тестирующему известна структура кода)
необходимо обеспечить прохождение управления по всем ответвлениям
программы. Иными словами, требуется выполнить как можно больший
процент инструкций, имеющихся в программе. Наряду с этой
характеристикой планирование тестов для объектно-ориентированной
программы должно включать «покрытие состояний».
То, что объект соединяет в себе состояние и поведение, обусловливает
необходимость проверки всех возможных переходов из состояния в
состояние. В планировании таких тестов должна помочь модель состояний
класса, построенная на этапе анализа и проектирования.
Системное тестирование проверяет всю программную систему целиком
и строится в большинстве случаев по принципу «черного ящика».
Тестирующий знает только внешние характеристики системы, но не знает,
как она работает.
Построение требований к системе в форме вариантов использования
обеспечивает естественный и простой способ планирования системного
тестирования. Фактически система вариантов использования становится
основой плана тестов на этапе системного тестирования.
Лекция 6. ОРГАНИЗАЦИЯ РАЗРАБОТКИ ПРОГРАММНЫХ СИСТЕМ
6.1. Назначение, структура управления разработкой ПС и его
основные процессы.
Управление разработкой ПС (software management) – это деятельность,
направленная на обеспечение необходимых условий для работы коллектива
разработчиков ПС, на планирование и контроль деятельности этого
коллектива с целью обеспечения требуемого качества ПС, выполнения
сроков и бюджета разработки ПС. Финальной частью этой деятельности
является организация и проведения аттестации (сертификации) ПС, которой
завершается стадия разработки ПС.
Выделим общие процессы по управлению разработкой ПС:
составление плана-проспекта по разработке ПС;
планирование и составление расписаний по разработке ПС;
управление издержками по разработке ПС;
текущий контроль и документирование деятельности коллектива
по разработке ПС.
подбор и оценка персонала коллектива разработчиков ПС.
Составление плана-проспекта по разработке ПС включает
формулирование предложений о том, как выполнять разработку ПС.
Прежде всего, должно быть зафиксировано, для кого разрабатывается
ПС:
для внешнего заказчика,
для других подразделений той же организации,
или является инициативной внутренней разработкой.
В плане-проспекте должны быть установлены общие очертания работ
по создания ПС и оценена стоимость разработки, а также предоставляемые
для разработки ПС материально-финансовые ресурсы и временные
ограничения.
Планирование и составление расписаний по разработке ПС – это
деятельность, связанная с распределением работ между исполнителями и по
времени их выполнения в рамках намеченных сроков и имеющихся ресурсов.
Управление издержками по разработке ПС – это деятельность,
направленная на обеспечение подходящей стоимости разработки в рамках
выделенного бюджета. Она включает оценивание стоимости разработки
проекта в целом или отдельных его частей, контроль выполнения бюджета,
выбор подходящих вариантов расходования бюджета. Эта деятельность тесно
связана с планированием и составлением расписаний в течение всего
периода выполнения проекта.
Основными источниками издержек являются:
затраты на аппаратное оборудование (hardware);
затраты на вербовку и обучение персонала;
затраты на оплату труда разработчиков.
Текущий контроль и документирование деятельности коллектива по
разработке ПС – это непрерывный процесс слежения за ходом развития
проекта, сравнения действительных состояния и издержек с
запланированными, а также документирования различных аспектов развития
проекта. Этот процесс помогает вовремя обнаружить затруднения и
предсказать возможные проблемы в развитии проекта.
Подбор и оценка персонала коллектива разработчиков ПС – это
деятельность, связанная с формированием коллектива разработчиков ПС.
Структура управления разработкой ПС.
Разработка ПС обычно производится в организации, в которой
одновременно могут вестись разработки ряда других программных средств.
Для управления всеми этими программными проектами используется
иерархическая структура управления.
Во главе этой иерархии находится директор (или вице-президент)
программистской организации, отвечающий за управление всеми
разработками программных средств.
Менеджер сферы разработок отвечает за управление разработками
программных средств (систем) определенного типа, например, программные
системы в сфере бизнеса, экспертные системы, программные инструменты и
инструментальные системы, поддерживающие процессы разработки
программных средств, и другие. Ему непосредственно подчинены менеджеры
проектов, относящихся к его сфере.
По каждому программному проекту назначается свой менеджер,
который управляет развитием этого проекта. Ему непосредственно
подчинены лидеры бригад разработчиков. Менеджер проекта осуществляет
планирование и составление расписаний работы этих бригад по разработке
соответствующего ПС (см. следующий раздел).
Обычно большой проект разбивается на несколько относительно
независимых подпроектов таким образом, чтобы каждый подпроект мог быть
выполнен отдельной небольшой бригадой разработчиков.
Наиболее употребительны три подхода к организации бригад
разработчиков:
обычные бригады,
неформальные демократические бригады,
бригады ведущего программиста.
Существенную роль в управлении качеством ПС играют программные
(софтверные) стандарты. Они фиксируют удачный опыт высоко
квалифицированных специалистов по разработке ПС для различных их
классов и для разных моделей их качества.
Различают два вида таких стандартов:
стандарты ПС (программного продукта),
стандарты процесса создания и использования ПС.
Уже отмечалось, что эти стандарты могут быть как международными
или национальными, так и специально созданными для организации, в
которой ведется разработка ПС. Разработка последних стандартов является
одной из функций управления обеспечением качества ПС.
Бригада по контролю качества состоит из ассистентов (рецензентов) по
качеству ПС. Она проводит смотры тех или иных частей ПС или всего ПС в
целом с целью поиска возникающих проблем в процессе его разработки.
Лекция 6. ОРГАНИЗАЦИЯ РАЗРАБОТКИ ПРОГРАММНЫХ СИСТЕМ
6.2. Управление качеством, аттестация и характеристика
методов оценки качества ПС.
Управление качеством ПС.
Планирование и составление расписаний по разработке ПС
представляет собой итеративный процесс, который заканчивается только
после прекращения работ по самому программному проекту.
В начале этого описания оцениваются общий срок разработки ПС,
используемые штаты исполнителей, предельный бюджет и другие
ограничения (условия) разработки. Должны быть также определены “вехи
развития проекта” и их сроки.
Веха развития проекта (project progress milestone) – это конечная точка
некоторого этапа или процесса, с которой связывается выдача некоторого
промежуточного продукта, представляющего собой некоторый четко
определенный документ.
Далее начинается итерационный процесс, основу которого составляет
повторяющиеся составления расписаний.
Составление расписания заключается:
в разделении всей работы, необходимой для выполнения проекта,
на отдельные самостоятельно выполняемые задания;
в составлении сетевого графика выполнения заданий;
в составлении гистограммы выполнения заданий;
в расстановке исполнителей заданий.
При выделении самостоятельных заданий для каждого из них
оценивается время его выполнения и его зависимость от других заданий с
точки зрения порядка выполнения. Сетевой график представляет собой
схему (сеть) путей выполнения заданий с указанием времени выполнения
каждого задания и с расстановкой вех развития проекта. В сетевом графике
должен быть определен критический путь, представляющий собой такой путь
заданий, суммарное время выполнения которых является наибольшим.
Гистограмма выполнения заданий (activity bar chart) содержит для каждого
задания свою временн-ю полосу от момента, когда выполнение этого задания
может быть начато, и до момента, когда выполнение этого задания должно
быть закончено.
Спустя некоторое время (обычно 2-3 недели) после активизации
процессов, указанных в расписании, производится обозрение (просмотр)
хода развития проекта и отмечаются возникшие противоречия. С учетом
этого производится пересмотр (уточнение) параметров проекта и
оценивается влияние измененных параметров на расписание проекта. В том
случае, когда заказчик не может пойти на подходящие изменения,
производится технический пересмотр проекта с целью поиска
альтернативных подходов к разработке ПС.
Аттестации ПС.
Завершающим этапом разработки ПС - аттестация (certification) ПС -
авторитетное подтверждение качества ПС.
Аттестационная комиссия проводит приемо-сдаточные испытания ПС с
целью получения необходимой информации для оценки его качества.
Под испытанием ПС - процесс проведения комплекса мероприятий,
исследующих пригодность ПС для успешной его эксплуатации (применения и
сопровождения) в соответствии с требованиями заказчика. На основе
полученной информации комиссия должна установить, в какой степени ПС
выполняет декларированные функции и в какой степени ПС обладает
декларированными примитивами и критериями качества. Решение
аттестационной комиссии о произведенной оценке качества ПС фиксируется
в соответствующем документе (сертификате), который подписывается
членами комиссии. Таким образом, оценка качества ПС является основным
содержанием процесса аттестации.
Различают следующие группы методов оценки примитивов качества ПС:
непосредственное измерение показателей примитива качества;
тестирование программ ПС;
экспертная оценка на основании изучения программ и
документации ПС.
Непосредственное измерение показателей примитива качества
производится путем проверки соответствия предъявленной документации
(включая тексты программ на языке программирования) стандартам или
явным требованиям, указанным в спецификации качества ПС, а также путем
измерения времени работы различных устройств и используемых ресурсов
при выполнении контрольных (тестовых) задач.
Для оценки некоторых примитивов качества ПС используется
тестирование. В некоторых случаях для оценки качества ПС проводятся
дополнительные полевые или промышленные испытания.
Полевые испытания ПС – это демонстрация ПС вместе с технической
системой, которой управляет эта ПС, с обеспечением тщательного
наблюдения за поведением ПС.
Промышленные испытания ПС – это процесс передачи ПС в постоянную
эксплуатацию пользователям, представляющий собой опытную эксплуатацию
ПС пользователями со сбором информации об особенностях поведения ПС и
ее эксплуатационных характеристиках.
Многие примитивы качества ПС трудно уловимы с точки зрения их
(объективной) оценки. В этих случаях иногда применяют метод экспертных
оценок. Этот метод заключается в следующем. Назначается группа экспертов
и каждый из этих экспертов в результате изучения представленной
документации составляет свое мнение об обладании ПС требуемым
примитивом качества.
Аттестация ПС похожа на смотр различных компонент ПС в процессе
управления качеством ПС, однако, имеются и существенные различия. Во-
первых, смотр проводится менее представительной группой специалистов.
Во-вторых, в процессе смотра не производится полной оценки качества ПС.
Целью же аттестации является проверка и фиксация реальных
показателей качества предъявленного ПС. Аттестационная комиссия,
подписывая документ о произведенной оценке качества ПС, принимает на
себя определенную ответственность за гарантию качества этого ПС. Но здесь
имеются определенные правовые проблемы, обсуждение которых выходит за
рамки темы этой лекции.
Лекция 10. ДОКУМЕНТИРОВАНИЕ ПРОГРАММНЫХ СРЕДСТВ.
10.1. Документация, создаваемая и используемая в процессе
разработки ПС.
При разработке ПС создается и используется большой объем
разнообразной документации. Она необходима как средство передачи
информации между разработчиками ПС, как средство управления
разработкой ПС и как средство передачи пользователям информации,
необходимой для применения и сопровождения ПС. На создание этой
документации приходится большая доля стоимости ПС.
Эту документацию можно разбить на две группы:
Документы управления разработкой ПС.
Документы, входящие в состав ПС.
Документы управления разработкой ПС (software process
documentation) управляют и протоколируют процессы разработки и
сопровождения ПС, обеспечивая связи внутри коллектива разработчиков ПС
и между коллективом разработчиков и менеджерами ПС (software managers) -
лицами, управляющими разработкой ПС.
Эти документы могут быть следующих типов:
Планы, оценки, расписания. Эти документы создаются
менеджерами для прогнозирования и управления процессами
разработки и сопровождения ПС.
Отчеты об использовании ресурсов в процессе разработки.
Создаются менеджерами.
Стандарты. Эти документы предписывают разработчикам, каким
принципам, правилам, соглашениям они должны следовать в
процессе разработки ПС. Эти стандарты могут быть как
международными или национальными, так и специально
созданными для организации, в которой ведется разработка ПС.
Рабочие документы. Это основные технические документы,
обеспечивающие связь между разработчиками. Они содержат
фиксацию идей и проблем, возникающих в процессе разработки,
описание используемых стратегий и подходов, а также рабочие
(временные) версии документов, которые должны войти в ПС.
Заметки и переписка. Эти документы фиксируют различные
детали взаимодействия между менеджерами и разработчиками.
Документы, входящие в состав ПС (software product documentation),
описывают программы ПС как с точки зрения их применения пользователями,
так и с точки зрения их разработчиков и сопроводителей (в соответствии с
назначением ПС). Здесь следует отметить, что эти документы будут
использоваться не только на стадии эксплуатации ПС (в ее фазах
применения и сопровождения), но и на стадии разработки для управления
процессом разработки (вместе с рабочими документами) - во всяком случае,
они должны быть проверены (протестированы) на соответствие программам
ПС.
Эти документы образуют два комплекта с разным назначением:
Пользовательская документация ПС (П-документация).
Документация по сопровождению ПС (С-документация).
10.2. Пользовательская документация программных средств.
Пользовательская документация ПС (user documentation) объясняет
пользователям, как они должны действовать, чтобы применить
разрабатываемое ПС. Она необходима, если ПС предполагает какое-либо
взаимодействие с пользователями. К такой документации относятся
документы, которыми должен руководствоваться пользователь при
инсталляции ПС (при установке ПС с соответствующей настройкой на среду
применения ПС), при применении ПС для решения своих задач и при
управлении ПС (например, когда разрабатываемое ПС будет
взаимодействовать с другими системами). Эти документы частично
затрагивают вопросы сопровождения ПС, но не касаются вопросов,
связанных с модификацией программ.
В связи с этим следует различать две категории пользователей ПС:
ординарных пользователей ПС и администраторов ПС. Ординарный
пользователь ПС (end-user) использует ПС для решения своих задач (в своей
предметной области). Это может быть инженер, проектирующий техническое
устройство, или кассир, продающий железнодорожные билеты с помощью
ПС. Он может и не знать многих деталей работы компьютера или принципов
программирования. Администратор ПС (system administrator) управляет
использованием ПС ординарными пользователями и осуществляет
сопровождение ПС, не связанное с модификацией программ.
Например, он может регулировать права доступа к ПС между
ординарными пользователями, поддерживать связь с поставщиками ПС или
выполнять определенные действия, чтобы поддерживать ПС в рабочем
состоянии, если оно включено как часть в другую систему.
Состав пользовательской документации зависит от аудиторий
пользователей, на которые ориентировано разрабатываемое ПС, и от режима
использования документов. Под аудиторией здесь понимается контингент
пользователей ПС, у которого есть необходимость в определенной
пользовательской документации ПС. Удачный пользовательский документ
существенно зависит от точного определения аудитории, для которой он
предназначен. Пользовательская документация должна содержать
информацию, необходимую для каждой аудитории. Под режимом
использования документа понимается способ, определяющий, каким образом
используется этот документ. Обычно пользователю достаточно больших
программных систем требуются либо документы для изучения ПС
(использование в виде инструкции), либо для уточнения некоторой
информации (использование в виде справочника).
В соответствии с работами можно считать типичным следующий состав
пользовательской документации для достаточно больших ПС:
Общее функциональное описание ПС. Дает краткую
характеристику функциональных возможностей ПС.
Предназначено для пользователей, которые должны решить,
насколько необходимо им данное ПС.
Руководство по инсталяции ПС. Предназначено для
администраторов ПС. Оно должно детально предписывать, как
устанавливать системы в конкретной среде, в частности, должно
содержать описание компьютерно-считываемого носителя, на
котором поставляется ПС, файлы, представляющие ПС, и
требования к минимальной конфигурации аппаратуры.
Инструкция по применению ПС. Предназначена для ординарных
пользователей. Содержит необходимую информацию по
применению ПС, организованную в форме удобной для ее
изучения.
Справочник по применению ПС. Предназначен для ординарных
пользователей. Содержит необходимую информацию по
применению ПС, организованную в форме удобной для
избирательного поиска отдельных деталей.
Руководство по управлению ПС. Предназначено для
администраторов ПС. Оно должно описывать сообщения,
генерируемые, когда ПС взаимодействует с другими системами, и
как должен реагировать администратор на эти сообщения. Кроме
того, если ПС использует системную аппаратуру, этот документ
может объяснять, как сопровождать эту аппаратуру.
Как уже говорилось ранее, разработка пользовательской документации
начинается сразу после создания внешнего описания. Качество этой
документации может существенно определять успех ПС. Она должна быть
достаточно проста и удобна для пользователя (в противном случае это ПС,
вообще, не стоило создавать). Поэтому, хотя черновые варианты (наброски)
пользовательских документов создаются основными разработчиками ПС, к
созданию их окончательных вариантов часто привлекаются
профессиональные технические писатели. Кроме того, для обеспечения
качества пользовательской документации разработан ряд стандартов, в
которых предписывается порядок разработки этой документации,
формулируются требования к каждому виду пользовательских документов и
определяются их структура и содержание.
10.3. Документация по сопровождению программных средств.
Документация по сопровождению ПС (system documentation) описывает
ПС с точки зрения ее разработки. Эта документация необходима, если ПС
предполагает изучение того, как оно устроена (сконструирована), и
модернизацию его программ. Как уже отмечалось, сопровождение - это
продолжающаяся разработка. Поэтому в случае необходимости модернизации
ПС к этой работе привлекается специальная команда разработчиков-
сопроводителей. Этой команде придется иметь дело с такой же
документацией, которая определяла деятельность команды первоначальных
(основных) разработчиков ПС, - с той лишь разницей, что эта документация
для команды разработчиков-сопроводителей будет, как правило, чужой (она
создавалась другой командой). Чтобы понять строение и процесс разработки
модернизируемого ПС, команда разработчиков-сопроводителей должна
изучить эту документацию, а затем внести в нее необходимые изменения,
повторяя в значительной степени технологические процессы, с помощью
которых создавалось первоначальное ПС.
Документация по сопровождению ПС можно разбить на две группы:
1. документация, определяющая строение программ и структур данных
ПС и технологию их разработки;
2. документацию, помогающую вносить изменения в ПС.
Документация первой группы содержит итоговые документы каждого
технологического этапа разработки ПС.
Она включает следующие документы:
Внешнее описание ПС (Requirements document).
Описание архитектуры ПС (description of the system architecture),
включая внешнюю спецификацию каждой ее программы
(подсистемы).
Для каждой программы ПС - описание ее модульной структуры,
включая внешнюю спецификацию каждого включенного в нее
модуля.
Для каждого модуля - его спецификация и описание его строения
(design description).
Тексты модулей на выбранном языке программирования (program
source code listings).
Документы установления достоверности ПС (validation documents),
описывающие, как устанавливалась достоверность каждой
программы ПС и как информация об установлении достоверности
связывалась с требованиями к ПС.
Документы установления достоверности ПС включают, прежде всего,
документацию по тестированию (схема тестирования и описание комплекта
тестов), но могут включать и результаты других видов проверки ПС,
например, доказательства свойств программ. Для обеспечения приемлемого
качества этой документации полезно следовать общепринятым
рекомендациям и стандартам.
Документация второй группы содержит руководство по сопровождению
ПС (system maintenance guide), которое описывает особенности реализации
ПС (в частности, трудности, которые пришлось преодолевать) и как учтены
возможности развития ПС в его строении (конструкции). В нем также
фиксируются, какие части ПС являются аппаратно- и программно-
зависимыми.
Общая проблема сопровождения ПС - обеспечить, чтобы все его
представления шли в ногу (оставались согласованными), когда ПС
изменяется. Чтобы этому помочь, связи и зависимости между документами и
их частями должны быть отражены в руководстве по сопровождению, и
зафиксированы в базе данных управления конфигурацией.
- 1.1. Методы программирования.
- 1.2. Технологическая схема решения задач.
- 1.3. Индустрия искусственного интеллекта. Экспертные системы.
- 1.4. Законы эволюции программного обеспечения
- 1. Понятие и основные характеристики программного модуля.
- 2.2. Методы разработки и контроль структуры программы.
- 2.3. Типы модуля в Delphi.
- 2.4. Динамически подключаемые библиотеки.
- 1. Основные понятия объектно-ориентированного программирования.