[syoma 1]

Привет.

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

Я говорю, что косяки они таким образом не исправят - если нет культуры менеджмента требований, она от SysML не появится. Но то такое.

Собственно вопрос - есть примеры успешного внедрения SysML при проектировании сложных встраиваемых систем? Причем не просто "Да, мы применяем", а именно интересно увидеть реальную и живую модель, которая действительно используется в цикле разработки. Вроде же весь смысл в том, что такая модель должна быть наглядна и понятна почти любому неподготовленному человеку. Хотелось бы увидеть, что она собой представляет и узнать о реальных впечатлениях от того, кто такое внедрил - сколько человеко-месяцев стоило, сколько теперь экономит? Уменьшает ли количество ошибок и, следовательно, итераций при проектировании?

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

ПС Вот сижу и думаю, стоит начинать учить, или ну его нафиг и на наш век хватит новшеств.

Спасибо.

 

[yes 5]

я поговорить зашел, для улучшения своего понимания :), ответа не знаю

а какой смысл в этих описаниях, если нет инструмента для генерации кода (как для софта, насколько я понимаю)? кажется, что подобной работой занимаются во ФГУПах, когда перерисовывают схемы из ПАДСа в автокаде, чтоб красивше было.

то есть между этой документацией и реальным проектом будет разрыв - соответствие в документации будет опираться на добросовестность исполнителей (как в примере с ФГУПом, на тетенек, которые это перерисовывают без малейшего понимания смысла) и внесение изменений (backannotate) в доку тоже потребует усилий

а, собственно, результатом внедрения будет замена картинок в визио (если они есть) на описание UML (тул, который сгенерит картинку, наверно не нужен с особой заточкой под электронику). вот у меня есть коллеги, которые только ТЕХ юзают и вообще продвинутые (были и генерация доки из HDL и HDL из док своими парсерами/трансляторами, но не прижилось), но картики рисуют в визио. ну, то есть, какой-то инструмент для передачи "идеи" от теоретиков к имплементаторам может быть формализован, но чем SysML лучше визио - мне не понятно.

а MSBE - я понимаю так - теоретики пишут на С++ или даже на SystemC (совсем слабенькие на Matlab-e или питоне), а имплементаторы растакивают модель по кускам, что-то для HDL, что-то для embedded (выкидывание малоков :) ) . Без этого нельзя в большинстве задач. Ну то есть где есть какая-та непонятность и требуется модель... Опять же, модели можно натравлять на реальные данные и получить большую "обзираемость процесса", чем корячится с осциллографами и жтагами...

вобщем мое мнение: да-да-нет-да :)

[syoma 1]

Лично что я понял из презентации, что мне показали - это то, что SysML позволяет отойти от описания требований в виде текста, т.е. "Система должна обеспечивать управление самолетом одной рукой" или Visio. А вместо этого, где нужно, требования можно представить в виде автомата состояний, или событий (клиент отсылает запрос на сервер, сервер отвечает через 5мс) или Use Case (пользователь хочет сделать то-то) и еще 7-ю способами. Вроде удобно - используешь тот инструмент, который подходит в данном случае. Ну и еще возможность связи требований, но тут я вообще не понял, как при этом отследить все это дело на корректность и наполненность.

Вот поэтому и ищу примеры - чтобы на пальцах показали, как оно в реальности работает и работает ли. Вот в интернете даже есть модель космического корабля (HTML версия тут) сделанного в SysML. Да вот только реально полетит ли такой корабль, спроектированный таким образом? NASA же предпочитает работать по старинке, скормив поставщикам 300-страничный документ с требованиями. И вот летают же?

Разрыв между документацией и проектом, конечно же будет - так как SysML это не решает. И мало того, я не вижу здесь возможностей для гибкой методологии разработки(Agile). Т.е. придется ждать сперва пока полностью не сделается модель и только потом приступать к разработке.  В общем для меня пока загадка, зачем нужен еще один костыль. В Domain-Specific многие из этих проблем снимает тот-же Matlab/Simulink + кодогенерация + тесты. Вот уж действительно полезная штука - и требования и проект генерятся из одной модели, почти 100%-ное соответствие документации проекту и отслеживание. А тут какая-то фигня.

[yes 5]

про UML - может я ошибаюсь, но ввод и работа с этим "языком" подразумевает некие графические редакторы. внутренний формат представления XML, такой же как использует Visio (то есть нечитаемый человеком)  (???)

есть тулзы типа graphitz или planttext, которые позволяют сгенерить картинку из текстового описания, но они не в мейнстриме

то есть, если язык не java или С++ для которых есть тулзы, которые генерят из исходников UML и из UML исходники - никаких преимуществ перед Visio не вижу. там можно точно так же рисовать иерархические картинки с переходами по клику и т.д.

