• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

J2EE patterns - Analysis or Design

 
Ranch Hand
Posts: 150
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
Ranch Hand
Posts: 313
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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 ]
 
Author
Posts: 93
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
Ranch Hand
Posts: 165
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
John,
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.

thanks
 
Consider Paul's rocket mass heater.
reply
    Bookmark Topic Watch Topic
  • New Topic