OberonCore

Библиотека  Wiki  Форум  BlackBox  Компоненты  Проекты
Текущее время: Пятница, 16 Ноябрь, 2018 11:16

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




Начать новую тему Ответить на тему  [ Сообщений: 24 ]  На страницу 1, 2  След.
Автор Сообщение
СообщениеДобавлено: Вторник, 05 Февраль, 2013 12:36 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 2046
Тема о выработке терминов (и/или определений) для использования в материалах по редактору... ну и любыми желающими, конечно...

Можно следовать т.н. «четырём золотым правилам научного изложения и восприятия научного произведения» акад. А.М. Новикова:

    1. Основные понятия, утверждения (теория в целом) должны быть явно и ясно определены независимо от знания их реципиентом (получателем).

    2. При оценке истинности суждений пользоваться только определениями, которые дал пропонент (источник), не подменять их своими представлениями.

    3. Явное определение не принимается, если оно не согласуется с контекстом.

    4. Выбор подходящего определения опирается на специфику задачи, которая решается с помощью данного определения.

Наверное, есть смысл думать о терминологии выразительной, где-то более сжатой, чем традиционная. Также можно думать о независимости ряда терминов и определений структур от форм записи структур. Имея в виду, в частности, это:
И.Е. Ермаков в http://ermakov.net.ru/pub/EIE-28-2010.pdf на с. 5 писал(а):
... Один из важнейших интеллектуальных навыков для инженера-программиста — умение находить подобие во внешне непохожих конструкциях и свободно выполнять эквивалентные преобразования между разными базисами.
- чтобы сам набор терминов и способ определения их подчёркивал подобие там, где оно выявлено...


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 05 Февраль, 2013 12:55 

Зарегистрирован: Суббота, 07 Март, 2009 15:39
Сообщения: 2933
Откуда: Астрахань
Код:
Состав концептов:
0.   Базовые неопределяемые понятия
1.   Алгоритмизация
2.   Язык программирования
3.   ООП
4.   Структуры данных и алгоритмы
5.   С++ - в качестве примера. Можно другой.
6.   ЭВМ
7.   Среда программирования - ?

Состав концептов Алгоритмизация базируется на Базовые неопределяемые понятия.
Состав концептов Язык программирования базируется на Базовые+Алгоритмизация
И так далее – по возможности использовать только предыдущий слой.

0.   Базовые – не определяемые
Символ
Число
Множество
Набор
Последовательность - ?
Имя
Данные
Действие
Конструкция
Инструкция
Правило
Объект
Язык
Устройство
Условие
Получается, что все эти определения – семантический конспект по Атанову

1.   Алгоритмизация
Исполнитель
   – устройство, способное понимать (распознавать?) и выполнять некоторый ограниченный набор инструкций

Команда (исполнителя)
   – одна инструкция, которую понимает и может выполнить исполнитель

Система команд исполнителя
   – множество команд, которые понимает и может выполнять исполнитель

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

Программа – это конкретизация алгоритма для конкретного исполнителя
   или – алгоритм, представленный в виде последовательности команд исполнителя.

Следование --- как определить ???
   – последовательность команд исполнителя ???

Ветвление
– команда исполнителя, позволяющая выполнить одну из двух последовательностей команд в зависимости от некоторого условия

Повторение  ( цикл - ??? )
– команда исполнителя, позволяющая многократно выполнить некоторую последовательность команд исполнителя

Подпрограмма (вспомогательный алгоритм)
   –
Параметр
Аргумент

Переменная
   – поименованный (имеющий имя) объект программы, характеризующийся определенным типом и …

Константа

Тип данных
   – множество объектов и конечный набор операций с ними

Операция – ??? != команда !!!
   – элементарное (неделимое) действие над данными 
   Операции бывают арифметическими, логическими, строковыми, битовыми и другими
   Операции могут иметь приоритет.

Операнд
   – объект, участвующий в операции
Выражение
   – заданная последовательность операция
Ввод (данных)
Вывод (данных)



2.   Язык программирования

Язык программирования – в алгоритмизацию ?
формальный язык, предназначенный для записи программ

Алфавит (языка программирования)
множество символов, посредством которых записываются конструкции языка программирования

