Туннельное моделирование v0.1 — псевдокод

Доброго времени чтения, уважаемые участники habrahabr.ru

Туннельное моделирование — способ моделирования, основанный на использовании сочетания уровня абстрактности (девятиуровневом расширении модели взаимодействия  открытых систем) и цикла Деминга.

В предыдущем сообщении habrahabr.ru/post/176391 была представлена коллекция графических примитивов для использования при моделировании. Пример использования графической нотации приводится в статье Туннельное моделирование Единого знания. В этой статье обсудим возможность применения символов клавиатуры стандартного ПК для построения таких моделей.

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

На начало 2013 года модель состоит из четырех фаз и девяти уровней.

Поразительным образом количество возможных скобок на клавиатуре — четыре пары (и соответствует количеству мастей в картах).

Для пар скобок выбрано следующее назначение:
Элемент цикла
Деминга
пара скобок Причина
Act [...] Типовое обозначение для необязательных параметров
Plan {...} Соответствие данному направлению элемента структуры
Do <...> Как обозначение для тегов и обязательных параметров
Check (...) Использование для параметров функций, которые
получают значение к моменту вызова


Примерно такие совпадения по количеству символов нашлись для уровней абстрактности

Обозначим символы для уровней:
Уровень абстрактности Символ Причина
Прикладной ? соответствие функциональному уровню и проблемам классификации
Представительский @ соответствие контексту и интерфейсам
Сеансовый % возможность сравнения изменений
Транспортный ^ связано с указателями Паскаля
Преобразующий ! как отображение важности действия
Сетевой & AND, как символ взаимодействия
Системный * напоминает о целостности системы
Канальный $ напоминает о накоплении, как основной задаче на данном уровне
Физический # как символ, менее всего подходящий другим уровням


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

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

Тогда для использования внутри модели могут использоваться стандарные скобочные символы. Однако, можно ввести еще одни спецскобки для описания иерархии включения элементов: пара скобок {: ... :}. К ним также применяется правило окружения пробельными символами. Ждут определения своего применения похожие пары скобок: [: ... :], <: ... :>, (: ... :)

Перечень терминов туннельного моделирования версии 0.2:

[ Совершенствование ] { Планирование } < Действие > ( Проверка )
Идея
Логический
[ Необходимость ] { Направленность } < Несуществование > ( Отрицание )
navigation (прослеживание связей, навигация)(1)
 
association end (полюс ассоциации)(1)
dynamic simulation
(динамическое моделирование)(1)
generalization set name (имя набора
обобщений)(1)
metadata (метаданные)(1)
N-ary association (N-арная
ассоциация)(1)
navigability (возможность навигации)(1)
system
conception (концептуализация
системы)(1)
Бизнес-руководители(2)
Мотивация
(-)(2)
Планировщик(2)
 
NULL (нуль)(1)
 
virtual (перекрываемое)(1)
 
Прикладной
[ Цель ] { Респондент } < Функция > ( Состояние )
  actor (действующее лицо)(1)
namespace (пространство имен)(1)
swimlane (плавательная дорожка)(1)
Люди, организации(2)
 
abstract operation (абстрактная операция)(1)
application analysis
(анализ приложения)(1)
metaclass (метакласс)(1)
pattern (образец,
паттерн)(1)
use case (вариант использования)(1)
Архитектура
приложений(2)
Список основных бизнес-процессов(2)
Функции,
Процессы(2)
 
composite state (составное состояние)(1)
enumeration
(перечисление)(1)
ordered (упорядоченный)(1)
state
(состояние)(1)
 
Представительский
[ Точка зрения ] { Обобщение } < Интерфейс > ( Оценка )
layer (уровень)(1)
Сфера действия (контекст)(2)
 
abstraction (абстракция)(1)
class (класс)(1)
classification
(классификация)(1)
generalization (обобщение)(1)
model
(модель)(1)
superclass (суперкласс)(1)
 
