Как я могу представить блок try catch с SQLException throw на диаграмме последовательности UML?

Я изо всех сил пытаюсь понять, как я могу представить следующий код диаграммой последовательности UML:

Что у меня уже есть:

Изображение моей диаграммы последовательности UML

Java-код:

public static Connection getDbConnection() throws SQLException{
if (instanceOfDbConnect == null) {
        instanceOfDbConnect = new DbConnection();
        System.out.println(" Connection  - - - - - - - -  Trying to create DBConnection.");
    }
    try {
        return DriverManager.getConnection(URL,user,password);
    } catch (SQLException e) {
        throw e;
    }

}

Как я могу справиться с этим выбрасыванием SQLException, если это делается таким образом? Мне кажется, что я должен получить ответное сообщение (throw e) от SQLException до DbConnection. Но что такое сообщение отправителя от DbConnection до SQLException?

Большое спасибо за вашу помощь!


java jdbc uml sequence-diagram visual-paradigm
person Banik    schedule 21.05.2019    source источник
comment
Я думаю, что если вы пытаетесь представить свой проект с таким уровнем детализации в UML, то вы, вероятно, тратите впустую свое время и время своего начальства. UML — это инструмент проектирования высокого уровня. Но это кодирование, а не дизайн. Сам код является гораздо лучшим представлением... для всех, кому нужно понять, что он делает/должен делать.   -  person Stephen C    schedule 21.05.2019
comment
@StephenC Я не согласен с вами, UML не ограничивается высокоуровневым дизайном (вероятно, я хорошо знаю, что распространение инструмента UML, создающего исходный код ;-))   -  person bruno    schedule 21.05.2019
comment
ХОРОШО. На самом деле я был косвенно вовлечен в метамоделирование UML OMG еще в конце 1990-х. Я чертовски уверен, что дизайнеры никогда не собирались использовать UML для подобных вещей. Теперь ясно, что вы можете сделать это... точно так же, как вы можете использовать кувалду, чтобы расколоть арахис... положим, это не делает это продуктивным использованием вашего времени как программиста.   -  person Stephen C    schedule 21.05.2019
comment
Ты почти сделал это. Думайте об исключениях как об alt фрагменте. Как было сказано выше: используйте UML там, где он хорош, и не увлекайтесь графическим программированием.   -  person qwerty_so    schedule 21.05.2019

Ответы (1)


arrow_upward
2
arrow_downward

Как уже отмечалось, UML не лучший вариант, когда речь идет о реальном коде. Ваши восемь строк кода (не считая одной закрывающей скобки) очень понятны. Попытка нарисовать это как SD могла бы выглядеть

введите здесь описание изображения

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

Теперь рассмотрим этот пример: введите здесь описание изображения

Здесь поведение сохраняется в примечаниях к сообщениям (используя Enterprise Architect). Вместо этого можно использовать элемент примечания и разместить его на диаграмме.

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

person qwerty_so    schedule 22.05.2019