Лексема
минимальная единица языка программирования, имеющая самостоятельный смысл

Синтаксис
формальные правила, по которым записываются конструкции языка программирования

Ключевое слово
Зарезервированное слово
имя, имеющее фиксированный смысл в языке программирования

Идентификатор

Литерал

Комментарий

Оператор

Процедура
Функция

Область видимости

Время жизни

Единица трансляции


3.   ООП

Класс
Поле
Метод
Инкапсуляция
Полиморфизм
Наследование
Композиция
Конструктор – не для всех языков программирования
Деструктор – не для всех языков программирования
Интерфейс (класса)
Принцип подстановки
Виртуальность

4.   Структуры данных и алгоритмы
Массив
   – пронумерованный набор объектов одного типа
Список
   Односвязный
   Двусвязный
   Циклический
   Слоеный
Очередь
   Приоритетная
Стек
Дерево
   Бинарное
      Балансированное
         АВЛ
         Красно-черное
         Скошенное
   В-дерево   

Поиск (в последовательностях)
   Последовательный
   Двоичный
   Интерполяционный

Сортировка

Хеширование
 
5.   ЭВМ

Память

Адрес

Регистры (общего назначения)

Процессор

Система команд
Методы адресации


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

Зарегистрирован: Суббота, 29 Март, 2008 19:27
Сообщения: 1021
Откуда: Россия, Чебоксары
Валерий Лаптев писал(а):
Алгоритм – это абстрактный алгоритм
– точное предписание исполнителю совершить определенную конечную последовательность действий для достижения заданной цели за конечное время – тут неясно, чем это отличается от программы
Убирайте из всех определений "за конечное время". Ибо для систем управления, систем реального времени получается и смысл другой, и вообще не получается - там главный цикл в норме не заканчивается никогда ;)

Цитата:
Программа – это конкретизация алгоритма для конкретного исполнителя
или – алгоритм, представленный в виде последовательности команд исполнителя.
Не забываем о неимперативном программировании. Хотя Илья и высказался за то, чтобы всё равно подразумевать там исполнителя с конкретными алгоритмами, но так ли это - вопрос спорный...


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

Зарегистрирован: Суббота, 07 Март, 2009 15:39
Сообщения: 2933
Откуда: Астрахань
Все же похоже, что программа - это не всегда алгоритм, но всегда для исполнителя.
Программа на Прологе - не императивщина, но исполнитель-то есть!
Программа на Лиспе - опять то же самое!


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 05 Февраль, 2013 16:26 
Модератор
Аватара пользователя

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


Прошу не считать мой голос "за". Я не уверен, стоит ли так считать - я обратил внимание, что многие придерживаются такой позиции.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 08 Февраль, 2013 11:05 

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

Alexey_Donskoy писал(а):
...
Цитата:
Программа – это конкретизация алгоритма для конкретного исполнителя
или – алгоритм, представленный в виде последовательности команд исполнителя.
Не забываем о неимперативном программировании. Хотя Илья и высказался за то, чтобы всё равно подразумевать там исполнителя с конкретными алгоритмами, но так ли это - вопрос спорный...
Так может, и тут выделить случаи императива и декларатива? И будет во втором что-то вроде: "Программа - результат алгоритмизации неимперативной модели предметной области по алгоритму для данного рода модели, управляемому целями, для конкретной цели"?..
Ну а алгоритм - модель задачи для императивного исполнителя...


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 08 Февраль, 2013 13:14 
Аватара пользователя

Зарегистрирован: Суббота, 29 Март, 2008 19:27
Сообщения: 1021
Откуда: Россия, Чебоксары
Владислав Жаринов писал(а):
Может, явно учесть различие между вычислительными (трансформационными) и управляющими (реагирующими) задачами?..
ИМХО, методически неверно...

Цитата:
Тогда м.б. для второго случая "за конечное время цикла реакции на алгообстановку"... как-то так...
Не надо приплетать реальное время через-под левое колено.
Кроме того, там кое-что зависит не только от программной части, но и от аппаратной.

