DRAKON.SU

Текущее время: Четверг, 28 Март, 2024 20:33

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




Начать новую тему Ответить на тему  [ Сообщений: 51 ]  На страницу 1, 2, 3  След.
Автор Сообщение
СообщениеДобавлено: Пятница, 19 Февраль, 2010 10:08 

Зарегистрирован: Вторник, 15 Декабрь, 2009 11:43
Сообщения: 83
Предлагаю вашему вниманию мои предложения
по созданию компактной системы разработки
и документирования ПО реального времени.

Есть ли вообще реальная необходимость в
создании простой и общедоступной системы
разработки и документирования ПО РВ ?

Буду рад вашим замечаниям и предложениям.

Вложение:
srdporw.rar [402.39 КБ]
Скачиваний: 630


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

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 631
Откуда: Россия, Орёл
Интересно, спасибо.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 23 Февраль, 2010 02:08 

Зарегистрирован: Воскресенье, 09 Март, 2008 22:38
Сообщения: 341
Дмитрий_ВБ писал(а):
Предлагаю вашему вниманию мои предложения
по созданию компактной системы разработки
и документирования ПО реального времени

По поводу Ваших предложений, Дмитрий.
1. Не стоит все-таки, как мне кажется, упрощать всем понятную устоявшуюся систему обозначений, в частности, заменять графический примитив условия с ромба на прямоугольник.
2. Вы пишете, что задача генерации текста программы на структурном языке без goto, например, Java, тривальна. Не совсем соглашусь, и, полагаю, Вам сообщество скажет еще большее
спасибо, если Вы алгоритм/программу решения подобной задачи построите и выложите в свободный доступ.

Дмитрий_ВБ писал(а):
Есть ли вообще реальная необходимость в
создании простой и общедоступной системы
разработки и документирования ПО РВ ?
Буду рад вашим замечаниям и предложениям.

Безусловно, есть. Поскольку, несмотря на наличие ряда разработок в этой области (в том числе нашей ;-) - кстати, в космической промышленности достигнуты в этой области значительныйе высоты), нет общедоступного бесплатного проработанного стандарта.


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

Зарегистрирован: Вторник, 15 Декабрь, 2009 11:43
Сообщения: 83
Ответы Андрею (TAU):

1. Можно изображать условие и ромбом - с точки зрения графического редактора
тут разницы почти никакой. Просто при изображении условий ромбами
визуальная схема будет занимать больше места. И вообще способ отображения
условия (ромб/прямоугольник/прямоугольник большего размера, чем действие)
можно вынести в файл конфигурации.

2. В подсказке к и.с.Дракон, в разделе "Программирование, синтез ПО",
подраздел "Программирование на языке семейства Оберон имеет особенности"
вполне доступно, как мне кажется, все описано для языков без goto. Что
касается Java, то в формате ВЯЗ БС программы АВ имеем:


:.1. класс такой-то

начало класса, объявление переменных

:.2. процедура р1

...

:.3. процедура р2

...

:.4. процедура main

...

:.5. конец класса такой-то
-------------
}


И в чем проблема ?





3. Вообще почему возник вопрос. У моего отделения в плане появилась
работа по созданию управляющего контроллера для нового типа замедлителя
с перспективой создания в дальнейшем универсального управляющего
контроллера для различных типов замедлителей. Заказчик требует
предоставить возможность ознакомления с подробными алгоритмами работы
ПО контроллера, причем крайне желательно, чтобы в доступной для него
форме (т.е. блок-схемы, а не UML-диаграммы), и чтобы алгоритмы реально
соответствовали бы текущей версии ПО контроллера. Вот я, по указанию
руководства, и задумался - что делать ? Дракон бы подошел, если бы не
перечисленные мной выше недостатки.



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

По перспективам моей дальнейшей работы в этом направлении.
Сейчас мне опять недели на 2 придется отвлечься на решение текущих
производственных проблем, а дальше будет видно. Было бы неплохо, если
бы работа по созданию описанного мной в предложениях графического
редактора была включена в план работ моего отделения как часть темы по
созданию ПО контроллера замедлителя. Но при этом (С) на программу будет
уже не мой личный, а моего института, так что за открытость кода я в
этом случае поручиться уже не смогу.
Интересно, что особенностью нынешнего рынка ПО в России является то,
что зарабатывать можно только на продаже узкоспециализированного ПО
для конкретных заказчиков, а попытки коммерческого распространения
российского ПО широкого назначения, к которым относятся и системы
документирования ПО, успеха не имеют (редкие исключения типа системы
"1С" и антивируса Касперского на общей картине не сказываются). Поэтому
я думаю, что, если бы мой институт взялся за создание системы разработки
и документирования ПО РВ, то лучше было бы с самого начала сделать такую
работу проектом с открытым кодом - могли бы попытаться заработать
авторитет как создатели "общедоступного бесплатного проработанного
стандарта" в области разработки ПО РВ.
Хотя у моего руководства может быть и другое мнение по этому вопросу.

Поэтому, если и пытаться двигаться в направлении создания российского
стандарта создания ПО РВ, опирающегося не на UML-диаграммы, а на
дракон-подобные визуальные схемы, то форум oberoncore представляется мне
самым подходящим местом для этого.

Нужно сформулировать основные требования:
1) к виду визуальных схем;
2) к текстовому формату представления визуальных схем;
3) к интерфейсу работы с графическим редактором;
4) к генератору исходного кода ПО.

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


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

