OberonCore

Библиотека  Wiki  Форум  BlackBox  Компоненты  Проекты
Текущее время: Вторник, 17 Сентябрь, 2019 20:12

Часовой пояс: UTC + 3 часа




Начать новую тему Ответить на тему  [ Сообщений: 41 ]  На страницу 1, 2, 3  След.
Автор Сообщение
 Заголовок сообщения: Оберон и проектирование систем
СообщениеДобавлено: Понедельник, 19 Сентябрь, 2011 11:52 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9139
Откуда: Россия, Орёл
Тема отделена отсюда:
viewtopic.php?f=78&t=3463

alexus писал(а):
С Oberon та же проблема. Он является прямым продолжением Модулы... и по-прежнему является процедурно-модульным языком. Объекты в нём - это "подарок бедным"... Понимания того, что язык разработки должен объединять и язык моделирования, и язык проектирования, и язык программирования... не наблюдается.


На самом деле объекты в нём - не "подарок бедным", а экстракт МЕХАНИЗМОВ ООП. Т.е. то, что нужно и достаточно для реализации разных вариантов. Это соответствует идеологии языка, который задуман как удобная абстракция машины, без претензий на удовлетворение каких-либо особых потребностей кого-то из прикладников. Цель - поднять абстракции и надёжность языка максимально, насколько это возможно без потери исходных возможностей оборудования.

Кроме того, на каждом витке развития от Модулы до КП и О7 Оберон остаётся бесспорным рабочим инструментом, в который не просочилось ничего спорного и экспериментального, что бы потом висело бесполезным грузом, кандидатом на исключение (а ведь хрен исключишь, из промышленного языка-то).

Так что:
Цитата:
Понимания того, что язык разработки должен объединять и язык моделирования, и язык проектирования, и язык программирования... не наблюдается.

ДОЛЖЕН - в будущем. Когда, наконец, разберёмся с моделированием, настолько ясно, насколько Вирт разобрался с программированием и чисто-программным проектированием.
Любые эксперименты можно делать поверх языка, библиотечно или инструментом типа CASE.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 19 Сентябрь, 2011 13:05 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 2046
alexus писал(а):
...
Да, я согласен с Вами. Возможно, так и должно быть... без веры ничего не получится, а вера антипод сомнениям и размышлениям.
Она и динамичной может быть... Мне, скажем, вера в когнитивную эффективность техноязыка не помешала согласиться с тем, что ради достижения изоморфии с дракон-силуэтом не нужно тащить в маршрутный подъязык текстового инфор-языка явные БП, если их там не должно быть... ;) А в результате была выявлена изоморфная силуэту запись маршрутов без явных БП по шампур-методу (через цикл Дейкстры). Правда, здесь тоже не без веры... только уже Фёдору Васильевичу и его единомышленникам... :)
alexus писал(а):
...
С Oberon та же проблема. Он является прямым продолжением Модулы... и по-прежнему является процедурно-модульным языком. Объекты в нём - это "подарок бедным"...
Как раз хотел прояснения Вашей позиции насчёт Оберон-семейства... Вы так оцениваете на основании знакомства с сутью механизмов - хотя бы по публикации Свердлова? Или по материалам этой темы?
alexus писал(а):
...
Понимания того, что язык разработки должен объединять и язык моделирования, и язык проектирования, и язык программирования... не наблюдается. Фактически остаются паллиативные решения типа UML... куцые, мультикорневые... бестолковые (если кратко).
...
Пока не ставится задача конкретной гибридизации - так и будет, полагаю... Как только сосредотачиваемся на изоморфии конкретному языку/набору языков - выявляется, что надо от новой формы записи. И ведь у "автоматчиков" то же было - подошли они со своей парадигмой к юмлю - и появились "прецизионные", "исполнимые" его определения... не знаю только, избавило ли это его вполне от тех свойств, которые Вы отметили... :)
Кстати, если подумать - то объединение тоже можно ведь сначала проводить для текстового базиса. Скажем - Оберон и Promela... А дальше - думать над визуализацией комплекса...
Да, язык проектирования - что это в Вашем понимании? Чем отличается?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 19 Сентябрь, 2011 15:44 
Аватара пользователя

