IBM Rhapsody или «бумага и карандаш»?

Question

My Background: Менеджер программ навигационных систем

Проект: разработка навигационного устройства, которое также может загружать приложения, например, iPhone. Итак, представьте себе что-то вроде TomTom или Garmin, но также возможность подключения к Wi-Fi и возможность запуска приложений. В настоящее время используется Rhapsody для GUI и поток конечных машин. Обсуждаем его использование для разработки приложений.

Вопрос: Я не программист, поэтому я искал термины непрофессионала, преимущества и недостатки использования Rhapsody для не-GUI-интенсивных подобных функций. Мое личное чувство заключается в том, что использование Rhapsody для определения простого приложения, например, отображение «Amber Alert App», легко определяется и описывается только листом бумаги. Попытка смоделировать этот вид приложения в инструменте Rhapsody была бы пустой тратой времени. Смысл, я могу написать, просмотреть его, внести изменения, все в Word и Visio, до того, как я мог бы даже запустить его в Rhapsody.

Согласны или не согласны? Преимущества недостатки? (Опять же, ища ответ непрофессионала.)

1. Следует ли использовать рапсодию для всего, что в этом проекте? Зачем? Или использует Rhapsody для небольших задач, например, используя бензопилу для обрезки кустарника?
2. Использует Rhapsody для получения дополнительных ресурсов и времени для реализации, особенно если у нас есть небольшое количество людей, которые знают, как их использовать и читать?
3. Другие комментарии?

Answer 1

Мой опыт: полномасштабная разработка критически важного программного обеспечения для авионики с использованием Rhapsody. У нас были взлеты и падения с помощью этого инструмента. Я думаю, что преимущества и недостатки могут различаться в зависимости от того, как разработчики привыкли к инструменту.

Ниже приведены мои впечатления.

Мои достоинства: Управление конфигурацией моделей Rhapsody, содержащих введенный вручную код. Частые исправления и/или дополнения к модели всегда синхронизируются с кодом и наоборот. Созданные документы синхронизируются с созданным кодом.

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

Мой вывод: Этот инструмент хорош для официальных проектов со всеми видами поставляемых документов и артефактов. Этот инструмент хорош для продуктов длительного срока службы, которые требуют много лет для разработки и обслуживания.

Answer 2

зависит от цели. Если ваши разработчики имеют опыт использования Rhapsody, так же быстро сделать диаграммы в Rhapsody, как в Visio/Word, с добавленным бонусом вы можете получить из них какой-то код. Если у вас нет опыта с Rhapsody, это займет больше времени ... Это также зависит от того, что вы будете делать с диаграммами позже. Являются ли диаграммы только для разработки этого приложения, а затем выбрасывают его, или вы хотите сохранить их для целей документации позже? Если вы хотите сохранить их, сделайте их в Rhapsody, у вас будет гораздо больше шансов сохранить их в курсе.

Answer 3

Возможно, вы можете протестировать Rhapsody с помощью оценочной лицензии (которую легко получить при загрузке с сайта IBM), или же вы можете использовать бесплатный Rational Modeler http://www-01.ibm.com/software/awdtools/modeler/, который имеет ту же концепцию, что и Rhapsody, с ограниченными возможностями, конечно. Это может быть хорошей альтернативой бумаге и карандашу.

Answer 4

Мой опыт:

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

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

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

Answer 5

Мой опыт работы с Rhapsody был разочаровывающим. Я нахожу это неуклюжим и неудобным для навигации, и, похоже, он создает свиную посуду. После 25 лет программирования на C/C++ я обнаружил, что базовый дизайн является общим элементом для определения успеха или неудачи. Rhapsody или любой другой инструмент UML не улучшают дизайн; вы можете создать kludge в UML так же легко, как можете, на любом другом языке. Точно так же вы можете создавать хорошие проекты на любом языке с таким же количеством предусмотрительности. Учитывая это, почему я хочу добавить еще один сложный слой в свой дизайн? Особенно тот, который имеет столько причуд, сколько Rhapsody.

Answer 6

Мой опыт: 6.5 лет Встроенные проекты программного обеспечения на С ++.

Преимущество:

• UML разработка на основе (это не очень стабильно, хотя.)
• Statecharts (не очень стабильно ни [не имеют некоторые ошибки в старых версиях, не тестировали последнюю версию]), объектную модель Диаграммы или некоторые другие диаграммы UML
• Переименование, перемещение компонента так же просто, как и перетаскивание.

Недостатки:

• Обучение это больно! Это почти требует завершения другого бакалавра в соответствующем отделе.
• Это абстрагирует разработчика от реализации реального кода. Заставляет вас забыть синтаксис языка.
• Выполнение повседневной вещи может быть легким, но попытка чего-то нового заставит вас убить себя.
• Обратная совместимость в новых версиях не работает.
• Кодирование не очень просто. Завершение кода существует, но это похоже на демоверсию.
• Контроль версий работает с IBM ClearCase безупречно. Не могу сказать то же самое для SVN или другого инструмента.
• Он поставляет «UML-порты» для связи между компонентами. Это обеспечивает безопасность, но испортит код. Вызывает слишком большие исходные коды, что также приводит к медленному выполнению и мучительному эксперименту по отладке. Мы должны были заменить порты регулярными указателями, чтобы ускорить и наблюдали повышение% 50 в одном из наших проектов.
• Вы платите за это!
• Иногда для создания простой строки кода C++ требуется несколько часов. Вы должны найти правильный путь Рапсодии!
• Это не просто редактор, он создает/генерирует код. Это означает, что вы можете попытаться решить проблему, вызванную Rhapsody; или потому, что вы еще не освоили его!

Подводя итог: Я твердо верю, что кодирование «Бумага и карандаш» делает меня лучше кодера/дизайнера.