Зарегистрирован: Воскресенье, 24 Февраль, 2008 15:32
Сообщения: 5846
Откуда: Москва
Дмитрий_ВБ писал(а):

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


Уважаемый Дмитрий!

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

Вы пишете:
Цитата:
при изображении условий ромбами
визуальная схема будет занимать больше места

По моему, это неверно (если говорить не о ромбах, а об иконе вопрос)..
Вложение:
Комментарий к файлу: Сравнение прямоугольника с иконой вопрос
СветофорВопрос.png
СветофорВопрос.png [ 23.27 КБ | Просмотров: 22782 ]

Вы пишете:
Цитата:
Вот я, по указанию
руководства, и задумался - что делать ? Дракон бы подошел, если бы не
перечисленные мной выше недостатки.

Простите, я не уловил про недостатки Дракона. Если можно, повторите,
пожалуйста, перечень недостатеов Дракона..

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


Известен постулат: " Программу пишут один раз, а читать ее
приходится много раз". ( Я. Пайл).
Моя позиция такова.
1. Поддерживаю устранение ненужных ограничений, замедляющих
работу с графическим редактором
2. Считаю нежелательной некоторую потерю наглядности

Вы пишете:
Цитата:
Пусть не обижается на меня Владимир Даниелович, но Дракон
провозглашен им как инструмент для людей с малым опытом
программирования, а мне нужен инструмент для программистов-
профессионалов, которых лишние ограничения будут только
раздражать.

Моя позиция несколько иная. Да, я признаю, что Дракон, в частности,
задуман как инструмент для людей с малым опытом программирования.
Но! Я полностью поддерживаю Вас, когда Вы хотите что-то изменить,
чтобы создать инструмент для программистов-профессионалов.

Здесь возникает важный вопрос. А нельзя ли найти компромисс?.
Нельзя ли удовлетворить и тех, и других? У меня нет готового ответа.
Но я об этом мечтаю. И я не исключаю, что, возможно, именно Вы
сумеете найти ответ. Желаю удачи!


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 27 Февраль, 2010 04:34 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 1443
Дмитрий_ВБ писал(а):
Нужно сформулировать основные требования:
...
3) к интерфейсу работы с графическим редактором;
...

Пока самое удобное, что использовал для моделирования - это редакторы типа BpWin (All Fusion...) и DesignIDEF... последний проще и притом функционален достаточно(старую версию и попытку спецификации можно найти в соотвествующих пунктах этой страницы).


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

Зарегистрирован: Вторник, 15 Декабрь, 2009 11:43
Сообщения: 83
Владимир Паронджанов:
Простите, я не уловил про недостатки Дракона. Если можно, повторите,
пожалуйста, перечень недостатеов Дракона..

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


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

Зарегистрирован: Среда, 16 Ноябрь, 2005 00:53
Сообщения: 143
Откуда: Россия, Орёл
Дмитрий_ВБ писал(а):
Главный недостаток (и это не только мое мнение) - отсутствие на текущий момент формализованной текстовой формы представления визуальной схемы... В спецификации Дракона ответ на этот вопрос отсутствует.
В перефразировании смысл не исказил?

Главный недостаток графического языка ДРАКОН - отсутствие в его спецификации формализованной формы текстового представления (графической схемы)...

Такая формулировка, по-моему, протифоречит сама себе.


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

Зарегистрирован: Вторник, 15 Декабрь, 2009 11:43
Сообщения: 83
Евгений Темиргалеев писал(а):
Главный недостаток графического языка ДРАКОН - отсутствие в его спецификации формализованной формы текстового представления (графической схемы)...

Такая формулировка, по-моему, протифоречит сама себе.


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

А если рассматривать Дракон в качестве визуального языка УДОБНОЙ для
программистов системы разработки и документирования ПО, то понятно, что
работа с файлом данных визуальной схемы должна быть УДОБНОЙ для
программиста, и если программисты ХОТЯТ, чтобы файл данных визуальной
схемы был прост, понятен и мог бы редактироваться точно так же, как и текст
программы, то для разработчика системы документирования ПО, который
хочет, чтобы его системой пользовались программисты, это требование
должно быть безусловным руководством к действию.


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

Зарегистрирован: Воскресенье, 24 Февраль, 2008 15:32
Сообщения: 5846
Откуда: Москва
Дмитрий_ВБ писал(а):
Владимир Паронджанов:
Цитата:
Простите, я не уловил про недостатки Дракона.
Если можно, повторите,
пожалуйста, перечень недостатков Дракона.


Главный недостаток (и это не только мое мнение) - отсутствие
на текущий момент формализованной текстовой формы
представления визуальной схемы.

Вопрос не в ключевых словах текстового кода, а в том,
как однозначно преобразовать его в дракон-схему.
В спецификации Дракона ответ на этот
вопрос отсутствует.


Уважаемый Дмитрий!

Спасибо за ответ.
Я покажу, как графику Дракона однозначно перевести в текст (на примере).
Вот графика (дракон-схема)
Вложение:
Комментарий к файлу: Дракон-схема Рис. 19
Рис. 19.png
Рис. 19.png [ 91.76 КБ | Просмотров: 22727 ]


А вот текст, однозначно соответствующий этой графике
(первые две ветки):
Вложение:
Комментарий к файлу: Текст, соответствующий графике
(рисунку 19)