abstract class (абстрактный класс)(1)
API(1)
application
programming interface (интерфейс программирования приложений)(1)
boundary class (пограничный класс)(1)
encapsulation
(инкапсуляция)(1)
interface (в java)(1)
user interface
(пользовательский интерфейс)(1)
wrapper
(обертка)(1)
Владелец, менеджер(2)
 
 
Сеансовый
[ Критерий ] { Прогноз } < Культура > ( История )
Модель предприятия(2)
 
rapid prototyping (быстрое прототипирование)(1)
system design
(проектирование системы)(1)
Важнейшие события(2)
Мастер-план
реализации(2)
Мотивация(2)
Перспективы (строки в таблице)(2)
 
interactive interface (интерактивный интерфейс)(1)
N-tier
architecture (многоуровневая архитектура)(1)
OO development
(объектно-ориентированная разработка)(1)
SQL(1)
system architecture
(архитектура системы)(1)
three-tier architecture (трехуровневая
архитектура)(1)
UML(1)
unified modeling language (унифицированный
язык моделирования)(1)
visibility (видимость)(1)
 
origin class (исходный класс)(1)
persistent object (постоянный
объект)(1)
UML1(1)
UML2(1)
 
Транспортный
[ Стратегия ] { Планирование } < Обучение > ( Познание )
architecture (архитектура)(1)
single inheritance (единственное
наследование)(1)
strong typing (жесткая типизация)(1)
weak typing
(слабая типизация)(1)
Бизнес-цели и стратегии(2)
Модель
системы(2)
Работающие бизнес-стратегии(2)
 
Бизнес-план(2)
 
derived class (производный класс)(1)
descendant class
(класс-потомок)(1)
enterprise model (модель предприятия)(1)
polymorphism (полиморфизм)(1)
state model (модель состояний)(1)
 
analysis (анализ)(1)
reverse engineering (инженерный анализ)(1)
 
Управляющий
[ Сценарий ] { Обеспечение } < Проект > ( Аудит )
activity (деятельность)(1)
control (управление)(1)
forward
engineering (прямое конструирование)(1)
life cycle (жизненный
цикл)(1)
policy method (стратегический метод)(1)
scenario
(сценарий)(1)
waterfall development (водопадная модель
разработки)(1)
Технологическая (физическая) модель(2)
 
extend (расширение)(1)
iterator (итератор)(1)
programming-in-the-large (программирование крупных
систем)(1)
ИТ-менеджеры и
разработчики(2)
Проектировщик(2)
Технологическая архитектура(2)
 
class design (проектирование классов)(1)
class diagram (диаграмма
классов)(1)
denormalization (денормализация)(1)
Системный
проект(2)
 
integration testing (тестирование интеграции)(1)
system testing
(тестирование системы)(1)
 
Оценивающий
[ Отношение ] { Помощь } < Управление > ( Учет )
composition (композиция)(1)
inheritance
(наследование)(1)
Архитектура интерфейса пользователя(2)
 
extensibility (расширяемость)(1)
method caching (кэширование
методов)(1)
 
active object (активный объект)(1)
controller (управляющий
объект)(1)
delegation (делегирование)(1)
lock
(блокировка)(1)
Время, расписания(2)
 
Бизнес-события(2)
 
Выравнивающий
[ Роль ] { Организация } < Соревнование > ( Контроль )
Люди(2)
Роли и модели бизнес-правил(2)
 
dynamic binding (динамическая привязка)(1)
interaction model
(модель взаимодействия)(1)
object-orientation (объектная
ориентированность)(1)
OO(1)
 
modularity (модульность)(1)
race condition (ситуация гонок)(1)
 
activity token (маркер деятельности)(1)
unit testing (модульное
тестирование)(1)
 
Технологический
Практический
[ Компетентность ] { Согласование } < Реализация > ( Результат )
library (библиотека)(1)
Реальные люди, организации(2)
 
