Figure illustrates a partial logical layered architecture for this iteration of NextGen application.
Figure 34.1 Partial logical view of layers in the NextGen application
Note the absence of an Application layer for this iteration of the design; as discussed later, it is not always necessary.
Since this is iterative development, it is normal to create a design of layers that starts simple, and evolves over the iterations of the elaboration phase. One goal of this phase is to have the core architecture established (designed and implemented) by the end of the iterations in elaboration, but this does not mean doing a large up - front speculative architectural design before starting to program. Rather, a tentative logical architecture is designed in the early iterations, and it evolves incrementally through the elaboration phase.
Observe that just a few sample types are present in this package diagram; this is not only motivated by limited page space in formatting this book, but is a signature quality of an architectural view diagram - it only shows a few noteworthy elements in order to concisely convey the big ideas of the architecturally significant aspects. The idea in a UP architectural view document is to say to the reader, "I've chosen this small set of instructive elements to convey the big ideas."
Comments on Figure:
Inter - Layer and Inter - Package Coupling
To help someone understand the NextGen logical architecture, it's also informative to include a diagram in the logical view that illustrates noteworthy coupling between the layers and packages. A partial example is illustrated in Figure.
Figure 34.2 Partial coupling between packages
Observe that dependency lines can be used to communicate coupling between packages or types in packages. Plain dependency lines are excellent when the communicator does not care to be more specific on the exact dependency (attribute visibility, subclassing, ...), but just wants to highlight general dependencies.
Note also the use of a dependency line emitting from a package rather than a particular type, such as from the Salespackage to POSRuleEngineFacade class, and the Domain package to the Log4J package. This is useful when either the specific dependent type is not interesting, or the communicator wants to suggest that many elements of the package may share that dependency.
Another common use of a package diagram is to hide the specific types, and focus on illustrating the package - package coupling, as in the partial diagram of Figure.
Figure 34.3 Partial package coupling
In fact, Figure illustrates probably the most common style of logical architecture diagram in the UML - a package diagram that shows between perhaps 5 to 20 major packages, and their dependencies.
Inter - Layer and Inter - Package Interaction Scenarios
Package diagrams show static information. To help someone understand the dynamicsin the NextGen logical architecture, it's also useful to include a diagram of how objects across the layers connect and communicate. Thus, an interaction diagram is helpful. In the spirit of an "architectural view" which hides uninteresting details, and emphasizes what the architect wants to convey, an interaction diagram in the logical view of the architecture focuses on the collaborations as they cross layer and package boundaries. A set of interaction diagrams that illustrate architecturally significant scenarios (in the sense that they illustrate many aspects of the large - scale or big ideas in the design) is thus useful.
For example, Figure illustrates part of a Process Sale scenario that emphasizes the connection points across the layers and packages.
Figure 34.4 An architecturally significant interaction diagram that emphasizes cross - boundary connections
Observe that the diagram ignores showing some messages, such as certain Sale collaborations, in order to highlight architecturally significant interactions.
UML Related Interview Questions
|Adv Java Interview Questions||Java collections framework Interview Questions|
|Design Patterns Interview Questions||Rational robot Interview Questions|
|Web semantic Interview Questions||Spring MVC Framework Interview Questions|
|Advanced C++ Interview Questions||Advanced jQuery Interview Questions|
|XML DOM Interview Questions||Object Oriented Analysis and Design Interview Questions|
Object-oriented Analysis And Design
Iterative, Evolutionary, And Agile
Inception Is Not The Requirements Phase
Iteration 1 Basics
System 'sequence Diagrams
Requirements To Design-iteratively
Logical Architecture And Uml Package Diagrams
On To Object Design
Uml Interaction Diagrams
Uml Class Diagrams
Grasp: Designing Objects With Responsibilities
Object Design Examples With Grasp
Designing For Visibility
Mapping Designs To Code
Test - Driven Development And Refactoring
Uml Tools And Uml As Blueprint
Iteration 2 - More Patterns
Quick Analysis Update
Grasp: More Objects With Responsibilities
Applying Gof Design Patterns
Iteration 3 Intermediate Topics
Uml Activity Diagrams And Modeling
Uml State Machine Diagrams And Modeling
Relating Use Cases
Domain Model Refinement
More Ssds And Contracts
Logical Architecture Refinement
More Object Design With Gof Patterns
Designing A Persistence Framework With Patterns
Uml Deployment And Component Diagrams
Documenting Architecture: Uml & The N+1 View Model
More On Iterative Development And Agile Project Management
All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd
Wisdomjobs.com is one of the best job search sites in India.