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

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 .. 79 80 81 82 83 84 < 85 > 86 87 88 89 90 91 .. 142 >> Next

the component development team. A component developer may be designated as the lead developer of the component development team, in which case he or she is the definitive owner of the following specific responsibilities as well as the responsibilities of the lead developer described earlier. If not designated as the single lead developer in the team, then the component developer works under the direction of the lead developer to help fulfill these responsibilities:
o Further refines the convergent business objects allocated to
the component development team by the assembly developer into deployable convergent components. This includes model refinement, technical modeling, model-driven implementation, and testing of the components.
o Defines artifact partitioning (for example, UML models, Java
archives, Java packages, and documentation) with the assembly developer to ensure effective consolidation of these artifacts into the assembly component. o Refines the accessor use cases specific to the assigned
convergent components together with the domain expert and defines and drives accessor development. o Develops the convergent component installation set for the
component in conjunction with the assembly developer. o Works with the technical writer to create design and user
documentation materials. o Convergent Architecture-specific consolidation of the
following RUP worker roles: test designer, developer, capsule developer, implementer, database designer.
Owned resources: o Change sets (artifacts): Convergent
components (architectural-IDE artifacts [UML models, configuration files, generation cartridges, build and test environments, Java-IDE environments, project configuration files], component installation sets, user documentation materials, developer documentation). The following specifications apply: o The component installation set for
the J2EE technology projection (Chapter 8) comprises: J2EE WebArchives containing accessors, EJB archives, client archives, and an installation verification test. o Specialized technologies: Same as lead
[4]This is a style-specific application of the concepts formulated in the RUP Work Guideline, "Developing Large-Scale Systems with the Rational Unified Process" (Kruchten 2000).
[5]Note that an assembly is an organization from a purely IT perspective. It organizes deployable IT resources. It does not represent a core business organization and is assigned this special name to make this distinction clear.
Convergent Architecture
Chapter 5: The IT-Organization Model
The Operational Systems Organization
The operational systems organization (OPS-O) is where assemblies are deployed and put into operational use. The specialty and prime responsibility of this organization is to provide a robust, stable environment as specified by the assembly development teams in the assembly installation guide. The assembly, including its operational installation, is developed in conjunction with the operational systems organization (deployment manager) to ensure feasibility and realistic expectations of all stakeholders regarding deployment, test, maintenance, and long-term operation of the assembly. The chief architect works with the operational systems organization to ensure that the simplest possible operational environment evolves to fulfill the diverse requirements of assemblies.
The operational systems organization also exists when the IT organization is developing software to be sold to external customers. The only difference is the focus on external customers in contrast to internal customers. The operational needs of these two customer groups are essentially identical from the perspective of the IT organization. In the case of external customers, the transition organization described later manages prerelease tests (beta-test programs) and the rapport with customers during the transition phase of system development. In parallel, it channels the rollout of the software product to the respective marketing, sales, and distribution organizations. With regard to the other organizations described in the chapter, the user support organization becomes the customer support organization and the local infrastructure and base systems organization provides necessary base systems for these activities. The feedback channels and relationships with the other IT organizations remain unchanged.
As indicated in Figure 5.7, the operational systems organization is partitioned into four suborganizations. All its responsibilities and roles, aside from those common to every IT organization, are delegated to the suborganizations, which are covered individually in the following subsections.
Figure 5.7: The operational systems organization.
The Transition Organization
The transition organization (Transition-O) is concerned with effectively moving assemblies into the operational environment. Such movements may occur not only at the end of the development cycle, but also at the end of iterations during elaboration and construction of an assembly. This organization is responsible for reducing impedance and friction between the development phases of the system's life cycle and the operational phases of its life cycle. To achieve this, the transition organization is involved in the entire life cycle of the system to ensure compatible
Previous << 1 .. 79 80 81 82 83 84 < 85 > 86 87 88 89 90 91 .. 142 >> Next