Хотелось бы начать такую тему. Причина тоже ясна, неполное владение понятиями диаграммы классов(далее ДК)

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

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

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

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

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

Классы, являясь типами объектов
"Тип" - относится к интерфейсу
"Класс" - к реализации,
те это несколько разные вещи.

зависимости

Например метод класса А возвращает объект класса В - это зависимость.

теоретическую или модельную
Together считает что это ассоциация.

"Тип" - относится к интерфейсу
"Класс" - к реализации,
те это несколько разные вещи.

Не совсем понял.....

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

зависимости
Например метод класса А возвращает объект класса В - это зависимость.

Да. Т.е. Если в объявочной части Класса содержится другой Класс, исключая ассоциацию.

теоретическую или модельную
Together считает что это ассоциация.

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

Господа!
Давайте сначала определимся с терминологией.
Читаем http://wikipedia.org

Класс (программирование) — некая сущность, которая задает некоторое общее поведение для объектов.

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

Фактически объектно-ориентированное программирование чаще всего сводится к созданию некоторого количества классов, описанию связей между этими классами и их свойств, и дальнейшей реализации полученных классов. Графическое представление некоторого количества классов и связей между ними называется диаграммой классов. Объектно-ориентированный подход за время своего развития накопил множество рекомендаций (паттернов) по созданию классов и иерархий классов.
Подробнее смотри: http://ru.wikipedia.org/wiki/Класс_(программирование)

Объект наряду с понятием «Класс», является важным понятием объектно-ориентированного подхода в программировании. Под объектом подразумевается некоторая сущность, обладающая состоянием и поведением. Как правило при рассмотрении объектов выделяется, что объект принадлежат одному или нескольким классам, которые в свою очередь определяют поведение объекта. Так же часто у объектов выделяется время жизни, то есть время создания объекта и время его уничтожения.
В большинстве языков Объектно ориентированных языков программирования (таких как Java, C++ или С#), объекты являются экземплярами некоторого заранее описанного класса (однако например в таком языке как JavaScript понятие класс не используется вовсе). Объекты в таких языках создаются с помощью конструктора класса, и уничтожаются либо с помощью деструктора класса (например, в C++), либо автоматически с использованием Garbage collector-а(в Java, C#).

Таким образом, класс - есть некая абстракция, а вовсе не интерфейс, как утверждает уважаемый Kolan.

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

Уважаемый bas, естественно ER частный случай ДК, состоящей из из классов-сущностей и не включающая граничные и упраляющие классы. А вот наличие последних и отличает ДК от ER.

Насчет зависимости думаю никто из вас не прав.

a dependency in computer science is a state in which one object uses a functionality of another object. This may cause changes on implementation of one object that can affect implementation of another object.
К сожалению нет русской статьи остается читать только английскую
http://en.wikipedia.org/wiki/Coupling_(computer_science)
очень примечательно.

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

Про последнее. Можно понимать так, что если некое свойства класса А, есть класс В, то между классом А и классом В есть устойчивая связь - читай ассоциация - а какая тут множественность, кардинальность и т.п.?

вот кстати, почитайте
http://alice.pnzgu.ru/~dvn/uproc/books/uml_user_guide/gl_10.htm#a02

Читаем http://wikipedia.org
Тоже мне истина в последней инстанции. Хочешь сейчас изменю?
Читай Буча, Фаулера.

Таким образом, класс - есть некая абстракция, а вовсе не интерфейс, как утверждает уважаемый Kolan.
Где я говорил что класс=интерфейс?

Еще раз, тк ты меня не понял:

Важно понимать различие между классом объекта и его типом. Класс объекта определяет, как объект реализован, то есть внутреннее состояние и реализацию операций объекта. Напротив, тип относится только к интерфейсу
объекта - множеству запросов, на которые объект отвечает. У объекта может быть много типов, и объекты разных классов могут иметь один и тот же тип.
Разумеется, между классом и типом есть тесная связь. Поскольку класс опре¬деляет, какие операции может выполнять объект, то заодно он определяет и его тип. Когда мы говорим «объект является экземпляром класса», то подразумеваем, что он поддерживает интерфейс, определяемый этим классом.

Нет ли такой мысли, что зависимость проявляется между объектами и пакетами, но не между классами?
Зависимость можно изобразить не только на диаграмме классов... В чем вопрос то?

Извините за многословие, но

Ни каких вопросов Kolan, просто мысли вслух. Форум понимаешь, brain ring, конференция мыслей, дискуссия!
Я поставил задачу или проблему: дать точное, полное и не двухсмысленное понимание понятиям. Это начала любого процесса обучения.
Вот видишь - ты говоришь одно, считая себе глубоко правым - я не спорю, но и верить тебе на слово не собираюсь; я пытаюсь утверждать нечто иное. Может wikipedia для тебя не авторитет - ну что ж, вероятно, ты прав.
Однако я тут не собираюсь перепираться чей песок в песочнице, я хочу в дискуссии увидеть точное понимание всех этих понятий.
Мне лично совсем не понятна мысль о типах и интерфейсах в товем изложении, прости, попробуй объяснить доходчивее.
Если разногласие идет в дельфийском смылсе, где есть типы и объекты, то это одно.

Понимаю, что зависимость можно изобразить не только на диаграмме классов. Хочется полностью понять когда, как и где ее использовать именно в отношении классов.

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

Вчитываясь в определения, тобою сформулированные (ПРОСТИ ЕСЛИ ЧТО ЗА ТЫКАНИЕ), я не очень понимаю в чем собственно разница в моих словах и в словах, написанных тобою.

Что например значит фраза "У объекта может быть много типов, и объекты разных классов могут иметь один и тот же тип.". Каких типов? Типов данных? Если так, то вроде это и ежу понятно, если речь идет о других типах, то не догоняю. Не силен в теориях, потому и начал тему, чтобы поумнеть:-))

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

