Недоря А.Е. - Диссертация. Приложения

Введение    Глава 1    Глава 2    Глава 3    Глава 4    Заключение    Литература    Приложения

Приложения

Приложение A. Модели ООП и языки CLOS и Оберон-2

Таблица отношения моделей ООП G. Bosch [1] и B. Meyer [2] и языков программирования. Таблица взята из [5] и дополнена столбцом для языка Оберон-2.

Features: Essential Desirable Permissible Inadmissible

   

BOOP

MOOP

CLOS

O2

routines

    as free subprograms

    exclusively as methods

   

D

P

   

P

D

   

Y

N

   

Y

N

objects

    using relationships

    containing relationships

    reference semantics

    value semantics

   

E

E

P

P

   

E

E

D

D

   

Y

Y

Y

Y

   

Y

Y

Y

Y

classes

    for abstraction

    with encapsulation

    as types

    as modules

    shared variables

    metaclasses

    documentation

    assertions

    generic

   

E

E

P

n/a

P

P

P

P

P

   

E

E

E

E

D

P

D

D

D

   

Y

Y

Y

N*

Y

Y

Y

N

N

   

Y

Y

Y

N*

Y

N

Y

N

N

inheritance

    single

    multiple

    repeated

    redefinition

   

E

P

P

D

   

E

E

E

E

   

Y

Y

Y

Y

   

Y

N*

N*

Y

typing

    strong

    weak

    static

    dynamic

   

D

P

D

D

   

E

I

D

E

   

N*

Y

option

Y

   

Y

N

Y

Y

polymorphism

    overloading

    parametric

   

D

D

   

E

E

   

Y

Y

   

N

Y

exceptions

    definable

   

P

   

D

   

Y

   

N

memory management

    garbage collection

   

P

   

E

   

Y

   

Y

persistence

    time-persistent objects

    space-persistent objects

 

D

D

 

P

P

 

indir.

N

 

indirectly

indirectly

concurrency

  concurrent objects

 

D

 

P

 

N

 

N

Пояснения к терминам:

routines

  as free subprograms

        subprograms may be defined independently of any class

  exclusively as methods

        all subprograms are defined as methods within a class

----------------------------------------------------------------

objects

  using relationships

        objects may make use of the service offered by other objects

  containing relationships

        object may contain other objects as part of their structure

  reference semantics

        it is possible to define and manipulate references to objects

  value semantics

        it is possible to refer to the value of objects, e.g. assignment, comparison

----------------------------------------------------------------

classes

  for abstraction

        class interfaces are defined independently to their implementation

  with encapsulation

        authentication and secrecy are enforced

  as types

        all classes have an associated type

  as modules

        classes comprises a basic unit in softwares physical structure

  shared variables

        it is possible to share a single variable among objects in a class

  metaclasses

        classes may be defined as instance of metaclasses

  documentation

        facilities exist to document classes and to extract this documentation

  assertions

        class semantics are defined by a set of axiomatic assertions

  generic

        class definitions may be parameterized by other class or subprograms

----------------------------------------------------------------

inheritance

  single

        classes may inherit the structure or behaviour of one other class

  multiple

        classes may inherit the structure or behaviour of more than one other class

  repeated

        it is possible to inherit from the same class in more than one way at once

  redefinition

        classes may redefine the implementation of inherited structure or behaviour

----------------------------------------------------------------

typing

  strong

        expressions are necessarily type-consistent

  weak

        expressions are not necessarily type-consistent

  static

        names are bound to types during compilation

  dynamic

        names are bound to types during execution

----------------------------------------------------------------

polymorphism

  overloading

        subprograms are distinguished by their argument and return types

  parametric

        methods may respond differently according to an object's class

----------------------------------------------------------------

exceptions

  definable

        it is possible to define program behaviour to failure

----------------------------------------------------------------

memory management

  garbage collection

        memory is automatically recovered after objects become inaccessible

----------------------------------------------------------------

persistence

  time-persistent objects

        objects may exist across invocations of manipulating programs

  space-persistent objects

        objects may be moved among the address spaces of distributed processors

----------------------------------------------------------------

concurrency

  concurrent objects

        object semantics are preserved within multiple threads of execution

Приложение B. Аксиоматика "хороших" систем

И увидел Бог все, что Он создал, и вот, хорошо весьма. И был вечер, и было утро: день шестой.

Быт. 1,31

И будет там большая дорога, и путь по ней назовется путем святым...

Ис. 35,8

Кто имеет уши слышать, да слышит!

Мат. 13,9

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

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

Теорема 1. Любая завершенная система не является "хорошей".

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

Замечание.

Хорошей иллюстрацией к данному утверждению может служить Вселенная, созданная Богом за 6 дней.

Конец замечания.

Следствие 1. Разработка "хорошей" системы должна продолжаться всегда.

Рассмотрим теперь проблему с другой стороны.

Аксиома 1. Все люди разные.
Аксиома 2. Но не совсем.

Замечание.

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

Конец замечания.

Следствие 2. Так как машины делают люди, то все машины получаются разными.

Следствие 3. Но все-таки у них есть что-то общее.

Следствие 4. ***

Очень секретное замечание (перед прочтением закрыть глаза).

Следствие 4 опущено из соображений морали.

Конец очень секретного замечания (глаза можно открыть).

И, наконец:

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

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

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

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

Мат. 7,15

Введение    Глава 1    Глава 2    Глава 3    Глава 4    Заключение    Литература    Приложения