Зарегистрирован: Суббота, 27 Февраль, 2010 23:34
Сообщения: 746
Илья Ермаков писал(а):
alexus писал(а):
С Oberon та же проблема. Он является прямым продолжением Модулы... и по-прежнему является процедурно-модульным языком. Объекты в нём - это "подарок бедным"... Понимания того, что язык разработки должен объединять и язык моделирования, и язык проектирования, и язык программирования... не наблюдается.
На самом деле объекты в нём - не "подарок бедным", а экстракт МЕХАНИЗМОВ ООП. Т.е. то, что нужно и достаточно для реализации разных вариантов. Это соответствует идеологии языка, который задуман как удобная абстракция машины, без претензий на удовлетворение каких-либо особых потребностей кого-то из прикладников. Цель - поднять абстракции и надёжность языка максимально, насколько это возможно без потери исходных возможностей оборудования.
Мы с Вами, как всегда, исходим из разных парадигм. Для Вас, как я понимаю, ООП - это простое развитие языков программирования. И для написания программ, сделанного Н. Виртом, наверное, достаточно.
Для меня ООП - это средство моделирования/проектирования систем. И здесь, сделанных Н. Виртом в Обероне расширений, совершенно недостаточно. (Речь идёт, именно, о получении высококачественных абстракций/моделей!) В этом и проблема, что Н. Вирт, как впрочем и адепты ООП, не пытается рассматривать ООП, как средство моделирования систем (а для написания программ ООП, как правило, избыточен).
Илья Ермаков писал(а):
Так что:
Цитата:
Понимания того, что язык разработки должен объединять и язык моделирования, и язык проектирования, и язык программирования... не наблюдается.
ДОЛЖЕН - в будущем. Когда, наконец, разберёмся с моделированием, настолько ясно, насколько Вирт разобрался с программированием и чисто-программным проектированием.
Любые эксперименты можно делать поверх языка, библиотечно или инструментом типа CASE.
При чём здесь эксперименты?.. Попробуйте с помощью библиотек смоделировать/спроектировать систему... Н. Вирт был прекрасным алгоритмистом... и остаётся им... И его "довесок" в виде ООП - это не потребность Оберон, а нечто вроде... "Хотите ООП?.. Нате вам... только отвяжитесь"... Что можно сделать нового с помощью ООП в Оберон, чего бы нельзя было сделать без него [без ООП]?..


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 19 Сентябрь, 2011 16:00 
Аватара пользователя

Зарегистрирован: Суббота, 12 Июль, 2008 22:49
Сообщения: 573
Откуда: Россия, Санкт-Петербург
alexus писал(а):
При чём здесь эксперименты?.. Попробуйте с помощью библиотек смоделировать/спроектировать систему... Н. Вирт был прекрасным алгоритмистом... и остаётся им... И его "довесок" в виде ООП - это не потребность Оберон, а нечто вроде... "Хотите ООП?.. Нате вам... только отвяжитесь"... Что можно сделать нового с помощью ООП в Оберон, чего бы нельзя было сделать без него [без ООП]?..

А что вы скажете про Active Oberon. Где присутствует определённая сущность OBJECT, которая обладает конретными свойствами и даже своей нитью выполнения?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 19 Сентябрь, 2011 16:56 

Зарегистрирован: Пятница, 20 Июль, 2007 17:26
Сообщения: 693
Откуда: Псков
Компилятор Оберона генерит код для целевого процессора.
Компилятор ЯзыкаМоделированияСистем генерит Оберон-код.
Дело за малым - Report ЯзыкаМоделированияСистем. :)


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Система языков формализации
СообщениеДобавлено: Понедельник, 19 Сентябрь, 2011 17:06 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 2046
М.б. не совсем так - язык проектирования (допустим, визуальный на базе шампур-метода - чтобы не отклоняться от топика сильно ;)) генерит код (исхтекст) и на языке программирования (Оберон) - и на языке моделирования (Promela)? Правда, поставленный Вами вопрос (об определении проект-языка или хотя бы его концепции - включая соотношение с другими языками триады) это не снимает... :) Но не всё сразу, наверное - для этого и данная линия обсуждения (которую, вероятно, со временем надо отделить будет :wink:)...


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 19 Сентябрь, 2011 17:13 
Аватара пользователя