friend(1)
implementation modeling (моделирование реализации)(1)
methodology (методология)(1)
multiple inheritance (множественное
наследование)(1)
peer (равные, одноранговые)(1)
Работающее
предприятие(2)
 
development (разработка)(1)
implementation
(реализация)(1)
Реализация бизнес-логики(2)
 
Детали реализации(2)
Сеть, расположение систем(2)
 
Ответственный
Устойчивый
[ Ответственность ] { Регламент } < Граница > ( Устойчивость )
responsibility (ответственность)(1)
 
activity diagram (диаграмма деятельности)(1)
development life cycle
(жизненный цикл разработки)(1)
sequence diagram (диаграмма
последовательности)(1)
substate (подсостояние)(1)
thread of control
(поток управления)(1)
 
final (для класса java)(1)
final (для метода java)(1)
system
boundary (граница системы)(1)
Архитектура безопасности(2)
 
changeability (изменяемость)(1)
coherence (согласованность,
цельность)(1)
implementation inheritance (наследование в
реализации)(1)
leaf class (листовой класс)(1)
robust
(устойчивость)(1)
 
Параллельный
[ Процедура ] { Взаимодействие } < Экземпляр > ( Завершение )
partition (раздел)(1)
specialization (конкретизация)(1)
 
concurrent (параллельный)(1)
direction (направление)(1)
transaction manager (администратор транзакций)(1)
 
focus of control (фокус управления)(1)
lifeline (линия
жизни)(1)
object (объект)(1)
reification (воплощение)(1)
transient object (временный объект)(1)
Дислокация,
сеть(2)
Работающие программы(2)
 
automatic transition (автоматический переход)(1)
completion
transition (переход по завершении)(1)
destructor (деструктор)(1)
garbage collection (сборка мусора)(1)
 
Специальный
[ Требование ] { Поставщик } < Продукция > ( Потребитель )
signature (сигнатура)(1)
subclass (подкласс)(1)
Архитектура
презентации(2)
Разработчик(2)
 
ancestor class (класс-предок)(1)
concrete class (конкретный
класс)(1)
constructor (конструктор)(1)
fourth-generation language
(язык четвертого поколения)(1)
method resolution (разрешение
методов)(1)
new (оператор создания объектов)(1)
object management
group (группа управления объектами)(1)
OMG(1)
public
(открытая)(1)
server (сервер)(1)
stored procedure (хранимая
процедура)(1)
 
  client (клиент)(1)
 
Межсетевой
[ Состав ] { Вход } < Процесс > ( Выход )
include (включение)(1)
iterative development (итерационная
разработка)(1)
Ключевые организации(2)
Модель
бизнес-процессов(2)
Программный код(2)
Сеть(2)
Структура
процессов(2)
 
entry activity (деятельность при входе)(1)
schema (схема)(1)
 
activation (активация)(1)
batch transformation (пакетное
преобразование)(1)
continuous transformation (непрерывное
преобразование)(1)
development stage (этап разработки)(1)
do
activity (текущая деятельность)(1)
method (метод)(1)
operation
(операция)(1)
service (сервис)(1)
software engineering (разработка
программного обеспечения)(1)
Модель Захмана(2)
Схема
логистики(2)
Функции(2)
 
exit activity (деятельность при выходе)(1)
view
(представление)(1)
 
Системный
[ Знание ] { Система } < Альтернатива > ( Использование )
association class (класс ассоциации)(1)
data dictionary (словарь
данных)(1)
object constraint language (объектный язык
ограничений)(1)
OCL (объектный язык ограничений)(1)
shopping-list
operation (операция по списку)(1)
Конструктор, архитектор(2)
Модель
потока работ (workflow)(2)
Описания бизнес-правил(2)
 
