Advertisement

SOP = Системно ориентированное программирование

Jurassic World: Dominion Dominates Fandom Wikis - The Loop

01:25

SOP - Системно Ориентированное программирование (концепция)

Введение (описание документа)

В данном документе предлагается новая концепция создания программных систем (ПС), основанная на реалиях сегодняшнего дня. Ее основными чертами являются:

  1. Ориентация на внутренние модели объектов реального мира присущие мышлению человека.
  2. Радикально большая наглядность иерархического представления блоков программ (как следствие предыдущего пункта)
  3. Гораздо более высокий уровень защиты от сбоев в работе модулей программы.
  4. Ориентация на многоядерность, многопроцессорность и сетевое (включая кластерное) программирование.
  5. Ориентация на многократное использование компонентов программ.

Хотя, в совокупности, все вышесказанное выглядит достаточно амбициозно (если не сказать "революционно"), но, на самом деле, настоящая концепция, во многом, является, скорее, собранием идей разбросанным по другим, разнообразным, Системам создания приложений (IDE) и концепциям программирования (о чем в тексте даются ссылки).


Краткая история создания

Как и многие другие вещи, данная концепция родилась из неудовлетворенности существующими идеологиями создания программ и, основанными на них, средами разработки.

Изначально, я, автор данного документа, проводил опытно-научные исследования в области искусстенного интеллекта, а, точнее, основных механизмов работы нашего мозга. Для опробования различных алгоритмов по данной теме, мне приходится писать много экспериментальных программ, работающих с большим количеством входной, сенсорной информации (видео, аудио и др.), и реализующих достаточно сложные алгоритмы работы, включающие самообучение, ранжирование и прочие вещи, присущие ИИ. Также мне всегда требовалась визуализация большого количества (сотни) различных параметров, для контроля работы моих систем. Какое-то время, это было удобно делать с помощью ООП и библиотек визуализации GLScene в Delphi и (позднее) в Visual Python. На каком-то этапе, я пришел к выводу, что смоделировать объект, состоящий из великого множества параллельно работающих подсистем с помощью последовательно работающих программ просто "не получается" и мне необходимо массово-параллельное программирование. Так я пришел к Эрлангу, и познакомился с его концепцией "процессно-ориентированного программмирования" ((С) Джо Армстронг). Все это неплохо подходило для решения моих задач, но, к сожалению, в мире Эрланга отсутствуют развитые среды для создания структурно-сложных приложений. Кроме того, (по крайней мере, по моим впечатлениям) программируя на Эрланге, нужно многое помнить о особенностях его использования, что сильно мешает реализовывать собственные сложные задачи. Поневоле я задумался, "А как должно быть в идеале?" в результате чего и родилась данная концепция, оказавшаяся универсальной для нового программирования, поскольку она основана на общих особенностях мышления человека.


Текущее состояние программирования (кризис)

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

2. Многие современные программные системы стали необходимой частью жизни многих и многих людей на Земле, что с одной стороны принесло им не мало пользы, а с другой принесло и ряд проблем. Как то:

- Ненадежность ПО. Случается, что оно падает с самыми неприятными последствиями и чтобы восстановить его работу надо вызывать специально обученный для этого персонал и нести существенные потери. Желательно как-то существенно продвинуться в этой области.

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

3. С другой стороны: процессорная и графическая мощность современных настольных компьютеров значительно возросла. Тем не менее, в программировании это, практически, никак не используется - программисты, по прежнему, пишут в текстовых редакторах IDE и пользуются (часто) примитивными (UML) схемами программ, набросанными на бумаге или на доске.


Процесс программирования

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

1. Программист получает (придумывает) задание, которое нужно реализовать. Часто оно выражается в виде описания нового необходимого функционала системы. После этого он придумывает(/осваивает существующее) внутреннее устройство требуемой системы в виде некоторого множества взаимодействующих компонент (иерархических объектов, таблиц БД, элементов GUI и т.д.), которое совместно реализует требуемый функционал.

2. Реализует необходимые компоненты (классы\объекты\модули и т.д.) с их функциональностью.

3. Организует их взаимодействие.

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

5. Получает (/осознает) новые потребности в функционале и проводит требуемую модификацию подсистем для их реализации.

Здесь важно отметить, что в пункте 1. у программиста существует (/появляется) некоторая внутренняя модель системы (которая должна реализовать необходимый функционал или сама является объектом исследования/моделирования). И, в обещем-то, весь процесс написания ПО сводится к реализации этой внутренней модели в терминах программных объектов. Очевидно, что чем проще будет выражение внутренних ментальных моделей будет в этих терминах, тем будет проще и процесс программирования и процесс дальнейшей модификации полученного ПО.

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

Часто, весьма полезными и при прямом, так и при обратном преобразовании оказываются полезными разнообразные диаграммы UML (Use case, Взаимодействия и прочие (по потребности)).

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