Зарегистрирован: Суббота, 12 Июль, 2008 22:49
Сообщения: 573
Откуда: Россия, Санкт-Петербург
albobin писал(а):
Компилятор Оберона генерит код для целевого процессора.
Компилятор ЯзыкаМоделированияСистем генерит Оберон-код.
Дело за малым - Report ЯзыкаМоделированияСистем. :)

Советую ознакомится с "Composita" - язык моделирования систем, надстройка над Active Oberon.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 19 Сентябрь, 2011 17:27 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 2046
Интересно... кто разбирается - у этого языка те же цели и задачи, что у Promela (исходя из этого описания второго, скажем)?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 19 Сентябрь, 2011 17:30 
Аватара пользователя

Зарегистрирован: Суббота, 27 Февраль, 2010 23:34
Сообщения: 746
Драконограф писал(а):
alexus писал(а):
Да, я согласен с Вами. Возможно, так и должно быть... без веры ничего не получится, а вера антипод сомнениям и размышлениям.
Она и динамичной может быть...
Она обязана быть динамичной. Собственно, есть два понимания "веры". Первое - это чужое мнение принятое без сомнений и размышлений. Назовём эту веру - вера в авторитет. Вторая вера основана на внутреннем понимании сути предмета или явления, результат озарения. Это вера в Истину. Первая вера статична (если авторитет больше не высказывается по данной теме). Вторая вера всегда в динамике, поскольку суть постоянно раскрывает (как правило, неожиданно) новые грани предмета или явления. Я говорю о второй вере... только.
Драконограф писал(а):
Мне, скажем, вера в когнитивную эффективность техноязыка не помешала согласиться с тем, что ради достижения изоморфии с дракон-силуэтом не нужно тащить в маршрутный подъязык текстового инфор-языка явные БП, если их там не должно быть... ;) А в результате была выявлена изоморфная силуэту запись маршрутов без явных БП по шампур-методу (через цикл Дейкстры). Правда, здесь тоже не без веры... только уже Фёдору Васильевичу и его единомышленникам... :)
Не могу комментировать, поскольку info21 в чёрном списке... не читаю.
Драконограф писал(а):
alexus писал(а):
С Oberon та же проблема. Он является прямым продолжением Модулы... и по-прежнему является процедурно-модульным языком. Объекты в нём - это "подарок бедным"...
Как раз хотел прояснения Вашей позиции насчёт Оберон-семейства... Вы так оцениваете на основании знакомства с сутью механизмов - хотя бы по публикации Свердлова?
Так что можно добавить к этому:
Вложение:
Sverdlov1.png
Sverdlov1.png [ 25.78 КБ | Просмотров: 7673 ]
(стр. 107) Речь идёт о разработке программ... Применительно к программам все правильно, хотя появляются вопросы о том, что такое "объектная манера мышления" и зачем она нужна?..
Драконограф писал(а):
Или по материалам этой темы?
Здесь обсуждаются частные вопросы... (после просмотра 2-х страниц)...
Драконограф писал(а):
alexus писал(а):
Понимания того, что язык разработки должен объединять и язык моделирования, и язык проектирования, и язык программирования... не наблюдается. Фактически остаются паллиативные решения типа UML... куцые, мультикорневые... бестолковые (если кратко).
...
Пока не ставится задача конкретной гибридизации - так и будет, полагаю... Как только сосредотачиваемся на изоморфии конкретному языку/набору языков - выявляется, что надо от новой формы записи. И ведь у "автоматчиков" то же было - подошли они со своей парадигмой к юмлю - и появились "прецизионные", "исполнимые" его определения... не знаю только, избавило ли это его вполне от тех свойств, которые Вы отметили... :)
Кстати, если подумать - то объединение тоже можно ведь сначала проводить для текстового базиса. Скажем - Оберон и Promela... А дальше - думать над визуализацией комплекса...
Да, язык проектирования - что это в Вашем понимании? Чем отличается?
Графика + справочники + формальное текстовое описание (если очень кратко). Для примера можно рассмотреть работу конструктора, материаловеда, проектировщиков-строителей... программистов (аналитиков).


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 19 Сентябрь, 2011 17:31 
Аватара пользователя