но во что это разовьется, пока не утихла business modeling активити вокруг UML - прогнозов не дам :) вот в 200х мне казалось, что SystemC очень перспективное решение, а сейчас один System Verilog остался...

 

upd : космокорабль по ссылке очень похож на рекламу Magic Draw. а с разработкой на UML мне непонятно, как верифицировать работоспособность модели? то есть на чем ее симулировать или прогонять статическую/формальную верификацию? как я понимаю, в UML нет каких либо требований на целостность - просто картинки

 

upd2: вспомнилось, что с VHDL была такая же (?) фигня - в 1980 он был придуман для документирования - то есть формализованное описание микросхем для чтения людьми. а первый синтез с VHDL Синопсис предложил во второй половине 199х, то есть 15+ лет VHDL имел смысл только как описание, без каких либо инструментов. с симуляцией по-моему еще хуже - Каденс верилог симулятор в конце 90-х выпустила, раньше, но тоже ранние 90-е, VHDL, наверно, еще позже начали симулировать

[alxkon 0]

20 hours ago, syoma said:

Привет.

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

Я говорю, что косяки они таким образом не исправят - если нет культуры менеджмента требований, она от SysML не появится. Но то такое.

Собственно вопрос - есть примеры успешного внедрения SysML при проектировании сложных встраиваемых систем? Причем не просто "Да, мы применяем", а именно интересно увидеть реальную и живую модель, которая действительно используется в цикле разработки. Вроде же весь смысл в том, что такая модель должна быть наглядна и понятна почти любому неподготовленному человеку. Хотелось бы увидеть, что она собой представляет и узнать о реальных впечатлениях от того, кто такое внедрил - сколько человеко-месяцев стоило, сколько теперь экономит? Уменьшает ли количество ошибок и, следовательно, итераций при проектировании?

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

ПС Вот сижу и думаю, стоит начинать учить, или ну его нафиг и на наш век хватит новшеств.

Спасибо.

 

Посмотрите это https://www.polarsys.org/

Мне раньше хотелось чего-то типа SysML для улучения качества документации.....

Лично мое мнение, в небольшой организации это сродни поиску философского камня, веры в silver bullet и толчению воды в ступе. Где не приходилось работать, отделы разработки 10- 50 человек, были попытки ввести UML,  SysML и другие методологии. И везде эпик фейл - "слишком вы далеки от народа". Нет надежной обратной связи, etc.

Единственно дельный совет я получил когда-то давно от приятеля: используй отдельные диаграмы UML для визуализации сложных вещей и не пытайся влезть во все эти модели и Энтерпрайз Архитекты, всеравно это ничем не закончится.

В нашем районе Вы уже не встретите этих дедушкиных обычаев и обрядов. Может где-нибудь высоко в горах Вы что-нибудь обнаружите для науки. (c)

 

[AlexandrY 2]

46 minutes ago, alxkon said:

Единственно дельный совет я получил когда-то давно от приятеля: используй отдельные диаграмы UML для визуализации сложных вещей и не пытайся влезть во все эти модели и Энтерпрайз Архитекты, всеравно это ничем не закончится.

В нашем районе Вы уже не встретите этих дедушкиных обычаев и обрядов. Может где-нибудь высоко в горах Вы что-нибудь обнаружите для науки. (c)

Думается здесь проблема в непонимании термина модель. 
Вот кто объяснит на пальцах термин "моделирование требований" ?  
Что такое вообще требования, откуда они беруться и куда деваются? 

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

В последнее время мультидисциплинарные модели становится делать все проще. 
Скажем можно легко сделать модель в которой бы отрабатывались механические принципы, электромагнитные и  процессорная DSP обработка.
Того же робота. 
Но решаться такая модель будет очень долго на десктопном компе. 
Поэтому этот подход еще труден.   

Ждем увеличения мощности компов, и следим за развитием тулсов. 
     

[syoma 1]

52 minutes ago, AlexandrY said:

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

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

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

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

И в этом, возможно и есть непонимание.

[AlexandrY 2]

3 hours ago, syoma said:

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

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

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

И в этом, возможно и есть непонимание.

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

И тогда я думаю что неотъемлемое свойство модели - возможность ее наблюдения с разных точек зрения.  

Хорошие тулсы позволяют нам определять правила конвертации моделей из одного представления в другое.
Эт как линейные системы конвертировать из пространства состояний в  рациональную функцию называемую переходной характеристикой и обратно. 
Или как электрическую схему конвертировать в печатную плату.  Или как модель StateFlow конвертировать в C.

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

[yes 5]

а зачем и как появилось UML?