Рис. 22.png
Рис. 22.png [ 69.69 КБ | Просмотров: 22725 ]

Из рис. 22 видно, что для описания веток в текстовый язык
пришлось внести ряд изменений.

В частности, появились два новых текстовых оператора,
отсутствующие в традиционных языках:

ВЕТКА < идентификатор ветки >
АДРЕС < идентификатор ветки >

Оператор текстового языка ВЕТКА объявляет название ветки
(записываемое на графическом языке внутри иконы «имя ветки»).

Оператор АДРЕС безусловно передает управление на текстовый
оператор ВЕТКА, имя которой совпадает с записью в операторе
АДРЕС.
___________________________________________________________

Если я неправильно ответил на ваш вопрос, поправьте меня.
Очень хотелось бы достичь взаимопонимания.


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

Зарегистрирован: Среда, 16 Ноябрь, 2005 00:53
Сообщения: 143
Откуда: Россия, Орёл
Дмитрий_ВБ писал(а):
Это еще как посмотреть - визуальная схема и кодирующий ее файл данных образуют диалектическое единство - если не будет одного из них, то и второго не будет тоже (для электронной формы записи).
ДРАКОН определяет правила построения и изображения схемы.

Формат файла, в котором хранится схема, определяет разработчик редактора схем.

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 27 Февраль, 2010 15:58 

Зарегистрирован: Вторник, 15 Декабрь, 2009 11:43
Сообщения: 83
Евгений Темиргалеев писал(а):
Дмитрий_ВБ писал(а):
Это еще как посмотреть - визуальная схема и кодирующий ее файл данных образуют диалектическое единство - если не будет одного из них, то и второго не будет тоже (для электронной формы записи).
ДРАКОН определяет правила построения и изображения схемы.

Формат файла, в котором хранится схема, определяет разработчик редактора схем.

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


Да, Евгений, конечно Вы правы.
Я подошел слегка упрощенно, поскольку тема - "Система разработки и
документирования ПО РВ", то я, конечно, рассматриваю всю систему в комплексе.
И в том, что в и.с.Дракон нет текстового представления дракон-схемы, сам язык
Дракон, определенный Владимиром Даниеловичем, не виноват. Виновата реализация.
Бедные программисты-кодировщики - на них все шишки падают, а теоретикам все
лавры в случае успеха.
И текстовое представление дракон-схемы Владимир Даниелович привел.
Но, попробовав написать утилиту "дракон -> ВЯЗ БС", стал подозревать я, недостойный,
что тут есть подводный камень под названием "сложность реализации". 2 института
10 лет работали над созданием ГРАФИТ-ФЛОКС, не самые глупые люди, между прочим.

Может, главная проблема с Драконом и заключается в сложности реализации идей
Владимира Даниеловича в изящной, мощной и полностью зачищенной от ошибок
современной IDE с модерновым дизайном ? Не могу сказать точно.
Что я могу сказать определенно - это то, что в формате ВЯЗ БС предложенной мной
программы АВ (см. тему "дракон-си") нет особых проблем с преобразованием
"визуальная схема <-> текстовый формат визуальной схемы". Да и графический
редактор для ВЯЗ БС написать, как мне кажется, не слишком сложно.

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 01 Март, 2010 11:32 

Зарегистрирован: Воскресенье, 24 Февраль, 2008 15:32
Сообщения: 5846
Откуда: Москва
Уважаемый Дмитрий!

Может быть, схемы (внизу) будут Вам хотя бы отчасти полезными

Вложение:
Комментарий к файлу: Дракон-Си Рис. 129
Рис. 129.png
Рис. 129.png [ 60.09 КБ | Просмотров: 22666 ]


Вложение:
Комментарий к файлу: Дракон-Си Рис. 130
(продолжение)

Рис. 130.png
Рис. 130.png [ 59.38 КБ | Просмотров: 22665 ]


КОММЕНТАРИЙ 1

Для примера превратим программы на языке Си в программы
на языке Дракон-Си. Как это сделать?

Ответ дан на рис. 129 и 130.

:idea: В 1-м примере на рис. 129 рассмотрен оператор языка Си if—else.

В средней графе показана программа на языке си, в которой
используется этот оператор.

А правее изображена математически эквивалентная ей
программа на языке Дракон-Си.

Чем же отличаются программы?

В си-программе мы видим два ключевых слова if, else,
четыре фигур-ные скобки и две круглые скобки.

В дракон-программе они исчезают и превращаются в чертеж.

Благодаря этому схема приобретает важное качест-во — наглядность.

:idea: Во 2-м примере на рис. 129 рассмотрен оператор if—elseif—else.

Рядом показаны математически эквивалентные программы на
языках Си и Дракон-Си.

В обеих программах применяется названный оператор —
соответственно в текстовой и графической форме.

:idea: В 3-м примере рассмотрены ключевые слова switch, case,
break, default.


В си-программе видим большое количество избыточных слов и
текстовых символов.
• switch (два раза)
• case 1
• case 2
• break
• две фигурные скобки
• две круглых скобки
• две косые скобки
• три двоеточия
• пять точек с запятой
• две звездочки.

Нужны ли все эти символы? Нет, не нужны!
В дракон-программе эти значки устраняются, превращаясь
в приятный для глаза графический образ, пригодный
для быстрого симультанного восприятия.

