Author Topic: How to structure a project when using packages (Read 14646 times)

phaase · « **on:** June 02, 2005, 03:48:54 am »

Hello,

in the EA user guide one can read:

The top level packages in EA are referred to as Views. This terminology is used simply to designate that the package is at the top level and may be used to subdivide a project into partitions such as Business Process, Logical Model, Dynamic View, etc.

Question 1: Isn't this definition contrary to the defintion of a view in the RUP?
Question 2: I want to use packages to structure my model. Is it preferable to place them within the views (and probably replace a package in different views), or is it preferable to place the packages on the top level and have within each package the different views?

Thanks in advance for any hint or suggestion.

Paolo F Cantoni · « **Reply #1 on:** June 02, 2005, 04:20:43 am »

Quote

Question 1: Isn't this definition contrary to the definition of a view in the RUP?

Hi phaase,

Can you post the definition of view in RUP that you are using?

And if the version of RUP you are using isn't the latest, can you check if the latest definition is any different.

That way, we can comment better.

Cheerz,
Paolo

phaase · « **Reply #2 on:** June 02, 2005, 04:50:40 am »

Hello Paolo,

on

http://www.maxwideman.com/pmglossary/PMG_V00.htm#View

you find:

'View:
A simplified description (an abstraction) of a model, which is seen from a given perspective or vantage point and omits entities that are not relevant to this perspective.'

Hence, as far as I understand, the complete model could not consist by views only. Rather the views are showing only some (from a distinct perspecitve interesting) aspects of the model. Hence, from my point of view, it should make more sense to have both the views and different models (e.g. design model) on the top level and do not include models within the views (as it is with the EA base model).

However, primary I'm interested in the way, other people organize their EA project when using packages (to not re-invent the same mistakes).

Greetings,

Peter

Bruno.Cossi · « **Reply #3 on:** June 02, 2005, 05:35:13 am »

Hello Peter,

it actually sounds to me that EA's Views do fit the definition you have posted. However, as you have full control over the set of views you choose to use, you can tweak it around whichever way you wish.
Also, the definition you have posted is not from RUP. And furthermore, I would much hope that EA does not blindly follow RUP no matter what :-)

Thanks,
Bruno

Quote

Hello Paolo,

on

http://www.maxwideman.com/pmglossary/PMG_V00.htm#View

you find:

'View:
A simplified description (an abstraction) of a model, which is seen from a given perspective or vantage point and omits entities that are not relevant to this perspective.'

Hence, as far as I understand, the complete model could not consist by views only. Rather the views are showing only some (from a distinct perspecitve interesting) aspects of the model. Hence, from my point of view, it should make more sense to have both the views and different models (e.g. design model) on the top level and do not include models within the views (as it is with the EA base model).

However, primary I'm interested in the way, other people organize their EA project when using packages (to not re-invent the same mistakes).

Greetings,

Peter

MichaelHanson · « **Reply #4 on:** June 03, 2005, 07:10:10 am »

I agree with Bruno, EA does not blindly follow or enforce any particular process, and you have total fexlibility over how you structure your views.

For example I follow the Microsoft Solution Framework (MSF 3.1) for my projects and structure the top level views in accordance with the phases of MSF

Envisioning
Planning
Developing
Stablising
Deploying

My only very minor criticism of the Views concept in EA is that you only seem to be able to add Custom views, it would be nice to choose the type so that you control the icon use to represent any top level View.

Mike Hanson

mbc · « **Reply #5 on:** June 03, 2005, 07:40:44 am »

Mike, I can select the icon myself, when I add a new view. I remember this feature was added some time ago. Which version are you using?

phaase, it is also possible to rename "Views" to something else, if the name is bothering you.

Best regards,
Mikkel

MichaelHanson · « **Reply #6 on:** June 03, 2005, 08:10:19 am »

Thanks Mikkel

You are right, I am using 5.0 766 but had not tried the feature for some time. I have a template project that I use which has the structure I use, but this was created intially with 3.* I think.

I obvioulsy didn't spot the mention of the new feature.

Mike

phaase · « **Reply #7 on:** June 03, 2005, 08:14:52 am »

Thanks for the great response.