Пункты 2. и 3. часто реализуются совместно, поскольку часто взаимодействие объектов и является частью их функционала.

В пункте 4. часть ошибок связана с тем, что использованные программистом функциональные компоненты (например, библиотечные функции) ведут себя не так как он представлял. Происходят некоторые непредвиденные внешние эффекты, включая "падение" отдельных компонент и программ.

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

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

Можно ли что-то тут сделать? Многие уже пытались, результаты не впечатляют. Но это не значит, что не стоит сделать еще попытку.

Цели и задачи для достижения

1. Упростить перевод внутренних ментальных моделей требуемой системы в программные системы.

2. Обеспечить максимальную наглядность получаемых ПС в статике и в динамике (при выполнении).

3. Обеспечить простоту их дополнения, модификации, создания новых необходимых компонент.


Как мы моделируем ментально

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

Здесь мы сталкиваемся с дилеммой: либо большая наглядность, либо стандартность описания. Если добиваться максимальной наглядности то, иногда, могут потребоваться и трехмерные движущиеся модели. Даже при условии избегания мелких ненужных деталей само их создание в компьютере, в настоящее время, это весьма нетривиальный процесс, для которого требуется некоторое обучение. Впрочем, весьма доступное. И общая тенденция в данной области, явно направлена на упрощение процесса получения требуемых форм. А что касается отображения готовых трех-мерных сцен, то с этим сейчас, вообще, проблем практически нет (спасибо разработчикам 3D-ускорителей).

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

(В качестве небольшого отступления от темы отметим, что согласно принципам ТРИЗ идеальным решением было-бы восприятием самим компьютером образов непосредственно из мозга. Опыты в этом направлении проводятся и, будем надеяться, они приведут в обозримом будущем к практическим результатам.)

Очевидно, желательно иметь все возможности для разных случаев: и 3D-модели (кому потребуется и кто умеет) и плоские схемы- рисунки (например, из пиктограмм\символов) и схемы из объектов - прямоугольников (с иконками на них или без них).

(отступление 2. Модели из прямоугольников активно развивает OMG Group в своем языке SysML (System Modeling Language) What-Is_SysML. Мое впечатление: лучше чем описания моделей в тексте, но недостаточно наглядно. Не очень оно соответствует внутренним человеческим ментальным моделям систем.)

Как это может выглядеть? Вот несколько концептуальных примеров отображения моделей:

(TODO: нарисовать и вставить примеры изображения ментальных моделей схемами , картинками, 3д моделями ...)

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

Мелко-автоматное моделирование

Если совсем в двух словах, то далее мы будем моделировать работу наших систем (\объектов) независимыми конечными автоматами. При этом не забываем, что подсистемы наших систем сами могут "раскрываться" в некоторые системы. А значит и наши автоматы тоже должны быть к этому приспособлены.

Что такое конечные автоматы (если кто не помнит) и обычное автоматное программирование хорошо описано у автора этой мощной концепции - д.т.н., профессор Шалыто А.А.,: Википедия и Кафедра

Однако мы не будем рисовать графы переходов автоматов из состояния в состояние, так как это не универсальный метод, для случая, когда этих состояний очень много. А Нам надо сохранить схему "читаемой" (\"понимаемой").

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

Эти понятия мы возьмем из Эрланга. Вернее из концепции параллельно-ориентированного программирования Джо Армстронга - см. его книгу по Эрлангу: вот ее незаконченный перевод глава 7, (в конце). А именно: все системы состоят из независимых параллельных процессов, которые обмениваются только сообщениями и имеют свой жизненный цикл (и могут "помереть"\"отказать").

Не все системы так просто переложить на такую модель. Если ее подсистемы физически воздействуют друг на друга, то, обычно, приходится вводить квантование времени и меру воздействия за этот квант. Трудности тут понятны.

Но, тем не менее, будем считать, что большинство нужных нам систем мы можем так выразить.

Пока не будем накладывать ограничения на сообщения, а рассмотрим подробнее процессы.


Обработка сообщений процессами

- только сообщения.

- очередь сообщений.


Реализация автоматов

- Раскрываемость в подсистему.

- внутреннее состояние (переменные).

- язык реализации. его свойства. Наглядность (картинки).

- внутренние функции.

- библиотеки функций.

- примеры изображений.


Контроль процессов (порождение и надежность)

Построение программной системы

- Иерархичность. последовательность.

- размещение процессов на процессорах и хостах. многоядерность и распределенность.

- Примеры: пользовательское приложение, веб-приложение, модель технической системы (ИИ?)


Развитие и обслуживание ПС

Наблюдение за процессами.

Отладка.

Профилирование.

Горячая замена кода.


Создание описанной системы программирования

Язык

графическая среда.

команда.



(будет продолжено.)

--M.Netov 19:52, мая 26, 2010 (UTC)

Материалы сообщества доступны в соответствии с условиями лицензии CC-BY-SA, если не указано иное.