КОММЕНТАРИЙ 2

Чтобы лучше уяснить преимущества языка Дракон-Си, произведем
мысленно обратное преобразование. Как видно из рис. 129, 130,
при преобразовании текстовой программы в визуальную исходный
текст си-программы разбивается на две части.

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

Остальные текстоэлементы языка Си (которые можно назвать
удаляемыми или «паразитными») становятся ненужными.
Они превращаются в графические линии и ключевые слова
«да» и «нет» (yes и no).

Рисунки 129 и 130 показывают, что список паразитных (удаляемых)
элементов языка Си оказывается внушительным.
Он включает все ключе-вые слова в примерах 1—7, кроме default,
все фигурные, круглые и косые скобки, двоеточия, метки,
комментарии в примерах 3—5 и, кроме того, точки с запятой
в примерах 2, 3, 7 и отчасти 6.

Таким образом, чтобы построить язык Дракон-Си, надо
по определенным правилам соединить визуальный синтаксис
Дракона с текстовым син-таксиса языка Си. Из последнего
следует удалить все элементы, функции которых реализуются
визуальными операторами Дракона.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 05 Март, 2010 05:51 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 1443
Дмитрий_ВБ писал(а):
Предлагаю вашему вниманию мои предложения
по созданию компактной системы разработки
и документирования ПО реального времени.

Есть ли вообще реальная необходимость в
создании простой и общедоступной системы
разработки и документирования ПО РВ ?

Буду рад вашим замечаниям и предложениям.


Вот такие соображения пока.
Вложение:
Комментарий к файлу: Новая версия.
Текст_Предложения_по_ДРАКОНу_v050410.pdf [254.17 КБ]
Скачиваний: 823

В основном они касаются предложений о визуальном представлении алгоритмов; о соотношении же визуального с текстовым, наверное, достаточно сказано здесь.


Последний раз редактировалось Владислав Жаринов Вторник, 06 Апрель, 2010 22:21, всего редактировалось 1 раз.

Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 06 Март, 2010 14:24 

Зарегистрирован: Вторник, 15 Декабрь, 2009 11:43
Сообщения: 83
Драконограф писал(а):
Вот такие соображения пока.


Уважаемый Драконограф, спасибо за Ваши замечания.

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

Задача Вами сформулирована правильно — работа с моделью задачи начиная
с формализации алгоритма ее решения вплоть до генерации исходного кода
программы, решающей эту задачу.
При этом желательно, чтобы формализация алгоритмов проводилась специалистами-
предметниками, хорошо разбирающимися в своей области, но плохо разбирающихся
в программировании. Эти люди с высшим техническим образованием знают, что такое
блок-схемы, но у них часто нет ни времени, ни желания разбираться с дополнительной
терминологией описания блоков, введенной В.Д. Паронджановым. Для них ромб — это
условие, а прямоугольник — действие. И зачем, с их точки зрения, придумывать что-то
еще ? Поэтому принцип «чем проще — тем лучше» имеет под собой реальную основу.

По поводу псевдографики — лет 7 назад мы использовали ОСРВ RMX for DOS, в
которой DOS использовалась как одна из задач многозадачного режима (некий аналог
виртуальной машины DOS в Win), а остальные задачи были RMX-овскими.
Графические возможности такой среды были ограниченными — драйвер для
видеокарты под RMX приходилось писать самим, среда разработки программ состояла
из DOS-овской версии MultiEdit и компилятора командной строки.
Но хотя корни у псевдографики конечно же исторические, она послужила хорошим
базисом для макетного варианта среды разработки ПО, позволив отбросить все, не
относящееся непосредственно к структуре алгоритма. И эта же псевдографическая
логика работы программы может быть сравнительно легко расширена до полноценной
графической логики работы. Так что принцип «от простого к сложному» себя
оправдывает.

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

Драконограф: «Как я понимаю, алфавит и правила техноязыка выработаны в т.ч. с
использованием методов инженерной психологии, на основе экспериментальной
отработки лучшего восприятия
дракон-схем. И менять их можно только на научной
основе.»
Ох как меня приводят в смущение подобные фразы ! И крыть нечем — ведь «научная
основа» ! Но одному человеку рамка помогает сосредоточиться на находящемся в ней
тексте, а другого, наоборот, отвлекает от текста, находящегося в рамке. У разных людей
разная скорость обработки зрительной информации, и это диктует разные предпочтения
для наиболее удобных форм подачи зрительной информации. Ох, как здесть все
неоднозначно . . . В отличие от математики, или от программирования, или даже от
эргономических требований по созданию пультов управления, согласно которым взаимное
расположение приборов индикации, кнопок и рукояток на пульте выбирается с учетом
минимизации маршрутов движения зрительных осей оператора. Поэтому в вопросе выбора
формы блока условия я за демократичное задание формы этого блока в файле
конфигурации, а упертость типа - «тут должны быть ромбы!» или «тут должны быть
гробики!» мне непонятна.

Драконограф: «ВЯЗБС-силуэт, показанный на Рис. 5, следует считать промежуточным
результатом выкладки в лиоформу — обозначения веток устранены за счёт «вноса»
переходов в текст икон, но
форма силуэта ещё сохраняется. Предполагается, что так
понятнее;
однако мне понятнее либо
нормальный силуэт, либо конечный результат
на
Рис. 6, где не надо извлекать смысл переходов по петле силуэта из икон где-то внутри тела.»
Возможно, что так — тогда можно ввеси кнопку смены представления «примитив/силуэт».
Если человек не хочет лазить вверх/вниз по примитиву, то вывести ему силуэт.