Зарегистрирован: Суббота, 27 Февраль, 2010 23:34
Сообщения: 746
Madzi писал(а):
alexus писал(а):
При чём здесь эксперименты?.. Попробуйте с помощью библиотек смоделировать/спроектировать систему... Н. Вирт был прекрасным алгоритмистом... и остаётся им... И его "довесок" в виде ООП - это не потребность Оберон, а нечто вроде... "Хотите ООП?.. Нате вам... только отвяжитесь"... Что можно сделать нового с помощью ООП в Оберон, чего бы нельзя было сделать без него [без ООП]?..
А что вы скажете про Active Oberon. Где присутствует определённая сущность OBJECT, которая обладает конретными свойствами и даже своей нитью выполнения?
Ничего не скажу, поскольку не вижу в этом какого-то принципиального решения (тем паче, концепции).


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 19 Сентябрь, 2011 18:24 

Зарегистрирован: Пятница, 20 Июль, 2007 17:26
Сообщения: 693
Откуда: Псков
Madzi писал(а):
albobin писал(а):
Компилятор Оберона генерит код для целевого процессора.
Компилятор ЯзыкаМоделированияСистем генерит Оберон-код.
Дело за малым - Report ЯзыкаМоделированияСистем. :)

Советую ознакомится с "Composita" - язык моделирования систем, надстройка над Active Oberon.

Это всё не то - это всё вариации Оберона Вирта. Интересно узнать, чего же это такое - "совершенно недостаточно" из недавнего поста.
Расширяемые структуры данных, процедурные типы, модули ... что ещё надо? или что-то совсем иное? Хотелось бы узнать, а что будет "совершенно достаточно"? :)


Последний раз редактировалось albobin Понедельник, 19 Сентябрь, 2011 18:31, всего редактировалось 1 раз.

Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 19 Сентябрь, 2011 18:27 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 2046
alexus писал(а):
...
Драконограф писал(а):
Мне, скажем, вера в когнитивную эффективность техноязыка не помешала согласиться с тем, что ради достижения изоморфии с дракон-силуэтом не нужно тащить в маршрутный подъязык текстового инфор-языка явные БП, если их там не должно быть... ;) А в результате была выявлена изоморфная силуэту запись маршрутов без явных БП по шампур-методу (через цикл Дейкстры). Правда, здесь тоже не без веры... только уже Фёдору Васильевичу и его единомышленникам... :)
Не могу комментировать, поскольку info21 в чёрном списке... не читаю.
Жаль... если отталкивает частая категоричность суждений - так она тоже не "статична". ;) Скажем, по тому же техноязыку - отношение в этом посте оценивалось как негативное. Однако когда выяснилось, что метод позволяет выразить на языке и иной подход к программированию, чем предложен создателем техноязыка - в этом посте никакого негатива не обнаружилось... :) Впрочем, это м.б. личное - и не могу настаивать на изменении отношения...
Скажем так - Илье Евгеньевичу и его единомышленникам... :)


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 19 Сентябрь, 2011 18:43 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 2046
albobin писал(а):
...
Это всё не то - это всё вариации Оберона Вирта. Интересно узнать, чего же это такое - "совершенно недостаточно" из недавнего поста.
Расширяемые структуры данных, процедурные типы, модули ... что ещё надо? или что-то совсем иное? Хотелось бы узнать, а что будет "совершенно достаточно"? :)
Мне кажется, вы о разных "схемах" говорите - Madzi (как и alexus) - о "внешней", Вы - о "нейтральной". В смысле, описанном в этом посте, скажем. Причём, конкретное представление (здесь - как FBD-схем) нейтральное или внешнее - зависит ещё и от реализации.
Всё, что Вы перечисляете - не для внешних представлений - там, условно говоря, "деталь имеет тип детали, если она соответствует чертежу детали со всеми свойствами, представленными в предметно-специфических обозначениях".


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 19 Сентябрь, 2011 18:57 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9139
Откуда: Россия, Орёл
alexus писал(а):
И его "довесок" в виде ООП - это не потребность Оберон, а нечто вроде... "Хотите ООП?.. Нате вам... только отвяжитесь"... Что можно сделать нового с помощью ООП в Оберон, чего бы нельзя было сделать без него [без ООП]?..


Вот и нет. ООП позволило делать динамически расширяемые системы. Собственно, Вирт и сделал язык для написания своей новой ОС. Компонентное программирование, как течение в индустрии, началось как раз с того, что Вирт включил ООП в Оберон. Добавил к динамической модульности полиморфизм (динамическое связывание).
Что из этого вышло, мы знаем, например, по работам Шиперского: http://oberoncore.ru/library/start (Object-orinetation in operation systems и Component Software Beyond Object-Oriented Programming).
У нас про это хорошую статью написал Сергей Юрьевич Губанов: http://oberoncore.ru/articles/gubanov

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 19 Сентябрь, 2011 18:58 
Аватара пользователя

