OberonCore

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

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




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

Зарегистрирован: Пятница, 20 Июль, 2007 17:26
Сообщения: 693
Откуда: Псков
Драконограф писал(а):
Я не пойму - так для проекта системы (того, что применительно к деятельности выражается, скажем на UML) предлагается тоже прогязык (скажем, Оберон) использовать?

Видимо да , раз было сказано выше, что "сделанных Н. Виртом в Обероне расширений, совершенно недостаточно".


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

Зарегистрирован: Суббота, 27 Февраль, 2010 23:34
Сообщения: 746
Илья Ермаков писал(а):
alexus писал(а):
С моей точки зрения, программная система - это не набор программ/модулей, это, прежде всего, архитектура... (уровни, интерфейсы, роли, классы, свойства, схемы и протоколы взаимодействия...). И код/кодирование в этой системе понятий... не первичный элемент.
Полностью с Вами согласен.
Я не представляю программу как текст/код. Я всегда представляю её как инженерную систему. Состоящую из компонент. Взаимодействующих через интерфейсы.
Строго говоря... элементы не должны взаимодействовать между собой... напрямую. Они должны делать только то, что им предписано... свыше. Сделали и отдали наверх, а кто там и как дальше работает, они не ведают. Если элемент (компонент/объект) А взаимодействует с элементом Б, то это взаимодействие должно быть определено, как минимум в элементе А, но, возможно, и в элементе Б, а это, в свою очередь, означает, что элемент А не может использоваться без элемента Б и, наоборот. Такая связь "цементирует" элементы и лишает систему гибкости (возможности перестраивать связи). "Слабые связи" в системе исчезают... а за ними и сама система становится монолитом, то есть, не-системой.
Илья Ермаков писал(а):
И Оберон (в варианте КП, если Вы не в курсе, то здесь ООП усилено: http://oberon.ch/pdf/CP-New.pdf) позволяет мне хорошо это выражать. Не навязывая никаких шаблонов, позволяя создать свои кубики и соединять их, собирать из них систему. Модульность + полиморфизм - что ещё нужно от языка? Только чтоб не мешал! Оберон не мешает.
Уф... Хорошо, давайте рассуждать... Пусть у нас есть некая предметная область, способная решать некоторое множество задач. Нам надо реализовать это в виде программной системы. Система состоит из элементов и связей, которые она устанавливает/переключает между элементами. На вход системы подаются возмущения/задачи/сообщения, которые решаются (формируется отклик/реакция) с помощью определённой схемы связей между элементами. То есть, пришла некая задача/сообщение, поднимается определённая схема её решения/обработки (сообщения). Таким образом, множество задач спроецированное на заданное множество элементов (их свойств) порождает множество схем (в очень простом случае, множество задач равно множеству схем, но, как правило, количество схем многократно больше множества задач).
Связи, устанавливаемые системой, обращаются к свойствам элементов системы. Всё множество свойств элементов образуют интерфейс системы и элементов. С другой стороны, каждая задача, разложима на шаги, которые и есть свойства элементов/исполнительных устройств системы. Можно произвольно компоновать те или иные свойства, создавая элементы (компоненты/объекты (точнее, классы)). От того, насколько хорошо продуманы интерфейсы (свойства), насколько грамотно они скомпонованы зависит применимость системы для решения задач данных типов, её [системы] эффективность, гибкость и масштабируемость.
Элементы являются исполнителями... с точки зрения системы, но они могут быть очень далеки от реальной исполнительной среды, то есть, они сами могут являться системами. В этом случае, свойства элемента, это те возмущения/задачи/сообщения, с которыми обращаются к элементу, а сам элемент состоит из под-элементов, по которым он распределяет задания в полном соответствии с некоторыми собственными схемами. И т.д. пока не дойдём до реального исполнительного уровня (машинных команд, операторов языка программирования и т.п.).
Отдельно можно рассказывать о формировании интерфейсов, их группировки на основе ролей, о их проекции на свойства классов/компонентов, о формировании схем... Всё это проще и удобнее делать с помощью декларативно-визуальных средств/инструментов, способных интегрировать самые разные средства визуального и текстового программирования. Ну, не случайно же обрели такую популярность средства визуального представления форм (диалоговых окон), построителей схем баз данных и пр. и пр. (Диалоговое окно - визуальная декларация, схема базы данных - декларация на IDEF, ERWin... или DDL SQL).
Как всё это можно сделать в рамках Оберон, КП или Дракона для любых видов систем?.. А ведь ещё не рассмотрены не самые простые вопросы параллельной работы, разделяемых (& persistent) элементов и т.п.


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

Зарегистрирован: Суббота, 27 Февраль, 2010 23:34
Сообщения: 746
Драконограф писал(а):
Илья Ермаков писал(а):
Конечно, но это не уровень моделирования, это более низкий уровень компоновки технической системы. Но лучше решить хорошо проблемы одного уровня и оставить другой людям на самостоятельное решение, чем получить неважное решение сразу обоих уровней.
Как я понимаю, Александр всё-таки об уровне моделирования ("нейтральной схеме")... где он также предполагает всё-таки выражение не на прогязыке, а на "предметном"?..
Моделирование, проектирование и программирование - это три фазы одного процесса, они имеют существенные различия, но и... один и тот же предмет (одну и ту же предметную область). И, в этом случае, они обязаны быть формальными и совместимыми. Имеет смысл рассмотреть такую метафору: есть предметная область, которая проецируется с помощью средств/языка моделирования в модели предметной области. Модели предметной области уточняются, дорабатываются, сравниваются... до тех пор пока не получается модель наиболее адекватная (по ключевым характеристикам) своей предметной области/оригиналу.
Та же предметная область, но уже в виде модели проецируется с помощью средств проектирования/языка проектирования на проекты. Проекты разрабатываются, сравниваются... пока не получен проект наиболее адекватный модели при минимальных затратах на реализацию.
Наконец, та же предметная область в виде проекта реализуется с помощью тех или иных средств разработки.

Какая "схема" является "нейтральной"?


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

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


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

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


Конечно, это так. Но во многих случаях надсистема не занимается "ручной передачей" каждого события между компонентами. Надсистема соединяет их какими-нибудь коммуникациями, трубами. Коммуникации и их установление относятся к надсистеме, конечно. Но протекание события от одной подсистемы другой потом уже идёт без прямого вмешательства надсистемы (хотя она всегда может пересоединить, если что). Так что косвенный вызов через полиморфный указатель, когда вызывающий знает только абстрактный тип (интерфейс) и не знает, какая там реализация на другом конце вызова, как раз похож на такую трубу.

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

Рассмотрим пример на КП. Имена на русском для понятности.

Код:
MODULE Телефония;

   TYPE
      Линия* = POINTER TO ABSTRACT RECORD END;
      Сеанс* = POINTER TO ABSTRACT RECORD END;
      Реализация* = POINTER TO ABSTRACT RECORD END;

   VAR
      стандартная-: Реализация;

   PROCEDURE (л: Линия) Звонить* (номер): Сеанс, NEW, ABSTRACT;
   PROCEDURE (л: Линия) Входящий* (): Сеанс, NEW, ABSTRACT;

   PROCEDURE (сн: Сеанс) Сказать* (сообщение), NEW, ABSTRACT;
   PROCEDURE (сн: Сеанс) Слушать* (сообщение), NEW, ABSTRACT;
   PROCEDURE (сн: Сеанс) Закрыть*, NEW, ABSTRACT;

   PROCEDURE (р: Реализация) НоваяЛиния* (): Линия, NEW, ABSTRACT;

   PROCEDURE ЗадатьСтандартную* (реализация: Реализация);
   BEGIN
      стандартная := реализация
   END ЗадатьСтандартную;

END Телефония.

MODULE Секретари;
   IMPORT Телефония;

   TYPE
      Секретарь* = ABSTRACT RECORD END;
      Реализация* .... аналогично ....
   
    VAR
      стандартная*: Реализация;

   .... разные процедуры секретаря ...
   PROCEDURE (с: Секретарь) СестьНаТелефон* (линия: Телефония.Линия), NEW, ABSTRACT;
   PROCEDURE (с: Секретарь) Помогать* (кому: Секретарь), NEW, ABSTRACT;

END Секретари.


Реальных реализаций телефонии и секретарей у нас может быть много. В разных модулях. Никто в системе, кроме конфигурирующих процедур, не знает про эти модули.
Стандартные реализации привязывает какой-нибудь конфигурирующий модуль:
Код:
MODULE Config;
   PROCEDURE Setup;
   BEGIN
      Телефония.ЗадатьСтандартную(ТелефонияВариант1.реализация);
      Секретари.ЗадатьСтандартную(СекретариВариант1.реализация)
   END Setup;
END Config;


Специфические для нашего приложения особенности вынесем в наш модуль конфигурации:
Код:
MODULE НашиРесурсы;
   IMPORT Телефония, СекретариВариантЭкстра;
   VAR
      телефония-: Телефония.Реализация;
      секретари-: Секретари.Реализация;

   PROCEDURE Иниц;
   BEGIN
      телефония := Телефония.стандартная;
      секретари := СекретариВариантЭкстра.реализация;
   END Иниц;

BEGIN
   Иниц
END НашиРесурсы;


Наконец, есть наш прикладной модуль:

Код:
MODULE НашОфис;
   IMPORT Телефония, Секретари, НашиРесурсы;

   VAR
      телЛиния: Телефония.Линия;
      секретарь1, секретарь2: Секретари.Секретарь;
   
   PROCEDURE Иниц;
   BEGIN
      телЛиния := НашиРесурсы.телефония.НоваяЛиния();
      секретарь1 := НашиРесуры.секретари.НовыйСекретарь();
      секретарь2 := НашиРесурсы.секретари.НовыйСекретарь();
      секретарь1.СестьНаТелефон(телЛиния);
      секретарь2.Помогать(секретарь1)
   END Иниц;

END НашОфис.


Пожалуйста, ни реализация секретарей, ни реализация телефонии не знают друг про друга. Модуль НашОфис вообще ничего не знает, где реализованы эти компоненты. Он создаёт их экземпляры через абстрактные фабрики и соединяет. И они начинают вместе работать.
Модуль НашиРесурсы, как отдел обеспечения, знает немного больше про то, какие реализации используются. Но тщательно скрывает эти детали от модуля НашОфис. Но и то, телефонию он использует стандартную, и только для секретарей "заморачивается" знанием конкретной реализации.

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

Получаем расширяемую, изменяемую, в том числе динамически, систему. Компонентную.


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

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

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

Возможно, со временем появится лаконичная и достаточно универсальная CASE-технология. Не исключаю. Но пока над ней только думают... Я и сам не прочь подумать :)

