Форум Сообщества Аналитиков
Общий раздел => Теория моделирования и нотации => UML SysML и пр. => Тема начата: Galogen от 01 Декабря 2006, 20:16:54
-
Хотелось бы начать такую тему. Причина тоже ясна, неполное владение понятиями диаграммы классов(далее ДК)
И так, небольшой экскурс. Классы, являясь типами объектов, во многом берут свое происхождение от 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
объекты разных классов могут иметь один и тот же тип
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 /
Идея состояло в том, что бы реализовать модельное решение, но не довести проект до конца. Хотя в общем возможность такая есть.
В приниципе в данной идее нет нового, сейчас существуют вполне солидные системы кадровых агентств, так или иначе решающих эту задачу.
В общем в понедельник посмотрю, что у меня есть и вышлю...
-
Господа!
Классы и объекты придумали умные люди. Умные потому, что они не усложняют суть, а упрощают, ибо ... (много поговорок). Меня всегда нервировали профессора коллапсирующие в своём океане информации. Всё гениальное должно быть до безобразия простым. Вот возьмём класс-объект, это гениальный бинарный примитив способный наиболее просто смоделировать сложнейшие процессы во вселенной. В отличие от реального мира схема класс-объект всегда положительна, а в жизни у примитивов есть и анти примитив. Почему физики умнее ИТ-шников? Они уже давно знают, но молчат ))
Я ИТ-шник. Смесь сетевика и программиста. И я призываю Вас своих коллег не коллапсировать, а упрощать и сбрасывать лишнюю массу для исключения коллапса.
Пархайте как бабочки, жальте как пчёлы!
-
Выскажусь-ка.
разумеется базовой сущностью модели ООП является класс и обьект класса. Он же - экземпляр класса. Интерфейсы сугубого отношения к базе не имеют, это уже "проекции" на экземпляр класса, то есть его различные виды в том или ином контексте.
Например экземпляр "вася" может быть видим как слесарь, и как больной геморроем. Один его вид необходим в контексте - работа, другой в контексте поликлиника. Но такие "проекции" - они же интерфейсы, это уже некая надстройка и развитие ооп модели.
То что обьект может принадлежать к нескольким классам сразу - это могучая дурь, поскольку точный, актуальный тип обьекта задается его конструктором.
Никто не мешает насиловать ооп концепцию и изменять ее до неузнаваемости. Ну например создать такую систему в которой тип обьекта может меняться. Вопрос только - какую концептуальную задачу мы этим решим и к чему такие фичи в вашем подходе.
Ах да...всерьез рассматривать разницу между типом и классом не стоит. Исторически типы появились для контроля корректности программ, и сокращения числа необходимых мнемоник операций над обьектами.
Классы появились когда стало понятно, что необходимо создавать сложные типы обьектов и иметь возможность все операции и инварианты обьекта описывать как нечто целостное. Тут и появился класс. Соббсно.
Наследование появилось как идея описания иерархических отношений родства на системе классов, и описании общих свойств обьектов.
Ну и так далее..
Из своего опыта могу сказать, что мне приходилось использовать розу для реализации сложных систем из сотен классов на С++, но разумеется безо всяких там отношений ассоциации, и проч. аналитической муры, а расписывая лишь пакеты классов с точными именами полей класса, прямыми описаниями методов, конструкторов и так далее. роза при генерации кода помогала с помошью параметров генерации создавать автоматически некий код(что было лень писать ручками), автоматически делать нужные инклуды, оформлять заголовки файлов и так далее.
Очень сомнительно, что применяя ассоциации, агрегирования и проч, можно проделать такую же работу за приемлемое время. диаграммы точно станут нечитаемыми в силу могучего изобилия стрелок, линий и проч.
Фактически использовались мной лишь отношения наследования и зависимости. А также средства разбрасывания класов по пакетам - файлам .сpp и .h в терминах с++.
-
добавление. топикстартер подходит к диаграмме классов с точки зрения чисто схематического и поверхностного моделирования некоей программной системы. я глубоко убежден, что такие диаграммы имеются в умл именно для решения задачи разработки программного обеспечения в терминах ооп и ничего другого.
Но! Всерьез ассоциациями и проч. архианалитикой ничего не опишешь. Если у вас классов 500, в каждом технически методов по 10, и собственных полей в среднем штуки 4 - вы в стрелочках просто запутаетесь.
А при таком обилии классов требуется именно наглядность представления, для работы с этой системой классов при ее коррекции или сопровождении.
Потому просьба на примеры из руководств типа на диаграмме три класса - клиент, продавец и заказ, и все на отношениях, не смотреть. они если и научны, то антипрактичны.
-
Alys, спасибо за интерес к теме и полезные высказывания. Правда они несколько запоздали. Тема была начата более полутра лет. За это время ситуация значительно прояснилась и понимание тоже
А при таком обилии классов требуется именно наглядность представления, для работы с этой системой классов при ее коррекции или сопровождении.
Не до конца понял Вашу мысль о наглядности представления
-
обычно при сопровождении большой программной системы или ее разработке, необходимо иметь перед глазами структуру классов, особенно если новый человек вводится в проект. наглядность диаграмм в данном случае много выше чем наглядность исходников программ.
однако в данном случае стоит акцентровать. имелось ввиду, что диаграмма не перенасыщена отношениями аггрегирования и проч. ассоциациями, а атрибуты классов(например) вписаны явным образом(не через отношения, а прямо в тело класса).
-
То что обьект может принадлежать к нескольким классам сразу - это могучая дурь, поскольку точный, актуальный тип обьекта задается его конструктором.
на данном этапе возможностей ООЯ, наверное, это действительно так, но почему же "могучая дурь"? Множественная классификация и множественное наследование в реальном мире встречается довольно часто, другое дело, что современный ООЯ просто не позволяет просто воспользоваться этим. Возможно пока в этом и нет потребности и есть гораздо более простые средства выразить это в программе.
Никто не мешает насиловать ооп концепцию и изменять ее до неузнаваемости. Ну например создать такую систему в которой тип обьекта может меняться. Вопрос только - какую концептуальную задачу мы этим решим и к чему такие фичи в вашем подходе.
а параметризированные классы не укладываются в то, что Вы описали?
Из своего опыта могу сказать, что мне приходилось использовать розу для реализации сложных систем из сотен классов на С++, но разумеется безо всяких там отношений ассоциации, и проч. аналитической муры,
Т.е. Вы считаете ассоциации - простой аналитической дурью?
А что вы понимаете здесь под "розой"
роза при генерации кода помогала с помошью параметров генерации создавать автоматически некий код(что было лень писать ручками), автоматически делать нужные инклуды, оформлять заголовки файлов и так далее.
Т.е. единственная причина использовать автогенерацию - это лень?
Очень сомнительно, что применяя ассоциации, агрегирования и проч, можно проделать такую же работу за приемлемое время. диаграммы точно станут нечитаемыми в силу могучего изобилия стрелок, линий и проч.
Трудно не согласиться, но не стоит ли все-таки различать аналитическую работу и собственно реализацию. Или Вы полагаете, что аналитика - суть пиар и ничего более?
Фактически использовались мной лишь отношения наследования и зависимости. А также средства разбрасывания класов по пакетам - файлам .сpp и .h в терминах с++.
Но Вы использовали это не потому ли, что это было полезно и сокращало время и позволяла не потеряться в массе информации?
Но! Всерьез ассоциациями и проч. архианалитикой ничего не опишешь. Если у вас классов 500, в каждом технически методов по 10, и собственных полей в среднем штуки 4 - вы в стрелочках просто запутаетесь.
Может быть все дело в точке зрения? Что такое эти 500 классов - откуда они появились? Это классы предметной области? Или уже объекты программной реализации? Все ли 500 классов вам нужны для анализа одновременно? Не разбиваются ли эти 500 классов на смысловые группы, которые и следует рассматривать отдельно? Разве проектировщики баз данных отказываются от представления связей только из-за того, что их слишком много? Повторяюсь не следует ли всегда при решени задачи держать в голове: (1) точку зрения, (2) контекст использования, (3) уровень использования ?
обычно при сопровождении большой программной системы или ее разработке, необходимо иметь перед глазами структуру классов, особенно если новый человек вводится в проект. наглядность диаграмм в данном случае много выше чем наглядность исходников программ.
однако в данном случае стоит акцентровать. имелось ввиду, что диаграмма не перенасыщена отношениями аггрегирования и проч. ассоциациями, а атрибуты классов(например) вписаны явным образом(не через отношения, а прямо в тело класса).
опять же вопрос об уровне где и как использовать ассоциации и тем более агрегации.
Понимаете явное указание атрибута типа объект среди атрибутов другого класса по сути есть уже указание на решение, но задача аналитика не указать конкретное решение по реализации, а сказать что нужно реализовать. Ведь Вы не будете спорить, что ассоциацию можно реализовать по-разному? В то время как явное указание атрибута жестко будет определять и способ реализации связи между двумя объектами - через ссылку, массив, коллекцию или создание отдельного класса. Т.е. если на модели Вы укажите просто ссылку на объект, как это принято в C++, а в реальности вам потребуется сделать нечто иное - не приведет ли это к логическому разрыву между реализацией и моделью - как впрочем часто и бывает?
-
***Множественная классификация и множественное наследование в реальном мире встречается довольно часто, другое дело, что современный ООЯ просто не позволяет просто воспользоваться этим.***
ну не очень то и часто множественная классификация(выражающаяся в множественом наследовании) встречаются в этом мире.
и она сводима к однократному наследованию. это можно показать, соббсно.
действительно. если вы решили что ваш класс должен находиться в двух классификациях сразу, то чтобы разделить "сцепившиеся классификации" вам можно просто расщепить класс на два - один для одной классификации, и другой - для другой. вообще сцепившиеся классификации говорят скорее о том, что классификация проведена неверно. с точки зрения математики классификация есть разбиение общего множества обьектов(ну или понятий) на непересекающиеся домены, поддомены и так далее до конечных подмножеств. непересекающихся даже в пределах одного разбиения-данной классификации. и вдруг получется, что другое разбиение(классификация) дает некий домен, что вы считаете эквивалентным домену из совершенно другого разбиения!!! йерунда получается. :)
***а параметризированные классы не укладываются в то, что Вы описали?***
не очень понял. параметризованные классы это просто генераторы актуальных классов. ну можно назвать их метаклассами или еще чем. название генераторов классов им больше подходит.
если создается обьект некоего параметризованного класса, то в данном месте в генератор происходит подстановка параметров, генерируется актуальный класс, и все.
***Т.е. Вы считаете ассоциации - простой аналитической дурью?***
это было слишком сильное утверждение с моей стороны. имелось ввиду что в области разработки софта увлечение стрелками сильно перегружает диаграмму, что резко снижает ее читабельность.
***А что вы понимаете здесь под "розой"***
Rational Rose.
***Т.е. единственная причина использовать автогенерацию - это лень?***
составлять диаграммы без генерации кода - пустая забава. она даже зря порой оплачивается. диаграммы классов, без генерации, и если этот код не проверен компилятором, может быть даже семантически неверной. например атрибут класса с неким типом, написанным явно, навроде
_my_attr: SomeClass внутри класса,
будет скорее всего проглочен системой, даже если SomeClass более нигде не описан. При генерации кода и его компиляции это будет обнаружено компилятором.
Итак диаграмма классов хороша для визуального анализа вашей системы, как набора классов, проведения этапа разбиения на модули, подсистемы, генерации кода, и генерации документации. с генерацией тестов никогда не работал, ничего сказать не могу.
***Трудно не согласиться, но не стоит ли все-таки различать аналитическую работу и собственно реализацию. Или Вы полагаете, что аналитика - суть пиар и ничего более?***
мощный вопрос. я лично со всем радикализмом считаю, что просто "аналитиков" в мире не бывает. аналитик обязательно должен знать предметную область, и особенности реализации. хотя бы неявно.
пример. я занимался разработкой компиляторов, например. вы например в этом не понимаете, но вы аналитик, и начинаете рисовать диаграммы работы компилятора. ну и что вы нарисуете? две три очевидных диаграммы, типа - подать файл на вход системы, если найдена ошибка, выдать сообщение куда-то с указанием типа ошибки и позиции в тексте. все. а это понятно и без диаграмм. и без аналитиков.
итак. если аналитик не понимает предметной области и особенностей реализации, он беспомощен.
***Может быть все дело в точке зрения? Что такое эти 500 классов - откуда они появились? Это классы предметной области? Или уже объекты программной реализации? Все ли 500 классов вам нужны для анализа одновременно?***
это классы - всего. разумеется они распадаются на подсистемы, часто различные приложения или службы, и так далее. но это система выполняющая некую общую задачу.
ну например представьте себе структуру типовой ос. и есть архитектор ос. задачи такого рода, разумеется, трудно решать только в виде текста на с++.
***Понимаете явное указание атрибута типа объект среди атрибутов другого класса по сути есть уже указание на решение, но задача аналитика не указать конкретное решение по реализации, а сказать что нужно реализовать. Ведь Вы не будете спорить, что ассоциацию можно реализовать по-разному? В то время как явное указание атрибута жестко будет определять и способ реализации связи между двумя объектами - через ссылку, массив, коллекцию или создание отдельного класса.***
если атрибут простого типа вроде
_is_correct:boolean
вы будете рисовать на квадратик класса boolean какую-то свободную от деталей реализации ассоциацию?
если вы архитектор верхнего уровня, не ваше дело рисовать атрибуты. вы должны рисовать методы. то есть составлять функциональные интерфейсы классов. а атрибуты всегда имеют прямое отношение к реализации. не хотите иметь отношения к реализации - рисуйте контракты - то есть функциональный набор.
рисуете атрибуты - думайте о реализации.
в случае если вы уверены, что у класса должен быть некий атрибут, что выразим как множество экземпляров неких других классов, типа ссылки на нечто во множественном числе...просто напишите
_name: PoolOfFoo. где PoolOfFoo - некий класс с собственной функциональностью(что вы должны тоже описать), и уже программер и пусть решает как этот Pool ему реализаовать.
Стрелка вообще ничего ему не скажет.
Ну генератор кода сделает из этой стрелки нечто вразумительное, по ему известным правилам. Но тогда это уже не выбор программиста, а выбор конфигурации паттернов генерации кода. Если вы их не знаете, не понимаете какой код они сгенерят,...то тут легко получить уязвимость с точки зрения адекватной реализации.
Хочу резюмировать. Диаграмма классов(и заложенные в ней возможности) адекватны именно реализационному этапу в разработке софта. Если вы собираетесь ее использовать только на этапе логического анализа верхнего уровня, и потом передать кодерам...то вы пропустили именно самый трудный и длительный этап - этап реализации, с генерацией кода. кодеры у вас окажутся в слишком свободной ситуации, и наверняка будут нести отсебятину, в результате которой система окажется незрелой во многих смыслах.
Если же вы дали систему классов сформулированную до конца, с требованием, что кодеры не имеют права менять состав классов без согласования с вами, и занесения это в диаграммы - то кодеры оказываются в жестких рамках и кстати, довольно часто это приветсвуют. поскольку им не нужно особо задумываться над тонкостями реализации. они просто наполняют тела методов нужным кодом. и если классы сформулированы верно, методы обычно довольно атомарны и не имеют сложной логики.
-
Хочу резюмировать. Диаграмма классов(и заложенные в ней возможности) адекватны именно реализационному этапу в разработке софта. Если вы собираетесь ее использовать только на этапе логического анализа верхнего уровня, и потом передать кодерам...то вы пропустили именно самый трудный и длительный этап - этап реализации, с генерацией кода. кодеры у вас окажутся в слишком свободной ситуации, и наверняка будут нести отсебятину, в результате которой система окажется незрелой во многих смыслах.
Правильно, только это должен делать архитектор или тим лид програмистов, но никак не аналитик. А то у нас получается не аналитик, а всемогущий семикрыл - и цели может сформулировать и требования написать и архитектуру с классами прорисовать и предметку понимает и если нужно может и покодировать, ну а тестировать - само собой. Я, например, боюсь архитектуры, кот. может нарисовать аналитик, Вы это скажите програмерам, они вас пошлют далеко и надолго.
-
500 "голых" классов без разделения на уровни/пакеты -- скорее всего признак плохого дизйна. Даже если ваша модель реализации столь сложна -- то нужно позаботиться об инкапсуляции логики в некие контейнеры (модули, пакеты и т.п.), и активно выставлять "наружу" интерфейсы.
Говоря о "большом софте" и в частности ОС -- там тоже действуют простые способы борьбы со сложностью и следовательно энтропией -- а именно декомпозиция. Часть функциональности ОС реализована утилитами, функциональность которых ограничена.
-
***500 "голых" классов без разделения на уровни/пакеты -- скорее всего признак плохого дизйна.***
я лично, ни в своей, ни в мировой практике, не встречал 500 "голых" классов в одном файле(видимо это вы хотите сказать)? :)
хотелось бы видеть ненормального способного на этот титанический труд.
труд воистину титанический поскольку только компиляция такого пакета будет составлять неприемлемое время, а уж работа с ним в редакторе - чистое самоубийство.
с чего вы взяли, что такие люди есть, и один из них - перед вами?
-
ос претендующая на современность имеет архитектуру сходную с микроядерной, и с динамической загрузкой модулей ос. от есть конфигурируется при запуске, и не требует априори значительных аппаратных ресурсов. она также имеет механизмы самоверификации, защиты от сбоев, и предоставляет задачам изолированные среды для выполнения. и это только базовая функциональность.
разумеется в одном файле написать такое - это подвиг
реальная архитектура - модульная и многослойная. с четким контролем и видимости обьектов и проникновения хода исполнения из слоя в слой.
-
ос претендующая на современность имеет архитектуру сходную с микроядерной, и с динамической загрузкой модулей ос. от есть конфигурируется при запуске, и не требует априори значительных аппаратных ресурсов. она также имеет механизмы самоверификации, защиты от сбоев, и предоставляет задачам изолированные среды для выполнения. и это только базовая функциональность.
А как быть с ОС, претендующей на полезность? А с ОС, претендующей на коммерческий успех? ;)
Разработка компиляторов и ОС - это классические задачи системного программирования. Предметные области, в которых программист разбирается лучше любого специально обученного аналитика. Но такие задачи я бы отнёс... как бы это поточнее выразиться... к периоду внтриутробного развития технологий создания ПО. :)
В чём я полностью с Вами согласен - это в том, что любые визуальные диаграммы нужны не для усложнения, а для упрощения. Но алфавит тоже нужен для упрощения. А чтобы складывать буквы в слова, нужно научиться читать, иначе эти закорючки так и останутся "грамотейской дурью".
с точки зрения математики классификация есть разбиение общего множества обьектов(ну или понятий) на непересекающиеся домены, поддомены и так далее до конечных подмножеств. непересекающихся даже в пределах одного разбиения-данной классификации.
Действительно, йерунда получается. А СУБД вы тоже до сих пор только иерархические используете? ;)
-
***Но такие задачи я бы отнёс... как бы это поточнее выразиться... к периоду внтриутробного развития технологий создания ПО.***
вы похоже утверждаете, что системный анализ и задачи системного программирования несовместимы :) и понятие системы в них разныя?
тогда дайте понятие системы, в том и другом случае, и покажите разницу.
***А СУБД вы тоже до сих пор только иерархические используете?***
представление данных и логическая классификация понятий - вещи разные.
классический пример из ООП.
есть два класса - шар и цвет.
если вы считаете что класс - цветной шар есть просто наследник от классов шар и цвет, то это грубая ошибка.
почему?
потому что если это не ошибка, то экземпляр класса цветной шар должен отвечать утвердительно на два вопроса
- является ли цветной шар шаром? да!
-является ли цветной шар цветом? ... как вы ответите?
более тонкий пример.
класс мужчина(классификация людей) и класс - армейский генерал(классификация военных званий).
так вот реальный генерал иван петрович вовсе не может быть преставителем некоего класса наследника от мужчины и генерала. потому что такой класс есть строго говоря по ооп - кентавр типа мужчино-генерал.
а правильно так, либо нужно наследовать от мужчины и иметь атрибут военное звание...либо от генерала и иметь атрибут - персона. в зависимости от предметной области.
-
Alys, нажимаем на кнопочку ЦИТИРОВАТЬ, в результате в форме быстрого ответа появлется цитата. Править и что-то делать не удобно?
Согласен, хотя несложно переключиться на латиницу и написать для первой цитаты [/quotе]
а все последующие [quotе] [/quotе]
Но можно поступить проще. (Копируем текст ссылки, следует отметить что в эту форму бстрого ответа можно включить цитирование разных писем - просто нажимая кнопку ЦИТИРОВАТЬ)
Выделяем текст в форме быстрого ответа - копировать, нажать кнопку Ответ и вставить в окно редактор - уже проще и интереснее.
Кажется Вы имеете возможность настроить свой интерфейс фронтэнда более гибко и отключить форму быстрого ответа, тогда при цитировании будете попадать в форму ответа
-
короче, над темой множественного наследования и ооп нужно задуматься всерьез. строго говоря это порождение кентавров. причем если само понятие наследования гласит - я доопределяю наследованный класс. или - я сужаю, специализирую его.
то множественное следовательно должно говорить - я специализирую кентавра из двух предков. строго говоря - не совсем понятно, что тут имеется ввиду. не совсем понятно и то, насколько предки сами не являются кентаврами, не несут ли каких-то общих свойств(в результате их собственных диаграмм наследования).
короче неясностей масса, а достоинств..вроде и нет.
-
вы похоже утверждаете, что системный анализ и задачи системного программирования несовместимы :) и понятие системы в них разныя?
тогда дайте понятие системы, в том и другом случае, и покажите разницу.
Понятие системы многоаспектное, но системный анализ - научно-практический метод решения слабоформализованных проблем, а системное программирование - скорее технология причем часто определяемое довольно однозначно - нечто направленное на создание ОС и тому подобное ПО.
Системное программирование (или программирование систем) — род деятельности, заключающийся в работе над системным программным обеспечением. Основная отличительная черта системного программирования по сравнению с прикладным программированием заключается в том, что результатом последнего является выпуск программного обеспечения, предлагающего определённые услуги пользователям (например, текстовый процессор). в то время как результатом системного программирования является выпуск программного обеспечения, предлагающего сервисы по взаимодействию с аппаратным обеспечением (например, дефрагментация жёсткого диска), что подразумевает сильную зависимость таких программ от аппаратной части. (http://ru.wikipedia.org/wiki/Системное_программирование)
Системный анализ возник в эпоху разработки компьютерной техники. Успех его применения при решении сложных задач во многом определяется современными возможностями информационных технологий. Н.Н. Моисеев приводит, по его выражению, довольно узкое определение системного анализа [1]: «Системный анализ — это совокупность методов, основанных на использовании ЭВМ и ориентированных на исследование сложных систем — технических, экономических, экологических и т.д. Результатом системных исследований является, как правило, выбор вполне определенной альтернативы: плана развития региона, параметров конструкции и т.д. Поэтому истоки системного анализа, его методические концепции лежат в тех дисциплинах, которые занимаются проблемами принятия решений: теории операций и общей теории управления». (http://ru.wikipedia.org/wiki/Системный_анализ)
Вне всякого сомнения нельзя противопоставлять эти понятия. но нельзя и сравнивать.
Вы же не сравниваете периодическую систему Менделева и синтез аммиака.
представление данных и логическая классификация понятий - вещи разные.
так же как и реализация и аналитическая работа, хотя и то и другое моежт работать с одним объектом диаграммой классов
классический пример из ООП.
есть два класса - шар и цвет.
если вы считаете что класс - цветной шар есть просто наследник от классов шар и цвет, то это грубая ошибка.
почему?
потому что если это не ошибка, то экземпляр класса цветной шар должен отвечать утвердительно на два вопроса
- является ли цветной шар шаром? да!
-является ли цветной шар цветом? ... как вы ответите?
Классический? Но тут не сопоставимые понятия. Цвет - это конечно может быть класс, но все-таки скорее простой тип, не обладающий функциональностью и свойствами, вернее имеющее одно единственное свойство - самое себя, ну или если хотите длину волны.
Шар же имеет форму, структуру, фактуру, вес, размер, материал. Скажите существует не цветной шар? т.е. бесцветный? и какого цвета цветной шар ночью?
Кроме того, если Вы говорите цветной шар, то ровной я могу сказать шаровой цвет. И кажется такое понятие есть! например кубовый краситель - как на этот счет.
А если взять такое понятие как частица. Известно что она дуальна: она есть материальный объект и волна.
Или возьмем растение Росинка - это и растение - но и животное, там есть и то и другое.
А как назвать профессора, который обучается? :) Ну конечно такие глупости делать в программировании не нужно, но в ПРИКЛАДНОМ программирование всякое может возникнуть.
Хотя часто встречающая проблема. Сотрудник: руковдитель и просто исполнитель, еще он может быть на окладе и иметь почасовую оплату.
А классический пример с АМФИБИЕЙ! Ой если покопаться найти можно еще. Конечно гуру говорят нам избегайте таких проблем - ибо ну не могут это делать просто ООЯ.
Аналогичная ситуация с ER и реляционной БД. Нет в ней связей многие ко многим, потому такая связь называется неспецифичной и требует разруливания через таблицу связи.
Истинный аналитик естественно будет использовать связь многие-ко-многим, вот проектировщик же предложить уже решение, часто case системы предлагают саморешение по трансформационной схеме ибо одно довольно однозначно
-
короче, над темой множественного наследования и ооп нужно задуматься всерьез. строго говоря это порождение кентавров. причем если само понятие наследования гласит - я доопределяю наследованный класс. или - я сужаю, специализирую его.
то множественное следовательно должно говорить - я специализирую кентавра из двух предков. строго говоря - не совсем понятно, что тут имеется ввиду. не совсем понятно и то, насколько предки сами не являются кентаврами, не несут ли каких-то общих свойств(в результате их собственных диаграмм наследования).
короче неясностей масса, а достоинств..вроде и нет.
следует все-таки сказать, что наследование - это механизм реализации в ООП, именно там он зародился. В аналитике же говорят обобщение и конкретизация.
Потому и говорят множественная классификация, часто на практике встречающаяся ситуация.
-
Честно говоря, системное программирование настолько муторное понятие, что я бы и спорить не стал. И прикладное - тоже. Вы ж не пользуетесь только компилятором и ос, чтобы разрабатывать и запускать свои прикладные программы? вам нужна среда программирования, вроде Eclipse, или JavaBeans. подавай отладчики, профайлеры, UML плагины или среды, да еще с реверсинженерией? это тоже прикладные программы?
короче понятие системного софта - растяжимое и вся эта кухня имеет весьма масштабный код и требует соотв. технологий разработки. Или вы скажете, что система аля интернет магазин или безбумажная бухгалтерия покруче будет какого-нить JavaBeans? и потому инет магазин нужно делать на диаграммах...а то что я выше перечислил - прям на коленке? гм.
Классический? Но тут не сопоставимые понятия. Цвет - это конечно может быть класс, но все-таки скорее простой тип, не обладающий функциональностью и свойствами, вернее имеющее одно единственное свойство - самое себя, ну или если хотите длину волны.
Шар же имеет форму, структуру, фактуру, вес, размер, материал. Скажите существует не цветной шар? т.е. бесцветный? и какого цвета цветной шар ночью?
шар у нас не биллиардный(иначе был бы биллардный шар), а типа математический. имеет радиус. всего-то. одно простое такое число. :) так же как и цвет.
цвет кстати сложное понятие и имеет операции - вроде - сложение цветов, вычитание цветов. натуральный класс.
и не стоит различать тип и класс. все что имеет ассоциированные с неким понятием операции или данные - можно оформить как класс. класс=тип, на самом деле.
Кроме того, если Вы говорите цветной шар, то ровной я могу сказать шаровой цвет. И кажется такое понятие есть! например кубовый краситель - как на этот счет.
я пока говорить шаровой цвет не научился. и кубовый краситель тоже. ничего путного ответить тут не могу.
А если взять такое понятие как частица. Известно что она дуальна: она есть материальный объект и волна.
Или возьмем растение Росинка - это и растение - но и животное, там есть и то и другое.
частица и волна - это просто две разных "проекции" на одну сущность. это слишком очевидно. потому в java это будет записано интерфейсами.:)
Все ваши примеры просто примеры неточных классификаций. Неточно классифицируя, вы получаете казусы и пытаетесь заткнуть это "кентавром".
Аналогичная ситуация с ER и реляционной БД. Нет в ней связей многие ко многим, потому такая связь называется неспецифичной и требует разруливания через таблицу связи.
я ж вроде обьяснил, что связь "многие ко многим" получается не на графе наследования, а просто в виде связи на экземплярах. классы тут вообще не причем. имея экхемпляры только одного класса, их можно выстроить в произвольный граф. но это же не наследование!!! а связь самих данных! класс вообще один. называется - узел графа.
или я не понял чего?
-
следует все-таки сказать, что наследование - это механизм реализации в ООП, именно там он зародился. В аналитике же говорят обобщение и конкретизация.
Потому и говорят множественная классификация, часто на практике встречающаяся ситуация.
задирать нос не стоит. в любой маломальски приличной книжке по ооп, так и говорят - конкретизация класса...что выражается в таком термине как наследование класса. и что. ну и разумеется обобщение.
-
вы похоже утверждаете, что системный анализ и задачи системного программирования несовместимы :) и понятие системы в них разныя?
тогда дайте понятие системы, в том и другом случае, и покажите разницу.
Нет, я этого не утверждаю. Я утверждаю, что системный программист может свободно ориентироваться в предметной области компиляторов и операционных систем и легко "задавит авторитетом" любого аналитика, не имеющего достаточного опыта в программировании. Но в общей картине разработки ПО эти предметные области сейчас составляют ничтожные доли процента.
А при работе над большим или длительным проектом визуальные диаграммы, в том числе диаграмма классов, - это, пожалуй, единственный способ зафиксировать принятые архитектурные решения для того, кому рано или поздно придётся разбираться с тем, что накодили его предшественники. Здесь одна большая и сложная диаграмма классов может оказаться намного полезнее, чем сотня простых и маленьких.
Я, кстати, именно сейчас жалею о том, что восемь лет назад, разрабатывая одну библиотеку, не документировал решения в виде диаграмм UML (конечно, тогда я даже слова такого не знал). Потому что сейчас вдруг возникла необходимость её срочной доработки, для этого взяли нового программиста, и ему достаточно трудно ориентироваться в коде. Приходится постоянно сидеть рядом с ним и на пальцах объяснять то, что можно было когда-то просто нарисовать. А сейчас, чтобы нарисовать, мне самому тратить время на разбор собственного кода.
-
задирать нос не стоит.
Да нет что Вы, я не задираю высказываю свое мнение. Вы же его высказываете, я не говорю не задирайте мол нос.
Насчет типов я согласен, что каждый тип может быть представлен классом.
-
Alys, Вы к чему ведете дискуссию? К тому чтобы сказать, что UML отстой и придумали его глупые люди? И что все эти рассуждения про использования ДК - суть танцы с бубнами? И реально нужна только - и не более - связь- обощение, которая просто структурирует классы в иерархию? Что весьма полезно, а все остальное от лукавого?
-
Alys, Вы к чему ведете дискуссию? К тому чтобы сказать, что UML отстой и придумали его глупые люди? И что все эти рассуждения про использования ДК - суть танцы с бубнами? И реально нужна только - и не более - связь- обощение, которая просто структурирует классы в иерархию? Что весьма полезно, а все остальное от лукавого?
нет. я просто хочу спросить...а языки с одиночным наследованием придумывают идиоты?
вот взять и сделать сразу множественное.
и нет проблем - все сразу умные.
-
нет. я просто хочу спросить...а языки с одиночным наследованием придумывают идиоты?
вот взять и сделать сразу множественное.
и нет проблем - все сразу умные.
"...Люди - это идиоты.
Себя я тоже включаю сюда...
Неважно, насколько вы остроумны и находчивы, всё равно большую часть дня вы проводите, как идиот."
Эдвард Йордон, Death March (в русском переводе - "Путь камикадзе")
-
нет. я просто хочу спросить...а языки с одиночным наследованием придумывают идиоты?
вот взять и сделать сразу множественное.
и нет проблем - все сразу умные.
Совершенно не сопоставимо.
1. сначала были языки, потом родилась нотация язык описания, метаязык.
2. UML - это не язык программирования
3. не все вещи реализуются сразу, например, принципиально возможно летать на Марс, но вот пока не летают
или ну вот нет еще нормальных средств распознования рукописного текста, но вообще - это возможно и единично решено.
4. так и с множественным наследованием - хотя причем тут множественное наследование? тут вообще тема была про другое немного, про использование или не использование диаграммы классов для отображения программы
И все-таки насчет множественного наследования. Оно есть хотите Вы или нет.
При этом можно выделить ситуацию наследования от независимых классов - область определения которых не пересекается. И тут кажется особых проблем в наследовании нет. Чаще всего используется именно такое наследование
Другая ситуация когда классы частично пересекаются в области совего попределения - и тут конечно есть проблемы. Однако средствами UML мы можем этот факт отобразить путем использования ограничений
множественная классификация не поддерживается большинством языков и существуют обходные маневры: делегирование с использованием композиции частей, наследование важнейших классов с делегированием остальных, вложенные обощения и т.п.
-
я пока говорить шаровой цвет не научился. и кубовый краситель тоже.
Век живи - век учись. :) Есть и шаровая краска, и кубовый цвет. В некоторых предметных областях.
-
uml ная диаграмма классов была явно навеяна языком с++ с его множественным наследованием. если бы она не покрывала возможности с++, это вызвало бы отторжение программистской общественности. никакой более глубокой мысли в наборе возможностей диаграммы классов в uml и нет.
потому говорить - но раз в умл такое наследование имеет место - то значит так и нужно! - не имеет под собой реальных аргументов.
аналогично говорить, что такой язык как java или C# неадекватны uml тоже наивно. хотя в них множественное наследование вызовет ошибку компилятора.
ваш тезис, galogen, что мол еще не пришло время! не совсем понятен. какие еще преграды должны взять большевики от разработки языков? множественное наследование? преграда была давно взята, но от нее отказались как от военного коммунизма. перешли к однократному плюс множестенные интерфейсы(что совсем не аналог наследования, а реализация проекций на класс).
частица - волна, на самом деле не может быть классом наследником от частицы и волны по той простой причине, что такой обьект должен ВСЕГДА утвердительно отвечать на оба вопроса - есть ли ты частица? есть ли ты волна? а в реальности элем.частица отвечает на эти вопросы то да, то нет. то есть воплощает не сумму свойств, а исключающее или - или частица, или волна. в зависимости от условий.
-
***Есть и шаровая краска, и кубовый цвет. В некоторых предметных областях.***
приведите более понятные примеры.
я не верю, что умл в основном позиционируется как средство описания бредовых состояний у пациентов.
-
приведите более понятные примеры.
я не верю, что умл в основном позиционируется как средство описания бредовых состояний у пациентов.
Морякам это скажите. :)
Шаровая краска используется для окраски кораблей.
Кубовый цвет упоминается даже в словаре Ожегова.
http://ozhegov.ru/slovo/20245.html
-
Честно говоря я уже не понимаю сути дискуссии ... толи множественное наследование это плохо, толи хорошо ....
Никто же не заставляет наследоваться от множества объектов, даже если это допустимо. В конце концов у объекта шар может быть просто свойство -- цвет. И уже не важно, это свойство типа класс или имеет простой тип.
Вобщем дискуссия превращается в просто потерю времени.
-
uml ная диаграмма классов была явно навеяна языком с++ с его множественным наследованием. если бы она не покрывала возможности с++, это вызвало бы отторжение программистской общественности. никакой более глубокой мысли в наборе возможностей диаграммы классов в uml и нет.
Но вдруг есть? Неужели все, кто использует UML не ведают, что творят? Причём вот уже двадцать лет... Прямо МАТРИЦА какая-то получается. :)
-
гриша, речь идет не об умл в целом, а о диаграмме классов. которая явно натянута на концепт ооп в с++.
-
гриша, речь идет не об умл в целом, а о диаграмме классов. которая явно натянута на концепт ооп в с++.
Я, честно говоря, из всех объектных языков серьёзно только на C++ и работал. Java изучал когда-то, даже сертификаты есть, но не пригодились.
Множественное наследование C++ применял в библиотеке, которая уже десять лет успешно используется в разных проектах.
В библиотеке реализован механизм обмена сообщениями, на момент разработки стояла задача платформенной независимости этого механизма. В процессе работы типового приложения создаются тысячи взаимодействующих объектов из очень ограниченного набора классов (около двух десятков), и для того, чтобы самому понять, как же они взаимодействуют, мне приходилось рисовать разные диаграммы. Об UML я тогда ничего не знал, но сейчас, просмотрев свою старую документацию, я понимаю, что тогда я разрабатывал аналоги:
- диаграммы классов (это было проще всего)
- диаграмм взаимодействия
- диаграмм последовательности
- диаграмм состояний
"Отношение ассоциации" у меня лично никаких вопросов не вызывает. Разве что само слово раздражало поначалу своим наукообразием, но не больше, чем "инкапсуляция" и "агрегация", не говоря уже о "полиморфизме". Есть стрелочка, она нужна для понимания взаимосвязи объектов, и всегда понятно, что она означает в данном конкретном случае. А относится она к классу "стрелочек", "заострённых палочек", или "графических обозначений отношения ассоциации в нотации диаграмм классов UML 2.0" - какая разница?
Это же как с алфавитом - когда я читаю текст, какая мне разница, из чего состоит слово - из "букв", "литер" или "графем"?