Domain model vs. Analysis model vs. Design model - Help!

Domain model vs. Analysis model vs. Design model - Help!

Post by Marc D'Aous » Sun, 18 Mar 2001 01:26:47





Quote:> Folks,

> In Rational Unified process each stage of the development results in a
> model. How to move from Domain model to Analysis model to Design model
> using Rational Rose? For example, should we place all the classes
> generated during the Analysis into Use Case View and during Design -
> into Logical View? Or should we start with each model "from scratch",
> with a clean slate?

> Also, how do you resolve names, e.g. you have "Flight" entity in you
> business model and "FlightEJB" bean with Flight interface in your Design
> model? Or you have "Customer" actor and "Customer" entity? What is the
> recommended strategy?

> Thanks!

> Michael Misha Shengaout

Michael,

If I understand correctly, your problem involves structuring your rose
model, and flowing from one model to the other; from the use case model, to
the analysis model, to the design model.

For an example of how to structure and RUP project using Rose, you can
create a new project, and select the RUP template that comes with Rose.
You'll notice is uses something called Realizations (use cases with dashed
lines). Realizations are a mechanism that allows you to maintain
traceability across your models. They allow you to make the "link" between
the model.
In a nutshell, using them goes something like this,

You begin by working on your use case model, documenting the requirements of
the systems.
You prioritize the use cases
You move into the analysis model, and create a Use Case Realization that
traces to a use case in the use case model
You create the business objects, collaborations, state diagrams, etc ..
associated with that use case.
You move into the design model, and create a Use Case Realization that
traces to an analysis model realization.
You create the class diagrams, sequence diagrams, etc ... associated with
that use case.

This whole process allows you maintain traceability in your project. i.e.:
you can trace a design class all the way to the requirement(s) that was
create to fulfill.

You can use traceability to help solve your other problem as well. The
FlightEJB interface can  "trace" to the Flight entity. As for having 2
classes with the same name, it's not a problem if you manage it the
traceability properly.

Hope this helps,

Marc D'Aoust

 
 
 

Domain model vs. Analysis model vs. Design model - Help!

Post by Michael Misha Shengaou » Sat, 17 Mar 2001 08:55:33


Folks,

In Rational Unified process each stage of the development results in a
model. How to move from Domain model to Analysis model to Design model
using Rational Rose? For example, should we place all the classes
generated during the Analysis into Use Case View and during Design -
into Logical View? Or should we start with each model "from scratch",
with a clean slate?

Also, how do you resolve names, e.g. you have "Flight" entity in you
business model and "FlightEJB" bean with Flight interface in your Design
model? Or you have "Customer" actor and "Customer" entity? What is the
recommended strategy?

Thanks!

Michael Misha Shengaout

  mshenga.vcf
< 1K Download

 
 
 

Domain model vs. Analysis model vs. Design model - Help!

Post by Michael Grob » Sat, 17 Mar 2001 21:59:36



> This is a multi-part message in MIME format.
> --------------4919DBDDD69DA7ADFB85E58D
> Content-Type: text/plain; charset=us-ascii
> In Rational Unified process each stage of the development results in a
> model. How to move from Domain model to Analysis model to Design model
> using Rational Rose? For example, should we place all the classes
> generated during the Analysis into Use Case View and during Design -
> into Logical View? Or should we start with each model "from scratch",
> with a clean slate?

An analysis model and a design model are both logical views of the
system.  The RUP model template shows this structure

Logical View
 |
 +-Analysis Model
 |
 +-Design Model

Here is what I have used in the past.  Actors go in the Use Case View.
Analysis classes go in the Analsis Model package and design classes go in
the Design Model section.  That is assuming you have benefit by keeping
the analysis model around and not simply evolving it to a design model.
If you expect a benefit, you have to be ready to maintain those separate
models when your requirements change.

Quote:

> Also, how do you resolve names, e.g. you have "Flight" entity in you
> business model and "FlightEJB" bean with Flight interface in your Design
> model? Or you have "Customer" actor and "Customer" entity? What is the
> recommended strategy?