database management system (система управления базой данных)(1)
DBMS (СУБД)(1)
information hiding (сокрытие информации)(1)
package
(пакет)(1)
private (закрытая)(1)
protected (защищенная)(1)
relational dbms (реляционная субд)(1)
system (система)(1)
Логические
модели данных(2)
 
OO database (объектно-ориентированная база данных)(1)
OO
programming language (объектно-ориентированный язык
программирования)(1)
OO-DBMS (объектно-ориентированная СУБД)(1)
override (подмена или перекрытие)(1)
 
fire (запустить фактически)(1)
implementation method (метод
реализации)(1)
overloading (перегрузка)(1)
refactoring
(рефакторинг)(1)
state diagram (диаграмма состояний)(1)
Сетевая
архитектура(2)
 
Канальный
[ Правило ] { Структура } < Субъект > ( Ресурс )
access specifier (спецификатор доступа)(1)
base class (базовый
класс)(1)
condition (условие)(1)
constraint (ограничение)(1)
derived element (производный элемент)(1)
guard condition (сторожевое
условие)(1)
normal form (нормальная форма)(1)
 
aggregation (агрегация)(1)
assembly (совокупность)(1)
class
model (модель классов)(1)
container class (класс-контейнер)(1)
dictionary (словарь)(1)
framework (каркас)(1)
index (индекс)(1)
link (связь)(1)
procedure-driven control (процедурное
управление)(1)
relational database (реляционная база данных)(1)
subsystem (подсистема)(1)
table (таблица)(1)
use case diagram
(диаграмма вариантов использования)(1)
Модель распределенной
архитектуры(2)
Описание структуры данных(2)
Физическая модель
данных(2)
 
access modifier (модификатор доступа)(1)
effect (действие)(1)
event-driven control (событийное управление)(1)
reference
(ссылка)(1)
reflection (рефлексия)(1)
this (целевой
объект)(1)
Структуры управления(2)
 
attribute (атрибут)(1)
bag (мультимножество)(1)
database (база
данных)(1)
member (составляющая класса, в с++)(1)
passive object
(пассивный объект)(1)
qualifier (квалификатор)(1)
submachine
(вложенный конечный автомат)(1)
value
(значение)(1)
Данные(2)
Данные(2)
 
Физический
[ Сущность ] { Объект } < Сообщение > ( Событие )
_ тестовая строка(1)
Список важных понятий и объектов(2)
 
domain analysis (анализ предметной области)(1)
extent of a class
(экстент класса)(1)
Концептуальная модель данных(2)
Территориальное
расположение(2)
 
call-by-value (вызов по значению)(1)
cardinality (кардинальное
число, мощность)(1)
default value (значение по умолчанию)(1)
identifier (идентификатор)(1)
object identity (индивидуальность
объекта)(1)
qualified association (квалифицированная ассоциация)(1)
signal (сигнал)(1)
value-based identity (индивидуальность, основанная
на значениях)(1)
 
change event (событие изменения)(1)
event (событие)(1)
nested
state (вложенное состояние)(1)
region (область)(1)
signal event
(событие сигнала)(1)
time event (событие времени)(1)
transition
(переход)(1)
Время(2)
Определение временных привязок(2)
 
Хаотический
[ Существование ] { Связь } < Способность > ( Случайность )
entity-relationship (ER) model (модель сущность-связь)(1)
ER
(сущность-связь)(1)
 
association (ассоциация)(1)
call-by-reference (вызов по
ссылке)(1)
foreign key (внешний ключ)(1)
primary key (первичный
ключ)(1)
scope (область действия)(1)
sequence
(последовательность)(1)
ternary association (тернарная
ассоциация)(1)
 
candidate key (потенциальный ключ)(1)
feature (составляющая)(1)
identity (индивидуальность)(1)
multiplicity (кратность)(1)
object
diagram (диаграмма объектов)(1)
static (данные и методы класса)(1)
transitive closure (транзитивное замыкание)(1)
 
real-time system (система реального времени)(1)
 
