CS616 – Software
Engineering II
|
Lecture 11
|
Larman – Part5
– Elaboration: Iteration 3
Chapter 30 – Designing the Logical Architecture Patterns
·
Objectives
o
Design a logical architecture
in terms of layers and partitions with the Layers pattern
o
Illustrate the logical
architecture using UML package diagrams
o
Apply the Façade,
Observer and Controller patterns
Software Architecture
·
Software architecture
deals with the large scale system
·
Software architecture
includes –
o
organization and major
structure of the major elements of the system
o
system and subsystem
behavior
o
collaborations
Architectural investigation
Identifying those functional
and non-functional requirements that should have a significant impact on the
system design
Architectural design
Resolution of requirements
in the design of the software, the hardware and networking, etc.
Architectural Dimensions and Views in UP
- Logical Architecture – conceptual organization of system in layers,
packages, major frameworks, classes, interfaces, subsystems
·
Deployment Architecture –
allocation of processes to processing units and network configuration
Architectural Patterns and Pattern Categories
Three Levels:
- Architectural Patterns - related to large-scale
and course-grained design
- Design Patterns – related to small and medium
scale design of objects and frameworks
- Idioms – language oriented low-level design
solutions
Architectural Pattern : Layers
Solution
- Organize the large-scale logical structure of a
system into discrete layers of distinct, related responsibilities, with a
clean cohesive separation of concerns such that the “lower” layers are
low-level and general services, and the higher layers are more application
specific.
- Collaboration and coupling is from higher to
lower layers; lower to higher layer coupling is avoided
Problems
- Source code problems are rippling throughout the
system – many parts of the system are highly coupled
- Application logic is intertwined with the user
interface, and cannot be reused with a different interface, nor
distributed to another processing mode
- Potentiall general technical services or
business logic is intertwined with more application specific logic.
- There is a high coupling across different areas
of concern. It is difficult to divide the work along clear boundaries for
different developers
Example
The purpose and number of
layers varies across applications and application domains. Applied to information
systems, typical layers look like this:
Partial layered architecture
for NEXGEN application:
Inter-layer and Inter-Package Coupling
·
Include diagram that
illustrates noteworthy coupling events between layers and packages
·
e.g. partial coupling between
packages
Inter-Layer and Inter-Package Interaction Scenarios
- Use interaction diagrams to illustrate
architecturally significant scenarios
- e.g. part of ProcessSale scenario that
emphasizes connection points across layers
Single Packages vs. Subsystems
- Some packages are true subsystems with behavior
and interfaces
- In UML, subsystem identified with a s
stereotype:
Façade
- A public façade object defines the services for
the subsystem
- Clients collaborate with the façade – not
subsystem components
- e.g. POSRuleEngineFacade and PersistanceFacade
- Façade only exposes a small number of high level
operations
- Façade does not do its own work – it mediates
- e.g. POSRuleEngineFacade is a wrapper
- Common for Domain Layer to expose to expose only
one object to upper layer
- Technical services layer may expose multiple
façades
System Operations and Layers
- SSDs illustrate system operations
- e.g. requests generated by an actor via
Presentation Layer onto Application Layer
Upward Collaboration with Observer
- When lower Application layer needs to
communicate with Presentation Layer – done with Observer pattern
- UI objects in higher presentation layer
implement an interface such as PropertyListener or AlarmListener and listen
for events coming from lower layers
- e.g.
The Model-View Separation Principle
·
What kind of visibility
should other packages have to the Presentation Layer?
·
How should non-window
classes communicate with windows?
·
Should be no direct
coupling from other components to window objects
Model – Domain-Layer objects
View – presentation objects
·
The Model-View
Separation principle: model objects should have no direct knowledge of of view
objects
·
e.g. Register object
should not directly send message to a GUI window object ProcessSaleFrame asking
it to display something
Model-View Separation and “Upward” Communication
·
Windows can obtain
information to display by sending messages to domain objects => polling or
pull-from-above
·
But polling is
insufficient => push-from-below
Chapter 31 – Organizing the Design and Implementation Model Packages
·
Objectives
o
Organize Packages to
reduce impact of changes
Package Organization Guidelines
·
GuideLine – Package
Functionally Cohesive Vertical and Horizontal Slices
e.g.
All NextGen Pricing package types are related to product pricing
·
GuideLine – Package a
Family of Interfaces
e.g.
Java EJB package javax.ejb has 12 interfaces in separate packages
·
GuideLine – Package by
Work and by Cluster of Unstable Classes
e.g.
packages are usually the basic unit of development work not classes
·
GuideLine – Most
Responsible are most stable
e.g.
lowest-level classes are most stable
·
GuideLine – Factor out
Independent Types
Organize types that can be used independently or in different contexts into separate packages
·
GuideLine – Use
Factories to Reduce Dependency on Concrete Packages
Reduce
dependency on concrete classes in other packages
·
GuideLine – No Cycles
in Packages
If a group of packages have cyclic dependency they should be treated as one larger package
Chapter 32 – Introduction to Architectural Analysis and SAD
Objectives
·
Create architectural
factor tables
·
Create technical memos
that record architectural decisions
·
Know basic principles
for architectural design
·
Know resources for
learning architectural patterns
·
UP records
architectural factors in Supplementary Specification
·
Architectural Decisions
recorded in Software Architecture Document (SAD)
Architectural Analysis
- Identification and resolution of system’s non-functional
requirements within context of functional requirements
- Common Steps in Architectural Analysis
1. Identify and analyze the non-functional requirements
that have an impact on the architecture
2. For requirements with a significant architectural
impact, analyze alternatives and create solutions that resolve the impact
The Science: Identification and Analysis of Architectural Factors
·
Architectural Factors
o
Strongest architectural
Factors – high level FURPS+ categories:
§
Functionality
§
Reliability
§
Performance
§
Supportability
§
Implementation
§
Interface
·
Quality Scenarios
o
Define measurable or
observable responses
o
Quality scenarios are
short statements of the form <stimulus> <measurable response>
e.g. When a bug report arrives from the NextGen beta test volunteer, reply with a phone call within 1 working day
Summary of themes in Architectural Analysis
- Architectural concerns are related to
non-functional requirements and include an awareness of the business
context
- Architectural concerns involve system-level,
large-scale and broad problems whose resolution usually involves
large-scale or fundamental design decisions
- Interdependencies and trade-offs
- Generation and and evaluation of alternative
solutions
Architectural Analysis within UP
Six Views:
- Logical
Conceptual organization of the software in terms of most important layers, subsystems, packages, frameworks, classes, and interfaces
- Process
Process and threads wrt responsibilities, collaborations, and allocation of logical elements
- Deployment
Physical deployment of processes and components to processing nodes, and the physical network configuration between nodes
- Data
Overview of persistent data schema and their mappings to database objects
- Use Case
Summary of most architecturally significant use cases and their non-functional requirements
- Implementation
Actual
source code and executables
When to Create an Architectural View
·
After the system is
built – as a summary
·
At the end of each
iteration (e.g. elaboration I, II, III, …)
·
Speculatively, during
each iteration, as an aid to creative design
Sample Structure of SAD
·
Architectural
Representation
Summary
of how the architecture will be described in this document
·
Architectural
Factors and Decisions
Reference
to the Supplementary Specification
·
Logical View
UML
package diagrams and class diagrams of major elements
·
Process View
UML class and interaction diagrams illustrating the processes and threads of the system
·
Use-Case View
Brief summary of most architecturally significant use cases, UML interaction diagrams for some use cas realizations with commentary
·
Deployment View
UML
deployment diagrams showing the nodes and allocation of processes and
components