System Context Diagram - modeling

[bioform]

A context diagram has a center object that represents the System Under Development (SUD), with different external systems surrounding it.

These "external" systems communicate with the SUD in some fashion and are usually "linked" to the center object (sometimes in a way that indicates their information exchanging capabilities, in, out, or bidirectional)

The purpose of course is to help establish the scope (or boundaries) of the SUD... "No that's not our system...  We will use Oracle as the... Well do we really want to automate the..."

Okay, that is how I think of it... So using UML we would need:

• an element to represent the SUD located in the middle,
• an element to represent the systems external to the SUD, and
• an association between these elements to represent the information exchange.

My thinking is:

• the SUD would be the "Actor" that is used to represent the system (rectangle notations)
• the external systems would also be represented by an Actor. When it is a automated system I use the rectangle notation, stick figure when it is a person.
• the links between the actor's would be an ""nformation Flow" with the "Direction" attribute defined (Unspecified, Source -> Target, Target -> Source, or Bi-Directional)

 

My goal is to be able to maintain this conceptual view throughout the life of the project using UML elements and automation (e.g. adding of an external systems, etc.)

Thoughts, suggestions, different approach?
David

[Thelonius]

David

I've been using the UML Component diagram for what you propose. A 'Component' element represents a 'Business System'. The 'Information Flow' connector represents an 'Interface'.

One model represents the 'As Is' environment. A different model represents the 'To Be' future environment, the 'End State'.

I'm vaguely aware that one can define a 'baseline', and have the 'to be' representation in the same .eap model, but I haven't got there yet.

Be nice if there was a book titled 'How to Use EA for Enterprise Architecture Purposes: Examples of Practical Applications Using the World's Cheapest and Most Open Architecture Tool'.

I'm using EA merely as 'a better Visio' at this point. Experimenting with UML Profiles to define Tagged Values, but that's still in the R&D phase.

The current 'As Is' model has an 'Everything' diagram that shows all of the more than 100 business systems in it, with all of the myraid interfaces. It's 'the diagram that shows just how complex our environment is'. Not much use for anything other than that. We have defined other, smaller, more detailed, but scope-limited diagram views for various Business Domains. E.g., all the business systems and interfaces that play in 'Risk Management'.

We say that the diagrams we're creating with EA are 'just the tip of the iceberg' of architecture work. We have defined 13 textual information descriptors that we keep in the 'Notes' section for 'Business Systems' and 9 bits of defined information in the 'Notes' section for each 'Interface'.

This supporting textual information provides the 'real value' for our architectural work. We're able to use the model in real time to answer common architecture questions: "How many of our systems are dependent on WebMethods for interfaces?"

I avoid mentioning the word 'UML' when talking to the customer.

Happy to share information with anyone.

Regards
Jon

[bioform]

Yes, I understand the "Component" diagram idea and that is very helpful during the design phase... (also the context diagram should serve as input for that analysis too.)

My approach during this early part of the inception phase, is to establish the business glossary (get agreement on terms and names) and identify the "external" systems (including person actors) that will interact with the system under design.

