Modeling Interaction between System and Actors

[hglathe]

Hi,

I want to model the following:
The interaction (functions and informations flows) between my system I've already modeled and the external systems (here actors of my system).

What I already have are the information structure (class diagram) of the system itself. Next time it will be transfered into a logical model for relational database management system.

Now, several external system have to interact with my system. Each of the external systems have restricted access on the database. Not all informations are public to all external partners. Thus, I have to define views for each external system.

My question:

How can I model views based on an already existing structural class model with EA?
How can I use thoose views for defining informations flows between my system and the external partners?

What kind of diagram is suitable for modeling an overview of external systems and my system together with interaction associations + information flows?

Many thanks in advance, Helko

[qwerty]

There's no short answer to your question. Probably collaborations are a good way to show the constraints for the systems. A collaboration is a realization of a use case which shows how the single systems(/actors) interact. For this purpose you can use sequence/activity diagrams.

q.

[Paulus]

Hi Helko,

My 2cts: i wouldn't model the views themselves since to me they are a technical choice for implementing a specific autorisation requirement.

So I would rather start with the underlying requirements, like this: create a stereotyped Requirement called 'Autorisation ticket'

Now for each specific access restriction:

1) create a Requirement element in your model of type 'Autorisation ticket' and describe conceptually what type of information should be made available to an actor (an extern system or human actor) that has such a ticket.

2) Create an RTF document element in your model that details the requirement into a description of the classes/attributes that are involved and link this to your 'Autorisation ticket'

3) Also, using the information in the RTF document, link each 'Autorisation ticket' to the classes in your model that contain information covered by the requirement

4) Last but not least: link each 'Autorisation ticket' to those Actors in your model (either humon or system) that should have access to the the information that the ticket describes. Alternatively if the autorisation depends not so much on the actor but on specific information exchanges link the ticket to the interface class modelling this exchange.

5) In the description of the exchange you can now refer to the classes you already have since the linked requirement will make clear what restrictions apply.

This way you get a flexible representation that keeps the domain model clean while you're still able to trace the impact if either the class model or the autorisation requirements change. The information required to implement the views is ofcourse contained in the RTF document linked to each ticket.

regards,

Paulus

[hglathe]

Hello,

thank you all for the replies.
To the use of authorization tickets and RTF documents: Thats a workaround that might work.

But I notice that there are no first class concepts for realizing such a view mechanism where I can define individual role specific data projection and selection on my system data schema such as when making database engineering.

What do you think about the folowwing:
What about modeling additional classes with a certain stereotype 'data schema view' or something else. Such a class must be non-persistent (it's just a view) also contains attributes and view specific methods. The attributes will be derived (simply 1:1 representation of the equally named attribute of an associated class). Or the value will be derived from diverent attribute values comming somewhere specific from all the associated persistent system classes. Each derivation expression has to be defined somewhere in the properties of the derived attribute.

Finally you will get several classes with such a stereotype and each class with lots of derived attributes. Thoose classes must be somehow associated with external system components.

What do you think about that? Do you know first class concepts for realizing that with EA's modeling languages?

Thanks in advance, Helko

[Paulus]

What you describe sounds a lot like the  "View" stereotype from the Data modelling extended profile. Perhaps it is easier to turn this around: start by creating the DDL, define each view using the "View" stereotype from that, create a class in your concectual model for each view and link these together using a Realize link?

[hglathe]

You're right it sounds like the view stereotype.
And it should be a view.

What is the difference between the class you have mentioned and the entity types I will define before the views?

I thought that there is already a possibility to model views with more detailed first class concepts. The view stereotype is what I need but I have to specify the view internals with a classical DDL-statement.
My wish is:
- to have the entity types modeled
- create additonal views
- associate the views with the appropriate entity types
- derive view attributes (1:1 from assciated entity types and more complex view attributes through attatching a DDL statement)

Thoose view stereotyped classes shall be the base for the SOA based business solution architecture on top of the database layer.

Each view class will be faced through a entity service bean and appropriate data transfer object (DTO's).

Thanks in advance, Helko

[Paulus]

OK I now understand what you want to achieve. You can do that with EA but it requires some work: add a custom tagged value type 'ViewAttributeMap' that will hold the mapping (from the menu, settings->UML types-> tagged value types), define each view as a standard UML class with attributes, and to each attribute add a tagged value 'ViewAttributeMap' with a QL expression <entity>.<atrribute> for a 1-1 mapping or DDL for more complex mappings (you can do that from the 'Tagged Values' view).

The drawback is that there is no check on the validity of the QL against your model (eg if you have a map Book.Title and you change the attribute Title to Description then your QL is not altered by EA). So you may want to write a script that checks for such inconsistencies.

regards,

Paulus