Зарегистрирован: Суббота, 27 Февраль, 2010 23:34
Сообщения: 746
Драконограф писал(а):
Жаль... если отталкивает частая категоричность суждений - так она тоже не "статична". ;)
Категоричность суждений, вопреки распространённому мнению, не всегда спутница глупости. Лично меня она ничуть не отталкивает. Но обсуждать/осуждать никого не стану...
Драконограф писал(а):
Скажем так - Илье Евгеньевичу и его единомышленникам... :)
Илье Евгеньевичу я ответил, добавить пока нечего. Разница наших взглядов/рассуждений/умозаключений объясняется выбором подходов (программирование vs. моделирование). За несколько лет, наши подходы ничуть не сблизились (возможно, это объясняется различием в решаемых задачах... но скорее всего... разным мышлением...). С моей точки зрения, программная система - это не набор программ/модулей, это, прежде всего, архитектура... (уровни, интерфейсы, роли, классы, свойства, схемы и протоколы взаимодействия...). И код/кодирование в этой системе понятий... не первичный элемент.
В этой связи... мне совершенно не интересно сравнивать разные языки программирования. На эту тему было много споров, которые сводятся к одному простому выводу: каждый пишет на том, что... лучше знает или на том, на чём требуют. Спорить о языках программирования, с точки зрения ООП, не более продуктивно. В 1992 году в "Мире ПК" я писал про ООП на ассемблере (тогда только вышел TASM 3.x). И "объектность" ассемблера мало чем отличается от "объектности" Оберона (гибкость выше, наглядность ниже... и всё).


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 19 Сентябрь, 2011 19:04 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9139
Откуда: Россия, Орёл
alexus писал(а):
С моей точки зрения, программная система - это не набор программ/модулей, это, прежде всего, архитектура... (уровни, интерфейсы, роли, классы, свойства, схемы и протоколы взаимодействия...). И код/кодирование в этой системе понятий... не первичный элемент.