Цитата:
Как всё это можно сделать в рамках Оберон, КП или Дракона для любых видов систем?.. А ведь ещё не рассмотрены не самые простые вопросы параллельной работы, разделяемых (& persistent) элементов и т.п.

Ну зачем обязательно для любых? Пусть даже для 80% случаев (по частоте столкновения с ними программистов). Известно же соотношение 80/20 - 20% случаев потребуют на 80% более сложного решения. Зачем таскать эту сложность с собой всегда? Если я могу её надстроить в тот момент, когда мне встретится случай из тех 20%.


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

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


Последний раз редактировалось alexus Вторник, 20 Сентябрь, 2011 06:48, всего редактировалось 1 раз.

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

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


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

Зарегистрирован: Суббота, 27 Февраль, 2010 23:34
Сообщения: 746
Илья Ермаков писал(а):
alexus писал(а):
Всё это проще и удобнее делать с помощью декларативно-визуальных средств/инструментов, способных интегрировать самые разные средства визуального и текстового программирования. Ну, не случайно же обрели такую популярность средства визуального представления форм (диалоговых окон), построителей схем баз данных и пр. и пр. (Диалоговое окно - визуальная декларация, схема базы данных - декларация на IDEF, ERWin... или DDL SQL).
Эти инструменты уже заточены на определённые ниши и на порядок сложнее в реализации, при приросте эффективности не слишком большом, кроме случаев, когда автоматизируются массовые задачи. А если сегодня коллектив решает задачу из одной области, завтра - из другой, овчинка и выделки не стоит.
Очевидно, должен быть и другой коллектив, который видит общие части самых разных задач, и обобщает частности и доводит их до простого декларативно-визуального решения/инструмента/языка.
И желательно... чтобы был ещё третий коллектив, который бы видел всё множество решений/инструментов/языков и систематизировал их...
Илья Ермаков писал(а):
Возможно, со временем появится лаконичная и достаточно универсальная CASE-технология. Не исключаю. Но пока над ней только думают... Я и сам не прочь подумать :)
Вряд ли это будет CASE-технология...


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

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