Драконограф: « Это очередное требование о необходимости нестрогого (полуавтоматиче-
ского, «либерал-») режима визуализации; оно уже обсуждалось и по сути признано оправдан-
ным, однако нужно определиться — какие правила шампур-метода нужно отбросить в таком
режиме? Хотелось бы услышать и мнение Дмитрия об этом.»
Разработка интерфейса для дракон-редактора — это обширная область, над которой еще
надо хорошеньно поразмыслить — пока у меня нет определенных предложений на эту тему.


Еще раз могу повторить: мои предложения НЕ ОТНОСЯТСЯ к обсуждению определенного
В.Д. Паронджановым языка Дракон. Если вдруг найдется сильный коллектив программистов,
обладающий временем и ресурсами для создания полноценной и многофункциональной IDE
Дракон, пригодной для коммерческого использования — будут молодцы, если сделают.


Вопрос в том, что, будучи сильно ограничен по времени и ресурсам, я должен выбирать
для реализации заведомо минималистскую модель системы разработки и документирования
ПО РВ. Свои предложения по поводу создания такой системы я кратко расписал.



Буду рад вашим замечаниям и предложениям.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 08 Март, 2010 05:22 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 1443
Дмитрий_ВБ писал(а):
желательно, чтобы формализация алгоритмов проводилась специалистами-
предметниками, хорошо разбирающимися в своей области, но плохо разбирающихся
в программировании. Эти люди с высшим техническим образованием знают, что такое
блок-схемы, но у них часто нет ни времени, ни желания разбираться с дополнительной
терминологией описания блоков, введенной В.Д. Паронджановым.

С первой частью не могу не согласиться, а во второй, конечно, транслируется позиция заказчиков информатизации; предполагаю, что позиция Дмитрия необязательно с ней совпадает. Корни понятны: языки представления знаний относятся к конструктивным, а в то время, как обычно для постановки задач предметниками используются стихийные. Понимание различия между ними (см. Фридланд, 2005, с.54-55; вкратце - стихийные языки возникают, конструктивные - создаются) не требует "высшего технического"; вполне достаточно "средне-школьной эрудиции"; в результате возникает желание, вроде бы вполне невинное - сделать язык под свои потребности/желания. А такое ли уж оно невинное?
Невольно пришёл на ум диалог из одной сказки:
"- Вообще хорошо, что вы пришли, вы поможете мне разрешить одну порблему. - сказал тролль Кумле.
- Надо говорить "проблема", не "порблема" - сказал Юн.
- Разве у нас в стране нет свободы? Разве мы не имеем права выговаривать слова так, как нам заблагорассудится?! - возмутился Кумле.
- А всё же слова надо произносить правильно - не уступал Юн.
- Ну хорошо, послушай сначала, о чём идёт речь, - ответил Кумле, - а как ты это назовёшь, это уж твоё дело." (Синкен Хопп. Волшебный мелок.//Сказочные повести скандинавских писателей. - М.:Правда, 1987. - с. 73)

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

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

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

О ромбах - прежде всего, на схемах в Драконографике и не только можно видеть, как плохо умещается там сколько-нибудь длинный текст... а предметнику ведь привычно формулировать условия, пожалуй, в виде текстовых вопросов... потом уже аналитик/программист превратит их в логвыры. Но и тогда эта форма неудобна и для записи/чтения текста, и для компоновки на диосцене.

Дмитрий_ВБ писал(а):
И зачем, с их точки зрения, придумывать что-то
еще ?

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

Дмитрий_ВБ писал(а):
Но хотя корни у псевдографики конечно же исторические, она послужила хорошим базисом для макетного варианта среды разработки ПО, позволив отбросить все, не
относящееся непосредственно к структуре алгоритма.
будучи сильно ограничен по времени и ресурсам, я должен выбирать
для реализации заведомо минималистскую модель системы разработки и документирования
ПО РВ.

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

Дмитрий_ВБ писал(а):
либо
нормальный силуэт, либо конечный результат
на
Рис. 6, где не надо извлекать смысл переходов по петле силуэта из икон где-то внутри тела.»
Возможно, что так — тогда можно ввеси кнопку смены представления «примитив/силуэт».

Очень даже правильно... оператору надо давать побольше нужных настроек.

Дмитрий_ВБ писал(а):
В отличие от математики, или от программирования, или даже от
эргономических требований по созданию пультов управления,... ...в вопросе выбора
формы блока условия я за демократичное задание формы этого блока в файле
конфигурации, а упертость типа - «тут должны быть ромбы!» или «тут должны быть

Ну, тут я цитату оборву - почему, объяснил в документе, а если коротко - то по принципу "неназываемости неблагоприятного" (а Почепцов-то прав - вон как хорошо представления можно навязывать :wink: ). Чисто технически также согласен - почему бы не дать и такую настройку, но содержательно - не уверен... демократия это или анархия (см. сказку)?
    Вообще сохранение двойственности/множественности обозначений ставит говорящих на языке в положение "Буриданова осла"... недаром при внедрении баз данных действует принцип единства банка - при актуализации очередной порции данных в новом банке старый (напр. в виде бумажных документов) уничтожается. Так и здесь - при доподготовке слушателям устраиваем "очные ставки" старых и новых конструкций, спрашиваем "Новая система обозначений понятна?" потом командуем: "Старое забыть, сочинять по-новому! (ать-два :))". Конечно, реально "забывание" не будет происходить по мановению волшебной палочки :)... но оно вообще возможно только при жёстком запрете на пользование забываемого.
