Какую диаграмму и нотацию использовать для моделирования вызовов процедур?(Прочитано 53195 раз)
Здравствуйте!

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

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

Вопрос в том, какая диаграмма в UML больше всего подходит для отображения связей между методами программы, между методами объектов программы?



Диаграмма пакетов, но это не принципиально, можно и диаграмму объектов использовать.



как вариант, можно и диаграмму последовательности использовать
но надо будет указывать все объекты, из которых вызываются процедуры



Диаграмма пакетов, но это не принципиально, можно и диаграмму объектов использовать.

Допустим, надо на диаграмме изобразить что процедура1 вызывает процедуру2, а процедура2 вызывает процедуру3.

1. Если использовать диаграмму пакетов, то непонятно что в нее добавлять. Какими элементами на ней будут представлены процедура1, процедура2 и процедура3?

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



как вариант, можно и диаграмму последовательности использовать
но надо будет указывать все объекты, из которых вызываются процедуры

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



UML разрешает устанавливать ассоциации между двумя операциями, но т.к. нотации для отдельного изображения операции в диаграммах нет, то тут надо немного подумать.

Как вариант, используйте диаграмму активности. Изобразите операции как Action (точнее CallOperationAction) которые вызывают соответствующие операции и между ними уже установите зависимости.
Sparx EnterpriseArchitect поддерживает это с помощью drag&drop.

Для CallOperationAction в скобках указывается класс, операция которого вызывается, и возможно указать название операции, если название действия отлично от него.
« Последнее редактирование: 16 Ноября 2012, 23:14:50 от Artem Sovetnikov »



Изобразите операции как Action (точнее CallOperationAction) которые вызывают соответствующие операции и между ними уже установите зависимости.

А что такое CallOperationAction в переводе на русский?
Просто я UML изучал по книге Буча Г. "Язык UML. Руководство пользователя".



Я в принципе написал про это, CallOperationAction (понятие из спецификации UML) это такой Action, который вызывает операцию.

Надеюсь у вас второе издание этой книги, по UML 2.0?



Я в принципе написал про это, CallOperationAction (понятие из спецификации UML) это такой Action, который вызывает операцию.
Надеюсь у вас второе издание этой книги, по UML 2.0?

да, второе издание,
только в нем все называется по-русски,
какой перевод в этой книге соответствует CallOperationAction?



Диаграмма активности, на ней Action - это Действие



Вам шашечки или ехать?

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

Нарисуйте на доске фломастером, сфотографируйте, фотку положите в репозиторий, при изменении перерисуйте.

Если кровь из носу нужно изменить существующую UML-модель программы — задайте этот вопрос автору UML-модели.



Все зависит от инструмента, которым вы пользуетесь.
Можно вытащить эту зависимость просто запросами.
Построить матрицу зависимостей
В конце концов сделайте, то что предлагают участники дискуссии.
Следуйте принципу KISS
« Последнее редактирование: 17 Ноября 2012, 13:32:45 от Galogen »



Вам шашечки или ехать?

Всё, что вам нужно — это набор прямоугольников со вписанными туда названиями методов и связи между прямоугольниками, показывающими направление вызовов.
Конечно, для решения моей конкретной задачи, просто набор прямоугольников подойдет.
Но ведь модель создается при помощи определенной стандартной нотации, чтобы ее могли прочитать другие.
И мне хотелось бы, чтобы составленную мной диаграмму могли читать другие программисты, чтобы я ее мог показать им, и обсудить предлагаемое мной решение.

Нарисуйте на доске фломастером, сфотографируйте, фотку положите в репозиторий, при изменении перерисуйте.

Если кровь из носу нужно изменить существующую UML-модель программы — задайте этот вопрос автору UML-модели.
Пока речь идет не об изменении, а о дополнении.
Т.е. хочу добавить в модель диаграмму вызовов процедур



Все зависит от инструмента, которым вы пользуетесь.
Пользуюсь Power Desinger
Можно вытащить эту зависимость просто запросами.
Не понял, что значит "вытащить эту зависимость просто запросами"?
В конце концов сделайте, то что предлагают участники дискуссии.
Просто квадратики я уже нарисовал.
Но, я повторюсь, основной вопрос у меня - это знание языка моделирования UML, признанного как наиболее удобного языка моделирования.
Ведь, такая же задача у меня может возникнуть еще не раз.
И мне хотелось бы знать, как правильно на UML изображать зависимости между процедурами.
Следуйте принципу KISS
Для примера, прежде чем пекаря допустят в пекарный цех, чтобы спечь батон, пекарь должен три года учиться в кондитерском училище.
Поэтому, я желаю изучить тонкости UML
Я думаю, что это пригодится



Диаграмма активности, на ней Action - это Действие
У меня в Power Desinger в диаграмме активности доступны следующие линии:
1) Flow на закладке "Activity Diagram"
2) Link \ Traceability link на закладке "Standart"

Flow как я понимаю по смыслу не подходит.
Наверное лучше использовать Link.

Как вы думаете?




 

Sitemap 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19