Pull to refresh

Comments 37

Я бы не назвал это ООП.
Это просто типичный способ упрощения работы дизайнеру алгоритма за счет того, что создается база данных сигналов под конкретный объект управления. Раньше это все писалось ручками и можно было легко сделать неуникальную переменную и получить проблемы.
Объекты — это часто физические компоненты — моторы, кнопки, задвижки и т.д и они импортируются из принципиальной схемы. Чтобы не возникало путаницы с сигналами, все эти объекты автоматически получают набор входных и выходных сигналов и параметров, которые имеют уникальные имена и которые потом кодогенератор может преобразовать в глобальные переменные. В этом и есть смысл базы данных сигналов. Никаких инкапсуляций, никаких классов, все направлено на то, чтобы скрипт, указанный в конце вашей статьи, сгенерировал нужный файл, в котором будут представлены все десятки тысяч сигналов, используемые в реально исполняемом коде.


Как верх стандартизации вы можете глянуть на IEC 61850, где четко прописано как все это дело должно работать.

Да принцип работы именно такой.
Но то что это совсем не ООП не соглашусь. Например:
Инкапсуляция – это свойство системы, позволяющее объединить данные и методы, работающие с ними, в классе и скрыть детали реализации от пользователя.
Когда я ставлю на схему блок, в примере статьи КД1, я как раз получаю классический пример инкапсуляции. Пользователь указывает сигнал с какого датчика он хочет получить в миливольтах, и задает параметры для пересчета и получает значения в единицах измерения, например в град Цельсия.
Классическое из ООП объединение данных и методов их обработки.

А где здесь методы?
Насколько я знаю эти вещи, кроме пересчета — т.е. умножения/деления на константу + оффсет + ограничение по максимуму/минимум, эта база данных не делает. Т.е. любой сигнал, по умолчанию проходит через этот пересчет и вы, если хотите, можете привести милливольты в Цельсии или напряжение в Per Unit. Но это все!

Здесь «метод класса» в терминах ООП, это схема внутри блока. В этой схеме можно реализовать любую логику обработки. Сама схема привязана к конкретному наименованному набору данных. Инкапсуляция — блок содержит схемы и набор данных.
Инкапсуляция — это свойство программной системы. Вы ещё назовите инкапсуляцией то, что прораб, который использует сантехника и электрика, не обязан знать детали их работы :)
А логика обработки сигнала с датчика, написанная на графическом зыке программирования, разве не является програмной системой?
В Си есть и инкапсуляция, и наследование, и полиморфизм.
Язык Си не является объектно-ориентированным языком. И значит все что будет описано ниже это костыли и велосипеды.
ООП включает в себя три столпа: инкапсуляция, наследование, полиморфизм. Ниже я покажу как этих вещей можно добиться в С.
habr.com/ru/post/263547
C++ начинался с препроцессора CFront, который из кода достандартного тогда еще C++ герерировал код на C. А тот уже компилировался в исполнимый код, как обычно.
Разница между современным C++ и C кажется огромной, но различия между этими языками не стоит преувеличивать. Приуменьшать, впрочем, тоже необязательно...)
Так как он не объектно-ориентированный, если он соответствует вашему же определению?)
Тем более, четкого и однозначно принятого определения ООП до сих пор нет.
Я так полагаю, что раз встроенных механизьмов реализции методоллогии ООП нет в С, а нужно делать из костылей и велосипедов, то это не ООП. А если стандратные средства поддерживают методологию ООП из коробки, то ООП. Наверное так как то, но это не точно ;)
С точки зрения пользователя СFront это ООП, а С — нет.
Что вы называете встроенными механизмами реализации методологии ООП и каких механизмов не хватает в Си?

Интересное, кстати разделение, если делать X — удобно, то это парадигма ООП, а если неудобно — не ООП.

По поводу механизмов — наследование структур есть, структуры могут содержать указатели на функции, вспомним, например, STDIN / STDOUT. инкапсуляция в Си из коробки получше чем в современных языках — всё инкапсулировано и скрыто в одном файле, пока вы сами, явно, не опишите, что из этого файла можно будет использовать снаружи. *

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

