Author Topic: Switching from ARTiSAN while keeping RtP process  (Read 507 times)


  • EA User
  • **
  • Posts: 37
  • Karma: +0/-0
    • View Profile
Switching from ARTiSAN while keeping RtP process
« on: June 18, 2007, 08:01:29 am »
I am evaluating EA as an alternative to our existing ARTiSAN Real-time Studio tool. Unlike EA ARTiSAN promotes the use of its own development process known as Real-time Perspectives (RtP), and we have been using this successfully.

At the Requirements Architecture level, RtP has three models - Scope, Modes, and Usage. Scope is represented by a non-UML compliant proprietary diagram type referred to as a Context Diagram. Now the term context diagram means different things to different people; in ARTiSAN it has Actors, Subsystems, Interface Devices, and links carrying synchronous and asynchronous messages.

In EA I can successfully represent the Scope Model using a Collaboration Diagram and some object stereotypes for <<subsystem>> and <<device interface>>, and hidden sequence numbers and object members. (This is contrary to  ARTiSAN's RtP Mentor's advice, which suggests a UML compliant form would be a "Structure Diagram", but it does little to elaborate, and I cannot see how you can have messages on links in a structure diagram!?).

The Collaboration Diagram representation is potentially more expressive than ARTiSAN's proprietary form, but it introduces a few problems due to what EA allows  me to do with these diagram elements:

In RtP, the Modes Model is a State Diagram attached to a subsystem in the Context Diagram; my problem here is that the subsystem is an object not a classifier, and EA does not allow me to attach a State Diagram to an object. I am not sure why I can add operations to an unclassified object but not a state diagram?

Ideally I would be able to attach a State Diagram to a <<subsystem>> object (without a classifier), and the event triggers would be the operations attached to that object (which are also the messages on the incoming links). As it is, the Modes Model has to be a stand-alone State Diagram with manual consistency checking between the Modes and Scope models (i.e. the triggers are just textual names with no automated link to the messages in the Context Diagram).

The RtP Usage Model is as you might expect an Use Case Diagram, elaborated with typically Sequence Diagrams - this of course translates well to EA. However in the RtP Modes Model, the action blocks are typically Use Cases, whereas EA only supports Activities as direct model links, so again, the action blocks are only textually related to the use cases. Again I am not sure why EA is so restrictive regarding elements that can usefully be attached to action blocks?

Currently I am not too unhappy with the compromises I have had to make, since the depth of the RtP Requirements Architecture is in the Usage Model, and this EA does better than ARTiSAN IMO. However if anyone can offer any suggestions as to how I might improve this mapping of RtP to EA, or perhaps modify the process itself to achieve the same goal (i.e. represent the same information) in a manner better supported by EA I would appreciate any suggestions.

Also if anyone can offer an opinion on where I have suggested EA is inflexible - perhaps it breaks the UML for example - I would be interested. I would not want to venture a feature request for something that is fundamentally flawed.  :-[