разработка языка программирования и обследования
0,0
рейтинг
10 апреля 2013 в 21:17

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

Доброго времени чтения, уважаемые участники 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
Алексей Подоров @palexisru
карма
1,0
рейтинг 0,0
разработка языка программирования и обследования
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое Разработка

Комментарии (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
            Вы уже начинаете извиваться и разделять самоубийства на кошерные (голыми руками) и некошерные (повеситься, поджариться, и т.д.)…

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

Интересные публикации