я так понимаю, что Страуструп со товарищи (точный список надо гуглить) в 80-е работали программистами и придумали С++, в 90-е они стали уже менежерами (тимлидами, архитекторами и т.п.) и столкнулись с проблемой: как объяснить тупым индусам-программистам, что они должны делать, чего от них хочет начальство?

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

------------------

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

 

[syoma 1]

44 minutes ago, yes said:

Страуструп со товарищи уже на пенсии, ничего нового не добавляется

Если это так, то тогда я нихера не вижу смысла в этой затее.

[AlexandrY 2]

19 minutes ago, yes said:

а зачем и как появилось UML?

я так понимаю, что Страуструп со товарищи (точный список надо гуглить) в 80-е работали программистами и придумали С++, в 90-е они стали уже менежерами (тимлидами, архитекторами и т.п.) и столкнулись с проблемой: как объяснить тупым индусам-программистам, что они должны делать, чего от них хочет начальство?

UML вырос не из ООП, а из диагамм состояний или конечных автоматов.
А потом UML пригрузили классами, хотя на мой взгляд это модули, ведь в UML нет диаграмм наследования и диаграмм полиморфизма там нет. 
Реляционные базы изначально на диаграммах отношений строились, без этих диаграмм ни одну базу не спроектируете.  
И это не рисунки для чайников. Плотность информации на диаграммах очень высокая и нотации диаграмм чайникам ни о чем не говорят. 
Главное свойство диаграмм - наглядная иерархичность и модульность, иерархичность представляется мне как способ редукции. 
Пока не начнешь строить диаграммы не получается увидеть иерархию и модульность.   
Т.е. диаграммы больше всего нужны самим разработчикам.
Просто разработчиков создающих архитектуры очень мало.  И архитектура не такая вещь которая сегодня одна, а завтра другая.
Поэтому разработчиков дамающих на тем как разрабатывать разные архитектуры еще меньше. 
Скажем в мелком embedded которое тут у нас в основном обсуждается архитектуры давно сложились и мало кто думает как их строить с нуля.   

[yes 5]

на всякий случай, я не упоминал ни ООП, ни чайников.

я говорил о малочисленных высокооплачиваемых профессионалах (Страуструп со товарищи) и многочисленных низкооплачиваемых профессионалах (индусы, эмигранты из СССР) и методе взаимодействия между ними.

в UML кстати есть еще тип сущностей "временные диаграммы" (upd еще протокольные взаимодействия - ну типа Алиса и Боб - тоже не видел в тулзах), то есть как раз таки эмбеддед - то есть изначально замышлялось охватить всю отрасль (видел это давно и в книжке - похоже, не прижилось). но в тулзах как раз таки ООП и диаграммы наследования автоматизированы, по крайней мере, я так это понимаю (upd: но мое понимание слабое и сильно обобщенное. обобщаю чиподельскую VMM, с которой знаком лучше, и которая однозначно нужна была для использования индусов в чиподелании)

 

[AlexandrY 2]

1 hour ago, yes said:

на всякий случай, я не упоминал ни ООП, ни чайников.

я говорил о малочисленных высокооплачиваемых профессионалах (Страуструп со товарищи) и многочисленных низкооплачиваемых профессионалах (индусы, эмигранты из СССР) и методе взаимодействия между ними.

в UML кстати есть еще тип сущностей "временные диаграммы" (upd еще протокольные взаимодействия - ну типа Алиса и Боб - тоже не видел в тулзах), то есть как раз таки эмбеддед - то есть изначально замышлялось охватить всю отрасль

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

Я пробовал использовать UML для объяснения сущностей заказчикам и коллегам. Вот тут действительно затык. Люди впадают в ступор. Нотация UML на самом деле абсолютно чужда обывателю и низкоквалифицированным программерам в том числе. 

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

[syoma 1]

50 minutes ago, AlexandrY said:

Нотация UML на самом деле абсолютно чужда обывателю и низкоквалифицированным программерам в том числе. 

Дык народ, поэтому я и спрашивал не о UML, а о SysML - попытки сделать этот язык более универсальным и понятным простому обывателю в виде инженера, который не программист вообще. То, что UML в софтверном мире более или менее популярен, и так понятно. 

[Skryppy 0]

Насчет SysML и MBSE  не знаю такие инструменты, но описание требований к модели + генерация очень похоже можно сделать и в матлабе. Недавно был на конференции по матлабу, там народ активно рекламировал матлаб как среду в которой можно связать требования + кодогенерацию. Не знаю как это работает на практике (лично я использую матлаб только для моделировая и генерации кода) , но советую посмотреть ролики на похожие темы, может все можно проще решить матлабом не изучая новые языки программирования. Вот примерные ссылки. https://exponenta.ru/products/system-models , https://www.youtube.com/watch?v=J88A35JEcHQ