Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - Helmut Ortmann

Pages: 1 ... 47 48 [49] 50 51 ... 61
Uml Process / Re: [SysML] Activities
« on: July 09, 2014, 10:16:17 pm »

I think you could put is this way.

Parameter is the specification what is possible to pass and Pins specifies what is passed in the current context.


Uml Process / Re: [SysML] Activities
« on: July 09, 2014, 09:53:03 pm »

1. Define an Activity
Usually you define and specify an activity, which is a reusable behavior, in an activity- or/and bbd (only definition) -diagram. An Activity may have parameters and a behavior described by its Activity Diagram.
Parameters are like formal parameters defined by the specification in a programming language. In essence it's the specification of the parameter which might be passed in case of an invocation/call.

2. The usage of an Activity
Usually you use an Activity inside an Activity Diagram. Just simply drag the activity from the canvas to the diagram and make sure you have chosen to create an Invocation. You see the result as a fork in the right down corner of the shape.
Now you have a usage / invocation of an activity. It's up to you to use pins to visualize the exchange of parameters. Each Activity parameter may result in a PIN which is the actual parameter with current value in a programming language. You may also say: This is the invocation/call of a behavior.

In SysML and also in UML it's often useful to distinguish between the specification of a reusable behavior and the call / usage of the behavoir. The usage may pass special values to the Activity.

In short:
- Definition is an Activity with the specification of its behavior and parameters
- Invocation / Usage is the current usage of the Activity from e.g another Activity with possible actual values.
- A Parameter is the specification which parameters may be passed to the Activity. Activities may have parameters
- A Pin of an Activity Invocation represents the currently passed value of the parameter. Activity Invocations may have Pins.

Hope it helps.


Uml Process / Re: Finding where a InformationItem is conveyed
« on: May 21, 2014, 08:27:58 pm »
If you start your SQL with:
Code: [Select]
select t_diagram.ea_guid AS CLASSGUID, t_diagram.diagram_type AS CLASSTYPE,..

you can jump from the search window to the diagram.


Uml Process / Re: Finding where a InformationItem is conveyed
« on: May 21, 2014, 08:03:52 pm »
With script and SQL-Search it's possible (not a perfect solution).

Write a SQL-Search with the GUID as <Search Term> and output the diagram, Source Element and Target Element. Then you can easily navigate to the diagram and with luck you see your item.

Write a browser script which calls the Search with the GUID.
Put the browser script into a browser script group.

Then you have your search at the context menue in the project browser.

To make it a bit easier to use you may write a Search Script (type  Model Search Group) to open the diagram of the selected connector and select the source and target of the connector.

I admit, if you haven't done it before it will take some time.


Uml Process / Re: Composite Use cases and relationships
« on: May 20, 2014, 04:12:27 am »

in general: EA maintains composite relationships. I've also encountered sometimes problems with this relationships. These issues were related to Version Controlled Packages. In my experience manageable. What EA release you are using?

You can detect lost relationships by query. I admit it's not trivial.

Personally I would create a composite structure by nested packages (package in package). If you have troubles you can easily  rebuild the lost relationship. I like structuring something by packages. Everybody understands it and is able to see it at first glance.

If you do this the EA composite diagram is just a shortcut for the convenience of the user. Lost no real problem.


Uml Process / Re: Documentation for Activity Diagram Toolbox
« on: December 27, 2013, 06:54:22 am »

my personal view:

The quickest way is to
  • buy a book
  • make a training
  • get a coach for you and your team

Let me try to say it with some words. Forgive me for oversimplifying.

In UML an activity is a behavior. A behavior (an activity) can describe the behavior of a simple C-function or of a whole system, a part of a system or something else like a business process.

An activity diagram describes an behavior. Therefore it's a good idea to have an activity diagram for each activity.  

An activity, an activity diagram may contain arbitrary activities, actions, or control elements like decisions.

Actions are atomic operations where the modeler has no intention to refine them by means of UML.

Actions may be a bit confusing because of the many existing kinds. For the start you may need:
  • Atomic action (just the text and specification inside)
  • call operation action (call a method of a class)
  • call behavior action (call a behavior, an activity)

These elements together with:
  • Init
  • Final
  • Decision
  • Merge
  • Fork
  • Join
you have your basic toolset.

For the start: Learn to make valuable models. Think of yourself of an author who wants to explain your problem at hand to the invisible reader.