* Хоть четкого определения данной парадигмы нет, если полиморфизм и инкапсуляция довольно хорошие механизмы, и с развитием ООП/ООД они стали популярнее и удобнее, наследование отличительной чертой парадигмы я никак не могу назвать
Создатель ООП Алан Кей с вами бы не согласился:
«Я считал объекты чем-то вроде биологических клеток, и/или отдельных компьютеров в сети, которые могут общаться только через сообщения.»
«Мой опыт в математике заставил меня понять, что каждый объект может иметь несколько алгебр, они могут объединяться в семейства, и это может быть очень полезным.»
«Одна из ключевых идей: система должна продолжать работу во время тестирования о особенно во время произведения изменений. Даже крупные изменения должны быть поэтапными и занимать не больше доли секунды.»
«Позднее связывание позволяет с меньшими усилиями встраивать в проект идеи, которые возникли позже в процессе разработки (по сравнению с системами с более ранним связыванием вроде C, C++, Java, и пр.)»
«Я не против типов, но мне не знакома ни одна система типов, которая не вызывала бы боли. Так что мне все еще нравится динамическая типизация.» — Алан Кей за динамическую типизацию.
«ООП для меня это сообщения, локальное удержание и защита, скрытие состояния и позднее связывание всего. Это можно сделать в Smalltalk и в LISP.» — а наследования в Smalltalk не было вовсе.
В системах управления как правило все занчительно проще, с точки зрения типов:
На вход идет число — значение с датчика, на выход тоже число — команда упрвления, все число, даже если это логическое да или нет 0,1. Для упрощения можно считать что все числа — реальные двойной точности.
А «идеи возникшие позже», это разные схемы обработки этих чисел.
Я отвечал с чисто теоретической точки зрения на вашу реплику про «инкапсуляцию, наследование, полиморфизм». Я не знаю кто это придумал, но в большинстве российских (и, кажется, не только российских) вузов с этих слов начинается разговор про ООП и я не уверен, что это правильное начало разговора. По сути большинство вузов обучает не ООП и не программированию, а C++, Java или C#.
Ярко показывает степень разрыва в мышлении тот факт, что Алан Кей считает LISP «главной идеей в Computer Science», тогда как большинство преподавателей в вузах если и слышали это название, то ничего не понимают в функциональном программировании. И уж совершенно точно в вузах студенты не слышат ни слова про SOLID, про то, что наследование — очень опасная штука и её нужно использовать очень осторожно (о чём написано даже в «банде четырёх»). Там, блин, задают домашние задания на придумывание идиотских иерархий классов. Даже полиморфизм они зачастую неспособны объяснить без наследования.

Когда-то я жалел, что не закончил вуз по программистской специальности. Сейчас — не жалею. Я закончил лингвистический класс гимназии и (спасибо Наталье Михайловне) знаю английский достаточно хорошо, чтобы слушать и читать Роберта Мартина, Мартина Фаулера и пр. в оригинале, а не преподавателей российских вузов, многие из которых вообще ни разу в жизни не занимались профессиональным программированием и переписывают друг у друга из учебников и методичек одну и ту же ересь десятилетиями.
Меня вообще не учили ООП, программированию меня учили в рамках базового первого курса, чисто решение расчетных задач, циклы, интерполяция, интегрирование. Я по образованию инженер конструктор ядерных реакторов, поэтому не могу иметь притензии к своему ВУЗу. ООП я изучал сам, разрабатывая нативные компоненты к Delphi, в качестве источника данных был пользовательсткий мануал на английском языке. Можт я что то там не так понял, но если обратится к английской википедии, то они так же начинают определение ООП, как объединение данных и методов их обработки, а значит не такая уж это ересь, по мнению большинства англоязычных пользователей wi-ki:
Object-oriented programming (OOP) is a programming paradigm based on the concept of «objects», which can contain data, in the form of fields (often known as attributes), and code, in the form of procedures (often known as methods). A feature of objects is an object's procedures that can access and often modify the data fields of the object with which they are associated (objects have a notion of «this» or «self»). In OOP, computer programs are designed by making them out of objects that interact with one another.[1][2] OOP languages are diverse, but the most popular ones are class-based, meaning that objects are instances of classes, which also determine their types.
en.wikipedia.org/wiki/Object-oriented_programming
Главное чтобы работало. Но ООП очень большая тема, чтобы её можно было раскрыть в рамках мануала, это одна из трёх главных парадигм программирования на данный момент и было написано уже штук 10 книг, которые можно назвать классическими, притом развитие не стоит на месте, те же принципы SOLID были предложены в начале 2000-х. Да, это просто формальное проговаривание лучших практик уже сложившихся к тому времени, но до этого проговаривания большинство им не следовало (боюсь, сейчас ситуация не сильно поменялась) и в большинстве материалов они не были изложены.

инкапсуляция, наследование, полиморфизм – это не про ООП

Это общие понятия актуальные для всех парадигм ЯП, "приватизированные" ООП

Пример определения из ООП
Инкапсуляция – это свойство системы, позволяющее объединить данные и методы, работающие с ними, в классе и скрыть детали реализации от пользователя.
Когда я ставлю на схему блок, в примере КД, я как раз получаю классический пример инкапсуляции. Пользователь указывает сигнал с какого датчика он хочет получить в миливольтах, и задает параметры для пересчета и получает значения в единицах измерения, например в град Цельсия.
Классическое из ООП объединение данных и методов их обработки.
Спасибо за статью — очень интересно.

Но с точки зрения всех, кто впервые сталкивался эти этим абстракциями, после классических процедурных языков понятнее не становилось, кажется наоборот все еще больше запутывалось.
Тут похоже опечатка. Но по сути ИМХО от процедурного Паскаля перйти к ОО Паскалю Delphi ( упомянутому в статье) очень просто даже на формальном уровне.