Actually we are not going to follow the RUP process. I'm just a bit confused by the way the name 'View' is used by SparxSystems. In the EAExample project there exist two top level views, 'Model Views' and 'Other Views'. The 'Model Views' package/view contains Models (e.g. Requirement Model, Design Model, ...) while 'Other Views' contains Views. For me this seems to be a bit inconsistenly. One migth think that this is only an academic problem, but It's difficult for me to find argues when presenting my coworkers such an scheme. Therefore, and that's the point my question actually focused, I'm looking for some examples to structure an EA project (in particular when parting the project into different packages.) Maybe it's not only for me helpful if SparxSystem would offer (probably by the help of the user community) more model projects examples for different kind of projects.

Peter

mbc · « **Reply #8 on:** June 03, 2005, 08:19:08 am »

Peter, what you really need is to decide on a process. The process should have guidelines for how to structure your artifacts.

I could give you the outline that I am currently working on for a template project structure in my company, but if you don't follow the same process as us, this structure will not suit you.

Mikkel

phaase · « **Reply #9 on:** June 03, 2005, 08:29:39 am »

Mikkel,

actually we are in the process of reorganizing our development process. Therefore it would be helpful to see the solutions of other people. I would appreciate you sending me your template. (peter.haase at plath.de)

Thanks in advance, Peter

MichaelHanson · « **Reply #10 on:** June 03, 2005, 08:43:35 am »

Peter

I have been looking around for resources that might help explain the origins of the default structure in EA as I was sure that the UML specification defined the same set of views originally. I haven't read the spec lately but I vaguely remember reading somewhere that the views are no longer defined by the UML spec leaving that to the process.

Anyway I found this http://www.ulb.ac.be/di/rwuyts/INFO025_2004/04-UML-Overview.pdf which you might find useful in understanding the reasoning behind the EA default views.

When you are considering your package structure (at least for the physical model) you should consider the language in use, particularly if you use the code generation features of EA. For example my projects for the last few years have been targetted at the .NET platform with C# as the favoured language. The default behaviour of EA when generating C# code for you is to use the package hierarchy as the namespace hierarchy. Once you set a package as a Namespace Root all packages below that are considered a namespace boundary and code is generated accordingly.

Mike

phaase · « **Reply #11 on:** June 06, 2005, 07:36:10 am »

Mike, thanks a lot for that information.

I'll try to point out my problem by given a concrete example.

In the system to be developed, a subpackage is identified to handle received signal data. For the name of the package I choosed 'SignalProcessing'. Assuming I would use the view structure defined by the EAExample and I'm going to produce subpackage specific information related to both the 'Use Case View' and the 'Logical View' , should one:

1. include that subpackage within both the (top level) 'UseCase View' and the 'Logical View' (and hence repeat the definition of that package)

or should one:

2. make that subpacke a top level package and repeat within that subpackage the view structure, i.e. for this example repeat within that subpackage at least the used views 'Use Case View' and 'Logical View'?

Isn't there a standard way to handle such things? By myself I assume that the way to handle this shouldn't be much different for different processes.

Peter

mbc · « **Reply #12 on:** June 06, 2005, 07:41:12 am »

I think the answer is that you should not have the same kind of packages in the logical view and the use case view.

In the logical view, your packages are of an architectural sort.

In the use case view, your structure should be use case-oriented. Each use case will probably work across many different logical view packages. You may group your use cases in packages too, but they would not be the same packages.

Mikkel

phaase · « **Reply #13 on:** June 06, 2005, 08:15:46 am »

Mikkel, I follow your argumentation. But does this also hold for example for the 'Logical View' and the 'Component View'. For my understanding it makes sense to display both a class diagram and a component diagram for the same subpackage.

mbc · « **Reply #14 on:** June 06, 2005, 08:23:36 am »

I think it still holds, although maybe only part of the way.

The way I would try to structure my packages, each package would probably result in one component.

Of course, if you have a large system with packages of packages of packages, you might need packages of components. However, I would like to caution you against making a deep tree. That goes for your source file directories on your disk too. If you are able to keep your structure flat, you are making it more likely that you are making reusable components.

Mikkel

Sparx Systems Forum

News: