This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
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? Thanks, Fintan
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. Regards, [ October 02, 2002: Message edited by: Byron Estes ]
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 :,> Thanks, John Carnell
John Carnell<br />Principal Architect<br /> <br />Netchange, LLC<br />1161 HillCrest Heights<br />Green Bay, WI 54313<br /> <br />email@example.com<br /> <br /> <br />Author of <a href="http://www.amazon.com/exec/obidos/ASIN/159059228X/ref=jranch-20" target="_blank" rel="nofollow">Pro Jakarta Struts, Second Edition</a>