По  аналогии с языками основанными на классах 
можно попробовать строить модель системы, которая будет
реализована на  JavaScript, как  диаграмму классов UML.
Но возникают сомнения: как отображать отношение объектов-конструкторов,
если одни из них является прототипом другого.
Как расширение(extend) или как агрегация(aggregation)?

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

Но, так же можно представить, что работник любого
предприятия является человеком и поэтому группа
люди(Person) включает в себя всех тех,
кто являются служащими. Тогда Person агрегирует
в себя Employee.

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

Лешек А. Мацяшек "Анализ требований и проектирование систем" изд. "Вильямс", 2002 . - 428 с. М.
стр. 229-230 "Делегирование или наследование"


Как отображать пототипирование в диаграммах классов UML?

Присоединённый файл ( Кол-во скачиваний: 29 )
 all.JPG 14,30 Kb

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


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

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

Далее обсуждение в соответствующем разделе.

Статья на wikepedia Объектно-ориентированное программирование говорит:

Прототипное программирование

Примерами языков программирования, где используется прототипное программирование, являются Self и JavaScript.

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

А  статья Шаблон делегирования:

шаблон делегирования (англ. delegation pattern) — это способ, которым объект внешне выражает некоторое поведение, но в реальности передаёт ответственность за выполнение этого поведения связанному объекту. Шаблон делегирования является фундаментальной абстракцией которая поддерживает композицию (также называемую агрегацией), примеси (mixins) и аспекты (aspects).

Так может показывать ассоциации объектов-конструкторов как агрегирование?

Какой смысл в том, что конструктор является чьим-либо прототипом?

Уже строят.


Первое. Вы же, видимо, строите модель на базе конструкторов, выдавая их за традиционные классы.


Конструкторы в топку, если уж показывать, так объект+цепь прототипов, только вряд ли при этом можно назвать объект составным, в котором обитают "внутренние" объекты-прототипы. Не так же это.

Ошибся. 
Если один из объектов является прототипом для другого
объекта-конструктора.

Если объект, созданный одним конструктором, является прототипом объекта, созданного другим конструктором.

Извиняюсь, глуплю.
Код получаем следующий:


В UML-диаграмме классов отображаем только сами объекты(employee, person),
показывая, что employee расширяет person?


Присоединённый файл ( Кол-во скачиваний: 18 )
 extendObjects.jpg 6,88 Kb

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

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

Не знаю, что вы подразумеваете под термином "агрегация", обычно это "целое->часть" или "has-a" и т.п., то, что вы описываете можно скорее обобщить под ооп-термином "наследование", коим собсно и является делегирование в javascript...

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

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


и там же:


Покажем, что с помощью делегирования можно моделировать наследование и наоборот.
Это значит, что одни и те же функциональные возможности можно реализовать
как с помощью наследования, так и делегирования. Согласие в этом вопросе
впервые было достигнуто на конференции в США в городе Орландо, штат Флорида, в
1987 году и теперь известно как Орландское соглашение

Лешек А. Мацяшек "Анализ требований и проектирование систем" изд. "Вильямс", 2002 . - 428 с. М.
стр. 229-230 "Делегирование или наследование"


Эту главу можно прочитать здесь.

Это сообщение отредактировал(а) rene - 25.4.2008, 14:08

Еще идея.

Связывание объектов  интерпретатором JavaScript через прототипирование приводит к тому, что объекты делегируют друг другу свойства и методы. Это, если мы говорим о внутренних механизмах
работы JavaScript. 

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

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

Зачем вам еще форум?...