Books
in black and white
Main menu
Share a book About us Home
Books
Biology Business Chemistry Computers Culture Economics Fiction Games Guide History Management Mathematical Medicine Mental Fitnes Physics Psychology Scince Sport Technics
Ads

convergent architecture Building model driven J2EE Systems with UML - Hubert R.

Hubert R. convergent architecture Building model driven J2EE Systems with UML - Wiley publishing , 2002. - 289 p.
ISBN: 0-471-10560-0
Download (direct link): convergentarchitecturebu2002.pdf
Previous << 1 .. 81 82 83 84 85 86 < 87 > 88 89 90 91 92 93 .. 142 >> Next

In this chapter, the basic OPR concepts presented in Chapter 3 were used to structure the IT organization and to define the roles and responsibilities of workers in the context of concrete organizations. In addition, the artifacts created by these workers were specified along with any specialized tools these workers use to produce and manipulate these artifacts.
The reference IT organization may be used as a basis to prepare IT organizations, large or small, to consistently produce systems according to the Convergent
-154-
Convergent Architecture Chapter 5: The IT-Organization Model
Architecture. It also sets the stage to present the process—the specific flow of activities between workers, tools, and artifacts. This flow of activities within the IT organization is the focus of the process model in the next chapter.
-155-
Convergent Architecture
Chapter 6: The Development Process
Chapter 6: The Development Process Model
Overview
The preceding chapter addressed the design of the information technology (IT) organization. This chapter will focus on the development process model, also referred to as the Convergent Architecture (CA) process, that complements and leverages the responsibilities, workers, and artifacts of the IT organization. This is the third and last component in the development model of the Convergent Architecture.
The existence of hundreds of books covering the software process is clear evidence of the central importance of this process in professional software organizations. Although there is ample discord—with a touch of religious fanaticism—as to which precise approach is best, many of the modern methodologies exhibit more similarities than differences. Their principal differences lie in the structure of their presentation, their weighting or emphasis of particular process aspects, and their scope. Indeed, there is no precise definition of where process begins and where it leaves off. This is why the Convergent Architecture sees process as just one aspect of a holistic approach that addresses the three pillars of project design, business design, and system design.
The CA process is not yet another generalized development process or methodology. As you will see in the following section, the CA process refines aspects of existing methodologies. However, instead of taking a process-centric approach, it takes a style-centric approach: It considers process in the context of the rest of the architectural style. By doing this, features of the architecture can be tuned to assist each other in all directions. This is in stark contrast to many methodologies that expend considerable effort trying to make things work together that were not designed to work together. In other words, in the development of the CA process, two questions are of main concern. First, how can the CA process help us achieve our style-specific goals using the other features of the style—the organization model, the convergent component metamodel, the architectural integrated development environment (IDE), and so forth? Second, and most important, how can the other features of the style help us simplify the CA process? The answers to these questions results in a continuous fine-tuning from the perspectives of both the development process and its surrounding environment. Such comprehensive optimization from various perspectives enables efficiencies and synergies not possible from a unidirectional, process-centric perspective. This multidirectional tuning contributes to what I call reference-frame continuity, an intrinsic property of the architectural style: Every project benefits from it automatically and immediately.
Before moving into the details, let's look at one example of reference-frame continuity and how it simplifies the CA process. A good example is the interaction between the modeling style and the architectural IDE, which, although not themselves part of the CA process, are part of the style. As such, they are a dependable part of a reference frame that can be leveraged by other parts of the style. In this particular example, the architectural IDE and the modeling style combine forces to simplify several workflows, thus simplifying the CA process. Based on the modeling style, the IDE can actively assist the developer through many activities.[1] In many situations, the developer only needs to set a few key
-156-
Convergent Architecture
Chapter 6: The Development Process
properties in the model to enable the IDE to automatically derive other models and properties. These derived design features are later used by the IDE to generate source code, also according to the modeling style. In such cases, the developer can be successful without having an expert background and/or having extensive experience with these activities. For example, during accessor development, complex design mechanisms such as user event dispatching or the interaction between the frames of an Internet representer are now carried out in the context of assisted modeling. As such, these aspects no longer need to be handled in the workflow description. They are delegated to the style-specific IDE. This new level of assistance and automation constitutes a logical step toward higher design capabilities similar to the improvements brought about by third-generation compilers. Just as no other development processes would describe the internal workings of a compiler as part of the workflow, the workflows of the CA process do not need to cover the aspects handled automatically by its architectural IDE. From the perspective of the developer, the complexity disappears (without being ignored by the architecture), and this aspect of development becomes a simple step in the workflow description.
Previous << 1 .. 81 82 83 84 85 86 < 87 > 88 89 90 91 92 93 .. 142 >> Next