Объектно-ориентированный анализ и проектирование

Гради Буч

Объектно-ориентированный анализ и проектирование

с примерами приложений на С++

ВТОРОЕ ИЗДАНИЕ

Rational Санта-Клара, Калифорния

перевод с английского под редакцией И. Романовского и Ф. Андреева

Оглавление

Содержание

Об авторе

Предисловие

Часть I. Концепции

Глава 1. Сложность

1.1. Сложность, присущая программному обеспечению
1.2. Структура сложных систем
1.3. Внесение порядка в хаос
1.4. О проектировании сложных систем

Выводы
Дополнительная литература
Врезка: Методы проектирования программных систем

Глава 2. Объектная модель

2.1. Эволюция объектной модели
2.2. Составные части объектного подхода
2.3. Применение объектной модели

Выводы
Дополнительная литература
Врезка: Основные положения объектной модели

Глава 3. Классы и объекты

3.1. Природа объекта
3.2. Отношения между объектами
3.3. Природа классов
3.4. Отношения между классами
3.5. Взаимосвязь классов и объектов
3.6. Качество классов и объектов

Выводы
Дополнительная литература
Врезка: Поиск метода

Глава 4. Классификация

4.1. Важность правильной классификации
4.2. Идентификация классов и объектов
4.3. Ключевые абстракции и механизмы

Выводы
Дополнительная литература
Врезка: Проблема классификации

Часть II. Метод

Глава 5. Обозначения

5.1. Элементы обозначений
5.2. Диаграммы классов
5.3. Диаграммы состояний и переходов
5.4. Диаграммы объектов
5.5. Диаграммы взаимодействия
5.6. Диаграммы модулей
5.7. Диаграммы процессов
5.8. Применение системы обозначений

Выводы
Дополнительная литература

Глава 6. Процесс

6.1. Основные принципы
6.2. Микропроцесс проектирования
6.3. Макропроцесс проектирования

Выводы
Дополнительная литература

Глава 7. Практические вопросы

7.1. Управление и планирование
7.2. Кадры
7.3. Управление релизами
7.4. Повторное использование
7.5. Качество и измерения
7.6. Документация
7.7. Инструменты
7.8. Специальные вопросы
7.9. Выгоды и опасности объектно-ориентированной разработки

Часть III. Примеры приложений

Глава 8. Система сбора данных: метеорологическая станция

8.1. Анализ
8.2. Проектирование
8.3. Эволюция
8.4. Сопровождение

Дополнительная литература
Врезка: Требования к метеорологической станции

Глава 9. Среда разработки: библиотека базовых классов

9.1. Анализ
9.2. Проектирование
9.3. Эволюция
9.4. Сопровождение

Дополнительная литература
Врезка: Требования к библиотеке базовых классов

Глава 10. Архитектура клиент-сервер: складской учет

10.1. Анализ
10.2. Проектирование
10.3. Эволюция
10.4. Сопровождение

Дополнительная литература
Врезка: Требования к системе складского учета

Глава 11. Искусственный интеллект: криптоанализ

11.1. Анализ
11.2. Проектирование
11.3. Эволюция
11.4. Сопровождение

Дополнительная литература
Врезка: Требования к системе криптоанализа

Глава 12. Управление: контроль за движением поездов

12.1. Анализ
12.2. Проектирование
12.3. Эволюция
12.4. Сопровождение

Дополнительная литература
Врезка: Требования к системе управления движением

Послесловие

Приложение: Объектно-ориентированные языки программирования

А.1. Концепции
А.2. Smalltalk
А.3. Object Pascal
А.4. C++
A.5. Common Lisp Object System (CLOS)
A.6. Ada
A.7. Eiffel
А.8. Другие объектно-ориентированные языки программирования

Словарь терминов

Литературные ссылки

Библиография

А. Классификация
В. Объектно-ориентированный анализ
C. Объектно-ориентированные приложения
D. Объектно-ориентированные архитектуры
Е. Объектно-ориентированные СУБД
F. Объектно-ориентированное проектирование
G. Объектно-ориентированное программирование
Н. Прикладное программирование
I. Специальная литература
J. Теория
K. Инструменты и среды разработки

Предметный указатель

Об авторе

Предисловие

Как программисты-профессионалы мы стремимся делать свои системы полезными и работоспособными. Как инженеры-разработчики мы должны создавать сложные системы при ограниченных компьютерных и кадровых ресурсах. За последние несколько лет объектно-ориентированная технология проникла в различные разделы компьютерных наук. К ней относятся как к средству преодоления сложности, присущей многим реальным системам. Объектная модель показала себя мощной объединяющей концепцией.

Что изменилось по сравнению с первым изданием

Со времени выхода в свет первого издания книги "Объектно-ориентированное проектирование с примерами применения" ("Object-Oriented Design with Applications") объектно-ориентированная технология стала одной из основных при разработке программного обеспечения промышленного масштаба. Мы видим, что во всем мире объектная парадигма применяется в таких различных областях, как управление банковскими транзакциями, автоматизация кегельбанов, управление коммунальным хозяйством и исследование генов человека. Во многих случаях новые поколения операционных систем, систем управления базами данных, телефонных служб, систем авионики и мультимедиа-программ пишутся в объектно-ориентированном стиле. В большинстве таких проектов предпочли использовать объектно-ориентированную технологию просто потому, что не было другой возможности создать достаточно надежную и жизнеспособную систему.

За последние годы в сотнях проектов применяли нотацию и процесс разработки, предложенные в нашей книге [Включая мои собственные проекты. Я все же разработчик, а не методолог. Первый вопрос, который нужно задавать каждому методологу: "Используете ли вы ваши методы при разработке собственных программ?"]. В процессе собственной разработки проектов и с учетом опыта многих других, кто пожертвовал своим временем, чтобы поделиться с нами, мы нашли много способов усовершенствовать наш метод. Усовершенствование достигается за счет лучшего изложения процесса проектирования, введения семантики, которая ранее не была отражена в нашей нотации, и упрощения этой нотации там, где возможно.

За истекшее время появились многие другие методы, изложенные в работах Джекобсона (Jacobson), Румбаха (Rumbaugh), Гоада и Иордана (Goad and Yourdon), Константайна (Constantine), Шлера и Меллора (Shiaer and Mellor), Мартина и Одел-ла (Martin and Odell), Вассермана (Wasserman), Голдберга и Рубина (Goldberg and Rubin), Эмбли (Embley), Вирфс-Брока (Wirfs-Brock), Голдстейна и Алгера (Goldstein and Alger), Хендерсон-Селлерса (Henderson-Sellers), Файесмита (Firesmith) и др. Особенно интересна работа Румбаха, который отмечает, что в наших подходах больше сходства чем различий. Мы провели анализ многих из этих методов, разговаривали с разработчиками и менеджерами, которые их использовали, и, когда это было возможно, пытались сами их применять. Так как мы больше заинтересованы в реальной помощи по разработке проектов в объектно-ориентированной технологии, чем в догматическом следовании (будь то по эмоциональным или историческим причинам) нашим идеям, мы пытались включить все лучшее, что нашли в новых методах, в нашу собственную работу. Мы с благодарностью отмечаем фундаментальный и уникальный вклад каждого из этих лиц в данную область.

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

Цели, аудитория и структура этого издания остаются теми же, что и в первом. Однако, есть пять существенных различий между вторым и первым изданиями.

Во-первых, глава 5 была расширена с тем, чтобы изложить унифицированную систему обозначений значительно подробнее. Чтобы сделать ее более понятной, были явно разделены существенные и дополнительные элементы обозначений. Кроме того, особое внимание уделено взаимному согласованию разных представлений в этой системе.

Во-вторых, значительно расширены главы 6 и 7, в которых рассматривается практика объектно-ориентированного анализа и проектирования. Мы даже сменили в этом издании заглавие книги, отразив тот факт, что наш метод объединяет анализ и проектирование.

В-третьих, мы решили приводить примеры всех программных текстов в основной части книги на одном языке, а именно на C++. Этот язык быстро становится фактическим стандартом для многих областей, кроме того, большинство профессиональных разработчиков, "сочиняющих" на других языках, могут "читать" на C++. Это не значит, что мы считаем другие языки - такие, как Smalltalk, CLOS, Ada или Eiffel - менее важными. Главная цель этой книги - анализ и проектирование, и так как нам нужны конкретные примеры, мы решили писать их на достаточно общем языке программирования. Где возможно, мы описываем особенности семантики других языков и их влияние на наш метод.

В-четвертых, в это издание включены несколько новых примеров приложений. Некоторые интересные идиомы и среды разработки применялись для написания целого ряда приложений и наши примеры отражают эти достижения. Например, концепция "клиент/сервер" послужила основой для одного пересмотренного прикладного примера.

Наконец, почти в каждую главу добавлены ссылки на литературу. Кроме того, мы обсуждаем новые проблемные вопросы объектно-ориентированной технологии, возникшие после выхода первого издания.

Цели

Эта книга призвана служить практическим руководством по созданию объектно-ориентированных систем. Особое внимание мы уделяем следующим целям:

• обеспечить отчетливое понимание основных концепций объектной модели;
• помочь освоить систему обозначений и процесс объектно-ориентированного анализа и проектирования;
• научить читателя практическому применению объектно-ориентированного подхода в различных предметных областях.

Изложенные здесь понятия имеют серьезное теоретическое обоснование, но эта книга прежде всего призвана удовлетворить практические потребности и интересы сообщества разработчиков программных продуктов.

Аудитория

Книга предназначена и для профессионалов, и для студентов:

• Разработчику-практику мы покажем, как эффективно применять объектно-ориентированную технологию для решения реальных задач.
• Если вы выступаете в роли аналитика или архитектора системы, мы поможем вам пройти путь от постановки задачи до реализации, с использованием объектно-ориентированного анализа и проектирования. Мы разовьем вашу способность отличать "хорошую" объектно-ориентированную архитектуру от "плохой" и находить правильное решение в сложном реальном мире. Возможно самое важное, что мы предлагаем - новые подходы к рассмотрению сложных систем.
• Менеджеру программного проекта мы подскажем, как распределить ресурсы в команде разработчиков и снизить издержки, связанные с написанием любой сложной программной системы.
• Создателю инструментальных программных средств и их пользователю мы предложим подробное изложение системы обозначений и процесса объектно-ориентированной разработки - основы CASE (computer-aided software engineering, разработка программ с помощью компьютера).
• Студенту книга будет полезна, как основа, которая поможет приобрести начальные знания и навыки в искусстве создания сложных систем.

Книга может быть использована при чтении курсов для студентов и аспирантов, а также при проведении профессиональных семинаров и самостоятельном изучении. Так как она посвящена в основном методу построения программ, книга идеально подойдет для курсов проектирования программных продуктов и даст материал для дополнительных занятий по курсам объектно-ориентированных языков.

Структура

Книга делится на три большие части - "Концепции", "Метод" и "Примеры приложений" - с добавлением значительного дополнительного материала.

Концепции

Метод

Вторая часть описывает метод построения сложных систем, основанный на объектной модели. Сначала мы вводим систему графических обозначений объектно-ориентированного анализа и проектирования, а затем рассматриваем процесс разработки. Мы затрагиваем и практические вопросы, в частности роль этого процесса в жизненном цикле программного продукта и его значение для управления проектами.

Примеры приложений

Заключительная часть посвящена пяти нетривиальным примерам, охватывающим широкий круг приложений: сбору данных, прикладным средам разработки, архитектуре клиент/сервер, искусственному интеллекту и управлению технической системой. Мы выбрали эти области, так как они хорошо представляют те разновидности сложных задач, с которыми может столкнуться программист. Легко можно продемонстрировать успех любых принципов на простых задачах, но поскольку мы фокусируем свое внимание на создании систем реальной жизни, нам было интереснее показать, как объектная модель доходит до сложных приложений. Некоторые читатели могут быть незнакомы со спецификой выбранного приложения, поэтому мы начинаем каждый пример с краткого обсуждения присущих ему технологических особенностей (таких, как проектирование базы данных и понятия информационной доски). Разработку программных систем нельзя свести к набору рецептов, поэтому мы подчеркиваем необходимость постепенного развития приложений на основе соблюдения ряда четких принципов и следования ясным моделям.

Дополнительный материал

Помимо этой книги, можно порекомендовать "Сборник задач", содержащий упражнения, вопросы и проекты, которые должны оказаться полезными для… Приобрести инструментальные средства и пройти обучение методу Буча (Booch)… Как пользоваться этой книгой?

ЧАСТЬ ПЕРВАЯ

Концепции

Сэр Исаак Ньютон по секрету признавался друзьям, что он
знает, как гравитация ведет себя, но не знает, почему.

Лили Томлин (Lily Tomlin)
В поисках признаков разумной жизни во Вселенной
(The Search for Signs of Intelligent Life in the Universe)

Глава 1

Сложность

1.1. Сложность, присущая программному обеспечению

Простые и сложные программные системы

Мы знаем, что не все программные системы сложны. Существует множество программ, которые задумываются, разрабатываются, сопровождаются и используются… Нас интересует разработка того, что мы будем называть промышленными… Существенная черта промышленной программы - уровень сложности: один разработчик практически не в состоянии охватить…

Почему программному обеспечению присуща сложность?

Сложность реального мира. Проблемы, которые мы пытаемся решить с помощью программного обеспечения, часто неизбежно содержат сложные элементы, а к… Эта внешняя сложность обычно возникает из-за "нестыковки" между… Дополнительные сложности возникают в результате изменений требований к программной системе уже в процессе разработки.…

Последствия неограниченной сложности

Наше неумение создавать сложные программные системы проявляется в проектах, которые выходят за рамки установленных сроков и бюджетов и к тому же не… Как мы можем изменить положение дел? Так как проблема возникает в результате… 1.2. Структура сложных систем

Примеры сложных систем

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

Это пример сложной иерархической системы. Персональный компьютер нормально работает благодаря четкому совместному функционированию всех его составных частей. Вместе эти части образуют логическое целое. Мы можем понять, как работает компьютер, только потому, что можем рассматривать отдельно каждую его составляющую. Таким образом, можно изучать устройства монитора и жесткого диска независимо друг от друга. Аналогично можно изучать арифметическую часть ЦП, не рассматривая при этом подсистему памяти.

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

Структура растений и животных. Ботаник пытается понять сходство и различия растений, изучая их морфологию, то есть форму и структуру. Растения - это сложные многоклеточные организмы. В результате совместной деятельности различных органов растений происходят такие сложные типы поведения, как фотосинтез и всасывание влаги.

Растение состоит из трех основных частей: корни, стебли и листья. Каждая из них имеет свою особую структуру. Корень, например, состоит из корневых отростков, корневых волосков, верхушки корня и т.д. Рассматривая срез листа, мы видим его эпидермис, мезофилл и сосудистую ткань. Каждая из этих структур, в свою очередь, представляет собой набор клеток. Внутри каждой клетки можно выделить следующий уровень, который включает хлоропласт, ядро и т.д. Так же, как у компьютера, части растения образуют иерархию, каждый уровень которой обладает собственной независимой сложностью.

Все части на одном уровне абстракции взаимодействуют вполне определенным образом. Например, на высшем уровне абстракции, корни отвечают за поглощение из почвы воды и минеральных веществ. Корни взаимодействуют со стеблями, которые передают эти вещества листьям. Листья в свою очередь используют воду и минеральные вещества, доставляемые стеблями, и производят при помощи фотосинтеза необходимые элементы.

Для каждого уровня абстракции всегда четко разграничено "внешнее" и "внутреннее". Например, можно установить, что части листа совместно обеспечивают функционирование листа в целом и очень слабо взаимодействуют или вообще прямо не взаимодействуют с элементами корней. Проще говоря, существует четкое разделение функций различных уровней абстракции.

В компьютере транзисторы используются как в схеме ЦП, так и жесткого диска. Аналогично этому большое число "унифицированных элементов" имеется во всех частях растения. Так Создатель достигал экономии средств выражения. Например, клетки служат основными строительными блоками всех структур растения; корни, стебли и листья растения состоят из клеток. И хотя любой из этих исходных элементов действительно является клеткой, существует огромное количество разнообразных клеток. Есть клетки, содержащие и не содержащие хлоропласт, клетки с оболочкой, проницаемой и непроницаемой для воды, и даже живые и умершие клетки.

При изучении морфологии растения мы не выделяем в нем отдельные части, отвечающие за отдельные фазы единого процесса, например, фотосинтеза. Фактически не существует централизованных частей, которые непосредственно координируют деятельность более низких уровней. Вместо этого мы находим отдельные части, которые действуют как независимые посредники, каждый из которых ведет себя достаточно сложно и при этом согласованно с более высокими уровнями. Только благодаря совместным действиям большого числа посредников образуется более высокий уровень функционирования растения. Наука о сложности называет это возникающим поведением. Поведение целого сложнее, чем поведение суммы его составляющих [6].

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

Жизнь растений и животных поддерживает значительное число механизмов надклеточного уровня, то есть более высокого уровня абстракции. И растения, и животные используют сосудистую систему для транспортировки внутри организма питательных веществ. И у тех, и у других может существовать различие полов внутри одного вида.

Структура вещества. Исследования в таких разных областях, как астрономия и ядерная физика, дают множество других примеров невероятно сложных систем. В этих двух дисциплинах мы найдем примеры иерархических структур. Астрономы изучают галактики, которые объединены в скопления, а звезды, планеты и другие небесные тела образуют галактику. Ядерщики имеют дело со структурной иерархией физических тел совсем другого масштаба. Атомы состоят из электронов, протонов и нейтронов; электроны, по-видимому, являются элементарными частицами, но протоны, нейтроны и другие тяжелые частицы формируются из еще более мелких компонентов, называемых кварками.

Мы опять обнаруживаем общность форм механизмов в этих сложных иерархиях. На самом деле оказывается, что во Вселенной работают всего четыре типа сил: гравитационное, электромагнитное, сильное и слабое взаимодействия. Многие законы физики универсальны, например, закон сохранения энергии и импульса можно применить и к галактикам, и к кваркам.

Структура социальных институтов. Как последний пример сложных систем рассмотрим структуру общественных институтов. Люди объединяются в группы для решения задач, которые не могут быть решены индивидуально. Одни организации быстро распадаются, другие функционируют на протяжении нескольких поколений. Чем больше организация, тем отчетливее проявляется в ней иерархическая структура. Транснациональные корпорации состоят из компаний, которые в свою очередь состоят из отделений, содержащих различные филиалы. Последним принадлежат уже отдельные офисы и т.д. Границы между частями организации могут изменяться, и с течением времени может возникнуть новая, более стабильная иерархия.

Отношения между разными частями большой организации подобны отношениям между компонентами компьютера, растения или галактики. Характерно, что степень взаимодействия между сотрудниками одного учреждения несомненно выше, чем между сотрудниками двух разных учреждений. Клерк, например, обычно не общается с исполнительным директором компании, а в основном обслуживает посетителей. Но и здесь различные уровни имеют единые механизмы функционирования. Работа и клерка и директора оплачивается одной финансовой организацией, и оба они для своих целей используют общую аппаратуру, в частности, телефонную систему компании.

Пять признаков сложной системы

1. "Сложные системы часто являются иерархическими и состоят из взаимозависимых подсистем, которые в свою очередь также могут быть разделены на… Саймон отмечает: "тот факт, что многие сложные системы имеют почти… Важно осознать, что архитектура сложных систем складывается и из компонентов, и из иерархических отношений этих…

Организованная и неорганизованная сложность

Этот пример наводит на мысль, что мы обращались с термином иерархия в весьма приблизительном смысле. Наиболее интересные сложные системы содержат… Эта вторая иерархия представляет собой иерархию типа "is-a". Исходя… Объединяя понятия структуры классов и структуры объектов с пятью признаками сложных систем, мы приходим к тому, что…

Роль декомпозиции

Алгоритмическая декомпозиция. Большинство из нас формально обучено структурному проектированию "сверху вниз", и мы воспринимаем… Объектно-ориентированная декомпозиция. Предположим, что у этой задачи… Хотя обе схемы решают одну и ту же задачу, но они делают это разными способами. Во второй декомпозиции мир представлен…

Роль абстракции

Вулф так описывает этот процесс: "Люди развили чрезвычайно эффективную технологию преодоления сложности. Мы абстрагируемся от нее. Будучи не в… В главе 2 понятие абстракции рассмотрено более детально.

Роль иерархии

Определить иерархии в сложной программной системе не всегда легко, так как это требует разработки моделей многих объектов, поведение каждого из… 1.4. О проектировании сложных систем

Инженерное дело как наука и искусство

Когда разрабатывается совершенно новая система, роль инженера как художника выдвигается на первый план. Это происходит постоянно при проектировании…

Смысл проектирования

По предположению Страуструпа: "Цель проектирования - выявление ясной и относительно простой внутренней структуры, иногда называемой… Важность построения модели. Моделирование широко распространено во всех… Как мы уже сказали выше, чтобы понять во всех тонкостях поведение сложной системы, приходится использовать не одну…

Глава 2

Объектная модель

Объектно-ориентированный анализ и проектирование принципиально отличаются от традиционных подходов структурного проектирования: здесь нужно… В этой главе мы выясним, чем является и чем не является… 2.1. Эволюция объектной модели

Тенденции в проектировании

Большинство современных коммерческих программных систем больше и существенно сложнее, чем были их предшественники даже несколько лет тому назад.… Вегнер сгруппировал некоторые из наиболее известных языков высокого уровня в…   Второе поколение (1959-1961) FORTRAN II Подпрограммы, раздельная компиляция …

Основные положения объектной модели

Но в объектной модели отражается и множество других факторов. Как показано во врезке ниже, объектный подход зарекомендовал себя как унифицирующая… Рис. 2-4. Топология малых и средних приложений в объектных и объектно-ориентированных языках.

OOP, OOD и ООА

Рис. 2-5. Топология больших приложений в объектных и объектно-ориентированных… В Object Pascal используется термин приведение типов, а в языке Ada то же самое называется преобразование типов. Чтобы…

Парадигмы программирования

Невозможно признать какой-либо стиль программирования наилучшим во всех областях практического применения. Например, для проектирования баз знаний… Каждый стиль программирования имеет свою концептуальную базу. Каждый стиль… Эти элементы являются главными в том смысле, что без любого из них модель не будет объектно-ориентированной. Кроме…

Абстрагирование

Абстракция выделяет существенные характеристики некоторого объекта, отличающие его от всех других видов объектов и, таким образом, четко определяет… Абстрагирование концентрирует внимание на внешних особенностях объекта и… Выбор правильного набора абстракций для заданной предметной области представляет собой главную задачу…

Инкапсуляция

Абстракция и инкапсуляция дополняют друг друга: абстрагирование направлено на наблюдаемое поведение объекта, а инкапсуляция занимается внутренним… Инкапсуляция, таким образом, определяет четкие границы между различными… Дисков прямо утверждает, что "абстракция будет работать только вместе с инкапсуляцией" [53]. Практически это…

Модульность

Согласно Барбаре Лисков "модульность - это разделение программы на фрагменты, которые компилируются по отдельности, но могут устанавливать… Правильное разделение программы на модули является почти такой же сложной… Модули выполняют роль физических контейнеров, в которые помещаются определения классов и объектов при логическом…

Ifndef _GPLAN_H

Define _GPLAN_H 1 #include "gtypes.h" #include "except.h" #include "actions.h" class GrowingPlan ... class FruitGrowingPlan ... class GrainGrowingPlan ...

#endif

Здесь мы импортируем в файл три других заголовочных файла с определением интерфейсов, на которые будем ссылаться: gtypes.h, except .h и actions.h. Собственно код классов мы поместим в модуль реализации, в файл с именем gplan.cpp.

Мы могли бы также собрать в один модуль все программы, относящиеся к окнам диалога, специфичным для данного приложения. Этот модуль наверняка будет зависеть от классов, объявленных в gplan.h, и от других файлов-заголовков с описанием классов GUI.

Вероятно, будет много других модулей, импортирующих интерфейсы более низкого уровня. Наконец мы доберемся до главной функции - точки запуска нашей программы операционной системой. При объектно-ориентированном проектировании это скорее всего будет самая малозначительная и неинтересная часть системы, в то время, как в традиционном структурном подходе головная функция - это краеугольный камень, который держит все сооружение. Мы полагаем, что объектно-ориентированный подход более естественен, поскольку, как замечает Мейер, "на практике программные системы предлагают некоторый набор услуг. Сводить их к одной функции можно, но противоестественно... Настоящие системы не имеют верхнего уровня" [63].

Иерархия

Значительное упрощение в понимании сложных задач достигается за счет образования из абстракций иерархической структуры. Определим иерархию следующим… Иерархия - это упорядочение абстракций, расположение их по уровням. Основными видами иерархических структур применительно к сложным системам являются структура классов (иерархия…

Типизация

Типизация - это способ защититься от использования объектов одного класса вместо другого, или по крайней мере управлять таким использованием. Типизация заставляет нас выражать наши абстракции так, чтобы язык… Идея согласования типов занимает в понятии типизации центральное место. Например, возьмем физические единицы измерения…

Параллелизм

Кроме этого "аппаратного" различия, мы будем различать "тяжелую" и "легкую" параллельность по потребности в ресурсах.… Многие современные операционные системы предусматривают прямую поддержку… Лим и Джонсон отмечают, что "возможности проектирования параллельности в объектно-ориентированных языках не…

Сохраняемость

Традиционно, первыми тремя уровнями занимаются языки программирования, а последними - базы данных. Этот конфликт культур приводит к неожиданным… Унификация принципов параллелизма для объектов позволила создать параллельные… Языки программирования, как правило, не поддерживают понятия сохраняемости; примечательным исключением является…

Преимущества объектной модели

Во-первых, объектная модель позволяет в полной мере использовать выразительные возможности объектных и объектно-ориентированных языков… Сохраняемость поддерживает состояние и класс объекта в пространстве и во времени.

Использование объектного подхода

В настоящее время объектно-ориентированное проектирование - единственная методология, позволяющая справиться со сложностью, присущей очень большим…

Открытые вопросы

Выводы Развитие программной индустрии привело к созданию методов объектно-ориентированного анализа, проектирования и программирования,… Рис. 2-6. Применения объектной модели. Модульность - это состояние… Дополнительная литература

Глава 3

Классы и объекты

И инженер, и художник должны хорошо чувствовать материал, с которым они работают. В объектно-ориентированной методологии анализа и создания сложных программных систем основными строительными блоками являются классы и объекты. Выше было дано всего лишь неформальное определение этих двух элементов. В этой главе мы рассмотрим природу классов и объектов, взаимоотношения между ними, а также сообщим несколько полезных правил проектирования хороших абстракций.

3.1. Природа объекта

Что является и что не является объектом?

В предыдущей главе объект был неформально определен как осязаемая реальность, проявляющая четко выделяемое поведение. С точки зрения восприятия… Таким образом, мы расширили неформальное определение объекта новой идеей:… Объектами реального мира не исчерпываются типы объектов, интересные при проектировании программных систем. Другие…

Состояние

Другими словами, автомат играл роль (ожидание монеты), которую пользователь игнорировал, нажав сначала кнопку. Или предположим, что пользователь… В каждой из таких ситуаций мы видим, что поведение объекта определяется его… На основе этого примера дадим следующее низкоуровневое определение:

Поведение

Поведение - это то, как объект действует и реагирует; поведение выражается в терминах состояния объекта и передачи сообщений. Иными словами, поведение объекта - это его наблюдаемая и проверяемая извне… Операцией называется определенное воздействие одного объекта на другой с целью вызвать соответствующую реакцию.…

Идентичность

"Идентичность - это такое свойство объекта, которое отличает его от всех других объектов" [12]. Они отмечают, что "в большинстве языков программирования и управления… Примеры. Начнем с определения точки на плоскости.

Типы отношений

Отношения двух любых объектов основываются на предположениях, которыми один обладает относительно другого: об операциях, которые можно выполнять, и… Зайдевиц и Старк назвали эти два типа отношений отношениями старшинства и…

Связи

Семантика. Мы заимствуем понятие связи у Румбаха, который определяет его как "физическое или концептуальное соединение между объектами" [16]. Объект сотрудничает с другими объектами через связи, соединяющие его с ними. Другими словами, связь - это специфическое сопоставление, через которое клиент запрашивает услугу у объекта-сервера или через которое один объект находит путь к другому.

На рис. 3-2 показано несколько разных связей. Они отмечены линиями и означают как бы пути прохождения сообщений. Сами сообщения показаны стрелками (соответственно их направлению) и помечены именем операции. На рисунке объект aController связан с двумя объектами класса DisplayItem (объекты a и b). В свою очередь, оба, вероятно, связаны с aView, но нам была интересна только одна из этих связей. Только вдоль связи один объект может послать сообщение другому.

Связь между объектами и передача сообщений обычно односторонняя (как на рисунке; хотя технически она может быть и взаимной). Как мы увидим в главе 5, подобное разделение прав и обязанностей типично для хорошо структурированных объектных систем [На самом деле организация объектов, показанная на рис. 3-2, встречается настолько часто, что ее можно считать типовым проектным решением. В Smalltalk аналогичный механизм известен как MVC, model/view/controller (модель/представление/контроллер). Как мы увидим в следующей главе, хорошо структурированные системы имеют много таких опознаваемых типовых решений]. Заметьте также, что хотя передаваемое сообщение инициализировано клиентом (в данном случае aController), данные передаются в обоих направлениях. Например, когда aController вызывает операцию move для пересылки данных объекту а, данные передаются от клиента серверу, но при выполнении операции isUnder над объектом b, результат передается от сервера клиенту.

Участвуя в связи, объект может выполнять одну из следующих трех ролей:

• Актер [Actor - это деятель, исполнитель. А исполнитель ролей, это и есть актер. - Примеч. ред.]. Объект может воздействовать на другие объекты, но сам никогда не подвергается воздействию других объектов; в определенном смысле это соответствует понятию активный объект.

Рис. 3-2. Связи.

• Сервер. Объект может только подвергаться воздействию со стороны других объектов, но он никогда не выступает в роли воздействующего объекта.

• Агент. Такой объект может выступать как в активной, так и в пассивной роли; как правило, объект-агент создается для выполнения операций в интересах какого-либо объекта-актера или агента.

На рис. 3-2 объект aController выступает как актер, объект a - как агент и объект aView - как сервер.

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

Абстракция нагрева имеет достаточно четкое поведение, что дает нам право на описание такого класса. Сначала определим тип, значение которого задает прошедшее время в минутах.

//Числопрошедшихминут
typedef unsigned int Minute;

Теперь опишем сам класс TemperatureRamp, который по смыслу задает функцию времени от температуры:

class TemperatureRamp {
public:

TemperatureRamp();
virtual ~TemperatureRamp();
virtual void clear();
virtual void bind (Temperature, Minute);
Temperature TemperatureAt (Minute);

protected:
...
};

Выдерживая наш стиль, мы описали некоторые из операций виртуальными, так как ожидаем, что этот класс будет иметь подклассы.

На самом деле в смысле поведения нам надо нечто большее, чем просто зависимость температуры от времени. Пусть, например, известно, что на 60-й минуте должна быть достигнута температура 250°F, а на 180-й - 150°F. Спрашивается, какой она должна быть на 120-й минуте? Это требует линейной интерполяции, так что требуемое от абстракции поведение усложняется.

Вместе с тем, управления нагревателем, поддерживающего требуемый профиль, мы от этой абстракции не требуем. Мы предпочитаем разделение понятий, при котором нужное поведение достигается взаимодействием трех объектов: экземпляра TemperatureRamp, нагревателя и контроллера. Класс TemperatureController можно определить так:

class TemperatureController {
public:

TemperatureController(Location);
~TemperatureController();
void process(const TemperatureRamp&);
Minute schedule(const TemperatureRamp&) const;

private:
...
};

Тип Location был определен в главе 2. Заметьте, что мы не ожидаем наследования от этого класса и поэтому не объявляем в нем никаких виртуальных функций.

Операция process обеспечивает основное поведение этой абстракции; ее назначение - передать график изменения температуры нагревателю, установленному в конкретном месте. Например, объявим:

TemperatureRamp growingRamp;
TemperatureController rampController(7);

Теперь зададим пару точек и загрузим план в контроллер::

growingRamp.bind (250, 60);
growingRamp.bind(150, 180);
rampController.process(growingRamp);

В этом примере rampController - агент, ответственный за выполнение температурного плана, он использует объект growingRamp как сервер. Эта связь проявляется хотя бы в том, что rampController явно получает growingRamp в качестве параметра одной из своих операций.

Одно замечание по поводу нашего стиля. На первый взгляд может показаться, что наши абстракции - лишь объектные оболочки для элементов, полученных в результате обычной функциональной декомпозиции. Пример операции schedule показывает, что это не так. Объекты класса TemperatureController имеют достаточно интеллекта, чтобы определять расписание для конкретных профилей, и мы включаем эту операцию как дополнительное поведение нашей абстракции. В некоторых энергоемких технологиях (например, плавка металлов) можно существенно выиграть, если учитывать остывание установки и тепло, остающееся после предыдущей плавки. Поскольку существует операция schedule, клиент может запросить объект TemperatureController, чтобы тот рекомендовал оптимальный момент запуска следующего нагрева.

Видимость. Пусть есть два объекта А и в и связь между ними. Чтобы А мог послать сообщение в, надо, чтобы в был в каком-то смысле видим для А. Мы можем не заботиться об этом на стадии анализа, но когда дело доходит до реализации системы, мы должны обеспечить видимость связанных объектов.

В предыдущем примере объект rampController видит объект growingRamp, поскольку оба они объявлены в одной области видимости и потому, что growingRamp передается объекту rampController в качестве параметра. В принципе есть следующие четыре способа обеспечить видимость.

• Сервер глобален по отношению к клиенту.
• Сервер (или указатель на него) передан клиенту в качестве параметра операции.
• Сервер является частью клиента.
• Сервер локально порождается клиентом в ходе выполнения какой-либо операции.

Какой именно из этих способов выбрать - зависит от тактики проектирования.

Синхронизация. Когда один объект посылает по связи сообщение другому, связанному с ним, они, как говорят, синхронизируются. В строго последовательном приложении синхронизация объектов и состоит в запуске метода (см. врезку ниже). Однако в многопоточной системе объекты требуют более изощренной схемы передачи сообщений, чтобы разрешить проблемы взаимного исключения, типичные для параллельных систем. Активные объекты сами по себе выполняются как потоки, поэтому присутствие других активных объектов на них обычно не влияет. Если же активный объект имеет связь с пассивным, возможны следующие три подхода к синхронизации:

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

Все объекты, описанные в этой главе, были последовательными. В главе 9 мы рассмотрим остальные варианты более подробно.

Агрегация

Рис. 3-3. Агрегация. Агрегация может означать физическое вхождение одного объекта в другой, но не обязательно. Самолет состоит из крыльев,…

Что такое класс?

Понятия класса и объекта настолько тесно связаны, что невозможно говорить об объекте безотносительно к его классу. Однако существует важное различие этих двух понятий. В то время как объект обозначает конкретную сущность, определенную во времени и в пространстве, класс определяет лишь абстракцию существенного в объекте. Таким образом, можно говорить о классе "Млекопитающие", который включает характеристики, общие для всех млекопитающих. Для указания на конкретного представителя млекопитающих необходимо сказать "это - млекопитающее" или "то - млекопитающее".

Класс представляет набор объектов, которые обладают общей структурой и одинаковым поведением.

В общепонятных терминах можно дать следующее определение класса: "группа, множество или вид с общими свойствами или общим свойством, разновидностями, отличиями по качеству, возможностями или условиями" [17]. В контексте объектно-ориентированного анализа дадим следующее определение класса:

Класс - это некое множество объектов, имеющих общую структуру и общее поведение.

Любой конкретный объект является просто экземпляром класса. Что же не является классом? Объект не является классом, хотя в дальнейшем мы увидим, что класс может быть объектом. Объекты, не связанные общностью структуры и поведения, нельзя объединить в класс, так как по определению они не связаны между собой ничем, кроме того, что все они объекты.

Важно отметить, что классы, как их понимают в большинстве существующих языков программирования, необходимы, но не достаточны для декомпозиции сложных систем. Некоторые абстракции так сложны, что не могут быть выражены в терминах простого описания класса. Например, на достаточно высоком уровне абстракции графический интерфейс пользователя, база данных или система учета как целое, это явные объекты, но не классы [Можно попытаться выразить такие абстракции одним классом, но повторной используемости и возможности наследования не получится. Иметь громоздкий интерфейс - плохая практика, так как большинство клиентов использует только малую его часть. Более того, изменение одной части этого гигантского интерфейса требует обновления каждого из клиентов, независимо от того, затронуло ли его это изменение по сути. Вложенность классов не устраняет этих проблем, а только откладывает их]. Лучше считать их некими совокупностями (кластерами) сотрудничающих классов. Страуструп называет такие кластеры компонентами [18]. Мы же, по причинам, которые будут объяснены в главе 5, называем такие кластеры категориями классов.

Интерфейс и реализация

большие задачи надо разделить на много маленьких и перепоручить их мелким субподрядчикам. Нигде эта идея не проявляет себя так ярко, как в… По своей природе, класс - это генеральный контракт между абстракцией и всеми… Идея контрактного программирования приводит нас к разграничению внешнего облика, то есть интерфейса, и внутреннего…

Жизненный цикл класса

В поведении простых классов можно разобраться, изучая операции их открытой части. Однако поведение более интересных классов (такое как перемещение объекта класса DisplayItem или составление расписания для экземпляра класса TemperatureController) включает взаимодействие разных операций, входящих в класс. Как уже говорилось выше, объекты таких классов действуют как маленькие машины, части которых взаимодействуют друг с другом, и так как все такие объекты имеют одно и то же поведение, можно использовать класс для описания их общей семантики, упорядоченной по времени и событиям. Как будет показано в главе 5, мы можем описывать динамику поведения объектов, используя модель конечного автомата.

3.4. Отношения между классами

Типы отношений

Из этого простого примера следует, что классы, как и объекты, не существуют изолированно. В каждой проблемной области ключевые абстракции… Отношения между классами могут означать одно из двух. Во-первых, у них может… Известны три основных типа отношений между классами [22]. Во-первых, это отношение "обобщение/специализация"…

Ассоциация

В C++ это можно выразить с помощью того, что Румбах называет погребенными указателями [24]. Вот две выдержки из объявления соответствующих… class Product; class Sale;

Наследование

class Time... struct ElectricalData { Time timeStamp; int id; float fuelCell1Voltage, fuelCell2Voltage; float fuelCell1Amperes, fuelCell2Amperes; float…

Агрегация

class TemperatureController { public: TemperatureController(Location); ~TemratureController(); void process(const… private:

Использование

class TemperatureController { public: TemperatureController(Location); ~TemperatureController(); void… private:

Инстанцирование

Template<class Item> class Queue { public: Queue(); Queue(const Queue<Item>&); virtual ~Queue(); virtual… protected: ... };

Метаклассы

Как было сказано, любой объект является экземпляром какого-либо класса. Что будет, если мы попробуем и с самими классами обращаться как с объектами? Для этого нам надо ответить на вопрос, что же такое класс класса? Ответ - это метакласс. Иными словами, метакласс - это класс, экземпляры которого суть классы. Метаклассы венчают объектную модель в чисто объектно-ориентированных языках. Соответственно, они есть в Smalltalk и CLOS, но не в C++.

Вот как Робсон мотивирует потребность в метаклассах: "классы доставляют программисту интерфейс для определения объектов. Если так, то желательно, чтобы и сами классы были объектами, так, чтобы ими можно было манипулировать, как всеми остальными описаниями" [49].

В языках типа Smalltalk первичное назначение метакласса - поддержка переменных класса (которые являются общими для всех экземпляров этого класса), операции инициализации переменных класса и создания единичного экземпляра метакласса [50]. По соглашению, метакласс Smalltalk обычно содержит примеры использования его классов. Например, как показано на рис. 3-11, мы могли бы задать переменную класса nextId для метакласса TelemetryData, чтобы вырабатывать идентифицирующие метки при создании каждого экземпляра TelemetryData. Аналогично, мы могли бы определить оператор порождения новых экземпляров класса, который изготавливал бы их, скажем, в некотором предварительно выделенном пуле памяти.

Хотя в C++ метаклассов нет, семантика его конструкторов и деструкторов служит целям, аналогичным тем, что вызвали к жизни метаклассы. C++ имеет средства поддержки и переменных класса, и операций метакласса. Конкретно, в C++ можно описать члены данных или функции класса как статические (static), что будет означать: этот элемент является общим для всех экземпляров класса. Статические члены класса в C++ эквивалентны переменным класса в Smalltalk. Статическая функция-член класса играет роль операций метакласса в Smalltalk.

Как мы уже отмечали, в CLOS аппарат метаклассов еще сильнее чем в Smalltalk. Через него можно изменять саму семантику элементов: следование классов, обобщенные функции и методы. Главное преимущество - возможность экспериментировать с другими объектно-ориентированными парадигмами и создавать такие инструменты для разработчика, как броузеры классов и объектов.

Рис. 3-11. Метаклассы.

В CLOS есть предопределенный класс с именем standard-class, который является метаклассом для всех нетипизированных классов, определенных с помощью defclass. В этом метаклассе есть метод make-instance, который создает экземпляры. Кроме того, в нем определена вся техника работы со списком следования классов. Все это можно изменить.

Методы и обобщенные функции в CLOS тоже можно рассматривать как объекты. Так как они несколько отличаются от обычных объектов, то в совокупности объекты, соответствующие классам, методам и обобщенным функциям, называются метаобьектами. Каждый метод является экземпляром предопределенного класса standard-method, а каждая функция является экземпляром предопределенного класса standard-generic-function. Поскольку поведение этих предопределенных классов можно изменить, удается влиять на трактовку методов и обобщенных функций.

3.5. Взаимосвязь классов и объектов.

Отношения между классами и объектами

Классы и объекты - это отдельные, но тесно связанные понятия. В частности, каждый объект является экземпляром какого-либо класса; класс может порождать любое число объектов. В большинстве практических случаев классы статичны, то есть все их особенности и содержание определены в процессе компиляции программы. Из этого следует, что любой созданный объект относится к строго фиксированному классу. Сами объекты, напротив, в процессе выполнения программы создаются и уничтожаются.

В качестве примера рассмотрим классы и объекты для задачи управления воздушным движением. Наиболее важные абстракции в этой сфере - самолеты, графики полетов, маршрут и коридоры в воздушном пространстве. Трактовка этих классов объектов по самому их определению достаточно статична. Иначе невозможно было бы построить никакого приложения, использующего такие общепонятные факты, как то, что самолеты могут взлетать, летать и приземляться, а также что никакие два самолета не должны находиться одновременно в одной и той же точке.

Объекты же этих классов, напротив, динамичны. Набор маршрутов полетов сменяется не очень часто. Существенно быстрее изменяется множество самолетов, находящихся в полете. Частота, с которой самолеты занимают и покидают воздушные коридоры, еще выше.

Роль классов и объектов в анализе и проектировании

На этапе анализа и ранних стадиях проектирования решаются две основные задачи:

• Выявление классов и объектов, составляющих словарь предметной области.
• Построение структур, обеспечивающих взаимодействие объектов, при котором выполняются требования задачи.

В первом случае говорят о ключевых абстракциях задачи (совокупность классов и объектов), во втором - о механизмах реализации (совокупность структур).

На ранних стадиях внимание проектировщика сосредоточивается на внешних проявлениях ключевых абстракций и механизмов. Такой подход создает логический каркас системы: структуры классов и объектов. На последующих фазах проекта, включая реализацию, внимание переключается на внутреннее поведение ключевых абстракций и механизмов, а также их физическое представление. Принимаемые в процессе проектирования решения задают архитектуру системы: и архитектуру процессов, и архитектуру модулей.

3.6. Качество классов и объектов

Измерение качества абстракции

Опыт показывает, что процесс выделения классов и объектов является последовательным, итеративным. За исключением самых простых задач с первого раза… Термин зацепление взят из структурного проектирования, но в более вольном… Кроме зацепления между модулями в объектно-ориентированном анализе, существенно зацепление между классами и объектами.…

Как выбрать операции?

Функциональность. Описание интерфейса класса или модуля - трудная работа. Обычно первое приближение делается, исходя из структурного смысла класса, а затем, когда появляются клиенты класса, интерфейс уточняется, модифицируется и дополняется. В частности может возникнуть потребность в создании новых классов или в изменении взаимодействия существующих.

В пределах каждого класса принято иметь только примитивные операции, отражающие отдельные аспекты поведения. Такие методы называются точными. Принято также отделять методы, не связанные между собой. Это облегчает образование подклассов с переопределением поведения. Решение о количестве методов может быть обусловлено двумя причинами: описание поведения в одном методе упрощает интерфейс, но усложняет и увеличивает размеры самого метода; расщепление метода усложняет интерфейс, но делает каждый из методов проще. По наблюдению Мейера "хороший проектировщик умеет найти компромисс между большим числом связей (дробление системы на фрагменты) и большим размером модулей (что может привести к потере управляемости)" [54].

В объектно-ориентированном проектировании принято рассматривать методы класса как единое целое, поскольку все они взаимодействуют друг с другом для реализации протокола абстракции. Таким образом, определив поведение, нужно решить, в каком из классов это поведение реализуется. Халберт и O'Брайен предложили следующие критерии для принятия такого решения:

• Повторная используемость	Будет ли это поведение полезно более чем в одном контексте?
• Сложность	Насколько трудно реализовать такое поведение?
• Применимость	Насколько данное поведение характерно для класса, в который мы хотим включить поведение?
• Знание реализации	Надо ли для реализации данного поведения знать секреты класса?

Обычно операции объявляются, как методы класса, к объектам которого относятся данные действия. Однако в языках Object Pascal, C++, CLOS и Ada допускается описание операций в виде свободных подпрограмм (утилит класса). Свободная подпрограмма, в терминологии C++, - это функция, не являющаяся элементом класса. Свободные подпрограммы не могут переопределяться подобно обычным методам, в них нет такой общности. Наличие утилит позволяет выполнить требование примитивности и уменьшить зацепление между классами, особенно если эти операции высокого уровня задействуют объекты многих различных классов.

Аспекты расхода памяти и времени. После того, как мы приняли решение о необходимости конкретной функции и определили ее семантику, следует принять решение об использовании ею времени и памяти. Для выражения таких решений принято использовать понятие лучшего, среднего и худшего вариантов, где худший - это верхний допустимый предел расходов.

Раньше мы уже отмечали, что поскольку один объект посылает другому сообщение, эти два объекта должны быть каким-то образом синхронизированы. В случае многих потоков управления это означает, что передача сообщений сложнее, чем управление вызовами подпрограмм. Для большинства языков программирования синхронизация просто не нужна, поскольку в них программы однопотоковые, и все объекты действуют последовательно. Мы говорим в таких случаях о простой передаче сообщений, так как ее семантика больше похожа на простой вызов подпрограмм. Однако в языках, поддерживающих параллелизм [Ada и Smalltalk имеют прямую поддержку параллельности. Языки типа C++ такой поддержкой не обладают, но в них часто можно обеспечить семантику параллельности за счет расширения классами (зависящими от платформы): примером служит библиотека AT&T для C++], нужно побеспокоиться о более изощренных системах передачи сообщений, чтобы избежать случаев, когда два потока работают одновременно и несогласованно с одним и тем же объектом. Объекты, семантика которых сохраняется при многопоточности, являются или синхронизированными, или защищенными.

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

• Синхронная	Операция активизируется только при готовности передающего и принимающего сообщения объектов; ожидание взаимной готовности может быть неопределенно долгим.
• С учетом задержки	То же, что и синхронная, однако, в случае, если принимающий не готов, передающий не выполняет операцию.
• С ограничением времени	То же, что и синхронная, однако, посылающий будет ждать готовности принимающего не дольше некоторого времени.
• Асинхронная	Операция выполняется вне зависимости от готовности принимающего.

Нужная форма выбирается для каждой операции отдельно, но только после того, как ее функциональная семантика определена.

Как выбирать отношения

Одним из полезных правил является закон Деметера, который утверждает, что "методы любого класса не должны зависеть от структуры других классов,… При анализе структуры классов системы в целом можно обнаружить, что иерархия… Иногда требуется выбирать между отношениями наследования, агрегации и использования. Например, должен ли класс Car…

Выбор реализации

Представление. Представление классов и объектов почти всегда должно быть инкапсулировано (скрыто). Это позволяет вносить изменения (например,… Одним из наиболее трудных решений является выбор между вычислением элементов… Модульная структура. Аналогичные вопросы возникают при распределении деклараций классов и объектов по модулям. В языке…

Глава 4

Классификация

Классификация - средство упорядочения знаний. В объектно-ориентированном анализе определение общих свойств объектов помогает найти общие ключевые абстракции и механизмы, что в свою очередь приводит нас к более простой архитектуре системы. К сожалению, пока не разработаны строгие методы классификации и нет правила, позволяющего выделять классы и объекты. Нет таких понятий, как "совершенная структура классов", "правильный выбор объектов". Как и во многих технических дисциплинах, выбор классов является компромиссным решением.

На одной из конференций программистам был задан вопрос: "Какими правилами вы руководствуетесь при определении классов и объектов?" Страуструп, разработчик языка C++, ответил: "Это как поиск святого Грааля. Не существует панацеи". Габриель, один из разработчиков CLOS, сказал: "Это вопрос, на который нет простого ответа. Я просто пробую" [1]. К счастью, имеется богатый опыт классификации в других науках, на основе которого разработаны методики объектно-ориентированного анализа. Каждая такая методика предлагает свои правила (эвристики) идентификации классов и объектов. Они и будут предметом этой главы.

Важность правильной классификации

Классификация и объектно-ориентированное проектирование

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

Классификация есть средство упорядочение знаний.

Разумная классификация, несомненно, - часть любой науки. Михальски и Степп утверждают: "неотъемлемой задачей науки является построение содержательной классификации наблюдаемых объектов или ситуаций. Такая классификация существенно облегчает понимание основной проблемы и дальнейшее развитие научной теории" [2]. Та же философия относится и к инженерному делу. В области строительной архитектуры и городского планирования, как отмечает Александер, для архитектора "его проектная деятельность, и скромная, и гигантская по размеру, управляется целиком образами, которые он держит в своем сознании в данный момент, и его способностью комбинировать эти образы при создании нового проекта" [3].

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

Классификация играет большую роль при распределении процессов между процессорами. Мы направляем процессы на один процессор или на разные в зависимости от того, как эти процессы связаны друг с другом.

Трудности классификации

Примеры классификации. В главе 3 мы определили объект как нечто, имеющее четкие границы. На самом деле это не вполне так. Границы предметов часто неопределенны. Например, посмотрите на вашу ногу. Попытайтесь определить, где начинается и кончается колено. В разговорной речи трудно понять, почему именно эти звуки определяют слово, а не являются частью какого-то более длинного слова. Представьте себе, что вы проектируете текстовый редактор. Что считать классом - буквы или слова? Как понимать отдельные фразы, предложения, параграфы, документы? Как обращаться с произвольными, не обязательно осмысленными, блоками текста? Что делать с предложениями, абзацами и целыми документами - соответствуют ли такие классы нашей задаче?

То, что разумная классификация - трудная проблема, новостью не назовешь. И поскольку есть параллели с аналогичными трудностями в объектно-ориентированном проектировании, рассмотрим примеры классификации в двух других научных дисциплинах: биологии и химии.

Вплоть до XVIII века идея о возможности классификации живых организмов по степени сложности была господствующей. Мера сложности была субъективной, поэтому неудивительно, что человек оказался в списке на первом месте. В середине XVIII века шведский ботаник Карл Линней предложил более подробную таксономию для классификации организмов: он ввел понятия рода и вида. Век спустя Дарвин выдвинул теорию, по которой механизмом эволюции является естественный отбор и ныне существующие виды животных - продукт эволюции древних организмов. Теория Дарвина основывалась на разумной классификации видов. Как утверждает Дарвин, "натуралисты пытаются расположить виды, роды, семейства в каждом классе в то, что называется натуральной системой. Что подразумевается под этой системой? Некоторые авторы понимают некоторую простую схему, позволяющую расположить наиболее похожие живые организмы в один класс и различные - в разные классы" [4]. В современной биологии термин "классификация" обозначает "установление иерархической системы категорий на основе предположительно существующих естественных связей между организмами" [5]. Наиболее общее понятие в биологической таксономии - царство, затем, в порядке убывания общности: тип (отдел), класс, отряд (порядок), семейство, род и, наконец, вид. Исторически сложилось так, что место каждого организма в иерархической системе определяется на основании внешнего и внутреннего строения тела и эволюционных связей. В современной классификации живых существ выделяются группы организмов, имеющих общую генетическую историю, то есть организмы, имеющие сходные ДНК, включаются в одну группу. Классификация по ДНК полезна, чтобы различить организмы, которые похожи внешне, но генетически сильно отличаются. По современным воззрениям дельфины ближе к коровам, чем к форели [6].

Возможно, для программиста биология представляется зрелой, вполне сформировавшейся наукой с определенными критериями классификации организмов. Но это не так. Биолог Мэй сказал: "На сегодняшний день мы даже не знаем порядок числа видов растений и животных, населяющих нашу планету: классифицировано менее, чем 2 млн. видов, в то время как возможное число видов оценивается от 5 до 50 млн." [7]. Более того, различные критерии классификации одних и тех же животных приводят к разным результатам. Мартин утверждает, что "все зависит от того, что вы хотите получить. Если вы хотите, чтобы классификация говорила о кровном родстве видов, вы получите один ответ, если вы желаете отразить уровень приспособления, ответ будет другой" [8]. Можно заключить, что даже в строгих научных дисциплинах методы и критерии классификации сильно зависят от цели классификации.

Аналогичная ситуация сложилась и в химии [9]. В древние времена считалось, что все вещества суть комбинации земли, воздуха, огня и воды. В настоящее время такая классификация не может считаться сколько-нибудь удовлетворительной. В середине XVII в. Роберт Бойль предложил элементы как примитивные химические абстракции, из которых составляются более сложные вещества. Век спустя, в 1789 г., Лавуазье опубликовал первый список, содержащий 23 элемента, хотя впоследствии было открыто, что некоторые из них таковыми не являются. Но открытие новых элементов продолжалось, список увеличивался. Наконец, в 1869 г. Менделеев предложил периодический закон, который давал точные критерии для классификации известных элементов и даже мог предсказывать свойства еще не открытых элементов. Но даже периодический закон не был концом истории о классификации элементов. В начале XX в. были открыты элементы с одинаковыми химическими свойствами, но с разными атомными весами - изотопы.

Вывод прост. Как утверждал Декарт: "Открытие порядка - нелегкая задача, но если он найден, понять его совсем не трудно" [10]. Лучшие программистские решения выглядят просто, но, как показывает опыт, добиться простой архитектуры очень трудно.

Итеративная суть классификации. Все эти сведения мы привели здесь не для того, чтобы оправдать "долгострой" в программном обеспечении, хотя на самом деле многим менеджерам и пользователям кажется, что необходимы века, чтобы закончить начатую работу. Мы просто хотели подчеркнуть, что разумная классификация - работа интеллектуальная и лучший способ ее ведения - последовательный, итеративный процесс. Это становится очевидным при анализе разработки таких программных продуктов, как графический интерфейс, стандарты баз данных и языки программирования четвертого поколения. Шоу утверждает, что в разработке программного обеспечения "развитие какой-либо абстракции часто следует общей схеме. В начале проблема решается ad hoc, то есть как-нибудь, для каждого частного случая. По мере накопления опыта некоторые решения оказываются более удачными, чем другие, и возникает род фольклора, переходящего от человека к человеку. Удачные решения изучаются более систематически, они программируются и анализируются. Это позволяет развить модели, осуществить их автоматическую реализацию, и разработать теорию, обобщающую найденное решение. Это в свою очередь поднимает практику на более высокий уровень и позволяет взяться за еще более сложную задачу, к которой, в свою очередь, мы подходим ad hoc, тем самым начиная новый виток спирали" [11].

Итеративный подход к классификации накладывает соответствующий отпечаток и на процедуру конструирования иерархии классов и объектов при разработке сложного программного обеспечения. На практике обычно за основу берется какая-то определенная структура классов, которую постепенно совершенствуют.

Разные наблюдатели классифицируют один и тот же объект по-разному.

И только на поздней стадии разработки, когда уже получен некоторый опыт использования такой структуры, мы можем критически оценить качество получившейся классификации. Основываясь на полученном опыте, мы можем создать новый подкласс из уже существующих (вывод), или разделить большой класс на много маленьких (факторизация), или, наконец, слить несколько существующих в один (композиция). Возможно, в процессе разработки будут найдены новые общие свойства, ранее не замеченные, и мы сможем определить новые классы (абстракция) [12].

Почему же классификация так сложна? Мы объясняем это двумя причинами. Во-первых, отсутствием "совершенной" классификации, хотя, естественно, одни классификации лучше других. Кумбс, Раффья и Трал утверждают, что "существует столько способов деления мира на объектные системы, сколько ученых принимается за эту задачу" [13]. Любая классификация зависит от точки зрения субъекта. Флуд и Кэрсон приводят пример: "Соединенное Королевство... экономисты могут рассматривать как экономический институт, социологи - как общество, защитники окружающей среды - как гибнущий уголок природы, американские туристы - как достопримечательность, советские руководители - как военную угрозу, наконец, наиболее романтичные из нас, британцев - как зеленые луга родины" [14]. Во-вторых, разумная классификация требует изрядной доли творческого озарения. Бертвистл, Даль, Мюрхауг и Нюгард заключают, что "иногда ответ очевиден, иногда он - дело вкуса, а бывает, что все зависит от умения заметить главное" [15]. Все это напоминает загадку: "Почему лазерный луч похож на золотую рыбку?.. Потому, что ни тот, ни другой не умеют свистеть" [16]. Надо быть очень творческим мыслителем, чтобы найти общее в настолько несвязанных предметах.

4.2. Идентификация классов и объектов

Классический и современный подходы

Со времен Платона проблема классификации занимала умы бесчисленных философов, лингвистов, когнитивистов, математиков. Поэтому было бы разумно изучить накопленный опыт и применить его в объектно-ориентированном проектировании. Исторически известны только три подхода:

• классическая категоризация;
• концептуальная кластеризация;
• теория прототипов [17].

Классическая категоризация. В классическом подходе "все вещи, обладающие данным свойством или совокупностью свойств, формируют некоторую категорию. Причем наличие этих свойств является необходимым и достаточным условием, определяющим категорию" [18]. Например, холостые люди - это категория: каждый человек или холост, или женат, и этот признак достаточен для решения вопроса, к какой категории принадлежит тот или иной индивидуум. С другой стороны, высокие люди не определяют категории, если, конечно, мы специально не уточним критерий, позволяющий четко отличать высоких людей от невысоких.

Классическая категоризация пришла к нам от Платона и Аристотеля. Последний в своей классификации растений и животных пользовался техникой рассуждений, напоминающей современную детскую игру в 20 вопросов (Это минерал, животное или растение? Это покрыто мехом или перьями? Может ли оно летать? Пахнет ли оно?) [20]. Такой подход нашел последователей, наиболее выдающимися из которых были: Фома Аквинский, Декарт, Локк. По утверждению Фомы Аквинского: "Мы можем именовать вещи согласно нашим знаниям об их природе, получаемым через познание их свойств и действий" [21].

Принципы классической категоризации отражены в современной теории развития ребенка. Пьяже утверждает, что после первого года жизни ребенок осознает существование объектов и затем начинает приобретать навыки их классификации, вначале пользуясь базовыми категориями, такими, как собаки, кошки и игрушки [22]. Позднее ребенок осознает, с одной стороны более общие (животные), а с другой стороны, более частные категории (колли, доги, овчарки) [23].

Таким образом, классический подход в качестве критерия похожести объектов использует родственность их свойств. В частности, объекты можно разбивать на непересекающиеся множества в зависимости от наличия или отсутствия некоторого признака. Мински предположил, что "лучшими являются такие наборы свойств, элементы которых мало взаимодействуют между собой. Этим объясняется всеобщая любовь к таким критериям как размер, цвет, форма и материал. Так как эти критерии не пересекаются, про какой-нибудь предмет можно утверждать, что он большой, серый, круглый и деревянный" [24]. Вообще говоря, свойства не обязательно должны быть измеряемыми, в качестве их можно использовать наблюдаемое поведение. То обстоятельство, что птицы летают, а рыбы нет, позволяет отличить орла от форели.

Проблема классификации На рис. 4-1 показаны 10 поездов, обозначенных буквами от А до J. Каждое изображение состоит из паровоза и нескольких вагонов. Прежде чем продолжать чтение, попытайтесь за 10 минут определить несколько групп изображений, составленных по какому-то логическому признаку. Например, изображения можно разбить на три группы: в одной группе поезда имеют черные колеса, в другой группе - белые, а в третьей - и белые, и черные. Этот пример взят из работы Степпа и Михальски о концептуальном объединении [19]. Очевидно, "правильного" разбиения на группы не существует. Наши изображения были классифицированы 93 различными способами. Наиболее распространенный способ классификаций по длине состава: были выделены три группы: составы с двумя, тремя и четырьмя вагонами. Второй по популярности вид классификации - по цвету колес поезда. Сорок из девяносто трех видов классификации были уникальными (то есть вид содержал только один экземпляр). Экспериментируя с этим рисунком, мы убедились в правоте Степпа и Михальски. Большинство опрошенных нами предлагали один из двух наиболее популярных видов классификации (по длине состава и цвету колес поезда). Один опрошенный предложил следующее: в одной группе составы помечены буквами, нарисованными с помощью только прямых линий (A, Е, F, H и I), в другой - буквами с кривыми линиями. Вот уж, действительно, пример нетривиального мышления. Если вы уже справились с заданием, давайте изменим условия. Представим, что круги обозначают груз с токсичными веществами, прямоугольники - лесоматериалы, все остальные знаки обозначают пассажиров. Попытайтесь теперь классифицировать изображения и заметьте, как дополнительная информация влияет на вашу точку зрения. В наших опытах большинство опрошенных классифицировало поезда по тому, содержит состав токсичный груз или нет. Мы заключили, что новые сведения о реальной ситуации облегчают и улучшают классификацию.

Какие конкретно свойства надо принимать во внимание? Это зависит от обстановки. Например, цвет автомобиля надо зафиксировать в задаче учета продукции автомобилестроительного завода, но он не интересен программе, управляющей уличным светофором. Вот почему мы говорим, что нет абсолютного критерия классификации, одна и та же структура классов может подходить для одной задачи и не годиться для другой. Джеймс пишет: "Нельзя утверждать, что некоторая схема классификации лучше других отражает структуру и порядок вещей в природе. Природе безразличны наши попытки в ней разобраться. Некоторые классификации действительно важнее других, но только в связи с нашими интересами, а не потому, что они вернее или полнее отражают реальность" [25].

Современное западное мышление по большей части насквозь пропитано классической категоризацией, однако, как показывает пример с высокими и низкими людьми, этот подход не всегда работает. Косок отмечает, что "естественные категории не четко отграничены друг от друга. Большинство птиц летает, но не все. Стул может быть деревянным, металлическим или пластмассовым, а количество ног у него целиком зависит от прихоти конструктора. Практически невозможно перечислить определяющие свойства естественной категории, так, чтобы не было исключений" [26]. Это, действительно, коренные пороки классической категоризации, которые и попытались исправить в современных подходах. Ими мы сейчас займемся.

Рис. 4-1. Проблема классификации.

Концептуальная кластеризация. Это более современный вариант классического подхода. Он возник из попыток формального представления знаний. Степп и Михальски пишут: "При таком подходе сначала формируются концептуальные описания классов (кластеров объектов), а затем мы классифицируем сущности в соответствии с этими описаниями" [27]. Например, возьмем понятие "любовная песня". Это именно понятие, а не признак или свойство, поскольку степень любовности песни едва ли можно измерить. Но если можно утверждать, что песня скорее про любовь, чем про что-то другое, то мы помещаем ее в эту категорию.

Концептуальную кластеризацию можно связать с теорией нечетких (многозначных) множеств, в которой объект может принадлежать к нескольким категориям одновременно с разной степенью точности. Концептуальная кластеризация делает в классификации абсолютные суждения, основываясь на наилучшем согласии.

Теория прототипов. Классическая категоризация и концептуальная кластеризация - достаточно выразительные методы, вполне пригодные для проектирования сложных программных систем. Но все же есть ситуации, в которых эти методы не работают. Рассмотрим более современный метод классификации, теорию прототипов, предпосылки которой можно найти в книге по психологии восприятия Рош и ее коллег [28].

Существуют некоторые абстракции, которые не имеют ни четких свойств, ни четкого определения. Лакофф объясняет эту проблему так: "По утверждению Виттгенстейна (Wittgenstein), существуют категории (например, игры), которые не соответствуют классически образцам, так как нет признаков, свойственных всем играм... По этой причине их можно объединить так называемой семейной схожестью... Виттгенстейн утверждает, что у категории игр нет четкой границы. Категорию можно расширить и включить новые виды игр при условии, что они напоминают уже известные игры" [29]. Вот почему этот подход называется теорией прототипов: класс определяется одним объектом-прототипом, и новый объект можно отнести к классу при условии, что он наделен существенным сходством с прототипом.

Лаков и Джонсон применяют классификацию на основе прототипов к упомянутой выше проблеме стульев. Они замечают, что "мы считаем мягкий пуф, парикмахерское кресло и складной стул стульями не потому, что они удовлетворяют некоторому фиксированному набору признаков прототипа, но потому, что они имеют достаточное фамильное сходство с прототипом... Не требуется никакого общего набора свойств прототипа, которое годилось бы и для пуфика и для парикмахерского кресла, но они оба - стулья, так как каждый из них в отдельности похож на прототипный стул, пусть даже каждый по-своему. Свойства, определяемые при взаимодействии с объектом (свойства взаимодействия), являются главными при определении семейного сходства" [30].

Понятие свойств взаимодействия - центральное для теории прототипов. В концептуальной кластеризации мы группируем в соответствии с различными концепциями. В теории прототипов классификация объектов производится по степени их сходства с конкретным прототипом.

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

На практике мы идентифицируем классы и объекты сначала по свойствам, важным в данной ситуации, то есть стараемся выделить и отобрать структуры и типы поведения с помощью словаря предметной области. "Потенциально возможных абстракций, как правило, очень много" [31]. Если таким путем не удалось построить удобоваримой структуры классов, мы пробуем концептуальный подход. В этом случае в центре внимания уделяется поведение объектов, когда они взаимодействуют друг с другом. Наконец, мы пробуем выделить прототипы и ассоциировать с ними объекты.

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

Объектно-ориентированный анализ

Теперь мы рассмотрим несколько проверенных практикой подходов к анализу объектно-ориентированных систем. Классические подходы. Разные ученые находят различные источники классов и… Например, Шлаер и Меллор предлагают следующих кандидатов в классы и объекты [32]: • Осязаемые предметы …

Ключевые абстракции

Как мы уже отмечали, определение ключевых абстракций включает в себя два процесса: открытие и изобретение. Мы открываем абстракции, слушая… Наиболее мощный способ выделения ключевых абстракций - сводить задачу к уже… Уточнение ключевых абстракций. Определив кандидатов на роли ключевых абстракций, мы должны оценить их по критериям,…

Идентификация механизмов

Рассмотрим требование, предъявляемое к автомобилю: нажатие на акселератор должно приводить к увеличению оборотов двигателя, а отпускание… Какую именно реализацию выберет разработчик, зависит от таких параметров, как… Подобно тому, как было бы недопустимой невежливостью со стороны клиента нарушать правила пользования сервером, также и…

ЧАСТЬ ВТОРАЯ

Метод

Какое нововведение приведет к успешному проекту, а какое к провалу не вполне предсказуемо. Каждая возможность создать что-то новое, будь то мост, самолет или небоскреб, ставит инженера перед выбором, который может казаться безграничным. Он может заимствовать сколько захочет все лучшее и полезное из тех существующих проектов, которые успешно противостоят разрушающим силам человека и природы, а может, напротив, решить улучшить те аспекты предыдущих проектов, которые сочтет нужным.

 

Генри Петроски (Henry Petroski)

Проектирование как человеческая деятельность

(То Engineer is Human)

Глава 5

Обозначения

Однако, хорошо продуманная и выразительная система обозначений очень важна для разработки. Во-первых, общепринятая система позволяет разработчику… "Разработка программного обеспечения всегда будет кропотливой работой...… 5.1. Элементы обозначений

Необходимость разных точек зрения

На рис. 5-1 представлены различные типы моделей (описанные в главе 1), которые мы считаем главными в объектно-ориентированном подходе. Через них… Наша система обозначений богата деталями, но это не означает, что в каждом… Как отмечает Вайнберг: "В некоторых областях (таких, как архитектура), в процессе проектирования графический план…

Модели и ракурсы

В каждом из двух измерений мы строим несколько диаграмм, которые дают нам вид моделей системы в различных ракурсах. Таким образом, модели системы… Рассмотрим для примера систему, включающую в себя несколько сотен классов; эти… Для простоты на диаграммах все сущности с одинаковыми именами в одной области видимости рассматриваются как ссылки на…

Логическая и физическая модели

При анализе мы должны задать следующие вопросы: Каково требуемое поведение системы? Каковы роли и обязанности объектов по поддержанию этого… Как было отмечено в предыдущей главе, чтобы выразить наши решения о поведении… При проектировании мы должны задать следующие вопросы относительно архитектуры системы: Какие существуют классы и…

Статическая и динамическая модели

Каждый класс может иметь собственную диаграмму переходов, которая показывает, как объект класса переходит из состояния в состояние под воздействием…

Инструменты проектирования

5.2. Диаграммы классов

Существенное: классы и отношения между ними

Диаграмма классов показывает классы и их отношения, тем самым представляя логический аспект проекта. Отдельная диаграмма классов представляет определенный ракурс структуры классов. На стадии анализа мы используем диаграммы классов, чтобы выделить общие роли и обязанности сущностей, обеспечивающих требуемое поведение системы. На стадии проектирования мы пользуемся диаграммой классов, чтобы передать структуру классов, формирующих архитектуру системы.

Два главных элемента диаграммы классов - это классы и их основные отношения.

Классы. На рис. 5-2 показано обозначение для представления класса на диаграмме. Класс обычно представляют аморфным объектом, вроде облака [Выбор графических обозначении - это трудная задача. Требуется осторожно балансировать между выразительностью и простотой, так что проектирование значков - это в большой степени искусство, а не наука. Мы взяли облачко из материалов корпорации Intel, документировавшей свою оригинальную объектно-ориентированную архитектуру iAPX432 [6]. Форма этого образа намекает на расплывчатость границ абстракции, от которых не ожидается гладкости и простоты. Пунктирный контур символизирует то, что клиенты оперируют обычно с экземплярами этого класса, а не с самим классом. Можно заменить эту форму прямоугольником, как сделал Румбах [7]:

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

Каждый класс должен иметь имя; если имя слишком длинно, его можно сократить или увеличить сам значок на диаграмме. Имя каждого класса должно быть уникально в содержащей его категории. Для некоторых языков, в особенности - для C++ и Smalltalk, мы должны требовать, чтобы каждый класс имел имя, уникальное в системе.

Рис. 5-2. Значок класса.

На некоторых значках классов полезно перечислять несколько атрибутов и операций класса. "На некоторых", потому что для большинства тривиальных классов это хлопотно и не нужно. Атрибуты и операции на диаграмме представляют прообраз полной спецификации класса, в которой объявляются все его элементы. Если мы хотим увидеть на диаграмме больше атрибутов класса, мы можем увеличить значок; если мы совсем не хотим их видеть - мы удаляем разделяющую черту и пишем только имя класса.

Как мы описывали в главе 3, атрибут обозначает часть составного объекта, или агрегата. Атрибуты используются в анализе и проектировании для выражения отдельных свойств класса [Точнее, атрибут эквивалентен отношению агрегации с физическим включением, метка которого совпадает с именем атрибута, а мощность равна в точности единице]. Мы используем следующий не зависящий от языка синтаксис, в котором атрибут может обозначаться именем или классом, или и тем и другим, и, возможно, иметь значение по умолчанию:

• A - только имя атрибута;
• :C - только класс;
• A:C - имя и класс;
• A:C=E - имя, класс и значение по умолчанию.

Имя атрибута должно быть недвусмысленно в контексте класса. В главе 3 говорилось, что операция - это услуга, предоставляемая классом. Операции обычно изображаются внутри значка класса только своим именем. Чтобы отличать их от атрибутов, к их именам добавляются скобки. Иногда полезно указать полную сигнатуру операции:

• N() - только имя операции;
• RN(Аргументы) - класс возвращаемого значения (R), имя и формальные параметры (если есть).

Имена операций должны пониматься в контексте класса однозначно в соответствии с правилами перегрузки операций выбранного языка реализации.

Общий принцип системы обозначений: синтаксис элементов, таких, как атрибуты и операции, может быть приспособлен к синтаксису выбранного языка программирования. Например, на C++ мы можем объявить некоторые атрибуты как статические, или некоторые операции как виртуальные или чисто виртуальные [В C++ члены, общие для всех объектов класса, объявляются статическими; виртуальной называют полиморфную операцию; чисто виртуальной называют операцию, за реализацию которой отвечает подкласс]; в CLOS мы можем пометить операцию как метод :around. В любом случае мы пользуемся спецификой синтаксиса данного языка, чтобы обозначить детали. Как описывалось в главе 3, абстрактный класс - это класс, который не может иметь экземпляров. Так как абстрактные классы очень важны для проектирования хорошей структуры классов, мы вводим для них специальный значок треугольной формы с буквой А в середине, помещаемый внутрь значка класса (рис. 5-3). Общий принцип: украшения представляют вторичную информацию о некой сущности в системе. Все подобные типы украшений имеют такой же вид вложенного треугольника.

Отношения между классами. Классы редко бывают изолированы; напротив, как объяснялось в главе 3, они вступают в отношения друг с другом. Виды отношений показаны на рис. 5-4: ассоциация, наследование, агрегация (has) и использование. При изображении конкретной связи ей можно сопоставить текстовую пометку, документирующую имя этой связи или подсказывающую ее роль. Имя связи не обязано быть глобальным, но должно быть уникально в своем контексте.

Значок ассоциации соединяет два класса и означает наличие семантической связи между ними. Ассоциации часто отмечаются существительными, например Employment (место работы), описывающими природу связи. Класс может иметь ассоциацию с самим собой (так называемая рефлексивная ассоциация). Одна пара классов может иметь более одной ассоциативной связи. Возле значка ассоциации вы можете указать ее мощность (см. главу 3), используя синтаксис следующих примеров:

• 1 - В точности одна связь
• N - Неограниченное число (0 или больше)
• 0..N - Ноль или больше
• 1..N - Одна или больше

 

Рис. 5-3. Значок абстрактного класса.

Рис. 5-4. Значки отношений между классами.

• 0..1 - Ноль или одна
• 3..7 - Указанный интервал
• 1..3, 7 - Указанный интервал или точное число

Обозначение мощности пишется у конца линии ассоциации и означает число связей между каждым экземпляром класса в начале линии с экземплярами класса в ее конце. Если мощность явно не указана, то подразумевается, что она не определена.

Обозначения оставшихся трех типов связи уточняют рисунок ассоциации дополнительными пометками. Это удобно, так как в процессе разработки проекта связи имеют тенденцию уточняться. Сначала мы заявляем о семантической связи между двумя классами, а потом, после принятия тактических решений об истинных их отношениях, уточняем эту связь как наследование, агрегацию или использование.

Значок наследования, представляющего отношение "общее/частное", выглядит как значок ассоциации со стрелкой, которая указывает от подкласса к суперклассу. В соответствии с правилами выбранного языка реализации, подкласс наследует структуру и поведение своего суперкласса. Класс может иметь один (одиночное наследование), или несколько (множественное наследование) суперклассов. Конфликты имен между суперклассами разрешаются в соответствии с правилами выбранного языка. Как правило, циклы в наследовании запрещаются. К наследованию значок мощности не приписывается.

Значок агрегации обозначает отношение "целое/часть" (связь "has") и получается из значка ассоциации добавлением закрашенного кружка на конце, обозначающем агрегат. Экземпляры класса на другом конце стрелки будут в каком-то смысле частями экземпляров класса-агрегата. Разрешается рефлексивная и циклическая агрегация. Агрегация не требует обязательного физического включения части в целое.

Знак использования обозначает отношение "клиент/сервер" и изображается как ассоциация с пустым кружком на конце, соответствующем клиенту. Эта связь означает, что клиент нуждается в услугах сервера, то есть операции класса-клиента вызывают операции класса-сервера или имеют сигнатуру, в которой возвращаемое значение или аргументы принадлежат классу сервера.

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

Рис. 5-5 показывает, как описывается в этих обозначениях задача обслуживания тепличной гидропонной системы. Эта диаграмма представляет только малую часть структуры классов системы. Мы видим здесь класс GardeningPlan (план выращивания), который имеет атрибут, названный crop (посев), одну операцию-модификатор execute (выполнить) и одну операцию-селектор canHarvest (можно собирать?). Имеется ассоциация между этим классом и классом EnvironmentalController (контроллер среды выращивания): экземпляры плана задают климат, который должны поддерживать экземпляры контроллера.

Рис. 5-5. Диаграмма классов гидропонной системы.

Эта диаграмма также показывает, что класс EnvironmentalController является агрегатом: его экземпляры содержат в точности по одному экземпляру классов Heater (нагреватель) и Cooler (охлаждающее устройство), и любое число экземпляров класса Light (лампочка). Оба класса Heater и Cooler являются подклассами абстрактного запускающего процесс класса Actuator, который предоставляет протоколы startUp и shutDown (начать и прекратить соответственно), и который использует класс Temperature.

Существенное: категории классов

Как объяснялось в главе 3, класс - необходимое, но недостаточное средство декомпозиции. Когда система разрастается до дюжины классов, можно заметить группы классов, связанные внутри, и слабо зацепляющиеся с другими. Мы называем такие группы категориями классов.

Многие объектно-ориентированные языки не поддерживают это понятие. Следовательно, выделение обозначений для категорий классов позволяет выразить важные архитектурные элементы, которые не могли быть непосредственно записаны на языке реализации [Среда программирования Smalltalk поддерживает концепцию категорий классов. Собственно это и подвигло нас на включение категорий в систему обозначений. Однако, в Smalltalk категории классов не имеют семантического содержания: они существуют только для более удобной организации библиотеки классов. В C++ категории классов связаны с концепцией компонент (Страуструп), они еще не являются чертой языка, хотя включение в него семантики пространства имен рассматривается [8]. (В настоящее время пространства имен включены в стандарт. - Примеч. ред.)].

Рис. 5-6. Значок категории классов.

Классы и категории классов могут сосуществовать на одной диаграмме. Верхние уровни логической архитектуры больших систем обычно описываются несколькими диаграммами, содержащими только категории классов.

Категории классов. Категории классов служат для разбиения логической модели системы. Категория классов - это агрегат, состоящий из классов и других категорий классов, в том же смысле, в котором класс - агрегат, состоящий из операций и других классов. Каждый класс системы должен "жить" в единственной категории или находиться на самом верхнем уровне системы. В отличие от класса, категория классов не имеет операций или состояний в явном виде, они содержатся в ней неявно в описаниях агрегированных классов.

На рис. 5-6 показан значок, обозначающий категорию классов. Как и для класса, для категории требуется имя, которое должно быть уникально в данной модели и отлично от имен классов.

Иногда полезно на значке категории перечислить некоторые из содержащихся в ней классов. "Некоторые", потому, что зачастую категории содержат довольно много классов, и перечислять их все было бы хлопотно, да это и не нужно. Так же, как список атрибутов и операций на значке класса, список классов в значке категории представляет сокращенный вид ее спецификации. Если мы хотим видеть на значке категории больше классов, мы можем его увеличить. Можно удалить разделяющую черту и оставить в значке только имя категории.

Категория классов представляет собой инкапсулированное пространство имен. По аналогии с квалификацией имен в C++, имя категории можно использовать для однозначной квалификации имен содержащихся в ней классов и категорий. Например, если дан класс A из категории B, то его полным именем будет A::B. Таким образом, как будет обсуждаться далее, для вложенных категорий квалификация имен простирается на произвольную глубину.

Некоторые классы в категории могут быть открытыми, то есть экспортироваться для использования за пределы категории. Остальные классы могут быть частью реализации, то есть не использоваться никакими классами, внешними к этой категории. Для анализа и проектирования архитектуры это различие очень важно, так как позволяет разделить обязанности между экспортируемыми классами, которые берут на себя общение с клиентами, и внутренними классами в категории, которые, собственно, выполняют работу. На самом деле, во время анализа закрытые аспекты категории классов можно опустить. По умолчанию все классы в категории определяются как открытые, если явно не указано противное. Ограничение доступа будет обсуждаться ниже.

Категория может использовать невложенные категории и классы. С другой стороны, и классы могут использовать категории. Для единообразия мы обозначаем эти экспортно-импортные отношения так же, как отношение использования между классами (см. рис. 5-4). Например, если категория A использует категорию B, это означает, что классы из A могут быть наследниками, или содержать экземпляры, использовать или быть еще как-то ассоциированы с классами из B.

Рис. 5-7. Диаграмма классов верхнего уровня для гидропонной системы.

Когда в категории слишком много общих классов, вроде базовых классов-контейнеров или других базовых классов, подобных Object в Smalltalk, возникают практические затруднения. Такие классы будут использоваться чуть ли не всеми другими категориями, загромождая корневой уровень диаграммы. Чтобы выйти из положения, такие категории помечаются ключевым словом global в левом нижнем углу значка, показывающим, что категория по умолчанию может быть использована всеми остальными.

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

Пример. На рис. 5-7 приведен пример диаграммы классов верхнего уровня для тепличного хозяйства. Это типичная многослойная система. Здесь абстракции, которые ближе к реальности (а именно активаторы и датчики климата и удобрений), располагаются на самых нижних уровнях, а абстракции, отражающие понятия пользователя, - ближе к вершине. Категория классов ТипыПосевов - глобальна, то есть ее услуги доступны всем другим категориям. На значке категории классов Планирование показаны два ее важных класса: GardeningPlan (план выращивания) с рис. 5-5 и PlanAnalyst (анализатор планов). При увеличении любой из восьми категорий классов, показанных на рисунке, обнаружатся составляющие их классы.

Рис. 5-8. Значок параметризованного класса.

Дополнительные обозначения

Параметризованные классы. В некоторых объектно-ориентированных языках программирования, в частности, C++, Eiffel и Ada можно создавать… Параметризованные классы достаточно сильно отличаются от обычных, что… Связь между параметризованным классом и его инстанцированием изображается пунктирной линией, указывающей на…

Реализация Мы ставим их как "засечки" на линии связи у источника. Например, на рис. 5-12 показано, что класс GrainCrop множественно наследует от классов Crop (посев) (открытый суперкласс) и FoodItem (пища) (защищенный суперкласс). Рис. 5-12. Значок управления доступом. FoodItem в свою очередь содержит от одного до двадцати трех закрытых экземпляров класса VitaminContent (содержание витаминов) и один открытый экземпляр класса CaloricEquivalent (калорийность). Заметим, что CaloricEquivalent мог бы быть записан как атрибут класса FoodItem, так как атрибуты эквивалентны агрегации, мощность которой равна 1:1. Кроме того, мы видим, что класс GrainCrop (посев зерновых) использует класс GrainYieldPredictor (предсказатель урожая зерновых) как часть своей реализации. Это обычно означает, что некоторый метод класса GrainCrop использует услуги, предоставляемые классом GrainYieldPredictor. Кроме уже рассмотренных в этом примере случаев, обычная ассоциация так же может быть украшена символами доступа. Метасвязь (связь между инстанцированным классом и его метаклассом) не может получить таких украшений. Символы ограничения доступа можно применять к вложенности во всех ее формах. На обозначении класса мы можем указать доступ к атрибутам, операциям или вложенным классам, добавив символ ограничения доступа в качестве префикса к имени. Например, на рис. 5-12 показано, что класс Crop имеет один открытый атрибут scientificName (ботаническое название), один защищенный - yield (урожай), и один закрытый - nutrientValue (количество удобрения). Такие же обозначения используются для вложенных классов или категорий классов. По умолчанию все вложенные классы и категории являются открытыми, но мы можем указать ограниченный доступ соответствующей меткой. Типы отношении. В некоторых языках встречаются настолько всепроникающие типы отношений, с настолько фундаментальной семантикой, что было бы оправдано введение новых символов. В C++, например, имеется три таких конструкции: static - переменная (или функция) класса; virtual - совместно используемый базовый класс в ромбовидной структуре наследования; friend - класс, которому даны права доступа к закрытым и защищенным элементам другого класса.   Рис. 5-13. Значки отношений. Логично использовать для них такое же украшение в виде треугольного значка, как и для абстрактного класса, но с символами S, V или F соответственно. Рассмотрим пример на рис. 5-13, который представляет другой ракурс классов, показанных на предыдущем рисунке. Мы видим, что базовый класс OrganicItem (органический компонент) содержит один экземпляр класса ItemDictionary (словарь компонентов) и что этот экземпляр содержится самим классом, а не его экземплярами (то есть он является общим для всех экземпляров). В общем случае мы указываем обозначение static на одном из концов ассоциации или на конце связи агрегации. Рассматривая класс GrainCrop, мы видим, что структура наследования приобретает ромбовидную форму (связи наследования, разветвившись, сходятся). По умолчанию, в C++ ромбовидная форма структуры наследования ведет к тому, что в классах-листьях дублируются структуры базового, дважды унаследованного класса. Чтобы класс GrainCrop получил единственную копию дважды унаследованных структур класса OrganicItem, мы должны применить виртуальное наследование, как показано на рисунке. Мы можем добавлять украшение виртуальной связи только к наследованию. Значок дружественности можно присоединить к любому типу связи, расположив значок ближе к серверу, подразумевая, что сервер считает клиента своим другом. Например, на рис. 5-13 класс PlanAnalyst дружит с классом Crop, а, следовательно, имеет доступ к его закрытыми и защищенным элементам, включая оба атрибута yield и scientificName. Физическое содержание. Как показано в главе 3, отношение агрегации является специальным случаем ассоциации. Агрегация обозначает иерархию "целое/часть" и предполагает, что по агрегату можно найти его части. Иерархия "целое/часть" не означает обязательного физического содержания: профсоюз имеет членов, но это не означает, что он владеет ими. С другой стороны, отдельная запись о посеве именно физически содержит в себе соответствующую информацию, такую, как имя посева, урожай и график подкормки. Рис. 5-14. Физическое содержание. Агрегация обычно выявляется при анализе и проектировании; уточнение ее как физического содержания является детализирующим, тактическим решением. Однако, распознать этот случай важно, во-первых, для правильного определения конструкторов и деструкторов классов, входящих в агрегацию, и, во-вторых, для генерации и последовательного исправления кода. Физическое содержание отмечается на диаграмме украшением на конце линии, обозначающей агрегацию; отсутствие этого украшения означает, что решение о физическом содержании не определено. В гибридных языках мы различаем два типа содержания: по значению целое физически содержит часть по ссылке целое физически содержит указатель или ссылку на часть. В чисто объектно-ориентированных языках, в особенности в Smalltalk, физическое содержание бывает только по ссылке. Чтобы отличить физическое присутствие объекта от ссылки на него, мы используем закрашенный квадратик для обозначения агрегации по значению и пустой квадратик - для агрегации по ссылке. Как будет обсуждаться позже, этот стиль украшений согласуется с соответствующей семантикой на диаграммах объектов. Рассмотрим пример, приведенный на рис. 5-14. Мы видим, что экземпляры класса CropHistory (история посева) физически содержат несколько экземпляров классов NutrientSchedule (график внесения удобрений) и ClimateEvent (климатическое событие). Физическое содержание частей агрегации по значению означает, что их создание или уничтожение происходит при создании или уничтожении самого агрегата. Таким образом, агрегация по значению гарантирует, что время жизни агрегата совпадает с временем жизни его частей. В противоположность этому, каждый экземпляр класса CropHistory обладает только ссылкой или указателем на один экземпляр класса Crop. Это означает, что времена жизни этих двух объектов независимы, хотя и здесь один является физической частью другого. Еще один случай - отношение агрегации между классами CropEncyclopedia (энциклопедия посевов) и CropHistory. В данном случае мы вообще не упоминаем физическое содержание. Диаграмма говорит о том, что эти два класса состоят в отношении "целое/часть", и что по экземпляру CropEncyclopedia можно найти соответствующий экземпляр CropHistory, но физическое содержание тут ни при чем. Вместо этого может быть разработан другой механизм, реализующий эту ассоциацию. Например, объект класса CropEncyclopedia запрашивает базу данных, и получает ссылку на подходящий экземпляр CropHistory. Роли и ключи. В предыдущей главе мы указали на важность описания различных ролей, играемых объектами в их взаимодействии друг с другом; в следующей главе мы изучим, как идентификация ролей помогает провести процесс анализа. Коротко говоря, роль абстракции - это то, чем она является для внешнего мира в данный момент. Роль обозначает потребность или способность, в силу которых один класс ассоциируется с другим. Текстовое украшение, описывающее роль класса, ставится рядом с любой ассоциацией, ближе к выполняющему роль классу, как это видно на рис. 5-15. На этом рисунке классы PlanAnalyst (анализатор планов) и Nutritionist (агрохимик) оба являются поставщиками информации для объекта класса CropEncyclopedia (они оба добавляют информацию в энциклопедию), а объекты класса PlanAnalyst являются также и пользователями (они просматривают материал из энциклопедии). В любом случае, роль клиента определяет индивидуальное поведение и протокол, который он использует. Обратим внимание также на рефлексивную ассоциацию класса PlanAnalyst: мы видим, что несколько экземпляров этого класса могут сотрудничать друг с другом и при этом они используют особый протокол, отличающийся от их поведения в ассоциации, например, с классом CropEncyclopedia. Рис. 5-15. Роли и ключи. На этом примере показана также ассоциация между классами CropEncyclopedia и Crop, но с другим типом украшения, которое представляет ключ (изображается как идентификатор в квадратных скобках). Ключ - это атрибут, значение которого уникально идентифицирует объект. В этом примере класс CropEncyclopedia использует атрибут scientificName, как ключ для поиска требуемой записи. Вообще говоря, ключ должен быть атрибутом объекта, который является частью агрегата, и ставится на дальнем конце связи-ассоциации. Возможно использование нескольких ключей, но значения ключей должны быть уникальны. Рис. 5-16. Значок ограничения. Ограничения. Как говорилось в главе 3, ограничение - это выражение некоторого семантического условия, которое должно сохраняться. Иначе говоря, ограничение - инвариант класса или связи, который должен сохраняться, если система находится в стабильном состоянии. Подчеркнем - в стабильном состоянии, потому что возможны такие переходные явления, при которых меняется состояние системы в целом и система находится во внутренне рассогласованном состоянии, так что невозможно соблюсти все наложенные ограничения. Соблюдение ограничений гарантируется только в стабильном состоянии системы. Мы используем для ограничений украшения, похожие на те, что использовались нами для обозначения ролей и ключей: помещаем заключенное в фигурные скобки выражение ограничения рядом с классом или связью, к которым оно прилагается. Ограничение присоединяется к отдельным классам, к ассоциации в целом или к ее участникам. На рис. 5-16 мы видим, что для класса EnviromentalController наложено ограничение на мощность, постулирующее, что в системе имеется не более 7 экземпляров этого класса. При отсутствии ограничения на мощность класс может иметь сколько угодно экземпляров. Обозначение для абстрактного класса, введенное ранее, является специальным случаем ограничения (нуль экземпляров), но так как это явление очень часто встречается в иерархиях классов, оно получило собственный тип украшения (треугольник с буквой А). Класс Heater (нагреватель) имеет ограничение другого типа. В рисунок включено требование гистерезиса в работе нагревателя: он не может быть включен, если с момента его последнего выключения прошло меньше пяти минут. Мы прилагаем это ограничение к классу Heater, считая, что контроль за его соблюдением возложен на экземпляры класса. На этой диаграмме изображены еще два типа ограничений: ограничение на ассоциации. В ассоциации между классами EnvironmentalController и Light требуется, чтобы отдельные источники света были уникально индексированы относительно друг друга в контексте данной ассоциации. Имеется еще ограничение, наложенное на ассоциации EnvironmentalController с классами Heater и Cooler, состоящее в том, что диспетчер не может включить нагреватель и охладитель одновременно. Это ограничение прикладывается к ассоциации, а не к классам Heater и Cooler, потому что его соблюдение не может быть поручено самим нагревателям и охладителям. При необходимости можно включить в выражение ограничения имена других ассоциаций с помощью квалифицированных имен, использованных в проекте. Например, Cooler:: запускает однозначно именует одну из ассоциаций класса-диспетчера. В нашей системе обозначений такие выражения часто используются в ситуации, когда один класс имеет ассоциацию (например, агрегацию) с двумя (или более) другими классами, но в любой момент времени каждый его экземпляр может быть ассоциирован только с одним из объектов. Ограничения бывают также полезны для выражения вторичных классов, атрибутов и ассоциаций [В терминологии Румбаха это называется производные сущности: для них он использует специальный значок. Нашего общего подхода к ограничениям достаточно, чтобы выразить семантику производных классов, атрибутов и ассоциации; этот подход облегчает повторное использование существующих значков и однозначное определение сущностей, от которых взяты производные]. Например, рассмотрим классы Adult (взрослые) и Child (дети), являющиеся подклассами абстрактного класса Person (Люди). Мы можем снабдить класс Person атрибутом dateofbirth (дата рождения) и добавить атрибут, называемый age (возраст), например, потому что возраст играет особую роль в нашей модели реального мира. Однако, age - атрибут вторичный: он может быть определен через dateofbirth. Таким образом, в нашей модели мы можем иметь оба атрибута, но должны указать ограничение, определяющее вывод одного из другого. Вопрос о том, какие атрибуты из каких выводятся, относится к тактике, но ограничение пригодится независимо от принятого нами решения. Аналогично, мы могли бы иметь ассоциацию между классами Adult и Child, которая называлась бы Parent (родитель), а могли бы включить и ассоциацию, именуемую Caretaker (попечитель), если это нужно в модели (например, если моделируются официальные отношения родительства в системе социального обеспечения). Ассоциация Caretaker вторична: ее можно получить как следствие ассоциации Parent; мы можем указать этот инвариант как ограничение, наложенное на ассоциацию Caretaker. Ассоциации с атрибутами и примечания. Последнее дополнительное понятие связано с задачей моделирования свойств ассоциаций; в системе обозначений задача решается введением элемента, который может быть приложен к любой диаграмме. Рассмотрим пример на рис. 5-17. На нем показана ассоциация многие-ко-многим между классами Crop и Nutrient. Эта ассоциация означает, что к каждому посеву применяется N (любое число) удобрений, а каждое удобрение применяется к N (любому числу) посевов. Класс NutrientSchedule является как бы свойством этого отношения многие-ко-многим: каждый его экземпляр соответствует паре из посева и удобрения. Чтобы выразить этот семантический факт, мы рисуем на диаграмме пунктирную линию от ассоциации Crop/Nutrient (ассоциация с атрибутом) к ее свойству - классу NutrientSchedule (атрибут ассоциации). Каждая уникальная ассоциация может иметь не больше одного такого атрибута и ее имя должно соответствовать имени класса-атрибута. Идея атрибутирования ассоциаций имеет обобщение: при анализе и проектировании появляется множество временных предположений и решений; их смысл и назначение часто теряются, потому что нет подходящего места для их хранения, а хранить все в голове - дело немыслимое. Поэтому полезно ввести обозначение, позволяющее добавлять произвольные текстовые примечания к любому элементу диаграммы. На рис. 5-17 имеется два таких примечания. Одно из них, приложенное к классу NutrientSchedule, сообщает нечто об ожидаемой уникальности его экземпляров (Выбирает из общего набора расписаний); другое (Получаем из базы данных удобрений) приложено к конкретной операции класса Nutrient и выражает наши пожелания к ее реализации. Рис. 5-17. Ассоциация с атрибутом и примечание. Для таких примечаний мы используем значки, похожие на бумажки, и соединяем их с элементом, к которому они относятся, пунктирной линией. Примечания могут содержать любую информацию: обычный текст, фрагменты программ или ссылки на другую документацию (все это может пригодиться при разработке инструментов проектирования). Примечания могут быть не связаны ни с каким элементом, это значит, что они относятся к самой диаграмме [Значок, который мы используем, похож на обозначение примечаний во многих windows-системах, особенно следующих традициям Macintosh. Непосредственными вдохновителями нашего обозначения были предложения Гамма, Хелпа, Джонсона и Влиссидеса [10]].

Спецификации

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

Существенное: состояния и переходы

Рис. 5-18. Значок состояния. Два основных элемента диаграммы состояний и переходов - это, естественно, состояния и переходы между ними.

Дополнительные понятия

Рис. 5-21. Действия, условные переходы и вложенные состояния. Действия, ассоциированные с состояниями и условные переходы. Как показано на рис. 5-18, с состояниями могут быть…

Спецификации

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

5.4. Диаграммы объектов

Существенное: объекты и их отношения

Рис. 5-23. Значок объекта. Объекты. На рис. 5-23 показан значок, который изображает объект на диаграмме объектов. Как и в диаграммах классов,…

Дополнительные понятия

Роли, ключи и ограничения. Выше мы говорили, что на диаграмме классов при изображении ассоциации рядом с нею может быть написана ее роль,… Рис. 5-26 дает пример использования этого дополнительного обозначения. Здесь… Используя те же обозначения, что и для диаграммы классов, мы можем указать ключи или ограничения, ассоциированные с…

Спецификации

Context: глобальный | категория | класс | операция В частности, область видимости диаграммы объектов может быть глобальной, или в…

Существенное: объекты и их взаимодействия

Диаграммы взаимодействия не вводят новых понятий или обозначений. Скорее, они берут существенные элементы диаграммы объектов и перестраивают их. Как… Диаграммы взаимодействий часто лучше диаграмм объектов передают семантику…

Дополнительные понятия

Пояснения. Для сложных сценариев, использующих условия или итерации, диаграмма объектов может быть дополнена пояснениями. Как показано на примере… Передача управления. Ни простейшие диаграммы объектов, ни диаграммы… 5.6. Диаграммы модулей

Существенное: модули и их зависимость

Некоторые языки, особенно Smalltalk, не имеют ничего подобного физической архитектуре, сформированной модулями; в таких случаях диаграммы модулей не… Основными элементами диаграммы модулей являются модули и их зависимости. Модули. На рис. 5-32 сведены обозначения различных типов модулей. Первые три значка - это файлы, различающиеся своими…

Глава 6

Процесс

Процесс объектно-ориентированного анализа и проектирования не сводится к сумме рецептов, однако он определен достаточно хорошо, чтобы быть… 6.1. Основные принципы

Характерные черты удачных проектов

Архитектура. Признак добротности архитектуры - ее концептуальное единство и целостность. По утверждению Брукса, "концептуальная целостность в… Не существует единственно верного способа классифицировать абстракции и… Как правило, хорошая архитектура тяготеет к объектной ориентированности. Это не означает, что любая…

Рациональный процесс проектирования

Упорядоченный процесс проектирования чрезвычайно важен для организаций, разрабатывающих программное обеспечение. Хэмфри перечисляет следующие пять… К сожалению, как отмечают Парнас и Клеменс: "Мы никогда не отыщем… С приобретением опыта у организации встает вопрос: "Как примирить творчество и новации с возрастающей…

Обзор

Микропроцесс объектно-ориентированной разработки приводится в движение потоком сценариев и архитектурных продуктов, которые порождаются и последовательно уточняются в макропроцессе. Микропроцесс, по большей части, - повседневный труд отдельного разработчика или небольшого коллектива разработчиков.

Микропроцесс относится в равной степени к программисту и архитектору программной системы. С точки зрения программиста, микропроцесс предлагает руководство в принятии бесчисленного числа ежедневных тактических решений, которые являются частью процесса создания и подгонки архитектуры системы. С точки зрения архитектора, микропроцесс является основой для развития архитектуры и опробования альтернатив.

В микропроцессе традиционные фазы анализа и проектирования умышленно перемешаны, а управление осуществляется "по возможности". Как отмечает Страуструп, "не существует рецептов, которые могли бы заменить ум, опыт и хороший вкус в проектировании и программировании... Различные фазы программного проекта, такие, как проектирование, программирование и тестирование, неотделимы друг от друга" [11].

Как показано на рис. 6-1, микропроцесс обычно состоит из следующих видов деятельности:

• выявление классов и объектов на данном уровне абстракции;
• выяснение семантики этих классов и объектов;
• выявление связей между этими классами и объектами;
• спецификация интерфейса и реализация этих классов и объектов.

Теперь рассмотрим каждый из этих видов деятельности подробно.

Выявление классов и объектов

Цель. Цель выявления классов и объектов состоит в том, чтобы найти границы предметной области. Кроме того, эта деятельность является первым шагом в продумывании объектно-ориентированной декомпозиции разрабатываемой системы.

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

Результаты. Главным результатом этого шага является обновляющийся по мере развития проекта словарь данных. Вначале достаточно составить список действующих лиц, состоящий из всех заметных классов и объектов, названых именами, отражающими их смысл [12]. Когда словарь разрастется, можно сделать простейшую базу данных, или более специальный инструмент проектирования, непосредственно поддерживающий выбранный метод разработки [Формально, словарь данных объектно-ориентированной разработки должен содержать спецификации каждого элемента архитектуры]. В своих более формальных разновидностях словарь данных служит предметным указателем для всех остальных компонентов проекта, включая диаграммы и спецификации обозначений объектно-ориентированного проектирования.

Рис. 6-1. Микропроцесс.

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

Создание словаря данных на этом шаге дает три существенных выигрыша. Во-первых, сама работа с ним помогает выработать общепринятую и исчерпывающую терминологию, которой можно пользоваться на протяжении всего проекта. Во-вторых, словарь - естественное оглавление ко всем материалам проекта и система точек входа для доступа к проекту в произвольном порядке. Это особенно полезно, когда в команду принимается новый разработчик, который должен быстро войти в курс дел. В-третьих, словарь данных позволяет архитектору окинуть весь проект единым взглядом, что может привести к открытию новых общностей, которые иначе могли бы быть упущены.

Виды деятельности. Как мы описывали в главе 4, выявление классов и объектов связано с двумя видами творческих актов: открытием и изобретением.

Не каждый член команды должен быть равно искусен во всем. Аналитики, особенно работающие с экспертами в предметной области, должны уметь хорошо обнаруживать абстракции, то есть находить осмысленные классы и объекты в предметной области. Тем временем архитекторы и старшие разработчики придумывают классы и объекты, решающие чисто программистские проблемы. Мы обсудим природу этих творческих актов в следующей главе.

В любом случае основой для выявления классов и объектов служат методы классификации, описанные в главе 4. Обычный порядок действий таков:

• Применить классический подход к классификации (см. раздел 4.2, "Объектно-ориентированный анализ"), чтобы получить множество кандидатов в классы и объекты. В начале жизненного цикла хорошими стартовыми точками являются материальные элементы и их роли. Затем исследовать последовательности событий, что даст другие абстракции первого и второго порядка: в конце концов, для каждого события мы должны иметь объект, который отвечает за его обнаружение и/или обработку.
• Применить технику анализа поведения (см. там же) и выявить абстракции, которые непосредственно связаны с функциональными точками системы. Функциональные точки системы, как будет сказано подробнее в этой главе, берутся из макропроцесса и представляют отдельные проверяемые и внешне наблюдаемые поведения системы. Как и в случае событий, для каждого поведения можно найти классы и объекты, которые инициируют его и участвуют в нем.
• Для соответствующих сценариев, созданных в макропроцессе, применить технику анализа вариантов (см. там же). В начале жизненного цикла мы исследуем самые общие сценарии поведения системы. В процессе разработки мы постепенно переходим ко все более детализированным сценариям, добираясь до самых темных уголков поведения системы.

В каждом из этих подходов CRC-карточки являются эффективным катализатором "мозгового штурма" и помогают теснее сплотить коллектив, подталкивая его членов к общению [Это ужасно банально, но некоторые проектировщики программ и в самом деле не очень общительны].

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

Путевые вехи и характеристики. Мы благополучно завершим эту фазу, когда будем иметь достаточно стабильный словарь данных. Поскольку микропроцесс развивается итеративно, следует ожидать, что словарь будет закончен и закрыт лишь на очень поздней стадии проекта. Пока нас удовлетворяет обильный, даже избыточный набор абстракций с содержательными именами и разумным распределением обязанностей.

Признаком качества, следовательно, будет то, что словарь не подвергается серьезным изменениям каждый раз, когда мы проходим новую итерацию микропроцесса. Неустойчивость словаря показывает, что разработчики еще не достигли желаемого, или в архитектуре что-то не так. По ходу разработки мы можем контролировать устойчивость нижних уровней архитектуры, отслеживая результаты локальных изменений взаимодействующих абстракций.

Выяснение семантики классов и объектов

Цель. Цель выяснения семантики классов и объектов - определить поведение и атрибуты каждой абстракции, выявленной на предыдущем шаге. При этом мы уточняем намеченные абстракции, продуманно и измеримо распределяя между ними обязанности.

На стадии анализа мы применяем этот шаг, чтобы распределить обязанности между различными видами поведения системы. На стадии проектирования мы применяем процедуру выяснения семантики, чтобы четко распределить обязанности между частями реализации. При реализации мы продвигаемся от описаний ролей и обязанностей в свободной форме к спецификациям конкретных протоколов для каждой абстракции и, в конечном счете, - к точным сигнатурам каждой операции.

Результаты. На этом шаге получаются несколько результатов. Первым является уточнение словаря данных, с помощью которого мы изначально присвоили обязанности абстракциям. В ходе проектирования мы можем выработать спецификации к каждой абстракции (как описано в главе 5), перечисляя имена операций в протоколе каждого класса. Затем, как можно скорее, мы выразим интерфейсы этих классов на языке реализации. Для C++ это означает создание .h-файлов, в Ada - спецификаций пакетов, в CLOS - обобщенных функций для каждого класса, в Smalltalk - это объявление, но не реализация методов каждого класса. Если проект связан с базой данных, особенно с объектно-ориентированной, на этом шаге мы получаем общий каркас нашей схемы данных.

В добавление к этим, по сути тактическим решениям, мы составляем диаграммы объектов и диаграммы взаимодействий, передающие семантику сценариев, создаваемых в ходе макропроцесса. Эти диаграммы формально отражают рас-кадровку каждого сценария и, таким образом, описывают явное распределение обязанностей среди взаимодействующих объектов. На этом шаге впервые появляются конечные автоматы для представления некоторых абстракций.

Чтобы команда разработчиков могла развивать согласованный язык обозначений и для учета обязанностей каждой абстракции, мы можем, как и на предыдущем шаге, использовать специализированную базу данных или другие, более специфические инструменты проектирования. Когда мы напишем на выбранном языке формальные интерфейсы классов, мы можем использовать наши инструменты проектирования для проверки и гарантии выполнения принятых решений.

Главная выгода большей формальности результатов на этом шаге состоит в том, что она помогает разработчику увидеть назначение всех протоколов абстракции. Невозможность четко определить смысл - признак зыбкости самих абстракций.

Виды деятельности. С этим шагом связано три вида деятельности: раскадровка, проектирование изолированных классов и поиск шаблонов.

Главными объектами раскадровки являются основные и второстепенные сценарии, полученные в макропроцессе. В ходе этой деятельности происходит нисходящее выяснение семантики. Там, где это касается функциональных точек системы, принимаются стратегические решения. Типичный ход выполнения действий может быть таким:

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

Неформально мы можем использовать для раскадровки CRC-карточки. Для большей формальности команде разработчиков следует составить диаграммы объектов и взаимодействий. На стадии анализа раскадровка обычно выполняется командой, включающей, как минимум, аналитика, эксперта в предметной области, архитектора и контролера качества. На стадии проектирования и позже, при реализации, раскадровка выполняется архитектором и старшими разработчиками для доводки стратегических решений, и отдельными разработчиками - для доводки тактических решений. Привлечение дополнительных членов команды к участию в раскадровке - в высшей степени эффективный путь обучения начинающих разработчиков и передачи им сложившегося видения архитектуры.

В начале разработки проекта мы можем задавать семантику классов и объектов в свободной форме, просто описывая обязанности каждой абстракции. Обычно достаточно фразы или предложения; если этого мало - мы встречаем верный признак того, что данная обязанность является чрезмерно сложной и должна разделиться на меньшие. На более поздних стадиях разработки, когда мы будем заниматься доводкой протоколов отдельных абстракций, можно указать имена специфических операций, не определяя их полные сигнатуры, которые мы выясним потом. Таким образом, мы получим соответствие: каждая обязанность выполняется набором операций, а каждая операция как-либо участвует в выполнении обязанностей соответствующей абстракции. После этого, чтобы отразить динамическую семантику протоколов классов [Как мы описывали в главе 3, протокол определяет, что некоторые операции должны вызываться в определенном порядке. Для всех случаев кроме самых тривиальных операции редко встречаются в одиночестве; выполнение каждой из них имеет свои предусловия, проверка которых часто требует вызова других операции], имеющих управляемое событиями или зависящее от состояния поведение, мы можем построить конечные автоматы для них.

На этом шаге важно сосредоточить внимание больше на поведении, чем на структуре. Атрибуты представляют структурные элементы, а, значит, есть опасность, особенно на ранних стадиях анализа, преждевременным указанием некоторых атрибутов стеснить реализационные решения. Атрибуты должны идентифицироваться на этом этапе лишь настолько, насколько они необходимы в построении концептуальной модели сценария.

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

• Выбрать одну абстракцию и перечислить ее роли и обязанности.
• Определить необходимое множество операций, удовлетворяющих этим обязанностям. Попытаться, где возможно, использовать операции для концептуально схожих ролей и обязанностей повторно.
• Рассмотреть каждую операцию абстракции: если она не примитивна - выделить и определить примитивы. Составные операции могут быть оставлены в самом классе (либо из-за их общности, либо по соображениям эффективности) или могут быть отправлены в утилиту классов (если они будут часто изменяться). Где это возможно следует рассмотреть минимальный набор примитивных операций.
• Учесть конструирование, копирование и уничтожение объектов [13]. Если не имеется причин поступить иначе, лучше иметь общие стратегические принципы для таких операций, чем позволить отдельным классам вводить свои собственные решения.
• Придать завершенность: добавить другие примитивные действия, которые не нужны существующим клиентам, но "округляют" абстракцию, что повышает вероятность использования ее новыми клиентами. Помня, что невозможно иметь полную завершенность, стремиться к простоте.

Важно избегать преждевременного определения отношения наследования - это часто ведет к потере целостности типа.

На ранних этапах разработки проектировать отдельные классы можно изолировано. Однако, как только мы определим структуры наследования, этот шаг будет включать в себя размещение операций в иерархии классов. Рассматривая операции, связанные с некоторым уровнем абстракции, мы должны решить, на каком уровне абстракции их разместить. Операции, которые могут быть использованы несколькими классами одного уровня, должны быть помещены в их общий суперкласс, который, возможно, придется создать. Действия, которые совместно используются никак не связанными классами, должны быть инкапсулированы в класс-примесь.

Третий вид деятельности - поиск шаблонов - связан с обобществлением абстракций. Выявляя семантику классов и объектов, мы должны отмечать шаблоны поведения, которые могут пригодиться где-нибудь еще. Этот процесс может проистекать в следующем порядке:

• Имея полный набор сценариев на этом уровне абстракции, найти шаблоны взаимодействия абстракций. Такие взаимодействия могут представлять неявные идиомы или механизмы. Они должны быть исследованы, чтобы гарантировать, что не имеется никаких необоснованных различий в вызовах операций. Нетривиальные шаблоны взаимодействия нужно явно документировать как стратегические решения, чтобы они по возможности могли быть повторно использованы, а не изобретались заново. Это повышает архитектурную целостность.
• Имея набор обязанностей для данного уровня абстракции, отыскать шаблоны поведения. Общие роли и обязанности должны быть унифицированы в форме общих классов - базовых, абстрактных или примесей.
• Если уже специфицированы конкретные операции, найти шаблоны среди сигнатур операций. Если среди них встречаются часто повторяющиеся, устранить все непринципиальные различия и ввести классы-примеси или утилиты классов.

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

Путевые вехи и характеристики. Мы благополучно завершим этот шаг, когда будем иметь более или менее достаточный, примитивный и полный набор обязанностей и/или операций для каждой абстракции. В начале разработки достаточно иметь неформальный список обязанностей, а в дальнейшем мы постепенно уточняем семантику.

Качественные показатели включают все эвристики классов, описанные в главе 3. Сложные и туманные обязанности и операции говорят о том, что абстракции еще недостаточно определены. Невозможность написать конкретный файл заголовков или как-либо по другому формализовать интерфейс классов также говорит о том, что абстракции плохо сформулированы, или что основные понятия определяли не те люди [Остерегайтесь аналитиков и архитекторов, если они не хотят или не могут выразить конкретно семантику своих абстракции; это признак надменности или беспомощности].

При просмотре сценариев ожидайте бурных дебатов. Это помогает разработчикам делиться архитектурными представлениями и развивать искусство определения абстракций. Не проверенные абстракции не стоит пытаться кодировать.

Выявление связей между классами и объектами

Цель. Цель выявления связей между классами и объектами - уточнить границы каждой обнаруженной ранее в микропроцессе абстракции и опознать все сущности, с которыми она взаимодействует. Это действие формализует концептуальное и физическое размежевание между абстракциями, начатое на предыдущем шаге.

Мы применяем этот шаг в анализе для спецификации связей между классами и объектами (включая некоторые важные отношения наследования и агрегации).

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

Результаты. Основными результатами этого шага являются диаграммы классов, объектов и модулей. Хотя в конце концов мы должны выразить наши решения, принятые при анализе и проектировании, на языке программирования, диаграммы дают более широкий обзор архитектуры и, кроме того, позволяют раскрыть отношения, которые с трудом формулируются на используемом языке реализации.

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

Нет ни возможности, ни необходимости создавать исчерпывающий набор диаграмм, которые определили бы все возможные виды связей между нашими абстракциями. Нужно сосредоточиться на "интересных отношениях", причем подразумевается, что в число "интересных" входят те связи между абстракциями, которые отражают фундаментальные архитектурные решения или выражают детали, необходимые для реализации.

Результатом анализа на данном этапе являются диаграммы классов, которые содержат категории классов, идентифицирующие кластеры абстракций, сгруппированные по слоям и разделам. Эти результаты пригодятся и для документирования.

При анализе мы также строим диаграммы объектов, завершая тем самым просмотр сценариев, начатый на предыдущем шаге. Отличие в том, что мы можем теперь рассмотреть взаимодействия между классами и объектами и обнаружить скрытые ранее общие механизмы взаимодействия, которыми следует воспользоваться. Обычно это приводит к локальным перестройкам структуры наследования. При проектировании мы пользуемся диаграммами объектов вместе с более детализированным описанием состояний, чтобы показать действие наших механизмов в динамике. Явный результат этого шага - набор диаграмм, которые идентифицируют механизмы взаимодействия.

При реализации мы должны принять решения о физическом разбиении нашей системы на модули и о распределении процессов по процессорам. Эти решения мы можем выразить на диаграммах модулей и процессов.

На этом же шаге также обновляется словарь данных. В нем отражаются распределения классов и объектов по категориям и модулей по подсистемам.

Основная польза полученных результатов в том, что они помогают наглядно показать и понять отношения, которыми связаны концептуально и физически далекие сущности.

Виды деятельности. С этим шагом связано три вида деятельности: спецификация ассоциаций, идентификация различных взаимодействий и уточнение ассоциаций. Спецификация ассоциаций является одним из основных действий в анализе и на ранней стадии проектирования. Как объяснялось в главе 3, ассоциации семантически слабы: они обозначают только некоторую семантическую зависимость, роль каждого участника связи и кардинальность связи и, возможно, направление допустимого перехода. Однако для анализа и ранней стадии проектирования этого часто достаточно, ибо передаются все важные детали связей между двумя абстракциями, при этом предохраняя нас от поспешных решений о реализации. Типичный порядок выполнения данного этапа таков:

• Выбрать множество классов данного уровня абстракции или ассоциированных с некоторым набором сценариев; нанести на диаграммы все важнейшие операции и атрибуты, необходимые для иллюстрации существенных свойств моделируемой задачи.
• Выяснить наличие зависимости между каждыми двумя классами и установить ассоциацию, если она присутствует. Необходимость перехода от одного объекта к другому и неизбежность использования некоторого поведения другого объекта являются причиной введения ассоциации. Чтобы устранить косвенные зависимости, следует ввести новые абстракции, которые служили бы агентами или посредниками. Некоторые ассоциации могут быть сразу идентифицированы как отношение "частное/общее" или агрегации.
• Для каждой ассоциации определить роль каждого участника, если необходимо уточнить кардинальность и выявить другие ограничения.
• Проверить годность этих решений, для чего просмотреть сценарий и убедиться, что имеющиеся ассоциации необходимы и достаточны для получения требуемых переходов и поведения абстракций этого сценария.

Диаграммы классов - основные модели, получаемые на данном этапе. Идентификация взаимодействий происходит главным образом при проектировании и, как описано в главе 4, является задачей классификации. А, значит, она также требует творчества и интуиции. В зависимости от текущего состояния макропроцесса, мы должны рассмотреть несколько различных типов взаимодействия:

• Как часть формулировки наших стратегических решений, мы должны составить для каждого определенного на предыдущем шаге механизма диаграмму объектов, иллюстрирующую его динамическую семантику. Проверить каждый механизм в центральных и периферийных сценариях. Где возможен параллелизм, назначить объекты - актеры, агенты и серверы и способы синхронизации между ними. При этом может понадобиться ввести новые связи между объектами и устранить неиспользованные или избыточные.
• Если между классами наблюдается общность, необходимо поместить эти классы в иерархию "общее/частное". Как говорилось в главе 3, обычно лучше создать "лес" классов, чем единое дерево. На предыдущем шаге мы уже определили кандидатов на базовые, абстрактные классы и классы-примеси; теперь нужно разместить их в структуре наследования. Для существенных классов следует рассмотреть диаграммы классов и оценить их качество, согласно эвристикам главы 3. В частности, требует особого внимания иерархическая структура: она не должна быть слишком высокой или слишком короткой, чересчур широкой или узкой. Там, где встречаются шаблоны в структуре или поведении, нужно реорганизовать иерархию так, чтобы максимизировать общность (но не в ущерб простоте).
• Как часть архитектурного проектирования, мы должны рассмотреть группирование классов в категории и организацию модулей в подсистемы. Это - стратегические решения. Архитекторы могут использовать диаграммы классов, чтобы определить иерархию категорий классов, которая формирует слои и разделы разрабатываемой системы. Обычно это делается сверху вниз. Имея глобальное представление о системе, выделяют основные абстракции, выполняющие главные обязанности системы, которые являются логически связными и могут изменяться независимо. Архитектуру также можно модернизировать снизу вверх, когда при каждом прохождении через микропроцесс идентифицируются семантически замкнутые группы классов. Нужно также принять решения о распределении классов по категориям. Если существующие категории слишком раздуваются или обнаруживаются новые группы классов, можно ввести новые категории или реорганизовать старые. Выявление модулей (для физической модели системы) выполняется аналогично и принятые решения отражаются на диаграммах модулей.
• Распределение классов и объектов по модулям является до некоторой степени локальным решением и чаще всего отражает отношения видимости абстракций. Как мы указывали в главе 5, отображение логической модели в физическую дает возможность разработчику открыть или ограничить доступ к каждой абстракции или упаковать вместе логически связанные абстракции, которые предполагается изменять по отдельности. Как мы обсудим в следующей главе, на отображение логической модели в физическую влияет также распределение обязанностей в команде проектировщиков. В любом случае все принятые решения можно выразить в виде диаграммы модулей.

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

Отношения наследования, агрегации, инстанцирования и использования - важнейшие типы ассоциаций, представляющие для нас интерес вместе с такими свойствами, как метки, роли, кардинальность и т.д. Типичный порядок уточнения ассоциаций таков:

• Имея набор классов, уже разбитый на группы, следует найти шаблоны поведения, указывающие на возможную связь "общее/частное". Далее необходимо разместить эти классы в существующей структуре наследования или построить новую подходящую структуру.
• Если имеются шаблоны структуры, то, используя наследование с классами-примесями или агрегацию, попробовать ввести новые классы, отражающие общность структуры.
• Найти классы с похожим поведением, которые либо находятся на одном уровне, либо еще не входят в структуру наследования и рассмотреть возможность введения общих параметризованных классов.
• Рассмотреть существующие ассоциации с точки зрения переходов между ними и ограничить их насколько возможно. Если не требуется двустороннего перехода, считать связь простым отношением использования.
• Определить тактические детали: указать роли, ключи, кардинальность, дружественность и т.д. Не требуется излишне детализировать: достаточно включить лишь важные результаты анализа и проектирования или то, что необходимо для реализации.

Путевые вехи и характеристики. Мы благополучно завершим эту фазу, когда достаточно полно определим семантику и связи интересующих абстракций, чтобы приступить к началу реализации.

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

Реализация классов и объектов

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

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

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

Чтобы раскрыть связи между логическим и физическим в нашей реализации системы, мы вводим диаграммы модулей, которые можно затем использовать, чтобы наглядно показать отображение нашей архитектуры в ее программную реализацию. Далее можно применить специфические инструментальные средства, которые позволяют либо генерировать код из диаграмм, либо восстанавливать диаграммы по реализации.

В этот шаг входит и обновление словаря данных, включая новые классы и объекты, которые были выявлены или изобретены при реализации существующих абстракций. Эти новые абстракции являются частью исходной информации для следующего цикла микропроцесса.

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

На стадии анализа результаты этого действия относительно абстрактны: мы не так обеспокоены собственно реализацией, как заинтересованы в отыскании новых абстракций, которым можно делегировать обязанности. На стадии проектирования, особенно на поздних стадиях проектирования классов, мы действительно переходим к практическим решениям.

Типичный порядок действий таков:

• Пересмотреть протокол каждого класса. Идентифицировать стереотипы его использования объектами-клиентами, чтобы определить, какие операции являются центральными и, следовательно, должны быть оптимизированы. Для облегчения реализации разработать точные сигнатуры всех важнейших операций.Рассмотреть возможность использования параметризованных классов, закрытого или защищенного наследования в реализации. Выбрать подходящие классы-примеси или параметризованные классы (или создать новые, если задача достаточно общая) и соответствующим образом изменить структуру наследования.
• Рассмотреть объекты, которым можно делегировать обязанности. Для достижения эффективности может потребоваться незначительная реорганизация обязанностей и/или протокола абстракции нижнего уровня.
• Если семантика абстракции не может быть выражена через наследование, инстанцирование или делегирование, рассмотреть подходящее представление из примитивов языка. Выбрать то представление, которое оптимизирует стереотипы использования, учитывая важность операций с точки зрения объектов-клиентов абстракции. Однако помните, что невозможно оптимизировать каждый случай использования. Получив эмпирическую информацию из последовательных версий-прототипов, мы можем выделить абстракции, которые неэффективно используют время или память и улучшить их реализацию, не опасаясь нарушить предположения клиентов относительно нашей абстракции.
• Выбрать подходящий алгоритм для каждой операции. Ввести вспомогательные операции для расчленения сложных алгоритмов на более простые или более пригодные для повторного использования части. Рассмотреть возможные компромиссы, в частности, сделать выбор между хранением и вычислением отдельных членов-данных.

Путевые вехи и характеристики. На стадии анализа мы считаем, что благополучно завершили фазу реализации, когда идентифицировали все важные абстракции из тех, что необходимы для выполнения обязанностей абстракций, выявленных на этом цикле микропроцесса. На стадии проектирования реализация считается благополучно завершенной, когда мы получили исполнимую или почти исполнимую программную модель наших абстракций.

Главным показателем благополучия на этой фазе является простота. Сложные, неуклюжие или неэффективные реализации свидетельствуют о недостатках самой абстракции или о плохом ее представлении.

6.3. Макропроцесс проектирования

Обзор

Макропроцесс является контролирующим по отношению к микропроцессу. Макропроцесс предписывает ряд измеримых результатов и действий, которые позволяют команде разработчиков оценить риск, внести заблаговременные изменения в микропроцесс и сосредоточиться на коллективном анализе и проектировании. Макропроцесс - это деятельность всего коллектива в масштабе от недель до месяцев.

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

Макропроцесс заботит в первую очередь технического руководителя команды разработчиков, цели которого несколько отличаются от задач отдельного разработчика. Они оба заинтересованы в качестве конечного программного продукта, удовлетворяющем требованиям заказчика [Ну, конечно, не все, а большинство. К сожалению, некоторые менеджеры больше заинтересованы в развитии своей империи, чем в развитии программного продукта. Прибавьте к этому предыдущее примечание относительно аналитиков и проектировщиков. Я думаю, Данте мог бы найти для них подходящее место]. Однако, конечного пользователя мало волнует, правильно ли использованы в проекте параметризованные классы или полиморфизм; заказчик гораздо более обеспокоен сроками, качеством, полнотой и правильностью работы программы. Поэтому макропроцесс сконцентрирован на управлении риском и выявлении общей архитектуры - двух управляемых компонентах, имеющих решающее значение для сроков, полноты и качества проекта.

В макропроцессе в большой степени сохранены традиционные фазы анализа и проектирования и процесс в меру упорядочен. Как показано на рис. 6-2, макропроцесс обычно включает следующие действия:

• Выявление сущности требований к программному продукту (концептуализация).
• Разработка модели требуемого поведения системы (анализ).
• Создание архитектуры для реализации (проектирование).
• Итеративное выполнение реализации (эволюция).
• Управление эволюцией продукта в ходе эксплуатации (сопровождение).

 

Рис. 6-2. Макропроцесс.

У всех нетривиальных программных разработок макропроцесс продолжается и после создания и внедрения системы. Это особенно видно на примере организаций, специализирующихся на создании семейств программ, на которые часто выделяются значительные капиталовложения.

Основная философия макропроцесса состоит в постепенном развитии. Как его определяет Вонк, "при разработке методом последовательного развития, система выстраивается шаг за шагом, причем каждая новая версия содержит функциональность предыдущей, плюс новые функции" [14]. Этот подход чрезвычайно хорошо сочетается с объектно-ориентированной парадигмой и дает много возможностей для управления риском. Как утверждает Гилб: "Постепенная передача программ заказчику изобретена для того, чтобы заранее предупредить нас о надвигающихся неприятностях" [15].

Теперь детально рассмотрим каждое действие в макропроцессе. Естественно, одним из показателей зрелости организации, ведущей разработку, является знание случаев, когда надо обойти эти правила, что мы будем отдельно отмечать в нашем обзоре.

Концептуализация

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

Анализ

Цель. Как утверждает Меллор, "цель анализа - дать описание задачи. Описание должно быть полным, непротиворечивым, пригодным для чтения и обозрения всеми заинтересованными сторонами, реально проверяемым" [16]. Говоря нашим языком, цель анализа - представить модель поведения системы.

Надо подчеркнуть, что анализ сосредоточен не на форме, а на поведении. На этой фазе неуместно заниматься проектированием классов, представлением или другими тактическими решениями. Анализ должен объяснить, что делает система, а не то, как она это делает. Любое, сделанное на стадии анализа (вопреки этому правилу) утверждение о том "как", может считаться полезным только для демонстрации поведения системы, а не как проверяемое требование к ее проектированию.

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

Сосредоточившись на поведении, мы приступаем к выяснению функциональных точек системы. Функциональные точки, впервые описанные Аланом Альбрехтом, обозначают видимые извне и поддающиеся проверке элементы поведения системы [17]. С точки зрения конечного пользователя, функциональная точка представляет некоторое простейшее действие системы в ответ на некоторое событие [Как отмечает Дрегер, в теории управления информационными системами функциональная точка представляет отдельную бизнес-функцию конечного пользователя [18]]. Функциональные точки часто (но не всегда) обозначают отображение входов на выходы и таким образом представляют преобразования, совершаемые системой. С точки зрения аналитика, функциональные точки представляют кванты поведения. Действительно, функциональные точки - мера сложности системы: чем их больше, тем она сложнее. На стадии анализа мы передаем семантику функциональных точек сценариями.

Анализ никогда не происходит независимо. Мы не стремимся к исчерпывающему пониманию поведения системы и даже утверждаем, что сделать полный анализ до начала проектирования не только невозможно, но и нежелательно. Процесс построения системы поднимает вопросы о ее поведении, на которые реально нельзя дать гарантированный ответ, занимаясь только анализом. Достаточно выполнить анализ всех первичных элементов поведения системы и некоторого количества вторичных, добавляемых для гарантии того, что никакие существенные шаблоны поведения не пропущены.

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

Результаты. ДеШампо считает, что результатом анализа должно быть описание назначения системы, сопровождаемое характеристиками производительности и перечислением требуемых ресурсов [19]. В объектно-ориентированном проектировании мы получаем такие описания с помощью сценариев. Каждый сценарий представляет одну функциональную точку. Мы используем первичные сценарии для иллюстрации ключевого поведения и вторичные для описания поведения в исключительных ситуациях.

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

Часто эти результаты анализа объединяют в один формальный документ, который формулирует требования анализа к поведению системы, иллюстрируя их диаграммами, и показывает такие неповеденческие аспекты системы, как эффективность, надежность, защищенность и переносимость [20].

Побочным результатом анализа будет оценка риска: выявление опасных мест, которые могут повлиять на процесс проектирования. Обнаружение имеющегося риска в начале процесса проектирования облегчит возможные архитектурные компромиссы на поздних этапах разработки.

Виды деятельности. С анализом связаны два основных вида деятельности: анализ предметной области и планирование сценариев.

Как мы описали в главе 4, анализ области должен идентифицировать обитающие в данной проблемной области классы и объекты. Прежде, чем взяться за разработку новой системы, обычно изучают уже существующие. В этом случае мы можем извлечь выгоду из опыта других проектов, в которых принимались сходные решения. Лучшим результатом анализа предметной области может явиться вывод, что нам не надо проектировать новый продукт, а следует повторно использовать или адаптировать существующую программу.

Планирование сценариев является центральным действием анализа. Интересно, что по этому вопросу, кажется, имеется совпадение мнений среди других методологов, особенно у Рубина и Голдберга (Rubin adn Goldberg), Адамса (Adams), Вирфс-Брока (Wirfs-Brock), Коада (Coad) и Джекобсона (Jacobson). Типичный порядок его выполнения следующий:

• Идентифицировать основные функциональные точки системы и, если возможно, сгруппировать функционально связанные виды поведения. Рассмотреть возможность создания иерархии функций, в которой высшие функции вытекают из низших.
• Для каждого представляющего интерес набора функциональных точек сделать раскадровку сценария, используя технику анализа поведения и примеров использования, описанную в главе 4 [Всесторонний анализ этого предмета можно найти в работах Джекобсона [22] и Рубина и Голдберга [23]]. В мозговом штурме каждого сценария эффективна техника CRC-карточек. Когда прояснится семантика сценариев, следует документировать их, используя диаграммы объектов, которые иллюстрируют объекты, инициирующие и обеспечивающие поведение, и их взаимодействие при выполнении действий сценария. Приложить описание событий, происходящих при выполнении сценария, и порядок выполняемых в результате действий. Кроме того, необходимо перечислить все предположения, ограничения и показатели эффективности для каждого сценария [21].
• Если необходимо, сделать вторичные сценарии, иллюстрирующие поведение системы в исключительных ситуациях.
• Для объектов с особо важным жизненным циклом описать диаграммы состояний (построить конечный автомат).
• Найти в сценариях повторяющиеся шаблоны и выразить их в терминах более абстрактных обобщенных сценариев или в терминах диаграмм классов, показывающих связи между ключевыми абстракциями.
• Внести изменения в словарь данных; включить в него новые классы и объекты, выявленные для каждого сценария, вместе с описанием их ролей и обязанностей.

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

Путевые вехи и характеристики. Мы благополучно завершим эту фазу, когда мы будем иметь уточненные и подписанные сценарии для всех фундаментальных типов поведения системы. Говоря подписанные, мы предполагаем, что конечные результаты анализа проверялись экспертами, конечными пользователями, аналитиками и архитекторами; говоря фундаментальные, мы имеем в виду типы поведения, основные для данного приложения. Повторим, мы не ожидаем полного анализа, - достаточно рассмотреть только основные и несколько второстепенных видов поведения.

Степень совершенства анализа будет измеряться, в частности, его полнотой и простотой. Хороший анализ выявляет все первичные сценарии и, как правило, важнейшие вторичные. Разумный анализ включает также просмотр всех стратегически важных сценариев, так как это помогает привить единое видение системы всему коллективу разработчиков. Наконец, следует найти шаблоны поведения, которые давали бы возможно более простую структуру классов и учитывали бы все, что есть общего в различных сценариях.

Другой важной составной частью анализа является оценка риска, которая облегчит будущие стратегические и тактические компромиссы.

Проектирование

Результаты. Имеется два основных результата проектирования: описание архитектуры и выработка общих тактических приемов. Мы можем описывать архитектуру путем построения диаграмм или создавая… Мы используем архитектурные релизы системы как осязаемую демонстрацию строения архитектуры. Архитектурный релиз…

Эволюция

Эволюция архитектуры в значительной степени состоит в попытке удовлетворить нескольким взаимоисключающим требованиям ко времени, памяти и т.д. -… Таким образом, эволюция - это и есть процесс разработки программы. Как пишет… Пейдж-Джонс называет ряд преимуществ такой поступательной разработки: "Обеспечивается обратная связь с…

Сопровождение

Леман и Белади сделали несколько неоспоримых наблюдений, рассматривая процесс "созревания" уже внедренной программной системы: … Мы отличаем понятие сохранения системы программного обеспечения от ее… Результаты. Поскольку сопровождение является в определенном смысле продолжением эволюции системы, ее результаты похожи…

Глава 7

Практические вопросы

Ситуация усугубляется тем обстоятельством, что проектирование - никак не точная наука. Возьмем проектирование баз данных, одну из технологий,… Из этого можно сделать вывод, что при любом самом изощренном и теоретически… 7.1. Управление и планирование

Управление риском

Как было описано в предыдущей главе, микропроцесс объектно-ориентированной разработки нестабилен по своей природе и требует активного управления,… Многие виды деятельности по управлению разработкой программного обеспечения,…

Планирование задач

Проводимые встречи дают простую, но эффективную возможность гладкой подстройки планов в микропроцессе и распознания показавшихся на горизонте… Планирование задач связано с построением графика представления результатов… Ключ к тому, чтобы не поддаваться чрезмерно оптимистическому планированию, - "калибровка" команды и ее…

Просмотр

Руководитель должен проводить просмотры с разумной частотой. За исключением самых ответственных и уязвимых для ошибок мест, просто неэкономично… Как описано в предыдущей главе, сценарии являются первичным результатом… Просмотр архитектуры должен охватывать всю систему, включая ее механизмы и структуру классов. Как и при просмотре…

Роли разработчиков

Эксперименты показывают, что объектно-ориентированная разработка требует несколько иного разделения труда по сравнению с традиционными методами. Мы… Архитектор проекта - его творец, человек с сильно развитым воображением; он… Очень плохая практика - нанимать архитектора со стороны, который, образно выражаясь, въезжает на белом коне,…

ЧАСТЬ ТРЕТЬЯ

Примеры приложений

Чтобы построить теорию, необходимо как следует знать основные феномены изучаемой области. Что касается теории вычислений, то мы не знаем этого предмета настолько, чтобы изложить его на высоком уровне абстракции. Напротив, нам следует объяснять хорошо изученные конкретные примеры, на основе которых мы сможем догадаться об общих принципах и обосновать их.

Марвин Минский (Marvin Minsky)

Форма и содержание в компьютерной науке

(Form and Content in Computer Science)

Глава 8

Система сбора данных: метеорологическая станция

8.1. Анализ

Определение границ рассматриваемой задачи

Мы начнем наш анализ с рассмотрения аппаратной части системы. Это задача системного анализа. Она включает в себя такие вопросы, как технологичность… На рис. 8-1 приведена диаграмма, иллюстрирующая состав аппаратной части…

TimeDate

Поддержание информации о текущем времени и о текущей дате. Операции: CurrentTime - текущее время currentDate - текущая дата setFormat - установка формата setHour - установка часа …

TemperatureSensor

Поддержание информации о текущей температуре. Операции: currentTemperature - текущая температура setLowTemperature - установка минимальной температуры setHighTemperature -…

PressureSensor

Поддержание информации о текущем барометрическом давлении. Операции: currentPressure - текущее давление setLowPressure - установка минимального давления setHighPressure - установка…

HumiditySensor

Поддержание информации о текущей влажности, выраженной в процентах от 0% до 100%. Операции: currentHumidity - текущая влажность setLowHumidity - установка минимальной влажности setHighHumidity - установка…

WindSpeedSensor

Поддержание информации о текущей скорости ветра. Операции: currentSpeed - текущая скорость setLowSpeed - установка минимальной скорости setHighSpeed - установка максимальной…

WindDirectionSensor

Поддержание информации о текущем направлении ветра, указываемом как точка на розе ветров. Операции: currentDirection - текущее направление

Keypad

Ответственность:

Поддержание информации о коде последней клавиши, нажатой на клавиатуре.

Операции:

lastKeyPress - последняя нажатая клавиша

Атрибуты:

key - клавиша

Заметим, что этот класс не знает о назначении той или иной клавиши: экземпляр данного класса несет информацию лишь о том, какая клавиша была нажата. Ответственность за интерпретацию клавиш несет другой класс, который будет определен позднее.

Следующая абстракция - класс LCDDevice, предназначенный для того, чтобы обеспечить определенную независимость нашей программной системы от аппаратной части, на которой она будет работать. Для рабочих станций и персональных компьютеров существует целый ряд стандартов (хотя зачастую и конфликтующих между собой) графического интерфейса, таких, например, как Motif или Microsoft Windows. К сожалению, для встроенных контроллеров нет общепризнанных стандартов, поэтому анализ задачи приводит нас к мысли о том, что для ее решения необходимо создать прототипы и затем определить основные требования к интерфейсу пользователя.

Рис. 8-5. Дисплей метеорологической станции.

На рис. 8-5 приведен один из подобных прототипов. Здесь не показаны изображения, характеризующие коэффициент резкости погоды и точку росы, требуемые в задании, а также такие детали, как верхние и нижние границы измерений за 24 часа. Однако, все основные графические элементы присутствуют. Итак, нам необходимо выводить на экран текст (двух различных размеров и начертаний), окружности и линии различной толщины. Также следует заметить, что некоторые элементы изображения являются статическими (такие, как заголовок ТЕМПЕРАТУРА), а некоторые - динамическими (направление ветра). И статические, и динамические элементы изображения генерируются программно. В итоге упрощается аппаратная часть (не надо заказывать специальные жидкокристаллические дисплеи со встроенными статическими элементами), но несколько усложняется программное обеспечение.

Требования к графике можно выразить через следующую абстракцию:

Имя:

LCDDevice

Управление выводом на экран графических элементов. Операции: drawText - рисовать текст drawLine - рисовать линию drawCircle - рисовать окружность setTextSize - установка…

Timer

Ответственность:

Осуществление прерываний и диспетчеризация функций обратного вызова.

Операции:

setCallback() - установка функции обратного вызова

Сценарии

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

• Мониторинг первичных измеряемых параметров: скорости и направления ветра, температуры, барометрического давления и влажности.
• Мониторинг производных параметров: коэффициента жесткости погоды, точки образования росы, трендов температуры и барометрического давления.
• Показ максимальных и минимальных значений выбранных параметров.
• Установка времени и даты.
• Калибровка выбранных датчиков.
• Включение системы.

Добавим еще две дополнительные ситуации:

• Отказ питания.
• Отказ датчика.

Исследуем вышеприведенные сценарии для того, чтобы понять поведение (именно поведение, а не внутреннюю структуру) системы.

Главной задачей системы является мониторинг основных измеряемых параметров. Одним из ограничений является невозможность обрабатывать информацию с частотой, превышающей 60 измерений в секунду. К счастью, наиболее интересные для нас погодные параметры меняются с гораздо меньшей скоростью. Дополнительный анализ показывает, что для своевременной регистрации изменений различных погодных параметров достаточно обеспечить следующие частоты снятия информации:

• каждые 0.1 секунды направление ветра
• каждые 0.5 секунды скорость ветра
• каждые 5 минут температура, барометрическое давление и влажность

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

Рис. 8-7. Сценарий измерений.

Продолжим рассмотрение данного сценария. Теперь нам предстоит решить, какие из объектов, приведенных на диаграмме, должны отвечать за вывод информации на экран дисплея, то есть, фактически, за передачу данных экземпляру класса LCDDevice. Здесь возможны два варианта: можно передать ответственность за эти действия самим классам датчиков (подобная схема реализована в архитектурах, подобных MVC), либо создать отдельный класс для связи между датчиками и дисплеем. В данном случае мы выбираем второй вариант, так как он позволяет нам изолировать в рамках одного класса все проектные решения, касающиеся механизмов реализации вывода параметров на экран. В итоге к результатам нашего анализа добавляется описание еще одного класса:

Имя:

DisplayManager

Организация отображения параметров на экране дисплея. Операции: drawStaticItems - рисование статических элементов displayTime - вывод времени displayDate - вывод даты …

Вывод на экран максимальных и минимальных значений выбранного параметра.

Замечание: для прекращения работы в данном режиме пользователь нажимает клавишу RUN, при этом экран дисплея возвращается в первоначальное… После рассмотрения этого сценария мы приходим к выводу о необходимости… Установка времени и даты подчиняется аналогичному сценарию:

Установка времени и даты.

Замечание: для прекращения работы в данном режиме пользователь нажимает клавишу RON, при этом экран дисплея возвращается в первоначальное состояние,… Сценарий калибровки датчика следует той же схеме:

Калибровка датчика.

Рис. 8-10. Клавиатура метеорологической станции. Замечание: для прекращения работы в данном режиме пользователь нажимает клавишу RUN, при этом экран дисплея…

Установка единиц измерений температуры и скорости ветра.

Замечание: для прекращения работы в данном режиме пользователь нажимает клавишу RUN, при этом экран дисплея возвращается в первоначальное состояние,… После изучения сценариев работы можно определить состав и расположение клавиш… Приведенные выше сценарии можно наглядно отобразить с помощью диаграмм состояний. Так как все сценарии тесно связаны,…

InputManager

Диспетчеризация команд пользователя. Операции: processKeyPress обработка сигналов с клавиатуры

Включение системы.

Постусловия: Последние минимаксные значения параметров устанавливаются равными их первому замеру. Время достижения микимакса считается… Отметим, что задание постусловий определяет ожидаемое состояние системы после… На этом мы завершим изучение основных сценариев работы метеорологической станции. Конечно, для полноты картины было бы…

Архитектурный каркас

Существует целый ряд архитектурных моделей для решения задач сбора и обработки данных и управления, но наиболее часто встречаются синхронизация… В первом случае архитектура системы скомпонована из ряда относительно… Однако подобные архитектуры оказываются не всегда приемлемыми при создании жестких систем реального времени, где…

Механизм покадровой обработки

Начнем с разработки внешнего интерфейса для класса Timer, осуществляющего диспетчеризацию функции обратного вызова (все решения будут в дальнейшем… // Временной промежуток, измеряемый в 1/60 долях секунды typedef unsigned int… Затем определим класс Timer:

Планирование релизов

В принципе, можно было бы изменить порядок этапов, но мы выбрали именно такую последовательность, исходя из того, что наиболее сложная и рискованная… Мы не будем подробно останавливаться на реализации данной версии, поскольку…

Механизм датчиков

На данном этапе разработки иерархия классов-датчиков, представленная на рис. 8-4, остается без изменений. Мы, однако, должны уточнить… class Sensor { public: Sensor(SensorName, unsigned int id = 0); virtual ~Sensor(); virtual float currentValue = 0; virtual float…

Механизм вывода информации на экран

class DisplayManager { public: DisplayManager(); ~DisplayManager(); void clear(); void refresh(); void… protected: // ... };

Механизм пользовательского интерфейса

Начнем с определения словаря проблемной области: enum Key {kRun, kSelect, kCalibrate, kMode, kUp, kDown, kLeft, kRight,… Нам приходится использовать префикс k, чтобы не дублировать наименований типов, уже определенных для SensorName.

Глава 9

Среда разработки: библиотека базовых классов

Основным преимуществом объектно-ориентированных языков программирования, таких, как C++ и Smalltalk, является высокая степень повторного использования в хорошо спроектированных системах. Это означает, что для разработки каждого следующего приложения требуется гораздо меньше нового кода; следовательно, меньшее количество кода требуется сопровождать и поддерживать.

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

Среды разработки могут быть достаточно универсальны и применимы к широкому кругу приложений. К этой категории относятся общие фундаментальные классы, математические библиотеки и библиотеки графического интерфейса пользователя. Среды разработки могут встречаться и в достаточно узких предметных областях, таких, например, как учет пациентов больницы, торговля текстилем, менеджмент, телефонные системы. Там, где существует семейство программ, решающих сходные задачи, появляется повод создать прикладную среду разработки.

В этой главе мы применим объектно-ориентированный подход к созданию библиотеки фундаментальных классов. В предыдущей главе нашими основными задачами были реализация управления системой в реальном времени и оптимальное разделение функциональных свойств между несколькими относительно автономными и статическими объектами. Здесь же будут доминировать два различных аспекта: стремление к гибкости архитектуры с широким выбором альтернатив оптимизации по времени и памяти, и необходимость использования общих механизмов управления памятью и синхронизацией.

9.1. Анализ

Определение границ проблемной области

Тем, кого интересует теоретический фундамент, можно посоветовать обратиться к плодотворной работе Кнута [2], а также других исследователей в данной… Первое открытие в ходе нашего анализа - это четкое отделение структурных…

Требования к библиотеке базовых классов

Библиотека должна содержать универсальные структуры данных и алгоритмы, способные удовлетворить потребности большинства стандартных приложении C++. Кроме того, библиотека должна быть:

• Полной	Библиотека должна содержать семейство классов, объединенных согласованным внешним интерфейсом, но с разными представлениями, так чтобы разработчики могли выбрать то, семантика которого наиболее точно соответствует приложению.
• Адаптируемой	Все фрагменты кода, зависящие от платформы, должны быть выделены и изолированы в отдельные классы для обеспечения возможности локальных изменений в них. В частности, разработчик должен иметь контроль над механизмами хранения данных и синхронизации процессов.
• Эффективной	Процедура подключения различных фрагментов библиотеки к приложению должна быть простой (эффективность при компиляции). Непроизводительные затраты оперативной памяти и процессорного времени на обслуживание и подключение должны быть сведены к минимуму (эффективность при исполнении). Библиотека должна обеспечивать более надежную работу, чем механизмы, разработанные пользователем вручную (эффективность при разработке).
• Безопасной	Каждая абстракция должна быть безопасной с точки зрения типов, так чтобы статические предположения о поведении класса могли быть обеспечены компилятором. Для выявления нарушений динамической семантики классов должен быть использован механизм исключений. Возбуждение исключения не должно испортить состояние объекта, вызвавшего исключение.
• Простой	Библиотека должна иметь прозрачную структуру, дающую возможность пользователю легко находить и подключать к приложению ее фрагменты.
• Расширяемой	Для пользователя должна быть реализована возможность включения в библиотеку новых классов. При этом архитектурная целостность среды разработки не должна нарушаться.

Библиотека должна быть относительно небольших размеров; надо всегда помнить, что пользователь с большей охотой займется разработкой собственного кода, чем изучением чужого малопонятного класса.

Предполагается наличие трансляторов языка C++, поддерживающих параметризованные классы и обработку исключений. В целях обеспечения переносимости библиотеки она не должна зависеть от служб операционной системы.

Таким образом, первым результатом нашего анализа будет разделение всех абстракций на две категории:

• Структуры	Содержит все структурные абстракции.
• Инструменты	Содержит все алгоритмические абстракции.

Как мы скоро увидим, между этими двумя категориями существует отношение использования: некоторые инструменты построены на базе более примитивных свойств, обеспечиваемых структурами.

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

Проведя анализ, мы выделим следующие типы структур:

• Набор	Множество различных элементов (в том числе дубликатов).
• Множество	Набор неповторяющихся элементов.
• Коллекция	Индексируемое множество элементов.
• Список	Последовательность элементов, имеющая начало; структурное разделение допускается.
• Стек	Последовательность элементов; элементы могут удаляться и добавляться только с одного конца.
• Очередь	Последовательность элементов, к которой можно добавлять элементы с одного конца, а удалять - с другого.
• Дека	Последовательность элементов, к которой можно добавлять и из которой можно удалять элементы с обоих концов.
• Кольцо	Последовательность элементов, к которой можно добавлять и из которой можно удалять элементы, находящиеся на вершине круговой структуры.
• Строка	Индексируемая последовательность элементов, в которой возможны операции с подстроками.
• Ассоциативный массив	Словарь пар "элемент/значение".
• Дерево	Набор (имеющий начало - корень дерева) вершин и ребер, которые не могут образовывать циклы и пересекаться; структурное разделение допускается.
• Граф	Множество вершин и ребер (без выделенного начального элемента), которое может содержать циклы и пересечения; структурное разделение допускается.

Как уже говорилось в главе 4, упорядочение представленных выше абстракций есть проблема классификации. Мы выбрали именно такую модель из-за того, что она обеспечивает закрепление определенного поведения за каждой категорией объектов.

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

Для некоторых классов в процессе анализа выявилась желательность их функциональной изменчивости. В частности, нам могут понадобиться упорядоченные коллекции, деки и очереди (последние часто называют приоритетными очередями). Кроме того, мы можем различать ориентированные и неориентированные графы, односвязные и двусвязные списки, бинарные, множественные и AVL-деревья [AVL-дерево - предложенная Г.М.Адельсон-Вольским и Е.М.Ландисом конструкция подравниваемого бинарного дерева. - Примеч. ред.]. Эти специализированные абстракции могут быть получены уточнением одной из вышеперечисленных; их не следует выделять в отдельные большие категории.

Несмотря на то, что мы уже обнаружили признаки общности поведения, мы пока не будем заниматься проработкой иерархической структуры. На этапе анализа важно разобраться в ролях каждой абстракции.

Мы выделим следующие типы инструментов:

• Дата/Время	Операции с датой и временем.
• Фильтры	Ввод, обработка и вывод.
• Поиск по образцу	Операции поиска последовательностей внутри других последовательностей.
• Поиск	Операции поиска элементов внутри структур.
• Сортировка	Операции упорядочивания структур.
• Утилиты	Составные операции, базирующиеся на базовых структурных операциях.

Несомненно, существует масса различных функциональных вариантов этих абстракций. Можно, например, выделить несколько видов сортировок (быстрая сортировка методом пузырька, сортировка кучи и т.д.) или поиска (последовательный, двоичный, различные способы обхода дерева и т.д.). Как и раньше, мы отложим решения относительно наследования этих абстракций.

Модели взаимодействий

Анализ показывает, что существует определенный набор основных механизмов, необходимый для библиотеки базовых классов: семантика времени и … При проектировании системы базовых классов необходимо сохранять баланс между… Встанем на точку зрения пользователя нашей библиотеки. Какие абстракции представляют имеющиеся в ней классы? Как они…

Тактические вопросы

Как было отмечено в главе 3, объектно-ориентированные языки предоставляют три основных механизма упорядочения большего числа классов: наследование,… Рассмотрим усеченное описание предметно-зависимого класса очереди в C++: class NetworkEvent... // сетевое событие

EventQueue(); virtual ~EventQueue(); virtual void clear(); // очистить virtual void add(const NetworkEvent&); // добавить virtual void pop(); // продвинуть virtual const NetworkEvent& front() const; // первый элемент

...
};

Перед нами абстракция, олицетворяющая очередь событий: структура, в которую мы можем добавлять новые элементы в конец очереди и удалять элементы из начала очереди. C++ позволяет скрыть внутренние детали реализации класса очереди за его внешним интерфейсом (операциями clear, add, pop и front ).

Нам могут потребоваться также некоторые другие варианты очереди, например, приоритетная очередь, где события выстраиваются в соответствии с их срочностью. Разумно воспользоваться результатами уже проделанной работы и организовать новый класс на базе ранее определенного:

class PriorityEventQueue : public EventQueue {
public:

PriorityEventQueue();
virtual ~PriorityEventQueue();
virtual void add(const NetworkEvent&);

...
};

Виртуальность функций (например функции add) поощряет переопределение операций в подклассах.

Комбинация наследования с параметризованными классами позволяет создавать еще более общие абстракции. Семантика класса очереди не зависит от того, что в ней: волки или овцы. Используя классы-шаблоны, можно переопределить наш базовый класс следующим образом:

template<class Item>
class Queue {
public:

Queue();
virtual ~Queue();
virtual void clear();
virtual void add(const Item&);
virtual void pop();
virtual const Item& front() const;

...
};

Это наиболее распространенный способ использования параметризованных классов: взять существующий конкретный класс, выделить в нем то, что не зависит от элементов, с которыми он оперирует, и сделать эти элементы аргументами шаблона.

Наследование и параметризация очень хорошо сочетаются. Наш подкласс PriorityQueue можно, например, обобщить следующим образом:

template<class Item>
class PriorityQueue : public Queue<Item> {
public:

PriorityQueue();
virtual ~PriorityQueue();
virtual void add(const Item&);

...
};

Безопасность с точки зрения типов - ключевое преимущество данного подхода. Мы можем создать целый ряд различных классов конкретных очередей:

Queue<char> characterQueue;
typedef Queue<MetworkEvent> EventQueue;
typedef PriorityQueue<NetworkEvent> PriorityEventQueue;

Рис. 9-1. Наследование и параметризация.

При этом язык реализации не позволит нам присоединить событие к очереди символов, а вещественное число - к очереди событий.

Рис. 9-1 иллюстрирует отношения между параметризованным классом (Queue), его подклассом (PriorityQueue), примером этого подкласса (PriorityEventQueue) и одним из его экземпляров (mailQueue).

Этот пример подтверждает правильность одного из самых первых наших архитектурных решений: почти все классы нашей библиотеки должны быть параметризованными. Тогда будет выполнено и требование защищенности.

Макроорганизация

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

Семейства классов

Третий основной принцип проектирования библиотеки заключается в построении семейств классов, связанных отношением наследования. Для каждого типа структур мы создадим несколько различных классов, объединенных единым интерфейсом (как в случае с абстрактным классом Queue), но с разными конкретными подклассами, имеющими несколько различные представления и поэтому отличающимися Своим устройством и характеристиками "время/память". Таким образом мы обеспечим библиотечное требование полноты. Разработчик сможет выбрать тот конкретный класс, который в большей степени подходит для решения его задачи. В то же время этот класс обладает тем же интерфейсом, что и остальные классы семейства. Сознательное четкое разделение абстрактного базового класса и его конкретных подклассов позволяет пользователю системы выбрать, скажем, на первом этапе проектирования один из классов в качестве рабочего, а затем, в процессе доводки приложения, заменить его на другой, чем-то отличающийся класс того же семейства, затратив на это минимум времени и усилий (единственное, что ему потребуется, - это заново оттранслировать свою программу). При этом разработчик будет уверен в нормальном функционировании программы, так как все классы, принадлежащие одному семейству, обладают идентичным внешним интерфейсом и схожим поведением. Смысл в такой организации классов состоит еще и в возможности копирования, присваивания и сравнения объектов одного семейства даже в том случае, если их представления совершенно разнятся.

Можно сказать, что базовый абстрактный класс как бы содержит в себе все важные черты абстракции. Другое важное применение абстрактных базовых классов - это кэширование общего состояния, которое дорого вычислять заново. Так можно перевести вычисление O(n) в операцию порядка O(1) - простое считывание данных. При этом, естественно, требуется обеспечить соответствующий механизм взаимодействия между абстрактным базовым классом и его подклассами, чтобы гарантировать актуальность кэшируемого значения.

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

• Ограниченная	Структура хранится в стеке и, таким образом, имеет статический размер (известный в момент создания объекта).
• Неограниченная	Структура хранится в куче и ее размеры могут динамически изменяться.

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

Второй вариант связан с синхронизацией. Как было отмечено в главе 2, множество полезных приложений обходятся одним процессом. Их называют последовательными системами, потому что они используют один поток управления. Для других приложений (особенно это касается систем реального времени) требуется обеспечить синхронизацию нескольких одновременно выполняемых потоков. Такие системы называются параллельными, и в них каким-то образом должно обеспечиваться взаимное исключение процессов, конкурирующих за один и тот же ресурс. Ясно, что нельзя дать возможность управлять одним и тем же объектом одновременно нескольким потокам, это в конце концов приведет к нарушению его состояния. Рассмотрим, например, поведение двух агентов, которые одновременно пытаются добавить элемент одному и тому же объекту класса Queue. Первый агент, начавший добавление элемента, может быть прерван раньше, чем окончит данную операцию, и оставит объект второму агенту в незавершенном состоянии.

Рис. 9-3. Семейства классов.

Как отмечалось в главе 3, в данном случае при проектировании существуют всего три возможных альтернативы, каждая из которых требует обеспечения различного уровня взаимодействия между агентами, оперирующими с общими объектами:

• последовательный;
• защищенный;
• синхронизированный.

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

• Отражает общность различных форм.
• Позволяет осуществлять более простой доступ к элементам библиотеки.
• Позволяет избежать бесконечных метафизических споров о "чистом объектно-ориентированном подходе".
• Упрощает интеграцию системы с другими библиотеками.

Микроорганизация

В целях обеспечения простоты работы с системой выберем один общий стиль оформления структур и механизмов библиотеки:

template<...>
class Name : public Superclass {
public:

Конструкторы // виртуальный деструктор // операторы // модификаторы // селекторы

protected:

Данные // функции

private:

Друзья

};

Описание абстрактного базового класса Queue начинается следующим образом:

template<class Item> class Queue {

Сигнатура шаблона template служит для задания аргументов параметризованного класса. Отметим, что в C++ шаблоны сознательно введены таким образом, чтобы передать достаточную гибкость (и ответственность) в руки разработчика, инстанцирующего шаблон в своем приложении.

Далее определим обычный список конструкторов и деструкторов:

Queue();
Queue(const Queue<Item>&);
virtual ~Queue();

Отметим, что мы описали деструктор виртуальным, чтобы обеспечить полиморфное поведение при уничтожении объектов класса. Далее объявим все операторы:

virtual Queue<Item>& operator=(const Queue<Item>&);
virtual int operator==(const Queue<Item>&) const;
int operator!=(const Queue<Item>&) const;

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

Если мы хотим ограничить доступ к копированию, присваиванию или сравнению некоторых объектов, нам надо объявить эти операторы защищенными или закрытыми.

Определим теперь модификаторы, позволяющие менять состояние объекта:

virtual void clear() = 0;
virtual void append(const Item&) = 0;
virtual void pop() =0;
virtual void remove (unsigned int at) = 0;

Данные операции объявлены как чисто виртуальные, а это значит, что их описание является обязанностью подклассов. Наличие чисто виртуальных функций делает класс Queue абстрактным.

Спецификатор const указывает (компилятор может это проверить) на использование функций-селекторов, то есть функций, предназначенных исключительно для получения информации о состоянии объекта, но не для изменения состояния:

virtual unsigned int length() const = 0;
virtual int isEmpty() const = 0;
virtual const Item& front() const =0;
virtual int location(const Item&) const = 0;

Эти операции тоже определены как чисто виртуальные, потому что класс Queue не обладает достаточной информацией для их полного описания.

Защищенная часть каждого класса начинается с описания тех элементов, которые формируют основу его структуры и должны быть доступны подклассам [Всюду, где веские причины не заставляют нас действовать по-другому, мы объявляем элементы класса закрытыми. Здесь, однако, существует веская причина объявить эти фрагменты защищенными: доступ к ним потребуется подклассам]. Абстрактный класс Queue, в. отличие от своих подклассов (см. ниже), подобных элементов не имеет.

Продолжит защищенную часть базового класса определение служебных функций, которые будут полиморфно реализованы в конкретных подклассах. Класс Queue содержит довольно типичный список таких функций:

virtual void purge() = 0;
virtual void add(const Item&) = 0;
virtual unsigned int cardinality() const = 0;
virtual const Item& itemAt (unsigned int) const = 0;
virtual void lock();
virtual void unlock();

Причины, по которым мы ввели именно эти функции, будут рассмотрены в следующем разделе.

И, наконец, определим закрытую часть, обычно содержащую объявления о классах-друзьях и те элементы, которые мы хотим сделать недоступными даже для подклассов. Класс Queue содержит только декларации о друзьях:

friend class QueueActiveIterator<Item>;
friend class QueuePassiveIterator<Item>;

Как мы увидим в дальнейшем, эти объявления друзей понадобятся для поддержки идиом итератора.

Семантика времени и памяти

Рассмотрим тот спектр требований, который должен учитываться при разработке библиотеки общего назначения. На рабочей станции, обладающей большим… Неограниченные формы применимы в тех случаях, когда размер структуры не может… Таким образом, все структуры данной библиотеки должны присутствовать в альтернативных вариантах; поэтому нам придется…

Управление памятью

На рис. 9-5 приведен выбранный для данной библиотеки механизм управления памятью [Историческое замечание: потребовалось около четырех итераций…  

Итерация

При этом перед нами стоял выбор: можно было определять итерации как часть протокола объектов или создавать отдельные объекты, ответственные за… Для каждой структуры определены две формы итераций. Активный итератор требует… Рассмотрим в качестве примера активный итератор для класса Queue:

Синхронизация

При разработке данной библиотеки было сделано следующее предположение: разработчики, планирующие использовать параллельные процессы, должны… class Semaphore { public: Semaphore(); Semaphore(const Semaphore&); Semaphore(unsigned int count); ~Semaphore(); void seize();…

Проектирование интерфейса классов

После того, как выработаны основные принципы построения архитектуры системы, остающаяся работа проста, но зачастую довольно скучна и утомительна. Следующий этап будет состоять в реализации трех или четырех семейств классов (таких, как очередь, множество и дерево) в соответствии с выбранной архитектурой, и в последующем их тестировании в нескольких приложениях [Вирфс-Брок считает, что необходимо тестировать среду разработки по крайней мере на трех приложениях, чтобы проверить правильность стратегических и тактических решений [15]].

Наиболее тяжелой частью данного этапа является создание подходящего интерфейса для каждого базового класса. И здесь, в процессе изолированной разработки отдельных классов (см. главу 6), нельзя забывать о задаче обеспечения глобального соответствия всех частей системы друг другу. В частности, для класса Set можно определить следующий протокол:

• setHashFunction	Устанавливает функцию хеширования для элементов множества.
• clear	Очищает множество.
• add	Добавляет элемент к множеству.
• remove	Удаляет элемент из множества.
• setUnion	Объединяет с другим множеством.
• intersection	Находит пересечение с другим множеством.
• difference	Удаляет элементы, которые содержатся в другом множестве.
• extent	Возвращает количество элементов в множестве.
• isEmpty	Возвращает 1, если множество пусто.
• isMember	Возвращает 1, если данный элемент принадлежит множеству.
• isSubset	Возвращает 1, если множество является подмножеством другого множества.
• isProperSubset	Возвращает 1, если множество является собственным подмножеством другого множества.

Подобным же образом можно определить протокол класса BinaryTree:

• clear	Уничтожает дерево и всех его потомков.
• insert	Добавляет новый узел в корень дерева.
• append	Добавляет к дереву потомка.
• remove	Удаляет потомка из дерева.
• share	Структурно делит данное дерево.
• swapChild	Переставляет потомка с деревом.
• child	Возвращает данного потомка.
• leftChild	Возвращает левого потомка.
• rightChild	Возвращает правого потомка.
• parent	Возвращает родителя дерева.
• setItem	Устанавливает элемент, ассоциированный с деревом.
• hasChildren	Возвращает 1, если у дерева есть потомки.
• isNull	Возвращает 1, если дерево нулевое.
• isShared	Возвращает 1, если дерево структурно разделено.
• isRoot	Возвращает 1, если дерево имеет корень.
• itemAt	Возвращает элемент, ассоциированный с деревом.

Для схожих операций мы используем схожие имена. При разработке интерфейса мы также проверяем полученное решение на соответствие критериям достаточности, полноты и примитивности (см. главу 3).

Классы поддержки

При реализации класса, ответственного за манипуляции с текстовыми строками, мы столкнулись с тем, что возможностей, предоставляемых классами поддержки Bounded и Unbounded, явно недостаточно. Ограниченная форма, в частности, оказывается неэффективной для работы со строками с точки зрения памяти, так как мы должны инстанцировать эту форму в расчете на максимально возможную строку, и следовательно понапрасну расходовать память на более коротких строках. Неограниченная форма, в свою очередь, неэффективна с точки зрения быстродействия: поиск элемента в строке может потребовать последовательного перебора всех элементов связного списка. По этим причинам нам пришлось разработать третий, "динамический" вариант:

• Динамический

Структура хранится в "куче" в виде массива, длина которого может уменьшаться или увеличиваться.

Структура хранится в "куче" в виде массива, длина которого может уменьшаться или увеличиваться.

Соответствующий класс поддержки Dynamic представляет собой промежуточный вариант по отношению к ограниченному и неограниченному классам, обеспечивающий быстродействие ограниченной формы (возможно прямое индексирование элементов) и эффективность хранения данных, присущую неограниченной форме (память выделяется только под реально существующие элементы).

Ввиду того, что протокол данного класса идентичен протоколу классов Bounded и Unbounded, добавление к библиотеке нового механизма не составит большого труда. Мы должны создать по три новых класса для каждого семейства (например, DynamicString, GuardedDynamicString и SynchronizedDynamicString). Таким образом, мы вводим следующий класс поддержки:

template<class Item, class StorageManager>
class Dynamic {
public:

Dynamic(unsigned int chunkSize);

protected:

Item* rep;
unsigned int size;
unsigned int totalChunks;
unsigned int chunkSize;
unsigned int start;
unsigned int stop;
void resize(unsigned int currentLength,
unsigned int newLength, int preserve - 1);
unsigned int expandLeft(unsigned int from);
unsigned int expandRight(unsigned int from);
void shrinkLeft(unsigned int from);
void shrinkRight(unsigned int from);

};

Последовательности разбиваются на блоки в соответствии с аргументом конструктора chunkSize. Таким образом, клиент может регулировать размер будущего объекта.

Из интерфейса видно, что класс Dynamic имеет много общего с классами Bounded и Unbounded. Отличия в реализации трех типов классов каждого семейства будут минимальны.

Займемся теперь классом ассоциативных массивов. Его реализация потребует новой переработки ограниченной, динамической и неограниченной форм. В частности, поиск элемента в ассоциативном массиве требует слишком много времени, если его приходится вести перебором всех элементов. Но производительность можно значительно увеличить, используя открытые хеш-таблицы.

Абстракция открытой хеш-таблицы проста. Таблица представляет собой массив последовательностей, которые называются клетками. Помещая в таблицу новый элемент, мы сначала генерируем хеш-код по этому элементу, а затем используем код для выбора клетки, куда будет помещен элемент. Таким образом, открытая хеш-таблица делит длинную последовательность на несколько более коротких, что значительно ускоряет поиск.

Соответствующую абстракцию можно определить следующим образом:

template<class Item, class Value, unsigned int Buckets, class Container>
class Table {
public:

Table(unsigned int (*hash)(const Item&));
void setHashFunction(unsigned int (*hash)(const Item&));
void clear();
int bind(const Item&, const Value&);
int rebind(const Item&, const Value&);
int unbind(const Item&);
Container* bucket(unsigned int bucket);
unsigned int extent() const;
int isBound(const Item&) const;
const Value* valueOf(const Item&) const;
const Container *const bucket(unsigned int bucket) const;

protected:

Container rep[Buckets];

};

Использование класса Container в качестве аргумента шаблона позволяет применить абстракцию хеш-таблицы вне зависимости от типа конкретной последовательности. Рассмотрим в качестве примера (сильно упрощенное) объявление неограниченного ассоциативного массива, построенного на базе классов Table и Unbounded:

template<class Item, class Value, unsigned int Buckets,
class StorageManager>
class UnboundedMap : public Map<Item, Value> {
public:

UnboundedMap();
virtual int bind(const Item&, const Value&);
virtual int rebind(const Item&, const Value&);
virtual int unbind(const Item&);

protected:

Table<Item, Value, Buckets, Unbounded<Pair<Item, Value>, StorageManager>> rep;

};

В данном случае мы истанцируем класс Table контейнером unbounded. Рис. 9-12 иллюстрирует схему взаимодействия этих классов.

В качестве свидетельства общей применимости этой абстракции мы можем использовать класс Table при реализации классов множеств и наборов.

Рис. 9-12. Классы поддержки.

Инструменты

Еще более сложная ситуация возникает при создании инструментов, которые оперируют с другими структурами. Как уже отмечалось, алгоритмы тоже можно… Рассмотрим в качестве примера алгоритмы поиска образца внутри… У всех этих алгоритмов существуют по крайней мере три общие черты: все они проводят операции над последовательностями…

BMPatternMatch(); BMPattemMatch(int (*isEqual) (const Item& x, const Item& y)); virtual ~BMPattemMatch(); virtual int match(const Sequence& target, const Seque unsigned int start = 0); virtual int match(const Sequence& target, unsigned in

protected:

unsigned int length;
unsigned int* skipTable;
void preprogress(const Sequence& pattern);
unsigned int itemsSkip(const Sequence& pattern, const Item& item);

};

Рис. 9-13. Классы поиска.

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

На рис. 9-13 приведена иерархия классов поиска. Иерархия подобного типа применима для большинства инструментов библиотеки. При этом формируются сходные по структуре семейства классов, что позволяет пользователям легко в них ориентироваться и выбирать те, которые наилучшим образом подходят для их приложений.

9.4. Сопровождение

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

Одной из таких задач является проблема времени жизни объектов. Может встретиться клиент, который не хочет или не нуждается в использовании полно масштабной объектно-ориентированной базы данных, а планирует лишь время от времени сохранять состояние таких структур, как очереди и множества, чтобы иметь возможность получить их состояние при следующем вызове из той же программы или из другого приложения. Принимая во внимание то, что подобные требования могут возникать довольно часто, имеет смысл дополнить нашу библиотеку простым механизмом сохранения объектов.

Сделаем два допущения, касающихся этого механизма. Во-первых, клиент должен обеспечить потоки, в которые объекты будут записываться и считываться. Во-вторых, клиент обязан обеспечить объектам поведение, необходимое для направления в поток.

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

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

Рис. 9-14 иллюстрирует работу такого механизма, продлевающего жизнь объектов за счет работы отдельного агента. Класс Persist является дружественным классу Queue; мы определяем эту связь внутри описания класса Queue следующим образом:

friend class Persist<Item, Queue<Item>>;

В этом случае классы становятся дружественными только в момент инстан-цирования класса Queue. Внедрив подобные описания дружественности в каждый абстрактный базовый класс, мы обеспечиваем возможность использования Persist с любой структурой библиотеки.

Параметризованный класс Persist содержит операции записи и считывания put и get, а также функции для подключения потоков обмена данными. Мы можем определить данную абстракцию следующим образом:

template<class Item, class Structure>
class Persist {
public:

Persist();
Persist(iostream& input, iostream& output);
virtual ~Persist();
virtual void setInputStream(iostream&);
virtual void setOutputStream(iostream&);
virtual void put(Structure&);
virtual void get(Structure&);

protected:

iostream* inStreain;
iostream* outStream;

};

Рис. 9-14. Обеспечение сохраняемости с помощью агента.

Реализация данного класса зависит от того, является ли он дружественным классу Structure, который фигурирует в качестве аргумента шаблона. В частности, Persist зависит от наличия в структуре вспомогательных функций purge, cardinality, itemAt, lock, и unlock. Далее срабатывает однородность нашей библиотеки: поскольку каждый базовый класс Structure имеет подобные функции, то persist можно безо всяких изменений использовать для работы со всеми имеющимися в библиотеке структурами.

Рассмотрим в качестве примера реализацию функции Persist::put:

template<class Item, class Structure>
void Persist<Item, Structure>::put(Structure& s)
{

s.lock();
unsigned int count = s.cardinality();
(*outStream) << count << endl;

for (unsigned int index = 0; index < count; index++)

(*outStream) << s.itemAt(index);

s.unlock();

}

Эта операция использует разработанный нами ранее механизм блокировки, поэтому она будет работать и для защищенных, и для синхронизированных форм. Алгоритм работы функции несложен: сначала в поток выводится количество элементов структуры, а затем, последовательно, все ее элементы. Реализация persist::get аналогично выполняет обратное действие:

template<class Item, class Structure>
void Persist<Item, Structure>::get(Structure& s)
{

s.lock();
unsigned int count;
Item item;
if (! inStream->eof()) {

(*inStream) >> count;
s.purge();
for (unsigned int index = 0; (index < count) && (! inStream->eof());
index++)
{

(*inStream) >> item;
s.add(item);

}

}
s.unlock();

}

Для того, чтобы использовать этот простой механизм сохранения данных, клиенту надо всего лишь инстанцировать один дополнительный класс для каждой структуры.

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

Дополнительная литература

Бигерстафф и Перлис (Biggerstaffand Perlis) [H 1989] провели исчерпывающий анализ повторного использования программного обеспечения. Вирфс-Брок (Wirfs-Brock) [С 1988] предложил хорошее введение в объектно-ориентированные среды разработки. Джонсон (Johnson) [G 1992] изучал вопросы документирования архитектуры сред разработки и выявил ряд общих моментов.

Библиотека МасАрр [G 1989] для Macintosh является хорошим примером правильно сконструированной объектно-ориентированной прикладной среды разработки. Введение в более раннюю версию этой библиотеки классов может быть найдено у Шмукера (Schmucker) [G 1986]. В недавней работе Голдстейн и Алджер (Goldstein and Alger) [С 1992] обсуждают развитие объектно-ориентированного программного обеспечения для Macintosh.

Другие примеры сред разработки: гипермедиа (Мейровиц (Meirowitz) [С 1986]), распознавание образов (Йошида (Yoshida) [С 1988]), интерактивная графика (Янг (Young) [С 1987]), настольные издательские системы (Феррел (Ferrel) [K 1989]). Среды разработки общего назначения: ЕТ++ (Вейнанд (Weinand) [K 1989]) и управляемые событиями MVC-архитектуры (Шэн (Shan) [G 1989]). Коггинс (Coggins) [С 1990] изучил, в частности, развитие библиотек для C++.

Эмпирическое изучение объектно-ориентированных архитектур и их влияния на повторное использование можно найти в работе Льюиса (Lewis) [С 1992].

Глава 10

Архитектура клиент-сервер: складской учет

Конечно, любая СУБД требует адаптации к условиям конкретного предприятия, которую организации часто разбивают на две задачи: проектирование данных… Если эти два подхода не удастся совместить в рамках одного проекта, то… Еще в недалеком прошлом бизнес-приложения выполнялись на больших ЭВМ, что воздвигало для обычного служащего почти…

Определение границ задачи

При разработке такой системы заказчикам необходимо частично переосмыслить весь бизнес-процесс и учесть уже имеющиеся программы, чтобы не потерять…   Требования к системе складского учета В качестве части… Не удивительно, что системная архитектура будет отражать перечисленные функциональные свойства. На рис.10-1 приведена…

Архитектура клиент-сервер

Что можно отнести к категории клиент-сервер, а что нет, до сих пор является предметом жарких дискуссий [Также как и вопрос о том, что можно считать… Один из основных вопросов при проектировании архитектуры системы состоит в… Но на архитектурные решения оказывает влияние не только обилие стандартов. Имеют значение и такие вопросы, как защита…

Сценарии работы

Каждый из основных сценариев может включать в себя ряд вторичных: Заказанного клиентом товара нет на складе. Заказ клиента неверно … Для системы такой сложности, наверно, будут выявлены десятки основных… На рис. 10-2 представлен сценарий, в котором покупатель размещает свой заказ в телемаркетинговой фирме. В выполнении…

Модели баз данных

Разработка эффективной базы данных является трудной задачей, так как к ней предъявляется много взаимно противоречивых требований. Проектировщик… Между разработкой базы данных и созданием объектно-ориентированного приложения… Дэйт утверждает, что при проектировании любой базы данных нужно дать ответ на следующий вопрос: "Какие структуры…

SQL

При работе с объектно-ориентированной моделью, где данные и формы поведения соединены воедино, пользователю может понадобиться осуществить ряд транзакций с таблицами. Он, например, может захотеть добавить в базу нового поставщика, исключить из нее некоторые товары или изменить количество имеющегося в наличии товара. Может также появиться необходимость сделать различные выборки из базы данных, например, просмотреть список всех продуктов от определенного поставщика или получить список товаров, количество которых на складе недостаточно или избыточно с точки зрения заданного нами критерия. Может, наконец, понадобиться создать исчерпывающий отчет, в котором оценивается стоимость пополнения запасов до определенного уровня, используя наименее дорогих поставщиков. Подобные типы транзакций присутствуют почти в каждом приложении, использующем реляционную базу данных. Для взаимодействия с реляционными СУБД разработан стандартный язык - SQL (Structured Query Language, язык структурированных запросов). SQL может использоваться и в интерактивном режиме, и для программирования.

Самой важной конструкцией языка SQL является предложение SELECT следующего вида:

SELECT <attribute> FROM <relation> WHERE <condition>

Для того чтобы, например, получить коды продуктов, чей запас на складе меньше 100 единиц, можно написать следующее:

SELECT PRODUCTID, QUANTITY FROM INVENTORY WHERE QUANTITY < 100

Возможно создание и более сложных выборок. Например такой, где вместо кода товара фигурирует его наименование:

SELECT NAME, QUANTITY
FROM INVENTORY, PRODUCTS
WHERE QUANTITY < 100 AND INVENTORY.PRODUCTID = PRODUCTS.PRODUCTID

В этом предложении присутствует связь, позволяющая как бы объединять несколько отношений в одно. Данное предложение SELECT не создает новой таблицы, но оно возвращает набор строк. Одна выборка может содержать сколь угодно большое число строк, поэтому мы должны иметь средства для доступа к информации в каждой из них. Для этого в языке SQL введено понятие курсора, смысл которого схож с итерацией, о которой мы говорили в главе 3. Можно, например, определить курсор следующим образом:

DECLAREСCURSOR

FOR SELECT NAME, QUANTITY
FROM INVENTORY, PRODUCTS
WHERE QUANTITY < 100 AND INVENTORY.PRODUCTID = PRODUCTS.PRODUCTID

Чтобы открыть эту выборку, мы пишем

OPEN C

Для прочтения записей выборки используется оператор FETCH:

FETCH C INTO NAME, AMOUNT

И, наконец, после того, как работа завершена, мы закрываем курсор;

CLOSE C

Вместо использования курсора можно пойти другим путем: создать виртуальную таблицу, где содержатся результаты выборки. Такая виртуальная таблица называется представлением. С ним можно работать как с настоящей таблицей. Создадим, например, представление, содержащее наименование товара, имя поставщика и стоимость:

CREATE VIEW V (NAME, COMPANY, COST) AS
SELECT PRODUCTS.NAME, SUPPLIERS.COMPANY, PRICES.PRICE
FROM PRODUCTS, SUPPLIERS, PRICES
WHERE PRODUCTS.PRODUCTID = PRICES.PRODUCTID AND SUPPLIERS.SUPPLIERID = PRICES.SUPPLIERID

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

В нашей системе SQL-запросы будут играть роль абстракций низкого уровня. Пользователи вряд ли будут разбираться в SQL, ведь этот язык не является частью предметной области. Мы будем использовать SQL при реализации программы. Составлять свои SQL-предложения смогут только достаточно искушенные в программировании разработчики инструментальных средств нашей системы. От простых смертных, работающих с системой каждый день, язык запросов будет скрыт.

Рассмотрим следующую задачу: получив заказ, мы хотим определить имя сделавшей его компании. С точки зрения программиста SQL, это нетрудная задача. Однако, в нашем случае, когда основное программирование выполняется на C++, мы предпочли бы использовать следующее выражение:

currentOrder.customer().name()

С точки зрения объектно-ориентированного подхода это выражение вызывает селектор customer, возвращающий ссылку на клиента, а затем - селектор name, возвращающий имя клиента. На самом деле данное выражение вычисляется следующим запросом:

SELECT NAME
FROM ORDERS, CUSTOMERS
WHERE ORDERS.CUSTOMERID = CURRENTORDER.CUSTOMERID
AND ORDERS.CUSTOMERID = CUSTOMERS.CUSTOMERID

Спрятав от клиента детали реализации данного вызова, мы скрыли от него все неприятные особенности работы с SQL.

Отображение объектно-ориентированного представления мира в реляционное концептуально ясно, но обычно требует довольно утомительной проработки деталей [Большая часть преимуществ объектно-ориентированных баз данных заключается как раз в том, что в них эти утомительные детали скрыты от разработчика. Отображение классов в таблицы достаточно легко алгоритмизуемо, поэтому существует альтернатива ООСУБД: инструментальные средства, которые автоматически преобразуют определения классов C++ в реляционную схему и SQL-код. Тогда, например, если приложение запрашивает атрибут данного объекта, сгенерированный код создает необходимые SQL-предложения для стандартной реляционной базы данных, получает требуемые данные и доставляет их клиенту в форме, согласованной с интерфейсом C++]. По замечанию Румбаха, "Соединение объектной модели с реляционной базой данных - в целом довольно простая задача, за исключением вопросов, связанных с обобщением" [16]. Румбах предлагает также некоторые правила, которые следует учитывать при отображении классов и ассоциаций (включая агрегацию) на таблицы:

• Каждый класс отображается в одну или несколько таблиц.
• Каждое отношение "многие ко многим" отображается в отдельную таблицу.
• Каждое отношение "один ко многим" отображается в отдельную таблицу или соотносится с внешним ключом [17].

Далее он предлагает три альтернативных варианта отображения иерархии наследования в таблицы:

• Суперкласс и каждый его подкласс отображаются в таблицу.
• Атрибуты суперкласса реплицируются в каждой таблице (и каждый подкласс отображается в отдельную таблицу).
• Атрибуты всех подклассов переносятся на уровень суперкласса (таким образом мы имеем одну таблицу для всей иерархии наследования) [18].

Нет ничего удивительного в том, что существуют определенные ограничения по использованию SQL в низкоуровневой реализации [Недавно был предложен новый стандарт - SQL3, который содержит объектно-ориентированные расширения. Они существенно уменьшают семантические различия между объектно-ориентированным и реляционным взглядом на мир и устраняют многие другие ограничения SQL]. В частности, этот язык поддерживает ограниченный набор типов данных, а именно, символы, строки фиксированной длины, целые числа и вещественные числа с фиксированной и плавающей точкой. Отдельные реализации иногда умеют работать и с другими типами данных; однако представление информации в виде графических элементов или строк произвольной длины напрямую не поддерживается.

Анализ схем данных

Начнем с уже перечисленного нами списка основных абстракций. Применив к нему правила Румбаха, мы получим следующие таблицы базы данных (сначала… Затем следуют таблицы, отражающие классификацию продуктов и их наличие на… И, наконец, мы вводим таблицы для документопотока: OrderTable PurchaseOrderTable InvoiceTable …

Архитектура клиент/сервер

Для примера рассмотрим поведение классов Order и ProductRecord. Анализ первого из них дает нам следующий перечень необходимых операций: … Перечисленные сервисные операции можно сразу выразить на языке C++,… // типы идентификационных номеров typedef unsigned int OrderID;

Механизм транзакций

В нашем примере мы воспользовались только третьим способом. Но, в общем случае, могут использоваться все указанные виды взаимодействия в… Мы ранее уже упомянули о классе транзакции, но не остановились подробно на его… Действительно, транзакция является основным высокоуровневым видом взаимодействия сервера и клиента, а также между…

Создание клиентской части приложения

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

При создании нашей системы складского учета мы можем столкнуться с двумя препятствиями. Во-первых, нужно выяснить, каким должен быть "правильный" интерфейс пользователя. Во-вторых, желательно определить, какие общепринятые подходы мы можем использовать при создании интерфейса.

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

Второй вопрос находится в сфере стратегии проекта, но для его успешного разрешения у нас имеется множество хороших примеров. Существуют коммерческие продукты, например, Х Window System от MIT, Open Look, Windows от Microsoft, MacApp от Apple, NextStep от Next, Presentation Manager от IBM. Все эти продукты существенно различаются: некоторые основываются на сети, а некоторые опираются на концепцию ядра, некоторые позволяют действовать на уровне пикселей, а другие считают примитивами более сложные геометрические фигуры. В любом случае все они позволяют существенно упростить создание графического интерфейса пользователя. Ни один из перечисленных продуктов не родился за одну ночь. Все они постепенно развивались из самых простых систем, прошли путь проб и ошибок. В результате эти системы вобрали в себя набор абстракций, достаточный для построения пользовательского интерфейса. Поскольку нет однозначного ответа на вопрос о лучшем интерфейсе, то существуют несколько вариантов оконной модели.

В главе 9 мы уже упоминали о том, что при работе с большими библиотеками классов (каковыми являются и библиотеки графического интерфейса) важно понять механизмы их построения. Для нашей задачи основным механизмом является реакция GUI-приложений на события. Берсон указывал, что для клиентской части приложения существенны события, связанные со следующими объектами [24]:

• мышь
• клавиатура
• меню
• обновление окна
• изменения размера окна
• активизация/деактивация
• начало/завершение.

Мы добавим к этому перечню сетевые события [Например, механизмы DDE (Dynamic Data Exchange, динамический обмен данными) и OLE (Object Linking and Embedding, связь и внедрение объектов) от Microsoft представляют собой основанные на сообщениях протоколы, обеспечивающие обмен информацией между приложениями Windows]. Для нашей архитектуры они очень существенны, поскольку клиентская часть приложения связана с другими компонентами и приложениями через сеть. Описанная семантика хорошо согласуется с нашим подходом к построению класса Transaction, который может рассматриваться как посредник, пересылающий события от приложения к приложению. С точки зрения построения клиентской части, сетевые события являются разновидностью событий, что позволяет описать единый механизм реакции на события.

Берсон обратил внимание на наличие нескольких альтернативных моделей обработки событий [25]:

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

Изрядно упрощая, можно утверждать, что в интерфейсе MacApp используется цикл, в Motif - функции обратного вызова, a Microsoft Windows является примером гибридной модели.

Кроме первичного механизма, нам необходимо реализовать еще множество GUI-механизмов: рисование, прокрутка, работа с мытью, меню, сохранение и восстановление, печать, редактирование, обработка ошибок, распределение памяти. Безусловно, подробное рассмотрение всех этих вопросов находится вне рамок нашего анализа, поскольку каждая конкретная GUI-среда имеет свои собственные реализации этих механизмов.

Мы предлагаем разработчику клиентской части приложения выбрать подходящую GUI-среду разработки, изучить ее основные механизмы и правильно их применить.

10.3. Эволюция

Управление релизами

Для примера остановимся на трех простых транзакциях: занесение в базу нового клиента, добавление товара и принятие заказа. При реализации этих… При общем сроке проектирования системы в 12-18 месяцев необходимо каждые 3… В главе 6 уже упоминалось, что ключевым моментом при такой стратегам является выявление риска, поэтому для каждого…

Генераторы приложений

Языки четвертого поколения используются для генерации экранных форм и отчетов. На основании спецификаций они создают исполняемый код форм и отчетов.… Такой подход позволяет нам воспользоваться преимуществами 4GL, сохраняя… Такую же стратегию можно использовать и при реализации диалога пользователя с системой. Написание программ для…

Глава 11

Искусственный интеллект: криптоанализ

Эти и подобные им проблемы привлекают внимание исследователей в области искусственного интеллекта, которые стремятся улучшить наши представления о… Реализация в системе хотя бы одного из этих требований уже является непростой… Успехи энтузиастов в этой области несколько преувеличены; но, тем не менее, искусственный интеллект дал немало хороших…

Определение границ предметной области

В качестве первого шага анализа попробуйте решить (только честно, не заглядывая вперед!) следующую криптограмму записывая, каждый ваш шаг: Q AZWS DSSC KAS DXZNN DASNN Подсказка: буква w соответствует букве v исходного текста. Перебор всех возможных вариантов совершенно лишен смысла.…

Архитектура метафоры информационной доски

Вообразим себе комнату с большой доской, рядом с которой находится группа людей, держащих в руках фрагменты изображения. Процесс начинают… Из рис. 11-1 видно, что основу метода составляют три элемента: информационная… Энглемор и Морган уточняют: "необходимые для решения задачи знания о предметной области разделены на несколько…

Архитектура информационной доски

Объекты информационной доски. Объекты на доске образуют иерархию, отражающую иерархичность различных уровней абстракции источников знаний. Таким… Источники знаний должны пользоваться общей информацией о сделанных в процессе… Наконец, источники знания делают предположения о связи между буквами реального и шифровального алфавитов, так что мы…

Интеграция

Интеграция объектов верхнего уровня. На рис. 11-7 показана диаграмма объектов нашей системы на самом верхнем уровне, которая полностью соответствует… На диаграмме появился экземпляр класса Cryptographer. Он агрегирует объекты…

Добавление источников знаний

Убедившись в правильной работе механизма вывода, можно последовательно вводить в систему источники знаний. Целесообразность именно такого процесса… Реализация источников знаний является предметом инженерии знаний. Для… В процессе реализации источников знании могут выявиться общие для нескольких источников правила и/или поведение.…

Расширение функциональных возможностей

В интеллектуальных системах очень важно наряду с решением задачи получить информацию о самом процессе поиска решения. Для этого нужно придать… Для реализации такого свойства необходимо сделать две вещи. Во-первых, нужно… Посмотрим, какие классы нам понадобятся. Прежде всего, введем класс Action, регистрирующий действия источников знаний…

Изменение технических требований

Первое требование самое простое, поскольку связь нашей системы с английским языком не является существенной. Она отражается только на правилах… Второе требование существенно сложнее, но разрешимо в рамках механизма доски.… Труднее всего выполнить последнее требование, так как обучение компьютеров относится к области искусственного…

Глава 12

Управление: контроль за движением поездов

Если за создание большой системы возьмется разработчик, который занимался написанием в оконной среде небольших программ, рассчитанных на одного… В этой главе представлена как раз такая задача. Она демонстрирует, как… 12.1. Анализ

Определение границ проблемной области

Железные дороги по-прежнему являются коммерческими и, следовательно, они должны быть прибыльными. Железнодорожные компании обязаны постоянно… Такие автоматические и полуавтоматические системы сегодня существуют в Швеции,… Требования к системе управления движением

Системные и программные требования: хрупкий компромисс

Когда мы уже имеем скелет архитектуры (как на рис. 12-1), можно с помощью экспертов в данной прикладной области приступать к разработке основных… В системе таких размеров запросто можно найти сотни первичных сценариев [Мы…

Ключевые абстракции и механизмы

Как мы пришли к выводу, что именно в этих подзадачах сконцентрирован основной риск разработки? Систему связывает воедино распределенная сеть передачи данных. С помощью радио… Кроме того, система должна одновременно хранить информацию о местоположении и планируемых маршрутах множества поездов.…

Механизм передачи сообщений

Сейчас нас интересует второй уровень передачи сообщений. Так как система включает территориально распределенную сеть, мы должны учесть такие… Первый шаг при определении сообщений в системе - анализ взаимодействия каждой… Очень важно, чтобы на данном этапе проектирования внимание было сосредоточено на сути, а не на форме сообщений.…

Планирование расписания поездов

Наш первый шаг состоит в точном определении того, из каких частей состоит план поезда. Для этого мы должны перечислить всех потенциальных клиентов… На рис. 12-6 приведены стратегические проектные решения, касающиеся структуры… Из рис. 12-6 видно, что класс TrainPlan имеет один статический объект типа UniqueId, так называемое магическое число,…

Отображение информации

Рассмотрим, например, отображение информации о профиле и качестве участков пути. Требуется, чтобы изображение появлялось в двух местах: в… Однако, этот подход не лишен недостатков. Мы, вероятно, получим множество…

Механизм опроса датчиков

Воспроизведение этого поведения для каждого датчика не только утомительно и чревато ошибками, но и раздувает объем кода. Если мы с самого начала не… Мы уже решали аналогичную задачу в главе 8, применительно к метеорологической… Это хороший пример повторного использования проектных решении в различных прикладных областях.

Модульная архитектура

Проектирование программного обеспечения для очень больших систем должно начинаться до полного завершения проектирования аппаратных средств.… На ранних этапах мы должны разумно провести декомпозицию программного… Желательно, чтобы системные архитекторы поэкспериментировали с несколькими альтернативными декомпозициями на…

Спецификация подсистем

Диаграмма модулей на рис. 12-9 полезна, но не полна, так как каждая из подсистем на ней слишком велика для реализации одним небольшим коллективом… Рассмотрим для примера подсистему NetworkFacilities (сеть). Мы решили разбить… Подсистема, названная Databases (базы данных), построена на основе ресурсов подсистемы NetworkFacilities и служит для…

Добавление новых функций

Рассмотрим единственное добавление к нашим требованиям: обработку платежной ведомости. Предположим, анализ показал, что работа с платежными… Дальнейший анализ показывает, что от интеграции обработки платежной ведомости… Что добавление этой функции затрагивает в нашем проекте? Очень немногое. Новую подсистему можно добавить в подсистему…

Изменение аппаратных средств

Аналогично, радикальные изменения в стандартах телекоммуникации затронут нашу реализацию в очень ограниченном отношении. Наш проект гарантирует, что… Итак, воображаемые изменения, которые мы вводили, не смогли разрушить… Дополнительная литература

Послесловие

Потребность в сложных программных системах растет с ошеломляющей быстротой. По мере того, как увеличивается производительность аппаратуры и все…

Приложение

Объектно-ориентированные языки программирования

Данное приложение предназначено для читателей, не знакомых с языками программирования, упоминавшимися в этой книге. Мы приводим сводное описание… А.1. Концепции В настоящее время насчитывается более двух тысяч языков программирования высокого уровня. Большинство этих языков…

Происхождение

Развитие Smalltalk потребовало почти десятилетних усилий группы энтузиастов. Главным архитектором на протяжении почти всей работы был Дэн Ингалс… Известны пять выпусков языка Smalltalk, обозначаемых по году их появления: Smalltalk-72, -74. -76, -78, и самое свежее воплощение - Smalltalk-80. Реализации 1972 и 1974 годов заложили основу…

Обзор

Как пишет Ингалс: "Цель проекта Smalltalk - сделать мир информации доступным для детей любого возраста. Вся трудность состоит в том, чтобы найти и применить достаточно простые и эффективные метафоры, которые позволят человеку свободно оперировать самой разнообразной информацией от чисел и текстов до звуковых и зрительных образов" [5]. В основу языка положены две простые идеи:

• все является объектами;
• объекты взаимодействуют, обмениваясь сообщениями.

В табл. А-1 приведены характеристики языка Smalltalk с точки зрения семи основных элементов объектного подхода. Множественное наследование в принципе может быть реализовано за счет переопределения некоторых методов-примитивов [6].

Абстракции	Переменные экземпляра Методы экземпляра Переменные класса Методы класса	Да Да Да Да
Инкапсуляция	Переменных Методов	Закрытые Открытые
Модульность	Разновидности модулей	Нет
Иерархии	Наследование Шаблоны Метаклассы	Одиночное Нет Да
Типизация	Сильная типизация Полиморфизм	Нет Да (одиночный)
Параллельность	Многозадачность	Непрямая (посредством классов)
Сохраняемость	Долгоживущие объекты	Нет

Таблица А-1. Smalltalk.

Пример

<пример пропущен>

Ссылки

Основными руководствами по языку Smalltalk являются книги "Smalltalk-80:

The Language", Голдберг и Робсон [7]; "Smalltalk-80: The Interactive Programming Environment", Голдберг [8]; "Smalltalk-80: Bit of History Words of Advice", Kpacнер, [9]. ЛаЛонд и Пух [10] подробно исследуют Smalltalk-80, в том числе библиотеки классов и средства разработки приложений.

А.3. Object Pascal

Происхождение

Обзор

Шмукер (Schmucker) утверждает, что "Object Pascal - это "скелет" объектно-ориентированного языка [В последние годы этот язык стал очень популярен благодаря системе Delphi фирмы Borland. - Примеч. ред.]. В нем нет методов класса, переменных класса, множественного наследования и метаклассов. Эти механизмы исключены специально, чтобы сделать язык простым для изучения начинающими "объектными" программистами" [11].

В табл. А-2 приведены общие характеристики Object Pascal.

Абстракции	Переменные экземпляра Методы экземпляра Переменные класса Методы класса	Да Да Нет Нет
Инкапсуляция	Переменных Методов	Открытые Открытые
Модульность	Разновидности модулей	Модуль (unit)
Иерархии	Наследование Шаблоны Метаклассы	Одиночное Нет Нет
Типизация	Сильная типизация Полиморфизм	Да Да (одиночный)
Параллельность	Многозадачность	Нет
Сохраняемость	Долгоживущие объекты	Нет

Таблица А-2. Object Pascal.

Ссылки

Основным руководством по Object Pascal является "MPW Object Pascal Reference" от Apple [12].

А.4. C++

Происхождение

Известны несколько версий C++. В версии 1.0 реализованы основные механизмы объектно-ориентированного программирования, такие как одиночное… Первые компиляторы C++ строились на основе препроцессора для языка С,…

Обзор

Страуструп пишет: "C++ создавался с целью избавить автора и его друзей от необходимости программировать на ассемблере, С или других современных языках такого уровня. Главной задачей было придумать язык, на котором удобно писать хорошие программы и с которым программисту приятно работать. C++ никогда не проектировался на бумаге. Его проектирование, документирование и реализация выполнялись одновременно" [13]. C++ исправил многие недостатки С и ввел описания классов, контроль типов, перегрузку функций, управление памятью, постоянные типы, ссылки, встраиваемые функции, производные классы и виртуальные функции [14].

Характеристики C++ приведены в табл. А-3.

Абстракции	Переменные экземпляра Методы экземпляра Переменные класса Методы класса	Да Да Да Да
Инкапсуляция	Переменных Методов	Открытые, защищенные, закрытые Открытые, защищенные, закрытые
Модульность	Разновидности модулей	файл
Иерархии	Наследование Шаблоны Метаклассы	Множественное Да Нет
Типизация	Сильная типизация Полиморфизм	Да Да (одиночный)
Параллельность	Многозадачность	Непрямая (посредством классов)
Сохраняемость	Долгоживущие объекты	Нет

Таблица А-3. C++.

Пример

Снова вернемся к задаче определения фигур. В C++ принято описывать интерфейсную часть классов в заголовочных файлах. Мы можем написать:

struct point {

int x;
int y;

};

class Shape {
public:

Shape();
void setCenter(Point p};
virtual void draw() = 0;
Point center() const;

private

Point theCenter;

};

class Circle : public Shape {
public:

Circle();
void setRadius(int r);
virtual void draw();
int radius() const;

private:

int theRadius;

};

class Rectangle : public Shape {
public:

Rectangle();
void setHeight(int h);
void setWidth(int w);
virtual void draw();
int height() conat;
int width() const;

private:

int theHeigh;
int theWidth;

};

class SolidRectangle : public Rectangle {
public:

virtual void draw();

};

Определение C++ не предполагает наличия библиотеки классов. Для наших целей мы предположим наличие программного интерфейса Х Windows и глобальных объектов Display, window, GraphicsContext (требуемых xlib). Теперь можно завершить разработку, написав в отдельном файле реализацию методов, перечисленных выше:

Shape::Shape()
{

theCenter.x = 0;
theCenter.y = 0;

};

void Shape::getCenter(Point p)
{

theCenter = p;

};

Point Shape::center() const
{

return theCenter;

};

Circle::Circle() : theRadius(0) {};

void Circle: :setRadius( int r)
{

theRadius = r;

};

void Circle::draw()
{

int x = (center().x - theRadius);
int y = (center().y - theRadius);
XDrawArc(Display, Window, GraphicsContext, x, y,
(theRadius • 2), (theRadius * 2), 0, (360 • 64));

};

int Circle::radius() const
{

return theRadius;

};

Rectangle::Rectangle() : theHeight(0), theWidth(0) {};

void Rectangle::setHeight( int h)
{

theHeight = h;

};

void Rectangle::setWidth( int w)
{

theWidth = w;

};

void Rectangle::draw()
{

int x = (center().x - (theWidth / 2));
int y = (center().y - (theHeight / 2));
XDrawRectangle(Display, Window, GraphicsContext, x, y, thewidth, theHeight);

};

int Rectangle::height() const
{

return theHeight;

};

int Rectangle::width() const
{

return thewidth;

};

void SolidRectangle::draw()
{

Rectangle::draw();
int x - (center().x - (width() / 2));
int y - (center().y - (height() / 2));
gc oldGraphicsContext = GraphicsContext;
XSetForeground(Display, GraphicsContext, Gray);
XDrawFilled(Display, Window, GraphicsContext, x, y,
width(), height());
GraphicsContext = OldGraphicsContext;

};

Ссылки

Основной ссылкой по C++ является "Annotated C++ Reference Manual" Эллис и Страуструпа [15]. Кроме того, Страуструп [16] предложил углубленный анализ языка и его использования в контексте объектно-ориентированного проектирования.

А.5. Common Lisp Object System (CLOS)

Происхождение

Идея стандартизации была поддержана летней конференцией ACM по Lisp и функциональному программированию 1986 года, в результате чего была создана… Серьезное влияние на проект CLOS оказали языки NewFlavors и CommonLoops. После…

Обзор

Кип отмечает, что в проекте CLOS ставились три основные цели. CLOS должен:

• представлять собой стандартное расширение языка, включающее все наиболее полезные свойства существующей объектно-ориентированной парадигмы;
• обеспечить эффективный и гибкий интерфейс программиста, позволяющий реализовать большинство прикладных задач;
• проектироваться как расширяемый протокол, так, чтобы можно было изменять его поведение, тем самым стимулируя дальнейшие исследования в области объектно-ориентированного программирования [17].

Обзор характеристик CLOS можно найти и табл. А-4. Не поддерживая непосредственно механизм долгоживущих объектов, CLOS имеет расширения с протоколом метаобъектов, реализующих этот механизм [18].

Абстракции	Переменные экземпляра Методы экземпляра Переменные класса Методы класса	Да Да Да Да
Инкапсуляция	Переменных Методов	Чтение, запись, доступ Открытые
Модульность	Разновидности модулей	Пакет
Иерархии	Наследование Шаблоны Метаклассы	Множественное Нет Да
Типизация	Сильная типизация Полиморфизм	Возможна Да (множественный)
Параллельность	Многозадачность	Да
Сохраняемость	Долгоживущие объекты	Нет

Таблица А-4. CLOS.

Ссылки

Основным руководством по языку CLOS является -"Common Lisp Object System Specification" [19].

А.6. Ada

Происхождение

Проект-победитель вначале носил условное наименование Green (в конкурсе проект имел зеленый кодовый знак); позднее он получил имя Ada в честь Ады… Непосредственными предшественниками Ada являются Pascal и его производные,…

Обзор

Разработчики Ada прежде всего беспокоились о:

• надежности и эксплуатационных качествах программ;
• программировании как разновидности человеческой деятельности;
• эффективности [20].

В табл. А-5 приведены основные характеристики языка Ada с точки зрения объектного подхода.

Абстракции	Переменные экземпляра Методы экземпляра Переменные класса Методы класса	Да Да Нет Нет
Инкапсуляция	Переменных Методов	Открытые, закрытые Открытые, закрытые
Модульность	Разновидности модулей	Пакет
Иерархии	Наследование Шаблоны Метаклассы	Нет (входит в Ada9x) Да Нет
Типизация	Сильная типизация Полиморфизм	Да Нет (входит в Ada9x)
Параллельность	Многозадачность	Да
Сохраняемость	Долгоживущие объекты	Нет

Таблица А-5. Ada.

Ссылки

Основным руководством по языку Ada является "Reference Manual for the Ada Programming Language" [21].

A.7. Eiffel

Происхождение

Несмотря на сильное влияние Simula, Eiffel - вполне самостоятельный объектно-ориентированный язык со своей собственной средой разработки. Eiffel поддерживает динамическое связывание и статическую типизацию, тем самым… Неотъемлемой частью языка являются пред- и постусловия, то есть утверждения, которые должны выполняться при входе в…

Обзор

Eiffel поощряет хорошее программирование, добротную спецификацию классов, сильную типизацию и повторное использование, как через наследование, так и через параметризацию. Формальная трактовка исключительных ситуаций позволяет жестко специфицировать интерфейсы классов при реализации.

Eiffel предоставляет законченную среду разработки программ, включая специальный редактор с выделением синтаксиса, генератор документации, библиотеки классов и броузер. Кроме того, поддерживаются средства управления кодом и сборкой программ.

Свойства языка с точки зрения нашей модели показаны в табл. А-6.

Абстракции	Переменные экземпляра Методы экземпляра Переменные класса Методы класса	Да Да Нет Нет
Инкапсуляция	Переменных Методов	Закрытые Открытые, закрытые
Модульность	Разновидности модулей	Блок (unit)
Иерархии	Наследование Шаблоны Метаклассы	Множественное Да Нет
Типизация	Сильная типизация Полиморфизм	Да Да
Параллельность	Многозадачность	Нет
Сохраняемость	Долгоживущие объекты	Нет

Таблица А-6. Eiffel.

Ссылки

Лучше всего взять книгу Мейера "Object Oriented Software Construction" [22].

А.8. Другие объектно-ориентированные языки программирования

На рис. А-2 вы найдете названия многих важных объектных и объектно-ориентированных языков, в библиографии есть ссылки на информацию о большинстве из них.

<рисунок пропущен>

Словарь терминов

абстрактная операция, abstract operation. Объявленная, но не реализованная операция в абстрактном классе. В C++ абстрактные операции объявляются как… абстрактный класс, abstract class. Класс, который не может иметь экземпляров.… абстракция, abstraction. Существенные характеристики объекта, которые отличают его от всех других объектов и четко…

Литературные ссылки

Предисловие

Mills, Н. 1985. DPMA and Human Productivity. Houscon, TX: Data Processing Management, Association.

Часть I. Концепции

Wagner, J. 1986. The Search for Signs of Intelligent Life in the Universe. New York, NY: Harper and Row, p.202. By permission of ICM. Inc.

Глава 1. Сложность

[1] Brooks, F. April 1987. No Silver Bullet: Essence and Accidents of Software Engineering. IEEE Computer vol.20(4), p.12.

[2] Peters, L. 1981. Software Design. New York, NY: Yourdon Press, p.22.

[3] Brooks. No Silver Bullet, p.11.

[4] Parnas, D. July 1985. Software Aspects ofStrategic Defense Systems. Victoria, Canada: University of Victoria. Report DCS-47-IR.

[5] Peter, L. 1986. The Peter Pyramid. New York, NY: William Morrow, p.153.

[6] Waldrop, M. 1992. Complexity: The Emerging Science at the Edge of Order and Chaos. New-York, NY: Simon and Schuster.

[7] Courtois, P. June 1985. On Time and Space Decomposition of Complex Structures. Communications of the ACM vol.28(6), p.596.

[8] Simon, H. 1982. The Sciences of the Artificial. Cambridge, MA: The MIT Press, p.218.

[9] Rechtin, E. October 1992. The Art of Systems Architecting. IEEE Spectrum, vol.29( 10), p.66.

[10] Simon. Sciences, p.217.

[11] Ibid, р. 221.

[12] Ibid, p.209.

[13] Gall, J. 1986. Systemantics: How Systems Really Work and How They Fail. Second Edition. Ann Arbor, MI: the General Systemantics Press, p.65.

[14] Miller, G. March 1956. The Magical Number Seven, Plus or Minus Two: Some Limits on Our Capacity for Processing Information. The Psychological Reviev vol.63(2), p.86.

[15] Simon. Sciences, p.81.

[16] Dijktra, E. 1979. Programming Considered as a Human Activity. Classics in Software Engineering. New York, NY: Yourdon Press, p.5.

[17] Parnas, D. December 1985. Software Aspects of Strategic Defense Systems. Communications of the ACM vol.28(12), p.1328.

[18] Tsai, J. and Ridge, J. November 1988. Intelligent Support for Specifications Transformation. IEEE Software vol.5(6), p. 34.

[19] Stein, J. March 1988. Object-oriented Programming and Database Design. Dr. Dobb's Journal of Software Tools for the Professional Programmer, No. 137, p.18.

[20] Peters. Software Design.

[21] Yau, S. and Tsai, J. June 1986. A Survey of Software Design Techniques. IEEE Transactions on Software Engineering vol.SE-12(6).

[22] Teledyne Brown Engineering. Software Methodology Catalog. Report MC87-COMM/ADP-0036. October 1987. Tinton Falls, NJ.

[23] Sommerville, 1.1985. Software Engineering. Second Edition. Workingham, England: Addison-Wesley, p.68.

[24] Yourdon, E. and Constantine, L. 1979. Structured Design. Englewood Cliffs, NJ: Prentice-Hall.

[25] Myers, G. 1978. Composite/Structured Design. New York, NY: Van Nostrand Reinhold.

[26] Page-Jones, M. 1988. The Practical Guide to Structured. Systems Design. Englewood Cliffs. NJ: Yourdon Press.

[27] Wirth, N. January 1983. Program Development by Stepwise Refinement. Communications of the ACM vol.26(1).

[28] Wirth, N. 1986. Algorithms and Data Structures. Englewood Cliffs, NJ: Prentice-Hall.

[29] Dahl, O., Dijkstra, E. and Hoare, C.A.R. 1972. Structured Programming. London. England: Academic Press.

[30] Mills, H., Linger, R. and Hevner, A. 1986. Principles of Information System Design and Analysis. Orlando, FL: Academic Press.

[31] Jackson, M. 1975. Principles of Program Design. Orlando, FL: Academic Press.

[32] Jackson, M. 1983. System Development. Englewood Cliffs, NJ: Prentice-Hall.

[33] Orr, K. 1971. Structured Systems Development. New York, NY: Yourdon Press.

[34| Langdon, G. 1982. Computer Design. San Jose, CA: Computeach Press, p.6.

[35] Miller. Magical Number, p.95.

[36] Shaw, M. 1981. ALPHARD: From and Content. New York, NY: Springer-Verlag, p.6.

[37] Goldberg, A. 1984. Smalltalft-80: The Interactive Programming Environment. Reading, MA: Addison-Wesley, p.80.

[38] Petroski, H. 1985. To Engineerls Human. St Martin's Press: New York, p.40.

[39] Dijkstra, E. January 1993. American Programmer vol.6(1).

[40] Mostow, J. Spring 1985. Toward Better Models of the Design Process. Al Magazine vol.6(1), p.44.

[41] Stroustrup, В. 1991. The C++ Programming Language. Second Edition. Reading, MA: Addison-Wesley, p.366.

[42] Eastman, N. 1984. Software Engineering and Technology. Technical Directions vol.10(1): Bethesda, MD: IBM Federal Systems Division, p.5.

[43] Brooks. No Silver Bullet, p.10.

Глава 2. Объектная модель

[1] Rentsch, Т. September 1982. Object-Oriented Programming. SIGPLAN Notices vol.17(12), p.51.

[2] Wegner, P. June 1981. The Ada Programming Language and Environment. Unpublished draft.

[3] Abbott, R. August 1987. Knowledge Abstraction. Communications of the ACM vol.30(8), p.664.

[4] Ibid, p.664.

[5] Shankar, K. 1984. Data Design: Types, Structures, and Abstractions. Handbook of Software Engineering. New York, NY: Van Nostrand Reinhold, p.253.

[6] Macintosh MacApp 1.1.1 Programmer's Reference. 1986. Cupertino, CA: Apple Computer, p.2.

[7] Bhaskar, K. October 1983. How Object-oriented Is Your System? SICPLAK Notices vol.18(10), p.8.

[8] Stefik, M. and Bobrow, D. Winter 1986. Object-oriented Programming: Themes and Variations, AI Magazine vol.6(4), p.41.

[9] Yonezawa, A. and Tokoro, M. 1987. ObjecE-Oriented Concurrent Programming. Cambridge, MA: The MIT Press, p.2.

[10] Levy, H. 1984. Capability-Based Computer Systems. Bedford, MA: Digital Press, p.13.

[11] Ramamoorthy, С. and Sheu, P. Fall 1988. Object-oriented Systems. IEEE Expert vol.3(3), p.14.

[12] Myers, G. 1982. Advances in Computer Architecture. Second Edition. New York, NY: John Wiley and Sons, p.58.

[13] Levy. Capability-Based Computer.

[14] Kavi, K. and Chen, D. 1987. Architectural Support for Object-oriented Languages. Proceedings of the Thirty-second IEEE Computer Society International Conference. IEEE.

[15] iAPX432 Object Primer. 1981. Santa Clara, CA: Intel Corporation.

[16] Dally, W.J. and Kajiya.J.T. March 1985. An Object-oriented Architecture, SIGARCH Newsletter vol.13(3).

[17] Dahlby, S., Henry, G., Reynolds, D. and Taylor, P. 1982. The IBM System/38: A High Level Machine, in Computer Structures: Principles and Examples. New York, NY: McGraw-Hill.

[18] Dijkstra. E. May 1968. The Structure of the "THE" Multiprogramming System. Communications of the ACM vol.11(5).

[19] Pashtan, A. 1982. Object-Oriented Operating Systems: An Emerging Design Methodology. Proceedings of the ACM'S2 Conference. ACM.

[20] Parnas, D. 1979. On the Criteria to the Be Used in Decomposing Systems into Modules, in Classics in Software Engineering. New York, NY: Yourdon Press.

[21] Liskov, B. and Zilles, S. 1977. An Introduction to Formal Specifications of Data Abstractions. Current Trends in Programming Methodology: Software Specification and Design vol.1. Englewood Cliffs. NJ: Prentice-Hall.

[22] Guttag, J. 1980. Abstract Data Types and the Development of Data Structures, in Programming Language Design. New York, NY: Computer Society Press.

[23] Shaw. Abstraction Techniques.

[24] Nygaard, K. and Dahl, O-J. 1981. The Development of the Simula Languages, in History of Programming Languages. New York, NY: Academic Press, p.460.

[25] Atkinson, M. and Buneman, P. June 1987. Types and Persistence in Database Programming Languages. ACM Computing Surveys vol.19(2), p.105.

[26] Rumbaugh, J. April 1988. Relational Database Design Using an Object-oriented Methodology. Communications of the ACM vol.31(4), p.415.

[27] Chen, P. March 1976. The Entity-Relationship Model - Toward a Unified View of Data. ACM Transactions on Database Systems vol.1(1).

[28] Barr,A.and Feigenbaum. E. 1981. The Handbook ofArtificial Intelligence. vol.1.Los Altos, CA: William Kaufmann, p.216.

[29] Stillings, N., Feinstein, M., Garfield.J., Rissland, E., Rosenbaum, D., Weisler. S., Baker-Ward, L. 1987. Cognitive Science: An Introduction. Cambridge, MA: The MIT Press, p.305.

[30] Rand, Ayn. 1979. Introduction to Objectivist Epistemology. New York, NY: New American Library.

[31] Minsky, M. 1986. The Society of Mind. New York, NY: Simon and Schuster.

[32] Jones, A. 1979. The Object Model: A Conceptual Tool for Structuring Software. Operating Systems. New York, NY: Springer-Verlag, p.8.

[33] Stroustrup, В. May 1988. What Is Object-oriented Programming? IEEE Software vol.5(3), p.10.

[34] Cardelli, L. and Wegner, P. On Understanding Types, Data Abstraction, and Polymorphism. December 1985. ACM Computing Surveys vol.17(4). p.481.

[35] DeMarco, T. 1979. Structured Analysis and System Specification. Englewood Cliffs, NJ: Prentice-Hall.

[36] Yourdon, E. 1989. Modem Structured Analysis. Englewood Cliffs, NJ: Prentice-Hall.

[37] Gane, C. and Sarson, T. 1979. Structured Systems Analysis. Englewood Cliffs, NJ: Prentice-Hall.

[38] Ward, P. and Mellor, S. 1985. Structured Development for Real-Time Systems. Englewood Cliffs, NJ: Yourdon Press.

[39] Hatley, D. and Pirbhai, 1.1988. Strategies for Real-Time System Specification. New York, NY: Dorset House.

[40] Jenkins, M. and Glasgow, J. January 1986. Programming Styles in Nial. IEEE Software vol.3(1), p.48.

[41] Bobrow, D. and Stefik, M. February 1986. Perspectives on Artificial Intelligence Programming. Science vol.231, p.951.

[42] Dahl, O., Dijkstra, E. and Hoare, C.A.R. 1972. Structured Programming. London, England: Academic Press, p.83.

[43] Shaw, M. October 1984. Abstraction Techniques in Modern Programming Languages. IEEE Software vol.1(4), p.10.

[44] Berzins, V. Gray, M. and Naumann, D. May 1986. Abstraction-Based Software Development. Communications of the ACM vol. 29(5), p.403.

[45] Abelson, H. and Sussman, G. 1985. Structure and Interpretation of Computer Programs. Cambridge, MA: The MIT Press, p.126.

[46] Ibid, p.132.

[47] Seidewitz, E. and Stark, M. 1986. Towards a General Object-oriented Software Development Methodology. Proceedings of the First International Conference on Ada Programming Language Applications for the NASA Space Station. NASA Lyndon B.Johnson Space Center. TX: NASA, p.D.4.6.4.

[48] Meyer, B. 1988. Object-oriented Software Construction. New York. NY: Prentice-Hall.

[49] Wirfs-Brock. R. and Wilkerson, B. October 1989. Object-oriented Design: A Responsibility-Driven Approach. SICPLAN Notices vol.24(10).

[50] Ingalls, D. The Smalltalk-76 Programming System Design and Implementation. Proceedings of the Fifth Annual ACM Symposium on Principles of Programming Languages. ACM, p.9.

[51] Gannon.J., Hamlet. R. and Mills. H. July 1987. Theory of Modules. IEEE Transactions on Software Engineering vol.SE-13(7), p.820.

[52] Date, С. 1986. Relational Database: Selected Writings. Reading, MA: Addison-Wesley, p.180.

[53] Liskov, B. May 1988. Data Abstraction and Hierarchy. SIGPLAN Notices vol.23(5). p.19.

[54] Britton, K. and Parnas. D. December 8. 1981. A-7E Softs-are Module Guide. Washington, D.C. Naval Research Laboratory, Report 4702, p.24.

[55] Gabriel, R. 1990. Private Communication.

[56] Stroustrup, B. 1988. Private Communication.

[57] Myers. G. 1978. Composite/Structured Design. New York. NY: Van Nostrand Reinhold, p.21.

[58] Liskov, B. 1980. A Design Methodology for Reliable Software Systems, in Tutorial on Software Design Techniques. Third Edition. New York, NY: IEEE Computer Society, p.66.

[59] Zelkowitz, M. June 1978. Perspectives on Software Engineering. ACM Computing Surveys vol.10(2), p.20.

[60] Parnas, D., Clements, P. and Weiss, D. March 1985. The Modular Structure of Complex Systems. IEEE Transactions on Software Engineering vol.SE-11(3), p.260.

[61] Britton and Parnas. A-7E Software, p.2.

[62] Parnas. D., Clements, P. and Weiss, D. 1983. Enhancing Reusability with Information Hiding. Proceedings of the Workshop on Reusability in Programming. Stratford, CT: ITT Programming. p.241.

[63] Meyer. Object-oriented Software Construction, a. 47.

[64] Сох, В. 1986. Object-Oriented Programming: An Evolutionary Approach. Reading, MA: Addison-Wesley, p.69.

[65] Danforth, S. and Tomlinson. C. March 1988. Type Theories and Object-Oriented Programming. ACM Computing Surveys vol.20(1), p.34.

[66] Liskov. 1988. р. 23.

[67] As quoted in Liskov. 1980. p.67.

[68] Zilles, S. 1984. Types, Algebras, and Modeling, in On Conceptual Modeling: Perspectives from Artificial Intelligence. Databases, and Programming Languages. New York, NY: Springer-Verlag, p.442.

[69] Doming, A. and Ingalls, D. 1982. A Type Declaration and Inference System for Smalltalk. Palo Alto, CA: Xerox Palo Research Center, p.134.

[70] Wegner. P. October 1987. Dimensions of Object-oriented Language Design. SIGPLAN Notices vol.22(12). p.171.

[71] Stroustrup, B. 1992. Private communication.

[72] Tesler, L. August 1981. The Smalltalk Environment. Byte vol.6(8), p.142.

[73] Borning and Ingalls. Type Declaration, p.133.

[74] Thomas, D. March 1989. What's in an Object? Byte vol.14(3), p.232.

[75] Lim, J. and Johnson, R. April 1989. The Heart of Object-oriented Concurrent Programming. SIGPLAN Notices vol.24(4), p.165.

[76] Ibid, p.l65.

[77] Black, A., Hutchinson, N., Jul, E., Levy, H. and Carter, L. July 1986. Distribution and Abstract Types in Emerald. Report 86-02-04. Seattle, WA: University of Washington, p.3.

[78] Proceedings of the ACM SIGPLAN Workshop on Object-Based Concurrent Programming. April 1989. SIGPLAN Notices vol.24(4), p.1.

[79] Atkinson, M., Bailey, P., Chisholm, K., Cockshott, P. and Morrison, R. 1983. An Approach to Persistent Programming. The Computer Journal vol.26(4), p.360.

[80] Khoshafian, S. and Copeland, G. November 1986. Object Identity. SIGPLAN Notices vol.21(11), p.409.

[81] Vbase Technical Overview. September 1987. Billerica, MA: Ontologic, p.4.

[82] Stroustrup, В. November 1987. Possible Directions for C++. Proceedings of the USENIX C++ Workshop. Santa Fe, NM, p.14.

[83] Meyer. Object-oriented Software Construction, p.30-31.

[84] Robson, D. August 1981. Object-oriented Software Systems, Byte vol.6(8), p.74.

Глава 3. Классы и объекты

[1] Lefrancois, G. 1977. Of Children: An Introduction to Child Development. Second Edition. Belmont, CA: Wadsworth, p.244-246.

[2] Nygaard, K. and Dahl, O-J. 1981. The Development of the Simula Languages, in History of Programming Languages. New York, NY: Academic Press, p.462.

[3] Halbert, D. and O'Brien, P. September 1988. Using Types and Inheritance in Object-oriented Programming. IEEE Software vol. 4(5), p.73.

[4] Smith, M. and Tockey, S. 1988. An Integrated Approach to Software Requirements Definition Using Objects. Seattle, WA: Boeing Commercial Airplane Support Division, p.132.

[5] Сох, В. 1986. Object-oriented Programming: An Evolutionary Approach. Reading, MA: Addison-Wesley, p.29.

[6] MacLennan, B. December 1982. Values and Objects in Programming Languages. SICPLAN Notices vol.17(12), p.78.

[7] Lippman, S. 1989. C++ Primer. Reading, MA: Addison-Wesley, p.185.

[8] Adams, S. 1993. Private communication.

[9] Wirfs-Brock, R.,Wilkerson, В. and Wiener, L. 1990. Designing Object-oriented Software. Englewood Cliffs, New Jersey: Prentice-Hall, p.61.

[10] Rubin, K. 1993. Private communication.

[11] Macintosh MacApp 1.1.1 Programmer's Reference. 1986. Cupertino. CA: Apple Computer, p.4.

[12] Khoshafian, S. and Copeland, G. November 1986. Object Identity. SIGPLAN Notices vol.21(ll).p.406.

[13] Ingalls, D. 1981. Design Principles behind Smalltalk. Byte vol.6(8), p.290.

[14] Gall, J. 1986. Systemantics: Ноw Systems Really Work and How They Fail. Second. Edition. Ann Arbor, MI: The General Systemantics Press, p.158.

[15] Seidewitz, E. and Stark, M. 1986. Towards a General Object-oriented Software Development Methodology. Proceedings of the First International Conference on Ada Programming Language Applications for the NASA Space Station. NASA Lyndon B. Johnson Space Center. TX: NASA. p.D.4.6.4.

[16] Rumbaugh, J., Blaha, M., Premerlani, W., Eddy, F. and Lorensen, W. 1991. Object-oriented Modeling and Design. Englewood Cliffs, New Jersey: Prentice-Hall, p.459.

[17] Webster's Third New International Dictionary of the English Language, unabridged. 1986. Chicago. Illinois: Merriam-Webster.

[18] Stroustrup, B. 1991. The C++ Programming Language, Second Edition. Reading, MA: Addison-Wesley, p.422.

[19] Meyer, B. 1987. Programmingas Contracting. Report TR-EI-12/CO. Goleta, CA: Interactive Software Engineering.

[20] Snyder, A. November 1986. Encapsulation and Inheritance in Object-oriented Programming Languages. SIGPLAN Notices vol. 21(11).

[21] LaLonde, W. April 1989. Designing Families of Data Types Using Exemplars. ACM Transactions on Programming Languages and Systems vol.11(2), p.214.

[22] Rumbaugh, J. April 1988. Relational Database Design Using an Object-oriented Methodology. Communications of the ACM vol.31(4), p.417.

[23] Lieberman, H. November 1986. Using Prototypical Objects to Implement Shared Behavior in Object-oriented Systems. SIGPLAN Notices vol.21(11).

[24] Rumbaugh,1991.p.312.

[25] Brachman, R. October 1983. What IS-A Is and Isn't: An Analysis of Taxonomic Links in Semantic Networks. IEEE Computer vol.16(10), p.30.

[26] Micallef, J. April/May 1988. Encapsulation, Reusability, and Extensibility in Object-oriented Programming Languages. Journal of Object-oriented Programming vol.1(1). p.15.

[27] Snyder. Encapsulation, p.39.

[28] Cardelli, L. and Wegner. P. On Understanding Types, Data Abstraction, and Polymorphism. December 1985. ACM Computing Surveys vol.17(4), p.475.

[29] As quoted in Harland, D., Szyplewski, M. and Wainwright, J. October 1985. An Alternative View of Polymorphism. SIGPLAN Notices vol.20( 10).

[30] Kaplan, S. and Johnson, R. July 21,1986. Designing and Implementing/or Reuse. Urbana. IL University of Illinois, Department of Computer Science, p.8.

[31] Deutsch, P. 1983. Efficient Implementation of the Smalltalk-80 System, in Proceedings of the 11th Annual ACM Symposium on the Principles a/Programming Languages, p.300.

[32] Ibid, p.299.

[33] Duff, С. August 1986. Designing an Efficient Language. Byte vol.11(8), p.216.

[34] Stroustrup, В. 1988. Private communication.

[35] Stroustrup, В. November 1987. Possible Directions for C++. Proceedings of the USENIX C++ Workshop. Santa Fe, New Mexico, p.8.

[36] Keene, S. 1989. Object-Oriented Programming in Common Lisp. Reading, MA: Addison-Wesley, p.44.

[37] Winston. P. and Horn. B. 1989. Lisp. Third Edition. Reading, MA: Addison-Wesley, p.510.

[38] Micallef, J. April/May 1988. Encapsulation. Reusability, and Extensibility in Object-Oriented Programming Languages. Journal of Object-Oriented Programming vol.1 (1), p.25.

[39] Snyder. Encapsulation, p.41.

[40] Vlissides, J. and Linton, M. 1988. Applying Object-oriented Design to Structured Graphics. Proceedings of USENIX C++ Conference. Berkeley, CA: USENIX Association, p.93.

[41] Meyer, В. 1988. Object-oriented Software Construction. New York. NY: Prentice-Hall, p.274.

[42] Keene. Object-oriented Programming, p.118.

[43] Snyder. Encapsulation, p.43.

[44] Hendler, J. October 1986. Enhancement for Multiple Inheritance. SIGPLAN Notice vol.21(10), p.100.

[45] Stroustrup, 1987. p.3.

[46] Stroustrup, В. 1988. Parameterized Types for C++. Proceedings of USENIX C++ Conference. Berkley, CA: USENIX Association, p.1.

[47] Meyer, В. November 1986. Gcnericity versus Inheritance. SIGPLAN Notices vol.21(11), p.402.

[48] Stroustrup. 1988, p.4.

[49] Robson, D. August 1981. Object-oriented Software Systems. Byte vol.6(8), p.86.

[50] Goldberg, A. and Robson, D. 1983. Smalltalk-80: The Language and Its Implementation. Reading, MA: Addison-Wesley, p.287.

[51] Ingalls, D. August 1981. Design Principles Behind Smalltalk. Byte vol.6(8), p.286.

[52] Stevens, W., Myers. G. and Constantine, L. 1979. Structured Design, in Classics in Software Engineering. New York, NY: Yourdon Press, p.209.

[53] Page-Jones, M. 1988. The Practical Guide to Structured Systems Design. Englewood Cliffs, New Jersey: Yourdon Press, p.59.

[54] Meyer. 1987, p.4.

[55] Halbert, D. and O'Brien, P. September 1988. Using Types and Inheritance in Object-oriented Programming. IEEE Software vol.4(5), p.74.

[56] Sakkinen, M. December 1988. Comments on "the Law of Demeter" and C++. SIGPLAN Notices vol.23(12), p.36.

[57] Lea, D. August 12,1988. User's Guide to GNU C++ Library. Cambridge. MA: Free Software Foudation, p.12.

[58] Ibid.

[59] Meyer. 1988, р. 332.

[60] Wirth, N. 1986. Algorithms and Data Structures. Englewood Cliffs. NJ: Prentice-Hall, p.37.

[61] Keene. Object-oriented Programming, p.68.

[62] Parnas, D., Clements, P. and Weiss, D. 1989. Enhancing Reusability with Information Hiding. Software Reusability. New York, NY: ACM Press, p.143.

Глава 4. Классификация

[1] As quoted in Swaine, M. June 1988. Programming Paradigms. Dr. Dobb's Journal of Software Tools. No.140, p.110.

[2] Michalski, R. and Stepp, R. 1983. Learning from Observation: Conceptual Clustering, in Machine Learning: An Artificial Intelligence Approach. Palo Alto, CA: Tioga. p.332.

[3] Alexander, С. 1979. The Timeless Way of Building. New York, NY: Oxford University Press, p.203.

[4] Darwin, С. 1984. The Origin of Species. vol.49 of Great Books of the Western World. Chicago, IL: Encyclopedia Britannica, p.207.

[5] The New Encyclopedia Britannica. 1985. Chicago, IL Encyclopedia Britannica. vol.3, p.356.

[6] Gould, S. June 1992. We Are All Monkey's Uncles. Natural History.

[7] May, R. September 16,1988. How Many Species Are There on Earth? Science vol.241, p.1441.

[8] As quoted in Lewin, R. November 4,1988. Family Relationships Are a Biological Conundrum. Science vol.242, p.671.

[9] The New Encyclopedia Britannica vol.3, p.156.

[10] Descartes, R. 1984. Rules for the Direction of the Mind. vol.31 of Great Books of the Western World. Chicago, IL: Encyclopedia Britannica, p.32.

[11] Shaw, M. May 1989. Larger Scale Systems Require Higher-Level Abstractions. SIGSOFT Engineering Notes vol.14(3), p.143.

[12] Goldstein, Т. May 1989. The Object-oriented Programmer. The C++ Report vol.1(5).

[13] Coombs, С., Raiffa, H. and Thrall, R. 1954. Some Views on Mathematical Models and Measurement Theory. Psychological Review vol.61(2), p.132.

[14] Flood, R. and Carson, E. 1988. Dealing with Complexity. New York, NY: Plenum Press, p.8.

[15] Birtwistle, G., Dahl, O-J., Myhrhaug, В. and Nygard, K. 1979. Simula begin. Lund. Sweden: Studentlitteratur, p.23.

[16] Heinlein, R. 1966. The Moon Is a Harsh Mistress. New York, NY: The Berkeley Publishing Group, p.11.

[17] Sowa, J. 1984. Conceptual Structures: Information Processing in Mind and Machine. Reading, MA: Addison-Wesley, p.16.

[18] Lakoff, G. 1987. Women. Fire, and Dangerous Things: What Categories Reveal About the Mind. Chicago, IL: The University of Chicago Press, p.161.

[19] Stepp, R. and Michalski, R. February 1986. Conceptual Clustering of Structured Objects: A Goal-Oriented Approach. Artificial Intelligence vol.28( 1), p.53.

[20] Wegner, P. 1987. The Object-Oriented Classification Paradigm, in Research Directions in Object-Oriented Programming. Cambridge, MA: The MIT Press, p.480.

[21] Aquinas, Т. 1984. Summa Theologica. vol.19 of Great Books of the Western World. Chicago, IL: Encyclopedia Britannica, p.71.

[22] Maier, H. 1969. Three Theories of Child Development: The Contributions of Erik H. Erickson, Jean Piaget and Robert R. Sears, and Their Applications. New York, NY: Harper and Row, p.111.

[23] Lakoff. Women. Fire, p.32.

[24] Minsky, M. 1986. The Society of Mind. New York, NY: Simon and Schuster, p.199.

[25] The Great Ideas: A Syntopicon of Great Books of the Western World. 1984. vol.1 of Great Books of the Western World. Chicago, IL: Encyclopedia Britannica, p.293.

[26] Kosko, В. 1992. Neural Networks and Fuzzy Systems. Englewood Cliffs, NJ: Prentice-Hall, p.xx.

[27] Stepp, p.44.

[28] Lakoff. Women, Fire, and Dangerous Things, p. 7.

[29] Ibid, p.16.

[30] Lakoff, G. and Johnson, M. 1980. Metaphors We Live By. Chicago, IL: The University of Chicago Press, p.122.

[31] Meyer, В. 1988. Private communication.

[32] Shlaer, S. and Mellor, S. 1988. Object-oriented Systems Analysis: Modeling the World in Data. Englewood Cliffs, NJ: Yourdon Press, p.15.

[33] Ross, R. 1987. Entity Modeling: Techniques and Application. Boston, MA: Database Research Group, p.9.

[34] Coad, P. and Yourdon, E. 1990. Object-oriented Analysis. Englewood Cliffs, NJ: Prentice-Hall, p.62.

[35] Shlaer, S. and Mellor, S. 1992. Object Lifecycles: Modeling the World in States. Englewood Cliffs, New Jersey: Yourdon Press.

[36] Wirfs-Brock, R., Wilkerson, B. and Wiener, L. 1990. Designing Object-oriented Software. Englewood Cliffs, New Jersey: Prentice-Hall, p.61.

[37] Rubin, K. and Goldberg, A. September 1992. Object Behavior Analysis. Communications of the ACM, vol.35(9), p.48.

[38] Dreger, В. 1989. Function Point Analysis. Englewood Cliffs, NJ: Prentice-Hall, p.4.

[39] Arango, G. May 1989. Domain Analysis: From Art Form to Engineering Discipline. SIGSOFT Engineering Notes vol.14(3), p. 153.

[40] Moore, J. and Bailin, S. 1988. Position Paper on Domain Analysis. Laurel, MD: СТА, р. 2.

[41] Jacobson, I., Christerson, M.,Jonsson, P. and Overgaard, G. 1992. Object-oriented Software Engineering. Workingham, England: Addison-Wesley, p.VIII.

[42] Zahniseer, R. July/August 1990. Building Software In Groups. American Programmer, vol.3(7-8).

[43] Goldstein, N. and Alger, J. 1992. Developing Object-oriented Software for the Macintosh. Reading, Massachusetts: Addison-Wesley, p.161.

[44] Beck, K. and Cunningham, W. October 1989. A Laboratory for Teaching Object-oriented Thinking. SIGPLAN Notices vol. 24(10).

[45] Abbott, R. November 1983. Program Design by Informal English Descriptions. Communications of the ACM vol.26(11).

[46] Saeki, M., Horai, H. and Enomoto, H. May 1989. Software Development Process from Natural Language Specification. Proceedings of the 11th International Conference on Software Engineering. New York, NY: Computer Society Press of the IEEE.

[47] McMenamin, S. and Palmer, J. 1984. Essential Systems Analysis. New York, NY: Yourdon Press, p.267.

[48] Ward, P. and Mellor, S. 1985. Structured Development for Real-time Systems. Englewood Cliffs, NJ: Yourdon Press.

[49] Seidewitz, E. and Stark, M. August 1986. General Object-oriented Software Development, Report SEL-86-002. Greenbelt, MD: NASA Goddard Space Flight Center, p.5-2.

[50] Seidewitz, E. 1990. Private Communication.

[51] Goldberg, A. 1984. Smalltalk-80: The Interactive Programming Environment. Reading, MA: Addison-Wesley, p.77.

[52] Thomas, D. May/June 1989. In Search of an Object-oriented Development Process. Journal of Object-Oriented Programming vol.2(1), p.61.

[53] Stroustrup, В. 1986. The C++ Programming Language. Reading, MA: Addison-Wesley, p.7.

[54] Halbert, D. and O'Brien, P. September 1988. Using Types and Inheritance in Object-oriented Programming. IEEE Software vol.4(5), p.75.

[55] Stefik, M. and Bobrow, D. Winter 1986. Object-oriented Programming: Themes and Variations, Al Magazine vol.6(4), p.60.

[56] Stroustrup, В. 1991. The C++ Programming Language, Second Edition. Reading, Massachusetts: Addison-Wesley, p.377.

[57] Stefik and Bobrow. Object-oriented Programming, p.58.

[58] Lins, С. 1989. A First Look at Literate Programming. Structured Programming.

[59] Gabriel, R. 1990. Private communication.

[60] Coplien, J. 1992. Advanced C++ Programming Styles and Idioms. Reading, Massachusetts: Addison-Wesley.

[61] Adams, S.July 1986. MetaMethods: The MVC Paradigm, in HOOPLA: Hooray for Object-oriented Programming Languages. Everette, WA: Object-oriented Programming for Smalltalk Applications Developers Association vol.1(4), p.6.

[62] Russo, V., Johnston, G. and Campbell, R. September 1988. Process Management and Exception Handling in Multiprocessor Operating Systems Using Object-oriented Design Techniques. SIGPLAN Notices vol.23(11), p.249.

[63] Englemore, R. and Morgan, Т. 1988. Blackboard Systems. Wokingham, England: Addison-Wesley, p.v.

[64] Coad, P. September 1992. Object-oriented Patterns. Communications of the ACM, vol.35(9).

Часть II. Метод

Petroski, H. 1985. То Engineer is Human. New York, NY: St Martin's Press, p.73.

Глава 5. Обозначения

[1] Shear, D. December 8, 1988. CASE Shows Promise, but Confusion Still Exists. EDN vol.33(25), p.168.

[2] Whitehead, A. 1958. An Introduction to Mathematics. New York, NY: Oxford University Press.

[3] Defense Science Board. Report of the Defense Science Board Task Force on Military Software. September 1987. Washington, D.C.: Office of the Undersecretary of Defense for Acquisition, p.8.

[4] Kleyn, M. and Gingrich, P. September 1988. GraphTrace - Understanding Object-Oriented Systems Using Concurrently Animated Views. SIGPLAN Notices vol.23(11), p.192.

[5] Weinberg, G. 1988. Rethinking Systems Analysis and Design. New York, NY: Dorset House, p.157.

[6] Intel. 1981. iAPX432 Object Primer. Santa Clara. CA.

[7] Rumbaugh, J., Blaha, M., Premerlani, W., Eddy, F. and Lorensen, W. 1991. Object-oriented Modeling and Design. Englewood Cliffs, New Jersey: Prentice-Hall.

[8] Stroustrup, B. 1991. The C++ Programming Language. Second Edition. Reading, Massachusetts: Addison-Wesley Publishing Company.

[9] Kiczales, G., Rivieres, J. and Bobrow, D. 1991. The Art of the Metaobject Protocol. Cambridge, Massachusetts: The MIT Press.

[10] Gamma, E., Helm, R., Johnson, R., Vlissides, J. 1993. A Catalog of Object-oriented Design Patterns. Cupertino, California: Taligent.

[11] Harel, D. 1987. Statecharts: A Visual Formalism for Complex Systems. Science of Computer Programming vol.8.

[12] Rumbaugh, Object-oriented Modeling and Design.

[13] Bear, S., Alien, P., Coleman, D. and Hayes, F. Graphical Specification of Object-oriented Systems. Object-oriented Programming Systems, Languages, and Applications. Ottawa, Canada: OOPSLA'90.

[14] Rumbaugh, Object-oriented Modeling and Design.

[15] Jacobson, I., Christerson, M., Johnson, P. and Overgaard, G. 1992. Object-oriented Software Engineering. Workingham, England: Addison-Wesley Publishing Company.

Глава 6. Процесс

[1] Brooks, F. 1975. The Mythical Man-Month. Reading, MA: Addison-Wesley, p.42.

[2] Stroustrup, В. 1991. The C++ Programming Language, Second Edition. Reading, MA: Addison-Wesley.

[3] Maccoby, M. December 1991. The Innovative Mind at Work. IEEE Spectrum, vol.28(12).

[4] Lammers, S. 1986. Programmers at Work. Redmond, WA: Microsoft Press.

[5] Druke, M. 1989. Private Communication.

[6] Jones, C. September 1984. Reusability in Programming: A Survey of the State of the Art. IEEE transactions on Software Engineering, vol.SE-10(5).

[7] Humphrey, W. 1989. Managing the Software Process. Reading, MA: Addison-Wesley, p.5.

[8] Curtis, В. May 17, 1989. ...But You Have to Understand, This Isn't the Way We Develop Software at Our Company. MCC Technical Report Number STP-203-89. Austin, TX: Microelectronics and Computer Technology Corporation, p.x.

[9] Parnas, D. and Clements, P. 1986. A Rational Design Process: How and Why to Fake It. IEEE Transactions on Software Engineering vol.SE-12(2).

[10] Boehm, B. August 1986. A Spiral Model of Software Development and Enhancement. Software Engineering Notes vol.11(4), p.22.

[11] Stroustrup, B. 1991. The C++ Programming Language, Second Edition. Reading, MA: Addison-Wesley, p.362.

[12] Brownsword, L 1989. Private communication.

[13] Stroustrup, p.373.

[14] Vonk, R. 1990. Prototyping. Englewood Cliffs, NJ: Prentice-Hall, p.31.

[15] Gilb, Т. 1988. Principles of Software Engineering Management. Reading, MA: Addison-Wesley, p.92.

[16] Mellor, S., Hecht, A., Tryon, D. and Hywari, W. September 1988. Object-oriented Analysis: Theory and Practice, Course Notes, in Object-oriented Programming Systems, Languages, and Applications. San Diego, CA: OOPSLA'88, p.1.3.

[17] Symons, С. 1988. Function Point Analysis: Difficulties and Improvements. IEEE Transactions on Software Engineering vol.14(1).

[18] Dreger, B. 1989. Function Point Analysis. Englewood Cliffs, NJ: Prentice-Hall, p.5.

[19] deChampeaux, D., Balzer, В., Bulman, D., Culver-Lozo, K., Jacobson, I., Mellor, S. The Object-oriented Software Development Process. Vancouver, Canada: OOPSLA'92.

[20] Davis, A. 1990. Software Requirements: Analysis and Specification. Englewood Cliffs, NJ: Prentice-Hall.

[21] Rubin, K. 1993. Private communication.

[22] Jacobson, I., Christerson, M., Jonsson, P., and Overgaard, G. 1992. Object-oriented Software Engineering. Workingham, England: Addison-Wesley Publishing Company.

[23] Rubin, K. and Goldberg, A. September 1992. Object Behavior Analysis. Communications of the ACM vol.35(9).

[24] Andert, G. 1992. Private communication.

[25] Page-Jones, M. 1988. The Practical Guide to Structured Systems Design. Englewood Cliffs, NJ: Yourdon Press, pp.261-265.

[26] Stefik, M. and Bobrow, D. Winter 1986. Object-oriented Programming: Themes and Variations, AI Magazine vol.6(4), p.41.

[27] Меуеr, В. 1988. Object-oriented Software Construction. New York, NY: Prentice-Hall, p.340.

[28] Andert, G. 1993. Private communication.

[29] Walsh, J. Preliminary Defect Data from the Iterative Development of a Large C++ Program. Vancouver. Canada: OOPSLA'92.

[30] Chmura, L., Norcio, A. and Wicinski, T. July 1990. Evaluating Software Design Processes by Analyzing Change Date Over Time. IEEE Transactions on Software Engineering vol.16(7).

[31] As quoted in Sommerville, I. 1989. Software Engineering. Third Edition. Wokingham, England: Addison-Wesley, p.546.

Глава 7. Практические вопросы

[1] Dijkstra, E. May 1986. The Structure of the "THE" Multiprogramming System. Communications of the ACM vol.11(5), p.341.

[2] Kishida, K., Teramoto, M., Torri, K. and Urano, Y. September 1988. Quality Assurance Technology in Japan. IEEE Software vol.4(5), p.13.

[3] Hawryszkiewycz, 1.1984. Database Analysis and Design. Chicago, IL: Science Reserch Associates, p.115.

[4] van Genuchten, M. June 1991. Why is Software Late? An Empirical Study of Reasons for Delay in Software Development. IEEE Transactions on Software Engineering vol.17(6), p.589.

[5] Gilb, Т. 1988. Principles of Software Engineering Management. Reading, Massachusetts: Addison-Wesley Publishing Company, p.73.

[6] As quoted in Zelkowitz, M. June 1978. Perspectives on Software Engineering. ACM Computing Surveys vol.10(2), p.204.

[7] Showalter, J. 1989. Private communication.

[8] Davis, A., Bersoff, E. and Comer, E. October 1988. A Strategy for Comparing Alternative Software Develpopment Lite Cycle Models. IEEE Transactions on Software Engineering vol.14(10), p.1456.

[9] Goldberg, A. 1993. Private communication.

[10] Schulmer, G. and McManus, J. 1992. Handbook of Software Quality Assurance, second Edition. New York, NY: Van Nostrand Reinhold, p.5.

[11] Schulmeyer, p.7.

[12] Schulmeyer, p.184.

[13] Schulmeyer, p.169.

[14] Walsh, J. Preliminary Defect Data from the Iterative Development of a Large C++ Program. Vancouver, Canada: OOPSLA'92.

[15] Chidamber, S. and Kemerer, C. 1993. A Metrics Suite for Object-Oriented Design. Cambridg, Massachusetts: MIT Sloan School of Management.

[16] Lang, K. and Peralmutter, B. November 1986. Oaklisp: an Object-oriented Scheme with First-Class Types. SIGPLAN Notices vol.21(11), p.34.

[17] Meyrowitz, N. November 1986. Intermedia: The Architecture and Construction of an Object-oriented Hypermedia System and Applications Framework. SIGPLAN Notices, vol.21(11), p.200.

[18] Kempf, R. October 1987. Teaching Object-oriented Programming With the KEE System. SIGPLAN Notices, vol.22( 12), p.11.

[19] Schmucker, K. 1986. Object-oriented Programming for the Macintosh. Hasbrouk Heights, NJ: Hayden, p.11.

[20] Taylor, D. 1992. Object-oriented Information Systems. New York, New York John Wiley and Sons.

[21] Pinson, L. and Wiener, R. 1990. Applications of Object-oriented Programming. Reading, Massachusetts: Addison-Wesley Publishing Company.

[22] Simonian, R. and Crone, M. November/December 1988. InnovAda: True Object-Oriented Programming in Ada. Journal of Object-Oriented Programming vol.1(4), p.19.

[23] Pascoe, G. August 1986. Elements of Object-oriented Programming. Byte vol.11(8), p.144.

[24] Russo, V. and Kaplan, S. 1988. А C++ Interpreter for Scheme. Proceedings of USENIX C++ Conference. Berkeley, CA: USENIX Association, p.106.

Часть III. Примеры приложений

Minsky, M. April 1970. Form and Content in Computer Science. Journal of the Association for Computing Machinery vol.17(2), p.197.

Глава 9. Среда разработки: библиотека базовых классов

[1] C++ Booch Components Class Catalog. 1992. Santa Clara, CA: Rational.

[2] Knuth, D. 1973. The Art of Computer Programming, Vol.1-3. Reading, MA: Addison-Wesley.

[3] Aho, A., Hopcroft, J. and Ullman, J. 1974. The Design and Analysis of Computer Programs. Reading, MA: Addison-Wesley.

[4] Kernighan, B. and Plauger, P. 1981. Software Tools in Pascal. Reading, MA: Addison-Wesley.

[5] Sedgewick, R. 1983. Algorithms. Reading, MA: Addison-Wesley.

[6] Stubbs, D. and Webre, N. 1985. Data Structures with Abstract Data Types and Pascal. CA: Brooks/Cole.

[7] Tenenbaum, A. and Augenstein, M. 1981. Data Structures Using Pascal. Englewood Cliffs, NJ: Prentice-Hall.

[8] Wirth, N. 1986. Algorithms and Data Structures, Second Edition. Englewood Cliffs, NJ: Prentice-Hall.

[9] Wirfs-Brock, R. October 1991. Object-Oriented Frameworks. American Programmer vol.4(10), p.27.

[10] Stroustrup, Bjarne. 1991. The C++ Programming Language, Second Edition. Reading, Massachusetts: Addison-Wesley, p.429.

[11] Coggins, J. September 1990. Design and Management of C++ Libraries. Chapel Hill, North Carolina, p.1.

[12] Ellis, M. and Stroustrup, B. 1990. The Annotated C++ Reference Manual. Reading, Massachusetts: Addison-Wesley, p.155.

[13] Ellis and Stroustrup, p.297.

[14] Ellis and Stroustrup, p.90.

[15] Wirfs-Brock, 1993. Private communication.

[16] Jacobson, I., Christerson, M.,Jonsson, P. and Overgaard, G. 1992. Object-oriented Software Engineering. Workingham, England: Addison-Wesley Publishing Company, p.184.

Глава 10. Архитектура клиент-сервер: складской учет

[1] Mirnno, P. April 1993. Client-Server Computing. American Programmer, Arlington MA: Cutter Information Corporation, p.19.

[2] Mimno, p.21.

[3] Berson, A. 1992. Client/Server Architecture. New York, NY: Me Graw-Hill, p.34.

[4] Berson, p.37.

[5] Berson, p.12.

[6] Berson, p.13.

[7] Date, С. 1981. An Introduction to Database Systems. Vol.1. Reading, Massachusetts: Addison-Wesley, p.4.

[8] Date. An Introduction, p.10.

[9] Hawryszkiewycz, 1.1984. Database Analysis and Design. Chicago, IL: Science Research Associates, p.425.

[10] Wiorkowski, G. and Kull, D. 1988. DB2 Design and Development Guide. Reading, MA: Addison-Wesley, p.29.

[11] Date. An Introduction, p.63.

[12] Wiorkowski and Kull. DB2 Design, p.2.

[13] Date. An Introduction, p.238.

[14] Wiorkowski and Kull. DB2 Design, p.15.

[15] Date, С. 1986. Relational Database: Selected Writings. Reading, MA: Addison-Wesley, p.461.

[16] Rumbaugh, J. July/August 1992. Onward to OOPSLA. Journal of Object-Oriented Programming, vol.5(4).

[17] Rumbaugh, J., Blaha, M., Premerlani, W., Eddy, F. and Lorensen, W. 1991. Object-oriented Modeling and Design. Englewood Cliffs, New Jersey: Prentice-Hall, p.386.

[18] Ibid.

[19] Date. An Introduction, p.237.

[20] Berson, p.39.

[21] Berson, p.441.

[22] Date, С. 1987. The Guide to the SQL Standard. Reading, MA: Addison-Wesley, p.32.

[23] Berson, p.244.

[24] Berson, p.61.

[25] Ibid.

Глава 11. Искусственный интеллект: криптоанализ

[1] Erman, L., Lark, J. and Hayes-Roth, F. December 1998. ABE: An Environment for Engineering Intelligent Systems. IEEE Transactions on Software Engineering vol.14(12), p.1758.

[2] Shaw, M. 1991. Heterogeneous Design Idioms for Software Architecture. Pittsburgh, Pennsylvania: Carnegie Mellon University.

[3] Meyer, C. and Matyas. 1982. Cryptography. New York, NY: John Wiley and Sons, p.1.

[4] Nii, P. Summer 1986. Blackboard Systems: The Blackboard Model of Problem Solving and the Evolution of Blackboard Architectures. AI Magazine vol.7(2), p.46.

[5] Englemore, R. and Morgan, T. 1988. Blackboard Systems. Wokingham, England: Addison-Wesley, p.16.

[6] Ibid, p.19.

[7] Ibid, p.6.

[8] Ibid, p.12.

[9] Nii. Blackboard Systems, p.43.

[10] Englemore and Morgan. Blackboard Systems, p. 11.

Глава 12. Управление: контроль за движением поездов

[1] Murphy, E. December 1988. All Aboard for Solid State. IEEE Spectrum vol.25(13), p.42.

[2] Rockwell Advanced Railroad Electronic Systems. 1989. Cedar Rapids, IA: Rockwell International.

[3] Tanenbaum, A. 1981. Computer Networks. Englewood Cliffs, NJ: Prentice-Hall.

Послесловие

Lefrancois, G. 1977. Of Children: An Introduction to Child Development, Second Edition. Belmont, CA:Wadsworth, p.371.

Приложение: Объектно-ориентированные языки программирования

[1] Wulf, W. January 1980. Trends in the Design and Implementation of Languages. IEEE Computer vol.13(1), p.15.

[2] Birtwistle, G., Dahl, O-J., Myhrhaug, В. and Nygard, K. 1979. Simula begin. Lund, Sweden: Studentlitteratur.

[3] Schmucker, K. 1986. Object-oriented Programming for the Macintosh. Hasbrouk Heights, NJ: Hayden, p.346.

[4] LaLonde, W. and Pugh, J. 1990. Inside Smalltalk, Volumes 1 and 2. Englewood Cliffs, New Jersey: Prentice-Hall.

[5] Ingalls, D. The Smalltalk-76 Programming System Design and Implementation. Proceedings of the Fifth Annual ACM Symposium on Principles of Programming Languages, ACM, p.9.

[6] Borning, A. and Ingalls, D. 1982. Multiple Inheritance in Smalltalk-80. Proceedings of the National Conference on Artificial Intelligence. Meno Park, CA: AAAI.

[7] Goldberg, A. and Robson, D. 1989. Smalltalk-80: The Language. Reading, MA: Addison-Wesley.

[8] Goldberg, A. 1984. Smalltalk-80: The Interactive Programming Environment. Reading, MA: Addison-Wesley.

[9] Krasner, G. 1983. Smalltalk-80: Bits of History. Words of Advice. Reading, MA: Addison-Wesley.

[10] LaLonde, 1990.

[11] Schmucker, K. August 1986. Object-Oriented Languages for the Macintosh. Byte vol.11 (8), р. 179.

[12] Macintosh Programmer's Workshop Pascal 3.0 Reference. 1989. Cupertino, CA: Apple Computer.

[13] Stroustrup, B. 1986. The C++ Programming Language, Second Edition. Reading, MA: Addison-Wesley, p.4.

[14] Gorlen, K. 1989. An Introduction to C++, in UNIX System VAT&T C++ Language System, Release 2.0 Selected Readings. Murray Hill, NJ: AT&T Bell Laboratories, p.2-1.

[15] Ellis, M. and Stroustrup, B. 1990. The Annotated C++ Reference Manual. Reading, Massachusetts: Addison-Wesley Publishing Company.

[16] Stroustrup, B. 1991. The C++ Programming Language, Second Edition. Reading, MA: Addison-Wesley.

[17] Keene, S. 1989. Object-oriented Programming in Common Lisp. Reading, MA: Addison-Wesley, p.215.

[18] Bobrow, D. 1990. Private communication.

[19] Bobrow, D., DeMichiel, L., Gabriel, R., Keene, S., Kiczales, G. and Moon, D. September 1988. Common Lisp Object System Specification X3J13 Document 88-002R. SIGPLAN Notices vol.23.

[20] Reference Manual for the Ada Programming Language. February 1983. Washington, D.C.: Department of Defence, Ada Joint Program Office, p.1-3.

[21] Ibid.

[22] Meyer, B. 1988. Object-oriented Software Construction. New York, NY: Prentice-Hall.

[23] Saunders, J. March/April 1989. A Survey of Object-oriented Programming Languages. Journal of Object-oriented Programming vol.1(6).

[24] Ibid, p.6.

Библиография

Библиография разделена на одиннадцать разделов, пронумерованных латинскими буквами от A до K. В конце каждой главы присутствуют ссылки на пункты в библиографии, имеющие вид [<метка> <год>]. Например, Брукс (Brooks) [H 1975] обозначает книгу 1975 года указанного автора, The Mythical Man-Month, раздел H (Прикладное программирование) библиографии.

А. Классификация

Allen, Т. and Starr, T. 1982. Hierarchy: Perspectives for Ecological Complexity. Chicago, Illinois: The University of Chicago Press.

Aquinas, T. Summa Theologica. Vol.19 of Great Books of the Western World. Chicago, IL: Encyclopedia Britannica.

Aristotle. Categories. Vol.8 of Creat Books of the Western World. Chicago, IL: Encyclopedia Britannica.

Bateson, G. 1979. Mind and Nature: A Necessary Unity. New York, New York Bantam Books.

Brachman, R., McGuinness, D., Patel-Schneider, P., and Resnick, L. Living with Classic. Principles of Semantic Networks. San Mateo, California: Morgan Kaufman Publishers.

Bulman, D. January 1991. Refining Candidate Objects. Computer Language vol.8(1).

Cant, S., Jeffery, D. and Henderson-Sellers, B. October 1991. A Conceptual Model of Cognitive Complexity of Elements of the Programming Process. New South Wales, Australia University of New South Wales.

Classification Society of North America. Jоurnal of Classification New York, NY: Springer-Verlag. Coad, P. September 1992. Object-Oriented Patterns. Communications of the ACM vol.35(9) Coad, P. 1993. The Object Game. Austin, TX: Object International.

Coombs, C., Raiffa, H., and Thrall, R. 1954. Some Views on Mathematical Models and Measurement Theory. Psychological Review vol.61(2).

Courtois, P. June 1985. On Time and Space Decomposition of Complex Structures. Communications of the ACM vol.2S(6).

Cunningham, W. and Beck, K. July/August 1989. Constructing Abstractions for Object-oriented Abstractions. Journal of Object-Oriented Programming vol.2(2).

Darwin, С. The Origin of Species. Vol.49 of Great Books of the Western World. Chicago, IL: Encyclopedia Britannica.

Descartes, R. Rules for the Direction ofthe Mind. Vol.31 of Great Books of the Western World. Chicago, IL: Encyclopedia Britannica.

Flood, R., and Carson, E. 1988. Dealing with Complexity. New York, NY: Plenum Press.

Gould, S. June 1992. We Are All Monkey's Uncles. Natural History.

Johnson, R. Documenting Frameworks using Patterns. Vancouver, Canada: OOPSLA'92.

Lakoff, G. 1987. Women, Fire, and Dangerous Things: What Categories Reveal About the Mind Chicago, IL: The University of Chicago Press.

Lefrancois, G. 1977. Of Children: An Introduction to Child Development, 2nd ed. Belmont, CA: Wadsworth.

Lewin, R. 4 November 1988. Family Relationships Are a Biological Conundrum. Science vol.242. Maccoby, M. December 1991. The Innovative Mind at Work. IEEE Spectrum vol.28(12).

Maier, H. 1969. Three Theories of Child Development: The Contributions of Erik H. EricksonJean Piaget and Robert R. Sears and Their Applications. New York, NY: Harper and Row.

May, R. 16 September 1988. How Many Species Are There on Earth? Science vol.241.

Michalski, R., and Steep, R. 1983. Learning from Observation: Conceptual Clustering, in Machine Learning: An Artificial Intelligence Approach ed. R. Michalski, J. Carbonell, and T. Mitchell. Palo Alto, CA: Tioga.

Miller, G. March 1956. The Magical Number Seven, Plus or Minus Two: Some Limits on Our Capacity for Processing Information. The Psychological Review vol.63(2).

Minsky, M. 1986. The Society of Mind New York, NY: Simon and Schuster.
-- April 1970. Form and Content in Computer Science. Journal of the Association for Computing Machinery vol.17(2).

Moldovan, D., and Wu, C. December 1988. A Hierarchical Knowledge-Based System for Airplane Classification. IEEE Transactions on Software Engineering vol.14(12).

Newell, A. 1990. Unified Theories of Congnition. Cambridge, Massachusetts: Harvard University Press. Newell, A., and Simon, H. 1972. Human Problem Solving. Englewood Cliffs, New Jersey: Prentice-Hall. Papert, S. 1980. Mindstorms: Children Computers and Powerful Ideas. New York, I: Basic Books.

Plato. Statesman. Vol.7 of Great Books of the Western World. Chicago, IL: Encyclopedia Britannica.

Prieto-Diaz, R. and Arango, G. 1991. Domain Analysis and Software Systems Modeling. Las Alamitos, California: Computer Society Press of the IEEE.

Shaw, M. 1989. Larger Scale Systems Require Higher-Level Abstractions. Proceedings of the Fifth International Workshop on Software Specification and Design. IEEE Computer Society.
-- 1990. Elements of a Design Language for Software Architecture. Pittsburgh, PA: Carnegie Mellon University.
-- 1991. Heterogeneous Design Idioms for Software Architecture. Pittsburgh, Pennsylvania: Carnegie Mellon University.

Siegler, R., and Richards, D. 1982. The Development of Intelligence, in Handbook of Human Intelligence, ed. R. Sternberg. Cambridge, London: Cambridge University Press.

Simon, H. 1962. The Architecture of Complexity. Proceedings of the American Philosophical Society. vol.106.
-- 1982. The Sciences of the Artificial. Cambridge, MA: The MIT Press.

Sowa, J. 1984. Conceptual Structures: Information Processing in Mind and Machine. Reading, MA: Addison-Wesley.
-- 1991. Principles of Semantic Networks. San Mateo, California: Morgan Kaufman Publishers.

Stepp, R., and Michalski, R. 1986. Conceptual Clustering of Structured Objects: A Goal-Oriented Approach. Artificial Intelligence vol.28(1).

Stevens, S. June 1946. On the Theory of Scales of Measurement, Science vol.103(2684).

Stillings, N., Feinstein. M., Garfield, J., Rissland, E., Rosenbaum, D., Weisler, S., and Baker-Ward, L. 1987. Cognitive Science: An Introduction. Cambridge, MA: The MIT Press.

Waldrop, M. 1992. Complexity: The Emerging Science at the Edge of Order and Chaos. New York, New York: Simon and Schuster.

В. Объектно-ориентированный анализ

Arango, G. May 1989. Domain Analysis: From Art Form to Engineering Discipline. SIGSOFT Engineering Notes vol.14(3).

Bailin, S. 1988. Remarks on Object-oriented Requirements Specification. Laurel, MD: Computer Technology Associates.

Bailin, S., and Moore, J. 1987. An Object-oriented Specification Method for Ada. Laurel. MD:

Computer Technology Associates.

Barbier, F. May 1992. Object-oriented Analysis of Systems through their Dynamical Aspects. Journal ofObject-oriented Programming vol.5(2).

Borgida, A., Mylopoulos, J., and Wong, H. 1984. Generalization/Specialization as a Basis for Software Specification, in On Conceptual Modeling: Perspectives from Artificial Intelligence, Databases, and Programming Languages, ed. M. Brodie, J. Mylopoulos, and J. Schmidt. New York, NY: Springer-Verlag.

Cemosek, G., Monterio, E., and Pribyl, W. 1987. An Entity-Relationship Approach to Software Requirements Analysis for Object-Based Development. Houston, TX: McDonnell Douglas Astronautics.

Coad, P. Summer 1989. OOA: Object-oriented Analysis. American Programmer vol.2(7-8).
-- April 1990. New Advances in Object-oriented Analysis. Austin, Texas: Object International.

Coad, P., and Yourdon, E. 1991. Object-oriented Analysis, Second Edition. Englewood Cliffs, New Jersey: Yourdon Press.

Dahl, O-J. 1987. Object-Oriented Specifications, in Research Directions in Object-Oriented Programming, ed. B. Schriver and P. Wegner. Cambridge, MA: The MIT Press.

deChampeaux, D. April 1991. A Comparative Study of Object-oriented Analysis Methods. Palo Alto, California: Hewlett-Packard Laboratories.
-- April 1991. Object-oriented Analysis and Top-Down Software Development. Palo Alto, California: Hewlett-Packard Laboratories.

DeMarco, T. 1979. Structured Analysis and System Specification. Englewood Cliffs, NJ: Prentice-Hall.

Embley, D., Kurtz, В., and Woodfield, S. 1992. Object-oriented Systems Analysis: A Model-Driven Approach. Englewood Cliffs, New Jersey: Yourdon Press.

EVB Software Engineering. 1989. Object-oriented Requirements Analysis. Frederick, MD. Gane, C., and Sarson, T. 1979. Structured Systems Analysis. Englewood Cliffs, NJ: Prentice-Hall.

Hatley, D., and Pirbhai, 1. 1988. Strategies for Real-Time System Specification. New York, NY:

Dorset House.

Ho, D. and Parry, T. July 1991. The Hewlett-Packard Method of Object-oriented Analysis. Palo Alto, California: Hewlett-Packard Laboratories.

Iscoe, N. 1988. Domain Models for Program Specification and Generation. Austin, TX: University of Texas.

Iscoe, N., Browne, J., and Werth, J. 1989. Modeling Domain Knowledge: An Object-oriented Approach to Program Specification and Generation. Austin, TX: The University of Texas.

Lang, N. January 1993. ShIaer-Mellor Object-oriented Analysis Rules. Software Engineering Notes vol.18(1).

Marca, D., and McGowan, C. 1988. SADTTM: Structured Analysis and Design Technique. New York, NY: McGraw-Hill.

Martin, J. and Odell, J. 1992. Object-oriented Analysis and Design. Englewood Cliffs, New Jersey: Prentice-Hall.

McMenamin, S., and Palmer, J. 1984. Essential Systems Analysis. New York, NY: Yourdon Press.

Mellor, S., Hecht, A., Tryon, D. and Hywari, W. September 1988. Object-oriented Analysis: Theory and Practice, Course Notes, from Object-Oriented Programming-Systems Languages, and Applications. San Diego, CA: OOPSLA'88.

Moore, J., and Bailin, S. 1988. Position Paper on Domain Analysis. Laurel, MD: Computer Technology Associates.

Page-Jones, M., and Weiss, S. Summer 1989. Synthesis: An Object-oriented Analysis and Design Method. American Programmer vol.2(7-8).

Rubin, K. and Goldberg, A. September 1992. Object Behavior Analysis. Communications of the ACM vol.35(9).

Saeki, M., Horai, H. and Enomoto, H. May 1989. Software Development Process from Natural Language Specification. Proceedings of the 11th International Conference on Software Engineering. New York, NY: Computer Society Press of the IEEE.

Shemer, I. June 1987. Systems Analysis: A Systemic Analysis of a Conceptual Model. Communications of 'the ACM vol.30(6).

Shlaer, S., and Mellor, S. 1988. Object-oriented Systems Analysis: Modeling the World in Data. Englewood Cliffs, NJ: Yourdon Press.
-- July 1989. An Object-oriented Approach to Domain Analysis. Software Engineering Notes vol.14(5).
-- Summer 1989. Understanding Object-oriented Analysis. American Programmer vol.2(7-8).
-- 1992. Object Lifecycles: Modeling the World in States. Englewood Cliffs, New Jersey: Yourdon Press.

Stoecklin, S., Adams, E., and Smith, S. 1987. Object-oriented Analysis. Tallahassee. FL: East Tennessee State University.

Sully, P. Summer 1989. Structured Analysis: Scaffolding for Object-oriented Development. American Programmer vol.2(7-8).

Tsai, J., and Ridge, J. November 1988. Intelligent Support for Specifications Transformation. IEEE Software vol.5(6).

Veryard, R. 1984. Pragmatic Data Analysis. Oxford, England: Blackwell Scientific Publications.

Ward, P. March 1989. How to Integrate Object Orientation with Structured Analysis and Design. IEEE Software vol.6(2).

Weinberg, G. 1988. Rethinking Systems Analysis and Design. New York, NY Dorset House.

С. Объектно-ориентированные приложения

Abdali, K., Cherry, G., and Soiffer, N. November 1986. A Smalltalk System for Algebraic Manipulation. SIGPLAN Notices vol.21(11).

Abdel-Hamid, T. and Madnick, S. December 1989. Lessons Learned from Modeling the Dynamics of Software Development. Communications of the ACM vol.32(12).

Almes, G., and Holman, C. September 1987. Edmas: An Object-oriented, Locally Distributed Mail System. IEEE Transactions on Software Engineering vol.SE-13(9).

Anderson, D. November 1986. Experience with Flamingo: A Distributed, Object-oriented User Interface System. SIGPLAN Notices vol.21(11).

Archer, J., and Devlin, M. 1987. Rationals Experience Using Ada for Very Large Systems. Mountain View, CA: Rational.

Bagrodia, R., Chandy, M., and Misra, J. June 1987. A Message-Based Approach to Discrete-Event Simulation. IEEE Transactions on Software Engineering vol.SE-13(6).

Barry, B. October 1989. Prototyping a Real-Time Embedded System in Smalltalk. SIGPLAN Notices vol.24(10).

Barry, В., Altoft, J., Thomas D., and Wilson, M. October 1987. Using Object to Design and Build Radar ESM Systems. SIGPLAN Notices vol.22(12).

Basili, V., Caldiera, G., and Cantone, G. January 1992. A Reference Architecture for the Component Factory. A CM Transactions on Software Engineering and Methodology vol.1(1).

Batory, D. and O'Malley, S. October 1992. The Design and Implementation of Hierarchical Software Systems with Reusable Components. ACM Transactions on Software Engineering and Methodology vol.1(4).

Bezivin, J. October 1987. Some Experiments in Object-oriented Simulation. SIGPLAN Notices vol.22(12).

Bhaskar, K., and Peckol, J. November 1986. Virtual Instruments: Object-oriented Program Synthesis. SIGPLAN Notices vol.21(11).

Bihair, T. and Gopinath, P. December 1992. Object-oriented Real-Time Systems: Concepts and Examples. IEEE Computer vol.25(12).

Bjornerstedt, A., and Britts, S. September 1988. AVANCE: An Object Management System. SIGPLAN Notices vol.23(11).

Bobrow, D., and Stefik, M. February 1986. Perspectives on Artificial Intelligence Programming. Science vol.231.

Boltuck-Pasquier, J., Grossman, E., and Collaud, G. August 1988. Prototyping an Interactive Electronic Book System Using an Object-Oriented Approach. Proceedings of ECOOP'88:

European Conference on Object-oriented Programming. New York, NY: Springer-Verlag.

Bonar, J., Cunningham R., and Schultz, J. November 1986. An Object-oriented Architecture of Intelligent Tutoring Systems. SIGPLAN Notices vol.21(11).

Booch, G. 1987. Software Components with Ada: Structures, Tools, and Subsystems. Menio Park, CA: Benjamin/Cummings.

Borning, A. October 1981. The Programming Language Aspects of ThingLab, a Constraint-Oriented Simulation Laboratory. ACM Transactions on Programming Languages and Systems vol.3(4).

Bowman, W., and Flegal, B. August 1981. ToolBox: A Smalltalk Illustration System. Byte vol.6(8).

Britcher, R., and Craig, J. May 1986. Using Modern Design Practices to Upgrade Aging Software Systems. IEEE Software vol.3(3)

Britton K. and Parnas, D. December 8, 1981. A-7E Software Module Guide, Report 4702. Washington, D.C.: Naval Research Laboratory.

Brooks, R. 1987. A Hardware Retargetable Distributed Layered Architecture for Mobile Robot Control. Cambridge, Massachusetts: MIT Artificial Intelligence Laboratory.

Brooks, R.and Flynn, A. June 1989. Fast, Cheap, and Out of Control A Robot Invasion of the Solar System. Cambridge, Massachusetts: MIT Artificial Intelligence Laboratory.

Bruck, D. 1988. Modeling of Control Systems with C++ and PHIGS. Proceedings of USENIX C++ Conference. Berkeley, CA: USENIX Association.

Budd, T. January 1989. The Design of an Object-oriented Command Interpreter. Software - Practice and Experience vol.19(1).

C++ Booch Components Class Catalog. 1992. Santa Clara, CA: Rational.

Call, L., Cohrs, D., and Miller, B. October 1987. CLAM - an Open System for Graphical User Interfaces. SIGPLAN Notices vol.22(12).

Campbell, R., Islam, N., and Madany, P. 1992. The Design of an Object-oriented Operating System: A Case Study of Choices. Vancouver, Canada: OOPSLA'92.

Caplinger, M. October 1987. An Information System Based on Distributed Objects. SIGPLAN Notices vol.22(i2).

Cargill, T. November 1986. Pi: A Case Study in Object-oriented Programming. SIGPLAN Notices vol.21(11).

Carroll, M. September 1990. Building Reusable C++ Components. Murray Hills, New Jersey: AT&T Bell Laboratories.

Cmelik, R., and Genani, N. May 1988. Dimensional Analysis with C++. IEEE Software vol.5(3).

Coggins, J. September 1990. Design and Management of C++ Libraries. Chapel Hill, North Carolina: University of North Carolina.

Cointe, P., Briot, J., and Serpette, B. 1987. The Formes System: A Musical Application of Object-oriented Concurrent Programming, in Object-oriented Concurrent Programming, ed. Yonezawa and M. Tokoro. Cambridge, MA: The MIT Press.

Collins, D. 1990. What is an Object-oriented User Interface? Thornwood, New York: IBM Systems Research Education Center.

Comeau, G. March 1991. C++ In the Real World Interviews with C++ Application Developers. The C++ Report vol.3(3).

Coplien, J. September 1991. Experience with CRC Cards in AT&T. The C++ Report vol.3(8). Coutaz, J. September 1985. Abstractions for User Interface Design. IEEE Computer vol.18(9). Custer, H. 1993. Inside Windows NT. Redmond, Washington: Microsoft Press.

Dasgupta, P. November 1987. A Probe-Based Monitoring Scheme for an Object-oriented Operating System. SIGPLAN Notices vol.21(11).

Davidson, С., and Moseley, R. 1987. An Object-oriented Real-Time Knowledge-Based System. Albuquerque, NM: Applied Methods.

Davis, J. and Morgan, T. January 1993. Object-oriented Development at Brooklyn Union Gas. IEEE Software vol.10(1).

deChampeaux, D., Anderson, A., Lerman, D., Gasperina, M., Feldhousen, E., Glei, M., Fulton, F., Groh, C., Houston, D., Monroe, C., Raj, Rommel, and Shultheis, D. October 1991. Case Study of Object-oriented Software Development. Palo Alto, California Hewlett-Packard Laboratories.

Dietrich, W., Nackman, L, and Gracer, F. October 1989. Saving a Legacy with Objects. SIGPLAN Notices vol.24(10).

Dijkstra, E. May 1968. The Structure of the "THE" Multiprogramming System. Communications of the ACMvol.11(5).

Durand, G., Benkiran, A., Durel, C., Nga, H., and Tag, M. 9 March 1988. Distributed Mail Service in CSE System. Paris, France: Synergie Informatique et Development.

Englemore, R., and Morgan, T. 1988. Blackboard Systems. Wokingham, England: Addison-Wesley.

Epstein, D., and LaLonde, W. September 1988. A Smalltalk Window System Based on Constraints. SIGPLAN Notices vol.23(11).

Ewing, J. November 1986. An Object-oriented Operating System Interface. SIGPLAN Notices vol.21(11).

Fenton, J., and Beck, K. October 1989. Playground: An Object-oriented Simulation System with Agent Rules for Children of All Ages. SIGPLAN Notices vol.24(10).

Fischer, G. 1987. An Object-oriented Construction and Tool Kit for Human-Computer Communication. Boulder, CO: University of Colorado Department of Computer Science and Institute of Cognitive Science.

Foley, J., and van Dam, A. 1982. Fundamentals of Interactive Computer Graphics. Reading, MA: Addison-Wesley.

Frankowski, E. 20 March 1986. Advantages of the Object Paradigm for Prototyping. Golden Valley, MN: Honeywell.

Freburger, K. October 1987. RAPID: Prototyping Control Panel Interfaces. SIGPLAN Notices vol.22(12).

Freitas, M., Moreira, A., and Guerreiro, P. July/August 1990. Object-oriented Requirements Analysis in an Ada Project. Ada Letters vol.X(6).

Funk, D. 1986. Applying Ada to Beech Starship Avionics. Proceedings of the First International

Conference on Ada Programming Language Applications for the NASA Space Station. Houston, TX: NASA Lyndon B.Johnson Space Center.

Garrett, N. and Smith, K. November 1986 Building a Timeline Editor from Prefab Parts: The Architecture of an Object-Oriented Application. SIGPLAN Notices vol.21(11).

Goldberg, A. 1978. Smalltalk in the Classroom. Palo Alto, CA: Xerox Palo Alto Research Center.

Goldberg, A. and Rubin, K. October 1990. Taming Object-oriented Technology. Computer Language vol.7(10).

Goldstein, N. and Alger, J. 1992. Developing Object-oriented Software for the Macintosh. Reading, Massachusetts: Addison-Wesley Publishing Company.

Gorlen, K. December 1987. An Object-oriented Class Library for C++ Programs. Software - Practice and Experience vol.17(12).

Gray, L. 1987. Transferring Object-oriented Design Techniques into Use: AWIS Experience. Fairfax, VA: TRW Federal Systems Group.

Grimshaw, A., and Liu, J. October 1987. Mentat: An Object-oriented Macro Data Flow System. SIGPLAN Notices vol.22(12).

Grossman, M., and Ege, R. October 1987. Logical Composition of Object-oriented Interfaces. SIGPLAN Notices vol.22(12).

Gutfreund, S. October 1987. Manipllcons in ThinkerToy. SIGPLAN Notices vol.22(12). Gwinn, J. February 1992. Object-oriented Programs in Realtime. SIGPLAN Notices vol.27(2).

Harrison, W., Shilling, J., and Sweeney, P. October 1989. Good News, Bad News: Experience Building a Software Development Environment Using the Object-oriented Paradigm. SIGPLAN Notices vol.24(10).

Hekmatpour, A., Orailoglu, A., and Chau, P. April 1991. Hierarchical Modeling of the VLSI Design Process. IEEE Expert vol.6(2).

Hollowell, G. November 1991. Leading the U.S. Semiconductor Manufacturing Industry Toward an Object-oriented Technology Standard. Hotline on Object-oriented Technology vol.3(1).

Ingalls, D., Wallace, S., Chow, Y., Ludolph, F., and Doyle, K. September 1988. Fabrik; A Visual Programming Environment. SIGPLAN Notices vol.23(11).

Jacky, J., and Kalet, I. November 1986. An Object-oriented Approach to a Large Scientific Application. SIGPLAN Notices vol.21(11).

Jacobson, I. January 1993. Is Object Technology Software's Industrial Platform? IEEE Software vol.10(1).

Jerrell, M. October 1989. Function Minimization and Automatic Differentiation using C++. SIGPLAN Notices vol.24(10).

Johnson, R., and Foote, B. June/July 1988. Designing Reusable Classes. Journal of Object-oriented Programming vol.1(2).

Jones, M., and Rashid, R. November 1986. Mach and Matchmaker: Kernel and Language Support fo Object-oriented Distributed Systems. SIGPLAN Notices vol.21(11).

Jurgen, R. May 1991. Smart Cars and Highways Go Global. IEEE Spectrum vol.28(5).

Kamath, Y. and Smith, J. November/December 1992. Experiences in C++ and O-O Design. Journal of Object-oriented Programming vol.5(7).

Kay, A., and Goldberg, A. March 1977. Personal Dynamic Media. IEEE Computer.

Kerr, R., and Percival, D. October 1987. Use of Object-oriented Programming in a Time Series Analysis System. SIGPLAN Notices vol.22(12).

Kiyooka, G. December 1992. Object-oriented DLLs. Byte vol.17(14).

Kozaczynski, W. and Kuntzmann-Combelles, A. January 1993. What it Takes to Make O-O Work. IEEE Software vol.10(1).

Krueger, C. June 1992. Software Reuse. ACM Computing Surveys vol.24(2).

Kuhl, F. 1988. Object-oriented Design for a Workstation for Air Traffic Control. McLean, VA: The MITRE Corporation.

LaPolla, M. 1988. On the Classificaition of Object-oriented Design. The Object-oriented Design of the Airland Battle Management Menu System. Austin, TX Lockheed Software Technology Center.

Lea, D. 12 August 1988. User's Guide to GNU C++ Library. Cambridge, MA: Free Software Foundation.
-- 1988. The GNU C++ Library. Proceedings of USENIX C++ Conference. Berkeley, CA: USENIX Association.

Leathers, B. July 1990. Cognos and Eiffel A Cautionary Tale. Hotline on Object-Oriented Technology vol.1(9).

Ledbetter. L, and Cox. B. June 1985. Software-lCs. Byte vol.10(6).

Lee, K., and Rissman, M. February 1989. Object-oriented Solution Example: A Flight Simulator Electrical System. Pittsburgh, PA: Software Engineering Institute.

Lee, K., Rissman, M., D'lppolito, R., Plinta, C. and Van Scoy, R. December 1987. An OOD Paradigm for Flight Simulators, Report CMU/SE1-87-TR-43. Pittsburgh, PA: Software Engineering Institute.

Levy, P. 1987. Implementing Systems Software in Ada. Mountain Vie, CA: Rational.

Lewis, J., Henry, S., Kafura, D., and Shulman, R. July/August 1992. On the Relationship Between the Object-oriented Paradigm and Software Reuse: An Empirical Investigation.Jounia/ of Object-orientedProgramming vol.5 (4).

Linton, M., Vlissides, J. and Calder, P. February 1989. Composing User Interfaces with Interviews. IEEE Computer vol.22(2).

Liu, L, and Horowitz, E. February 1989. Object Database Support for a Software Project - Management Environment. SIGPLAN Notices vol.24(2).

Locke, D., and Goodenough, J. 1988. A Practical Application of the Ceiling Protocol in a Real-Time System, Report CMU/SEI-88-SR-3. Pittsburgh, PA: Software Engineering Institute.

Love, T. 1993. Object Lessons. New York, New York: SIGS Publications. Lu, Cary. December 1992. Objects For End Users. Byte vol.17(14).

Madany, P., Leyens, D., Russo, V., and Campbell, R. 1988. A C++ Class Hierarchy for Building UNIX-like File Systems. Proceedings of USENIX C++ Conference Berkeley, CA: USENIX Association.

Madduri, H., Raeuchle, T., and Silverman, J. 1987. Object-Oriented Programming for Fault-Tolerant Distributed Systems. Golden Valley, MN: Honeywell Computer Science Center.

Maloney, J., Borning, A., and Freeman-Benson, B. October 1989. Constraint Technology for User Interface Construction on in ThingLab II. SIGPLAN Notices vol.24(10).

McDonald, J. October 1989. Object-oriented Programming for Linear Algebra. SIGPLAN Notices vol.24(10)

Mentor's Lessons in the School of Hard Knocks. January 25, 1993. Business Week.

Meyrowitz, N. November 1986. Intermedia Architecture and Construction of an Object-oriented Hypermedia System and Applications Framework. SIGPLAN Notices vol.21(11).

Miller, M., Cunningham, H., Lee. С., and Vegdahl, S. November 1986. The Application Accelerator Illustration System. SIGPLAN Notices vol.21(11).

Mohan, L, and Kashyap, R. May 1988. An Object-Oriented Knowledge Representation for Spatial Information. IEEE Transactions on Software Engineering vol.14(5).

Morgan, Т. and Davis, J. March 1991. Large-Scale Object Systems Development. Hotline on Object-oriented Technology vol.2(5).

Mraz, R. December 1986. Performance Evaluation of Parallel Branch and Bound Search with the Intel iPSE Hypercube Computer. Wright-Patterson Air Force Base, Ohio: Air Force Institute of Technology.

Muller, H., Rose, J., Kempt, J., and Stansbury, T. October 1989. The Use of Multimethods and Method Combination in a CLOS-Based Window Interface. SIGPLAN Notices vol.24(10).

Murphy, E. December 1988. All Aboard for Solid State. IEEE Spectrum vol.25(13).

Nerson, J. September 1992. Applying Object-oriented Analysis and Design. Communications of the ACM vol.35(9).

NeXT Embraces a New Way of Programming. 25 November 1988. Science vol. 242.

Orden, E. 1987. Application Talk. HOOPLA: Hooray for Object-oriented Programming Languages vol.1(1). Everette, WA: Object-oriented Programming for Smalltalk Application Developers Association.

Orfali, R. and Harkey, D. 1992. Client/Server Programming with OS/2. New York, New York: Van Nostrand Reinhold.

Oshima, M., and Shirai, Y. July 1983. Object Recogration Using Three-Dimensional Information. IEEE Transactions on Pattern Analysis and Machine Intelligence vol.5(4).

Page, Т., Berson, S., Cheng, W., and Muntz, R. October 1989. An Object-oriented Modeling Environment. SIGPLAN Notices vol.24(10).

Pashtan, A. 1982. Object-oriented Operating Systems: An Emerging Design Methodology. Proceedings of the ACM'82 Conference. New York Association of Computing Machinery.

Piersol, K. November 1986. Object-oriented Spreadsheets: The Analytic Spreadsheet Package. SIGPLAN Notices vol.21(11).

Pinson, L. and Wiener, R. 1990. Applications of Object-oriented Programming. Reading, Massachusetts: Addison-Wesley Publishing Company.

Pittman, M. January 1993. Lessons Learned in Managing Object-oriented Development. IEEE Software vol.10(1).

Plinta, C., Lee, K., and Rissman, M. 29 March 1989. A Model Solution for C31: Message Translation and Validation. Pittsburgh, PA: Software Engineering Institute.

Pope, S. April/May 1988. Building Smalltalk-80-based Computer Music Toos. Journal of Object-oriented Programming vol.1(1).

Raghavan, R. 1990. Taming Windows 3.0 and DOS Using C+ +. Lake Oswego, Oregon: Wyatt Software. Rockwell International. 1989. Rockwell Advanced Railroad Electronic Systems. Cedar Rapids, IA. Rombach, D. March 1990. Design Measurement: Some Lessons Learned. IEEE Software vol.7(2).

Rubin, K., Jones, P., Mitchell, C., and Goldstein, T. September 1988. A Smalltalk Implementation of an Intelligent Operator's Associate. SIGPLAN Notices vol.23(11).

Rubin, R., Walker, J., and Golin, E. October 1990. Early Experience with the Visual Programmer's WorkBench. IEEE Transactions on Software Engineering vol.16(10).

Ruspini, E., and Fraley, R. 1983. ID: An Intelligent Information Dictionary System, in Entity-Relationship Approach to Software Engineering, ed. C. Davis et al. Amsterdam, The Netherlands: Elsevier Science.

Russo, V., Johnston, G., and Campbell, R. September 1988. Process Management and Exception Handling in Multiprocessor Operating Systems Using Object-oriented Design Techniques. SIGPLAN Notices vol.23(11).

Sampson, J., and Womble, B. 1988. SEND: Simulation Environment for Network Design. Dallas, TX: Southern Methodist University.

Santori, M. August 1990. An Instrument that Isn't Really. IEEE Spectrum vol.27(8).

Scaletti, C., and Johnson, R. September 1988. An Interactive Environment for Object-oriented Music Composition and Sound Synthesis. SIGPLAN Notices vol.23(11).

Schindler, J. and Joy, S. February 1992. An Introduction to Object Technology at Liberty Mutual. Liberty Mutual Information Systems Research and Development.

Schoen, E., Smith, R., and Buchanan, B. December 1988. Design of Knowledge-Based Systems with a Knowledge-Based Assistant. IEEE Transactions on Software Engineering vol.14(12).

Schulert, A., and Erf, K. 1988. Open Dialogue: Using an Extensible Retained Object Workspace to Support a UIMS. Proceedings of USENIX C++ Conference Berkeley, CA: USENIX Association.

Scott. R., Reddy, P., Edwards. R., and Campbell. D. 1988 GPIO: Extensible Objects for Eleclronic Design. Proceedings of USENIX C++ Conference Berkeley. CA: USENIX Association.

Smith, R., Barth, P., and Young, R. 1987. A Substrate for Object-oriented Interface Design. Research Directions in Object-oriented Programming. Cambridge, MA: The MIT Press.

Smith, R., Dinitz, R., and Barth, P. November 1986. Impulse-86: A Substrate for Object-oriented Interface Design. SIGPLAN Notices vol.21(11).

Sneed, H., and Gawron, W. 1983. The Use of the Entity/Relationship Model as a Schema for Organizing the Data Processing Activities at the Bavarian Motor Works, in Entity-Relationship Approach to Software Engineering, ed. C. Davis et al. Amsterdam, The Netherlands: Elsevier Science.

Snodgrass, R. 1987. An Object-oriented Command Language, in Object-oriented Computing: Implementations vol.2. ed. G. Peterson. New York, NY: Computer Society Press of the IEEE.

Software Made Simple. September 30, 1991. Business Week.

Sridhar, S. September 1988. Configuring Stand-Alone Smalltalk-80 Applications. SIGPLAN Notices vol.23(11).

Stadel, M. January 1991. Object-oriented Programming Techniques to Replace Software Components on the Fly in a Running Program. SIGPLAN Notices vol. 26 (1).

Stevens, A. 1992. C++ Database Development. New York, New York: MIS Press.

Stokes, R. 1988. Prototyping Database Applications with a Hybrid of C++ and 4GL. Proceedings of USENIX C++ Conference. Berkeley, CA: USENIX Association.

Szcur, M., and Miller, P. September 1988. Transportable Applications Environment(TAE) PLUS:

Experiences in "Object"ively Modernizing a User Interface Environment. SIGPLAN Notices vol.23(11).

Szekely, P., and Myers, B. September 1988. A User Interface Toolkit Based on Graphical Objects and Constraints. SIGPLAN Notices vol.23(11).

Tanner, J. April 1986. Fault Tree Analysis in an Object-oriented Entironment. Mountain View, CA: IntelliCorp.

Taylor, D. 1992. Object-Oriented Information Systems. New York, New York John Wiley and Sons.

Temte, M. November/December 1984. Object-oriented Design and Ballistics Software. Ada Letters vol.4(3).

Tripathi, A., and Aksit. M. November/December 1988. Communication, Scheduling and Resource Management in SINA. Journal ofObject-oriented Programming vol.1(4).

Tripathi, A., Ghonami, A., and Schmitz, T. 1987. Object Management in the NEXUS Distributed Operating System. Proceedings of the Thirty-second IEEE Computer Society International Conference. New York, NY: Computer Society Press of the IEEE.

Ursprung, P., and Zehnder, C. 1983. HIQUEL: An Interactive Query Language to Define and Use Hierarchies, in Entity-relationship Approach to Software Engineering, ed. C. Davis et al. Amsterdam, The Netherlands: Elsevier Science.

van der Meulen, P. October 1987. INSIST: Interactive Simulation in Smalltalk. SIGPLAN Notices vol.22(12).

Vernon, V. September/October 1989. The Forest for the Trees. Programmer's Journal vol.7(5). Vilot, M. Fall 1990. Using Object-oriented Design and C++. The C++ Journal vol.1(1).

Vines, D., and King, T. 1987. Experiences in Building a Prototype Object-oriented Framework in Ada. Minneapolis, MN: Honeywell.

VlissidesJ., and Linton, M. 1988. Applying Object-oriented Design to Structure Graphics. Proceedings of USENIX C++ Conference Berkeley, CA: USENIX Association.

Volz, R. Mude, Т., and Gal, D. 1987. Using Ada as a Programming Language for Robot-Based Manufacturing Cells, in Object-oriented Computing; Concepts vol.1. ed. G. Peterson. New York, NY: Computer Society Press of the IEEE.

Walther, S., and Peskin, R. October 1989. Strategies for Scientific Prototyping in Smalltalk. SIGPLAN Notices vol.24(10).

Wasserman, A. and Pircher, P. January 1991. Object-oriented Structured Design and C++. Computer Language vol.8(1).

Weinand, A., Gamma, E., and Marty, R. September 1988. ET++ - An Object-oriented Application Framework in C++. SIGPLAN Notices vol.23(11).

Welch, B. July/August 1991. Securities Objects - The Complexity. Object Magazine vol.1(2).

White, S. October 1986. Panel Problem: Software Controller for an Oil Hot Water Heating System. Proceedings of COMPSAC. New York, NY: Computer Society Press of the IEEE.

Wirfs-Brock, R. September 1988. An Integrated Color Smalltalk-80 System. SIGPLAN Notices vol.23(11).
-- October 1991. Object-oriented Frameworks. American Programmer vol. 4(10).

WOSA Extensions for Financial Services. December 1992. Banking Systems Vendor Council.

Wu, P. January 1992. An Object-oriented Specification for a Compiler. SIGPLAN Notices vol.27(1).

Yoshida, N. and Hino, K. September 1988. An Object-oriented Framework of Pattern Recognition. SIGPLAN Notices vol.23(11).

Yoshida, Т., and Tokoro, M. 31 March 1986. Distributed Queueing Network Simulation:. An Application of a Concurrent Object-oriented Language. Yokohama, Japan: Keio University.

Young, R. October 1987. An Object-oriented Framework for Interactive Data Graphics. SIGPLAN Notices vol.22(12).

D. Объектно-ориентированные архитектуры

Athas, W., and Seitz, C. August 1988. Multicomputers: Message-Passing Concurrent Computers. IEEE Computer vol.21(8).

Dahlby, S., Henry, G., Reynold., D., and Taylor, P. 1982. The IBM System/38: A High Level

Machine, in Computer Structures: Principles and Examples, ed. G. Bell and A. Newell. New York, NY: McGraw-Hill.

Dally, W. and Kajiya, J. March 1985. An Object-oriented Architecture. SIGARCH Newsletter vol.13(3).

Fabry, K. 1987. Capability-Based Addressing, in Object-oriented Computing: Implementations vol.2. ed. G. Peterson. New York, NY: Computer Society Press of the IEEE.

Flynn, M. October 1980. Directions and Issues in Architecture and Language. IEEE Computer vol.13(10).

Harland, D., and Beloff, B. December 1986. Microcoding an Object-oriented Instruction Set. Computer Architecture News vol.14(5).

Hillis, D. 1985. The Connection Machine. Cambridge, Massachusetts: The MIT Press. Iliffe, J. 1982. Advanced Computer Design. London, England: Prentice/Hall International. Intel. 1981. iAPX432 Object Primer. Santa Clara, CA.

Ishikawa, Y., and Tokoro, M. March 1984. The Design of an Object-oriented Architecture. SIGARCH Newsletter vol.12(3).

Kavi, K., and Chen, D. 1987. Architectural Support for Object-oriented Languages. Proceeding of the Thirty-second IEEE Computer Society International Conference. New York, NY: Computer Society Press of the IEEE.

Lahtinen, P. September/October 1982. A Machine Architecture for Ada. Ada Letters vol.2(2).

Lampson. В., and Pier, K. January 1981. A Processor for a High-Performance Personal Computer, in The Dorado: A High Performance Personal Computer, Report CSL-81-1. Palo Alto, CA: Xerox Palo Alto Research Center.

Langdon, G. 1982. Computer Design. San Jose, CA: Computeach Press. Levy, H. 1984. Capability-Based Computer Systems. Bedford, MA: Digital Press.

Lewis, D., Galloway, D., Francis, R., and Thomson, B. November 1986. Swamp: A Fast Processor for Smalltalk-80. SIGPLAN Notices vol.21(11).

Mashburn, H. 1982. The C.mmp/Hydra Project: An Architectural Overview, in Computer Structures: Principles and Examples, ed. G. Bell and A. Newell. New York, NY: McGraw-Hill.

Myers, G. 1982. Advances in Computer Architecture, 2nd ed. New York, NY: John Wiley and Sons.

Rattner, J. 1982. Hardware/Software Cooperation in the iAPX-432. Proceedings of the Symposium on Architectural Support for Programming Languages and Operating Systems. New York, NY: Association of Computing Machinery.

Rose, J. September 1988. Fast Dispatch Mechanisms for Stock Hardware. SIGPLANNotices vol.23(11).

Samples, D., Ungar, D., and Hilfinger, P. November 1986. SOAR: Smalltalk Without Bytecodes. SIGPLAN Notices vol.21(11).

Soltis, R., and Hoffman, R. 1987. Design Considerations for the IBM System/38, in Object-oriented Computing Implementations vol.2. ed. G. Peterson. New York, NY: Computer Society Press of the IEEE.

Thacker, C., McCreight. E., Lampson, В., Sproull, R., and Boggs, D. August 1979. Alto: A Personal Computer, Report CSL-79-11. Palo Alto, CA: Xerox Palo Alto Research Center.

Ungar, D. 1987. The Design and Evaluation of a High-Performance Smalltalk System. Cambridge, MA: The MIT Press.

LJngar, D. and Patterson, D. January 1987. What Price Smalltalk? IEEE Computer vol.20(1).

Ungar, D., Blau, R., Foley, P., Samples, D., and Patterson, D. March 1984. Architecture of SOAR:

Smalltalk on a RISC. SIGARCH Newsletter vol.12(3).

Wah, В., and Li, G. April 1986. Survey on Special Purpose Computer Architectures for AI. SIGART Newsletter, no. 96.

Wulf, C. January 1980. Trends in the Design and Implementation of Programming Languages. IEEE Computer vol.13(1).

Wulf, W., Levin, R., and Harbison. S. 1981. HYDRA/C.mmp: An Experimental Computer System. New York, NY: McGraw-Hill.

E. Объектно-ориентированные СУБД

Alford, M. 1983. Derivation of Element-Relation-Attribute Database Requirements by Decomposition of System Functions, in Entity-Relationship Approach to Software Engineering. ed. C. Davis et al. Amsterdam, The Netherlands: Elsevier Science.

Andleigh, P. and Gretzinger, M. 1992. Distributed Object-Oriented Data-Systems Design. Englewood Cliffs, New Jersey: Prentice-Hall.

Atkinson, M., Bailey, P., Chisholm, K., Cockshott, P., and Morrison, R. 1983. An Approach to Persistent Programming. The Computer Journal vol. 26(4).

Atkinson, M., and Buneman, P. June 1987. Types and Persistence in Database Programming Languages. ACM Computing Surveys vol.19(2).

Atkinson, M., and Morrison, R. October 1985. Procedures as Persistent Data Objects. ACM Transactions on Programming Languages and Systems vol. 7(4).

Atwood, Т. February 1991. Object-Oriented Databases. IEEE Spectrum vol. 28(2).

Bachman, C. 1983. The Structuring Capabilities of the Molecular Data Model, in Entity-Relationship Approach to Software Engineering, ed. C. Davis et al. Amsterdam, The Netherlands: Elsevier Science.

Batini, C., and Lenzerini, M. 1983. A Methodology for Data Schema Integration in the Entity-Relationship Model, in Entity-Relationship Approach to Software Engineering, ed. C. Davis et al. Amsterdam, The Netherlands: Elsevier Science.

Beech, D. 1987. Groundwork for an Object Database Model, in Research Directions in Object-oriented Programming. ed. B. Schriver and P. Wegner. Cambridge. MA: The MIT Press.
-- September 1988. Intensional Concepts in an Object Database Model. SIGPLAN Notices vol.23(11).

Bertino, E. 1983. Distributed Database Design Using the Entity-Relationship Model, in Entity-Relationship Approach to Software Engineering, ed. C. Davis et al. Amsterdam , The Netherlands: Elsevier Science.

Blackwell, P., Jajodia, S. and Ng, P. 1983. A View Database Management Systems as. Abstract Data Types, in Entity-Relationship Approach to Software Engineering, ed. C. Davis et al. Amsterdam, The Netherlands: Elsevier Science.

Bloom, T. October 1987. Issues in the Design of Object-oriented Database Programming Languages. SIGPLAN Notices vol.22(12).

Bobrow, D., Fogelsong.D., and Miller, M. 1987. Definition Group: Making Sources into First-class Objects, in Research Directions in Object-oriented Programming, ed. B. Schriver and P. Wegner. Cambridge, MA: The MIT Press.

Brathwait, K. 1983. An Implementation of A Databases Using the Entity-Relationship (E-R) Approach, in Entity-Relationship Approach to Software Engineering, ed. C. Davis et al. Amsterdam, The Netherlands: Elsevier Science.

Breazeal, J., Blattner, M., and Burton, H. 28 March 1986. Data Standardization Through the Use of Data Abstraction. Livermore, CA: Lawrence Livermore National Laboratory.

Brodie, M. 1984. On the Development of Data Models, in On Conceptual Modeling: Perspectives from Artificial Intelligence, Databases, and Programming Languages, ed. M. Brodie, J. Mylopoulos, and J. Schmidt. New York, NY: Springer-Verlag.

Brodie, M., and Ridjanovic, D. 1984. On the Design and Specification of Database Transactions, in On Conceptual Modeling: Perspectives from Artificial Intelligence Databases and Programming Languages, ed. M. Brodie, J. Mylopoulos, andJ. Schmidt. New York, NY: Springer-Verlag.

Butterworth, P., Otis, A. and Stein, J. October 1991. The GemStone Object Database Management System. Communications of the ACM vol.34(10).

Carlson, C., and Arora, A. 1983. UPM: A Formal Tool for Expressing Database Update Semantics, in Entity-Relationship Approach to Software Engineering, ed. C. Davis et al. Amsterdam, The Netherlands: Elsevier Science.

Casanova, M. 1983. Designing Entity-Relationship Schemes for Conventional Information Systems, in Entity-Relationship Approach to Software Engineering, ed. C. Davis et al. Amsterdam, The Netherlands: Elsevier Science.

Cattell, R. 1991. Object Data Management. Reading, Massachusetts: Addison-Wesley Publishing Company.
-- May 1983. Design and Implementation of a Relationship-Entity-Datum Data Model, Report CSL-83-4. Palo Alto, CA: Xerox Palo Alto Research Center.

Chen, P. 1983. ER - A Historical Perspective and Future Directions, in Entity-Relationship Approach to Software Engineering, ed. C. Davis al. Amsterdam, The Netherlands: Elsevier Science.
-- March 1976. The Entity-Relationship Model - Toward a Unified View of Data. ACM Transactions on Database Systems vol.1(1).

Claybrook, В., Claybrook, A., and Williams, J. January 1985. Defining Database Views as Data Abstractions. IEEE Transactions on Software Engineering vol.SE-11(1).

D'Cunha, A., and Radhakrishnan, T. 1983. Applications of E-R Concepts to Data Administration, Entity-Relationship Approach to Software Engineering, ed. C. Davis et al. Amsterdam, The Netherlands: Elsevier Science.

Date, C. 1981, 1983. An Introduction to Database Systems. Reading, MA: Addison-Wesley.
-- 1986. Relational Database-. Selected Writings. Reading, MA: Addison-Wesley.
-- 1987. The Guide to The SQL Standard. Reading, MA Addison-Wesley.

Duhl, J., and Damon, C. September 1988. A Performance Comparison of Object and Relational Databases Using the Sun Benchmark. SIGPLAN Notices vol. 23(11).

Harland, D., and Beloff, B. April 1987. OBJEKT - A Persistent Object Store with an Integrated Garbage Collector. SIGPLAN Notices vol.22(4).

Hawryszkiewycz, 1.1984. Database Analysis and Design. Chicago, IL: Science Research Associates.

Higa, K., Morrison, M., Morrison, J. and Sheng, O. June 1992. An Object-Oriented Methodology for Knowledge Bas/Database Coupling. Communications of the ACM vol.35(6).

Hull, R., and King, R. September 1987. Semantic Database Modeling: Survey, Applications, and Research Issues. ACM Computing Surveys vol.19(3).

Jajodia, S., Ng, P., and Springsteel, F. 1983. On Universal and Representative Instances for Inconsistent Databases, in Entity-Relationship Approach to Software Engineering, ed. C. Davis et al. Amsterdam, The Netherlands: Elsevier Science.

Ketabchi, M., and Berzins, V. January 1988. Mathematical Model of Composite Objects and Its Application for Organizing Engineering Databases. IEEE Transactions on Software Engineering vol.14(1).

Ketabchi M., and Wiens, R. 1987. Implementation of Persistent Multi-User Object-oriented Systems. Proceedings of the Thirty-second IEEE Computer Society International Conference. New York, NY: Computer Society Press of the IEEE.

Khoshafian, S., and Abnous, R. 1990. Object-Orientation: Concepts, Languages, Databases, User, Interfaces. New York, New York: John Wiley and Sons.

Kim, W., and Lochovsky, K. 1989. Object-oriented Concepts, Databases, and Applications. Reading, MA: Addison-Wesley.

Kim, W., Ballou, N., Chou, H., Garze, J., Woelk, D., and Banerjee, J. September 1988. Integrating an Object-oriented Programming System with a Database System. SIGPLAN Notices vol.23(11).

Kim, W., Banerjee, J., Chou, H., Garza, J., and Woelk, D. October 1987. Composite Object Support in an Object-oriented Database System. SIGPLAN Notices vol.22(12).

Kung, С. Object Subclass Hierarchy in SQL A Simple Approach. Communcations of the ACM vol.33(7).

Laenens, E., and Vermeir, D. August 1988. An Overview of OOPS+, An Object-oriented Database Programming Language. Proceedings of ECOOP'88. European Conference on Object-oriented Programming. New York, NY: Springer-Verlag.

Lamb, C., Landis, G., Orenstein, J., and Weinreb, D. October 1991. The ObjectStore Database System. Communications of the ACM vol.34(10).

Larson, J. and Dwyer, P. 1983. Defining External Schemas for an Entity-Relationship Database, in Entity-Relationship Approach to Software Engineering, ed.C. Davis et al. Amsterdam, The Netherlands: Elsevier Science.

Maier, D., and Stein, J. 1987. Development and Implementation of an Object-oriented DBMS, in Research Directions in Object-oriented Programming, ed. B. Schriver and P. Wegner. Cambridge, MA: The MIT Press.

Margrave, G., Lusk, E., and Overheek, R. 1983. Tools for the Creation of IMS Database Designs from Entity-Relationship Diagrams, in Entity-Relationship Approach to Software Engineering. ed. C. Davis et al. Amsterdam, The Netherlands: Elsevier Science.

Mark, L, and Poussopoulos, N. 1983. Integration of Data, Schema, and Meta-schema in the Context of Self-documenting Data Models, in Entity-Relationship Approach to Software Engineering, ed. C. Davis et al. Amsterdam, The Netherlands: Elsevier Science.

Markowitz, V., and Makowsky, J. August 1990. Identifying Extended Entity-Relationship Object Structures in Relational Schemas. IEEE Transactions on Software Engineering vol.16(8).

Marti, R. 1983. Integrating Database and Program Descriptions using an ER Data Dictionary, in Entity-Relationship Approach to Software Engineering, ed. C. Davis et al. Amsterdam, The Netherlands: Elsevier Science.

Merrow, Т., and Laursen, J. October 1987. A Pragmatic System for Shared Persistent Objects. SIGPLAN Notices vol.22(12).

Mitchell, J., and Wegbreit; B. 1977. Schemes: A High-Level Data Structuring Concept, in Current * Trends in Programming Methodology Data Structuring vol.14 ed. R. Yeh. Englewood Cliffs, NJ: Prentice-Hall.

Morrison, R., Atkinson, M., Brown, A., and Dearie, A. April 1988. Bindings in Persistent Programming Languages. SIGPLAN Notices vol.23(4).

Moss, E., Herlihy, M., and Zdonik S. September 1988. Object-oriented Databases. Course Notes, from Object-oriented Programming Systems Language, and Applications. San Diego, CA: OOPSLA'88.

Moss, J. August 1992. Worcing with Persistent Objects To Swizzle or Not to Swizzle. IEEE Transactions on Software Engineering vol.18(8).

Nastos, M. January 1988. Databases, Etc. HOOPLA: Hooray for Object-oriented Programming Languages vol.1(2). Everette. WA: Object-oriented Programming for Smalltalk Application Developers Association.

Navathe, S., and Cheng, A. 1983. A Methodology for Database Schema Mapping from Extended Entity Relationship Models into the Hierarchical Model, in Entity-Relationship Approach to Software Engineering, ed. C. Davis et al. Amsterdam, The Netherlands: Elsevier Science.

Ontologic. 1987. Vbase Technical Overview. Billerica, MA. Oracle. 1989. Oracle for Macintosh: Reference, Version 1.1. Belmont, CA.

Penny, J., and Stein, J. October 1987. Class Modification in the GemStone Object-oriented DBMS. SIGPLAN Notices vol.22(12).

Peterson, R. 1987. Object-oriented Database Design, in Object-oriented Computing Implementation vol.2. ed. G. Peterson. New York, NY: Computer Society Press of the IEEE.

Sakai, H. 1983. Entity-Relationship Approach to Logical Database Design, in Entity-Relationship Approach to Software Engineering, ed. C. Davis et al. Amsterdam, The Netherlands: Elsevier Science.

Skarra, A., and Zdonik, S. 1987. Type Evolution in an Object-oriented Database, in Research Directions in Object-oriented Programming, ed. B. Schriver and P. Wegner. Cambridge, MA: The MIT Press.

Skarra, A., and Zdonik, S. November 1986. The Management of Changing Types in an Object-oriented Database. SIGPLAN Notices vol.21(11).

Smith, D., and Smith, J. 1980. Conceptual Database Design, in Tutorial on Software Design

Techniques, 3rd ed. ed. P. Freeman and A. Wasserman. New York, NY: Computer Society Press of the IEEE.

Smith, J., and Smith, D. Database Abstractions: Aggregation and Generalization. ACM Transactions on Database Systems vol.2(2).

Smith, K., and Zdonik, S. October 1987. Intermedia: A Case Study of the Differences Between Relational and Object-oriented Database Systems. SIGPLAN Notices vol.22(12).

Stein, J. March 1988 Object-oriented Programming and Database Design. Dr. Dobb's Journal vol.13(3).
-- March 1988. Object-oriented Programming and Database Design. Dr. Dobb's Journal of Software Tools for the Professional Programmer, no. 137.

Teorey, Т., Yang, D., and Fry, J. June 1986. A Logical Design Methodology for Relational Databases Using the Extended Entity-Relationship Model. ACM Computing Surveys vol.18(2).

Thuraisingham, M. October 1989. Mandatory Security in Object-Oriented Database Systems. SIGPLAN Notices vol.24(10).

Veloso, P., and Furtado, A. 1983. View Constructs for the Specification and Design of External Schemas, in Entity-Relationship Approach to Software Engineering, ed. C. Davis et al. Amsterdam, The Netherlands: Elsevier Science.

Wiebe, D. November 1986. A Distributed Repository for Immutable Persistent Objects. SIGPLAN Notices vol.21(11).

Wiederhold G. December 1986. Views, Objects, and Databases. IEEE Computer vol.19(12).

Wile, D., and Allard D May 1982. Worlds: an Organizing Structure for Object-bases. SIGPLAN Notices vol.19(5).

Zdonik, S., and Maier. D. 1990. Reading in Object-oriented Database Systems. San Mateo, CA: Morgan Kaufmann.

Zhang, Z., and Mendelzon, A. 1983. A Graphical Query Language for Entity-Relationship Databases, in Entity-Relationship Approach to Software Engineering, ed. C. David et al. Amsterdam, The Netherlands: Elsevier Science.

F. Объектно-ориентированное проектирование

Abbott, R. August 1987. Knowledge Abstraction. Communications of the ACM vol.30(8).
-- November 1983. Program Design by Informal English Descriptions. Communications of the ACM vol.26(11).

Ackroyd, M. and Daum, D. 1991. Graphical Notation for Object-oriented Design and Programming. Journal of Object- Oriented Programming vol.3 (5).

Abbott, R.August 1987. Knowledge Abstraction. Communications ofthe ACM vol.30(8)

Alabios, В. September 1988. Transformation of Data Flow Analysis Models to Object-oriented Design. SIGPLAN Notices vol.23(11).

Arnold, P., Bodoff, S., Coleman, D., Gilchrist, H., and Hayes, F. June 1991. An Evaluation of Five Object-oriented Development Methods. Bristol, England: Hewlett-Packard Laboratories.

Bear, S., Alien, P., Coleman, D., and Hayes, F. Graphical Specification of Object-oriented Systems. Object-oriented Programming Systems, Languages, And Applications. Ottawa, Canada: OOPSLA'90.

Beck, K., and Cunningham, W. October 1989. A Laboratory for Teaching Object-oriented Thinking. SIGPLAN Notices vol.24(10).

Berard, E. 1986. An Object-oriented Design Handbook. Rockville, MD: EVB Software Engineering.

Berzins, V., Gray, M., and Naumann, D. May 1986. Abstraction-Based Software Development. Communications of the ACM vol.29(5).

Blaha, M. April 1988. Relational Database Design Using Object-oriented Methodology. Communications of the ACM vol.31(4).

Booch, G. September 1981. Describing Software Design in Ada. SIGPLAN Notices vol.16(9). - March/April 1982. Object-oriented Design. Ada Letters vol.1(3).
-- February, 1986 Object-oriented Development. IEEE Transactions of Software Engineering vol.12(2).
-- 1987. On the Concepts of Object-oriented Design. Denver, CO: Rational.
-- Summer 1989. What Is and What Isn't Object-oriented Design. American Programmer vol.2(7-8). Booch, G. and Vilot, M. Object-oriented Design. The C++ Report.

Booch, G.Jacobson, I., and Kerth, N. September 1988. Specification and Design Methodologies in Support of Object-oriented Programming Course Notes from Object-oriented Programming Systems, Languages, and Applications. San Diego, CA: OOPSLA'88.

Bowles, A. November/December 1991. Evolution Vs Revolution: Should Structured Methods Be Objectified? Object Magazine vol.1(4).

Boyd, S. July/August 1987. Object-oriented Design and PAMELATM. Ada Letters vol.7(4)

Bril, R., deBunje, Т., and Ouvry, A. October 1991. Development of SCORE: Towards the Industrialization of an Object-oriented Method using the Formal Design Language COLD-1 as Notation. Eindhoven, The Netherlands: Philips Research Laboratories.

Brookman, D. November/December 1991. SA/SD versus OOD. Ada Letters vol. XI(9).

Bruno, G., and Balsamo, A. November 1986 Petri Net-Based Object-oriented Modelling of Distributed of Systems. SIGPLAN Notices vol.21(11).

Buhr, R. 1984. System Design with Ada. Englewood Cliffs, NJ: Prentice-Hall.
-- 22 August 1988. Machine Charts for Visual Prototyping in System Design. SCE Report 88-2. Ottawa, Canada; Carleton University.
-- 14 September 1988. Visual Prototyping in System Design. SCE Report 88-14. Ottawa, Canada; Carleton University.
-- 1989. System Design with Machine Charts: A CAD Approach with Ada Examples. Englewood Cliffs, NJ: Prentice-Hall.

Buhr, R., Karam, G., Hayes, C., and Woodside, M. March 1989. Software CAD: A Revolutionary Approach. IEEE Transactions on Software Engineering vol.15(3).

Bulman, D. August 1989. An Object-Based Development Model. Computer Language vol.6(8).

Cherry, G. 1987. PAMELA 2: Ada-Based Object-oriented Design Method. Reston, VA: Thought* *Tools.
-- 1990. Software Construction by Object-oriented Pictures. Canandaigua, NY: Thought* *Tools.

Clark, R. June 1987. Designing Concurrent Objects. Ada Letters vol.7 (6).

Coad, P. September 1991. OOD Criteria. Journal of Object-oriented Programming vol.(5).

Coleman, D., Hayes, F., and Bear, S. December 1990. Introducing Objectcharts or How to Use Statecharts in Object-oriented Design. Bristol, England: Hewlett-Packard Laboratories.

Comer, E. July 1989. Ada Box Structure Methodology Handbook. Melbourne, FL: Software Productivity Solutions.

Constantine, L. Summer 1989. Object-oriented and Structured Methods: Towards Integration. American Programmer vol.2(7-8).

CRI, CISI Ingenierie, and Matra. 20 June 1987. HOOD: Hierarchical Object-oriented Design. Paris, France.

Cribbs, J., Moon, S., and Roe, C. 1992. An Evaluation of Object- Oriented Analysis and Design Methodologies. Raleigh, North Carolina: Alcatel Network Systems.

Cunningham, W., and Beck, K. November 1986. A Diagram for Object-oriented Programs. SIGPLAN Notices vol.21(11).

Davis, N., Irving, M., and Lee, J. The Evolution of Object-Oriented Design from Conceptto Method. 1988. Surrey, United Kingdom: Logica Space and Defence Systems Limited.

Dean, H. May 1991. Object-Oriented Design Using Message Flow Decomposition, Jowna/ of Object-Oriented Programming vol.4(2).

deChampeaux, D., Balzer, В., Bulrnan, D., Culver-Lozo, K., Jacobson, I., Mellor, S. The Object-oriented Software Development Process. Vancouver, Canada: OOPSLA'92.

deChampeaux, D., Lea, D., and Faure, P. The Process of Object-oriented Design. Vancouver, Canada: OOPSLA'92.

Edwards, J. and Henderson-Sellers, B. November 1991. A Graphical Notation for Object-oriented Analysis and Design. New South Wales, Australia University of New South Wales.

Felsinger, R. 1987a. Integrating Object-oriented Design, Structured Analysis/Structured Design and Ada for Real-time Systems. Mt. Pleasant, SC.
-- 1987b. Object-oriented Design Course Notes. Torrance CA: Data Processing Management Association.

Fichman, R. and Kemerer, C. October 1992. Object-oriented and Conventional Analysis and Design Methodologies. IEEE Computer vol.25(10).

Firesmith, D. May 6, 1986. Object-oriented Development. Fort Wayne, Indiana: Magnavox Electronic Systems Co.
-- 1993. Object-oriented Requirements Analysis and Logical Design. New York, New York: John Wiley and Sons.

Fowler, M. 1992. A Comparison of Object-Oriented Analysis and Design Methods. Vancouver, Canada: OOPSLA'92.

Gamma, E., Helm, R.Johnson, R., Vlissides, J. 1993. A Catalog of Object-Oriented Design Patterns. Cupertino, California: Taligent.

Gane, C. Summer 1989. Object-oriented Data, Process Modeling. American Programmer vol.2(7-8).

Giddings, R. May 1984. Accommodating Uncertainty in Software Design. Communications of the ACM vol.27(5).

Gomaa, H. September 1984. A Software Design Method for Real-Time Systems. Communications of the ACM vol.27(9).

Gossain, S. and Anderson, B. An Iterative Design Modelfor Reusable Objects. Ottawa, Canada: OOPSLA'90.

Gouda, M., Han, Y.Jensen, E., Johnson, W., and Kain, R. November 1977. Towards a Methodology of Distributed Computer System Design, 6th Texas Conference on Computing Systems. New York, NY: Association of Computing Machinery.

Graham, 1.1991. Object-Oriented Methods. Workingham, England: Addison-Wesley Publishing Company.

Grosch, J. December 1983. Type Derivation Graphs - A Way to Visualize the Type Building Possibilities of Programming Languages. SIGPLAN Notices vol.18(12).

Harel, D. 1987. Statecharts: A Visual Formalism for Complex Systems. Science of Computer Programming, vol.8.
-- May 1988. On Visual Formalisms. Communications of the ACM vol.31 (5).

Henderson-Sellers, B. 1992. A Book of Object-oriented Knowledge. Englewood Cliffs, New Jersey: Prentice Hall.

Inwood, C. 1992. Analysis versus Design: Is there a Difference? The C++Journal vol.2(1). Jackson, M. Summer 1989. Object-oriented Software. American Programmer vol.2(7-8)

Jacobson, I. August 1985. Concepts for Modeling Large Real-Time Systems Academic dissertation. Stockholm Sweden: Royal Institute of Technology, Department of Computer Science.
-- October 1987. Object-oriented Development in an Industrial Environment SIGPLAN Notices vol.22(12).

Jacobson, I., Christerson, M., Jonsson, P., and Overgaard, G. 1992. Object-oriented Software Engineering. Workingham, England: Addison-Wesley Publishing Company.

Jamsa, K. January 1984. Object-oriented Design vs. Structured Design - A Student's Perspective. Software Engineering Notes vol.9(1).

Johnson, R. and Russo, V. May 1991. Reusing Object-oriented Designs. Urbana, Illinois: University of Illinois.

Jones, A. 1979. The Object Model: A Conceptual Tool for Structuring Software, in Operating Systems, ed. R. Bayer et. al. New York, NY: Springer-Verlag.

Kadie, C. 1986. Refinement Through Classes: A Development Methodology for Object-Objected Languages. Urbana, IL: University of Illinois.

Kaplan, S., and Johnson, R. 21 July 1986. Design and Implementing for Reuse. Urbana, IL: University of Illinois, Department of Computer Science.

Kay, A. August 1969. The Reactive Engine. Salt Lake City, Utah: The University of Utah, Department of Computer Science.

Kelly, J. 1986. A Comparison of Four Design Methods for Real-Time Systems. Proceedings of the Ninth International Conference on Software Engineering. New York, NY: Computer Society Press of the IEEE.

Kent, W. 1983. Fact-Based Data Analysis and Design, in Entity-Relationship Approach to Software Engineering, ed. C. Davis et al. Amsterdam, The Netherlands: Elsevier Science.

Kim, J. and Lerch, J. 1992. Towards a Model of Cognitive Process in Logical Design: Comparing Object-oriented and Traditional Functional Decomposition Software Methodologies. Pittsburgh, Pennsylvania: Carnegie Mellon University.

Ladden, R. July 1988. A Survey of Issues to Be Considered in the Development of an Object-oriented Development Methodology for Ada. Software Engineering Notes vol.13(3).

Lieberherr, K., and Riel, A. October 1989. Contributions to Teaching Object-oriented Design and Programming. SIGPLAN Notices vol.24(10).

Liskov, B. 1980. A Design Methodology for Reliable Software Systems, in Tutorial on Software Design Techniques, 3rd ed. ed. P. Freeman and A. Wasserman. New York, NY: Computer Society Press of the IEEE.

Lorenz, M. 1993. Object-oriented Software Development. Englewood Cliffs, New Jersey: Prentice-Hall.

Mannino, P. April 1987. A Presentation and Comparison of Four Information System Development Methodologies. Software Engineering Notes vol.12(2).

Martin, B. 1993. Designing Object-oriented C++ Applications Using the Booch Method. Englewood Cliffs, New Jersey: Prentice-Hall.

Masiero, P., and Germano, F. July 1988. JSD As an Object-oriented Design Method. Software Engineering Notes vol.13(3).

Meyer, B. 1988. Object-oriented Software Construction. New York, NY: Prentice Hall.

Meyer, B. March 1987. Reusability: The Case for Object-Oriented Design. IEEE Software vol.4(2).
-- 1989. From Structured Programing to Object-oriented Design: The Road to Eiffel. Structured Programming vol.10(1).

Mills, H. June 1988. Stepwise Refinement and Verification in Box-Structured System. IEEE Computer vol.21(6).

Mills, H., Linger, R., and Hevner, A. 1986. Principles of Information System Design and Analysis. Orlando, FL: Academic Press.

Minkowitz, C., and Henderson, P. March 1987. Object-Oriented Programming of Discrete Event Simulation Using Petri Nets. Stirling, Scotland: University of Stirling.

Mostow, J. Spring, 1985. Toward Better Models of the Design Process. AI Magazine vol.6(1).

Moulin, В. 1983. The Use of EPAS/lPSO Approach for Integrating Entity Relationship Concepts and Software Engineering Techniques, in Entity-Relationship Approach to Software Engineering. ed. C. Davis et al. Amsterdam, The Netherlands: Elsevier Science.

Mullin, M. 1989. Object-oriented Program Design with Examples in C++. Reading, MA: Addison-Wesley.

Nielsen, K., and Shumate, K. August 1987. Designing Large Real-Time Systems with Ada Communications of the Л CM vol.30(8).

Nielsen, K. March 1988. An Object-oriented Design Methodology for Real-Time Systems in Ada. San Diego, CA: Hughes Aircraft Company.

Nies, S. 1986. The Ada Object-oriented Approach. Proceedings on Ada Programming Language Applications for the NASA Space Station Houston, TX: NASA Lyndon B. Johnson Space Center.

Ossher, H. 1987. A Mechanism for Specifying the Structure of Large Layered, Systems, in Research Directions in Object-oriented Programming, ed. B. Schriver and P. Wegner Cambridge. MA: The MIT Press.

Page-Jones, M., Constantine, L, and Weiss, S. October 1990. Modeling Object-oriented Systems: The Uniform Object Notation. Computer Language vol.7(10).

Parnas, D. 1979. On the Criteria to be Used in Decomposing Systems into Modules. Classics In Software Engineering, ed. E. Yourdon. New York, NY Yourdon Press.

Parnas, D., Clements, P., and Weiss, D. March 1985. The Modular Structure of Complex Systems. IEEE Transactions on Software Engineering vol.SE-11 (3).

Pasik, A., and Schor, M. January 1984. Object-oriented Representation and Reasoning. SIGART Newsletter, no. 87.

Rajlich, V., and Silva, J. 1987. Two Object-oriented Decomposition Methods. Detroit, Michigan: Wayne State University.

Ramamoorthy, C., and Sheu, P. Fall 1988. Object-oriented Systems. IEEE Expert vol.3(3). Reenskaug, Т. August 1981. User-Oriented Descriptions of Smalltalk Systems. Byte vol.6(8).

Reiss, S. 1987. An Object-oriented Framework for Conceptual Programming in Research Directions in Object-oriented Programming, ed. B. Schriver and P. Wegner. Cambridge, MA: The MIT Press.

Richter, C. August 1986. An Assessment of Structured Analysis and Structured Design. Software Engineering Notes, vol.11(4).

Rine, D. October 1987. A Common Error in the Object Structure of Object-oriented Methods. Software Engineering Notes vol.12(4).

Rosenberg, D. and Jennett, P. July 1992. Object-oriented Analysis and Design Methods. Frameworks vol.6(4).

Ross, R. 1987. Entity Modeling: Techniques and Application. Boston, MA: Database Research Group.

Rosson, M., and Gold, E. October 1989. Problem-Solution Mapping in Object-oriented Design. SIGPLAN Notices vol.24(10).

Rumbaugh, J. April 1991. Relational Database Design Using an Object-oriented Methodology. Communications of the A CM vol.31(4).

Sahraoui, A. 1987. Towards a Design Approach Methodology Combining OOP and Petri Nets for

Software Production. Toulouse, France: Laboratoire d'Automatique et d'analyses des systemes du C.N.R.S.

Sakai, H. 1983. A Method for Entity-Relationship Behavior Modeling, in Entity Relationship Approach to Software Engineering, ed. C. Davis et al. Amsterdam, The Netherlands: Elsevier Science.

Seidewitz, E. May 1985. Object Diagrams. Greenbelt, MD: NASA Goddard Space Flight Center.

Seidewitz, E., and Stark, M. 1986. Towards a General Object-oriented Software Development

Methodology. Proceedings of the First International Conference on Ada Programming Language Applications for the NASA Space Station Houston TX: NASA Lyndon B. Johnson Space Center.
-- 1986. General Object-oriented Software Development, Report SEL-86-002. Greenbelt, MD:

NASA Goddard Space Flight Center.
-- July/August 1987. Towards a General Object-oriented Design Methodology. Ada Letters vol.7(4).
-- 1988. An Introduction to General Object-oriented Software Development. Rockville, MD: Millennium Systems.

Shilling, J., and Sweeney, P. October 1989. Three Steps to Views: Extending the Object-oriented Paradigm. SIGPLAN Notices vol.24(10).

Shiaer, S., Mellor, S., and Hywari, W. 1990. OODLE: A Language-Independent Notation for Object-oriented Design. Berkeley, California: Project Technology, California.

Shumate, K. 1987. Layered Virtual Machine/Object-Oriented Design. San Diego, CA: Hughes Aircraft Company.

Smith, M., and Tockey, S. 1988. An Integrated Approach to Software Requirements Definition Using Objects. Seattle, WA: Boeing Commercial Airplane Support Division.

Soisi, S. and Jones, E. March/April 1991. Simple Yet Complete Heuristice for Transforming Data Flow Diagrams into Booch Style Diagrams. Ada Letters vol.XI(2).

Song, X. May 1992. Comparing Software Design Methodologies Through Process Modeling. Irvine, California: University of California.

Stark, M. April 1986. Abstraction Analysis: From Structured Analysis to Object-oriented Design. Greenbelt, MD: NASA Goddard Space Flight Center.

Strom, R. October 1986. A Comparison of the Object-oriented and Process Paradigms. SIGPLAN Notices vol.2i(10).

Teledyne Brown Engineering. October 1987. Software Methodology, Catalog, Report MC87-COMM/ADP-0036. Tinton Falls, NJ.

The Fusion Object-Oriented Analysis and Design Method. May 1992. Bristol, England: Hewlett-Parckard Laboratories.

Trhomas, D. May/June 1989. In Search of an Object-oriented Development Process. Journal of Object-oriented Programming vol.2(1).

Wahl, S. 13 December 1988. Introduction to Object-oriented Software. C++ Tutorial Program of the USENIX Conference. Denver, CO: USENIX Association.

Walters, N. July/August 1991. An Ada Object-Based Analysis and Design Approach. Ada Letters vol.XI(5).

Wasserman, Т., Pircher, P., and Muller R. December 1988. An Object-Oriented Structure Design Method/or Code Generation. San Francisco, CA: Interactive Development Environments.
-- Summer 1989. Concepts of Object-Oriented Structured Design. American Programmer vol.2(7-8).
-- March 1990. The Object-Oriented Structured Design Notation for Software Design Representation. IEEE Computer vol.23(3).

Webster, D. December 1988. Mapping the Design Information Representation Terrain. IEEE Spectrum vol.21(12).

Williams, L. 1986. The Object Model in Software Engineering Boulder, CO: Software Engineering Research.

Wirfs-Brock, R., and Wilkerson, B. October 1989. Object-oriented Design: A Responsibility-Driven Approach. SIGPLAN Notices vol.24(10).

Wirfs-Brock, R., Wilkerson, В., and Wiener, L. 1990. Designing Object-oriented Software. Englewood Cliffs, New Jersey: Prentice Hall.

Xong, X. and Osterweil, L. June 1992. A Detailed Objective Comparison and Integration of Two Object-oriented Design Methodologies. Irvine, California: University of California.

Yau, S., and Tsai, J. June 1986. Survey of Software Design Techniques. IEEE Transactions on Software Engineering vol.SE-12(6)

Zachman, J. 1987. A Framework for Information Systems Architecture. IBM System Journal vol.26(3).

Zimmerman, R. 1983. Phases, Methods, and Tools - A Triad of System Development, in Entity-Relationship Approach to Software Engineering, ed. C. Davis et al. Amsterdam, The Netherlands: Elsevier Science.

G. Объектно-ориентированное программирование

Ada and C++: Business Case Analysis. July 1991. Washington, D.C.: Deputy Assistant Secretary of the Air Force.

Adams, S. July 1986. MetaMethods: The MVC Paradigm. HOOPLA: Hooray for Object-oriented Programming Languages vol.1(4). Everette, WA: Object-oriented Programming for Smalltalk Applications Developers Association.

Agha, G. October 1986. An Overview of Actor Languages. SIGPLAN Notices vol.21(10).
-- 1988. Actors: A Model of Concurrent Computation in Distributed Systems. Cambridge, MA: The MIT Press.

Agha, G., and Hewitt, C. 1987. Actors: A Conceptual Foundation for Concurrent Object-oriented Programming, in Research Directions in Object-oriented Programming, ed. B. Schriver and P. Wegner Cambridge. MA: The MIT Press.

Aksit, M., and Tripathi, A. September 1988. Data Abstraction Mechanisms in Sina/st. SIGPLAN Notices vol.23(11).

Albano, A. June 1983. Type Hierarchies and Semantic Data Models. SIGPLAN Notices vol.18(6).

Almes, G., Black, A. Lazowska, E., and Noe, J. January 1985. The Eden System: A Technical Review. IEEE Transactions of Software Engineering vol. SE-11(1).

Alpert, S., Woyak, S., Shrobe, H. and Arowood, L. December 1990. Object-oriented Programming in Al. IEEE Expert vol.5(6).

Althoff, J. August 1981. Building Data Structures in the Smalltalk-80 System. Byte vol.6(8).

Ambler, A. 1980. Gypsy: A Language for Specification and Implementation of Verifiable Programs, in Programming Language Design, ed. A. Wasserman. New York, NY: Computer Society Press.

America, P. 1987. POOL-T: A Parallel Object-oriented Language, in Object-oriented Concurrent Programming, ed. Yonezawa and M. Tokoro. Cambridge, MA: The MIT Press.

Apple Computer. 1989. MacApp: The Expandable Macintosh Application, version 2.0B9. Cupertino, CA.
-- Macintosh Programmers Workshop Pascal 3.0 Reference. Cupertino, CA.
-- AT&T Bell Laboratories. 1989. UNIX System VATTC++ Language System, Release 2.0 Library Manual. Murray Hill, NJ.
-- UNIX System VATTC++ Language System, Release 2.0 Product Reference Manual. Murray Hill, NJ.
-- UNIX System VATTC++ Language System. Release 2.0 Release Notes. Murray Hill, NJ.
-- UNIX System VATT C+ + Language System, Release 2.0 Selected Readings. Murray Hill, NJ.

Attardi, G. 1987. Concurrent Strategy Execution in Omega, in Object-oriented Concurrent Programming, ed. Yonezawa and M. Tokoro. Cambridge. MA: The MIT Press.

Bach, I. November/December 1982. On the Type Concept of Ada. Ada Letters vol.11(3).

Badrinath, В., and Ramamritham, K. May 1988. Synchronizing Transactions on Objects. IEEE Transactions on Computers vol.37(5).

Ballard, M., Maier, D., and Wirfs-Brock, A. November 1986. QUICKTALK: A Smalltalk-80 Dialect for Defining Primitive Methods. SIGPLAN Notices vol.21(11).

Beaudet, P., and Jenkins, M. June 1988. Simulating the Object-oriented Paradigm in Nial. SIGPLAN Notices vol.23(6).

Bennett, J. October 1987. The Design and Implementation of Distributed Smalltalk. SIGPLAN Notices vol.22(12).

Bergin, J., and Greenfield, S. March 1988. What Does Modula-2 Need to Fully Support Object-oriented Programming? SIGPLAN Notices vol.23(3).

Bhaskar, K. October 1983. How Object-oriented Is Your System? SIGPLAN Notices vol.18(10).

Birman, K., Joseph, Т., Raeuchle, Т., and Abbadi, A. June 1985. Implementing Fault-tolerant Distributed Objects. IEEE Transactions of Software Engineering vol.SE-11(6).

Birtwistle, G., Dahl, O-J., Myhrhaug, В., and Nygard, K. 1979. Simula begin. Lund, Sweden: Studentlitteratur.

Black, A., Hutchinson, N., Jul, E., and Levy, H. November 1986. Object Structure in the Emerald System. SIGPLAN Notices vol.21(11).

Black, A., Hutchinson, N., Jul, E., Levy, H., and Carter, L. July 1986. Distribution and Abstract Types in Emerald. Report 86-02-04. Seattle, WA: University of Washington.

Blaschek, G. 1989. Implementation of Objects in Modula-2. Structured Programming vol.10(3).

Blaschek, G., Pomberger, G., and Stritzinger, A. 1989. A Comparison of Object-oriented Programming Languages. Structured Programming vol.10 (4).

Block, F., and Chan, N. October 1989. An Extended Frame Language. SIGPLAN Notices vol.24(10).

Bobrow, D. November 1984. If Prolog is the Answer, What Is the Question? Palo Alto, California. Xerox Palo Alto Research Center.
-- 1985. An Overview of KRL, a Knowledge Representation Language, in Readings in Knowledge Representation, ed. R. Brachman and H. Levesque. Los Altos, CA: Morgan Kaufmann.

Bobrow, D., DeMichiel, L, Gabriel, R., Keene, S., Kiczales, G., and Moon, D. September 1988.

Common Lisp Object System Specification X3J13 Document 88-002R. SIGPLAN Notices vol.23.

Bobrow, D., Kahn, K., Kiczales, G., Masinter, L., Stefik, M., and Zdybel, F. August 1985. COMMONLOOPS: Merging Common Lisp and Object-Oriented Programming, Report ISL-85-8. Palo Alto, CA: Xerox Palo Alto Research Center, Intelligent Systems Laboratory.

Borgida, A. January 1985. Features of Languages for the Development of Information Systems at the Conceptual Level. IEEE Software vol.2(1).
-- October 1986. Exceptions in Object-Oriented Languages. SIGPLAN Notices vol.21(10).

Borning, A., and Ingalls, D. 1982a. A Type Declaration and Inference System for Smalltalk. Palo Alto, CA: Xerox Palo Alto Research Center.
-- 1982b. Multiple Inheritance in Smalltalk-80. Proceedings of the National Conference on Artificial Intelligence. Menio Park, CA: AAAI.

Bos, J. September 1987. PCOL - A Protocol-Constrained Object Language. SIGPLAN Notices vol.22(9).

Briot, J., and Cointe, P. October 1989. Programming with Explicit Metaclasses in Smalltalk. SIGPLAN Notices vol.24(10).

Buzzard, G., and Mudge, T. 1987. Object-Based Computing and the Ada Programming Language, in Object-oriented Computing: Concepts vol.1. ed. G. Peterson. New York, NY: Computer Society Press of the IEEE.

Canning, P., Cook, W., Hill, W., and Olthoff, W. October 1989. Interfaces for Strongly-Typed Object-oriented Programming. SIGPLAN Notices vol.24 (10).

Caudill, P., and Wirfs-Brock, A. November 1986. A Third Generation Smalltalk-80 Implementation. SIGPLAN Notices vol.21(11).

Chambers, C., Ungar, D., and Lee, E. October 1989. An Efficient Implementation of Self, a Dinamically-Typed Object-oriented Language Based on Prototypes SIGPLAN Notices-vol.24(10).

Chang, S. 1990. Visual Languages and Visual Programming. New York, New York: Plenum Press.

Chin, R. and Chanson, S. March 1991. Distributed Object-based Programming Systems. ACM Computing Surveys vol.23(1).

Clark, K. December 1988. PARLOG and Its Application. IEEE Transactions on Software Engineering vol.14(12).

Cleaveland, С. 1980. Programming Languages Considered as abstract Data Types. Communications of the ACM.

Coad, P. and Nicola, J. 1993. Object-oriented Programming. Englewood Cliffs, New Jersey: Yourdon Press.

Cointe, P. October 1987 Metaclasses Are First Class: the ObjVlisp Model. SIGPLAN Notices vol.22(12).

Connor, R., Dearie, A., Morrison, R., and Brown, A. October 1989. An Object Addressing Mechanism for Statically Typed Languages with Multiple Inheritance. SIGPLAN Notices vol.24(10).

Conroy, Т., and Pelegri-Llopart, E. 1983. An Assessment of Method-lookup Caches for Smalltalk-80 Implementations, in Smalltalk-80: Bits of History, Words of Advice, ed. G. Krasner. Reading MA: Addison-Wesley.

Coplien, J. 1992. Advanced C++ Programming Styles and Idioms. Reading, Massachusetts: Addison-Wesley Publishing Company.

Corradi. A., and Leonardi. L. December 1988. The Role of Opaque Types in Building Abstractions. SIGPLAN Notices vol.'23(12).

Сох, В. 1986. Object-oriented Programming: An Evolutionary Approach. Reading, MA: Addison-Wesley.

Cox, B. January 1983. The Object-oriented Pre-compiler. SIGPLAN Notices vol.18(1).
-- January 1984. Message/Object Programming: An Evolutionary Change in Programming Technology. IEEE Software vol.1(1).
-- February/March 1984. Object-oriented Programming: A Power Tool for Software Craftsmen. Unix Review.
-- October/November 1983. Object-oriented Programming in C. Unix Review. Сох, В., and Hunt, B. August 1986. Objects, Icons, and Software-lCs. Byte vol.11(8).

Cox, P. and Pietrzykowski, T. March 1989. Prograph: A Pictorial View of Object-oriented Programming. Nova Scotia, Canada: Technical University of Nova Scotia.

deJong, P. October 1986. Compilation into Actors. SIGPLAN Notices vol. 21(10). Deutsch, P. August 1981. Building Control Structures in the Smalltalk-80 System. Byte vol.6(8).
-- 1983. Efficient Implementation of the Smalltalk-80 System. Proceedings of the 11th Annual ACM Symposium on the Principles of Programming Languages. New York. NY: Association of Computing Machinery.

Dewhurst, S., and Stark, K. 1989. Programming in C++. Englewood Cliffs, NJ: Prentice Hall. Diederich, J., and Milton, J. May 1987. Experimental Prototyping in Smalltalk. IEEE Software vol.4(3).

Dixon, R., McKee, Т., Schweizer, P., and Vaughn, M. October 1989. A Fast Method Dispatcher for Compiled Languages with Multiple Inheritance. SIGPLAN Notices vol.24(10).

Dony, С. August 1988. An Object-oriented Exception Handling System for an Object-oriented Language Proceedings of ECOOP'88: European Conference on Object-Oriented Programming. New York, NY: Springer-Verlag.

Duff, C. August 1986. Designing an Efficient Language. Byte vol.11 (8).

Dussud, P. October 1989. TICLOS: An Implementation of CLOS for the Explorer Family. SIGPLAN Notices vol.24(10).

Eccles, J. 1988. Porting from Common Lisp with Flavors to C++. Proceedings of USENIX C++ Conference. Berkeley, CA: USENIX Association.

Edelson, D. September 1987. How Objective Mechanisms Facilitate the Development of Large Software Systems in Three Programming Languages. SIGPLAN Notices vol.22(9).

Ellis, M. and Stroustrup, B. 1990. The Annotated C++ Reference Manual. Reading, Massachusetts: Addison-Wesley Publishing Company.

Endres, T. May 1985. Clascal - An Object-oriented Pascal. Computer Language vol.2(5). Entsminger, G. 1990. The Tao of Objects. Redwood City, California: M & T Books. Filman, R. October 1987. Retrofitting Objects. SIGPLAN Notices vol.22(12). Finzer, W., and Gould, L. June 1984. Programming by Rehearsal. Byte vol.9(6).

Foote, В., and Johnson, R. October 1989. Reflective Facilities in Smalltalk-80. SIGPLAN Notices vol.24(10).

Freeman-Benson, B. October 1989. A Module Mechanism for Constraints in Smalltalk. SIGPLAN Notices vol.24(10).

Fukunaga, K., and Jirose, S. November 1986. An Experience with a Prolog-Based Object-Oriented Language. SIGPLAN Notices vol.21(11).

Gabriel, R., White, J., and Bobrow, D. September 1991. CLOS Integrating Object-oriented and Functional Programming. Communications of the Л CM vol.34( 9).

Goldberg, A. August 1981. Introducing the Smalltalk-80 System. Byte vol.6(8). Goldberg, A. September 1988. Programmer as Reader. IEEE Software vol.4(5).

Goldberg, A., and Kay, A. March 1976. Smalltalk-72 Instructional Manual. Palo Alto, CA: Xerox Palo Alto Research Center.
-- 1977. Methods for Teaching Programming Language Smalltalk, Report SSL 77-2. Palo Alto, CA:

Xerox Palo Alto Research Center.

Goldberg, A., and Pope, S. Summer 1989. Object-oriented Programming Is Not Enough. American Programmer vol.2(7-8).

Goldberg, A., and Robson, D. 1983. Smalltalk-80: The Language and Its Implementation. Reading, MA: Addison-Wesley.
-- 1989. Smalltalk-80: The Language. Reading, MA: Addison-Wesley.

Goldberg, A., and Ross, J. August 1981. Is the Smalltalk-80 System for Children? Byte vol.6(8).

Goldstein, Т. May 1989. The Object-oriented Programmer. The C++ Report vol.1(5).

Gonsalves, G., and Silvestri, A. December 1986. Programming in Smalltalk-80: Observations and Remarks from the Newly Initiated. SIGPLAN Notices vol. 21(12).

Gorlen, K. 1989. An Introduction to C++, in UNIX Systems VATTC++ Language System, Release 2.0 Selected Readings. 1989. Murray Hill, NJ: ATT Bell Laboratories.

Golden, K., Orlow, S., and Plexico, P. 1990. Data Abstraction and Object-oriented Programming in C++. New York, New York: John Wiley and Sons.

Gougen, J., and Meseguer, J. 1987. Unifying Functional, Object-oriented, and Relational Programming with Logical Semantics, in Research Directions in Object-oriented Programming. ed. Schriver and P. Wegner Cambridge. MA: The MIT Press.

Graube, N. August 1988. Reflexive Architecture: From ObjVLisp to CLOS. Proceedings of ECOOP'88 European Conference of Object-oriented Programming New York, NY: Springer-Verlag.

Grogono, P. November 1989. Polymorphism and Type Checking in Object-oriented Languages. SIGPLAN Notices vol.24(11).
-- 1991. Issues in the Design of an Object-oriented Programming Language. Structured Programming vol.12(1).

Hagmann, R. 1983. Preferred Classes: A Proposal for Faster Smalltalk-80 Execution, in Smalltalk-80: Bits of History, Words of Advices, ed. G. Krasner. Reading, MA: Addison-Wesley.

Hailpern. В., and Nguyen, V. 1987. A Model for Object-Based Inheritance, in Research Directions in Object-oriented Programming, ed. B. Shriver and P. Wegner. Cambridge, MA: The MIT Press.

Halbert, D., and O'Brien, P. September 1988. Using Types and Inheritance in Object-oriented Programming IEEE Software vol.4(5).

Halstead, R. 1988. Object-management on Distributed Systems, in Object-oriented Computing:

Implementations vol.2. ed. G. Peterson. New York, NY: Computer Society Press of the IEEE.

Harland, D., Szyplewski, M., and Wainwright, J. October 1985. An Alternative View of Polymorphism. SIGPLAN Notices vol.20(10).

Hendler, J. October 1986. Enhancement for Multiple Inheritance. SIGPLAN Notices vol.21(10).

Hines, Т., and Unger, E. 1986. Conceptual Object-oriented Programming. Manhattan, Kansas: Kansas State University.

Ingalls, D. The Smalltalk-76 Programming System Design and Implementation. Proceedings of the Fifth Annual ACM Symposium on Principles of Programming Languages, New York, NY: Association of Computing Machinery.
-- August 1981a. Design Principles Behind Smalltalk. Byte vol.6(8).
-- August 1981. The Smalltalk Graphics Kernel. Byte vol.6(8).
-- 1983. The Evolution of the Smalltalk Virtual Machine, in Smalltalk-80 Bits of History, Words of Advice, ed. G. Krasner. Reading, MA: Addison-Wesley.
-- November 1986. A Simple Technique for Handling Multiple Polymorphism. SIGPLAN Notices vol.21(11).

Ishikawa, Y., and Tokoro, M. 1987. Orient84/K: An Object-oriented Concurrent Programming Language for Knowledge Representation, in Object-oriented Concurrent Programming, ed. Yonezawa and M. Tokoro. Cambridge, MA: The MIT Press.

Jackson, M. May 1988. Objects and Other Subjects. SIGPLAN Notices vol. 23(5).

Jacky, J., and Kalet, I. September 1987. An Object-oriented Programming Discipline for Standard Pascal. Communications of the ACM vol.30(9).

Jacobson, I. November 1986. Language Support for Changeable, Large, Real-Time Systems. SIGPLAN Notices vol.21(11).

Jeffery, D. February 1989. Object-oriented Programming in ANSI C. Computer Language. Jenkins, M., and Glasgow, J. January 1986. Programming Styles in Nial. IEEE Software vol.3(1). Johnson, R. November 1986. Type-Checking Smalltalk. SIGPLAN Notices vol.21(11).

Johnson, R., Graver, J., and Zurawski, L. September 1988. TS An Optimizing Compiler for Smalltalk. SIGPLAN Notices vol.23(11).

Kaehler, and Patterson, D. 1986. A Taste of Smalltalk. New York, NY: W. W. Norton.
-- August 1986. A Small Taste of Smalltalk. Byte vol.11(8).

Kaehler, Т. November 1986. Virtual Memory on a Narrow Machine for an Object-oriented Language. SIGPLAN Notices vol.21(11).

Kahn, K., Tribble, E., Miller, M., and Bobrow, D. 1987. Vulcan: Logical Concurrent Objects, in Research Directions Object-oriented Programming, ed. B. Schriver and P. Wegner. Cambridge, MA: The MIT Press.
-- November 1986. Objects in Concurrent Logic Programming Languages. SIGPLAN Notices vol.21(11).

Kaiser, G., and Garlan, D. October 1987. MELDing Data Flow and Object-oriented Programming. SIGPLAN Notices vol.22(12).

Kalrne, С. 27 March 1986. Object-oriented Programming: A Rule-Based Perspective. Los Angeles, CA: Inference Corporation.

Kay, A. New Directions for Novice Programming in the 1980s. Palo Alto, CA: Xerox Palo Alto Research Center.

Keene, S. 1989. Object-oriented Programming in Common Lisp. Reading, MA: Addison-Wesley.

Kelly, K., Rischer, R., Pleasant, M., Steiner, D., McGrew, C., Rowe. J., and Rubin, M. 30 March 1986. Textual Representations of Object-oriented Programs for Future Programmers. Palo Alto, CA: Xerox Al Systems.

Kempf, J., Harris, W., D'Souza, R., and Snyder, A. October 1987. Experience with CommonLoops. SIGPLAN Notices vol.22(12).

Kempf, R. October 1987. Teaching Object-Oriented Programming with the KEE System. SIGPLAN Notices vol.22(12).

Khoshafian, S., and Copeland, G.November 1986. Object Identity. SIGPLAN Notices vol.21(11).

Kiczales, G., Rivieres, J., and Bobrow, D. 1991. The Art of the Metaobject Protocol. Cambridge, Massachusetts: The MIT Press.

Kilian, M. April 1987. An Overview of the Trellis/Owl Compiler. Hudson, MA: Digital Equipment Corporation.

Kimminau, D., and Seagren, M. 1987. Comparison of two Prototype Development Using Object-Based Programming. Naperville, IL: AT&T Bell Laboratories.

Knowledge Systems Corporation. 1987. Pluggable Gauges Version 1.0 User Manual. Cary, NC.

Knudsen J. and Madsen, O. August 1988. Teaching Object-oriented Programming Is More than Teaching Object-oriented Programming Languages. Proceedings of ECOOP'88: European Conference on Object-oriented Programming. New York, NY: Springer-Verlag.

Knudsen, J. August 1988. Name Collison in Multiple Classification Hierarchies. Proceedings of ECOOP'88; European Conference on Object-oriented Programming. New York, NY: Springer-Verlag.

Korson, T. and McGregor, J. September 1990. Understanding Object-oriented: A Unifying Paradigm. Communications of the ACM vol.33(9).

Koshmann, Т., and Evers, M. July 1988. Bridging the Gap Between Object-oriented and Logic Programming. IEEE Software vol.5(4).

Koskimies, K., and Paakki, J. July 1987. TOOLS: A Unifying Approach to Object-oriented Language Interpretation. SIGPLAN Notices vol.22(7).

Krasner, G. August 1981. The Smalltalk-80 Virtual Machine. Byte vol. 6(8).
-- ed. 1983. Smalltalk-80 Bits of History, Words of Advice. Reading, MA: Addison-Wesley.

Krasner, G, and Pope, S. August/September 1988. A Cookbook for Using the Model-View-Controller User Interface Paradigm in Smalhalk-8O.Joumal of Object-oriented Programming, vol.1(3).

Kristensen, В., Madsen, O., Moller-Pedersen, В., and Nygaard, K. 1987. The BETA Programming Language, in Research Directions Object-oriented Programming, ed. B. Schriverand P. Wegner. Cambridge. MA: The MIT Press.

LaLonde, W. April 1989. Designing Families of Data Types Using Exemplars. ACM Transactions on Programming Language and Systems vol.11(2).

LaLonde, W., Thomas, D., and Pugh, J. November 1986. An Examplar Based Smalltalk. SIGPLAN Notices vol.21(11).

LaLonde, W. and Pugh, J. 1990. Inside Smalltalk, Volumes 1 and 2. Englewood Cliffs, New Jersey: Prentice Hall.

Lang, K., and Peralmutter, B. November 1986. Oaklisp: an Object-oriented Scheme with First Class Types. SIGPLAN Notices vol.21(11).

Laursen, J., and Atkinson, R. October 1987. Opus: A Smalltalk Production System SIGPLAN Notices vol.22(12)

Lieberherr, K., and Holland, I. March 1989. Formulations and Benefits of the Law of Demeter. SIGPLAN Notices vol.24(3).
-- September 1989. Assuring Good Style for Object-oriented Programs. IEEE Software vol.6(5).

Lieberherr, K., Holland, I., Lee, G., and Riel, A. June 1988. An Objective Sense of Style. IEEE Computer vol.21(6).

Lieberman, H. November 1986. Using Prototypical Objects to Implement Shared Behavior in Object-oriented Systems. SIGPLAN Notices vol.21(11).
-- 1987. Concurrent Object-oriented Programming in Act 1, in Object-oriented Concurrent Programming, ed. Yonezawa and M. Tokoro. Cambridge, MA: The MIT Press.

Lieberman, H., Stein, L., and Ungar, D. May 1988. Of Types and Prototypes: The Treaty of Orlando. SIGPLAN Notices vol.23(5).

Lim, J., and Johnson, R. April 1989. The Heart of Object-oriented Concurrent Programming. SIGPLAN Notices vol.24(4).

Linowes, J. August 1988. It's an Attitude. Byte vol.13(8).

Lippman, S. 1989. C++ Primer 1991 2nd Edition. Reading, Massachusetts: Addison-Wesley Publishing Company.

Liskov, В., Atkinson, R., Bloom, T., Moss, E., Schaffert, C., Scheifler, R., and Snyder. R. 1981. CLU Reference Manual. New York, NY: Springer-Verlag.

Liskov, В., Snyder, A., Atkinson, R., and Schaffert, C. 1980. Abstraction Mechanisms in CLU, in Programming Language Design, ed. A. Wasserman. New York, NY: Computer Society Press.

Liu, C. March 1991. On the Object-Orientedness of C++. SIGPLAN Notices vol.26(3).

Lujun, S., and Zhongxiu. August 1987. An Object-oriented Programming Language for Developing Distributed Software. SIGPLAN Notices vol.22(8).

MacLennan, B. 1987. Values and Objects in Programming Languages, in Object-oriented Computing: Concepts vol.1. ed. G. Peterson. New York, NY: Computer Society Press of the IEEE.

Madsen, 0.1987. Block Structure and Object-oriented Languages, in Research Directions in Object-oriented Programming. ed. B. Schriver and P. Wegner. Cambridge, MA: The MIT Press.

Madsen, 0., and Moller-Pedersen, B. August 1988. What Object-oriented Programming May Be -And What It Does Not Have To Be. Proceedings of ECOOP'88: European Conference on Object-oriented Programming. New York, NY: Springer-Verlag.

Madsen, 0., and Moller-Pedersen, B. October 1989. Virtual Classes: A Powerful Mechanism in Object-oriented Programming. SIGPLAN Notices vol. 24(10).

Manci, D. 1990. Use of Metrics to Evaluate C++. Liberty Corner, New Jersey: AT&T Bell Laboratories.

Mannino, M., Choi, I., and Batory, D. November 1990. The Object-oriented Functional Data Language. IEEE Transactions on Software Engineering vol. 16(11).

Marcus, R.November 1985. Generalized Inheritance. SIGPLAN Notices vol.20(11).

Markowitz, V., and Raz, Y. 1983. Eroll: An Entity-Relationship, Role-Oriented Query Language, in Entity-Relationship Approach to Software Engineering, ed. C. Davis et al. Amsterdam, The Netherlands: Elsevier Science.

Masini, G., Napoli, A., Colnet, D., and Tompre, K. 1991. Object-oriented Languages. London, England: Academic Press.

Mellender, F. October 1988. An Integration of Logic and Object-oriented Programming. SIGPLAN Notices vol.23(1O).

Methfessel, R. April 1987. Implementing an Access and Object-oriented Paradigm in a Language That Supports Neither. SIGPLAN Notices vol.22(4).

Meyer, B.November 1986. Genericity versus Inheritance. SIGPLAN Notices vol.21(11).
-- February 1987. Eiffel: Programming for Reusability and Extensibility. SIGPLAN Notices vol.22(2).
-- November/December 1988. Harnessing Multiple Inheritance. Journal of Object-Oriented Programming vol.1(4).

Micallef, J. April/May 1988. Encapsulation, Reusability, and Extensibility in Object-Oriented Programming Languages-./ounia/ of Object- Oriented Programming vol.1(1).

Microsoft C++ Tutorial. 1992. Redmond, Washington: Microsoft Corporation. Microsoft Windows Guide to Programming. 1992. Redmond, Washington: Microsoft Corporation.

Minsky, N., and Rozenshtein, D. October 1987. A Law-Based Approach to Object-oriented Programming. SIGPLAN Notices vol.22(12).
-- October 1989. Controllable Delegation: An Exercise in Law-Governed Systems. SIGPLAN Notices vol.24(10).

Miranda. E. October 1987. BrouHaHa - A Portable Smalltalk Interpreter. SIGPLAN Notices vol.22(12).

Mittal, S., Bobrow, D., and Kahn, K. November 1986. Virtual Copies: At the Boundary Between Classes and Instances. SIGPLAN Notices vol.21 (11).

Moon, D. November 1986. Object-oriented Programming with Flavors. SIGPLAN Notices vol.21(11).

Morrison, R., Dearie, A., Connor, R., and Brown, A. July 1991. An Ad Hoc Approach to the Implementation of Polymorphism. ACM Transactions on Programming Languages and Systems vol.13(3).

Mossenbock, H., and Tempi, J. 1989. Object Oberon - A Modest Object-oriented Language. Structured Programming vol.10(4).

Mudge, Т. March 1985. Object-Based Computing and the Ada Language. IEEE Computer vol.18(3). Murray, R. 1990. C++ Tactics. Liberty Corner, New Jersey: AT&T Bell Laboratories.

Nelson, M. October 1991. Concurrency and Object-oriented Programming. SIGPLAN Notices vol.26(10).

Nierstrasz, 0. October 1987. Active Objects in Hybrid. SIGPLAN Notices vol.22(12). Novak, G. June 1983. Data Abstraction in GLISP. SIGPLAN Notices vol.18(6).
-- Fall 1983. GLISP: A Lisp-Based Programming System with Data Abstraction. AI Magazine vol.4(3).

Nygaard, K. October 1986. Basic Concepts in Object-oriented Programming. SIGPLAN Notices vol.21(10).

Nygaard, K., and Dahl, O-J. 1981. The Development of the Simula Languages, in History of Programming Languages, ed. R. Wexelbalt. New York, NY: Academic Press.

O'Brien, P. 15 November 1985. Trellis Object-Based Environment: Language Tutorial. Hudson, MA: Digital Equipment Corporation.

O'Grady, F. July/August 1990. Is There Life After COBOL? American Programmer. 3(7-8). Object-oriented Programming Workshop. October 1986. SIGPLAN Notices vol.21(10).

Olthoff, W. 1986. Augmentation of Object-Oriented Programming by Concepts of Abstract Data Type Theory: The ModPascal Experience. Kaiserslautern, West Germany: University of Kaiserslautern.

Osterbye, K. June/July 1988. Active Objects: An Access-Oriented Framework for Object-oriented Languages. Journal of Object-oriented Programming vol.1(2).

Paepcke, A. October 1989. PCLOS: A Critical Review. SIGPLAN Notices vol.24(10).

Parc Place Systems. 1988. The Smalltalk-80 Programming System Version VI 2.3. Palo Alto, CA.

Pascoe, G. August 1986. Elements of Object-oriented Programming. Byte vol.11(8).
-- November 1986. Encapsulators: A New Software Paradigm in Smalltalk-80. SIGPLAN Notices vol.21(11).

Perez, E. Sertember/October 1988. Simulating Inheritance with Ada. Ada Letters vol.8(7).

Peterson, G. ed. 1987. Object-oriented Computing Concepts. New York, NY: Computer Society Press of the IEEE.

Pinson, L., and Wiener, R. 1988. An Introduction to Object-oriented Programming and Smalltalk. Reading, MA Addison-Wesley.

Pohl, I. 1989. C++ for С Programmers. Redwood City, CA: Benjamin/Cummings. Pokkunuri, B. November 1989. Object-oriented Programming. SIGPLAN Notices vol.24(11). Ponder, С. and Bush, B. June 1992. Polymorphism Considered Harmful. SIGPLAN Notices vol.27(6). Fountain, D. August 1986. Object-oriented FORTH. Byte vol.11(8).

Proceedings of ECOOP'88: European Conference on Object-Oriented Programming. August 1988. New York, NY: Springer-Verlag.

Proceedings of OOPSLA '86: Object-oriented Programming Systems, Languages, and Applications. November 1986. SIGPLAN Notices vol.21(11).

Proceedings of OOPSLA 87: Object-oriented Programming Systems, Languages, and Applications. October 1987. SIGPLAN Notices vol.22(12).

Proceedings of OOPSLA Object-oriented Programming Systems, Languages, and Applications. September 1988. SIGPLAN Notices vol.23(11).

Proceedings of OOPSLA'89: Object-oriented Programming Systems, Languages, and Applications. October 1989. SIGPLAN Notices vol.24(10).

Proceedings of OOPSLA'90. Object-Oriented Programming Systems, Languages, and Applications. October 1990. SIGPLAN Notices vol.25(10).

Proceedings of OOPSLA'91. Object-oriented Programming Systems. Languages, and Applications. November 1991. SIGPLAN Notices vol.26(11).

Proceedings of OOPSLA '92. Object-Oriented Programming Systems, Languages, and Applications. October 1992. SIGPLAN Notices vol.27(10).

Proceedings of the ACM SIGPLAN Workshop on Object-Based Concurrent Programming. April 1989. SIGPLAN Notices vol.24(4).

Proceedings of the USENIX Association C++ Workshop. November 1987. Berkeley, CA: USENIX Association.

Proceedings of the Workshop on Data Abstraction, Databases and Conceptual Modelling. 1980. SIGPLAN Notices vol.16(1).

Pugh, J. March 1984. Actors - The Stage is Set. SIGPLAN Notices vol. 19(3).

Rathke, С. 1986. ObjTalk: Representation von Wissen in einer objektorientierten Sprache Stuttgart, West Germany: Institut fur Informatik der Universitat Stuttgart.

Rentsch, T. September 1982. Object-oriented Programming. SIGPLAN Notices vol.17(12).

Rettig, M., Morgan, Т., Jacobs, J., and Wimberly, D. January 1989. Object-oriented Programming in AI. AIExpert.

Robson, D. August 1981. Object-Oriented Software Systems. Byte vol. 6(8).

Rumbaugh, J. October 1987. Relations as Semantic Constructs in an Object-oriented Language. SIGPLAN Notices vol.22(12).

Russo, V., and Kaplan, S. 1988. A C++ Interpreter for Scheme. Proceedings of USENIX C++ Conference. Berkeley, CA: USENIX Association.

Sakkinen, M. August 1988. On the Darker Side of C++. Proceedings of ECOOP'88: European Conference on Object-oriented Programming. New York, NY: Springer-Verlag.

-- December 1988. Comments on "the Law of Demeter" and C++. SIGPLAN Notices vol.23(12).

Saltzer, J. 1979. Naming and Binding of Objects, in Operating Systems, ed. R. Bayer et. al. New York, NY: Springer-Verlag.

Sandberg, D. November 1986. An Alternative To Subclassing. SIGPLAN Notices vol.21(11).
-- October 1988. Smalltalk and Exploratory Programming. SIGPLAN Notices vol.23(10).

Saunders, J. March/April 1989. A Survey of Object-oriented Programming Languages./ournal of Object-oriented Programming vol.1(6).

Schaffert, С., Cooper, T., and Wilpolt, C. November 25, 1985. Trellis Object-Based Environment: Language Reference Manual. Hudson, MA: Digital Equipment Corporation.

Schaffert, C., Cooper, Т., Bullis, В., Kilian, M., and Wilpolt, C. November 1986. An Introduction to Trellis/Owl. SIGPLAN Notices vol.21(11).

Schmucker, K. 1986a. MacApp: An Application Framework. Byte vol.11 (8).
-- 1986b. Object-oriented Languages for the Macintosh. .Byte vol.11 (8).
-- 1986с. Object-Oriented Programming for the Macintosh. Hasbrouk Heights, NJ: Hayden.

Schriver, В., and Wegner, P. eds. 1987. Research Directions in Object-oriented Programming. Cambridge, MA: The MIT Press.

Seidewitz, E. March/April 1992. Object-oriented Programming with Mixins in Ada. Ada Letters vol.XII(2).
-- October 1987. Object-oriented Programming in Smalltalk and Ada. SIGPLAN Notices vol.22(12). Shafer, D. 1988. Hyper Talk Programming. Indianapolis, IN: Hayden Book.

Shah, A., Rumbaugh, J., Hamel, J., and Borsari, R. October 1989. DSM: An Object-Relationship Modeling Language. SIGPLAN Notices vol.24(10).

Shammas, N. October 1988. Smalltalk a la C. Byte vol.13(10).

Shan, Y. October 1989. An Event-Driven Model-View-Controller Framework for Smalltalk. SIGPLAN Notices vol.24(10).

Shapiro, J. 1991. A C++ Toolkit. Englewood Cliffs, New Jersey Prentice-Hall. Shaw, M. 1981. ALPHARD: Form and Content. New York, NY: Springer-Verlag.

Shibayama, E. September 1988. How to Invent Distributed Implementation Schemes of an Object-Based Concurrent Language - A Transformational Approach. SIGPLAN Notices vol.23(11).

Shibayama, E., and Yonezawa, A. 1987. Distributed Computing in ABCL/1, in Object-oriented Concurrent Programming, ed. Yonezawa and M. Tokoro. Cambridge MA: The MIT Press.

Shopiro, J. 13 December 1988. Programming Techniques with C++. C++ Tutorial Program of the USENIX Conference. Denver, CO: USENIX Association.
-- December 1989. An Example of Multiple Inheritance in C++: A Model of the lostream Library. SIGPLAN Notices vol.24(12).

Simonian, R., and Crone., M. November/December 1988. InnovAda: True Object-oriented Programming in Ada Journal of Object-oriented Programming vol.1(4).

Snyder, A. February 1985 Object-oriented Programming for Common Lisp. Report ATC-85-1. Palo Alto CA: Hewlett-Packard.
-- November 1986. Encapsulation and Inheritance in Object-oriented Programming Languages. SIGPLAN Notices vol.21(11).
-- 1987. Inheritance and the Development of Encapsulated Software Components, in Research Directions in Object-oriented Programming, ed. B. Schriver and P. Wegner. Cambridge, MA: The MIT Press.
-- January 1993. The Essence of Objects: Concepts and Terms. IEEE Software vol.10(1). Software Productivity Solution 1988. Classical-Ada User Manual. Melbourne. FL.

Stankovic, J. April 1982. Software Communication Mechanisms: Procedure Calls Versus Messages. IEEE Computer vol.15(4).

Stefik, M. and Bobrow D. Winter 1986. Object-oriented Programing: Themes and Variations, AI Magazine, vol.6(4).

Stefik, M. Bobrow, D. Mittal, S., and Conway, L. Fall 1983, Knowledge Programing in Loops. AI Magazine vol.4(3).

Stein, L. October 1987. Delegation Is Inheritance. SIGPLAN Notices vol. 22(12).

Stroustrup, B. January 1982. Classes: An Abstract Data Type Facility for the C Language. SIGPLAN Notices vol.17(1).
-- October 1986. An Overview of C++. SIGPLAN Notices vol.21(10).
-- 1987. The Evolution of C++. Proceedings of the USENIX C++ Workshop. Santa Fe. NM: USENIX Association.
-- November 1987. Possible Directions for C++. Proceedings of the USENIX C++ Workshop. Santa Fe., NM: USENIX Association.
-- 1988. Parameterized Types for C++. Proceedings of USENIX C++ Conference. Berkeley, CA: USENIX Association.
-- May 1988 What is Object-oriented Programming? IEEE Software vol. 5(3).
-- August 1988. A Better C? Byte vol.13(8).
-- 1991. The C++ Programming Language. Second Edition. Reading, Massachusetts: Addison-Wesley Publishing Company.

Suzuki.N. 1981. Inferring Types in Smalltalk, Proceedings of the 8th Annual Symposium of ACM Principles of Programming Languages. New York, NY: Association of Computing Machinery.

Suzuki, N., and Terada, M. 1983. Creating Efficient Systems for Object-oriented Languages. Proceedings of the 11th Annual ACM Symposium on the Principles of Programming Languages. New York, NY: Association of Computing Machinery.

Symposium on Actor Languages. October 1980. Creative Computing.

Tektronix. 1988. Modular Smalltalk.

Tesler, L. August 1986. Programming Experiences. Byte vol.11(8).

The Smalltalk-80 System. August 1981. Byte vol.6(8).

Thomas, D. March 1989. What's in an Object? Byte vol.14(3).

Tieman, M. 1 May 1988. User's Guide to GNU C++. Cambridge, MA: Free Software Foundation.

Tokoro, M., and Ishikawa, Y. October 1986. Concurrent Programming in Orient84/K: An Object-Oriented Knowledge Representation Language. SIGPLAN Notices vol.21(10).

Touati, H. May 1987. Is Ada an Object-Oriented Programming Language? SIGPLAN Notices vol.22(5).

Touretzky, D. 1986. The Mathematics of Inheritance Systems. Los Altos, California: Morgan Kaufman Publishers.

Tripathi, A., and Berge, E. An Implementation of the Object-oriented Concurrent Programming Language SINA. Software - Practice and Experience vol.19(3).

U. S. Department of Defense. February 1983. Reference Manual for the Ada Programming Language. Washington, D.C.: Ada Joint Program Office.

Ungar, D. September 1988. Are Classes Obsolete? SIGPLAN Notices vol. 23(11). Ungar, D., and Smith, R. October 1987. Self: The Power of Simplicity. SIGPLAN Notices vol.22(12).

van den Bos, J., and Laffra, C. October 1989. PROCOL: A Parallel Object Language with Protocols. SIGPLAN Notices vol.24(10).

Vaucher, J., Lapalrne, G., and Malenfant, J. August 1988. SCOOP: Structured Concurrent Object-oriented Prolog. Proceedings of ECOOP'88: European Conference on Object-oriented Programming. New York, NY: Springer-Verlag.

Warren. S., and Abbe, D. May 1980. Presenting Rosetta Smalltalk. Datamation.

Watanabe, Т., and Yonezawa, A. September 1988. Reflection in an Object-oriented Concurrent Language. SIGPLAN Notices vol.23(11).

Wegner, P. October 1987. Dimensions of Object-Based Language Design. SIGPLAN Notices vol.22(12).
-- January 1988. Workshop on Object-oriented Programming at ECOOP 1987. SIGPLAN Notices vol.23(1).
-- August 1990. Concepts and Paradigms of Object-oriented Programming. OOPS Messenger vol.1(1).
-- October 1992. Dimensions of Object-oriented Modeling. IEEE Computer vol.25(10).

Wiener, R. June 1987. Object-oriented Programming in C++ - A Case Study. SIGPLAN Notices vol.22(6).

Williams, G. Summer 1989. Designing the Future: The Power of Object-oriented Programming. American Programmer vol.2(7-8).

Wilson, R. 1 November 1987. Object-oriented Languages Reorient Programming Techniques. Computer Design vol.26(20).

Winblad, A., Edwards. S., and King, D. 1990. Object-oriented Software. Reading, Massachusetts: Addison-Wesley Publishing Company.

Winston, P., and Horn, B. 1989. Lisp. 3rd ed. Reading, MA: Addison-Wesley.

Wirfs-Brock, R. and Wilkerson, B. September 1988. An Overview of Modula Smalltalk. SIGPLAN Notices vol.23(11).

Wirth. N. June 1987. Extensions of Record Types. SIGCSE Bulletin vol. 19(2).
-- July 1988a. From Modula to Oberon. Software - Practice and Experience vol.18(7).
-- July 1988b. The Programming Language Oberon. Software - Practice and Experience vol.18(7).

Wolf, W. September 1989. Practical Comparison of Two Object-oriented Languages. IEEE Software vol.6(5).

Yokote, Y., and Tokoro, M. November 1986. The Design and Implementation of Concurrent Smalltalk. SIGPLAN Notices vol.21(11).
-- October 1987. Experience and Evolution of Concurrent Smalltalk. SIGPLAN Notices vol.22(12).

Yonezawa, A., and Tokoro. M. eds. 1987. Object-oriented Concurrent Programming. Cambridge, MA: The MIT Press.

Yonezawa, A., Briot, J., and Shibayama, E. November 1986. Object-oriented Concurrent Programming in ABCL/1. SIGPLAN Notices vol.21(11).

Yonezawa, A., Shibayama, E., Takada, Т., and Honda, Y. Modelling and Programming in an Object-oriented Concurrent Language ABCL/1, in Object-oriented Concurrent Programming, ed. Yonezawa and M. Tokoro. Cambridge, MA: The MIT Press.

Yourdon, E. February 1990. Object-oriented COBOL. American Programmer vol.3(2).
-- January 1992. Modeling Magic. American Programmer vol.5(1).

Zave, P. September 1989. A Compositional Approach to Multiparadigm Programming. IEEE Software vol.6(5).

H. Прикладное программирование

Abdel-Hamid, Т. and Madnick, S. 1991. Software Project Dynamics. Englewood Cliffs, New Jersey Prentice-Hall.

Abelson, H., and Sussman, G. 1985. Structure and Interpretation of Computer Programs. Cambridge, MA The MIT Press.

Andrews, D. and Leventhal, N. 1993. FUSION: Integration IE, CASE, and JAD:A Handbook for Reengineering the Systems Organization. Englewood Cliffs, New Jersey: Yourdon Press.

Appleton, D. 15 January 1986. Large Projects. Datamation.

Aron, J. 1974a. The Program Development Process: The Individual Programmer. Vol.1. Reading, MA:

Addison-Wesley.
-- 1974b. The Program Development Process: The Programming Team. Vol. 2. Reading, MA: Addison-Wesley.

Babich, W. 1986. Software Configuration Management. Reading, Massachusetts: Addison-Wesley Publishing Company.

Ben-Ari, M. 1982. Principles of Concurrent Programming. Englewood Cliffs, NJ: Prentice Hall.

Berard, E. 1993. Essays on Object-oriented Software Engineering. Englewood Cliffs, New Jersey: Prentice-Hall.

Berson, A. 1992. Client/Server Architecture. New York, New York: McGraw-Hill.

Berzins, V. and Luqi. 1991. Software Engineering with Abstractions. Reading, Massachusetts:

Addison-Wesley Publishing Company.

Biggerstaff, T. and Perils, A. 1989. Software Reusability. New York, New York: ACM Press.

Bisant, D. and Lyle, J. October 1989. A Two-Person Inspection Method to Improve Programming Productivity. IEEE Transactions on Software Engineering vol.15(10).

Bischofberger, W. and Keller, R. 1989. Enhancing the Software Life Cycle by Prototyping. Structured Programming.

Bloom, P. April 1993. Trends in Client-Server/Cooperative Processing Application Development Tools. American Programmer, Arlington MA: Cutter Information Corporation.

Boar, B. 1984. Application Prototyping. New York, New York: John Wiley and Sons.

Boehm, B. August 1986. A Spiral Model of Software Development and Enhancement. Software Engineering Notes, vol.11(4).
-- September 1992. Risk Control. American Programmer vol.5(7).

Boehm, В. and Papaccio, P. 1988. Understanding and Controlling Software Costs. IEEE Transactions on Software Engineering vol.4(10).

Boehm-Davis, D., and Ross., L. October 1984. Approaches to Structuring the Software Development Process. Report GEC/DIS/TR-84-B1V-1. Arlington, VA: General Electric.

Booch, G. 1986. Software Engineering with Ada. Menlo Park, CA: Benjamin/Cummings. Brooks, F. 1975. The Mythical Man-Month, Reading, MA: Addison-Wesley.
-- April 1987. No Silver Bullet: Essence and Accidents of Software Engineering. IEEE Computer vol.20(4).

Charette, R. 1989. Software Engineering Risk Analysis and Management. New York, New York: McGraw-Hill Book Company.

Chidamber, S. and Kemerer, C. Towards a Metrics Suite for Object-Oriented Design. Phoenix, Arizona: OOPSLA'91.
-- 1993. A Metrics Suite for Object-oriented Design. Cambridge, Massachusetts: MIT Sloan School of Management.

Chmura, I., Norcio, A., and Wicinski, T. July 1990. Evaluating Software Design Processes by Analyzing Change Date Over Time. IEEE Transactions on Software Engineering vol.16(7).

Сох, В. November 1990. Planning the Software Industrial Revolution. IEEE Software vol.7(6).

Curtis, В. 17 May. 1989. ...But You Have To Understand, This Isn't the Way We Develop Software At Our Company. MCC Technical Report Number STP-203-89. Austin, TX: Microelectronics and Computer Technology Corporation.

Curtis, В., Kellner, M., and Over, J. September 1992. Process Modeling, Communications of the ACM vol.35(9).

Dahl, 0., Dijkstra, E., and Hoare, C. A. 1972. Structured Programming. London, England: Academic Press.

Davis, A. 1990. Software Requirements: Analysis and Specification. Englewood Cliffs, New Jrsey: Prentice-Hall.

Davis, A., Bersoff, E., and Comer, E. October 1988. A Strategy for Comparing Alternative Software Development Life Cycle Models. IEEE Transactions on Software Engineering vol.14(10).

Davis, C., Jajodia, S., Ng, P., and Yeh, R. eds. 1983. Entity-Relationship Approach to Software Engineering. Amsterdam, The Netherlands: Elsevier Science.

DeMarco, Т., and Lister, T. 1987. Peopleware. New York, NY: Dorset House.

DeRemer, F., and Kron, H. 1980. Programming-in-the-Large versus Programming-in-the-Small

Tutorial on Software Design Techniques, 3rd ed. ed. P. Freeman and A. Wasserman. New York, NY: Computer Society Press of the IEEE.

Dewire, D. 1992. Client/Server Computing. New York, NY: McGraw-Hill.

Dijkstra, E. 1979. Programming Considered as a Human Activity, in Classics in Software Engineering, ed. E. Yourdon. New York, NY: Yourdon Press.
-- 1982. Selected Writings on Computing: A Personal Perspective. New York, NY: Springer-Verlag.

Dowson, M. August 1986. The Structure of the Software Process. Software Engineering Notes, vol.11(4).

Dowson, M., Nejmeh, В., and Riddle, W. February 1990. Software Engineering Practices in Europe, Japan, and the U.S. Boulder, Colorado Software Design and Analysis.

Dreger, B. 1989. Function Point Analysis. Englewood Cliffs, NJ: Prentice-Hall.

Eastman, N. 1984. Software Engineering and Technology. Technical Directions vol.10(1). Bethesda, MD: IBM Federal Systems Division.

Fagan, M. June 1976. Design and Code Inspections and Process in the Development of Programs. IBM-TR-00.73.

Foster, C. 1981. Real-Time Programming. Reading, MA: Addison-Wesley.

Freedman, D. February 1992. The Devil Is in the Details Everything Important Must be Reviewed. American Programmer vol.5(2).

Freeman, P. 1975. Software Systems Principles. Chicago, IL: Science Research Associates.

Freeman, P., and Wasserman, A. eds. 1983. Tutorial on Software Design Techniques. Fourth Edition. New York, NY: Computer Society Press of the IEEE.

Gehani, N. and McGettrick, A. 1986. Software Specification Techniques. Reading, Massachusetts:

Addison-Wesley Publishing Company.

Gilb, T. 1988. Principles of Software Engineering Management. Reading, Massachusetts: Addison-Wesley Publishing Company.

Glass, R. 1982. Modem Programming Practices: A Report from Industry. Englewood Cliffs, NJ: Prentice-Hall.
-- 1983. Real-Time Software. Englewood Cliffs, NJ: Prentice-Hall.
-- 1991. Software Conflict. Englewood Cliffs, NJ: Yourdon Press.

Goldberg, A. and Rubin, K. 1992. Tutorial on Object-oriented Project Management. Vancouver, Canada: OOPSLA'92.

Guengerich, S. 1992. Downsizing In formation Systems. Carmel, Indiana: Sams.

Guindon, R., Krasner, H., and Curtis, B. 1987. Breakdowns and Processes During the Early Activities of Software Design by Professionals. Empirical Studies of Programmers, Second Workshop. Norwood, New Jersey: Ablex Publishing Company.

Guttman, M. and Matthews, J. November/December 1992. Managing a Large Project. Object Magazine vol.2(4).

Hansen, P. 1977. The Architecture of Concurrent Programs. Englewood Cliffs, NJ: Prentice-Hall.

Henderson-Sellers, B. and Edwards, J. September 1990. The Object-oriented Systems Lifecycle. Communications of the ACM vol.33(9).

Hoare, C. April 1984. Programming: Sorcery or Science? IEEE Software vol.1(2).

Holt, R., Lazowska, E., Graham, G., and Scott, M. 1978. Structured Concurrent Programming. Reading, MA: Addison-Wesley.

Humphrey, W. 1988. Characterizing the Software Development Process: A Maturity Framework. IEEE Software vol.5(2).
-- 1989. Managing the Software Process. Reading, MA: Addison-Wesley. Jackson, M. 1975. Principles of Program Design. Orlando, FL: Academic Press.
-- 1983. System Development. Englewood Cliffs, NJ: Prentice-Hall.

Jensen, R., and Tonies, C. 1979. Software Engineering. Englewood Cliffs, NJ: Prentice-Hall.

Jones, C. September 1984. Reusability in Programming: A Survey of the State of the Art. IEEE Transactions on Software Engineering vol.SF-10 (5).
-- September 1992. Risky Business: The most Common Software Risks. American Programmer vol.5(7).

Karam, G. and Casselman, R. February 1993. A Cataloging Framework for Software Development Methods. IEEE Computer.

Kishida, K., Teramoto, M., Torri, K., and Urano, Y. September 1988. Quality Assurance Technology in Japan. IEEE Software vol.4(5).

Lammers, S. 1986. Programmers at Work. Redmond, WA: Microsoft Press.

Laranjeira, L. May 1990. Software Size Estimation of Object-Oriented Systems. IEEE Transactions on Software Engineering vol.16(5).

Ledgard, H. Summer 1985. Programmers: The Amateur vs. the Professional. Abacus vol.2(4).

Lejter, M., Myers, S., and Reiss, S. December 1992. Support for Maintaining Object-Oriented Programs. IEEE Transactions on Software Engineering vol. 18(12).

Linger, R., and Mills, H. 1977. On the Development of Large Reliable Programs, in Current Trends in Programming Methodology: Software Specification and Design vol.1. ed. R. Yeh. Englewood Cliffs, NJ: Prentice-Hall.

Linger, R., Mills, H., and Witt, B. 1979. Structured Programming. Theory and Practice. Reading, MA: Addison-Wesley.

Liskov, B. and Guttag, J. 1986. Absraction and Specification in Program Development. Cambridge, MA: The MIT Press.

Lorin, H. 1972. Parallelism in Hardware and Software. Englewool Cliffs, NJ: Prentice-Hall.

Luqi, August 1990. A Graph Model for Software Evolution. IEEE Transactions on Software Engineering vol.16(8).
-- May 1990. Software Evolution Through Rapid Prototyping. IEEE Computer vol.22(5).

Martin, J., and McClure, C. 1988. Structured Techniques: The Basis for CASE. Englewood Cliffs, NJ: Prentice-Hall.

Mascot, Version 3.1, The Official Handbook of. June 1987. London, England: Crown Copyright. Matsubara, T. July/August 1990. Bringing up Software Designers. American Programmer vol.3(7-8).

McCabe, Т. and Butler, C. December 1989. Design Complexity Measurement and Testing. Communications of the ACM vol.32(12).

Mellichamp, D. 1983. Real-Time Computing. New York, NY: Van Nostrand Reinhold.

Mills, H. November 1986. Structured Programming: Retrospect and Prospect. IEEE Software vol.3(6).

Mills, J. July 1985. A Pragmatic View of the System Architect. Communications of the ACM vol.28(7).

Mimno, P. April 1993. Client-Server Computing. American Programmer, Arlington MA: Cutter Information Corporation.

Mullin, M. 1990. Rapid Prototyping for Object-oriented Systems. Reading, Massachusetts: Addison-Wesley Publishing Company.

Munck, R. 1985. Toward Large Software Systems That Work. Proceedings of The AlAA/ACM/ NASA/IEEE Computers in Aerospace V Conference. Menlo Park, CA: AIAA.

Myers, G. 1978. Composite/Structured Design. New York, NY: Van Nostrand Reinhold. Newport, J. 28 April 1986. A Growing Gap in Software. Fortune.

Ng, P. and Yeh, R. 1990. Modem Software Engineering. New York, New York: Van Nostrand Reinhold.

Office of the Under Secretary of Defense for Acquistion. September 1987. Report of the Defense Science Board Task on Military Software. Washington, D. C.

Oman, P. and Lewis, T. 1990. Milestones in Software Evolution. Los Alamitos, California: Computer Society Press of the IEEE.

Orr, K. 1971. Structured Systems Development. New York, NY: Yourdon Press.

Page-Jones, M. 1988. The Practical Guide to Structured Systems Design. Englewood Cliffs, NY: Yourdon Press.

Parnas, D. December 1985. Software Aspects of Strategic Defense Systems. Communications of the ACM vol.28(12).

-- July 1985a. Why Conventional Software Development Does Not Produce Reliable Programs. Software Aspects of Strategic Defense Systems, Report DCS-47-IR. Victoria, Canada: University of Victoria.

-- July 1985b. Why Software is Unreliable. Software Aspects of Strategic Defense Systems, Report DCS-47-IR. Victoria, Canada: University of Victoria.

Parnas, D. and Clements, P. 1986. A Rational Design Process: How and Why to Fake It. IEEE Transactions on Software Engineering vol.SE-12(2).

Peters, L. 1981. Software Design. New York, NY: Yourdon Press. Pressman, R. 1988. Making Software Happen. Englewood Cliffs, New Jersey: Prentice-Hall.
-- 1992. Software Engineering: A Practitioner's Approach, Third Edition. New York, NY: McGraw-Hill Book Company.

Rakos, J. 1990. Software Project Management for Small to Medium Sized Projects. Englewood Cliffs, New Jersey: Prentice-Hall.

Ramamoorthy, C., Garg, V., and Prakask, A. July 1986. Programming in the Large. IEEE Transactions on Software Engineering vol.SE-12(7).

Rechtin, E. October 1992. The Art of Systems Architecting. IEEE Spectrum vol.29(10). Rettig, M. October 1990. Software Teams. Communications of the ACM vol.33(10).

Ross, D., Goodenough, J., and Irvine, C. 1980. Software Engineering: Process, Principles, and Goals. Tutorial on Software Design Techniques, 3rd Ed. ed. P. Freeman and A. Wasserman. New York, NY: Computer Society Press of the IEEE.

Rubinstein, R. and Hersh, H. 1984. The Human Factor. Burlington, Massachusetts Digital Press.

Schulmeyer, G. and McManus, J. 1992. Handbook of Software Quality Assurance, Second Edition. New York, New York: Van Nostrand Reinhold.

Shaw, M. November 1990. Prospects for an Engineering Discipline of Software. IEEE Software vol.7(6).

Smith, M. and Robson, D. June 1992. A Framework for Testing Object-oriented Programs. Journal of Object-oriented Programming vol.5(3).

Software Process Workshop. May 1988. SIGSOFT Software Engineering Notes vol.14(4). Sommerville, I. 1989. Software Engineering, 3rd ed. Wokingham, England: Addison-Wesley.

Song, X., and Osterweil, L. 1993. Executing an Iterative Design Process. Irvine, California: University of California.

Spector, A., and Gifford, D. April 1986. Computer Science Perspective of Bridge Design. Communications of the ACM vol.29(4).

Stevens, W., Myers., G., and Constantine, L. 1979. Structured Design, in Classics in Software Engineering, ed. E. Yourdon. New York, NY: Yourdon Press.

Symons, C. 1988. Function Point Analysis: Difficulties and Improvements. IEEE Transactions on Software Engineering vol.14(1).

Taylor, D. 1990. Object-Oriented Technology A Manager's Guide. Alameda, California: Servio Corporation.

The Software Trap: Automate - Or Else. 9 May. 1988. Business Week. Thomsett, R. July/August 1990. Effective Project Teams. American Programmer vol. 3(7-8).
-- June 1991. Managing Superlarge Projects: A Contingency Approach. American Programmer vol.4(6).

U. S. Department of Defense. 30 July 1982. Report ofthe DoD Joint Service Task Force on Software Problems. Washington, D.C.

van Genuchten, M. June 1991. Why is Software Late? An Empirical Study of Reasons for Delay in Software Development. IEEE Transactions on Software Engineering vol.17(6).

Vick, С., and Ramamoorthy, C. 1984. Software Engineering. New York, NY: Van Nostrand Reinhold. Vonk, R. 1990. Prototyping. Englewood Cliffs, NJ: Prentice-Hall.

Walsh, J. Preliminary Defect Data from the Iterative Development of a Large C+ + Program. Vancouver, Canada: OOPSLA'92.
-- January 1993. Software Quality in an Iterative Object-Oriented Development Paradigm. Santa Clara, California: Rational.

Ward, M. 1990. Software that Works. San Diego, California: Academic Press.

Ward, P., and Mellor, S. 1985. Structured Development for Real-Time Systems: Introduction and Tools. Englewood Cliffs, NJ: Yourdon Press.

Wegner, P. 1980. Research Directions in Software Technology. Cambridge, MA: The MIT Press.
-- July 1984. Capital-intensive Software Technology. IEEE Software vol.1(3).

Weinberg, G. 1988. Understanding the Professional Programmer. New York, New York: Dorset House Publishing.

Weinberg, G. and Freedman, D. 1990. Handbook of Walkthroughs, Inspections, and Technical Reviews. New York, New York: Dorset House.

Whitten, N. 1990. Managing Software Development Projects. New York, New York: John Wiley and Sons.

Wilde, N. and Huitt, R. December 1992. Maintenance Support for Object-Oriented Programs. IEEE Transactions on Software Engineering vol.18(12).

Wilde, N., Matthews, P. and Huitt, R. January 1993. Maintaining Object-oriented Software. IEEE Software vol.10(1).

Wirth, N. 1986. Algorithms and Data Structures. Englewood Cliffs, NJ: Prentice-Hall.

Workshop on Software Configuration Management. November 1989. SIGSOFT Software Engineering Notes vol.17(7).

Yamaura, T. January 1992. Standing Naked in the Snow. American Programmer vol.5(1).

Yeh, R. ed. 1977. Current Trends in Programming Methodology: Software Specification and Design. Englewood Cliffs, NJ: Prentice-Hall.

Yourdon, E. 1975. Techniques of Program Structure and Design. Englewood Cliffs, NJ: Prentice-Hall.
-- 1979. ed. Classics in Software Engineering. New York, NY: Yourdon Press.
-- 1989a. Modem Structured Analysis. Englewood Cliffs, NJ: Prentice-Hall.
-- 1989b. Structured Walkthroughs. Englewood Cliffs, NJ: Prentice-Hall.
-- August 1989с. The Year of the Object. Computer Language vol.6(8).
-- Summer 1989d. Object-oriented Observations. American Programmer vol.2(7-8).

Yourdon, E., and Constantine, L. 1979. Structured Design. Englewood Cliffs, NJ: Prentice-Hall.

Zahniseer, R. July/August 1990. Building Software in Groups. American Programmer vol.3(7-8).

Zave, P. February 1984. The Operational versus the Conventional Approach to Software Development. Communications of the ACM vol.27(2).

Zeikowitz, M. June 1978. Perspectives on Software Engineering. ACM Computing Surveys vol.10(2).

I. Специальная литература

Alexander, С. 1979. The Timeless Way of Building. New York, New York: Oxford University Press.

DeGrace, P. and Stahl, L. 1990. Wicked Problems, Righteous Solutions. Englewood Cliffs, New Jersey: Yourdon Press.

Fukuyama, F. 1992. The End of the Last Man. New York, New York: The Free Press.

Gall., J. 1986. Systemantics: How Systems Really Work and How They Fail. 2nd ed. Ann Arbor, MI: The General Systemantics Press.

Gleick, J. 1987. Chaos. New York, NY: Penguin Books.

Heckbert, P. 1988. Ray Tracing Jell-O Brand Gelatin. Communications of the ACM vol.31(2).

Heinlein, R. 1966. The Moon Is a Harsh Mistrres. New York, NY: The Berkeley Publishing Group.

Hofstadter, D. 1979. Godel, Escher, Bach: An Eternal Golden Braid. New York, NY: Vintage Books.

Inside Macintosh Volumes 1-5. 1988. Reading, MA: Addison-Wesley.

Kawasaki, G. 1990. The Macintosh Way. Glenview, Illinois Scott, Foresman and Company.

Lakoff, G. and Johnson, M. 1980. Metaphors We Live By. Chicago, Illinois: The University of Chicago Press.

Lammers, S. 1986. Programmers at Work. Bellevue, Washington, Microsoft Press.

Meyer, C., and Matyas. 1982. Cryptography. New York, NY:John Wiley and Sons.

Parker, T. 1983. Rules of Thumb. Boston, Massachusetts: Houghton Mifflin Company.

Peter, L. 1986. The Peter Pyramid. New York, NY: William Morrow.

Petroski, H. 1985. To Engineer Is Human. New York, NY: St. Martin's Press.

Rand, Ayn. 1979. Introduction to Objectivist Epistemology. New York, NY: New American Library.

Reti. L. 1988. The Unknown Leonard. New York, New York: Abradale Press.

Sears, F., Zemansky, M., and Young., H. 1987. University Physics. Seventh ed. Reading, MA: Addison-Wesley.

vonOech, R. 1990. A Whack on the Side of the Head. New York, New York: Warner Books, Incorporated.

Wagner, J. 1986. The Search for Signs of Intelligent Life in the Universe. New York, NY: Harper and Row.

Whitehead, A. 1958. An Introduction to Mathematics. New York, NY: Oxford University Press.

J. Теория

Aho, A., Hopcroft, J., and Ullman, J. 1974. The Design and Analysis of Computer Programs. Reading, MA: Addison-Wesley.

Almarode, J. October 1989. Rule-Based Delegation for Prototypes. SIGPLAN Notices vol.24(10).

Appelbe, W. and Ravn, A. April 1984. Encapsulation Constructs in Systems Programming Languages. ACM Transactions on Programming Languages and Systems vol.6(2).

Averill, E. April 1982. Theory of Design and Its Relationship to Capacity Measurement. Proceedings of the Fourth Annual International Conference on Computer Capacity Management. San Francisco, CA: Association of Computing Machinery.

Barr, A., and Feigenbaum, E. 1981. The Handbook of Artificial Intelligence. Los Altos, CA: William Kaufmann.

Bastani, F., and Iyengar, S. March 1987. The Effect of Data Structures on the Logical Complexity of Programs. Communications of the ACM vol.30 (3)

Bastani, F., Hilal, W., and Sitharama, S. October 1987. Efficient Abstract Data Type Components for Distributed and Parallel Systems. IEEE Computer vol.20(10).

Belkhouche, В., and Urban, J. May 1986. Direct Implementation of Abstract Data Types from Abstract Specifications. IEEE Transactions on Software Engineering vol.SE-12(5).

Bensley, E., Brando, Т., and Prelle, M. September 1988. An Execution Model for Distributed Object-Oriented Computation. SIGPLAN Notices vol. 23(11).

Berztiss, A. 1980. Data Abstraction, Controlled Iteration and Communicating Processes. Communications of the ACM.

Bishop, J. 1986. Data Abstraction in Programming Languages. Wokingham, England: Addison-Wesley.

Boehm, H., Demers, A., and Donahue, J. October 1980. An Informal Description of Russell. Technical Report TR 80-430. Ithaca, NY: Cornell University.

Borning, A., Duisberg, R., Freeman-Benson, В., Kramer. A., and Woolf, M. October 1987. Constraint Hierarchies. SIGPLAN Notices vol.22(12).

Boute, R. January 1988. Systems Semantics: Principles, Applications, and Implementation. ACM Transactions on Programming Languages and Systems vol.10(1).

Brachman, R. October 1983. What Is-a Is and Isn't: An Analysis of Taxonomic Links in Semantic Networks. IEEE Computer vol.16(10).

Brachman, R., and Levesque, H. eds. 1985. Readings in Knowledge Representation. Los Altos, CA: Morgan Kaufmann.

Brooks, R. April 1987. Intelligence without Representation. Cambridge, Massachusetts: MIT Artificial Intelligence Laboratory.

Bruce, K., and Wegner, P. October 1986. An Algebraic Model of Subtypes in Object-Oriented Languages. SIGPLAN Notices vol.21(10).

Card, S., Moran, Т., nad Newell, A. 1983. The Psychology of Human-Computer Interaction. Hillsdale, New Jersey: Lawrence Erlbaum Associates.

Cardelli, L, and Wegner, P. December 1985. On Understanding Types, Data Abstraction, and Polymorphism. ACM Computing Surveys vol.17(4).

Claybrook, В., and Wyckof, M. 1980. Module: an Encapsulation Mechanism for Specifying and Implementing Abstract Data Types. Communications of the ACM.

Cline, A., and Rich, E. December 1983. Building and Evaluating Abstract Data Types, Report TR-83-26. Austin, TX: University of Texas, Department of Computer Sciences.

Cohen, A. January 1984. Data Abstraction, Data Encapsulation, and Object-oriented Programming. SIGPLAN Notices vol.19(1).

Cohen, N. November/December 1985. Tasks as Abstraction Mechanisms. Ada Letters vol.5(3-6).

Cohen, P., and Loiselle, C. August 1988. Beyond ISA: Structures for Plausible Inherence in

Semantic Nets. Proceedings of the Seventh National Conference on Artificial Intelligence. Saint Paul, MN: American Association for Artificial Intelligence.

Collins, W. 1992. Data Structures: An Object-oriented Approach. Reading, Massachusetts: Addison-Wesley Publishing Company.

Cook, W., and Palsberg, J. October 1989. A Denotational Semantics of Inheritance and Its Correctness. SIGPLAN Notices vol.24(10).

Courtois, P., Heymans, F., and Parnas, D. October 1971, Concurrent Control with "Readers" and "Writers." Communications of the ACM vol.14(10).

Danforth, S., and Tomlinson, C. March 1988. Type Theories and Object-oriented Programming. ACM Computing Surveys vol.20(1).

Demers, A., Donahue, J., and Skinner, G. Data Types as Values: Polymorphism, Type-Checking, Encapsulation. Proceedings of the Fifth Annual ACM Symposium on Principles of Programming Languages. New York, NY: Association of Computing Machinery.

Dennis, J., and Van Horm, E. March 1966. Programming Semantics for Multiprogrammed Computations. Communications of the ACM vol.9(3).

Donahue, J., and Demers, A. July 1985. Data Types Are Values. ACM Transactions on Programming Languages and Systems vol.7(3).

Eckart, J. April 1987. Iteration and Abstract Data Types. SIGPLAN Notices vol.22(4).

Embley, D., and Woodfield, S. 1988. Assessing the Quality of Abstract Data Types Written in Ada. Proceedings of the 10th International Conference on Software Engineering. New York, NY: Computer Society Press of the IEEE.

Ferber, J. October 1989. Computational Reflection in Class-Based Object-oriented Languages. SIGPLAN Notices vol.24(10).

Fisher, J. and Gipson, D. November 1992. In Search of Elegance. Computer Language vol.9(11).

Gannon, J. Hamlet, R., and Mills, H. July 1987. Theory of Modules. IEEE Transactions on Software Engineering vol.SE-13(7).

Gannon, J., McMullin, P., and Hamlet, R. July 1981. Data Abstraction Implementation, Specification, and Testing. ACM Transactions on Programming Languages and System vol.3(3).

Gardner, M. May/June 1984. When to Use Private Types. Ada Letters vol.3(6).

Goguen, J. Thatcher, J., and Wagner, E. 1977. An Initial Algebra Approach to the Specification, Correctness, and Implementation of Abstract Data Types, in Current Trends in Programming Methodology: Data Structuring vol. ed. R. Yeh. Englewood Cliffs, NJ: Prentice-Hall.

Goldberg, D. 1989. Genetic Algorithms. Reading, Massachusetts: Addison-Wesley Publishing Company.

Graube, N. October 1989. Metaclass Compatibility. SIGPLAN Notices vol.24(10).

Gries, D., and Prins, J. July 1985. A New Notion of Encapsulation. SIGPLAN Notices vol.20(7).

Grogono, P., and Bennett, A. November 1989. Polymorphism and Type Checking in Object-oriented Language. SIGPLAN Notices vol.24(11).

Guttag, J. 1980. Abstract Data Types and the Development of Data Sructures, in Programming Language Design, ed. A. Wasserman. New York, NY: Computer Society Press of the IEEE.

Hammons, C., and Dobbs, P. May/June 1985. Coupling, Cohesion, and Package Unity in Ada. Ada Letters vol.4(6). I

Harel, D. and Kahana, C. October 1992. On Statecharts with Overlapping. ACM Transactions on Software Engineering and Methodology vol.1(4).

Harel, D., Lachover, H., Naamad, A., Pnueli, A., Politi, M., Sherman, R. Shtull-Trauring, S., and Trakhtenbrot, M. April 1990. STATEMATE: A Working Environment for the Development of Complex Reactive Systems. IEEE Transactions on Software Engineering vol.16(4).

Harrison G., and Liu, D. July/August 1986. Generic Implementations Via Analogies in the Ada Programming Language. Ada Letters vol.6(4).

Hayes, P. 1981. The Logic of Frames, in Readings in Artificial Intelligence, ed. B. Webber and N. Nilsson. Palo Alto, CA: Tioga.

Hayes-Roth, F., July 1985. A Backboard Architecture for Control. Artificial Intelligence vol.26(3).

Hayes-Roth, F., Waterman, D., and Lenat, D 1983. Building Expert Systems. Reading, MA: Addison-Wesley.

Haynes, C., and Friedman, D. October 1987. Embedding Continuations in Procedural Objects. ACM Transactions on Programming Languages and Systems vol.9(4).

Henderson, P. February 1986. Functional Programming, Formal Specification, and Rapid Prototyping. IEEE Transactions on Software Engineering vol.SE-12(2).

Herlihy, M., and Liskov, B. October 1982. A Value Transmission Method for Abstract Data Types. ACM Transactions on Programming Languages and Systems vol.4(4).

Hesselink, W. January 1988. A Mathematical Approach to Nondeterminism in Data Types. ACM Transactions on Programming Languages and Systems vol.10(1).

Hibbard, P., Hisgen, A., Rosenberg, J., Shaw, M., and Sherman, M. 1981. Studies in Ada Style. New York, NY: Springer-Verlag.

Hilfinger, P. 1982. Abstraction Mechanisms and Language Design. Cambridge, MA: The MIT Press.

Hoare, C. October 1974. Monitors: An Operating System Structuring Concept. Communications of the ACM vol.17(10).

Hoare, C. 1985. Communicating Sequential. Processes Englewood Cliffs, NJ: Prentice-Hall International. Hogg, J., and Weiser, S. October 1987. OTM: Applying Objects to Tasks. SIGPLANNotices vol.22(12).

Jajodia, S., and Ng. P. 1983. On Representation of Relational Structures by Entity-Relationship Diagrams, in Entity-Relationship Approach to Software Engineering, ed. C. Davis et al. Amsterdam, The Netherlands: Elsevier Science.

Johnson, C., 1986. Some Design Constraints Required for the Assembly of Software Components: The Incorporation of Atomic Abstract Types into Generically Structured Abstract Types. Proceedings of the First International Conference on Ada Programming. Language Applications for the NASA Space Station. Houston, TX: NASA Lyndon B. Johnson Space Center.

Kernighan, B. and Plauger, P. 1981. Software Tools in Pascal. Reading, MA: Addison-Wesley.

Knight, B. 1983. A Mathematical Basis for Entity Analysis, in Entity-Relationship Approach to Software Engineering, ed. C. Davis et al. Amsterdam, The Netherlands: Elsevier Science.

Knuth, D. 1973. The Art of Computer Programming, Vol.1-3. Reading, MA: Addison-Wesley.

Kosko, B. 1992. Neural Networks and Fuzzy Systems. Englewood Cliffs, New Jersey: Prentice-Hall Incorporated.

LaLonde, W., and Pugh, J. August 1985. Specialization, Generalization, and Inheritance: Teaching Objectives Beyond Data Stmctures and Data Types. SIGPLAN Notices vol.20(8).

Leeson, J., and Spear, M. March 1987. Type-Independent Modules: The Preferred Approach to Generic ADTs in Modula-2. SIGPLAN Notices vol.22(3).

Lenzerini, M., and Santucci, G. 1983. Cardinality Constraints in the Entity-Relationship Model, in Entity-Relationship Approach to Software Engineering, ed. C. Davis et al. Amsterdam, The Netherlands: Elsevier Science.

Levesque, H. July 1984. Foundations of a Functional Approach to Knowledge Representation. Artificial Intelligence vol.23(2).

Lindgreen, P. 1983. Entity Sets and Their Description, in Entity-Relationship Approach to Software Engineering, ed. C. Davis et al. Amsterdam, The Netherlands: Elsevier Science.

Lins, C. 1989. A First Look at Literate Programming. Structured Programming. Liskov, B. May 1988. Data Abstraction and Hierarchy. SIGPLAN Notices vol.23(5).
-- 1980. Programming with Abstract Data Types, in Programming Language Design, ed. A. Wasserman. New York, NY: Computer Society Press of the IEEE.

Liskov, В., and Scheifler, R. July 1983. Guardians and Actions: Linguistic Support for Robust, Disttibuted Programs. ACM Transactions on Programming Languages and Systems vol.5(3).

Liskov, В., and Zilles, S. 1977. An Introduction to Formal Specifications of Data Abstractions, in Current Trends in Programming Methodology: Software Specification and Design vol.1. ed. R. Yeh. Englewood Cliffs, NJ: Prentice-Hall.

Lowry, M. and McCartney. 1991. Automating Software Design. Cambridge, Massachusetts: The MIT Press.

Lucco, S. October 1987. Parallel Programming in a Virtual Object Space. SIGPLANNotices vol.22(12).

Maes, P. October 1987. Concepts and Experiments in Computational Reflection. SIGPLAN Notices vol.22(12).

Mark, L. 1983. What is the Binary Relationship Approach?, in Entity-Relationship Approach to Software Engineering, ed. C. Davis et al. Amsterdam, The Netherlands: Elsevier Science.

Markowitz, V., and Raz, Y. 1983. A Modified Relational Algebra and Its Use in an Entity-Relationship Environment, in Entity-Relationship Approach to Software Engineering, ed. C. Davis et al. Amsterdam, The Netherlands: Elsevier Science.

Matsuoka, S., and Kawai, S. September 1988. Using Tuple Space Communication in Distributed Object-Oriented Languages. SIGPLAN Notices vol.23(11).

McAllester, D., and Zabih, F. November 1986. Boolean Classes. SIGPLAN Notices vol.21(11). McCullough, P. October 1987. Transparent Forwarding: First Steps. SIGPLAN Notices vol.22(12).

Merlin, P., and Bochmanm, G. January 1983. On the Construction of Submodule Specifications and Communication Protocols. ACM Transactions on Programming Languages and Systems vol.5(1).

Meyer, B. 1987. Programming as Contracting, Report TR-EI-12/CO. Goleta, CA: Interactive Software Engineering.
-- October 1992. Applying "Design by Contract." IEEE Computer vol.25(10).

Minoura, Т., and Lyengar, S. January 1989. Data and Time Abstraction Techniques for Multilevel Concurrent Systems. IEEE Transactions on Software Engineering vol.15(1).

Murata, T. 1984 Modeling and Analysis of Concurrent Systems, in Software Engineering, ed. C. Vick and C. Ramamoorthy. New York, NY: Van Nostrand Reinhold.

Mylopoulos, J., and Levesque, H. 1984. An Overview of Knowledge Representation. On Conceptual Modeling: Perspectives from Artificial Intelligence, Databases and Programming Languages, ed. M. Brodie. J. Mylopoulos, and J. Schmidt. New York, NY: Springer-Verlag.

Nakano, R. 1983. Integrity Checking in a Logic-Oriented ER Model, in Entity-Relationship Approach to Software Engineering, ed. C. Davis et al. Amsterdam, The Netherlands: Elsevier Science.

Newton, M., and Watkins, J. November/December 1988. The Combination of Logic and Objects for Knowledge Representation. Journal of Object-Oriented Programming vol.1(4).

Nii, P. Summer 1986. Blackboard Systems: The Blackboard Model of Problem Solving and the Evolution of Blackboard Architectures. AI Magazine vol.7(2).

Ohori, A., and Buneman., P. October 1989. Static Type Inference for Parametric Classes. SIGPLAN Notices vol.24(1O).

Pagan, F. 1981. Formal Specification of Programming Language. Englewood Cliffs, NJ: Prentice-Hall.

Parent, C., and Spaccapieta, S. July 1985. An Algebra for a General Entity-Relationship Model. IEEE Transactions on Software Engineering vol.SE-II(7).

Parnas, D. 1977. The Influence of Software Structure on Reliability, in Current Trends in Programming Methodology: Software Specification and Design vol.1. ed. R. Yeh. Englewood Cliffs, NJ: Prentice-Hall.
-- 1980. Designing Software for Ease of Extension and Contraction, in Tutorial on Software Design Techniques, 3rd ed. ed. P. Freeman and A. Wasserman. New York, NY: Computer Society Press of the IEEE.

Parnas, D., Clements, P., and Weiss, D. 1983. Enhancing Reusability with Information Hiding. Proceedings of the Workshop on Reusability in Programming, Stratford, CT: ITT Programming.

Pattee, H. 1973 Hierarchy Theory. New York, NY: George Braziller.

Peckham, J., and Maryanski, F. September 1988. Semantic Data Models. ACM Computing Surveys vol.20(3).

Pedersen, С. October 1989. Extending Ordinary Inheritance Schemes to Include Generalization. SIGPLAN Notices vol.24(10).

Peterson., J. September 1977. Petri Nets. Computing Surveys vol.9(3). Reed, D. September 1978. Naming and Synchronization in a System. Cambridge, MA: The MIT Press.

Rich, C. and Wills, L. January 1990. Recognizing a Program's Design: A Graph-Parsing Approach. IEEE Software vol.7(1).

Robinson, L., and Levitt, K. 1977. Proof Techniques for Hierarchically Structured Programs, in Current Trends in Programming Methodology: Program Validation vol.2. ed. R. Yeh. Englewood Cliffs, NJ: Prentice-Hall.

Ross, D. July/August 1986. Classifying Ada Packages. Ada Letters vol.6(4).

Ruane, L. January 1984. Abstract Data Types in Assembly Language Programming. SIGPLAN Notices vol.19(1).

Rumbaugh, J. September 1988. Controlling Propagation of Operations Using Attributes on Relations. SIGPLAN Notices vol.23(11).

Sedgewick, R. 1983. Algorithms. Reading, MA: Addison-Wesley.

Shankar, K. 1984. Data Design: Types, Structures, and Abstractions, in Software Engineering, ed. C. Vick and C. Ramamoorthy. New York, NY: Van Nostrand Reinhold.

Shaw, M. 1984. The Impact of Modeling and Abstraction Concerns on Modern Programming Languag0.85troduction to Data Types, in Programming Language Design, ed. A. Wasserman. New York, NY: Computer Society Press of the IEEE.

Sherman, M., Hisgen, A., and Rosenberg, J. 1982. A Methodology for Programming Abstract Data Types in Ada. Proceedings of The AdaTec Conference on Ada. New York. NY: Association of Computing Machinery.

Siegel, J. April 1988. Twisty Little Passages. HOOPLA: Hooray for Object-Oriented Programming Languages vol.1(3). Everette, WA: Object-Oriented Programming for Smalltalk Application Developers Association.

Stefik, M., Bobrow, D., and Kahn, K. January 1986. Integrating Access-Oriented Programming into a Multiparadigm Environment. IEEE Software vol.3(1).

Storm, R., and Yemini, S. January 1986. Typestate: A Programming Language Concept for Enhancing Software Reliability. IEEE Transaction on Software Engineering vol.SE-12(1).

Stubbs, D., and Webre, N. 1985. Data Structures with Abstract Data Types and Pascal. Monterey, CA: Broocs/Cole.

Swaine, M. June 1988. Programming Paradigms. Dr. Dobb's Journal of Software Tools, no. 140.

Tabourier, Y. 1983. Further Development of the Occurrences Structure Concept: The EROS Approach, in Entity-Relationship Approach to Software Engineering, ed. C. Davis et al. Amsterdam, The Netherlands: Elsevier Science.

Tanenbaum, A. 1981. Computer Networks. Englewood Cliffs, NJ: Prentice-Hall. Throelli, L. October 1987. Modules and Type Checking in PL/LL. SIGPLAN Notices vol.22(12).

Tomlinson, C. and Singh, V. October 1989. Inheritance and Synchronization with Enabled-sets. SIGPLAN Notices vol.24(10).

Toy, W. 1984. Hardware/Software Tradeoffs in Software Engineering. Ed. C. Vick and C. Ramamoorthy. New York, NY: Van Nostrand Reinhold.

Vegdahl, S. November 1986. Moving Structures between Smalltalk Images. SIGPLAN Notices vol.21(11).

Walters, N. October 1992. Using Harel Statecharts to Model Object-oriented Behavior. SIGSOFT Notices vol.17(4).

Wasserman, A. 1980. Introduction to Data Types, in Programming Language Design, ed. A. Wasserman. New York, NY: Computer Society Press of the IEEE.

Weber, H., and Ehrig, H. July 1986. Specification of Modular Systems. IEEE Transactions on Software Engineering vol.SE-12(7).

Wegner, P. June 1981. The Ada Programming Language and Environment. Unpublished draft.

Wegner, P. 1987. On the Unification of Data and Program Abstraction in Ada, in Object-oriented Computing: Concepts vol.1. ed. G. Peterson. New York. NY: Computer Society Press of the IEEE.

Wegner, P. 1987. The Object-oriented Classification Paradigm, in Research Directions in Object-oriented Programming. ed. B. Schriver and P. Wegner. Cambridge, MA: The MIT Press.

Wegner, P., and Zdonik, S. August 1988. Inheritance as an Incremental Modification Mechanism or What Like Is and Isn't Like. Proceedings of ECOOP'88: European Conference on Object-oriented Programming. New York, NY: Springer-Verlag.

Weihl, W., and Liskov, B. April 1985. Implementation of Resilient, Atomic Data Types. ACM Transactions on Programming Languages and Systems vol. 7(2).

Weinberg, G. 1971. The Psychology of Computer Programming. New York: Van Nostrand / Reinhold Company.

Weller, D., and York, B. May 1984. A Relational Representation of an Abstract Type System. IEEE Transactions on Software Engineering vol.SE-10(3).

White, J. July 1983. On the Multiple Implementation of Abstract Data Types within a Computation. IEEE Transactions on Software Engineering vol. SE-9(4).

Wirth, N. December 1974. On the Composition of Well-structured Programs. Computing Surveys vol.6(4).
-- January 1983. Program Development by Stepwise Refinement. Communications of the ACM vol.26(1).
-- 1986. Algorithms and Data Structures, Second Edition. Englewood Cliffs, NJ: Prentice-Hall.
-- April 1988. Type Extensions. ACM Transactions on Programming Languages and Systems vol.10(2).

Wolf, A., Clarke, L., and Wileden, J. April 1988. A Model of Visibility Control. IEEE Transactions on Software Engineering vol.14(4).

Woods, W. October 1983. What's Important About Knowledge Representation? IEEE Computer vol.16(10).

Zilles, S. 1984. Types, Algebras, and Modelling, in On Conceptual Modeling: Perspectives from Artificial Intelligence, Databases, and Programming Languages, ed. M. Brodie, J. Mylopoulos, and J. Schmidt. New York, NY: Springer-Verlag.

Zippel, R. June 1983. Capsules. SIGPLAN Notices vol.18(6).

K. Инструменты и среды разработки

Andrews, Т., and Harris, С. 1987. Combining Language and Database Advances in an Object- Oriented Development Environment. Billerica, MA: Ontologic.

Corradi, A., and Leonardi, L. 1986. An Environment Based on Parallel Objects. Bologna, Italy: Universita' di Bologna.

Deutsch, P., and Taft, E. June 1980. Requirements for an Experimental Programming Environment. Report CSL-80-10. Palo Alto, CA: Xerox Palo Alto Research Center.

Diederich, J., and Milton, J. October 1987. An Object-Oriented Design System Shell. SIGPLAN Notices vol.22(12).

Durant, D., Carlson, G., and Yao, P. 1987. Programmers Guide to Windows. Berkeley, CA: Sybex.

Ertman, L, Lark, J., and Hayes-Roth, F. December 1988. ABE: An Environment for Engineering Intelligent Systems. IEEE Transactions on Software Engineering vol.14(12).

Ferrel, P., and Meyer, R. October 1989. Vamp: The Aldus Application Framework. SIGPLAN Notices vol.24(10).

Fischer, H., and Martin, D. 1987. Integrating Ada Design Graphics into the Ada Software Development Process. Encino, CA: Mark V Business Systems.

Goldberg, A. 1984a. Smalltalk-80: The Interactive Programming Environment. Reading, MA: Addison-Wesley.
-- 1984b. The Influence of an Object-oriented Language on the Programming Environment, in Interactive Programming Environments, ed. B. Barstow. New York, NY: McGraw-Hill.

Goldstein, I., and Bobrow, D. March 1981. An Experimental Description-Based Programming Environment, Report CSL-81-3. Palo Alto, CA: Xerox Palo Alto Research Center.

Gorlen, K. May 1986.Object-oriented Program Support. Bethesda, MD: National Institute of Health.

Hecht, A., and Simmons, A. 1986. Integrating Automated Structured Analysis and Design with Ada Programming Support Environments. Proceedings of the First International Conference on Ada Programming Language Applications for the NASA Space Station. Houston, TX: NASA Lyndon B.Johnson Space Center.

Hedin, G., and Magnusson B. August 1988. The Mjolner Environment: Direct Interaction with Abstractions. Proceedings of ECOOP'88: European Conference on Object-oriented Programming. New York, NY: Springer-Verlag.

Hudson, S., and King, R. June 1988. The Cactic Project: Database Support for Software Environments. IEEE Transactions on Engineering vol.14(6).

International Business Machines. April 1988. Operating System/2 Seminar Proceedings, IBM OS/2 Standard Edition Version 1.1, IBM Operating System/2 Update, Presentation Manager. Boca Ration, FL.

Kant, E. 26 March 1987. Interactive Problem Solving with a Task Configuration and Control System. Ridgefield, CT: Schlumberger-Doll Research.

Kleyn, M., and Ginrich, P. September 1988. GraphTrace - Understanding Object-oriented Systems Using Concurrently Animated Views. SIGPLAN Notices vol.23(11).

Laff, M., and Hailpern, B. July 1985. SW-2 - An Object-Based Programming Environment SIGPLAN Notices vol.20(7).

MacLenna, B. July 1985. A Simple Software Environment Based on Objects and Relations. SIGPLAN Notices vol.20(7).

Marques, J., and Guedes, P. October 1989. Extending the Operating System to Support an Object-oriented Environment. SIGPLAN Notices vol.24(10).

Minsky, N., and Rozenshtein, D. February 1988. A Software Development Environment for Law-Governed Systems. SIGPLAN Notices vol.24(2).

Moreau, D., and Dominick, W. 1987. Object-oriented Graphical Information Systems: Research Plan and Evaluation Metrics. Lafayette, LA: University of Southwestern Louisiana, Center for Advanced Computer Studies.

Nakata, S., and Yamazak, G. 1983. ISMOS: A System Based on the E-R Model and its Application to Database-Oriented Tool Generation, in Entity-Relationship Approach to Software Engineering. ed. C. Davis et al. Amsterdam, The Netherlands: Elsevier Science.

Nye, A. 1989. Xlib Programming Manual for Version 11. Newton, MA: O'Reilly and Associates.

O'Brien, P., Halbert, D., and Kilian, M. October 1987. The Trellis Programming Environment. SIGPLAN Notices vol.22(12).

Open Look Graphical User Interface Functional Specification. 1990. Reading, MA: Addison-Wesley. OSF/Motif Style Guide, Version 1.0. 1989. Cambridge, MA: Open Software Foundation.

Penedo, M., Ploedereder, E., and Thomas, I. February 1988. Object Management Issues for Software Engineering Environments. SIGPLAN Notices vol.24(2).

Reenskaug, Т., and Skaar, A. October 1989. An Environment for Literate Smalltalk Programming. SIGPLAN Notices vol.24(10).

Rosenplantt, W., Wileden, J., and Wolf, A. October 1989. OROS: Toward a Type Model for Software Development Environments. SIGPLAN Notices vol. 24(10).

Russo, V., and Campbell, R. October 1989. Virtual Memory and Backing Storage Management in Multiprocessor Operating Systems Using Object-Oriented Design Techniques. SIGPLAN Notices vol.24(10).

Scheifler, R., and Gettys, J. 1986. The X Window System. ACM Transactions on Graphics vol.63.

Schwan, K., and Matthews, J. July 1986. Graphical Views of Parallel Programs. Software Engineering Notes, vol.11(3).

Shear, D. 8 December 1988. CASE Shows Promise but Confusion Still Exists. EDN vol.33(25). Sun Microsystems. 29 March 1987. NeWS Technical Overview Mountain View, CA.

Tarumi, H., Agusa, K., and Ohno, Y. 1988. A Programming Environment Supporting Reuse of Object-oriented Software. Proceedings of the 10th International Conference on Software Engineering, New York, NY: Computer Society Press of the IEEE.

Taylor, R., Belz, F., Clarke, L, Osterweil, L, Selby, R., Wielden, J., Wolf, A., and Young, M. February 1988. Foundations for the Arcadia Environment. SIGPLAN Notices vol.24(2).

Tesler, L. August 1981. The Smalltalk Environment. Byte vol.6(8).

Vines, D., and King, T. 1988. Gaia: An Object-oriented Framework for an Ada Environment. Minneapolis, MN: Honeywell.

Weinand, A., Gamma, E., and Marty, R. 1989. Design and Implementation of ET++, a Seamless Object-oriented Application Framework. Structured Programming vol.10(2).

Wiorkowski, G., and Kull, D. 1988. DB2 Design and Development Guide. Reading, MA: Addison-Wesley.