Форум Сообщества Аналитиков
Общий раздел => ПО Аналитика => Тема начата: Приказчикова Мария от 25 Августа 2010, 15:38:53
-
У меня вопрос по UML 2.0 и Software Modeler, кто работал, какой объект в UML 2.0 отображает входящий документ? Заранее большое спасибо за ответ. И какой он в Modelerе?
p.s. Пока только изучаю..
-
У меня вопрос по UML 2.0 и Software Modeler, кто работал, какой объект в UML 2.0 отображает входящий документ? Заранее большое спасибо за ответ. И какой он в Modelerе?
p.s. Пока только изучаю..
А что за Software Modeler?
Понятие входящий документ в UML 2.0 нет. Но отобразить его можно. Вопрос в следующем: где на какой диаграмме и в каком контексте это нужно сделать?
-
IBM Software Modeler, входит в пакет Rational - модуль IBM Rational Software Architect.
Документ нужно отобразить на диаграмме деятельности. Я немного запуталась с различными объектами: есть Central Buffer, Data Store, но они используются как:
• Central Buffer – представляет собой буфер сбора входящей и исходящей информации
• DataStore – объект, обозначающий информацию, которая используется, когда необходимо
А просто документа, текущего, который от action к action переходит, не нашла.
-
Поясню: контекст такой, что происходят последовательные действия и результат одного является входным документом для другого, ьт.е. действие возможно после получения данного документа (информации)
-
Документ нужно отобразить на диаграмме деятельности. Я немного запуталась с различными объектами: есть Central Buffer, Data Store, но они используются как:
• Central Buffer – представляет собой буфер сбора входящей и исходящей информации
• DataStore – объект, обозначающий информацию, которая используется, когда необходимо
А просто документа, текущего, который от action к action переходит, не нашла.
это есть object node. Он как раз и может использоваться для этих случаев.
-
Хорошо, но, к сожалению, в инструменте Software Modeler, при клике на object node, мне предлагают создать либо Central buffer, либо DataStore, либо Activity Parameter. Визуального отображения Object Node нет.
-
Хорошо, но, к сожалению, в инструменте Software Modeler, при клике на object node, мне предлагают создать либо Central buffer, либо DataStore, либо Activity Parameter. Визуального отображения Object Node нет.
С этим инструментом не работаю. Не знаю чем вам помочь
-
Ладно, все равно спасибо :)
-
Всем добрый вечер!
Еще раз сформулирую вопрос:в документе от OMG для нотации UML написано, что обычный документ в последовательности обозначается Object Node. Попробовала добавить его в Моделере, но он на добавление предлагает только добавить Central Buffer, DataStore или Activity Parameter. Действительно ли обычный док отображается Object Node и как его добавить?
Несколько других вопросов:
1. Позволяет ли Software Modeler формировать технологические карты или инструкции к процессам. Если возможно то как?
2. Возможно ли проводить расчеты качественных и количественных характеристик процесса (на подобии ARIS eEPC)
3. И возможна ли семантическая проверка модели процессов.
Надеюсь на скорый ответ от пользователей IBM Software Modeler :)
-
Мария, вот для примера, и там же можно поискать более детально
https://www.ibm.com/developerworks/forums/thread.jspa?messageID=13696546�
Это похоже на ваш вопрос: https://www.ibm.com/developerworks/forums/thread.jspa?messageID=13869585�
-
Спасибо большое, информация очень помогла :)
-
Изучение RSM продолжается.
Вопрос теперь такой: можно ли связывать activity diagram между собой, чтобы на подобии как в Design Idef получилось?
-
Изучение RSM продолжается.
Вопрос теперь такой: можно ли связывать activity diagram между собой, чтобы на подобии как в Design Idef получилось?
Да UML 2 предусматривает такую возможность. Например Interaction Overview Diagram. Но кроме этого сама активити может быть декомпозирована, что собственно и есть то, что вы подразумеваете под IDEF
-
Тааак, хорошо, а возможно это сделать в Rational Sotaware Modeler? Помню, что не к вам вопрос, но может, кто увидит еще.
Считаю нужно вообще отдельную тему создать про этот инструмент. :)
-
Переименовал Вашу тему
-
В UML любой документ - это класс (или экземпляр).
Так или иначе, его надо создать в ProjectExplorer в соответствующем месте структуры.
Узлы объектов на диаграмме деятельности - это экземпляры класса, и когда Вы их создаете, Вы указываете тип как ссылку на соответствующий класс ("Входящий документ"). Какой объектный узел Вы нарисуете - почти безразлично: они четырехугольничком ресуются одинаково, а их суть - это выбранный тип (класс).
Нужно стремиться не перегружать диаграммы: показывать только то, что необходимо для иллюстрации вашей мысли.
На диаграмме деятельности показывать узлы объектов не обязательно: если Вы используете поток объектов, то при его создании тоже в свойствах делается ссылка на класс. Т.о. само использование потока объектов иллюстрирует наличие информации, а не просто передачу управления.
Иногда на диаграмме деятельности показывают объектные узлы при создании объектов, или даже несколько раз один и тот же узел, чтобы продемонстрировать изменения состояния (описанное в прикрепленной Note). Если это очень нужно.
Чтобы "проваливаться" в поддиаграммы или даже использовать "поведение, предназначенное для многократного использования", т.е то, которое можно использовать в разных контекстах, нужно на диаграмме создавать не Action, а Call Bechavior. При создании элемента Вам будет предложено выбрать существующее поведение или создать новое.
Такое вызываемое поведение м.б. деятельность или взаимодействие.
Если есть вопросы, пишите, присылайте картинки. Постараюсь помочь (если это не огромный проект). Или пришлите модельный файл.
-
Подскажите по этому продукту, как на диаграммах последовательности отобразить конкретный тип при возврате управления?
(Либо выбрать из перечислимого типа, либо выбрать конкретный подкласс)
-
Когда Вы создаете сообщение на диаграмме последовательности, нужно выбрать название соответствующей операции целевого класса. Если нужной операции нет, будет создана новая операция с именем сообщения.
Сообщение использует для передачи параметры и возвращаемое значение этой операции.
Т.о., устанавливать параметры и возвращаемое значение сообщению диаграммы последовательности не требуется.
-
Когда Вы создаете сообщение на диаграмме последовательности, нужно выбрать название соответствующей операции целевого класса.
Да операцию выбираю, но хотелось бы указать конкретный тип параметра в этой операции. Вот например есть два класса Мастер и Подчиненный, подчиненный может находится в двух состояниях (Работка, Инициализация) и он вызывает метод Мастера обновить состояние, куда передает текущее состояние (диаграммы во вложении). Вопрос и заключается в том как показать конкретное состояние (какое состояние он передает).
-
Небольшое замечание: аргумент сообщения д.б. доступен сообщению. В Вашем случае класс "Подчиненный" должен иметь атрибут "состояние".
Когда вы отправляете сообщение, аргументом является текущее значение этого атрибута.
Я вижу два варианта. Оба плохие. :'(
- На линию жизни перед сообщением устанавливаете State Invariant. В качестве ограничения устанавливаете "состояние = <нужное значение>". Это значение будет действительно на линии жизни до следующего изменения.
На диаграмме видно, какое значение пересылается. Валидатор нарушений не обнаруживает, т.е. это правильно.
Что плохо? Не используется элемент перечисления (Enumeration)
- Выбираем сообщение. На закладке Arguments в правой таблице создаем новую строку и выбираем тип Literal String. В поле Value пишем значение аргумента.
Тоже не используется перечисление.
Извините, лучше придумать не могу!
Если найдете более приличный способ, сообщите пожалуйста, будьте добры!
P.S. Если это не "придуманный" пример, то, наверное, сообщение должно включать идентификатор работяги.
-
Спасибо за ответ!
Это не придуманный пример, максимально приближенный к существующему. Подчиненный имеет атрибут состояние верно, и идентификатор то же.
1. Используем State Invariant (вот вопрос почему я не могу использовать уже описанные состояния из диаграммы состояний ( в ЕА такая возможность есть)? приходится новые создавать - поле для ошибок в).
2. Пробовал я писать ручками значение аргумента, но вот отобразить на диаграмме почему-то это не удалось. Может подскажите как? (в ЕА можно выбрать конкретное значение аргумента из списка. Не хочу сказать что ЕА лучше RSA ))))
-
Извините, я сегодня занят. При первой возможности посмотрю.
-
Я еще раз внимательно прочитал спецификацию UML.
Инвариант состояния к диаграмме состояний, к сожалению, отношения не имеет.
Инвариант состояния - это условие, которое должно исполняться на протяжении периода активности этого состояния.
На линии жизни период активности состояния сохраняется между точками вхождения сообщений.
Т.е. если между двумя точками вхождения указано {f>0}, то во всех отправляемых между этими точками сообщениях будет использовано f>0. Вместо {f>0} может быть {состояние="РАбота"}.
Или искать другое решение. Увы!
-
Я еще раз внимательно прочитал спецификацию UML.
Инвариант состояния к диаграмме состояний, к сожалению, отношения не имеет.
Леонид Борисович, не соглашусь с Вами.
Смотрим OMG Unified Modeling Language (OMG UML), Superstructure, V2.1.2
14.3.31 StateInvariant (from BasicInteractions)
Description
A StateInvariant is a runtime constraint on the participants of the interaction. It may be used to specify a variety of
different kinds of constraints, such as values of attributes or variables, internal or external states, and so on.
...
Presentation Options
...
The state symbol represents the equivalent of a constraint that checks the state of the object represented by the Lifeline.
...
На Figure 14.24 - Ignore, Consider, assert with State Invariants приведен пример нотации
-
Спасибо, Денис. Я действительно смотрел свой старый перевод спецификации, и, кроме того, не очень точно сформулировал мысль.
К сожалению, это не меняет сути. Особенно для Varg.
В Вашей цитате из спецификации говорится, что значок состояния - это альтернативное представление ограничения.
И далее говориться, что если поведение класса описывается машиной состояний, и мы хотим в качестве ограничения представить внутреннее состояние, то его название должно соответствовать одному из определенных состояний.
В остальном я, кажется, не "накривил".
Т.е. инвариант состояния представляет ограничение, в простейшем случае действующее как я написал в предыдущем письме. (В примере приведен более сложный случай).
И второй вывод - Rational выполнил спецификацию: есть два варианта нотации, и предлагается ввести текст ограничения и, не обязательно, название. Название может отражать состояние объекта.
М.б. им следовало предоставить опцию использования значений внутренних состояний, но в спецификации этого не предусмотрено.
-
подскажите пожалуйста, а как добавить свой стереотип в RSM?
А может можно расширить стандартными стереотипами (сейчас в списке всего 7 стереотипов).
Пробовал создать свой профиль, там новый стереотип, но выбрать его так и не получается (профиль к модели применил).
-
В проекте профиля при создании стереотипа Вы должны указать, к каким элементам этот стереотип можно применять. Сделали? Проверьте, пожалуйста, что тип элемента указан правильно.
Если профиль к модели Вы применили, то других "фокусов" я не вижу.
Если будет совсем туго, присылайте Вашу рабочую область. Разберусь на месте.
-
спасибо, да не применил к каким элементам этот стереотип применяется.