Цитата:
И будет во втором что-то вроде: "Программа - результат алгоритмизации неимперативной модели предметной области по алгоритму для данного рода модели, управляемому целями, для конкретной цели"?..
Можно ли назвать процесс интерпретации (или любого другого исследования) декларативных данных (Data Flow Diagram какой-нибудь) "программой"?! :facepalm:

Цитата:
Ну а алгоритм - модель задачи для императивного исполнителя...
"А вот это попробуйте!" (с) "Бриллиантовая рука" :wink:


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 08 Февраль, 2013 15:40 

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

Насчёт интерпретации - процесс исследования, конечно, можно называть "добычей данных"... :) Однако в цитате-то говорится о результате... который можно, например, сохранить для использования в качестве инструмента...


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 08 Февраль, 2013 16:48 

Зарегистрирован: Суббота, 07 Март, 2009 15:39
Сообщения: 2933
Откуда: Астрахань
Владислав Жаринов писал(а):
Ну а алгоритм - модель задачи для императивного исполнителя...

Мне нравится... :)


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 09 Февраль, 2013 11:43 
Аватара пользователя

Зарегистрирован: Суббота, 29 Март, 2008 19:27
Сообщения: 1021
Откуда: Россия, Чебоксары
Владислав Жаринов писал(а):
программа как часть системы по Усову... Вы это имели в виду?..
И это тоже.

Цитата:
Насчёт интерпретации - процесс исследования, конечно, можно называть "добычей данных"... :) Однако в цитате-то говорится о результате... который можно, например, сохранить для использования в качестве инструмента...
Не в ту степь.
Вы говорили о "программе, как результате алгоритмизации", что методически не всегда верно.

Я привожу другие примеры. Про неимперативное программирование уже говорили.
Одной из разновидностей неимперативного программирования является то, о чём обычно говорят как о "программе, управляемой данными".
То есть имеется средство моделирования, или САПР, или SCADA. Они сами по себе являются исполнителями.
А то, что мы делаем в них - по сути является программой, хотя ни разу может не быть алгоритмом.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 09 Февраль, 2013 17:32 

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 09 Февраль, 2013 18:53 
Аватара пользователя

Зарегистрирован: Суббота, 29 Март, 2008 19:27
Сообщения: 1021
Откуда: Россия, Чебоксары
Владислав Жаринов писал(а):
если мы делаем на исполнителе "программа, управляемая данными + платформа её исполнения" программу, то она также подпадает под обсуждаемое определение... именно в расширенном случае, когда мы не ограничиваемся императивом... :)
Где же попадает? У Вас же в определении "программа как результат алгоритмизации". Где здесь алгоритмизация?
Работу самой системы (иполнителя), которая задаётся недекларативной программой, нельзя назвать алгоритмизацией.
Это примерно то же самое, как если бы Вы купили готовый процессор и начали рассуждать о процессе проектирования процессора...

Цитата:
Ну и так пока не дойдём-таки до интеллекта в основе... который задачу ставит и тесты Тьюринга выдумывает... :wink: и главное - постановки варьирует, как Фридланд писал... Или как по-Вашему будет?..
А вот это уже не имеет отношения к решаемой задаче. Этак Вы и до курицы с яйцом дойдёте в пылу творения терминологии! :wink:

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


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

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

Alexey_Donskoy писал(а):
Владислав Жаринов писал(а):
если мы делаем на исполнителе "программа, управляемая данными + платформа её исполнения" программу, то она также подпадает под обсуждаемое определение... именно в расширенном случае, когда мы не ограничиваемся императивом... :)
Где же попадает? У Вас же в определении "программа как результат алгоритмизации". Где здесь алгоритмизация?
Работу самой системы (иполнителя), которая задаётся недекларативной программой, нельзя назвать алгоритмизацией.
Это примерно то же самое, как если бы Вы купили готовый процессор и начали рассуждать о процессе проектирования процессора...
...
Да, только это, думаю, замечание к тому, который будет сужать предмет... :) Мы говорим о двухчастном определении. Где есть и то, и другое. Для разных исполнителей - интеллекта (сильно абстрактного при нашем уровне знаний о нём) и "машины" (просто абстрактного, математически определяемого как говоритель на формальном языке). Это во-первых.
Во-вторых, под декларативом для "языковой машины" подразумевается наличие императива для построения императивной же программы. Так, в ПРОЛОГ-исполнителе - резолюций, в таблично-процессорном - обхода зависимостей ячеек, в СУБД-шном - изменения/выдачи значений полей (как я понимаю, по одному из двух методов - блокировочному или версионному)... а в СУПР - порождения по заказам экземпляров техпроцессов и планирования работ по ним...
Вот этот императив и занимается алгоритмизацией... и результатом будет код, исполнимый императивно... или как?..


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

