Book a Demo

Author Topic: Mix and Match Project Views - How  (Read 5627 times)

Paolo F Cantoni

  • EA Guru
  • *****
  • Posts: 8626
  • Karma: +259/-129
  • Inconsistently correct systems DON'T EXIST!
    • View Profile
Mix and Match Project Views - How
« on: May 24, 2006, 06:35:13 am »
This is a pretty strategic question for us.

We are currently, officially a Rational Rose (2003) shop.  However, I've now been using EA for a year and tried out a number of small projects with some success.

Business Context:  We provide relatively, to completely, bespoke solutions to large scale problems (in a specific, very large, application area) in numerous parts of the world.  The system we build for a customer in London (UK) will not necessarily look a lot like the one we build for Tokyo (Japan).

The current Rational Rose implementation creates a model per instance (which we call a Scheme) from an amalgam of .cat files - which could be considered to correspond to a project view node in EA.

However, analysis reveals that a better approach would be to separate the various models into groupings of packages by aspect (similar to Aspect Oriented Programming - AOP).  That is, each project (or Scheme) uses a particular technology, exists in a particular regulatory framework, is deployed in a particular geography, supports a particular business model (and so on...).  Many of these aspects are common between schemes - for example all the schemes in Scandinavia have a lot of commonality.

There was a proposal to create a matrix of .cat files:
Each package would be assessed as to which aspect it belonged to and then whether it was required in all schemes, multiple schemes or a specific scheme only.

Each scheme model would then be assembled from the set of .cat files that it required.

The .cat files are under source control.

Can I do something similar with EA?

Is it advisable?

Can I make changes to a package in one repository, check it into source control and check it out to another repository?

TIA,
Paolo
Inconsistently correct systems DON'T EXIST!
... Therefore, aim for consistency; in the expectation of achieving correctness....
-Semantica-
Helsinki Principle Rules!

Paolo F Cantoni

  • EA Guru
  • *****
  • Posts: 8626
  • Karma: +259/-129
  • Inconsistently correct systems DON'T EXIST!
    • View Profile
Re: Mix and Match Project Views - How
« Reply #1 on: May 26, 2006, 12:20:44 am »
No takers?

Insufficient information?

I would appreciate some feedback on this.

Paolo
Inconsistently correct systems DON'T EXIST!
... Therefore, aim for consistency; in the expectation of achieving correctness....
-Semantica-
Helsinki Principle Rules!

thomaskilian

  • Guest
Re: Mix and Match Project Views - How
« Reply #2 on: May 29, 2006, 05:24:00 am »
Actually I would be interested too in tha answer. I had no force to try this by myself so far and I'd like to save the effort in doing so.

jaimeglz

  • EA User
  • **
  • Posts: 164
  • Karma: +0/-0
    • View Profile
Re: Mix and Match Project Views - How
« Reply #3 on: May 29, 2006, 07:17:59 am »
Paolo:

I must begin by admitting that I don't understand very well what you are trying to do (and I don't understand at all what .cat files are); but, anyway, I would like to contribute a solution I have found useful for handling objects that are common to different projects.

1. Create an "Infrastructure" view package, with subpackages for metamodel elements (for instance, a class diagram for "objective", "problem", "resource"... ), and also for your home-made reusable components (classes, tables, whatever...), as well as commercially available components, hardware, and so forth. You can define your best-practices and reusable ensembles here (for  instance, your account, sub-accounts, cost center classes, their use cases, state charts...).

2. Create a general "Reusables" view package, for individual components that are not strictly part of your metamodel or your ensembles. You can include a "Dust bin" package here, so you can phase out elements instead of deleting them.

3. All your projects must have very similar high-level views and packages (requirements, business processes, use cases, database model, user interface model, architecture), even if they vary in detail.

4. Be sure your technology-independent conceptual (or "domain") model is kept up to date, so you have good "canonical" classes.

It seems to me that the challenge is much more logical (that is, a good hierarchy of reusables) than technological.

Hope this helps,

Jaime
« Last Edit: May 29, 2006, 07:19:30 am by jaimeglz »

thomaskilian

  • Guest
Re: Mix and Match Project Views - How
« Reply #4 on: May 29, 2006, 08:40:12 am »
Jaime,
what Paolo is aiming for is something different. .cat files in Rose are used for splitting up models. It's similar to a controlled package in EA. I used that also to distribute shared data and work between several people and projects. It was fairly easy to re-use .cat-files among different projcts. The question is: can EA provide the same technique (by using controlled packages) or are there any caveats?

Paolo F Cantoni

  • EA Guru
  • *****
  • Posts: 8626
  • Karma: +259/-129
  • Inconsistently correct systems DON'T EXIST!
    • View Profile
Re: Mix and Match Project Views - How
« Reply #5 on: May 29, 2006, 10:21:34 am »
Quote
Jaime,
what Paolo is aiming for is something different. .cat files in Rose are used for splitting up models. It's similar to a controlled package in EA. I used that also to distribute shared data and work between several people and projects. It was fairly easy to re-use .cat-files among different projcts. The question is: can EA provide the same technique (by using controlled packages) or are there any caveats?
Thomas is exactly correct!  That's what I'm looking for...

The issue is about the different projects evolving at different rates.  By using the .cat files (and source control - we use Rational ClearCase, so we can create "Views" to various lables) we can stabilise some projects at certain levels of models, and evolve others.  Later, when the stabilised projects can move on, they get the benefits of later improvements in the models.

Now,  as Thomas and I ask, can we do it as 'easily" with EA and controlled packages as the links between project based repositories?

How about it Sparxians?

Paolo
Inconsistently correct systems DON'T EXIST!
... Therefore, aim for consistency; in the expectation of achieving correctness....
-Semantica-
Helsinki Principle Rules!

Eve

  • EA Administrator
  • EA Guru
  • *****
  • Posts: 8110
  • Karma: +119/-20
    • View Profile
Re: Mix and Match Project Views - How
« Reply #6 on: May 29, 2006, 03:08:06 pm »
Yes, version controlled packages work well in this situation.  You'll just need to do a 'get latest' or 'get all latest' on the packages that have been updated for changes to be included in the current model.

Paolo F Cantoni

  • EA Guru
  • *****
  • Posts: 8626
  • Karma: +259/-129
  • Inconsistently correct systems DON'T EXIST!
    • View Profile
Re: Mix and Match Project Views - How
« Reply #7 on: November 05, 2007, 11:39:37 pm »
[size=13]Packages, Namespaces & groupings[/size] has additional, related information.

Paolo
Inconsistently correct systems DON'T EXIST!
... Therefore, aim for consistency; in the expectation of achieving correctness....
-Semantica-
Helsinki Principle Rules!