По поводу отличия - Паронджанов показал, что закономерности восприятия зрительной сцены одни и те же, поэтому и "кнопки" (операторы) разного назначения должны различаться уже на уровне формы, и движение по ним д. б. минимизировано, а для этого построение маршрутов деятельности нужно согласовать с закономерностями чтения текста человеком. Я не могу опровергнуть эти соображения на той же почве (инженерной психологии), а на любой другой это будет IMHO, некорректно.

Дмитрий_ВБ писал(а):
Разработка интерфейса для дракон-редактора — это обширная область, над которой еще надо хорошеньно поразмыслить — пока у меня нет определенных предложений на эту тему.

Да, в общем-то, нестрогий режим обсуждался, скажем, в этой теме, и наверное, что-то новое трудно к этому добавить... Если обобщить, то гл. обр. нужно предоставить сочинителю возможность "таскать" концы лиан куда он хочет, причём, говоря языком "банальной эрудиции", редактор должен обнаруживать нарушение топологических отношений перемещаемой лианы с остальными. А проще можно изобразить... допустим так:
Вложение:
Комментарий к файлу: Принцип пересадки лианы (в условном окружении).
Nestr_peresadka.pdf [99.48 КБ]
Скачиваний: 521
В правилах здесь в основном заложен строгий режим. Наверное, правило П2 здесь можно ослабить - не запрещать присоединение к горизонтали правее доминатора данной лианы, а создавать выше этого места излом (вводить в горизонталь вершину типа "излом вниз"), а в точке присоединения - древесную точку слияния (лиана идёт к ней слева; до этого написал здесь не то :)).
Также для нестрогого режима, видимо, можно ослабить ограничения на образование цикла посредством пересадки - только надо запрещать пересечение петель циклов. Это соответствует общей формулировке запрета на образование второго входа в цикл - маршрут не может входить в данный цикл, если его начало не лежит также внутри этого цикла. Отсюда и принцип обнаружения - как только потащили лиану из контура существующего цикла, где она берёт начало (а равно в контур, где она начало не берёт) - фиксируется ошибка.
Ну и можно допустить пересечение лианы с другими вертикалями - как временное (реализация предложена в МШ-методе).

Возможны варианты исполнения:
1) Редактор сразу по ходу перемещения (пока рисует "резиновую линию" лианы) отвергает нарушение;
2) Редактор отвергает нарушение после команды сочинителя на завершение операции.
То и другое, безусловно, ресурсоёмче, чем в строгом режиме, но наверное, случай 2) несколько проще; так работает DesignIDEF в режиме контроля грамматики дуг. Правда, лучше при этом указывать конкретные нарушения - пользователю понятнее.

P.S. Говорить по поводу сомнений в научности, вероятно, здесь оффтопик; свои соображения вынес в это сообщение (не знаю, подходящая ли тема... возможно пора создать что-нибудь отдельное типа "Организация и экономика информатизации" :)).


Последний раз редактировалось Владислав Жаринов Понедельник, 15 Март, 2010 06:05, всего редактировалось 7 раз(а).

Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 08 Март, 2010 05:28 

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

Грабин_ОружиеПобеды_ВД+Извл.djvu [90.29 КБ]
Скачиваний: 479

Что мы можем извлечь из описания скоростного метода (фактически - метода реинжиниринга бизнес-процессов) Грабина? Прежде всего - обычные сегодня принципы РБП ("не автоматизируйте, а уничтожайте функции", "не следуйте сложившейся оргструктуре, а [ре]формируйте её под назначение оргсистемы").
В то же время выделены устойчивые роли участников процесса для материального производства. Можно развить это - но в данной теме будет оффтопиком, поэтому вынесено сюда.


Каково значение результатов того же Грабина в деле формирования облика ЖЦ, адекватного требованиям времени, все мы понимаем - скоро будем отмечать 65-летие Победы, которую обеспечило и решение этой задачи тоже. Вопрос - как мы будем решать её для новой предметной области - ведь потенциально возможные вызовы ХХI века м.б. не менее серьёзны - мало ли какой может настать "особый период", в котором большие коллективы будут должны, быстро и чётко взаимодействуя, порождать гарантоспособные решения сложных проблем?

Каков возможный метод получения решения? Прежде всего это детальный расчётно-логический синтез точно по исходным данным. На с. 450 указывается, что наработка оптимально структурированных конструкций позволяет далее применять известный инженерный метод "рекле" (от РЕжь и КЛЕй :)) - брать максимально из "творческой базы", детальным методом лишь дополняя, если надо.
Кроме того, открывается дорога к применению менее популярного метода инженерии, который я могу назвать "методом Родена" (от известного ответа на вопрос, как он делает свои скульптуры: "- Я беру глыбу мрамора и отсекаю от него всё лишнее." :)) - составить систему-универсум для задач предметной области (заданного рода) и под конкретную задачу изымать из него ненужные компоненты. Как можно понять из описания Блэкбокса в этом сообщении, он позволяет работать как раз и "по Родену".

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