Пространственный
Пустой
1) UML 2.0. Объектно-ориентированное моделирование и
разработка. 2-е изд. — СПб.: Питер, 2007.
2) Захман — Архитектура и стратегия. «Инь» и «Янь»
информационных технологий предприятия


Мнение автора может не совпадать с Истиной. Для того и публикация, чтобы к Истине приблизиться.

По поводу вопросов — прошу оценить возможность их размещения в соответствующих темах:

По уровням абстрактности — habrahabr.ru/post/176249 (Абстрактность и модель взаимодействия открытых систем)

По циклу Деминга и графическому моделированию — habrahabr.ru/post/176391 (Модель взаимодействия открытых систем, цикл Деминга и Туннельное моделирование)

Для создания графических моделей разработана библиотека для среды MS Visio. Она доступна по адресу palexisru.narod.ru/sisyphus/visio/TunnelElements.zip. Для работы с этой библиотекой рекомендуется использование шаблона SADT. Особенно — рамка шаблона.

Психологической основой для данного подхода является трехмерная шкала Ганса Юргена Айзенка (психотизм, нейротизм, экстраверсия). Это позволяет предположить наличие у человека предрасположенности к такому подходу.

На этом я прощаюсь с участниками habrahabr.ru, как автор идеи туннельного моделирования, и — сразу возвращаюсь, как сторонник данного подхода.

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

Найти информацию пока можно по ключевым словам «туннельное моделирование» в строке поиска.

Жду вопросов, опровержений, предложений, задач для проверки подхода.
Спасибо.

Литература:
Рамбо, М. Блаха UML 2.0. Объектно-ориентированное моделирование и разработка 2-е изд.-СПб: Питер, 2007
Данилин А., Слюсаренко А. Архитектура и стратегия. «Инь» и «Янь» информационных технологий предприятия: Интернет-Ун-т Информ. Технологий, 2005

UPD: связанные статьи

Абстрактность и модель взаимодействия открытых систем habrahabr.ru/post/176249
Модель взаимодействия открытых систем, цикл Деминга и Туннельное моделирование habrahabr.ru/post/176391

UPD2: 31/05/2014 — список терминов обновлен в соответствии с девятнадцатиуровневой моделью взаимосвязи открытых систем habrahabr.ru/post/203770
Ads
AdBlock has stolen the banner, but banners are not teeth — they will be back

More