Я имел в виду - параллелизм отдельно от описания алгопроцессов (допустим, в их импер-части - на ДРАКОНе). Отдельным языком описания систем взаимодействующих алгопроцессов (с "расщеплениями рабочих точек" по терминологии, сложившейся в этой теме). Подробнее уже излагал - в этом посте, скажем.
А примитивы взаимодействия - конечно, при спускании на уровень алгопроцессов представляются через операции прогязыка... который не обязан поддерживать специально это. И тогда опять же всё представляется через базовые операции с памятью (м.б. - с портами). Как Вирт сделал в выдержке из этого поста. Так ведь?

Таковы представления. Вот ещё по системности моделирования - этот пост. Вы согласитесь с сказанным мной (и/или Рэйлвей Кагеном)? или есть по каким-то затронутым вещам своё представление?


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

Зарегистрирован: Понедельник, 30 Июль, 2007 10:53
Сообщения: 1538
Откуда: Беларусь, Минск
alexus писал(а):
Связи, устанавливаемые системой, обращаются к свойствам элементов системы. Всё множество свойств элементов образуют интерфейс системы и элементов. С другой стороны, каждая задача, разложима на шаги, которые и есть свойства элементов/исполнительных устройств системы.
Что-то я не понимаю, что Вы имеете в виду под свойством. Мне так кажется, что интерфейс - это характеристика другого типа. Интерфейс - это то, как мы можем применить элемент, а свойство - это нечто другое. Я думаю, что нельзя назвать свойством палки её применимость в качестве пАлицы.


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

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


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

