DRAKON.SU
https://forum.drakon.su/

Диаграмма потоков данных
https://forum.drakon.su/viewtopic.php?f=135&t=3510		 Страница 2 из 2
Автор:  Владислав Жаринов [ Среда, 27 Июль, 2011 15:35 ]
Заголовок сообщения:  Re: Диаграмма потоков данных
Ильченко Эдуард писал(а):
...
Но моё мнение такое, что если партнёры не имеют возможность заменить алгоритмы друг у друга (в приказном порядке), то значит они являются внешними по отношению друг к другу и взаимодействие происходит только через интерфейсы. Если они внешние, то бизнес-процесс не может быть общим (хотя он таким выглядит до поры до времени).
Если взаимодействие произходит через интерфейс, то отваливание одного из партнёров будет неприятным, но не смертельным. Если отвалится внутренний компонент бизнес-процесса, то перестанет существовать и сам бизнес-процесс. В общем, в бизнес-процессе нужно пользовать блоки try-except : ) Конечно, имхо.
Вообще-то компонентная точка зрения на систему исходит из того, что внешнее - это когда и содержание "неэкспортируемых" процессов модулей друг другу не известно :) А в интерфейс могут входить и трудовые процессы - не только объекты труда. Тогда они известны - и на этапе разработки м.б. согласованы "модулями"-оргсистемами (подразделениями).

Насчёт исключений - в принципе возможно - поэтому в ДРАКОН-Алго я и ввёл соответствующие макровиопы. Но вот у разработчиков структурного редактора своя т. зр. - что исключения м.б. не нужны - см. в конце этого поста, скажем.
Мотивы, как я понимаю (если не прав - В. Лаптев меня поправит) - что "ситуации", известные разработчику (а неизвестные он вряд ли сможет описать как исключения :wink:) - это часть единой логики хода процесса. И их надо так и описывать. C этим также можно согласиться. Тогда исключения как особые языковые формы оставить в спецификациях (для которых, собственно, ДА-диалект и предназначен).
Автор:  Владислав Жаринов [ Среда, 27 Июль, 2011 15:47 ]
Заголовок сообщения:  Re: Диаграмма потоков данных
Ильченко Эдуард писал(а):
Драконограф писал(а):
(после приведения "процедуры, закреплённой за Исполнителем" к алгоритмическому виду - ибо, как я понимаю, изначально Вы допускаете и простое текстовое её описание?)

Для Исполнителя-человека текстового описания вполне достаточно. Ну не электроды же ему в голову вживлять : )
Более того, весь бизнес-процесс может не иметь электронного представления : )
Ясное дело... можно на бумаге рисовать :)

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

Соответственно уходим от текстового раскрытия сути вершин - всё на схемах. Но в эскизных моделях, безусловно, это м.б. удобно - поэтому и нужно сохранить неформальные описания вершин - которые я и называю "графит-примечаниями". Кстати, поскольку этот пример показывает именно эскиз - то они используются и для описания "закреплённых процедур" в отдельных вершинах - см. здесь некоторые действия по выводу твёрдой копии.
Автор:  Ильченко Эдуард [ Среда, 27 Июль, 2011 17:07 ]
Заголовок сообщения:  Re: Диаграмма потоков данных
Драконограф писал(а):
Вообще-то компонентная точка зрения на систему исходит из того, что внешнее - это когда и содержание "неэкспортируемых" процессов модулей друг другу не известно :)

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

При проведении границ применяю правило: если нет доступа к замене алгоритма, то это внешний компонент. Получается такая иерархически-распределённая сеть : ) При этом для системы где имеются два внешних, по отношению друг к другу, компонента, может иметься надсистема, где эти же компоненты будут внутренними по отношению друг к другу (при наличии общего руководителя/супервайзера).
Автор:  Владислав Жаринов [ Среда, 27 Июль, 2011 18:03 ]
Заголовок сообщения:  Re: Диаграмма потоков данных
Ильченко Эдуард писал(а):
Драконограф писал(а):
Вообще-то компонентная точка зрения на систему исходит из того, что внешнее - это когда и содержание "неэкспортируемых" процессов модулей друг другу не известно :)

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

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