By placing the different objects in different packages, you don't *have*
to resolve names.  Sometimes turning on visibility will help (e.g. you see
"(from <parent package>)" on your diagrams.  This doesn't always help if
your package names are the same in the analysis and design models.  You
could use stereotypes (i.e. the analysis classes keep the "boundary"
"entity" "control" stereotypes while the design classes don't).  Or you
could adopt a naming convention.  A naming convention would be my last
choice.  I want meaningful names for my entities and if a concept is valid
in the problem domain and solution domain, I would want to keep the same
name.

In some models, we have copied the actors from the use case view down to
the design model.  We needed to add significant detail to the actor
methods in the design model that didn't seem useful in the use case view.

Hope this helps.

Michael Groble

 
 
 

Domain model vs. Analysis model vs. Design model - Help!

Post by Patrick Loga » Sat, 17 Mar 2001 14:58:13




Quote:

> In Rational Unified process each stage of the development results in a
> model. How to move from Domain model to Analysis model to Design model
> using Rational Rose? For example, should we place all the classes
> generated during the Analysis into Use Case View and during Design -
> into Logical View? Or should we start with each model "from scratch",
> with a clean slate?

However you do it, do it in very small increments. I would recommend
allowing you and your team the benefit of "starting from scratch" with the
design. Whether or not you have a "domain model", you should have a
business person or team that has a pretty clear understanding of what
they want, or a tolerance on both the business and development sides
to build up that business knowledge. I would recommend this approach
to RUP:

http://www.objectmentor.com/publications/RUPvsXP.pdf

Quote:> Also, how do you resolve names, e.g. you have "Flight" entity in you
> business model and "FlightEJB" bean with Flight interface in your Design
> model? Or you have "Customer" actor and "Customer" entity? What is the
> recommended strategy?

You will find various recommendations. Mine may not be common, but I
believe in it, and it is based on experience and observation. The only
approach to EJB I find useful is to use purely stateless session beans. In
fact I recommend not using EJB at all, but if necessary (e.g. to fulfill a
business/political commitment to use EJB) just stick to stateless session
beans.

Build the object model in plain old Java classes. This is easier, more
flexible, and less dependent on a technology that has very little
benefits but a significantly higher cost.

--
Patrick Logan

 
 
 

Domain model vs. Analysis model vs. Design model - Help!

Post by Michael Misha Shengaou » Sun, 18 Mar 2001 00:31:00


Dear Michael,

Thank you very much for the reply. It was most helpful. Could you tell me
please which CASE tool you used? Rational Rose doesn't seem to include the
stereotype into the name resolution, and this approach seems to be the most
appropriate...

Thanks again,

Michael Misha Shengaout



> > This is a multi-part message in MIME format.
> > --------------4919DBDDD69DA7ADFB85E58D
> > Content-Type: text/plain; charset=us-ascii
> > In Rational Unified process each stage of the development results in a
> > model. How to move from Domain model to Analysis model to Design model
> > using Rational Rose? For example, should we place all the classes
> > generated during the Analysis into Use Case View and during Design -
> > into Logical View? Or should we start with each model "from scratch",
> > with a clean slate?

> An analysis model and a design model are both logical views of the
> system.  The RUP model template shows this structure

> Logical View
>  |
>  +-Analysis Model
>  |
>  +-Design Model

> Here is what I have used in the past.  Actors go in the Use Case View.
> Analysis classes go in the Analsis Model package and design classes go in
> the Design Model section.  That is assuming you have benefit by keeping
> the analysis model around and not simply evolving it to a design model.
> If you expect a benefit, you have to be ready to maintain those separate
> models when your requirements change.

> > Also, how do you resolve names, e.g. you have "Flight" entity in you
> > business model and "FlightEJB" bean with Flight interface in your Design
> > model? Or you have "Customer" actor and "Customer" entity? What is the
> > recommended strategy?

> By placing the different objects in different packages, you don't *have*
> to resolve names.  Sometimes turning on visibility will help (e.g. you see
> "(from <parent package>)" on your diagrams.  This doesn't always help if
> your package names are the same in the analysis and design models.  You
> could use stereotypes (i.e. the analysis classes keep the "boundary"
> "entity" "control" stereotypes while the design classes don't).  Or you
> could adopt a naming convention.  A naming convention would be my last
> choice.  I want meaningful names for my entities and if a concept is valid
> in the problem domain and solution domain, I would want to keep the same
> name.

> In some models, we have copied the actors from the use case view down to
> the design model.  We needed to add significant detail to the actor
> methods in the design model that didn't seem useful in the use case view.

> Hope this helps.

> Michael Groble

  mshenga.vcf
< 1K Download
 
 
 

Domain model vs. Analysis model vs. Design model - Help!

Post by Robert C. Mart » Sun, 18 Mar 2001 00:39:02


On Thu, 15 Mar 2001 18:55:33 -0500, Michael Misha Shengaout


>This is a multi-part message in MIME format.
>--------------4919DBDDD69DA7ADFB85E58D
>Content-Type: text/plain; charset=us-ascii
>Content-Transfer-Encoding: 7bit

>Folks,

>In Rational Unified process each stage of the development results in a
>model.

Not quite.  Each stage of development results in progress in *all*
models, including implementation.

Quote:>How to move from Domain model to Analysis model to Design model
>using Rational Rose?

There is no automatic way to do this, nor should there be.  You build
these models to help you conceptualize and record your analysis and
design decisions.  There are no automatic transforms from one to the
other.

Remember, too, that models aren't required.  You create models only
when you know you need them.  If you create models because "it's part
of the process" then you are missing the point.  You create models out
of need, not out of duty.

Quote:>For example, should we place all the classes
>generated during the Analysis into Use Case View and during Design -
>into Logical View? Or should we start with each model "from scratch",
>with a clean slate?

You evolve each different model concurrently with all the others.
Entities that appear in the analysis model (if you bother to create an
analysis model) do not necessarily need to appear in the design model
(if you create a design model).

Quote:>Also, how do you resolve names, e.g. you have "Flight" entity in you
>business model and "FlightEJB" bean with Flight interface in your Design
>model? Or you have "Customer" actor and "Customer" entity? What is the
>recommended strategy?

Sounds to me like you are fighting your tool.  If you are having name
clashes, then put the different models in completely different
repositories.