JCEA Part 1: Design Patterns
Leo Crawford | Work | JCEA | Part 1 | 1. Concepts
 

Contents
  1. General
  2. References
  3. Syllabus
    1. Concepts
    2. Common architectures
    3. Legacy connectivity
    4. EJB
    5. EJB Container model
    6. Protocols
    7. Applicability of J2EE
    8. Patterns
    9. Messaging
    10. Internationalisation
    11. Security
  4. Reference
    1. UML
  5. Resources
  6. Further Tips
 
 

Syllabus
This section is not listed in the syllabus, but was part of the old syllabus. I choose to include it for as it may be useful.
 

Questions
  1. Describe the duties performed by a Java Architect.
    1. An architect of Java applications needs to be business-aware as well as technology-aware. An architect may be called in to advise management on how to take an existing system to production status, or to define requirements for a new system, or to develop a project plan which might include recommendations for training and mentoring the customer's staff.
    2. The customer may have already produced a proposed architecture and simply want the architect to lend his expertise in evaluating it.
    3. Java architects may be involved at all stages in the development lifecycle, although will generally not actually do the coding himself.
    4. There are obviously constraints on the architecture which may be employed in any situation. These might include:
      1. The customer's existing systems (including legacy data, infrastructure etc)
      2. The network bandwidth
      3. The customer's budget, skills of the customer's development staff etc
      4. Security requirements
  2. State how Java architecture design fits into the application development lifecycle.
    1. Java architecture design fits in between object-oriented analysis and object-oriented design.
    2. A good architecture should involve the creation of a robust solution, which is scalable, preferably portable (clearly the platform independence of Java fits in here), performs well, is well documented, and is successfully integrated with any existing system and/or data.
    3. The types of diagram which an architect may produce are class diagrams, UML package diagrams, dependency diagrams and UML deployment diagrams. Other UML diagrams may also be used for example sequence diagrams or collaboration diagrams.
 

Links
none
 

Observations
  • Concepts cover the role of an architect, non-functional reqyuirements (performance, scalability, reliability, availability, extensibility, manageability, maintainability and security) and UML.

Page created by Leo Crawford
last updated in June 2002