Здравствуйте господа.

Озадачился вопросом ведения сложных проектов после прочтения ряда статей.
1) Верно ли я понял то что методики и технологии предоставляемые програмным продуктом IBM Telelogic Rhapsody являются идеалом в данном вопросе?
2) Есть ли аналоги (не просто UML редакторы), а аналоги в широком смысле этого слова?
3) Используете ли вы данное ПО или аналогичное или весь алгоритм по старинке в головах программистов и на "солфетках", а абстрактное обобщение всего проекта в текстовом виде?

Окончательным гвоздём к переосмыслению ведения проектов стала статья Татарчевского Владимира "Некоторые мысли по поводу программирования встроенных систем" в журнале "Компоненты и технологии №8'2006" где все реалии с которыми сталкивается разработчик описаны в простой доступной форме.

Графические языки помогают на первом этапе начинающим программистам. Для разработки коротких программ.
Для профессиональных программистов графика как представление программы абсолютно неприемлема. ИМХО
Ее можно использовать если только дальше предвидится моделирование.
А так, во первых получается двойная работа, во вторых графика совсем не так понятна когда она разрастается на десятки листов.
Все хают оператор GOTO потому что он текст программ превращает в лапшу. Графика же является лапшой по природе.
Она сносно смотрится только когда занимает один экран.
Наглядно можно помучится с графикой например в Simulink-е. После того как обнаружите десять уровней вхождения подсистем, разбираться с той графикой отпадет всякая охота.

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

У большинства методов где используется UML и графика в основе лежит метод проектирования системы на основе КА.
Именно упор идёт на "графику" которая называется диаграмма состояний. Начинающие программисты рисуют ромбики прямоугольники и т.д. грубо говоря последовательность действий - алгоритм в пределах одной функции. Диаграммой состояний можно описать работу всего устройства, и уместить на один лист, что в той или иной степени позволяет абстрактно взглянуть на всю систему.

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

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

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

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


Посмотрю обязательно, спасибо.



На подзадачи, наверное всегда приходится разбивать, и обмен преимущественно по событиям. Но лично у меня нет чёткого представления как это всё одназначно и чётко проектировать до программирования, в рамках какого то стандарта.
Я пытаюсь увидеть, можно ли любую подзадачу выразить как отдельный КА(или совокупность КА) и описать её на этапе проектирования в виде UML моделей, с описанием интерфейсов.
Пока к сожалению всегда проектирование программы(отдельного алгоритма) сводится к бумажным рисованиям, где нужно таблицам, пометкам и т.д. но повторюсь, хочется проектировать заранее, стандартно и чтобы с любой информацией касаемой программы(отдельного алгоритма) было удобно работать в будущем другим проектировщикам, программистам, тестировщикам.

Судя по описаниям программа от IBM позволяет перевести уровень разработки на новый уровень, не зря ведь она стоит как небольшой самолёт.. уверен в ней собраны лучшие идеи, и большая часть велосипедов в ней создана.


В первом вашем комментарии вы писали:

Нашёл в одном из последующих номеров журнала статью(ответ на письмо) см шестой абзац (копирование запрещено с сайта). Там автор говорит про две недели и 40 страниц А4 диаграмм, для проекта, правда уровень сложности не указан. Но замечу что раскрывается вопрос исправления ошибки, в рамках которой удалось её и ряд других устранить за неделю после составления проектной документации, думаю этот факт важен.

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

Бывают случаи когда действительно заказчик ломится все показать на диаграммах. Но это будут диаграммы сценариев использования (вроде use case) и с собственной доморощенной нотацией. Тоже никакого отношения к UML.

Были еще заказчики которые знали графическую нотацию определенного класса логических контроллеров. Например Logo от Simensa или Alpha от Mitsubishi. Они представляли такие графические диаграммы и утверждали что это и есть программа. Тож не UML, как понимаете.

UML хорош для формализации отношений между равнозначными профессионалами. И может быть для моделирования на системном уровне.
В мелких встраиваемых проектах и некритичных для безопасности людей ни то ни то не нужно.

Есть, если чуть шире посмотреть
- язык "Дракон"
- программа qp в качестве примера к подходу Миро Самека (Miro Samek. Practical statecharts in C/C++)
- understand C/C++ - для реверса
- Crystal Flow - визуализатор, странно, что подобных опенсорс до сих пор нету.

Однако, я так понял, UML годится больше всего для постановки задач, не только для начинающих программистов. Когда собирается команда "непрограммирующих профессионалов" ©.

Думаете нет? Может sourceforge.net "пошерстить" по данному предмету. Дракон только и пиарится авторами на выделенном подфоруме http://forum.oberoncore.ru
Проблема думаю немного шире - в осмыслении эффективного пользовательского интерфейса при создании подобных средств
и undersand C/C++ уверен выведет кучу всевозможных диаграмм не выдав дополнительной семантической информации по дизайну функциональным решений
реализованных в диаграммах (так называемую мета информацию исходя на основе которой создавалось конкретное воплощённое решение)

P.S. Есть проект Thyrd эксперимента в озвученном вопросе, а насколько перспективен или нет и в какой степени предложенный подход
покажет время. Самому данная тема интересна, но понимания ещё не сложилось и пока видится что текстовый ввод пока наиболее эргономичен при создании прораммного кода.
И сказано было им, что придёте вы к плиточным графическим интерфейсам или накрайняк табличным

.

У меня такая хотелка сложилась: чтобы IDE могла одновременно визуализировать с добавлением специфической информации вручную (тут ничего сложного - транслируется в текст как комментарии).
Т.е. text<->UML<->Statechart<->Data relations
Подобное уже давно живет в SCADA системах где переход LD->ST->FBD одним кликом не считается чудом.

даже проходил курс по UML/Rhapsody, был недешев, теперь к реальностям:
- UML неплох но это не будет основой и костяком для всей и всех разработок
- тулзы есть и разные но сильно на них замарачиваться IMHO не стоит...

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

имеется в виду работать в Rhapsody, или работать без применения данных технологий?

Немного шире посмотрим на сабж.

IMHO технология и UML в целом,

проекты как правило более сложны, чем нам кажется вначале ...

полностью согласен.

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