Зарегистрирован: Суббота, 27 Февраль, 2010 23:34
Сообщения: 746
Valery Solovey писал(а):
Что-то я не понимаю, что Вы имеете в виду под свойством.
Свойство?.. Нечто внутреннее присущее данной сущности. Характеристика - это внешнее представление о свойствах сущности. В программировании свойство может быть представлено переменной (простой или составной) или подпрограммой (функцией/методом). Например, общее свойство материальных предметов - иметь вес; характеристика - вес; переменная - weight; методы - GetWeight и SetWeight.
Valery Solovey писал(а):
Мне так кажется, что интерфейс - это характеристика другого типа. Интерфейс - это то, как мы можем применить элемент, а свойство - это нечто другое. Я думаю, что нельзя назвать свойством палки её применимость в качестве пАлицы.
Интерфейс - это способность к взаимодействию. "Применимость в качестве" позволяет перейти к понятию "Роль". "Роль" - это поименованная совокупность интерфейсов. Любой предмет, обладающий необходимыми интерфейсами и соответствующими характеристиками, может выступать в данной роли. Например, для того чтобы выступать в роли палицы, предмет должен иметь определённые характеристики: длину, вес, диаметр и пр.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: О взаимодействии процессов
СообщениеДобавлено: Среда, 21 Сентябрь, 2011 07:21 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 2046
alexus в viewtopic.php?p=65729#p65729 писал(а):
...
Взаимодействие - тоже не совсем точный термин, поскольку взаимодействовать могут процессы протекающие параллельно, псевдо-параллельно, последовательно и псевдо-последовательно. Мне привычнее говорить о точках синхронизации, под которыми понимается ожидание завершения последнего параллельного действия процесса/потока/нити. Считается, что все действия происходят параллельно, если нет явной или косвенной точки синхронизации. Явная точка синхронизации устанавливается разработчиком для целей отладки, например. Косвенная точка синхронизации формируется логикой выполнения параллельных действий.
...
Да, конечно... мне тоже более уместным кажется определение "совместно протекающие взаимодействующие процессы"... только я его тут сократил. :)
alexus в viewtopic.php?p=65729#p65729 писал(а):
...
Это довольно большая тема. Подчеркну главную мысль... Любые действия должны иметь возможность протекать параллельно без внесения изменения в код (т.е. это режим по умолчанию). И только в случае необходимости явного указания последовательности действий в код вводятся специальные операции синхронизации/сериализации. Неявная синхронизация/сериализация формируется на этапе компиляции, например, на основе зависимостей по данным.
...
Должны, конечно... и то, что по умолчанию, д.б. также запрограммировано. Так, у Вирта, как я понимаю, приведён код рандеву-операторов (send/receive) для случая "все совместно протекающие алгопроцессы в общей памяти и через неё взаимодействуют".


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

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

