Форум Сообщества Аналитиков

×


Просмотр сообщений

В этом разделе можно просмотреть все сообщения, сделанные этим пользователем.


Сообщения - Сергей()

Страницы: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 »
181
Создаю модель в PowerDesigner (object-oriented model).
На диаграмме верхнего уровня (Class Diagram) хочу нарисовать, что вся система состоит из нескольких подсистем.
Вроде бы все просто. В спецификации языка UML есть подсистемы.

Но в PowerDesigner-е значка для подсистемы не нашел :(

Помогите разобраться в чем дело?

182
Надо решить, что является предметом моделирования:
1) процесс выполнения программы - тогда поведенческая диаграмма (может и диаграмма состояний, но лучше - диаграмма деятельности, где вызов будет изображаться узлом вызова деятельности, или старая добрая блок-схема, где вызов будет обозначаться блоком вызова). Правда на таких диаграмме вам не нужны стрелки-переходы и все узлы и блоки, не связанные с вызовами (если не надо отображать условия, при которых происходит вызов или последовательность вызовов или что-нибудь еще);
2) структура программы (исходного текста) - тогда структурная диаграмма (см. ранее).

Предыдущее сообщение от div тоже об этом говорит.

Наверное, больше подходит - структура программы.
Тогда получается что для каждого отображаемого метода нужно сделать отдельный класс. А правильно ли это будет с точки зрения семантики UML?

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

Ну как же... я в теме объяснил свою задачу.
Может быть не очень точно. Тогда сформулирую задачу еще раз:

Нужно к UML-модели модифицируемой программы добавить новую диаграмму.
На этой диаграмме будет отображена интересующая нас процедура программы и ее связи с другими методами, которые ее вызывают.
Это нужно для изменения этой процедуры, чтобы учесть влияние этих изменений на методы, которые ее вызывают.
Затем для каждого метода, изображенного на диаграмме и связанного с изменяемой процедурой (прямо или опосредованно через другие методы), будет проводиться оценка: нужно ли  переделывать этот вызывающий метод в связи с изменением процедуры.
Диаграмма должна быть выполнена в стандарте UML.

184
В рамках стандарта UML это называется диаграммой объектов. Квадратики (прямоугольники) объекты одного суперкласса - "Метод" с двумя подклассами "Метод программы" и "Метод объекта". Линии - связи одной ассоциации. Стрелки - от вызывающего к вызываемому (вызывающий "знает", кого вызывает, а вызываемый не "знает", кто вызывает).
Диаграмма объектов отображает взаимосвязи между объектами в какой-то конкретный момент времени, как будто описываемая система "заморожена".
То есть мне нужно будет изобразить как один метод вызывает другой метод на временном срезе. Это не то что мне нужно.
Мне нужно отобразить вызов не в конкретный момент, а вообще возможность вызова одного метода другим, неважно в какой момент времени и при каких условиях.

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

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

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

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

187
Было бы отлично, если бы была возможность показать вызовы как ссылки в сети объектов, без указания того, когда вызов совершается. Просто сам факт вызова. Например, как на скриншоте показаны ссылки с одного объекта на другой.
Оставляю за собой право ошибаться в понимании задачи автора топика.

вы правильно поняли мою задачу

188
Тут такой вопрос: цель в том, чтобы продемонстрировать читателю диаграммы знание UML, или в том, чтобы читатель понял, как это должно работать?
Есть ли уверенность, что другие программисты владеют всеми тонкостями нотаций UML диаграмм? А то ведь можно все формально правильно нарисовать, но окажется, что важные нюансы ускользнули от читателей.
В любой области должны быть общие понятия, разделяемые всеми, чтобы иметь возможность понять друг друга, и общаться с друг другом.
Чтобы читатель понял что он читает, он прежде всего должен знать "язык" того, что он собирается читать.
Если вы хотите поговорить с англичанином вы должны знать английский.
UML наиболее распространенный язык для моделирования ПО.

У нас вот программисты слово UML терпеть не могут, говорят "Ты лучше по простому нарисуй и на пальцах объясни".
Язык "простого" у каждого свой.
И нарисовав "по-простому", такие программисты вряд ли друг друга поймут _однозначно_ и _правильно_.
Да, изучение UML - нелегкое дело.
А разве изучение C++ или Java или PHP проще? Если программисты осилили язык программирования, то UML для них - не проблема.
А в компетентности программистов, которые не хотят или не могут изучать UML, я бы усомнился

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Страницы: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 »