Comments 37

    +6
    Вы опять так и не привели решаемую задачу.
      +3
      Вот-вот. Не хочу никого обидеть, но сейчас статья имеет следующий смысл: есть некоторый способ моделирования, есть какие-то «смайлики», которые обозначают какие-то объекты/операции, есть отсылки к некоторым областям знания/литературе. Все. Остальное осталось «за кадром». В общем, то ли я дурак, то ли лыжи не едут, но суть статьи мне не ясна.
        0
        Суть проста:
        Имеется линейная шкала абстрактности от 0% до 100%, на которой выделяется 9 нечетких уровней
        Имеется круговая шкала фаз цикла Деминга от -100% до +100%, на которой выделяется 4 нечетких области фазы

        Предлагается использование комбинации этих двух шкал при анализе и проектировании

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

        С уважением, Алексей.
          +4
          А зачем использовать эти шкалы при анализе и проектировании?

          Заодно — при анализе и проектировании чего?
            0
            А зачем использовать эти шкалы при анализе и проектировании?

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

            Мысль в том, что они ортогональны друг другу и могут совместно образовать двумерное пространство (если уж совсем точно, то сферу)
              0
              Это еще одно направление, в котором можно развивать стандартизацию.

              Стандартизацию чего?
                0
                Управления качеством информационных систем
                  0
                  Что такое «качество информационной системы»?
                    0
                    Я так думаю, что это качество в применении к информационной системе

                    Согласно ГОСТ Р ИСО 9000-2008 (отмененному):

                    3.1.1. КАЧЕСТВО (quality): степень соответствия совокупности присущих ХАРАКТЕРИСТИК (3.5.1) ТРЕБОВАНИЯМ (3.1.2).
                    Примечания
                    1. Термин «качество» может применяться с такими прилагательными, как плохое, хорошее или превосходное.
                    2. Термин «присущий», являющийся противоположным термину «присвоенный», означает имеющийся в чем-то, особенно если это относится к постоянным характеристикам.

                    Согласно N 149-ФЗ (федеральный Закон Об информации, информационных технологиях и о защите информации)
                    Статья 2. Основные понятия, используемые в настоящем Федеральном законе
                    3) информационная система — совокупность содержащейся в базах данных информации и обеспечивающих ее обработку информационных технологий и технических средств;
                      0
                      И какие же вы будете измерять соответствие характеристик информационной системы функциональным требованиям заказчика?
                        0
                        Измерят и без меня — по наработке на отказ, времени отклика, количеству успешных обращений и т.п.
                        Я предлагаю управлять
                          +1
                          Понятно. Вас не смущает, что описанные вами параметры не имеют отношения к функциональным требованиям?

                          Как вы собираетесь управлять тем, что вы не знаете, как контролировать?
                            0
                            По принципу «черного ящика»
                            Программа работает? Не трогай!

                              0
                              Чтобы управлять чем-то (равно как и контролировать), не надо лезть внутрь, нужно пользоваться публичным интерфейсом.

                              Но нельзя управлять чем-то, не умея контролировать его.
                                0
                                Прошу еще раз взглянуть на вторую (или третью) схему на habrahabr.ru/post/176391/ (Модель взаимодействия открытых систем, цикл Деминга и Туннельное моделирование) и подсказать, где я могу поискать контроллирование. Чем оно отличается от управления?
                                  0
                                  Во-первых, я не понимаю, почему я должен опираться на ваши же схемы.

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

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

                                    Кроме того могут быть две ситуации, когда Ваши глаза будут Вас обманывать:
                                    — машина села на свой мост
                                    — спидометр сломался
                                      0
                                      Мне не важно, что «получается». Мне важно, что нельзя (бессмысленно) «управлять качеством информационной системы» не имея средств контроля этого качества.
                                        0
                                        Мне не важно, что «получается».
                                        При таком подходе Ваше управление проявляет черты бессмыссленности — в Вашей терминологии
                                          0
                                          Речь не об управлении, а о вашем обсуждении.
      0
      На сайте Интегрального сообщества предложено поискать подход к проблеме Единого Знания
      integral-community.ru/forum/viewtopic.php?f=12&t=32
      Проект «Единое Знание»
      (координатор – д. филос. н., проф. Войцехович В.Э.)

      Цель – дискуссии, обсуждение и разработка участниками проекта возможности создания учения, объединяющего все основные типы знания — мировоззренческие, научные, художественные и иные.
      Почему возникает такая задача? – Потому что человечество накопило гигантские объёмы всевозможных знаний, представлений, образов, переживаний. Все они совершенно неорганизованны, разбросаны по библиотекам, сайтам, музеям, головам 7 миллиардов жителей Земли и напоминают беспорядочную «кучу» информации, разобраться в которой очень трудно.

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

      Частные знания составляют наука, искусство, обыденные представления («житейская мудрость»).

      Можно ли навести порядок в этом хаосе, состоящем из священных писаний, теорий, понятий, индивидуальных и коллективных переживаний и образов?
      Можно. И в это верили многие из великих мыслителей.


      Описание направления — на странице integral-community.ru/projects/uni-knowledge/

      В журнале Интегральная философия ( integral-community.ru/journal/ ) в № 1, 2012 опубликована статья: В.Э. Войцехович. Возможно ли Единое Знание? integral-community.ru/magazine/Integral-philosophy-mag1.pdf стр.26 — 34

      В журнале №2, 2012 integral-community.ru/magazine/Integral-philosophy-mag2.pdf стр. 81 — 94 опубликован мой вариант подхода к моделированию Единого Знания

      Просто, философов с математическим образованием в сообществе — как минимум, трое, а из программистов — похоже, я один.

      Присоединяйтесь — подумать.
        +1
        И как ваше «туннельное моделирование» этому помогает?
          0
          в 2004 году на civ.icelord.net/read.php?f=5&i=2324&t=2324 было первое предложение по оценке абстрактности, рациональности, глубины терминов

          Сейчас добавился контекст и выявлены основные кандидаты на то, чтобы быть «лицом сегмента».

          Увы, работать пришлось в основном в одиночку, только в последние годы удалось научиться объяснять, что же получается.

          При этом ( см. таблицу вверху) выяснилось, что можно провести параллель между ранними вариантами модели Захмана и полученной схемой, что позволяет сделать вывод об их равнозначности при поиске «белых пятен» стадии анализа. Модель Захмана содержит одну количественную и шесть качественных координат, данная модель — две количественных.

          Т.е. можно выдвинуть гипотезу о методологическом преимуществе данного подхода перед моделью Захмана.

          как то так…
            +1
            Я еще раз спрашиваю: какую задачу решает ваше «туннельное моделирование»? Конкретно, по пунктам.

            P.S.
            только в последние годы удалось научиться объяснять, что же получается.

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

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

                Естественно, технологии и методы и сейчас позволяют писать замечательные программы, но Вы тоже читаете на habrahabr о том, что студентов учат не тому.
                  0
                  На практике все подобные методологии радостно разбиваются о суровую реальность — поддерживать такую документацию часто дороже, чем систему построенную по ней. А для того чтобы объяснить разработчику задачу хватает текстов в свободной форме.
                    0
                    Думаю, что данный подход может неплохо поддаваться математизации, в частности, проверке целостности описания.
                    Первые схемы SADT рисовались на бумаге, потом до ПК добрался BPWin.

                    Согласитесь, что программу для такой технологии можно нарисовать даже в Access. Главное — знать, что можно сделать и так.
                0
                Конкретно, я в последнее время при необходимости анализа задачи беру шаблон из 10 файлов Visio с гиперссылками (один — оглавление 0.vsd, и по одному на каждый уровень: лист с циклом Деминга и по одному листу для декомпозиции каждого элемента цикла Деминга на данном уровне), копирую в новый каталог, и стараюсь заполнить все ячейки. При необходимости — выполняется простейшая структурная декомпозиция ячеек.

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

                Дальнейшую документацию сравниваю с полученными схемами, и смотрю, что еще не учтено.

                Т.е.на данном этапе, задача — «живая шпаргалка» для предпроектного обследования.
                  0
                  Простите, какого предпроектного обследования? Обследования чего?
                    0
                    Подготовка технического задания на учетные задачи
                      +1
                      Подготовка технического задания не является предпроектным обследованием.

                      Я же говорю — вы постоянно путаетесь в конкретном применении.
                        0
                        kill-sveta.narod.ru/pr_ais.html
                        Предпроектное обследование является предпроектным обследованием и предшествует подготовке технического задания
                          0
                          Предшествует, да. Но это никак не отвечает на вопрос «какого предпроектного обследования» и «обследования чего».
                            0
                            А зачем?
                            Последнее, на чем обкатывалась методика — задача по хранению информации об оборудовании, документах, связях оборудования и документов. Считайте, что рельс на железной дороге или труба в составе нефтепровода.
                              0
                              Потому что надо понимать спектр решаемых задач. И понимать, зачем они делаются.
                                0
                                Насчет спектра Вы правы. Данный подход в последнюю очередь стоит пробовать на технологических процессах, но он должен помочь в системах разных масштабов с участием людей.

        Only users with full accounts can post comments. Log in, please.