Stereotypes or tagged values are no concept to start with.

In my opinion most of the value of an UML model isn't generating a code but understanding the problem. After managing this you can look to code generation.

In mechanics we have:
  • side view
  • front view
  • top view

In UML we also have different views (diagram types) to our system at hand.

Therefore: Think about the best model kind for each type of problem. You may use a pincer to nail a nail into the wall.

Good luck,


Uml Process / Re: Baffled by rake symbol intricacies
« on: January 30, 2014, 06:20:46 pm »

Call Operation:
Just drag and drop an operation on the activity Diagram.
Use Call Operation if you want to have the relationship to your class model.

Call Beavior:
Just drag and drop an activity on the activity diagram. Choose Invocation.
Use Call Behavior if you want to call another activity or reuse beahavior.

Re Use of Activities:
You may drag an Activity(Composite Activity) by link on the diagram. You may drag an Activity as Invocation (Call Behavior) on the diagram. With a Call Behavior you can send parameters to an activity. For reuse of Beavior I only use Call Behaviors.  

Efficiently navigating and working:
Have a look on Geerts Navigator. I have my own Addin and a slightly different strategy.


Uml Process / Re: tracing from Activities to Actions
« on: January 10, 2014, 06:57:44 am »
Hi Robert,

I'm not sure I understood you right.

1. Diagrams which contains an action
Click on action + CTRL+U

2. Impact analysis by Search (SQL)

By the way: Usually an action is an aromatic thing which runs inside an activity. Therefore actions usually only occur once on that diagram which specify an activity. They are beneath/nested the activity which runs the action.

You may think of an action as one or more lines of code. Each line or group of code is unique within software module. For reuse of code/action you usually use similar strategies like in code. These are:
  • Call Operation Action
  • Call Behavior Action

Mostly, reuse of action isn't a good idea. Reuse of operations or behavior by calling them is a good idea.


Uml Process / Re: link between EAP Issue
« on: January 03, 2014, 06:29:04 am »

there is no way to link to another *.eap file.

What you can do is:
- Export your elements in *.eap(1) (xmi/xml)
- Import your elements in *.eap(2)
- Create the links in *.eap(2)
- By export / import of the links you have the links in both *.eap files

You can also use Version Control to accomplish this task.



Uml Process / Re: Find out where a diagram is used (linked)
« on: August 22, 2013, 07:07:18 pm »
Hi Alberto,

the Browser script to find diagram usage by right click, script, ..

Code: [Select]
option explicit

!INC Local Scripts.EAConstants-VBScript

'- Find Usage of Diagram
'- Diagram:   Find Usage of selected Diagram'
' History:
' 07. December 2011: Created
sub main()
      ' check diagram
      'Session.Output "test"
      'Session.Prompt "This script does support diagram items. ", promptOK
      dim guid
      dim id
      dim el
    dim s
      dim selected
      set selected       = Repository.GetContextObject()
      dim selectedDiagram as EA.Diagram ' to use intelli sense for Diagram
      Set selectedDiagram = selected  

      'on Diagram
      if not selected is nothing AND selectedDiagram.ObjectType = otDiagram then
                  Repository.RunModelSearch "Diagram usage", selectedDiagram.DiagramGUID, "", ""
                  exit sub
                  'Session.Output CStr(selectedConnector)
                  ' Session.Prompt "This script does not support diagram items of this type.", promptOK
          'in Browser
            ' Get the type of element selected in the Project Browser
            dim treeSelectedType
            treeSelectedType = Repository.GetTreeSelectedItemType()
            ' Handling Code: Uncomment any types you wish this script to support
            ' NOTE: You can toggle comments on multiple lines that are currently
            ' selected with [CTRL]+[SHIFT]+[C].
            select case treeSelectedType
      case otDiagram
                        dim theDiagram as EA.Diagram
                        set theDiagram = Repository.GetTreeSelectedObject()
                        Repository.RunModelSearch "Find CompositeElement of Diagram", theDiagram.DiagramGUID, "", ""
      ' Code for when a method is selected      
      '            case otMethod
                        case else
                        ' Error message
                              Session.Prompt "This script does not support items of this type.", promptOK
            end select
      end if
end sub


Create a script Group Browser Scripts, New VB Script, overwrite it