Да, по конкретному достижению перспективы высказался в этом посте. Если есть что сказать (поддержать заявку, скажем) - давайте. :)


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

Зарегистрирован: Суббота, 27 Февраль, 2010 23:34
Сообщения: 746
Драконограф писал(а):
...
Иногда не так просто провести грань между абстрактным и реальным... В любом случае, мы оперируем некоторыми собственными представлениями... то есть, моделями, то есть, абстракциями.
Конечно - и отображение типов на исполнителя имеет место.
Нет, про исполнителя речи пока ещё не идёт... Это более общая проблема наподобие... общего и частного.
Драконограф писал(а):
Только это уже переход от "нейтральной" схемы ко "внутренней" - что есть задача алгоритмически реализуемая... транслятором. Конечно, среди прочего там и различные пути виртуализации м.б. заложены.
Да, транслятор частично решает эту задачу, но полностью она решается только при старте/загрузке программы в память, так как код программы сам содержит множество описаний, которые используются загрузчиком и др. служебными программами. То есть, окончательная персонификация "копии программы" происходит... при ее старте.
Драконограф писал(а):
alexus писал(а):
ДРАКОН - алгоритмический язык, и Вы правы, в том, что он не имеет необходимой декларативной части. Он говорит/записывает то, как надо выполнять то или иное действие. Но он не отражает контекст исполнения, не вводит декларацию сущностей, их состояний и взаимосвязей... И в этом смысле, он не пригоден для построения систем.
Ну да... и у того же Ярослава при создании ДРОНа это проявилось. Пришлось ему всё неимперативное в комментарии текстом помещать... такая вот "гибридизация"... :)
Текстом или образом... не принципиально, принципиальны внутренние связи, чтобы изменения в одной части/на одной стадии адекватно представлялись в других частях/на других стадиях и... в документации, конечно. Не менее важно поддерживать вариантность (управление изменениями).
При этом рефакторинг, как явление, необходимо предать массовому осуждению... жестче, чем пресловутый GoTo.
Драконограф писал(а):
В то же время он выводы сделал. Как стало понятно при анализе его постов - он пошёл в русле предварительной классификации представлений, данной здесь (независимо, конечно :)) - и предложил свой вид структуризации деклар-знаний. Разумеется, можно и нужно идти дальше - включая и актив-знание, хотя бы как здесь. И это (и не только) задача на перспективу.
А может быть можно пойти более коротким путём?.. Интерфейсы(*) - группы/роли - классификация - сущности - рабочая/исполнительская среда (возможность взаимодействия сущностей для решения задач/возмущений)
(*) Речь идёт о над-интерфейсах, посредством которых система взаимодействует с над-системой, получает от неё задачи и ресурсы... и куда возвращает результаты/реакции.