Предвижу вопрос: а как это связано с конкретикой сегодняшнего дня? Во-первых, показана активная роль технолога как участника реинжиниринга; принимая конструкцию (в нашем случае - модель бизнес-процесса), одновременно влиять на её облик. Кроме того, очерчена ведущая роль руководителя: Грабин сам установил более высокий уровень взаимодействия конструктора и технолога, причём для начала встал на сторону последнего, сначала указав, а затем запретив конструировать нетехнологичные изделия (причём своим же подчинённым).


Последний раз редактировалось Владислав Жаринов Суббота, 15 Октябрь, 2011 11:21, всего редактировалось 1 раз.

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

Зарегистрирован: Среда, 16 Ноябрь, 2005 00:53
Сообщения: 143
Откуда: Россия, Орёл
Выделено обсуждение: Автоматизация эргономики дракон-схем


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 10 Март, 2010 18:17 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 1443
Дмитрий_ВБ писал(а):
...можно ввеси кнопку смены представления «примитив/силуэт».
Если человек не хочет лазить вверх/вниз по примитиву, то вывести ему силуэт.

Читая Свердлова, дошёл до этого места :) :
Вложение:
Комментарий к файлу: Схема трансляции условного оператора (сложного ветвления) в машинный код
Свердлов-ЯПиМТ-Рис_3_9.png
Свердлов-ЯПиМТ-Рис_3_9.png [ 42.59 КБ | Просмотров: 22374 ]

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

Дмитрий_ВБ писал(а):
И эта же псевдографическая
логика работы программы может быть сравнительно легко расширена до полноценной
графической логики работы.

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


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

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

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

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

Более того, переводчик нового издания "Алгоритмов и структур данных" Н. Вирта (как я понимаю, здесь он Info21) в контексте проекта "Информатика-21" ставит задачу:
    "...создания единой системы вводных курсов информатики и программирования, охватывающей учащихся примерно от 5-го класса общей средней школы по 3-й курс университета. Такая система должна иметь образцом и дополнять уникальную российскую систему математического образования. Это предполагает наличие стержня общих курсов, составляющих единство без внутренних технологических барьеров (которые приводят среди прочего, к недопустимым потерям дефицитного учебного времени) и лишь варьирующихся в зависимости от специализации, вместе с надстройкой из профессионально ориентированных курсов, опирающихся на этот стержень в отношении базовых знаний учащихся. Такая система подразумевает наличие качественных учебников... «говорящих» на общем образцовом языке программирования. " (Вирт Н., 2010. - с.5).

С постановкой задачи согласен; ведь классическое образование языковое в своей основе, и специфика информатики лишь в том, что языки здесь формальные. В то же время введение образцового прогязыка (как суперкласса импер-/деклар-языков) считаю только одним из направлений её решения. Структуру полного решения определяет минимальный целостный базис языков представления знаний как часть того, что Белошапка называет "системно-информационным метаязыком". Определить состав и структуру классов базиса можно из соображений, отчасти развивающих классификацию знаний в /Паронджанов В.Д., 2001, с. 192-93/; моя точка зрения по-прежнему здесь. В базис входят языки и обобщённой формализации (отношу к ним синтдиаграммы, IDEF0), и описания исполнителей (функционального, типа СТО; временного - диаграмм сигналов в контролируемых точках, в т.ч. совмещённых на общевременных диаграммах; различные материальные схемы, как-то: размещения, подключений; вне информоделирования, но взаимосвязанно - всевозможные чертежи, планы и карты), и другие импер-языки, кроме ДРАКОНа (протокольных диаграмм, функциональных сетей и т.д. - а также и мульти-импер-язык, обсуждаемый сейчас). Постепенно ввожу эти языки в Драконографику.
Состав языков, подлежащих включению в каждый класс, можно и нужно обсуждать (как и можно иногда поспорить с тем, к какому классу отнести тот или иной язык).

Как сказано во /Фридланд, 2005, с.213/:
    "разработчики любых систем, в т.ч. информационных, д.б. в некотором смысле педагогами, потому что пользователя необходимо учить правильно (эффективно) управлять системой."

В силу этого языки д.б. как формальными, так и когнитивно-эргономичными. Решающую роль приобретает и когнитивная эргономичность языков, образующих среду обучения и применения полученных знаний - в первую очередь математического, о чём также писал Паронджанов.
    Вообще, "Математика - это язык плюс рассуждения, это как бы язык и логика вместе." (цит. по: /Фридланд А.Я., 2005, с.183/); также "Математический язык - это естественный язык, опирающийся на математические объекты и математические способы манипулирования ими, чем но отличается от просто естественного языка. От формального языка он отличается гибкостью, вариативностью, необязательностью жёсткой фиксации синтаксиса и семантики, использованием отчасти явно фиксированного, а отчасти умалчиваемого, но подразумеваемого контекста." (Агафонов В.Н., 1990. - с.150). Однако для передачи необходимых математических знаний нужно показывать восприёмнику и язык и логику, и явное и подразумеваемое - иначе процесс затянется.