По иерархии модулей обсуждения возникают на форуме периодически. Видимо, это определяется принятой архитектурой модели.

Я всё это к тому, что стоит использовать опыт, накопленный при компонентном программировании, для информоделирования оргтехсистем (включающих инфопроги как часть).
Автор:  Ильченко Эдуард [ Среда, 27 Июль, 2011 21:50 ]
Заголовок сообщения:  Re: Диаграмма потоков данных
Драконограф писал(а):
Вопросы использования явных компонентов другими модулями хорошо разобрал Свердлов в примере с гетерогенной очередью - см. в этой выдержке.

Вложение:
1.png
1.png [ 4.47 КБ | Просмотров: 9422 ]

Вложение:
2.png
2.png [ 6.64 КБ | Просмотров: 9422 ]

Улыбнуло это предложение : )

А когда циклов FOR, WHILE, REPEAT, а тем более LOOP нет, волей-неволей научишься применять GOTO! : )
Автор:  Владислав Жаринов [ Четверг, 28 Июль, 2011 06:25 ]
Заголовок сообщения:  Re: Диаграмма потоков данных
Ильченко Эдуард писал(а):
Драконограф писал(а):
Вопросы использования явных компонентов другими модулями хорошо разобрал Свердлов в примере с гетерогенной очередью - см. в этой выдержке.

Вложение:
1.png

Вложение:
2.png

Улыбнуло это предложение : )

А когда циклов FOR, WHILE, REPEAT, а тем более LOOP нет, волей-неволей научишься применять GOTO! : )
А цикл LOOP (в полной форме - LOOP-EXIT-END) есть всегда - это же обычный "гибридный цикл" :) Просто LOOP/END - это явное "вытаскивание" безусловных переходов, образующих вход в цикл - см. рисунок и текст к нему в конце этого пункта. Конечно, здесь БП - это не goto, а обычная "закрывающая скобка цикла".
Автор:  Владислав Жаринов [ Понедельник, 15 Август, 2011 12:36 ]
Заголовок сообщения:  Re: Диаграмма потоков данных
Драконограф в viewtopic.php?p=64312#p64312 писал(а):
... Я как раз хотел сказать, что Ваше представление близко к компонентному моделированию :) Только там каждый модуль имеет и явную, и скрытую части - см. определение ПК-языка. Только явная наблюдаема - это и есть "знаемое извне" о модуле (ясно, что определения скрытой и процессы их прогона влияют на какие-то явные компоненты). Одномодульная изолированная система может не иметь явной части; отдельные модули многомодульной могут не иметь скрытой.
...
Сказанное тут также связано с тем, что заменяемость процессов не имеет отношения к их алгоритмичности. Последняя определяется только квалификацией исполнителя - понятны ему операции и объекты или нет.

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

А главное, о чём шла речь - не стоит наделять визуал ещё и функциями описания компонентного строения. Он изображает отношение следования операций по маршрутам - и хватит с этого рода схем... ;)
Надо нам изобразить иные отношения уложенными на плоскости - вводим адекватную трактовку шампур-слепышей (и сответствующую разметку вершин и, возможно, рёбер). Тем более это важно для схем со многими отношениями. Вот Рэйлвей Каген обдумывал соответствующий синтаксис... возможно, он представит наглядный пример вроде предложенного в этом посте перевода IDEF1X-схемы задачи обучения...
Автор:  Ильченко Эдуард [ Воскресенье, 12 Август, 2012 13:48 ]
Заголовок сообщения:  Re: Диаграмма потоков данных
Некоторое продолжение о бизнесс-процессах здесь.
Страница 2 из 2 Часовой пояс: UTC + 3 часа
Powered by phpBB® Forum Software © phpBB Group
https://www.phpbb.com/