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