Полностью с Вами согласен.
Я не представляю программу как текст/код. Я всегда представляю её как инженерную систему. Состоящую из компонент. Взаимодействующих через интерфейсы.
И Оберон (в варианте КП, если Вы не в курсе, то здесь ООП усилено: http://oberon.ch/pdf/CP-New.pdf) позволяет мне хорошо это выражать. Не навязывая никаких шаблонов, позволяя создать свои кубики и соединять их, собирать из них систему. Модульность + полиморфизм - что ещё нужно от языка? Только чтоб не мешал! Оберон не мешает.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 19 Сентябрь, 2011 19:13 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 2046
Илья Ермаков писал(а):
...
Конечно, но это не уровень моделирования, это более низкий уровень компоновки технической системы. Но лучше решить хорошо проблемы одного уровня и оставить другой людям на самостоятельное решение, чем получить неважное решение сразу обоих уровней.
Как я понимаю, Александр всё-таки об уровне моделирования ("нейтральной схеме")... где он также предполагает всё-таки выражение не на прогязыке, а на "предметном"?..


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 19 Сентябрь, 2011 19:17 
Аватара пользователя

Зарегистрирован: Суббота, 27 Февраль, 2010 23:34
Сообщения: 746
Илья Ермаков писал(а):
alexus писал(а):
И его "довесок" в виде ООП - это не потребность Оберон, а нечто вроде... "Хотите ООП?.. Нате вам... только отвяжитесь"... Что можно сделать нового с помощью ООП в Оберон, чего бы нельзя было сделать без него [без ООП]?..
Вот и нет. ООП позволило делать динамически расширяемые системы.
Объявите на процедурном языке интерфейсы и расширяйте любую систему на процедурном языке... Мы писали свою первую систему (для металлургов) на PC-XT (среда Turbo Pascal) именно так (включая overlay's и динамически подгружаемые библиотеки). Никаких объектов не было, а систему расширяли (уже без нас) около десятка лет. Динамические библиотеки и были теми самыми компонентами...
Илья Ермаков писал(а):
Собственно, Вирт и сделал язык для написания своей новой ОС. Компонентное программирование, как течение в индустрии, началось как раз с того, что Вирт включил ООП в Оберон. Добавил к динамической модульности полиморфизм (динамическое связывание).
Полиморфизм на основе интерфейсов... гораздо богаче полиморфизма на основе наследования. Поэтому оценить выбор Н.Вирта положительно, увы...
Илья Ермаков писал(а):
Что из этого вышло, мы знаем, например, по работам Шиперского: http://oberoncore.ru/library/start (Object-orinetation in operation systems и Component Software Beyond Object-Oriented Programming).
У нас про это хорошую статью написал Сергей Юрьевич Губанов: http://oberoncore.ru/articles/gubanov
Статья С.Ю. Губанова замечательная, хотя и не бесспорная. Например, он пишет
С.Ю. Губанов писал(а):
Программирование модульных систем, вообще говоря, не требует обязательного использования объектно-ориентированного подхода и наоборот. Однако, одновременное использование этих двух подходов для построения расширяемых систем привело к появлению новой парадигмы программирования. Дело в том, что ООП, в его наиболее распространённой трактовке, основано на понятии наследования. При совместном использовании ООП и модульности возникнет межмодульное наследование, но оно является препятствием к взаимозаменяемости модулей от различных производителей. Если часть типа определена в одном модуле, а другая часть типа — в другом, то весьма проблематично модуль с базовым типом поменять на аналогичный модуль от другого производителя из-за возможных тонких различий в реализации. В 1995 году, профессор Клеменс Шиперски (Clemens Szyperski) сформулировал основные положения Компонентно-ориентированного подхода (КОП) через ограничения, накладываемые на модульный подход и на ООП для их непротиворечивого одновременного сосуществования («Component-Oriented Programming A Refined Variation on Object-Oriented Programming», The Oberon Tribune, Vol 1, No 2, December 1995). Цель КОП — построение расширяемых (в полном смысле этого слова) систем с помощью модулей и ООП. Таким образом, КОП находится (по мнению Шиперского) «За пределами ООП» (так называется его уже дважды изданная за рубежом книга-бестселлер, к сожалению, до сих пор не переведённая на русский язык). Фундамент КОП образуют: полиморфизм, позднее связывание, настоящая инкапсуляция, полный контроль безопасности со стороны среды времени исполнения.
Замените слово "полиморфизм" на "интерфейсы" и исчезнет "объектность"... Но дело не простой в подмене понятий, а... в последовательности (разноуровневости) проектирования. Верхний уровень декларирует интерфейсы (что ему нужно от нижнего уровня), а нижний уровень группирует интерфейсы и формирует... описание модулей или классов. И т.д.
Илья Ермаков писал(а):
Конечно, но это не уровень моделирования, это более низкий уровень компоновки технической системы. Но лучше решить хорошо проблемы одного уровня и оставить другой людям на самостоятельное решение, чем получить неважное решение сразу обоих уровней.
Вот об этом-то и речь...


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 19 Сентябрь, 2011 20:05 

Зарегистрирован: Пятница, 20 Июль, 2007 17:26
Сообщения: 693
Откуда: Псков
Кстати об интерфейсах. Lagoona - тот же Оберон + "побольше интерфейса" :)
Вирт отлично всё выбрал - самую суть. Небольшие вариации и - вот вам блюдо с фичами.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Моделирование и программирвание
СообщениеДобавлено: Понедельник, 19 Сентябрь, 2011 20:09 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 2046
Я не пойму - так для проекта системы (того, что применительно к деятельности выражается, скажем на UML) предлагается тоже прогязык (скажем, Оберон) использовать?


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 41 ]  На страницу 1, 2, 3  След.

Часовой пояс: UTC + 3 часа


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 1


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Вся информация, размещаемая участниками на конференции (тексты сообщений, вложения и пр.) © 2005-2019, участники конференции «OberonCore», если специально не оговорено иное.
Администрация не несет ответственности за мнения, стиль и достоверность высказываний участников, равно как и за безопасность материалов, предоставляемых участниками во вложениях.
Без разрешения участников и ссылки на конференцию «OberonCore» любое воспроизведение и/или копирование высказываний полностью и/или по частям запрещено.
Powered by phpBB® Forum Software © phpBB Group
Русская поддержка phpBB