Download (direct link):
■ Preparatory and cross-project workflows. These workflows are not
associated with any particular project. They are initiated before the first development project and act in a cross-functional manner across all projects.
■ Canonical project workflows. Similar to the canonical development
team presented in Chapter 5, the canonical project workflow describes the development process from the perspective of the canonical development team.
Each of these categories was described in terms of the workers involved, the results produced, and the tools used to achieve these results. In addition,
Chapter 6: The Development Process
guidelines were presented within each activity outlining the tasks carried out by each worker and the usage tools employed to support the tasks.
The development model is now complete. The next chapter provides detail on how the architectural IDE supports the development model. The final chapter presents a tutorial to show how all the parts work together based on a concrete example using the architectural IDE. In this example you will see how key features of the architectural style work together to provide tangible advantages in a real-world environment.
In addition, the bonus chapter on the Web site provides complete details of the technology projection component in the form of a reference manual.
Chapter 7: The Architectural IDE
Chapter 7: The Architectural IDE— Automating the architecture
The third and fourth main features of an information technology (IT) architectural style as realized by the Convergent Architecture (refer to Figure 1.1) are the full-coverage tool suite and the formal technology projections. The focus of this chapter is the tool suite.
In the previous chapters we saw how the architectural integrated development environment (IDE) plays a central role in supporting and simplifying various aspects of the Convergent Architecture. Up to this point, the perspective has been from the various topics of the development model. The support provided by the IDE was pointed out with respect to the local topic of each section. Although important, the local perspective does not present the overall picture of how all these things work together. This chapter takes a close look at the sum of the parts: the interdependence of the individual pieces. It also analyzes some aspects not covered from the local perspectives of previous chapters. These aspects include the integrative and flow characteristics of the architectural IDE that enable it to better support the architecture as a whole instead of only covering parts of a development flow. Figure 7.1 summarizes the coverage of the architectural IDE with respect to the Convergent Architecture (CA) process.
funni'in MnJyi tojtywHery
Figure 7.1: Architectural IDE: Critical path coverage. Covering the critical-path workflows.
The principal objective of the architectural IDE is to automate and assist the critical-path workflows in the context of the entire development model. In the figure, the critical-path workflows are shown as they progress with time from left to right. Situated below each workflow are major categories of artifacts that must be created, integrated, and manipulated during the workflows. Analyzing the figure, we can briefly summarize the requirements on the architectural IDE as follows:
Concerning business and requirements models. The T-bar business analysis and requirements workflow requires tools to easily record
Chapter 7: The Architectural IDE
and manipulate business structures and flows. The modeling activities in this workflow are highly interactive. Thus, the tool must help a designer to rapidly record and structure significant amounts of business information without hindering the dynamics of group-analysis sessions. The resulting models should then be equally valuable as a source of business information and for convergent refinement into software systems.
Concerning a common model repository. The business and requirements models should initiate a trackable thread of information and design refinement across all other workflows. To support this thread, both business and technical design information should be saved in a well-defined central format (Unified Modeling Language, or UML) or common model repository. This repository must be open to incremental exchange and integration at any time with other tools (XMI/XML, open Java API).
Concerning UML design models. The creation of UML models according to the analysis-by-design workflow should proceed in an automated or assisted manner using the patterns defined by the architectural style.
Further automation should help the developer refine UML models according to the well-defined modeling style. This process of tool-assisted modeling should continue until the model is sufficiently complete to permit the automatic generation of all those aspects of a software system that can be reasonably represented in UML (as defined by the modeling style). To enable the generation of high-value artifacts, the tools must permit the developer to automatically verify and debug the UML model according to the requirements of the modeling style and the requirements of the target deployment environment.