Basic Question on OOAD

> After going through the book ,UML Distilled,and some

> other sites, i struck with some doubts. The major

> concerns are

An excellent book, Fowler is world renowned expert in this field. Checkout his web-site it contains a lot of additional material.

> 1. Regarding the steps or sequence of OOAD model .For

> the OOAD approach,I assume that the steps to be

> followded are i) Usecase ii) Problem domain

> identification iii) Sequence Diagram iv) Class

> diagram.(I am talking about a medium sized

> project).But in some sites the approach is a little

> bit different.Which is the right kind of approach?

The stages of any process vary considerable in practice, between organisations, teams, individuals, even projects.

It's really upto the [team|project] leaders to define the deliverables required, and good leadership will guide/mentor you through that process, however if you are that leadership, then experience/practice is the key...

Consider UML as a collection of tools/techniques, not a single process. Consider what each part of the process provides, not as deliverables, but in deconstructing problem. Decide if you need that stage in this instance.

I find that a light weight process with strongly forced iteration, works for me. During each iteration, I add detail, I don't tie my team to delivering every document in every iteration, but as the project develops it results in most of the documents showing up by the end. Now some of those iterations may be limited to the domain, some may include all steps, but regular iteration, and constant refinement is the key, to making UML work well.

> 2. If this is the sequence , where the architecture

> analysis/sub system identification fits. ?

This is a higher level process, that may not even exists in the beginning but emerges as you iterate. In a classic J2ee project, My first iteration might be a basic Servlet returning a JSP, my next iteration might include JNDI services, then a session bean, an Entity EJB, and so on. Typically the architecture emerges in more detail with each iteration. In the next project I may stick with the same architecture, or develop a new one. Architecture is almost a consequence of development/design process, it's not really the objective.

However experience often suggests an architectural approach for a project, before it's even begun. The so called Architechtural patterns. J2EE is an architectural pattern.

The sub-systems can be identified with Use-Cases. Each time a Use-Case uses the <<Uses>> stereotype, you've typically identified a sub-system, however again this is an area where experience typically identifies (many) of the sub-systems before you've begun, even during the feasibility stage.

> 3 .What is the conceptual model - is it the domain

> model or Functional model or Highlevel Technical

> Architecture ?

A conceptual model is exactly what it says a model of the concept (idea), it's highest level of abstraction. So for example 'client server' is a conceptual model, which might be implemented using the J2EE architectural Pattern, and using the the MVC Design Pattern. The specifics vary with each implementation, but the ideas remains the same.

> 4. In our old approach we are following a High level

> design (HLD)then a low level design(LLD).In this OOAD

> how one can map this ? What are the bountries ?

It's not a straight forward mapping, but broadly: A high level design broadly spans, the conceptual model to the domain level design. A low level design broadly incorporates every thing else, However, in OOAD and UML it's really an issue of the detail, and the split is arbitrary, you could use the same diagrams with more/less detail at different stages (iterations) of the process.

> 5. How do we map Domain classes to Design classes ?

This comes from the decomposition inherent in the iterative process of OO analysis and design.

Assume I identify a business rule called, Bob, now I know from experience that business rules are typically Session EJB's, so I create a stereotype, <<SessionEjb>>. My domain level diagram contains a Class Bob of stereotype <<SessionEjb>>. My knowledge of Bob tell me it is a composite of various other business rules, I can add these to the domain model, or if everybody knows (i.e. it's document in the requirements) I might choose to avoid that complexity at this state. This detail would certainly be present in a detailed design.

Assume this is my first <<SessionEjb>> identified. I should create a detail design for the <<SessionEjb>> stereotype, it implements the SessionBean interface, so I can add that detail. Session beans implement the SessionBean interface, so I add that and appropriate methods.

I can show that class definition as a stereotype or in detail, in my design.

> 5. The book UML distilled does not say anything about

> Entity Classes,Controller classes,Bountry classes and

> DataAccessor classes(Most of the OOAD talking ) .Is it

> because of the book discussed an alternative approch

> ?

No. These are typically examples of conceptuals models & design patterns, using the UML methodology, you need a patterns book(s), Sun's J2EE Core Java Framework is good for architectural patterns for J2EE systems and Design Patterns (Gamma et,al) is excellent for general design patterns.

> 5. Some of the books says that , When you design an

> object, everything regarding that object should be

> encapsulated by that class."ask the object to perform"

> (a customer should know all facts of a customer).if it

> is the case where do i add the methods like

> "findAllCustomers()" etc.

In a find(...) method of an AllCustomers class. So for example. MyApplication class, contains an AllCustomers class, which is a collection of Customers.

> Please review the statements and help me to understand a bit more.

Hope this helps.

MartinS. at 2007-7-1 23:57:32 >