Mapping views and model structure question

[shaft]

Does anyone know the appropriate way to map views in EA?

For example, a sequence diagram implements a use case. You could place the sequence diagram below the use case, but the general notion of views says that the sequence diagram goes in the dynamic view, and the use case diagram goes in the use case view.

So what is a good method of mapping diagrams/entities, while still keeping diagrams/entities in the appropriate views.

-Jeff

[TrtnJohn]

I like to keep only 2 views if possible.  So, I put all of my sequence diagrams as children under the actual Use Case.  I only use the dynamic view for common interactions that are referenced in many different sequence diagrams.

[thomaskilian]

There have been lots of discussions about the best projevt view with EA. The common sense is that there is no common sense. Some guys (like me) do not use any of the views in the way Sparx suggest (the post I'd like to reference got lost in the öast YABB-crash). Just feel free in inventing the best way for your need.

[shaft]

Just funny that every architecture book talks about the different views, and that the views should map and overlap.  However, I've never seen any documentation on a good way to do that using a tool.

[Paolo F Cantoni]

Just funny that every architecture book talks about the different views, and that the views should map and overlap.  However, I've never seen any documentation on a good way to do that using a tool.

That's because in theory, theory and practice are the same.  In practice they often aren't...

I'm with Thomas on this.  NONE of my models look anything like the default or any other prescribed structure.

Following Christopher Alexander (the originator of pattern languages) when you find the right setup for you  -it will feel right...

HTH,
Paolo

[Paolo F Cantoni]

Further to my last post, since I'm now emitting EA models to an XML representation, I've started to investigate views more deeply...

This begs the question, what [b]is[/b] a View?

Well, a View is NOT a UML concept.

The EA help Glossary defines:
view      A projection of a model, which is seen from a given perspective or vantage point and omits entities that are not relevant to this perspective.  

view element  A view element is a textual and/or graphical projection of a collection of model elements.

view projection  A projection of model elements onto view elements. A view projection provides a location and a style for each view element.

So, it would seem that views ought to be, principally, collections of diagrams that render specific views of the model - whose items are held elsewhere.  (Unfortunately the elsewhere is another view... )

It could be argued that if an item ends up appearing n only one View, then it ought to be resident in that view.

Other than that, one structure would appear to be as good as any other...

In my experience, it has been best to group items by their various functionalities.  Thus it could be argued that view groups around high-level "essential use cases" might be a viable approach.

Just some thoughts,
Paolo

 

[Paolo F Cantoni]

And while we're at it...

Conceptually, shouldn't we be able to have Views within Views?

Paolo

[sargasso]

Views within views? Yes, they're called "committees".

Seriously, views seem to have crept in from RUP perhaps.  maybe they're not strict geUMLischtliet but they are useful.  EA is great at handling views.  IMO the best tool around for it.

Somewhere else I wrote about the different blueprints used in a skyscraper - the builders, the electricians, the plumbers etc.  Each one may contain elements from the others and each trade knows what the symbols mean and how those symbols affect their problem - or more exactly, their "view" of the problem.

The four views I use are Requirements, Analysis, Design and Deployment.  They seem to work reasonably well in all (most) of the projects I have been involved in.  All four are, unlike RUP, not tied together by use cases but by an inward "flow" from the views towards a common structure in the Design view.

Requirements has got context, stakeholder, actor, business object, business process, requirement, use case and preliminary UI packages in it - stereotyped as "models".  The BOM, use case and UI elements tend all to reappear in the Analysis view which has 3 models logical behaviour, analysis (conceptual) class model and optionally conceptual state and sequence models.  Note that now we have distilled the problem down to two streams - the structural and the behavioral.
Next we could take the architect's view or the builder's view -  depends on DOW etc.  If architect, deployment view  takes the conceptual structure and builds or decides an attractive and functional component model. (and if we actually want to install the result as well as just build it we might include a deployment model.  The builder on the other hand rips right into the persistence, class and state/sequence models (hopefully based on the analysis and deployment models).

anyway , that's my view....

bruce

[vidafo]

@Bruce

I try to do the same approach but I wonder if there's a way to do some transformation from Analysis to Design.

How do you manage your views? Is there a transformation from Analysis to Design or do you simply create new classes in the Design View?

TX
daniele

[thomaskilian]

Daniele,
my 0.02€: I have changed the project structure several times and now have three main views: CIM, PIM and PSM where I find (more or less) the views bruce noted. The CIM contains requirements, use cases, actors, stakeholders - the project definition. The PIM contains use case realizations (collaborations) and the domain model - an abstract model. The PSM contains the class model and the deployment - physical things for real hardware. The steps from CIM to PIM are pure brainware. You need to design your domain with the help of an architect. The steps from PIM to PSM can (and should) be assisted by model transformations which can create concrete classes out of your abstract domain model. Model transformation is quite new and there still is no official standard. However, EA offers it and it works fine. Take the time to learn more about model transformation by reading EA's help and searching this forum.

[sargasso]

OK.  First, I don't equate views with progress,  there is a natural flow from desire to concept to reality (and beyond!) of course, but depending on the client and their desired methodolody, the problem and solution domains and the project dynamics the actual flow from go to woah is always slightly different.  Its a bit like pouring water down a rough inclined plane - it will end up at the bottom of the slope and it will follow the physical laws, but both the actual track of each water molecule and the order in which they end up in the resultant puddle are indeterminate.
This is where the power of views comes in.  They merely act as the "final" resting place (read structured puddle) for the solution information. When and how each element of the solution arrives at its destination is not predicatable.  Ergo I eschew (seeing we're being classical today) the idea of "migrating" or "transforming" elements between views.
Let me give a practical example, that damned "Log In" use case again.
Starting with the (malformed) requirement "the system should validate user access" as expressed by the stakeholder we just add it to the Requirements view as is, with the relevant referencing information.  Then we tie the stakeholder down on a bed of red ants in the the nearest desert and extract what they really want...  "the system shall only allow access to its functionality to a person belonging to a registered list of such people.  In order to validate that the person using the system is an authorised person, a system of ID/password matching should be used.  In addition all activities invoked by the person during the period they are logged in that result in updates to the corporate information stored by by the system should e logged in order to provide an audit trail."
Now we can start the analysis, design and construction of a solution to the requirement.
First thing I do is to create a new package in my "WIP" view that will be the scratch pad for all the following work on this requirement.  Now lets see, looks like we need a "Log In" use case that will realise the validate the person part of the requirement.  I know this is not a well formed use case from the POV of you Cockburn fans out there but it will do to start with.  What's the best case outcome?  The person using the system is recognised, granted access to the functionality and their ID is remembered for use in audit logging.  Shove that in as a scenario and ...  not to bore you ... so all the currently known scenarios are created.
Now, in my WIP diagram I've got a usecase and an external requirement and a realisation link.  Now I reckon that this use case will involve some sort of UI so I also add an empty screen element to the diagram.  Then I gather all the stakeholders together in a circus tent and get their input into the use case.  Let's say we emerge with the following:
1) new requirement - a person can only be logged in to the system at one one node at a time.
2) display requirement - the user ID must be entered i.e. no list of known users is to be displayed
etc etc
Also probably the UI might be a bit fleshed out- a couple of text boxes and two buttons (OK and Cancel)!

Now, new requirement  1 looks like we may need a controller element in the model that can achieve this result, so this gets added to my WIP diagram.

etc etc etc.

At various points in the game certain components of the solution become fixed (read "agreed") at tghat point I move them (or get the solution owner to move them into the correct slot in the repository views.  My WIP diagram remains the same its just that the elements that have become concrete have moved into their resting places.  When my final work on this bit of the solution is complete, the WIP "log in" package should be "empty" apart from the diagram and perhaps some leftover garbage that is not part of the solution.  Finally, during the game I may (will) have created other diagrams being the formal representation models that go into the proper views like the elements.
Voila - no "transform" between the formal structure views is needed - it all happens in WIP and if it "aint the answer" the formal model is not disturbed.

I suppose in summary that what I'm preaching is to create an extra view (or views or even another root item) called WIP and use it as a whiteboard until the "answer" can be put in its correct spot in the final puddle at the bottom of the slope.

hth - as it has helped me!

bruce

[TechWriter]

...The four views I use are Requirements, Analysis, Design and Deployment....Requirements has got context, stakeholder, actor, business object, business process, requirement, use case and preliminary UI packages in it - stereotyped as "models".  

Hi!  Can you elaborate on the difference between context and business process?  What would you expect to see in a context package compared with a business process package?

Also, I'm hoping to get a clearer understanding of when to use stereotypes.

Thanks!

[sargasso]

The way I use it, the Context model is an abstract high level view (sic!) of the system in its target business environment.  What I am trying to determine (or communicate) through this model is the system boundary  that will be used in the rest of this repository (or project root).

As explored elsewhere (ref???) system boundaries can often be confused.  One persons understanding of the boundary is not quite the same as someone else's.  The result of this can occassionally be catastophic.  A typical example being where stakeholder A's view is that a business level feature of the system is clearly within the ambit of the project, but the project's view is that it is clearly some other project's responsibility.  Result?  Feature is not considered in the project.

Similarly, system boundaries can sometimes be unclear in themselves.  An example (excuse me Paolo) is Paolo's code emitter.  Is the executable code within or outside that boundary?  For that matter, is the source code within or outside?  

So, the context model is simply a "stake in the ground" that is used either to gain agreement on the boundary or as a reference point for problem solving (in which case I may have several context's in play in the WIP until the final is decided).

As regards business process model, I've tricked you here with double plurals.  A project, IMV, may have multiple BPM's.  BPM's could be at any number of levels.  The set of BPM's in a particluar repository may not necessarily represent the entire set covered by/provided for by the system - just those of interest, those that needed exoplanation, formalisation etc etc.  Again, I have stuck them in my "Requirements" view as they seemed to fit here better than elsewhere and from my POV better than as a separate view =- others may difffer.

What's in them?

BPM's - I use Eriksson-Penker in the majority of projects.  This is because I just want to see the major effects and roles involved.  This tends to validate the completeness of the use case model.  Sometimes, I may break the BPM down to activity diagrams - or possibly multiple activity diagrams if I want to explore/present alternatives.  Typically, these are just "skeleton" models, the actual models and elements contained are not fully detailed.  Typically, just the diagram is required.

Context - A bit more difficult - short answer - it depends  
Probably the only guideline is that it tends to contain real world IT objects (nodes and components), people, processes, etc etc and a single boundary elelment.

hth
bruce