PS. Надо иметь ввиду принципиальное отличие построения системы от программы. Программа решает конкретную задачу (иногда подмножество связанных задач). Поэтому в основе программы лежит алгоритм. Система не решает задач сама по себе, она формирует среду решения задач. Графический интерфейс - набор элементов - совершенно бесполезен сам по себе, но с его помощью можно удобно взаимодействовать с пользователями при решении огромного количества самых разных задач. Точно также СУБД не имеют не малейшего смысла сами по себе, пока кто-то не воспользуется ими для решения каких-то задач. И т.д. и т.п.
Поэтому подходы к построению программ и систем - это разные подходы. Визуальный набор средств для создания систем будет в корне отличаться от... Дракона. (могу пояснить примером... из жизни... если это необходимо/полезно).


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

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 2046
Илья Ермаков в viewtopic.php?p=65671#p65671 писал(а):
alexus в viewtopic.php?p=65666#p65666 писал(а):
...
...
Рассмотрим пример на КП. Имена на русском для понятности.
Код:
...
...
Ну что ж, Илья Евгеньевич дал пример употребления КП-Родного. Который Виталий Валерьевич в своё время определял в "Решении сложных задач" (Гл.2 в выдержке).


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

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 2046
alexus писал(а):
Драконограф писал(а):
...
Конечно - и отображение типов на исполнителя имеет место.
Нет, про исполнителя речи пока ещё не идёт... Это более общая проблема наподобие... общего и частного.
Да, пока не нужно переходить ко внутренней схеме (от нейтральной) - не идёт.
alexus писал(а):
...
Драконограф писал(а):
Только это уже переход от "нейтральной" схемы ко "внутренней" - что есть задача алгоритмически реализуемая... транслятором. Конечно, среди прочего там и различные пути виртуализации м.б. заложены.
Да, транслятор частично решает эту задачу, но полностью она решается только при старте/загрузке программы в память, так как код программы сам содержит множество описаний, которые используются загрузчиком и др. служебными программами. То есть, окончательная персонификация "копии программы" происходит... при ее старте.
Согласен... вероятно, так же можно говорить об инструкциях "человеку-как-машине". :)
alexus писал(а):
...
Драконограф писал(а):
...
Ну да... и у того же Ярослава при создании ДРОНа это проявилось. Пришлось ему всё неимперативное в комментарии текстом помещать... такая вот "гибридизация"... :)
...
Текстом или образом... не принципиально, принципиальны внутренние связи, чтобы изменения в одной части/на одной стадии адекватно представлялись в других частях/на других стадиях и... в документации, конечно. Не менее важно поддерживать вариантность (управление изменениями).
При этом рефакторинг, как явление, необходимо предать массовому осуждению... жестче, чем пресловутый GoTo.
Почему бы и нет?.. А если изменения понимаются как варианты - то вместо этого что-то подобное механизму областей предполагается?
alexus писал(а):
...
Программа решает конкретную задачу (иногда подмножество связанных задач). Поэтому в основе программы лежит алгоритм. Система не решает задач сама по себе, она формирует среду решения задач. Графический интерфейс - набор элементов - совершенно бесполезен сам по себе, но с его помощью можно удобно взаимодействовать с пользователями при решении огромного количества самых разных задач. Точно также СУБД не имеют не малейшего смысла сами по себе, пока кто-то не воспользуется ими для решения каких-то задач. И т.д. и т.п.
Поэтому подходы к построению программ и систем - это разные подходы. Визуальный набор средств для создания систем будет в корне отличаться от... Дракона. (могу пояснить примером... из жизни... если это необходимо/полезно).
Безусловно! :) Именно это и имелось в виду как одно из назначений подфорума, заявленного здесь. А пока о нём речи не идёт - тут, наверное. :) Кстати, при этом концептуальные вопросы прояснить - допустим, такие: система алгоритмической части не содержит? и интерфейсу оператора в его прогязыковом ("нейтрализованном") представлении не соответствует алгопроцесс прорисовки/заполнения его формы (как вариант для управления неконсольного - и м.б. вообще чисто "схемокодированного" - индикации/считывания на пульте)?


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

