This week's book giveaway is in the Jobs Discussion forum.
We're giving away four copies of Java Interview Guide and have Anthony DePalma on-line!
See this thread for details.
The moose likes EJB and other Java EE Technologies and the fly likes J2EE patterns - Analysis or Design Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login

Win a copy of Java Interview Guide this week in the Jobs Discussion forum!
JavaRanch » Java Forums » Java » EJB and other Java EE Technologies
Bookmark "J2EE patterns - Analysis or Design" Watch "J2EE patterns - Analysis or Design" New topic

J2EE patterns - Analysis or Design

Fintan Conway
Ranch Hand

Joined: Apr 03, 2002
Posts: 141
Hi All,
At present when we are doing analysis we try to break down the classes in our use cases into data entities, boundary objects and controller objects, i.e. apply the MVC pattern in analysis.
Are the J2EE patterns applied in the design phase - when we split these classes into more fine-grained classes, or could be use some J2EE patterns in the analysis phase? Perhaps instead of MVC pattern?
Byron Estes
Ranch Hand

Joined: Feb 21, 2002
Posts: 313
I think it all depends how you define your phases and what goals you want to achieve from each phase. This makes your question more of a methodology issue then anything else and the answer will vary depending upon the industry standard or custom methodology you actually use.
Without the methodology, here's my two-cents...
Definition should ONLY deal with understanding the business problem from the users point of view. You are establishing the scope and domain of the problem you will solve.
Analysis should be of the current environment. This may involve systems, networks, processes, etc... They key word however is CURRENT. Analysis is for existing state not future state.
Design can involve both business design and techincal design. This where we start looking at what will be not what is and is where most pattern work will be employed. Note: If you are working with existing systems that exhibit/employ particular patterns, then that information might apperar/be discussed in your analysis.
Construction, Testing and Implementation/Deployment are more self-explanatory.
Different methodologies break up these steps in different ways, give them different names, and are executed differently (e.g. waterfall, iterative, etc.) but at their essence they are all fairly similar.
I hope this clarifies where patterns (in my option) are considered in the course of a software project.
[ October 02, 2002: Message edited by: Byron Estes ]

Byron Estes<br />Sun Certified Enterprise Architect<br />Senior Consulant<br />Blackwell Consulting Services<br />Chicago, IL<br /><a href="" target="_blank" rel="nofollow"></a>
John Carnell
Ranch Hand

Joined: Sep 27, 2002
Posts: 71
Hi Fintan,
I usually look at my projects from an iterative point of view. I start with the requirements and analysis. I try not to color my view with any pre-conceived notions of how technology can solve the problem.
Once I get a good feel for the business requirements (I usually like to go for an 80% understanding), I begin looking at design.
I begin looking at the overall design at a "macro" level. This is where I look how I am going to partition the application so that each tier in cleanly separated from one another. This where the J2EE Design Patterns really are applicable. They allow you to split the prospective application into distinct tiers and abstract away implementation details of each tier. Think of the J2EE Design Patterns as being the "plug-in" points for your code that does the real work. Your architetcure should be such that you can swap in and out application functionality without creating tight dependencie between your application architecture and your application business logic.
Once I have defined my macro level architecture I started diving down into developing a class model, sequences diagrams, etc... for the individual pieces of my application. At this level you really can start applying the more "micro" design patterns. I find these are usually the GOF design patterns and that I use them solve very tightly focused problems.
I hope that answers your question. I tend to get a little incoherent this late at night :,>
John Carnell

John Carnell<br />Principal Architect<br /> <br />Netchange, LLC<br />1161 HillCrest Heights<br />Green Bay, WI 54313<br /> <br /><br /> <br /> <br />Author of <a href="" target="_blank" rel="nofollow">Pro Jakarta Struts, Second Edition</a>
Manas Ahlaad
Ranch Hand

Joined: Nov 07, 2001
Posts: 165
any references to what you said. i mean any sites which actually describe internal of design
where does sequence diagram come into picture , where does class diagram ,where does patterns fit.


Manas<br />Today If You are not Confused,You are just not thinking Clearly !<br />---------------------------------
I agree. Here's the link:
subject: J2EE patterns - Analysis or Design
jQuery in Action, 3rd edition