Абстрактность и модель взаимодействия открытых систем

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

    Данная статья нацелена на обсуждение применения измерения абстрактности.

    В книге — Архитектура и стратегия. Инь и Янь информационных технологий предприятия — красной нитью проходит использование уровней абстрактности для создания моделей предприятия и информационных технологий. Аналогичная мысль содержится в классификации уровней информационных систем для предприятий связи — Бизнес-процессы в компаниях связи

    На аналогичную идею применения абстрактности я вышел в 2003 году при чтении учебников философии (Философия для аспирантов). Через год (в результате обсуждения идеи на форуме) появилась идея измерения абстрактности в процентах.

    Чтобы оставить в покое философию и перейти к IT, отмечу, что на мой взгляд, абстрактности 100% соответствует понятие идеи Платона и Гегеля, для осознания которой достаточно только самого понятия идеи. Узнаете рекурсию?

    Абстрактность 0% (опять же, на мой взгляд) имеет абсолютный вакуум. Для него достаточно идеи «Ничего нет!».

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

    Отвлекусь на определение понятия "система". После чтения вариантов определений выяснилось, что не существует систем, не стремящихся к самосохранению. Отсюда — появилось определение системы:
    Система — структура, способная поддерживать состояние гомеостаза (обсуждение — http://www.philosophystorm.org/palex/2973).

    В связи с распространенностью программных систем и модулей System в средствах разработки был выделен Системный уровень (System layer).
    Еще один уровень, Преобразующий (Transformation layer) был выделен на 50% абстрактности, что соответствует медиане реальности.

    Итак, для практического использования предлагается следующая последовательность уровней:
    • Прикладной
    • Представительский
    • Сеансовый
    • Транспортный
    • Преобразующий
    • Сетевой
    • Системный
    • Канальный
    • Физический

    Обсуждается связь уровней с разделами человеческого знания. Для использования примитивов для уровней предлагается следующие графические и символьные обозначения:
    Уровни абстрактности
    Источник — http://integral-community.ru/magazine/Integral-philosophy-mag2.pdf, стр.82

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

    прикладной уровень ( Application layer )
    functional — Функциональное — для разделов, использующих функциональное программирование.

    представительский уровень ( Presentation layer )
    aspect — Аспектное — для интерфесов и аспектов. Для методов могут указываться необходимые свойства и дополнения, используемые перед методом (before), после метода (after) и при выполнении каждого оператора (invariant)

    сеансовый уровень ( Session layer )
    predicate — Логическое — соответствует Булевым переменным, доказательству теорем, Аристотелевкой логике, работе с запросами SQL, LINQ или простейшим операциям Prolog.

    транспортный уровень ( Transport layer )
    controller — Управляющее — соответствует контроллеру (Controller) модели MVC

    преобразующий уровень ( Transformation layer )
    publish — Изменяемое — соответствует представлению (View) для модели MVC

    межсетевой уровень ( Network layer )
    public — Соединяющее — соответствует модели базы данных (Model) модели MVC

    системный уровень ( System layer )
    protected — Защищенное — внутренние элементы класса

    канальный уровень ( Link layer )
    private — Внутреннее — скрытые элементы класса

    физический уровень (Physical layer)
    local — Блоковые — переменные методов и блоков

    Для анализа предлагается следующая последовательность проникновения в смысл происходящего:
    Последовательность анализа

    Спасибо за внимание критикующих.

    Литература и ссылки:
    1. Данилин А., Слюсаренко А. Архитектура и стратегия. Инь и Янь информационных технологий предприятия, М., Интернет-Ун-т Информ. Технологий, 2005
    2. Чаадаев В.К. Бизнес-процессы в компаниях связи. Эко-Трендз. 2004
    3. Сальников В.П. Сандулов Ю.А., Гуцериев Ч.С., Кальной И.И. Философия для аспирантов — СПб.: Издательство “Лань”, 2001
    4. Предложения по применению модели взаимодействия открытых систем для разработки универсального языка программирования http://pl2-rainbow.livejournal.com/1710.html


    Тема предназначена для ознакомления с идеей шкалы абстрактности и обсуждения ее соответствия с моделью взаимодействия открытых систем.
    Может появиться вопроc: «А что дальше?».
    Тем, у кого такой вопрос появился, предлагаю ознакомиться со статьей по Туннельному моделированию Единого знания
    http://integral-community.ru/magazine/Integral-philosophy-mag2.pdf, стр.81-96.

    UPD: последующие связанные статьи
    • Модель взаимодействия открытых систем, цикл Деминга и Туннельное моделирование habrahabr.ru/post/176391
    • Туннельное моделирование v0.1 — псевдокод habrahabr.ru/post/176935
    • Туннельное моделирование v 0.1. Сферическая модель мировоззрения. Презентация идеологии habrahabr.ru/post/177131
    Метки:
    Поделиться публикацией
    Похожие публикации
    Реклама помогает поддерживать и развивать наши сервисы

    Подробнее
    Реклама
    Комментарии 26
    • 0
      Респект. Ждем статью.
      • 0
        Спасибо. Статья по туннельному моделированию — на habrahabr.ru/post/176391/

        Надеюсь, она не разочарует.
        • +1
          Это не статья.
          • 0
            Тогда прошу совета: как Вы предложите написать о том, что шкала абстрактности и цикл Деминга могут составить цилиндрическую систему координат, которую можно применить в анализе предметной области и проекции модели на языки программирования?

            Мой вариант на форуме Интегрального сообщества- в integral-community.ru/forum/viewtopic.php?f=8&t=12
            • 0
              Я предложу об этом не писать.
              • 0
                Для того, чтобы Вы могли похвастаться, что лучше меня знаете UML и модель Захмана?
                • 0
                  Нет, зачем? Я не считаю, что хорошо (и уж тем более лучше вас) знаю UML.
                  • 0
                    Я, конечно, проштудировал «Унифицированный процесс разработки», но на меня он произвел меньшее впечатление в смысле элегантности, чем методологии SADT и SDL. А когда вышел на моделирование философии, появился такой вариант методологии.

                    Так почему бы не проверить и туннельное моделирование? Может, эта дорога ведет к храму?

                    С уважением, Алексей.
                    • 0
                      Прежде чем что-то проверять, нужно сформулировать решаемую задачу и понять, чем не устраивают существующие способы ее решения.
                      • 0
                        Хорошо, я попытаюсь позже сформулировать (надеюсь, решаемую) задачу для habrahabr
                        Сейчас с формулировками можно ознакомиться на www.philosophystorm.org/palex/2664 и pl2-rainbow.livejournal.com/3147.html
                        • 0
                          Описанное по ссылкам не имеет никакого отношения к методологиям разработки.
                          • 0
                            Да, это пример описания обучающей моделирующей игровой задачи (как «Цивилизация» или «Эпоха империй», только начинаются раньше).

                            А идея в том, что предлагаемую в топе идеологию моделирования можно использовать в составе реализации такой программы.
                            • 0
                              … и это тоже не имет отношения к методологии разработки.

                              Собственно, в этом и есть ваша проблема — вы не можете объяснить, какую именно задачу вы пытаетесь решить, и зачем.
                              • 0
                                Если про меня лично, то моя задача типична для программиста: минимизировать трудозатраты при разработке и сопровождении. Плюс — сделать так, чтобы постановщики могли читать документацию фазы разработки.

                                Лень — двигатель прогресса!
                                • 0
                                  Для этого давно придумана куча методологий. Та же DDD с ее ubiquitous language.

                                  А я не то что вашу документацию — ваши посты с трудом читаю.
                                  • 0
                                    Про DDD — незнакомые слова. Обязательно поищу.

                                    А про мой вариант — я думаю, что в результате он должен быть не сложнее, чем IDEF0.

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

                                    А про чтение постов — в детстве мне продемонстрировали частушку:
                                    Если Вас задавит поезд, Вы невольно вскрикните.
                                    Раз задавит, два задавит, а потом привыкните

                                    Для справки — один из членов моей семьи (дядя) умер под колесами маленького поезда.
                                • 0
                                  Лень — двигатель прогресса!
        • 0
          Если «в лоб» сравнивать вашу предложенную 9-уровневую схему с 7-уровневой OSI ISO, то, видно, что вы просто разделили «Сетевой» уровнень (в проекции на семейство TCP/IP этот Сетевой уровень отвечает за маршрутизацию) на 3 уровня: Преобразующий, Сетевой и Системный.

          Но, как бы, просто так, наращивать количество слоев абстракции только ради самих абстракций это дурная практика (антипаттерн имеет имя «Baklava code»). Введение любого уровня абстракции должно что-то давать в качестве весомого профита. Иначе можно придумать еще целый миллион слоев.

          • 0
            Шкала абстрактности может быть гладкой, и, возможно, лет через 100 системные аналитики, философы и филологи смогут нам предоставить оценку абстрактности термина в контексте с точностью до десятых долей процента.

            Год назад на сайте «Философский штурм» (http://www.philosophystorm.org/palex/1985#comment-18503) была предложена шкала image

            Лучшая из критических оценок —
            «Посмотрел на схему, показалось что разобрался в том, что такое бытие… »


            А в определении источников уровней Вы правы:

            Перераспределение назначений уровней, выделенных по ГОСТ Р ИСО/МЭК 7498-1-99

            Преобразующий уровень (между сетевым и транспортным уровнем) обеспечивает качество услуг, предоставляет независимость маршрутизации и ретрансляции, предоставляет функциональные и процедурные средства для обмена СБД сетевого уровня по соединению сетевого уровня между логическими объектами транспортного уровня
            К этому уровню можно отнести протоколы маршрутизации, уровень межсетевого взаимодействия стека TCP/IP

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

            При этом административное управление систем (8.3.3) может быть сконцентрировано на транспортном уровне.

            Использованы основые принципы разбиения уровней эталонной модели
            Пункт 6.2 ГОСТ Р ИСО/МЭК 7498-1-99
            a) не следует создавать слишком много уровней, потому что это усложнит системотехническую задачу их описания;
            b) проводить границу следует в том месте, где описание услуг является наименьшим и число операций взаимодействия через границу сведено к минимуму;
            c) следует создавать отдельные уровни для выполнения таких функций, которые явно различаются по реализующим их процессам или используемым техническим решениям;
            d) следует сосредоточивать аналогичные функции в одном и том же уровне;
            ….
            Примечание — Не всегда можно доказать, что выбранная уровневая организация является наилучшим решением. Однако существуют принципы, основываясь на которых можно решить, где должны проходить границы между уровнями и сколько должно быть границ:
          • +1
            Я считаю, надо так.
            image
            • 0
              Спасибо за поддержку деления по уровням :-)

              Следующим шагом, думаю, необходимо попробовать привязать к уровням и данной системе обозначений выделенные на сейчас паттерны проектирования.
            • 0
              " Отвлекусь на определение понятия «система». После чтения вариантов определений выяснилось, что не существует систем, не стремящихся к самосохранению. Отсюда — появилось определение системы:
              Система — структура, способная поддерживать состояние гомеостаза (обсуждение — www.philosophystorm.org/palex/2973). "

              Странно, на СА у нас давалось определение, что система — это функция от четырех параметров: времени, структуры, цели и ресурсов.

              Многие системы не то, что не стремятся, я неспособны поддерживать себя. Так что самоподдерживающаяся система — это все же подкласс всех систем.
              • 0
                Попытка опровержения №1:
                Система имеет цель, но она не сможет достигнуть цели, если не обеспечит самосохранение.
                • 0
                  Почему это?

                  Взять ту же психологию, есть понятие «влечения к смерти». Согласно вашим утверждением. у человека такого быть не может, ведь человек — система. Любой достаточно сложный робот — это механизм, который не думая пожертвует собой ради человека, потому что он на это запрограммирован, при этом он является сложной системой многих электронных компонент.

                  Кроме того, у системы может стоять цель — уничтожить себя. Кроме того, цель может быть достигнута до того, как система себя разрушит, «походя», так сказать.
                  • 0
                    >>Взять ту же психологию, есть понятие «влечения к смерти». Согласно вашим утверждением. у человека такого быть не может, ведь человек — система

                    Интересно, сколько Вы знаете случаев, когда человек задушил сам себя голыми руками?
                    В других случаях для самоубийства создаются более сложные системы. При этом есть отдельная статья Уголовного кодекса: «доведение до самоубийства».

                    Остальные случаи — использование подсистемы в составе более сложной системы, например — смертники в мусульманстве или японской армии с предоставлением более «высокой» цели по сравнению с личной жизнью.
                    • 0
                      Вы уже начинаете извиваться и разделять самоубийства на кошерные (голыми руками) и некошерные (повеситься, поджариться, и т.д.)…

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