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 .. 109 110 111 112 113 114 < 115 > 116 117 118 119 120 121 .. 142 >> Next

Object Vicier
(JJ Hl1 ral 111! tir L' IJLL' nl
Ajvbftrtt
LTMÏ- Kennfmrdi AsflislftiH
Trju I <-l J I ivf
c.r nrr^m r jfe
■GcnfTiUcirtnr.
Ejn plrmeni,
I li'pkiv Hl Ih| rnvïrçinrnrnt
u Federated UMU XML Model Repository
Figure 7.7: Orientation of the C-RAS module.
-205-
Convergent Architecture
Chapter 7: The Architectural IDE
Figure 7.8: Pattern-based refinement.
-206-
Convergent Architecture
Chapter 7: The Architectural IDE
Figure 7.9: C-RAS-OPEN pattern example. With permission (Henderson-Sellers 1998, Fig. 2.3)
Figure 7.8 illustrates the refined state of the same model presented in the C-BOM section earlier. Here again, the hierarchy browser to the left of the figure shows the convergent components. When expanded, each component reveals its current state of refinement from the particular perspective of the C-RAS module. Note that the same business objects are still visible, but significant detail has been added. Each part of the CRC card for each convergent component is now displayed in the browser. In the figure, the account's responsibility for knowing/visible, "Know balance," is selected. To the right, in the work area, the results of this selection can be seen.
In the work area, an overview of the refined "Know balance" is shown. It can be seen that this responsibility has been mapped to an attribute and an operation, both residing in the default facet of the account component—an OPR resource component. Note that the facet is labeled with <none>. This manifests that the mapping patterns together with the J2EE-based modeling style understand that J2EE/EJB components currently only provide single interfaces. Facets are a component feature stemming from the CORBA component metamodel. They exist to support components with multiple interfaces, provided it is allowed by the
-207-
Convergent Architecture
Chapter 7: The Architectural IDE
modeling style (with its corresponding technology projection). In this case, the default J2EE/EBB projection is used. It is important to note that intelligent sensitivity toward the particular deployment infrastructure begins here. If the designer was allowed to model multiple interfaces, that is, facets, then the model could not be mapped cleanly (neither automatically nor by hand) to the intended J2EE/EJB infrastructures. By adding this constructive foresight, the developer is assisted in creating a model that can be used to effectively drive all downstream stages of development, many of them automatically.
The tabs at the top of the work area show how a developer refines a selected responsibility. Each tab presents the paths available for refinement according to the refinement patterns. One of these patterns is shown in Figure 7.9. This is the pattern for UML refinement of public/visible responsibilities from CRC cards in the business object model.
The pattern in the figure indicates that a public/visible responsibility for knowing, which corresponds to the currently selected responsibility, may be refined to visible operations or properties (attributes) of a component. When proceeding farther down in the pattern, it can be seen how these operations and attributes may be further refined. These refinement options are made available to the developer by the C-RAS for the selected responsibility. The developer then uses the tabs to create the required set of operations and attributes and to configure their details. Such details are, for example, the attribute's name, the operation's parameter list, or its preconditions and postconditions.
The lower part of the workspace provides directions and explanations to the developer concerning each type of refinement according to the patterns. As in all modeling modules, a verifier helps the developer see the integrity and status of refinement for each entity in the model. The entities marked by a green check have been sufficiently refined to satisfy the pattern. A red exclamation point means that refinement is still incomplete for that entity. The developer does not have to refine all entities before proceeding to the next module; he or she can come back later and complete the model in increments, each time removing a new set of red exclamation points. This process can begin with changes at the C-BOM level as well, of course. At the end of each refinement session, the developer moves on to the next stage of refinement by activating the C-REF/Rose tool via the Rose button. This button is shown at the upper right of the figure in the toolbar of the architectural IDE.
The Convergent UML Refinement Assistant (C-REF)
The C-REF module (see Figure 7.10) embeds Rational Rose and supports the later phases of the analysis-by-design workflow and all model-driven activities downstream from the analysis-by-design workflow. It assists the developer during UML refinement of all convergent components according to the currently enabled modeling style—J2EE/EJB by default. It is also used to configure and manage model-driven activities (generate, build, test, deploy) from the perspective of a project team as well as from the perspective of the special configuration requirements of a particular installation.
Previous << 1 .. 109 110 111 112 113 114 < 115 > 116 117 118 119 120 121 .. 142 >> Next