Между прочим, и общий процесс вывода инвариантов не мешало бы визуализировать для широкой аудитории, если уж все должны доказательно алгоритмизовать... с использованием как "развилочной логики" ДРАКОНа, так и "эргономизации математики" в КогниСтиле... и это тоже насущный вопрос к профессионалам. И как "продвигать" инвариант цикла и "восстанавливать" его и другие вопросы - всё должно получить воплощение примерно такое скажем, как в /Паронджанов В.Д., 2001, Рис.140/ - тогда можно надеяться, что техноязыком сможет пользоваться тот рядовой технолог любой сферы деятельности, для которого язык, собственно, и предназначен (в своём прикладном обличье).

А принимая для методологии формализации "большую тройку" (системную триаду) "ЯПЗ-ТФЗ-ИСП", имеем необходимость кроме спецификации описывать также элементы техпроцесса говорения на языке и основы его реализации - однако это не проблема, а благо - ведь справедливо отмечено, что:
    "Спецификация <формального языка> - весьма строгий документ, который не может служить учебником по программированию. Она обычно ...не даёт рекомендаций по применению тех или иных конструкций..." (Свердлов С.З., 2007. - с.299).

Кстати, и второе и третье есть и для Оберона - о реализации в Прил.D к спецификации (по Свердлову), а о технологии программирования в "Алгоритмах..." Вирта - что вполне естественно.

В итоге получается документ, определяемый как "Руководство по разработке и документированию решений задач (бизнес-процессов)", а точнее, быть может, "...по информатической формализации профессиональных знаний". Структура документа, я думаю, должна быть такой, как установлена для МШ-метода. При этом в общей части вводятся качественные и математические основы.
Состав ЯПЗ (как импер-, так и деклар-языков) для специфицирования, полагаю, можно вводить, исходя из концепции "трёх схем", обычно применяемой к моделированию данных (ДАО рассматривается как язык нейтральных импер-схем).
Раздел ТФЗ как раз должен учить говорить любого предметника на ДАО - сначала в ручном варианте, а по мере появления общепринятых ДАО-сред и систем автоматизации - также и в них (посредством отдельных частных методик). В первом приближении можно рассматривать его как "визуализацию Вирта", но конечно, содержание м.б. построено и иначе - возможно, как главы "Как улучшить работу ума...", посвящённые визуализации или как "Драконографика для ДАО".
Определяя реализацию в разделе ИСП, нужно учесть, что среда, допускающая только строгую визуализацию, будет неэффективна для непрерывного сочинения. Поэтому нужно сразу вводить и нестрогий метод визуализации. Только строгий метод ещё возможно разрабатывать на "любительском" этапе развития (и в чём-то даже оправданно для облегчения поиска и наработки программных решений, о чём примерно говорил Дмитрий_ВБ) - но и при этом манипуляции сочинителя над схемой никак не м.б. клавиатурными - для этого есть "мышь"; и всё равно таким методом возможно лишь визуалов в режиме единичного производства, для целей исследования и иллюстрации (не слишком объёмной) отдельных ИТ-вопросов. Для дела же (массовой формализации практических задач с повседневной корректировкой сочинённого) нужно реализовать и нестрогий режим, не упрощая однако до потери корректности результатов.
    Далее, при реализации следует ограничиться одним прогязыком для гибридизации - в противном случае мы получим гибридный язык, как говорят на западе, "типа кухонной раковины", т.е. со средствами-"заплатками" на нестыковки разных (часто различных концептуально) прогязыков; фактически все их придётся "втащить" в каждый гибридный техноязык, и в результате получение исходного текста по визуалу из разовой операции превращается в объёмный рутинный труд по коррекции правил и/или результата трансляции схемы.
    Нужно идти системным путём - определить "интерлингву", т.е. язык промежуточного представления, через который переводят с одного языка на другой. Если теоретически это м.б. Активный Оберон - очень хорошо, если нужен более низкоуровневый язык (типа IL в MS.NET) - можно определить таковой, но сначала целостно, корректно и удобно для сочинителя реализовав ОДИН гибридный техноязык (и тем самым накопив опыт правильного "эсперантизма").
    На это нацеливает и известная "бритва Оккама", и формулировка Л.А. Заде "соотношения неопределённостей" применительно к системно-информационной сфере: "По мере возрастания сложности системы наша способность формулировать точные, содержащие смысл утверждения о её поведении уменьшается вплоть до того порога, за которым точность и смысл становятся взаимоисключающими." (цит. по /Фридланд А.Я., 2005, с.207/) - "дьявол прячется в деталях", и чем их меньше уже на уровне концепции, тем лучше. Есть и другие формулировки этого принципа, напр. "Нельзя требовать, чтобы всё формально определялось. То, что просто, не может быть, собственно говоря, определено." (Фреге Г. Понятие и вещь.) или "...в каждой отрасли имеется свой, специфический для неё момент тривиальности. ...когда становится бесполезным дальнейшее уточнение деталей, поскольку ...дополнительные подробности лишь вносят путаницу." (Фокс Дж. Программное обеспечение и его разработка.)


Формулировка ДАО в целостном и сжатом виде фактически уже начата в Драконографике при рассмотрении подхода Оберона-2 к объектам алгоритмов.
    С учётом этого предполагаю как основу для составления спецификации документ по Оберону-2 (в пер. Свердлова) и раздел об Активном Обероне из диссертации Мюллера. Черновой перевод последнего делаю сам; он не претендует на истину - возможно, где-то есть и качественные переводы или оригинальные русские тексты, но что есть - тем и воспользовался, а для понимания содержания перевод - далеко не худший путь :)

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


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

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


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

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


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

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


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

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