Зарегистрирован: Суббота, 29 Март, 2008 19:27
Сообщения: 1021
Откуда: Россия, Чебоксары
Владислав Жаринов писал(а):
Насчёт абстрактного - когда как. Вот у Потопахина видно, что на этом можно и попасть... ибо от конкретики типов зависят действия и маршруты... и наоборот... :wink:
Нет. Абстрактного - это по определению алгоритм (как математическая абстракция).
А если конкретный исполнитель - то это уже программа. Исполняемая программа.

Цитата:
Мы говорим о двухчастном определении. Где есть и то, и другое. Для разных исполнителей - интеллекта (сильно абстрактного при нашем уровне знаний о нём) и "машины" (просто абстрактного, математически определяемого как говоритель на формальном языке).
Даже математикам не мешало бы быть проще. Нафига сдалось такое "двухчастное определение", я не понимаю. И подозреваю, что оно не нужно.

Цитата:
Вот этот императив и занимается алгоритмизацией... и результатом будет код, исполнимый императивно... или как?..
Во-первых, классический интерпретатор не подразумевает результирующего кода :)

Во-вторых, с тем же успехом можно и про процессор сказать, что он "занимается алгоритмизацией" (посмотрите, как работают современные схемы прогноза и управления конвейером внутри процессора).
Чувствуете, что здесь что-то не то? :wink: А это потому, что нет смысла забираться так глубоко.
У нас есть а) задача, б) исполнитель (та же SCADA, к примеру), в) программа для исполнителя.
Всё! Ничего лишнего.

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 09 Февраль, 2013 19:47 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 2046
Про интерпретатор я знаю... :wink: мы же про компилятор... :)
А вообще началось с того, что программа - не только императив (Илья, кажется, сказал... и не в первый раз). Отсюда и вторая часть оопределения. Что и повлекло за собой необходимость различать исполнителей...

В принципе это уже сделал Кауфман: viewtopic.php?p=71218#p71218 и не он один...

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 10 Февраль, 2013 14:11 

Зарегистрирован: Суббота, 07 Март, 2009 15:39
Сообщения: 2933
Откуда: Астрахань
Alexey_Donskoy писал(а):
Нет. Абстрактного - это по определению алгоритм (как математическая абстракция).
А если конкретный исполнитель - то это уже программа. Исполняемая программа.

Это мне еще больше нравится!
Завтра на лекции по алгоритмам и структурам данных студентов озадачу! :)


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 10 Февраль, 2013 14:14 

Зарегистрирован: Суббота, 07 Март, 2009 15:39
Сообщения: 2933
Откуда: Астрахань
Владислав Жаринов писал(а):
Про интерпретатор я знаю... :wink: мы же про компилятор... :)

А посмотрите-ка вы смешанные вычисления Андрея Петровича Ершова... :)
Указатели: проекции Футамуры, суперкомпиляция, частичные вычисления... :)


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 11 Февраль, 2013 11:38 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 2046
Будут интересны результаты... :)
Согласен с Алексеем. Единственное что - т.к. различаю исполнителей, то называю программу для интеллектуального "инструкцией". А так да, уже зафиксировал и буду употреблять... :)

Насчёт суперкомпиляции помню... по Романенко (у Кауфмана). :) В то же время, как понял, на вход этой системы надо подать интерпретатор (в частности, ПРОЛОГА или языка УБД)?.. который же ж надо написать сначала... интеллектуально в общем случае?.. ну или функцию и её аргумент?.. а это разве декларативные модели предметки/задачи?..
Кстати, Мейер по-своему "системировал" интерпретацию и компиляцию... тоже понравилось...


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: О названии элементов схем
СообщениеДобавлено: Воскресенье, 17 Февраль, 2013 08:19 

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