2 galogen & Kolan
Ну зачем сразу наезжать?? "Мы же культурные люди" (с)

На счет зависимости:

http://www.sparxsystems.com/resources/uml2_tutorial/uml2_classdiagram.html

Dependencies
A dependency is used to model a wide range of dependent relationships between model elements. It would normally be used early in the design process where it is known that there is some kind of link between two elements but it is too early to know exactly what the relationship is. Later in the design process, dependencies will be stereotyped (stereotypes available include «instantiate», «trace», «import» and others) or replaced with a more specific type of connector.

http://www.visualcase.com/tutorials/class-diagram.htm

A dependency exists between two elements if changes to one will affect the other.  If for example, a class calls an operation in another class, then a dependency exists between the two.  If you change the operation, than the dependent class will have to change as well.  When designing your system, the goal is to minimize dependencies.

http://en.wikipedia.org/wiki/Class_diagram#Dependency_.28UML.29

A dependency exists between two defined elements if a change to the definition of one would result in a change to the other. This is indicated by a dashed arrow pointing from the dependent to the independent element.

В общем, как всегда мнения разные, но сходство в одном - зависимости надо минимизировать.
Пример привел Kolan, когда в методе возвращается или присутствует параметр типа другого Класса.
Вот наглядный пример:
http://cnx.org/content/m11658/latest/listvisitors.png

Кстати - если даешь цитаты, неплохо бы давать ссылку на них, источник.

Design Patterns.

Что например значит фраза

У объекта может быть много типов

объекты разных классов могут иметь один и тот же тип

Черт картинки не вставились
Еще раз
У объекта может быть много типов
http://ksoftware.narod.ru/2Int.jpg


объекты разных классов могут иметь один и тот же тип
http://ksoftware.narod.ru/1Int.jpg

Черт картинки не вставились
Еще раз
У объекта может быть много типов
http://ksoftware.narod.ru/2Int.jpg

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

А катринки почему не цепляются? хм странно надо разобраться

объекты разных классов могут иметь один и тот же тип
http://ksoftware.narod.ru/1Int.jpg

2 galogen, Если не сложно, то в цитатах выделяй хотябы свой текст, а то сложно читать...

Ну и что?

Просто пояснил что имели ввиду
Э. Гамма   Р. Хелм   Р. Джонсон   Дж. Влиссидес   

Понимаешь, ну не все читали эту книгу, так же как и ты читал не всё из того, кто читал другое.

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

Почему все-таки спрашиваю, да потому, как не очень понимаю все-таки, что же ты имеешь в виду или имеют многоуважаемые авторы книги.

Добрый вечер, Эдуард.

Вот недавно зашел на Ваш ресурс. Впечатляет!
Много действительно полезной информации.
Особеноо меня заинтересовал проект "Служба занятости в рамках вуза".
Насколько я понял, его именно Вы делали.
На форуме я нашел множество диаграмм-использования.
Но нигде нет полного проекта (Он так и не был доделан?)

Эдуард, не могли бы Вы мне выслать этот проект (даже если он остался незавершенным).
Просто в данный момент я занимаюсь именно этой проблемой.
Заранее благодарю.
С уважением, Дмитрий
mailto:
          pw@gmail.ru

З.Ы. Может быть у кого-нибудь еще есть данная работа.
Буду очень признателен.

Vasya, я посмотрю, что у меня осталось и вышлю.
Скажу однако, что проект не был реальным, скорее чисто учебным, его идея подчерпнута из книги по практикуму CASE-технологий.
Проект в своем незаконченом виде существует по адресу http://www.isuct.ru/~ivt/uml /

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

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