Простейшая инкапсуляция уже есть в записях (record). Далее понятие о наследовании приходит в таких простых примерах:
type
TCoord = record // координаты точки
                    x, y : integer
                  end;
TRect = record // прямоугольник
                     leftTop, RBot : TCoord;
               end;


Остается заменить слово «record» на слово «class» (с указанием имени предка в скобках), разрешить записывать заголовки методов внутри таких «записей» и оговорить несложные правила полиморфизма классов.

только чистый Си, и еще желательно урезанный правилами и рекомендация MISRA C, чтобы все было надёжно, переносимо, безопасно.
Тут мне видится историческая несправедливость и непоследовательность. Еще во времена виртовского Паскаля критики указывали на слишком сильную (по их мнению) типизацию, отмечая, что Си — гораздо более гибкий язык. Следовательно на Си возможно больше трюков и, как оборотная сторона монеты, больше ошибок, более трудная читаемость исходного кода. Паскаль был сделан для обучения, Си — для разработки. Логичнее было выбрать для АЭС Паскаль, как потенциально более простой и надежный.
Мне тоже типизированный Паскаль нравится больше.
Но с Си на контроллерах управления, мне кажется это исторически сложилась такая практика, контроллеры более слабые, чем десктопные процессоры, поэтому гибкость Си позволяла реализовать «всякие трюки», а потом в критических системах это осталось, типа работает — не трогай. Вчера сделали на Си работало значит и сегодня будем продолжать тоже.
Со времен PDP-11 (а м.б. раньше) в Паскале был один супертрюк, который для любой самой глупой железки позволял записать любую инструкцию — встроенный ассемблер :) И со времен PDP-11 (и управляющих различной аппаратурой LSI-11) этот подход себя зарекомендовал: программа была написана в основном на Паскале, и только небольшие куски на ассемблере. ИМХО это надежнее, т.к. наглядно видно какие регистры для чего использованы, какие вектора прерываний и т.д.
В стандарте MЭК 60880 «Атомные станции. Системы контроля и управления, важные для безопасности. Программное обеспечение компьютерных систем, выполняющих функции категории А». Используется понятие
Проблемно-ориентированный язык (application oriented language): компьютерный язык, специально разработанный для определенного типа применений и используемый лицами, являющимися специалистами в данном типе применений. [МЭК 62138, 3.3]
В этом же стандарте есть понятие
Автоматизированная генерация кода (automated code generation): функция автоматизированных инструментов, позволяющая преобразовывать проблемно-ориентированный язык в форму, пригодную для компиляции или выполнения.
Таким образом схему графического языка SimInTech вполне можно рассматривать как программу на проблемно ориентированном языке. (графическом языке программирования)
Со стандартом не поспорить :) Раз так написано — так тому и быть.
Тут дело в том, что схему алгоритма можно запустить на исполнение без генерации года Си. Графический язык SimInTech может выполнять расчеты, сам по себе. А IDE Delphi все переводит в ОО Паскаль, а потом только компилирует и выполняет. Как то так.
И еще, в IDE Delphi функции все таки нужно писать на Паскале. А в графическом языке — не надо, можно все нарисовать.
Логичнее было выбрать для АЭС Паскаль, как потенциально более простой и надежный.

Не для АЭС, но для автоматизации производственных процессов так и сделали. Для программирования ПЛК часто используют ST (IEC 61313-3), который очень похож на Паскаль.
Но при этом этот же ST компилируется перед выполнением и возможно одной из промежуточных форм опять таки является Си.

Из приведенной схемы управления SimInTech, можно сгенерировать и ST. ООП в графическом языке SimInTech, а код сгенерируем ST.

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

Вот программист и думает в виде расчетных схемы SimInTech и объектов проекта. Хотя в случае АЭС это даже не програмист, а технолог. А программист вообще не нужен.

Вот, например, реальное описание в графической нотации алгоритма управления задвижками АЭС.:

Вячеслав, могу ли я попросить Вас подсказать, это что за стандарт описания алгоритмов? Или это своя росатомовская документация?

Это по сути внутренний стнадрат предприятий росатома, причем не всех. В основу, как я понимаю, взяты принципы из немецких гет-планов, в совое время Siemens продал свою старую технологию ВНИИА им. Духова, там были гет-станции специальные компьютеры, геде изображелись листы алгоритмов, слева вход справа выход между ними логика работы. Дале все это в рамке, с нумерацией листов подписями систем, и система кодирования ККS для имен сигналов. Получается такой вот документ, который все в росатоме понимают.

А может подскажете, как в серьёзной инженерной среде документируют ПО для ПЛК?

кроме как KKS (там всё по-немецки).

Или в большинстве случаев это просто текстовое описание?

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

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

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

Ну а конченый изготовитель всю эту радость рисует уже в среде разработки.

Если SimInTech использовать как например в кооперации для некоторых морских объектов, там от проектната до заливки в контроллер между организациями все в виде диаграмм алгоритмов SimInTech

Sign up to leave a comment.

Articles