I find that at this point the actual names of these systems may not be accurately known (e.g., "Well I know it will have to interact with our Payroll system...) I am not trying to describe any arhitecture yet, but rather to start/help identify the scope of the project.

During this time I am creating:

• Stereotyped Requirements (Definitions) that I use to contain these terms and name definitions,
• Matching business domain classes (if needed) which the "Definitions" link to, and
• Actors (e.g., People, Systems, and Stakeholders - Payroll, Loan Manager, Auditing Department)

I started a related thread on the Stakeholder Analysis topic (and an Onion Model approach) that I am finding works very well with the concept of a context diagram...

Currently as I identify an external system I:

• Add the system as an Actor (External System),
• Create an "owned" Partition with the same name (representing that actor in subsequent activity diagrams), and
• Create a Stakeholder "Role" for the "Interfacing System" slot in the "Containment System" layer of the onion model.

Note: Later the person who will be the POC for that stakeholder system will be created in that package by adding the "Stakeholder" to the system as an instance of the Element (Object)

That is my current approach and it lends itself well, I believe, to establishing a robust set of initial links to be expanded upon to support various types of analysis (conflict, coverage, impact, etc.) through traceability.

Since this seems to be an area/phase of projects that is glossed over or avoided, the risk is that entire groups of stakeholders, and their needs, goals, and requirements may missed entirely or “discovered” late in the development cycle.

I am interested in hearing/exploring the many ways EA, and how other EA users attempt to address/support this area of requirements engineering.

So, I'm lending MY ear to my fellow requirment engineers and countrypersons!;D

David

[Paolo F Cantoni]

Currently as I identify an external system I:

• Add the system as an Actor (External System),
• Create an "owned" Partition with the same name (representing that actor in subsequent activity diagrams), and
• Create a Stakeholder "Role" for the "Interfacing System" slot in the "Containment System" layer of the onion model.

Hi David,

If I understand what you're implying correctly...  

What you're expressing here is something I've come to believe that:  UML got it wrong in seeing "renderings" as separate things.  So for example, Sometimes I want to see this entity as a Class, sometimes as an Actor, sometimes as a Partition.  In other words, merely different renderings of the same entity.  (Similar to a named AassociationEnd IS an Attribute).

Obviously, you may start with separate things during early analysis, but when you discover that you have two renderings of the same thing, you should be able to unify them.

Notwithstanding (build) 840's improved support for synchronization of Attributes and AssociationEnds, we're looking at providing direct DB support for this "identity".

We're also looking at direct DB support for "unifying" the renderings of the same entity (held as separate rows in t_object).

What do you think of that approach?

Paolo

[bioform]

We're also looking at direct DB support for "unifying" the renderings of the same entity (held as separate rows in t_object).

What do you think of that approach?

Paolo

Yes, I agree that does address the issue directly. The underlying element should be rendered in the context of the use (stick actor, rectangle notation actor, partition, boundary, etc.)

In the mean time, I am planning on adding this functionality via add-in.
E.g., Drop an Actor that has been Stereotyped as an external system, then the rectangle notation is used. This could be expanded, so if an Actor was dropped on an activity diagram, then the Actor's Partition would be dropped instead, etc.

So my work-around for the Context diagram was to drop a "named" boundary (System) on the diagram, select the boundary and menu options Appearance... Shape... and then select Ellipse.  I then dropped the "system" actor into the middle of the boundary. To create the associations to the external system actors, I just dragged and association from the boundary to the external system actor, set direction and there we go!

Nice to know this is being looked into!

Dave

[Paolo F Cantoni]

Nice to know this is being looked into!

Dave

Yes, David,

but not (as far as I know) by Sparx...

I've managed to move the EA database "up one level" so that EA talks to the "physical" Database via views.  Under the views, we can make the tables do what we want...

We've only started, but so far results are encouraging...

Paolo

[bioform]

I am working on a the requirements for a large system that includes the integration of several intenal systems (we control as PART of the solution e.g., constrained to use a particular COTS package for telephony.)

I am trying to decide the proper layer and role (aka slot) to be defined for these stakeholders.
If they were external systems, then they would be located in Layer 2 (Containing System) and be represented by the slot “Interfacing System',

SO

Should these internal systems be in Layer 1 (Our System) and be represented as specific roles under the Normal Operator, Maintenance Operator, and Operational Support slots?

OR
Create in Layer 1 (Our System) the equivalent of the layer 2 slot “Interfacing Systems” and named something like Interfacing Subsystems?

I can see some advantages to the first, but the second seems to me like a better approach.

Any thoughts? Of course there is really no “bad” choice here, but would like some opinions.

Thanks, David

[bioform]

Because of the number of systems that my current SUD interfaces with, I have modeled the external system actors s and the exteral user actors as two separate diagrams.

That pretty much wraps up my EA modeling approach to context diagrams.

I will need to, of course, model these external system interfaces from the requirements POV.

Anyone have any thoughts to share on that subject?