Далее. Языки (и схем тоже) в первом подразделении бывают "родные" (с неформальным синтаксисом, возможностью "плавания" семантики в целях отражения неопределённости предметки) и "программные" (со строгим синтаксисом, фиксированной семантикой в целях отражения предметки как "поля определённостей").
Отсюда глифы д.б. с "программно строгим" набором и синтаксисом атрибутов или с возможностью заполнять их "как угодно" (но всё-таки в пределах прагматики языка :)). Для вторых предлагается название "холст" - ибо такое заполнение можно уподобить рисованию картины на поле глифа... :)


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: О системе названий для моделей
СообщениеДобавлено: Вторник, 26 Февраль, 2013 09:51 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 2046
И теперь можно перейти к этому:
Рэйлвэй Каген в viewtopic.php?p=56043#p56043 писал(а):
2Ильченко Эдуард:
Находиться в терминологическом контексте ЕСКД и не впадать при этом в программизм можно с помощью подстановки:
Код:
иконы          элементы
макроиконы     компоненты
ветки          ветви
маршруты       связи
лиана          группа
лианный блок   групповой блок
силуэт         комбинированная схема
примитив       базовая схема
Дополнено..
Код:
заземление лианы  адресация группы
заземлить лиану   (пере-)адресовать группу
пересадка лианы   присоединение группы
пересадить лиану  присоединить группу
- тут, возможно, следует учесть обсуждения формата проектов Ильченко (ДАР), где ряд участников кое-что предлагали...

Также по понятию для шины схем - сказанное здесь:
Геннадий Тышов в viewtopic.php?p=75869#p75869 писал(а):
В схемах широко применяется "линия групповой связи" по ГОСТ 2.721-74 "ОБОЗНАЧЕНИЯ УСЛОВНЫЕ ГРАФИЧЕСКИЕ В СХЕМАХ" таблица 6в. Смотрит http://www.docload.ru/Basesdoc/4/4604/index.htm.

Применение линии групповой связи наиболее знакомо по электрическим схемам.
В Драконе схема Силуэт построена с использованием линии групповой связи в петле Силуэта, с обозначением входящих линий иконами Ветка и Адрес в разрыве линий в соответствии с таблицей 6в 1.Примечания 3.б).
Происходит графическое разветвление (слияние) линий связи в линию групповой связи.

Таким образом в Силуэте петля представляет не 1-у связь, а объединение не связанных связей.
...
безусловно, справедливо (а контраргументы скорее спецпропагандистские - если такое здесь будет повторяться, обращусь к администрации). В то же время ЕСКД-шину можно рационально ограничить - что и сделано здесь:
...графит-сеть всё-таки не настолько свободна, как «ручная» схема, составленная по правилам ЕСКД. Это следствие применения формального метода составления.

Так, графит-схемы по сравнению с ЕСКД-схемами имеют следующие ограничения и особенности синтаксиса:


    * Замыкание шин графит-кросса в контур[ы].


    * Допущение отводов связей из кросса только из определённых сторон контуров.


    * Одинаковое направление ведения связей в кроссе (в ЕСКД связи можно вести навстречу друг другу).

      Фактически этим и обеспечивается возможность замыкания контуров графит-кросса.


    * Единичность начала и конца каждой связи (в ЕСКД допускаются два и более).

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


    * Выделение внешних и внутренних соединителей с отдельным их расположением и форматом.

      Тем самым явно разделяются механизмы «горизонтальной», диспозитивной декомпозиции и «вертикальной», ранговой. Оба типа могут сочетаться при формализации реального предмета моделирования.


    * Допущение только линейного порядка контуров (в ЕСКД возможен и двумерный).

      Двумерная «решётка» контуров даёт некоторые дополнительные возможности для структуризации содержания схемы. В то же время сходного результата можно достичь рациональной группировкой содержания в ряду/колонке контуров.


    * Формальная структуризация схемы в целом (в ЕСКД принято только полуформальное эллипсирование и сокращение многолинейных схем до однолинейных).
- потому для этих условий и термин оправдан отдельный. У меня принят "кросс".

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


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

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


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

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


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

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