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 - natvig

Pages: [1] 2 3 4
General Board / Re: Information Items Conveyed
« on: October 25, 2019, 07:19:22 pm »
Answer to your issue no 1: Right click on the Information flow and choose Advanced -> Information Items Conveyed...

You should definitely place internal block diagrams within the block itself. There are many benefits which this approach, there is simply no other way. Yes, documentation can be a little tricky, especially if I have multiple ibd:s within a block. How can you output elements from one diagram at a time in this case? I have had success doing it with document scripts following this guide:

Block definition diagrams on the other hand is normally not placed within a block, but can be in some special cases. One example is the diagram 7.10 in the book A Practical Guide to SysML (second edition). There you see the diagram header bdd [block] Camera (Power Subsystem) which indicates that the context for the diagram is a block which indicates that the diagram can be placed under the block itself.

SysML is general in the sense that it can model any system, hardware and software. It can also be used to model logical architectures, i.e. where it has not yet been decided if solution is hardware or software. Yes, UML (and SysML) have diagrams suitable to model non-textual constraints/requirements in use cases, interactions, activities, state machines etc. However, stakeholder needs and requirements are still very often expressed in textual languages and you are often expected to provide traceability from those text based requirements to more refined model based requirements. This is where SysML comes in handy since it provides everything you need to make the transition and traceability from those text based requirements to other parts of your model. UML and SysML can be used together in a model. A suggestion is to add the requirements part of SysML to the UML you are currently using.

You should look at SysML which is a UML based language (and an ISO standard) for modelling systems and its requirements. SysML includes all the concepts needed to model requirements and their relationships to system elements such as interfaces and other properties. The UML profile for SysML is available in Sparx EA.

There is yet another method. You can drag the quick linker to an empty area of your diagram and press the Shift-key before choosing the target element type. You will then be prompted with the search dialog which allows you to search for any element in the whole model. The target element does not need to be present in any diagram.

The new metamodeling features in EA14 is absolutely fantastic. Finally meta constraints and view specifications can be easily implemented into a profile to enable constraints to diagrams and model validation. There are a couple of minor features missing that would improve even furter, such as the possibility to set diagram options in a view specification. Another thing that I have not been able to implement is the inclusion of patterns from a view specification. It works well from a toolbox profile, but not from a view specification. Has anybody made it work? From a view specification I tried to expose an abstract stereotype called MyProfileName::MyPatternName(UMLPatternSilent), but it is not working.

Any ideas?

General Board / Re: Diagrams in report cropped!
« on: September 06, 2017, 04:36:07 am »
I have noticed similar behaviour when using EA from within a virtualised windows environment (like Parallels on Mac). Depending on the resolution set on the Windows desktop the images are cropped to a larger or lesser extent. Before generation of final documentation I sometimes need to change resolution.


General Board / Re: ISO 80000-1 Quantaties and Units
« on: May 29, 2017, 06:44:19 pm »
if I have done it correctly, it doesn't look like the ISO Library  (ISO 80000-1 Quantities and Units).

Do you see the Quantities and Units? Maybe I've missed something.
I forgot to mention that the library is only available from the SysML 1.3 Technology which is the one I still use most of the time. Note also that there were some changes made to units in SysML 1.4. Tim Weilkiens has written a post about the changes here:

General Board / Re: ISO 80000-1 Quantaties and Units
« on: May 29, 2017, 05:24:10 pm »
Those are available from the model wizard (Right click on a package -> Add a Model using Wizard...). My first impression is that they work reasonably ok.


I recognise the need that I think jankari is describing. My interpretation is that jankari needs to be able to include a tagged value, defined on the model document itself, into the generated report from that model document. Thus, analogous to Project Constants, but for each model document in a virtual document. The Report Constants setting on a virtual document overwrites any defined tagged values in a n individual model document. Also, it is not possible to include a custom defined tagged value of a virtual document.

