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

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

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

Системный анализ возник в эпоху разработки компьютерной техники. Успех его применения при решении сложных задач во многом определяется современными возможностями информационных технологий. Н.Н. Моисеев приводит, по его выражению, довольно узкое определение системного анализа [1]: «Системный анализ — это совокупность методов, основанных на использовании ЭВМ и ориентированных на исследование сложных систем — технических, экономических, экологических и т.д. Результатом системных исследований является, как правило, выбор вполне определенной альтернативы: плана развития региона, параметров конструкции и т.д. Поэтому истоки системного анализа, его методические концепции лежат в тех дисциплинах, которые занимаются проблемами принятия решений: теории операций и общей теории управления».

Вне всякого сомнения нельзя противопоставлять эти понятия. но нельзя и сравнивать.

Вы же не сравниваете периодическую систему Менделева и синтез аммиака.

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

так же как и реализация и аналитическая работа, хотя и то и другое моежт работать с одним объектом диаграммой классов

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

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

Шар же  имеет форму, структуру, фактуру, вес, размер, материал. Скажите существует не цветной шар? т.е. бесцветный? и какого цвета цветной шар ночью?

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

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

Или возьмем растение Росинка - это и растение - но и животное, там есть и то и другое.

А как назвать профессора, который обучается? Ну конечно такие глупости делать в программировании не нужно, но в ПРИКЛАДНОМ программирование всякое может возникнуть.

Хотя часто встречающая проблема. Сотрудник: руковдитель и просто исполнитель, еще он может быть на окладе и иметь почасовую оплату.

А классический пример с АМФИБИЕЙ! Ой если покопаться найти можно еще. Конечно гуру говорят нам избегайте таких проблем - ибо ну не могут это делать просто ООЯ.

Аналогичная ситуация с 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

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