DRAKON.SU

viewtopic.php?p=63085#p63085









Собственно, суть вопроса проста. Какие выразительные средства предоставляет ИС Дракон для моделирования архитектуры системы (объектной структуры, правил взаимодействия, композиции и т.п.).

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

Я надеюсь, с ИС Дракон вы знакомы в деталях.

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

ИС Дракон, имеет несколько вариантов применения, будем иметь ввиду Графит, т.е. графика и текст.

Архитектура программы - такого термина нет.
В википедии есть Архитектура программного обеспечения

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

На этапе разработки проектного решения в ИС Дракон стороны заказчика и исполнителя формируют свои требования и согласованные решения в текстовом и алгоритмическом виде.

Для оформления модулей в ИС Дракон в схеме Гном должна присутствовать икона "Модуль".
Описание переменных, классов и объектов на уровне модуля выполняется в программном приложении иконы "Модуль"; в нем же находится инициализирующая и финальные части модуля; имя формируемого программного текстового файла; ссылки на схемы - процедуры модуля.
Описание переменных, классов и объектов на уровне процедуры выполняется в программном приложении схемы.
Все описания выполняются про правилам выбранного языка программирования.

Примеры программирования на языке СИ++ в режиме с разделением времени можно видеть у С. Ефанова.
Ефанов дает высокую оценку использования ИТ Дракон.

Не знаю, о чем вы здесь говорите, но если этот вопрос решается при программировании, то так же можно выполнить его в ИС Дракон, средств достаточно.

Тогда это не Ваша ИС Дракон предоставляет какие-то средства моделирования-проектирования, а тот самый "выбранный язык программирования".


Таким образом, никаких средств для сохранения "неформализованной [в программном коде на языке программирования] информации" у Вас нет. И для "имения его проекта (модели)".

Поэтому заявление "В настоящее время, всем требованиям в полном объеме удовлетворяет ИС Дракон." было сделано Вами поспешно.

Хорошо, этого достаточно, в ИС Дракон язык программирования интегрирован и формируется единая среда проектирования. Вы, не видите или не хотите видеть в ИС Драконе ее текстовой составляющей.

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

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

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

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

Уважаемый Драконограф.

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

Я не специалист в области "моделирование архитектуры системы", ИС Дракон предлагается как проблемно не ориентированное средство отображения, по определению, обеспечивающее наглядность. Так же предлагается услуга по оказании помощи в освоении ИС Дракон.

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

Геннадий Николаевич, так разве кто что против говорит или Вас обвиняет в этом.

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

Илья, вам моя помощь не требуется, будет необходимость - обращайтесь.

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

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

Хорошо хоть отошли от посыла, заложенного в этой схеме... так может, и схему пора исправить?