This chapter is from the book
This chapter is from the book
This chapter is from the book
The Architectural Process
As we saw in Chapter 2, the architectural process is complex, requiring a mix of object-oriented analysis, requirements gathering, project management, and technology evaluation. As an architect, you are truly a jack of all trades. The process we detailed in Chapter 2 is as follows.
Perform initial requirements gathering.
Create abstract definition of system.
Identify nonfunctional requirements.
Identify high-level components.
Refactor component design and group components by tier.
Identify software technology required.
Identify hardware required.
Create deployment diagrams, component diagrams, and other documentation to describe the system architecture.
In the end, we would like the architecture and its supporting documentation to articulate the structure of the system and identify the components that comprise it and their interactions. Subsystems should be used to reduce coupling and clarify interactions.
Scattered throughout several of these steps, primarily steps 1, 3, 4, and 7, is the need to adequately document the analysis and design process with diagrams. A variety of diagrams may be used to show the components, their interaction, the security requirements, and the flow of information through the system. Fortunately, there is a core set of diagrams that represents something of a standard in OOAD. Before we can have a detailed discussion of J2EE architectural process, we must identify a core set of diagrams, our facility for communicating, and discuss how they should be used.