Uml Process / Re: Find out where a diagram is used (linked)
« on: August 22, 2013, 07:03:13 pm »
Hi Alberto,

the SQL:
Code: [Select]
Select o.ea_guid AS CLASSGUID, o.object_type As CLASSTYPE,
, o.Object_Type AS Type,  o.stereotype,'Reference to diagram' As Usage, As Diagram_Name, dia.diagram_type
#DB=DUMMY#    /*  Reference to Diagram    */ #DB=DUMMY#
#DB=JET#        t_object o INNER JOIN t_diagram dia on ( o.pdata1 = Format(dia.diagram_id ))   #DB=JET#
#DB=SQLSVR#        t_object o INNER JOIN t_diagram dia on ( o.pdata1 = dia.diagram_id )   #DB=SQLSVR#
#DB=ORACLE# t_object o INNER JOIN t_diagram dia on ( o.pdata1 = Cast(dia.diagram_id as Varchar2(39))             )   #DB=ORACLE#

where dia.ea_guid = '<Search Term>' AND o.object_type in ('InteractionOccurrence', 'Text', 'UMLDiagram')

Select o.ea_guid , o.object_type ,, o.Object_Type ,  o.stereotype,
  'Composite of diagram' , ' ', ' '
t_xref x INNER JOIN t_object o on (x.client = o.ea_guid)

where x.supplier = '<Search Term>'

order by 3,4,5


Uml Process / Re: How can I generate class diagrams from the .h?
« on: July 19, 2013, 04:45:20 am »

the import only creates classes from *.h/*.c files in case of C++/C.

A Diagram is a view of your system at hand. You, the modeler, defines what you want to see and what you want to communicate to your readers. A class is often part of several diagrams, several views.

For example you want to see the context of the class, a diagram. In another view / diagram you want to show the relations of the class. It's a different diagram with the same class but something other around it. In a third diagram you want to show the attributes of the class. This is just a new diagram with the same class and other visibility settings.

So you are the boss of your views. In other words you are the boss of what you want to tell. So it's your task to make some valuable diagrams.

Always keep in mind: If you delete a diagram the model will not change. It might be not understandable but in essence it's the same. A Diagram is simply a view to your model to improve understanding.


Uml Process / Re: How can I generate class diagrams from the .h?
« on: July 19, 2013, 12:31:19 am »

make sure the the default language is set to C
(Tools, Options, Sorce Code Engineering)
create an empty package:
- Right Click on the package
- Code Engeneering
- Import Source Directory
- Choose File Extens (C,H)
- Select Directory
- OK

EA creates the class(es). Create a diagram and drag the class onto the diagram.


Uml Process / Re: Design Hardware/Software dependencies in embed
« on: May 24, 2013, 04:14:52 am »

as mentioned before there are many possibilities.

My preferred methods are:

1. Find one or more stereotypes for hardware
I use simple <<HW>>, but you may find more specific elements like <<spi>>,<<uart>>,<<subsystem>>, <<extern>>,<<AUDI>> or what is important for you

2. Assign the stereotypes to class or blocks (UML/SysML)
    You may add some tagged values which are important for such a subtype. E.g. Baud-rate if its important.

3. Class/Block -Diagram or Composite Structure/Assembly -Diagram
    Decide which diagram type fits best your requirements.
    - Class/Block is the light way
    - Part in Composite Structure/Assembly -Diagram is the concrete way
    For a lot of peoples the difference between Class/Block and part is somehow fuzzy. Therefore I usually preferred modeling with Block/Class

4. Use Ports and Port Types to specify the connection points

5. Use connector to connect Ports

6. If it's important model the Item flows over the connectors .
    I usually prefer to define the transferred information by the port type or simple by a name. Of course, Interfaces will also do a good job.

7. In sequence Diagrams you can easily define the communication
    Because of stereotypes you always know who is participant in communication. <<subsystem>>, <<SPI>>,<<UART>>, <<system>>, <<extern>> for foreign unit are easily to understand.

With those approaches we have in effect an information flow. In discussion with system engineers or typical embedded developer this approach does a good job.

There is no "true way" to success. You have to take in account the experiences of your stake holders and ....

Kind regards,


Uml Process / Re: a unified process for SysML and UML
« on: March 27, 2013, 08:07:48 pm »
I'm interested too. Good idea!

Best regards,


Pages: 1 ... 47 48 [49] 50 51 ... 61