Существует ли формальный язык, который можно использовать для записи информации, представленной в диаграмме последовательности UML, в текстовый формат, понятный людям?
У нас часто требования к программному обеспечению указываются в виде сложных диаграмм последовательности, которые трудно просмотреть, проверить на правильность и внести изменения. Также ИМХО, программисты предпочли бы реализовывать из однозначного текстового представления требований, а не из растянутых многостраничных диаграмм.
(1) Да, существует проприетарный почти формальный язык текстового формата, способный выражать информацию в диаграммах последовательности UML, понятных программистам (и, возможно, некоторым другим людям).
Язык, который я имею в виду, был разработан и реализован Стивом Хановым, полный список примеров доступен по адресу https://www.websequencediagrams.com/examples.html, и я выделил один из примеров ниже, чтобы вы могли получить представление о читабельности:
(2) Но имейте в виду, что вы (или кто-то другой) можете писать плохой, нечитаемый код на любом языке (текстовом или графическом), и изменение языка не изменит автоматически вашу (или чью-то еще) привычку сделать код автоматически лучше, читабельнее, удобнее в сопровождении
(2.1) Запись однозначного текстового представления требований, например. в виде вариантов использования, одобренных клиентом, — это непростая в использовании и непростая в освоении вещь, и простое изменение языка не сильно улучшит ее. (см., например, Переполнение стека: от пользовательских историй к диаграмме последовательности, чтобы узнать больше )
(2.2) целевая аудитория (читатели) диаграмм последовательности UML — это не только программисты, но и менее технические заинтересованные лица, для которых изображение может стоить тысячи слов . На мой взгляд, предоставление программистам псевдокода Java, который при необходимости можно даже преобразовать в диаграмму последовательности UML с помощью инструмента (см. sequence-diagram-from-java-source-code">Переполнение стека: как сгенерировать диаграмму последовательности из исходного кода Java или Google: диаграмма последовательности java для получения дополнительных указателей) лучше, чем пытаться найти/изобрести последовательность -специфический для диаграмм язык
(2.3) безусловно, существуют инструменты, помогающие читать большие макеты UML с помощью таких приемов, как масштабирование, гиперссылки, свертывание/развертывание блоков, настройка отображаемого уровня детализации, а также размеры бумаги, такие как A3 или A2, который может превратить обычную многостраничную диаграмму в одностраничную.
Судя по вашему описанию, у вас процессная проблема, и вам лучше задать вопрос по адресу https://softwareengineering.stackexchange.com/help/on-topic
На какие темы я могу здесь спросить?
Programmers Stack Exchange – это сайт вопросов и ответов для профессионалов и студентов, занимающихся разработкой программного обеспечения и смежных областях, которые заинтересованы в получении экспертных ответов на концептуальные вопросы о разработке программного обеспечения.
Если у вас есть вопрос о...
- требования к программному обеспечению
- архитектура и дизайн программного обеспечения
- ...
- методологии и процессы разработки
- управление программной инженерией
- ...
Подход xmojmr — это эффективный способ документирования сценариев использования, и если ваши диаграммы последовательности сбивают с толку, это, вероятно, потому, что они недостаточно документированы. Как говорит xmojmr, картинка стоит тысячи слов, но иногда несколько сотен слов действительно помогают объяснить картинку! Я хотел бы поделиться небольшой информацией, которая может быть вам полезна.
Я рассматриваю процесс описания требований как имеющий три уровня, из которых сценарии использования являются третьими. Верхний уровень представляет собой диаграмму вариантов использования, которая показывает, как взаимодействуют различные варианты использования в системе и заинтересованные стороны, использующие систему. Следующий уровень — это детали каждого из этих вариантов использования. Для этого я использую «повествование о прецедентах». Третий уровень — это каждый отдельный путь («сценарий варианта использования») через вариант использования.
Существует много путаницы между вторым и третьим уровнями. Частично это связано с тем, что в некоторой степени они работают вместе, например, разумно анализировать связанные пути успеха и неудачи в сценарии использования как один сценарий, а не два. По крайней мере, я предпочитаю рассматривать их как один сценарий.
Я предпочитаю использовать диаграммы деятельности для документирования нарративов вариантов использования. Хотя с диаграммой последовательности можно делать практически все что угодно (по крайней мере, в версии 2.0), дивергентное поведение, деревья решений и параллельное поведение IMO более очевидны на диаграммах действий, чем на диаграммах последовательности. Таким образом, одна диаграмма действий для каждого варианта использования, а затем одна диаграмма последовательности для каждого отдельного сценария в варианте использования.
В вашем процессе похоже, что диаграммы последовательности не сопровождаются формальной документацией по сценариям использования. Если вы погуглите «сценарий использования», вы найдете ряд таких примеров. Однако имейте в виду, что многие примеры на самом деле документируют то, что я называю «рассказами».
Я использую терминологию из книги Тома Пендера Библия UML (Wiley Publishing, 2003). Еще одна замечательная книга — Writing Effective Use Cases Алистера Кокберна: здесь образец хорошего размера.
другой онлайн-инструмент преобразования текста в диаграммы, использующий аналогичный синтаксис. http://echoma.github.io/text_sequence_diagram/