With the above functionality it would be possible reduce the number of templates necessary in a model by reusing the same template for many different sections of a report. Consider for example a report with a standard template (look) for all chapters, except that the chapter heading is different for all chapters. With the possibility to include tagged values on the model document itself into the report, we could reuse one single template throughout the virtual document.



  • In order to share a common page definition between two diagram types you need to have this common page definition extend the ToolboxPage meta classes in both profiles! The common page can be located in one of the toolbox page packages, it does not matter which. But it should be visible in the diagrams of both toolbox pages.

No, doesn't work. Page only displayed in one toolbox associated with profile where this page is located.

Then you must have generated the toolbox profile from a directory instead of the diagrams. Or, the toolbox page is NOT present in both toolbox profile diagrams before generating the toolbox profiles. (I use this method all the time and know for a fact that it works.)

I'm not sure I understand you but I think I do, and yes it is possible to achieve what you want. A couple of points:

  • Each diagram type can only be associated with one toolbox profile, which means you have to create two toolbox profiles if you have two diagram types. Each toolbox profile need to have its own ToolboxPage metaclass. To create a Toolbox Page you extend this metaclass in a "stereotype" which holds the definition of the different elements you wish to have in your toolbox page.
  • In order to share a common page definition between two diagram types you need to have this common page definition extend the ToolboxPage meta classes in both profiles! The common page can be located in one of the toolbox page packages, it does not matter which. But it should be visible in the diagrams of both toolbox pages.
  • Make sure you create you profile by right clicking in a toolbox page diagram -> choose Advanced -> Save as profile. (The definitions you wish to include in your profile must be visible in the diagram.) It is not possible to create the profile by right clicking in the browser since the common page can only be located inb one of the toolbox profile folders. It will be missing from one of the toolbox pages if you try to do so. (Unless you move it of course between creation of toolbox profiles. But don't do that. Much easier to use the diagrams.)


Uml Process / Re: How to use IBD and properties
« on: November 30, 2016, 07:56:15 pm »
To be honest I haven't much experience with interfaces. I just think diagrams get cluttered with "lollipops". I haven't understood what interfaces add that cannot be achieved with ordinary blocks and interface blocks. If you turn to modern architectural frameworks such as the UAFP interfaces are not used.

I think you may have misunderstood my point about item properties. Everything is already in EA 12 (and EA 13). If you define your
properties on a block, item properties can be visualised exactly in the same way as item flows. No specials necessary. Follow these steps:
  • Define one or more flow properties under your block.
  • Create an item flow between two parts of the block.
  • Go to Properties | Tags of the item flow and choose your flow property created under step 1. (Only one item property is allows per item flow, as per the SysML spec.)
  • Add a connector between the parts of the block.
  • Right click the connector and choose Information Flows Realized...
  • Now select your item flows, and the item property will be displayed just lite any item flow.


Uml Process / Re: How to use IBD and properties
« on: November 29, 2016, 04:50:05 am »
Helmut, I agree on what you wrote, with one exception:

In SysML you can put Flow Properties on the connector and in EA you can only put blocks like classifiers on the connector (Information Flow realized).

EA is actually capable of handling item properties. Look at tagged values of your item flow. There you will be able to assign an item property to the flow. The flow can subsequently be realized by a connector.

(Also, I could live without Interfaces. Why would you want to use them?)


Automation Interface, Add-Ins and Tools / Achimate, definition vs use
« on: November 06, 2016, 02:25:23 am »
I'm trying to understand how to best use EA for Archimate modeling. Having a solid understanding of SysML, and appreciating the difference between definition and use, I find the Archimate implementation in EA lacks som important features. Say for example that you need to model a business process where one of the business functions appear more the once. This presents a problem in EA since more than one instance of an element on the same diagram is not allowed. This makes perfect sense when modeling SysML since you use call behaviour actions to modell process flows in activity diagrams. However, in the Archimate 3 profile that comes with EA 13 you are supposed to model all diagrams types using "Class diagrams" which is a diagram that is supposed to have elements of definition on them.

My guess is that other Archimate tools allows more than one instance of the same business function on the same diagram. In order to make EA more usable as an Archimate platform should't business processes be modeled in activity diagrams using call behaviour actions?

/Hans (Archimate beginner)

Pages: [1] 2 3 4