- •Лекция 1. Качество ПО
- •Внешние и внутренние факторы
- •Обзор внешних факторов
- •Корректность (Correctness)
- •Устойчивость (Robustness)
- •Расширяемость (Extendibility)
- •Повторное использование (Reusability)
- •Совместимость (Compatibility)
- •Эффективность (Efficiency)
- •Переносимость (Portability)
- •Простота использования (Easy of Use)
- •Функциональность (Functionality)
- •Своевременность (Timeliness)
- •Другие качества
- •Компромиссы
- •Ключевые вопросы
- •О программном сопровождении
- •Ключевые концепции
- •Лекция 2. Критерии объектной ориентации
- •О критериях
- •До какой степени мы должны быть догматичными?
- •Категории
- •Метод и язык
- •Бесшовность (seamlessness)
- •Классы
- •Утверждения (Assertions)
- •Классы как модули
- •Классы как типы
- •Вычисления, основанные на компонентах
- •Скрытие информации (information hiding)
- •Обработка исключений (Exception handling)
- •Статическая типизация (static typing)
- •Универсальность (genericity)
- •Единичное наследование (single inheritance)
- •Множественное наследование (Multiple inheritance)
- •Дублируемое наследование (Repeated inheritance)
- •Ограниченная универсальность (Constrained genericity)
- •Переопределение (redefinition)
- •Полиморфизм
- •Динамическое связывание
- •Выяснение типа объекта в период выполнения
- •Отложенные (deferred) свойства и классы
- •Управление памятью (memory management) и сборка мусора (garbage collection)
- •Реализация и среда
- •Автоматическое обновление (automatic update)
- •Быстрое обновление (fast update)
- •Живучесть (persistence)
- •Документация
- •Быстрый просмотр (browsing)
- •Библиотеки
- •Базовые библиотеки
- •Графика и пользовательские интерфейсы
- •Механизмы эволюции библиотек
- •Механизмы индексации в библиотеках
- •Продолжение просмотра
- •Библиографические ссылки и объектные ресурсы
- •Лекция 3. Модульность
- •Пять критериев
- •Декомпозиция
- •Модульная Композиция
- •Модульная Понятность
- •Модульная Непрерывность
- •Модульная Защищенность
- •Пять правил
- •Прямое отображение
- •Минимум интерфейсов
- •Слабая связность интерфейсов
- •Явные интерфейсы
- •Скрытие информации
- •Пять принципов
- •Лингвистические Модульные Единицы
- •Самодокументирование
- •Унифицированный Доступ
- •Открыт-Закрыт
- •Единственный Выбор
- •Ключевые концепции
- •Библиографические замечания
- •Упражнения
- •У3.1 Модульность в языках программирования
- •У3.2 Принцип Открыт-Закрыт (для программистов Lisp)
- •У3.3 Ограничения на скрытие информации
- •У3.4 Метрики для модульности (отчетная исследовательская работа)
- •У3.5 Модульность существующих систем
- •У3.6 Управление конфигурацией и наследование
- •Лекция 4. Подходы к повторному использованию
- •Цели повторного использования
- •Ожидаемые преимущества
- •Потребители и производители повторно используемых программ
- •Что следует повторно использовать?
- •Повторное использование персонала
- •Повторное использование проектов и спецификаций
- •Образцы проектов (design patterns)
- •Повторное использование исходного текста
- •Повторное использование абстрактных модулей
- •Повторяемость при разработке ПО
- •Нетехнические препятствия
- •Синдром NIH
- •Фирмы по разработке ПО и их стратегии
- •Организация доступа к компонентам
- •Несколько слов об индексировании компонентов
- •Форматы для распространения повторно используемых компонентов
- •Оценка
- •Техническая проблема
- •Изменения и постоянство
- •Повторно использовать или переделать? (The reuse-redo dilemma)
- •Пять требований к модульным структурам
- •Изменчивость Типов (Type Variation)
- •Группирование Подпрограмм (Routine Grouping)
- •Изменчивость Реализаций (Implementation Variation)
- •Независимость Представлений
- •Факторизация Общего Поведения
- •Традиционные модульные структуры
- •Подпрограммы
- •Пакеты
- •Пакеты: оценка
- •Перегрузка и универсальность
- •Синтаксическая перегрузка
- •Семантическая перегрузка (предварительное представление)
- •Универсальность (genericity)
- •Основные методы модульности: оценка
- •Ключевые концепции
- •Библиографические замечания
- •Ингредиенты вычисления
- •Функциональная декомпозиция
- •Декомпозиция, основанная на объектах
- •Объектно-ориентированное конструирование ПО
- •Вопросы
- •Ключевые концепции
- •Библиографические замечания
- •Лекция 5. К объектной технологии
- •Лекция 6. Абстрактные типы данных (АТД)
- •Критерии
- •Различные реализации
- •Представления стеков
- •Опасность излишней спецификации
- •Какова длина второго имени?
- •К абстрактному взгляду на объекты
- •Использование операций
- •Политика невмешательства в обществе модулей
- •Согласованность имен
- •Можно ли обойтись без абстракций?
- •Формализация спецификаций
- •Специфицирование типов
- •Универсализация (Genericity)
- •Перечисление функций
- •Категории функций
- •Раздел АКСИОМЫ
- •Две или три вещи, которые мы знаем о стеках
- •Частичные функции
- •Предусловия
- •Полная спецификация
- •Ничего кроме правды
- •От абстрактных типов данных к классам
- •Классы
- •Как создавать эффективный класс
- •Роль отложенных классов
- •Абстрактные типы данных и скрытие информации
- •Переход к более императивной точке зрения
- •Назад к тому, с чего начали?
- •Конструирование объектно-ориентированного ПО
- •За пределами программ
- •Дополнительные темы
- •Еще раз о неявности
- •Соотношение спецификации и проектирования
- •Соотношение классов и записей
- •Альтернативы частичным функциям
- •Полна ли моя спецификация?
- •Доказательство достаточной полноты
- •Ключевые концепции
- •Библиографические замечания
- •Упражнения
- •У6.1 Точки
- •У6.2 Боксеры
- •У6.3 Банковские счета
- •У6.4 Сообщения
- •У6.5 Имена
- •У6.6 Текст
- •У6.7 Покупка дома
- •У6.8 Дополнительные операции для стеков
- •У6.9 Ограниченные стеки
- •У6.10 Очереди
- •У6.11 Распределители
- •У6.12 Булевский -- BOOLEAN
- •У6.13 Достаточная полнота
- •У6.14 Непротиворечивость
- •Лекция 7. Статические структуры: классы
- •Классы, а не объекты - предмет обсуждения
- •Устранение традиционной путаницы
- •Роль классов
- •Модули и типы
- •Класс как модуль и как тип
- •Унифицированная система типов
- •Простой класс
- •Компоненты
- •Атрибуты и подпрограммы
- •Унифицированный доступ
- •Класс POINT
- •Основные соглашения
- •Распознавание вида компонент
- •Тело подпрограммы и комментарии к заголовку
- •Предложение indexing
- •Обозначение результата функции
- •Правила стиля
- •Наследование функциональных возможностей общего характера
- •Объектно-ориентированный стиль вычислений
- •Текущий экземпляр
- •Клиенты и поставщики
- •Вызов компонента
- •Принцип единственности цели
- •Слияние понятий модуль и тип
- •Роль объекта Current
- •Квалифицированные и неквалифицированные вызовы
- •Компоненты-операции
- •Селективный экспорт и скрытие информации
- •Неограниченный доступ
- •Ограничение доступа клиентам
- •Стиль объявления скрытых компонент
- •"Внутренний" экспорт
- •Собираем все вместе
- •Общая относительность
- •Большой Взрыв
- •Системы
- •Программа main отсутствует
- •Компоновка системы
- •Классическое "Hello"
- •Структура и порядок: программист в роли поджигателя
- •Обсуждение
- •Форма объявлений
- •Атрибуты или функции?
- •Экспорт атрибутов
- •Доступ клиентов к атрибутам
- •Оптимизация вызовов
- •Архитектурная роль селективного экспорта
- •Импорт листингов
- •Присваивание функции результата
- •Дополнение: точное определение сущности
- •Ключевые концепции
- •Библиографические замечания
- •Упражнения
- •У7.1 POINT как абстрактный тип данных
- •У7.2 Завершение реализации POINT
- •У7.3 Полярные координаты
- •Лекция 8. Динамические структуры: объекты
- •Объекты
- •Что такое объект?
- •Базовая форма
- •Простые поля
- •Простое представление книги - класс BOOK
- •Писатели
- •Ссылки
- •Идентичность объектов
- •Объявление ссылок
- •Ссылка на себя
- •Взгляд на структуру объектов периода выполнения
- •Объекты как средство моделирования
- •Четыре мира программной разработки
- •Реальность: "седьмая вода на киселе"
- •Работа с объектами и ссылками
- •Динамическое создание и повторное связывание
- •Инструкция создания
- •Общая картина
- •Для чего необходимо явное создание объектов?
- •Процедуры создания
- •Перекрытие инициализации по умолчанию
- •Статус экспорта процедур создания
- •Правила, применимые к процедурам создания
- •Процедуры создания и перегрузка
- •Еще о ссылках
- •Состояния ссылок
- •Вызовы и пустые ссылки
- •Операции над ссылками
- •Присоединение ссылки к объекту
- •Сравнение ссылок
- •Значение void
- •Клонирование и сравнение объектов
- •Копирование объектов
- •Глубокое клонирование и сравнение
- •Глубокое хранилище: первый взгляд на сохраняемость
- •Составные объекты и развернутые типы
- •Ссылок не достаточно
- •Развернутые типы
- •Роль развернутых типов
- •Агрегирование
- •Свойства развернутых типов
- •Недопустимость ссылок на подобъекты
- •Присоединение: две семантики - ссылок и значений
- •Присоединение
- •Присоединение: ссылочное и копии
- •Гибридное присоединение
- •Проверка эквивалентности
- •Работа со ссылками: преимущества и опасности
- •Динамические псевдонимы
- •Семантика использования псевдонимов
- •Выработка соглашений для динамических псевдонимов
- •Псевдонимы в ПО и за его пределами
- •Инкапсуляция действий со ссылками
- •Обсуждение
- •Графические соглашения
- •Ссылки и простые значения
- •Форма операций клонирования и эквивалентности
- •Статус универсальных операций
- •Ключевые концепции
- •Библиографические замечания
- •Упражнения
- •У8.1 Книги и авторы
- •У8.2 Личности
- •У8.3 Проектирование нотации
- •Лекция 9. Управление памятью
- •Что происходит с объектами
- •Создание объектов
- •Использование динамического режима
- •Повторное использование памяти в трех режимах
- •Отсоединение
- •Недостижимые объекты
- •Достижимые объекты в классическом подходе
- •Достижимые объекты в ОО-модели
- •Проблема управления памятью в ОО-модели
- •Три ответа
- •Несерьезный подход (тривиальный)
- •Может ли быть оправдан несерьезный подход?
- •Надо ли заботиться о памяти?
- •Байт здесь, байт там, и реальные покойники
- •Восстановление памяти: проблемы
- •Удаление объектов, управляемое программистом
- •Проблема надежности
- •Проблема простоты разработки
- •Подход на уровне компонентов
- •Управление памятью связного списка
- •Работа с утилизированными объектами
- •Дискуссия
- •Автоматическое управление памятью
- •Необходимость автоматических методов
- •Что в точности понимается под восстановлением?
- •Подсчет ссылок
- •Сборка мусора
- •Механизм сборки мусора
- •Основа сборки мусора
- •Сборка по принципу "все-или-ничего"
- •Продвинутый (Advanced) подход к сборке мусора
- •Алгоритмы параллельной сборки мусора
- •Практические проблемы сборки мусора
- •Класс MEMORY
- •Механизм освобождения
- •Сборка мусора и внешние вызовы
- •Среда с управлением памятью
- •Основы
- •Сложные проблемы
- •Перемещение объектов
- •Механизм сборки мусора
- •Повышенное чувство голода и потеря аппетита (Bulimia and anorexia)
- •Операции сборщика мусора
- •Ключевые концепции
- •Библиографические заметки
- •Упражнения
- •У9.1 Модели создания объектов
- •У9.2 Какой уровень утилизации?
- •У9.3 Совместное использование стека достижимых элементов
- •У9.4 Совместное использование
- •Лекция 10. Универсализация
- •Горизонтальное и вертикальное обобщение типа
- •Необходимость параметризованных классов
- •Родовые АТД
- •Проблема
- •Роль типизации
- •Родовые классы
- •Объявление родового класса
- •Использование родового класса
- •Терминология
- •Проверка типов
- •Правило типизации
- •Операции над сущностями родового типа
- •Типы и классы
- •Массивы
- •Массивы как объекты
- •Свойства массива
- •Размышления об эффективности
- •Синонимичная инфиксная операция
- •Стоимость универсализации
- •Обсуждение: что все-таки не сделано
- •Ключевые концепции
- •Библиографические замечания
- •Упражнения
- •У10.1 Ограниченная универсализация
- •У10.2 Двумерные массивы
- •У10.3 Использование своего формального родового параметра фактически как чужого
- •Лекция 11. Проектирование по контракту: построение надежного ПО
- •Базисные механизмы надежности
- •О корректности ПО
- •Выражение спецификаций
- •Формула корректности
- •Сильные и слабые условия
- •Введение утверждений в программные тексты
- •Предусловия и постусловия
- •Класс стек
- •Предусловия
- •Постусловия
- •Педагогическое замечание
- •Контракты и надежность ПО
- •Права и обязательства
- •Интуиция (Дзен) и искусство программной надежности: больше гарантий и меньше проверок
- •Утверждения не являются механизмом проверки вводимых данных
- •Утверждения это не управляющие структуры
- •Ошибки, дефекты и другие насекомые
- •Работа с утверждениями
- •Класс стек
- •Императив и аппликатив (применимость)
- •Замечание о пустоте структур
- •Проектирование предусловий: толерантное или требовательное?
- •Предусловия и статус экспорта
- •Толерантные модули
- •Инварианты класса
- •Определение и пример
- •Форма и свойства инвариантов класса
- •Инвариант в момент изменения
- •Кто должен обеспечить сохранность инвариантов
- •Роль инвариантов класса в программной инженерии
- •Инварианты и контракты
- •Когда класс корректен?
- •Корректность класса
- •Роль процедур создания
- •Ревизия массивов
- •Связывание с АТД
- •Не просто коллекция функций
- •Компоненты класса и АТД функции
- •Выражение аксиом
- •Функция абстракции
- •Инварианты реализации
- •Инструкция утверждения
- •Инварианты и варианты цикла
- •Трудности циклов
- •Сделаем циклы корректными
- •Ингредиенты доказательства корректности цикла
- •Синтаксис цикла
- •Использование утверждений
- •Утверждения как средство для написания корректного ПО
- •Использование утверждений для документирования: краткая форма класса
- •Мониторинг утверждений в период выполнения
- •Каков оптимальный уровень мониторинга?
- •Обсуждение
- •Нужен ли мониторинг в период выполнения?
- •Выразительная сила утверждений
- •Включение функций в утверждения
- •Инварианты класса и семантика ссылок
- •Что дальше
- •Ключевые концепции
- •Библиографические замечания
- •Упражнения
- •У11.1 Комплексные числа
- •У11.2 Класс и его АТД
- •У11.3 Полные утверждения для стеков
- •У11.4 Экспортирование размера
- •У11.5 Инвариант реализации
- •У11.6 Утверждения и экспорт
- •У11.7 Поиск жучков (bugs)
- •У11.8 Нарушение инварианта
- •У11.9 Генерация случайных чисел
- •У11.10 Модуль "очередь"
- •У11.11 Модуль "множество"
- •Постскриптум: Катастрофа Ариан 5
- •Лекция 12. Когда контракт нарушается: обработка исключений
- •Базисные концепции обработки исключений
- •Отказы
- •Исключения
- •Источники исключений
- •Ситуации отказа
- •Обработка исключений
- •Как не следует делать это - C-Unix пример
- •Как не следует делать это - Ada пример
- •Принципы обработки исключений
- •Цепочка вызовов
- •Механизм исключений
- •Спаси и Повтори (Rescue и Retry)
- •Как отказаться сразу
- •Таблица истории исключений
- •Примеры обработки исключений
- •Поломки при вводе
- •Восстановление при исключениях, сгенерированных операционной системой
- •Повторение программы, толерантной к неисправностям
- •N-версионное программирование
- •Задача предложения rescue
- •Корректность предложения rescue
- •Четкое разделение ролей
- •Когда нет предложения rescue
- •Продвинутая обработка исключений
- •Запросы при работе с классом EXCEPTIONS
- •Какой должна быть степень контроля?
- •Исключения разработчика
- •Обсуждение
- •Дисциплинированные исключения
- •Должны ли исключения быть объектами?
- •Методологическая перспектива
- •Ключевые концепции
- •Библиографические замечания
- •Упражнения
- •У12.1 Наибольшее целое
- •У12.2 Объект Exception
- •Лекция 13. Поддерживающие механизмы
- •Взаимодействие с не объектным ПО
- •Внешние программы
- •Улучшенные варианты
- •Использование внешних программ
- •ОО-изменение архитектуры (re-architecturing)
- •Вопрос совместимости: гибридный программный продукт или гибридные языки?
- •Передача аргументов
- •Инструкции
- •Вызов процедуры
- •Присваивание (Assignment)
- •Создание (Creation)
- •Условная Инструкция (Conditional)
- •Множественный выбор
- •Циклы
- •Проверка
- •Отладка
- •Повторение вычислений
- •Выражения
- •Манифестные константы
- •Вызовы функций
- •Текущий объект
- •Выражения с операторами
- •Нестрогие булевы операторы
- •Строки
- •Ввод и вывод
- •Лексические соглашения
- •Ключевые концепции
- •Упражнения
- •У13.1 Внешние классы
- •У13.2 Избегая нестрогих операторов
- •Лекция 14. Введение в наследование
- •Многоугольники и прямоугольники
- •Многоугольники
- •Прямоугольники
- •Основные соглашения и терминология
- •Наследование инварианта
- •Наследование и конструкторы
- •Пример иерархии
- •Полиморфизм
- •Полиморфное присоединение
- •Что на самом деле происходит при полиморфном присоединении?
- •Полиморфные структуры данных
- •Типизация при наследовании
- •Согласованность типов
- •Пределы полиморфизма
- •Экземпляры
- •Статический тип, динамический тип
- •Обоснованы ли ограничения?
- •Может ли быть польза от неведения?
- •Когда хочется задать тип принудительно
- •Полиморфное создание
- •Динамическое связывание
- •Использование правильного варианта
- •Переопределение и утверждения
- •О реализации динамического связывания
- •Отложенные компоненты и классы
- •Движения произвольных фигур
- •Отложенный компонент
- •Эффективизация компонента
- •Отложенные классы
- •Соглашения о графических обозначениях
- •Что делать с отложенными классами?
- •Задание семантики отложенных компонентов и классов
- •Способы изменения объявлений
- •Повторное объявление функции как атрибута
- •Обратного пути нет
- •Использование исходной версии при переопределении
- •Смысл наследования
- •Двойственная перспектива
- •Взгляд на класс как на модуль
- •Взгляд на класс как на тип
- •Наследование и децентрализация
- •Независимость от представления
- •Парадокс расширения-специализации
- •Роль отложенных классов
- •Назад к абстрактным типам данных
- •Отложенные классы как частичные интерпретации: классы поведения
- •Не вызывайте нас, мы вызовем вас
- •Программы с дырами
- •Роль отложенных классов при анализе и глобальном проектировании
- •Обсуждение
- •Явное переопределение
- •Доступ к предшественнику процедуры
- •Динамическое связывание и эффективность
- •Оценка накладных расходов
- •Статическое связывание как оптимизация
- •Кнопка под другим именем: когда статическое связывание ошибочно
- •Подход языка С++ к связыванию
- •Ключевые концепции
- •Библиографические замечания
- •Упражнения
- •У14.1 Многоугольники и прямоугольники
- •У14.2 Многоугольник с малым числом вершин
- •У14.3 Геометрические объекты с двумя координатами
- •У14.4 Наследование без классов
- •У14.5 Классы без объектов
- •У14.6 Отложенные классы и прототип
- •У14.7 Библиотека поиска в таблицах (семестровый проект)
- •У14.8 Виды отложенных компонентов
- •У14.9 Комплексные числа
- •Лекция 15. Множественное наследование
- •Примеры множественного наследования
- •Пример, неподходящий для введения
- •Может ли самолет быть имуществом?
- •Числовые и сравнимые значения
- •Окна - это деревья и прямоугольники
- •Деревья - это списки и их элементы
- •Составные фигуры
- •Брак по расчету
- •Структурное наследование
- •Наследование функциональных возможностей
- •Лунка и кнопка
- •Оценка
- •Переименование компонентов
- •Конфликт имен
- •Результат переименования
- •Смена имен и переопределение
- •Подбор локальных имен
- •Играем в имена
- •Использование родительской процедуры создания
- •Плоские структуры
- •Плоская форма класса
- •Применение плоской формы
- •Краткая плоская форма
- •Дублируемое наследование
- •Общие предки
- •По обе стороны океана
- •Совместное использование и репликация
- •Ненавязчивое дублирующее наследование
- •Правило переименования
- •Конфликт переопределений
- •Конфликт при совместном использовании: отмена определения и соединение компонентов
- •Конфликты при репликации: выделение
- •Выделение всех компонентов
- •Сохранение исходной версии при переопределении
- •Пример повышенной сложности
- •Дублируемое наследование и универсальность
- •Правила об именах
- •Обсуждение
- •Переименование
- •ОО-разработка и перегрузка
- •Ключевые концепции
- •Библиографические замечания
- •Упражнения
- •У15.1 Окна как деревья
- •У15.2 Является ли окно строкой?
- •У15.3 Завершение строительства
- •У15.4 Итераторы фигур
- •У15.5 Связанные стеки
- •У15.6 Кольцевые списки и цепи
- •У15.7 Деревья
- •У15.8 Каскадные или "шагающие" (walking) меню
- •У15.9 Плоский precursor (предшественник)
- •У15.10 Дублируемое наследование и репликация
- •Лекция 16. Техника наследования
- •Наследование и утверждения
- •Инварианты
- •Предусловия и постусловия при наличии динамического связывания
- •Как обмануть клиентов
- •Как быть честным
- •Пример
- •Устранение посредника
- •Субподряды
- •Абстрактные предусловия
- •Правило языка
- •Повторное объявление функции как атрибута
- •Замечание математического характера
- •Глобальная структура наследования
- •Универсальные классы
- •Нижняя часть иерархии
- •Универсальные компоненты
- •Замороженные компоненты
- •Запрет повторного объявления
- •Фиксированная семантика компонентов copy, clone и equality
- •Не злоупотребляйте замораживанием
- •Ограниченная универсальность
- •Вектора, допускающие сложение
- •Не ОО-подход
- •Ограничение родового параметра
- •Игра в рекурсию
- •Попытка присваивания
- •Когда правила типов становятся несносными
- •Проблема
- •Механизм решения
- •Правильное использование попытки присваивания
- •Типизация и повторное объявление
- •Устройства и принтеры
- •Одно- и двусвязные элементы
- •Правило повторного объявления типов
- •Закрепленные объявления
- •Несогласованность типов
- •Примеры из практики
- •Серьезное затруднение
- •Понятие опорного элемента
- •Опорный элемент Current
- •Еще раз о базовых классах
- •Правила о закрепленных типах
- •Когда не используются закрепленные объявления
- •Статический механизм
- •Наследование и скрытие информации
- •Кое-что о политике
- •Применение
- •Зачем нужна такая гибкость?
- •Интерфейс и повторное использование реализаций
- •Слово в защиту реализаций
- •Два стиля
- •Выборочный экспорт
- •Ключевые концепции
- •Библиографические замечания
- •Упражнения
- •У16.1 Наследование: простота и эффективность
- •У16.2 Векторы
- •У16.3 Экстракт?
- •Лекция 17. Типизация
- •Проблема типизации
- •Базисная конструкция
- •Статическая и динамическая типизация
- •Правила типизации
- •Реализм
- •Пессимизм
- •Статическая типизация: как и почему
- •Преимущества
- •Аргументы в пользу динамической типизации
- •Типизация: слагаемые успеха
- •"Типизирована ли кроха"?
- •Типизация и связывание
- •Ковариантность и скрытие потомком
- •Ковариантность
- •Параллельные иерархии
- •Своенравие полиморфизма
- •Скрытие потомком
- •Корректность систем и классов
- •Практический аспект
- •Корректность систем: первое приближение
- •Контравариантность и безвариантность
- •Использование родовых параметров
- •Типовые переменные
- •Полагаясь на закрепление типов
- •Глобальный анализ
- •Остерегайтесь полиморфных кэтколлов!
- •Назад, в Ялту
- •Одно правило и несколько определений
- •Оценка
- •Полное соответствие
- •Ключевые концепции
- •Библиографические замечания
- •Лекция 18. Глобальные объекты и константы
- •Константы базовых типов
- •Атрибуты-константы
- •Использование констант
- •Константы пользовательских классов
- •Константы с манифестом для этого непригодны
- •Однократные функции
- •Применение однократных подпрограмм
- •Разделяемые объекты
- •Однократные функции с результатами базовых типов
- •Однократные процедуры
- •Параметры
- •Однократные функции, закрепление и универсальность
- •Константы строковых типов
- •Unique-значения
- •Обсуждение
- •Инициализация: подходы языков программирования
- •Строковые константы
- •Unique-значения и перечислимые типы
- •Ключевые концепции
- •Библиографические замечания
- •Упражнения
- •У18.1 Эмуляция перечислимых типов однократными функциями
- •У18.2 Однократные функции для эмуляции unique-значений
- •У18.3 Однократные функции в родовых классах
- •У18.4 Однократные атрибуты?
- •Примечания
- •1.1. Хансена
- •1.2. Computer World
- •3.1. метода
- •3.2. именованные константы
- •3.3. Метод, требующий от каждого модуля, вводящего данные, проверку их достоверности, пригоден для реализации модульной защищенности
- •4.1. книга
- •4.3. таблице
- •10.1. Как рассматривать наследование и параметризацию, как соперников или как соратников, когда целью является построение более гибкого ПО
- •10.2. прозрачной
- •10.3. Рассмотрим первый набросок этого класса
- •10.4. инфиксную операцию
- •11.1. общий класс, описывающий стеки
- •11.2. Для инвариантов ответ такой же, как и для постусловий
- •12.1. учебника
- •13.1. процедура
- •13.2. Эта техника будет обсуждаться вместе с вопросом побочных эффектов в разделе принципов модульного проектирования
- •13.3. предыдущих лекциях
- •13.4. анализ символа, введенного пользователем
Нетехнические препятствия
Почему же повторное использование еще не является общепринятым?
Наиболее серьезные препятствия к этому являются техническими; пути их преодоления будут обсуждаться в последующих разделах этой лекции (да и в остальных лекциях курса). Но, конечно, имеются также некоторые организационные, экономические и политические препятствия.
Синдром NIH
Психологическим препятствием повторного использования является известный синдром: "Придумано Не Нами" (Not Invented Here или "NIH"). Говорят, что разработчики ПО являются индивидуалистами, предпочитающими все выполнять сами, не полагаясь на чужую работу.
Но на практике это не подтверждается. Разработчики ПО склонны к бесполезной работе не более других специалистов. Если имеется хорошее, широко известное и легкодоступное повторно используемое решение, то оно будет использовано.
Рассмотрим типичный случай лексического и синтаксического анализа. Намного проще создать программу грамматического анализа для командного языка или простого языка программирования, используя программные генераторы грамматического разбора (parser generators), например комбинацию известных программ Lex-Yacc, а не создавая все с нуля. Вывод очевиден: там, где инструментальные средства имеются, квалифицированные разработчики ПО повсеместно их используют.
В некоторых случаях имеет смысл создание собственного нестандартного анализатора, поскольку у упомянутых инструментальных средств имеются свои ограничения. Но обычно разработчики предпочитают обращаться к одному из этих средств. Это может привести к новому синдрому, противоположному синдрому NIH, который можно назвать синдромом "Привычки Препятствовать Нововведениям" (Habit Inhibiting Novelty или "HIN"). Повторно используемое решение, пусть даже полезное, но имеющее такие ограничения, которые сужают возможности разработчиков и подавляют внедрение новых идей, становится бесполезным. Попробуйте убедить кого-нибудь из разработчиков Unix'а использовать генератор грамматического разбора, отличающийся от Yacc, и вы можете на собственном опыте столкнуться с синдромом HIN.
Конечно, существует кое-что, напоминающее NIH, но часто это просто вполне понятная реакция осмотрительных разработчиков на новые и неизвестные компоненты. Они могут опасаться, что с ошибками или другими проблемами в новой для них программе труднее будет справиться, чем с решением, над которым они имеют полный контроль. Часто такие опасения оправдываются неудачными прежними попытками повторного использования компонентов. Но если новые компоненты являются высококачественными и обеспечивают нормальное функционирование программы, то опасения быстро исчезают.
Таким образом, обеспечить высокое качество при создании повторно используемых компонентов существенно важнее, чем для других видов ПО.
Обозначим через N стоимость уникального решения, R - решения, основанного на повторно используемых компонентах. Значение R никогда не будет равно нулю: сюда войдут затраты на обучение, затраты на включение компонентов в систему, понадобиться создать интерфейс вызова. Так что даже если экономия на повторном использовании и другие выгоды
r=(N - R)/ N
от повторного использования потенциально невелики, то придется все же убедить возможных "повторных пользователей" в том, что ради высокого качества повторно используемого решения стоит отказаться от желания полного контроля над всеми элементами системы.
|Этим объясняется, почему ошибочной целью является политика фирмы, направленная на работу с потенциальными повторными пользователями ( потребителями, как их называют разработчики). Вместо этого следует ужесточить требования к производителям внешних компонентов, требуя гарантий качества и пригодности предлагаемой ими продукции. Разработчики прикладных систем будут использовать ваши компоненты не в связи с вашими рекомендациями, а потому, что вы хорошо потрудились над тем, чтобы повторно используемые компоненты было выгодно применять в прикладных программах. |
Фирмы по разработке ПО и их стратегии
У фирмы по разработке ПО всегда существует искушение создавать решения, преднамеренно не удовлетворяющие критериям повторного использования, из опасения не получить следующий заказ, - поскольку если возможности уже приобретенного решения окажутся излишне широкими, то покупателю следующий заказ не потребуется!
Мне довелось слышать в высшей степени откровенное высказывание по этому вопросу после моей лекции о повторном использовании и ОО-технологии.
Высокопоставленный администратор из крупной фирмы по поставкам ПО сказал мне, что хотя он сознает высокую ценность этих идей, но никогда не будет внедрять их в своей фирме, поскольку не хочет резать курицу, несущую золотые яйца. Более 90% доходов его фирма получает от "сдачи напрокат" личного состава, предоставляя заказчикам услуги своих аналитиков и программистов, и руководство фирмы стремится довести эту цифру до 100%. При таком отношении к разработке ПО навряд ли будет встречена с энтузиазмом перспектива появления общедоступных библиотек повторно используемых компонентов.
Это высказывание было примечательно своей откровенностью, но оно вызвало очевидное возражение: если вообще возможно создать повторно используемые компоненты, которые заменят некоторые дорогостоящие услуги консультантов из фирмы, поставляющей ПО, то рано или поздно кто-либо их создаст. А тогда фирма, отказывавшаяся пойти таким путем, и у которой не осталось ничего, кроме торговли услугами своих консультантов, может пожалеть о том, что, подобно испуганному страусу, зарыла голову в песок.
Технологическая составляющая (engineering part) в разработке ПО не идентична такой же составляющей в индустрии массового производства; человеческий фактор будет, вероятно, попрежнему играть ключевую роль в процессе конструирования ПО.
Цель повторного использования состоит не в том, чтобы заменить людей инструментальными средствами (а это часто, несмотря на всяческие утверждения, происходит с другими отраслями производства), а в изменении соотношения между тем, что следует поручить людям, а что - инструментальным средствам. Так что для фирмы, приобретшей известность за счет своих консультантов, эти нововведения не так уж плохи. В частности:
* Во многих случаях разработчики, применяющие повторно используемые компоненты, могут по-прежнему успешно пользоваться помощью специалистов, которые посоветуют, как
наилучшим образом применять эти компоненты. Тем самым сохраняется существенная роль фирм по поставкам ПО и их консультантов.
*Как будет показано ниже, возможность повторного использования неотделима от расширяемости: хорошие повторно используемые компоненты будут оставаться открытыми для адаптации к конкретным обстоятельствам. Консультанты фирмы, разработавшей соответствующую библиотеку программ, имеют идеальную возможность выполнять настройку компонентов для отдельных заказчиков. Так что продажа компонентов и продажа услуг не обязательно являются взаимно исключающими видами деятельности; торговля компонентами может служить основой для торговли услугами.
*Хорошая повторно используемая библиотека может играть стратегическую роль в политике преуспевающей фирмы по производству ПО, даже если фирма продает решения, а не библиотеку, используя ее лишь для внутренних целей. Такая библиотека может дать фирме конкурентное преимущество в более быстрой и дешевой разработке нестандартных решений, удовлетворяющих требованиям заказчиков, чем могли бы сделать конкуренты, не опирающиеся на такую заранее заготовленную основу.
Организация доступа к компонентам
Вот что говорят скептики: прогресс в производстве повторно используемых ПО приведет к тому, что разработчики окажутся "заваленными" настолько большим количеством компонентов и это так усложнит их жизнь, что лучше бы этих компонентов не было.
Это высказывание следует рассматривать как предупреждение разработчикам повторно используемых ПО о том, что лучшие в мире повторно используемые компоненты бесполезны, если никто не знает об их существовании, или если для их получения придется затратить слишком много времени и усилий. Для практического успеха методов повторного использования требуется создание соответствующих баз данных, содержащих компоненты, запрос к которым позволял бы быстро выяснить, удовлетворяет ли нужным потребностям какойлибо из существующих компонентов.
Должны быть доступны и сетевые услуги, позволяющие осуществить заказ и немедленную доставку по сети выбранных компонентов.
Достижение этих целей требует решения технических и организационных проблем. Индексирование, поиск и доставка повторно используемых компонентов - это технические проблемы, решаемые известными средствами, в частности методами, основанными на использовании баз данных. Очевидно, справляться с программными компонентами ничуть не сложнее, чем с данными о заказчиках, информацией об авиарейсах или с библиотечными книгами.
С созданием Всемирной паутины WWW появились мощные средства поиска, позволяющие намного проще размещать и отыскивать полезную информацию либо в Интернете, либо в корпоративной сети (Intranet). Несомненно, появятся и более совершенные решения (полученные, возможно, с помощью ОО-технологии). Из всего этого становится очевидным, что основной трудностью реализации повторного использования является не организация использования повторно используемых компонентов, а в первую очередь - создание этих чертовых штуковин.
Несколько слов об индексировании компонентов
На стыке технических и организационных проблем возникает вопрос: как следует связывать индексирующую информацию, например ключевые слова с программными компонентами?
Принцип Самодокументирования говорит о том, что вся информация о модуле, включая индексирующую информацию и другие виды документации, - должна содержаться в самом модуле. Это важное требование учтено при разработке нотации классов, развиваемой в лекциях 7-18 этого курса. Механизм предусматривает возможность подключения данных индексирования к каждому компоненту.
"Самодокументирование", лекция 3.
Описание соответствующей синтаксической структуры не вызывает затруднений. В начале текста модуля предлагается написать предложение индексирования (indexing clause) в виде
Indexing
index_word1: value, value, value ...
index_word2: value, value, value ...
...
... Стандартное описание модуля (см. лекции 7-18) ...
Здесь каждое index_word (то есть - индексное слово) это идентификатор; каждое value (то есть - значение) это константа (целая, вещественная и т. д.), идентификатор, или какой либо другой стандартный лексический элемент. (Более подробно см. "Операторы индексирования", лекция 8 курса "Основы объектно-ориентированного проектирования")
Конкретные ограничения на выбор индексных слов и соответствующих значений отсутствуют, но какая либо отрасль промышленности, ассоциация по вопросам стандартизации (standards group), организация или проектная группа может, при необходимости, определить свои правила. Средства индексирования и поиска могут затем извлекать эту информацию, чтобы помочь разработчикам ПО в отыскании компонентов, удовлетворяющих определенным критериям.
Как показало обсуждение проблемы Самодокументирования, сохранение такой информации в самом модуле - а не во внешнем документе или базе данных - уменьшает вероятность ввода ложной информации и, в частности, не позволит забыть об обновлении информации при корректировке модуля (или наоборот). Операторы индексирования, довольно простые на первый взгляд, существенно помогают разработчикам приводить в порядок свои программные средства и регистрировать их свойства с тем, чтобы и другие разработчики могли о них узнать.
Форматы для распространения повторно используемых компонентов
Еще одной задачей, охватывающей как технические, так и организационные проблемы, является выбор представления для распространения: исходный текст или двоичный формат? Это спорный вопрос, и мы ограничимся рассмотрением только нескольких доводов с обеих сторон.
Разработчики коммерческого ПО часто распространяют лишь описание интерфейса (соответствующая краткая форма (short form) рассматривается в одной из последующих лекций) и исполняемый код. Тем самым разработчики защищают секреты производства и свои инвестиции. ("Использование утверждений (assertions) для документирования: сокращенная форма класса", лекция 11)
Двоичный код и в самом деле является предпочтительной формой распространения коммерческих прикладных программ, операционных систем и других инструментальных средств, в том числе компиляторов, интерпретаторов и сред разработки для ОО-языков.
Несмотря на непрекращающиеся нападки на такую концепцию, исходящие, в частности, от группы, называющейся Лигой Сторонников Свободного Программирования (League for Programming Freedom), маловероятно, что от такого способа распространения коммерческого ПО откажутся в ближайшем будущем. Но наше обсуждение относится не к обычным инструментальным средствам или прикладным программам: здесь рассматриваются библиотеки повторно используемых компонентов. В этом случае также могут быть найдены некоторые доводы в пользу распространения исходных текстов.
Для изготовителя программного компонента польза от распространения исходного текста состоит в том, что это облегчает перенос программ (porting efforts). Можно избежать утомительной и малорентабельной деятельности по адаптации ПО к множеству несовместимых платформ, существующих в современном компьютерном мире, рассчитывая на то, что разработчики ОО-компиляторов и программных сред выполнят эту работу за вас. (Для потребителя это, конечно, контраргумент, поскольку инсталляция исходного текста более трудоемка и может привести к непредвиденным ошибкам.)
|
Некоторые компиляторы создают вначале промежуточный код, который уже затем транслируется или интерпретируется на конкретной платформе. Это позволяет обеспечить мобильность ПО без полного доступа к исходному тексту. Если, как это часто бывает сейчас, в компиляторе формируется промежуточный код с использованием языка C, то вместо двоичного
кода обычно можно поставлять переносимый код на языке C4.2)
Этот прием использовался на разных этапах истории создания ПО, начиная с языка UNCOL (UNiversal COmputing Language - универсальный язык программирования), предложенного в конце пятидесятых годов 20-го века. Для него был определен формат команд, интерпретируемых на любой платформе, и представляющих промежуточный код, создаваемый компилятором. В связи с этой проблематикой в 1988 г. был сформирован консорциум компаний по компьютерным техническим средствам и программному обеспечению (Advanced computer environment (ACE) consortium). Вместе с языком Java появилась понятие байт-кода Java-
компилятора, для которого были разработаны интерпретаторы на многих платформах. Но для производителей компонентов вначале это привело к дополнительным трудозатратам. Необходима двойная гарантия того, что новый формат пригоден на любой платформе, представляющей практический интерес, и что не происходит потери эффективности выполнения промежуточного кода в сравнении с платформо-специфическим решением. Без этих гарантий нельзя будет отказаться от старой технологии и придется просто добавить новый формат кода к тем форматам, которые поддерживались ранее. Таким образом, решение, которое рекламируется как завершающее все проблемы переносимости, фактически на некоторое время порождает дополнительные проблемы переносимости.
|
Возможно, более важным доводом в пользу распространения текста исходного кода является то, что попытки защитить свои изобретения и секреты производства путем удаления исходного текста из реализации программного продукта могут не приносить никакой существенной пользы. Самая трудоемкая работа при составлении хорошей повторно используемой библиотеки связана с проектированием интерфейсов компонентов, а не с реализацией; и именно это вы вынуждены опубликовать. Это особенно очевидно в мире структур данных и алгоритмов, для которых почти все необходимые методы описаны в