Зарегистрирован: Суббота, 27 Февраль, 2010 23:34
Сообщения: 746
Драконограф писал(а):
alexus писал(а):
При этом рефакторинг, как явление, необходимо предать массовому осуждению... жестче, чем пресловутый GoTo.
Почему бы и нет?.. А если изменения понимаются как варианты - то вместо этого что-то подобное механизму областей предполагается?
Предполагается несколько иное... Я уже говорил о схемах. Схема - это распределение внешнего/внутреннего воздействия/возмущения/сообщения/запроса/задания по элементам системы. На одно и то же воздействие может быть несколько разных схем, выбор нужной схемы определяется состоянием системы. (Состояние не всегда является статическим, оно может быть и динамическим/переходным... но это очень трудная задача, как правило). Схема - это ничто иное, как алгоритм работы системы... с одной стороны. С другой стороны, это основа для расписания работы элементов (для большого класса систем - это очень важный момент).
В схеме указывается, кто, что, когда делает, иногда указывается объём или время выполнения работ (в системах реального времени, например). "Кто" - какой элемент системы. "Что" - тип работы или результата. "Когда" - время начала работы, может быть абсолютным (в 12:30:00:000 21.09.2011) или относительным (по завершении работы предыдущего[их] элемента[ов], например). После выполнения работы, элемент сам или отдельная служба может (если необходимо) фиксировать фактические параметры кто, что, когда и сколько... для последующего анализа, расчётов и пр. (В программных системах фактическая часть используется довольно редко, опять же в основном в real-time systems).
Сказанное, конечно, не имеет отношения к рефакторингу...
Драконограф писал(а):
alexus писал(а):
Программа решает конкретную задачу (иногда подмножество связанных задач). Поэтому в основе программы лежит алгоритм. Система не решает задач сама по себе, она формирует среду решения задач. Графический интерфейс - набор элементов - совершенно бесполезен сам по себе, но с его помощью можно удобно взаимодействовать с пользователями при решении огромного количества самых разных задач. Точно также СУБД не имеют не малейшего смысла сами по себе, пока кто-то не воспользуется ими для решения каких-то задач. И т.д. и т.п.
Поэтому подходы к построению программ и систем - это разные подходы. Визуальный набор средств для создания систем будет в корне отличаться от... Дракона. (могу пояснить примером... из жизни... если это необходимо/полезно).
Безусловно! :) Именно это и имелось в виду как одно из назначений подфорума, заявленного здесь. А пока о нём речи не идёт - тут, наверное. :) Кстати, при этом концептуальные вопросы прояснить - допустим, такие: система алгоритмической части не содержит?
Содержит, те же схемы к примеру. Плюс к этому внутренние системные службы.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Оберон и проектирование систем
СообщениеДобавлено: Пятница, 23 Сентябрь, 2011 21:23 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9139
Откуда: Россия, Орёл
По предложению Valery Solovey Отделил тему "Рефакторинг: есть ли ему место в разработке систем?" viewtopic.php?f=86&t=3573

(сделал рефакторинг обсуждения :) )


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

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


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

Сейчас этот форум просматривают: Google [Bot] и гости: 1


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

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