timed quiz 9pm EST
micos009
Newfolder.zipNew folder/L10-ArchitectureDesign.ppt
Architectural Design
Software Architecture
Architecture Design
- Architecture design is a problem-solving activity whose input is the SRS document and whose output is the “abstract” specification of a software which realizes the desired characteristics
Architecture Design – cont.
- Architecture design is a specification of the solution’s major components, their responsibilities and properties, and the relationship and collaboration among the major components.
Architecture Design
Architecture design is a problem-solving activity whose input is the SRS document and whose output is the “abstract” specification of a software which realizes the desired characteristics
Rephrased from page 254 of text
Architecture Design
Architecture design is a specification of the solution’s major components, their responsibilities and properties, and the relationship and collaboration among the major components.
Also, rephrased from page 254 of text
Architectural Design Activity Overlaps
- Architecture Design Activity can not be cleanly separated from SRS Analysis (Product Design) and Detail Design Activities because of the 4 design principles:
- Feasibility
- Adequacy
- Changeability
- Economy
Requirements
(Product Design)
Architectural
Design
Detail Design
- Feasibility: During Product Design, we may need to understand the feasibility of some specific architecture
- Adequacy: May need to “prove” the sufficiency of the solution and need to create an architectural prototype during Product Design or Design Analysis time
- Changeability: May need to make trade-offs of requirements based on the design architecture
- Economy: May need to explore schedule, cost, and resource impact based on the design architecture AND some detail design
Variations in Architectural Design
- Not all architectural designs are the same in terms of their level of abstraction:
- number of components (main components),
- description of each component
- relationships among components
Deciding on the “right” level of architectural depth has always been a problem.
- Two important Considerations:
1. Problem context: the larger the problem the more levels of abstraction, # of components, # of relationships among components
2. Organizational context: the more experienced and sophisticated organizations would have more standards, tools, guidelines, and skills invested --- thus may have more pre-determined preference or constraints on the architectural design
Introduction To Architectural Design
SRS
Design
Doc.
Design
Analysis
Architectural
Design
Detail
Design
Swft Engr. Design
Analyzed
SRS
Architectural Design Process
Develop Architectural
Alternatives
Evaluate Architectural
Alternatives
Select Architectural
Resolution
Finalize Software
Architectural Document
SAD
[selected ]
[else ]
SAD Template
- Product Overview
- Architectural Models
- Mapping between Models
- Architectural Design Rationale
Software Architecture Document (SAD)
- Product Overview:
summarizes the overall product description, stakeholders and target market descriptions, assumptions and constraints, and the basic business requirements (or refer to SRS)
- Architectural Models:
presents the architecture in terms of models of data, functional decomposition and functional activities, and system states and transitions (representing different aspects or views – use DeSCRIPTR as a guide).
3. Mapping between Models: presents and explains how the different models are related
4. Architectural Rationale:
explains the main criteria considered for design decisions, alternatives that were investigated, and why the particular architectural choice was made. (choosing which design decisions to discuss is important)
Design of Non-Functional Requirements
- Major Functional Requirements can be directly mapped into key architectural components, but how about “non-Functional requirements (or attributes)”?
See next slide
You Do It
- Major Functional Requirements can be directly mapped into key architectural components, but how about “non-Functional requirements (or attributes)”?
- Go to this week Discussion area and share your thoughts with your classmates.
Quality Attributes
- Operational Attributes
- Development Attributes
Operational Attributes
- Performance: time limits, space capacity, transaction limits
Operational Attributes – cont.
- Availability: readiness for use (borders on performance)
Operational Attributes – cont.
- Security: resistance or protection from harm
Operational Attributes – cont.
- Reliability: error resistance and performing to requirements
Operational Attributes – cont.
- Usability: easy to understand and navigate
Developmental attributes
- Maintainability: easy to understand and modify
Developmental attributes –cont.
- Reusability: portable, easy to modify, loose coupling, etc.
An Example
Page 258 - “Finger Print Matching”
- A program responsible for matching fingerprints read from scanners against a database to allow people into and out of a secure facility.
- There are also some other characteristics that are important:
(1) must respond quickly,
(2) must be available the entire time,
(3) must be able to perform matching at a reliable rate,
(4) and must resist attackers.
Fingerprint Matching Software “Design”
Input
validation
Fingerprint
validation
Fingerprint
Reading
device
Finger
DB
“fingerprints read from scanners”
“matching ---
against a database”
Fingerprint Matching Software “Design”
Example Using Activity Diagram notation
Input validation
fingerprint validation
Set-up / send message
fingerprint
input
pass/
no-pass
message
error
message
[bad input]
[good input]
Fingerprint
Reading
device
Finger
DB
What about these?
Fingerprint Matching Architecture
Fingerprint Matching Software “Design”
Example Using Activity Diagram
Fingerprint
Reading
device
validate
input
Fing_prt
input
Digitized
Fing prt
Evoke
F-prt-dig
Error
process
Error
message
[good print]
[else]
Input validation
Digitized
Fing prt
Fing_prt
table
validate
F-print
Pass/No-pass
message
Fingerprint validation
Finger
DB
Compare this with box-and line diagram on page 265 of text
What about these “non-functional” attributes?
- “respond quickly” – Performance
- Which functionality: a) input validation or b) fingerprint validation or both needs to be looked at?
- Is the scanner system or the db system a potential bottleneck?
- How do we specify the speed criteria on the activity diagram?
What about these “non-functional” attributes?
- “must be available the entire time - - -” - Availability
- Scanner system must have a back-up scanner to switch to?
- Do we need a redundant db or some other file?
- Similarly do we need to have a redundant processor ?
- How do we specify the redundancy on the activity diagram?
What about these “non-functional” attributes?
- “must perform matching at a reliable rate” – Reliability
- Input checking must not accept incomplete or smeared finger print
- Algorithms for digitizing finger prints must be accurate – (error rate?)
- Algorithm for data base compare must be accurate – (error rate?)
- How do we specify these on the activity diagram?
What about these “non-functional” attributes?
4. “must resist attacker” – Security
- What does this mean? The whole system must be physically protected and there should not be any “connection” to any other system.
- The system must have a security check functionality for start-up, shut-down, and access.
- We can do the security checking by adding another set of functionality to activity diagram
What about Cohesion?
- Would we have some issues related to “cohesion?”
- Input validation: a single related function
- Fingerprint validation: a single related function
Questions
New folder/L11-Arcitecture Resolution.ppt
Architectural Design Resolution
Software Architecture
Chapter 10
Architectural Design
SRS
Design
Doc.
Design
Analysis
Architectural
Design
Detail
Design
Swft Engr. Design
Analyzed
SRS
Architectural Design Process
Develop Architectural
Alternatives
Evaluate Architectural
Alternatives
Select Architectural
Resolution
Finalize Software
Architectural Document
SAD
[selected ]
[else ]
Architectural Design Resolution
Analyzed
SRS
Architectural Design Process
Develop Architectural
Design Alternatives
Evaluate Architectural
Alternatives
Select Architectural
Resolution
Finalize Software
Architectural Document
SAD
[selected ]
[else ]
Developing Architectural Design Alternatives
- Develop Functional Components
- Based on transforming SRS functions and data requirements
- Determine Components Based on “Quality Attributes”: maintainability, reusability, performance, availability & security (non-functional attributes)
- Based on transforming non-functional SRS requirements
- Modifying Existing Architecture (skip)
- Based on existing architecture as a starting point and transforming it to satisfy the new system
- Elaborate an Architecture Style (chapter 15)
- Based on an existing architectural style and elaborate on that style
- Transform a Conceptual Model (chapter 11-Destailed Design)
- Based on viewing the SRS problem description as a solution description and transforming that to fit the new system
Transforming and elaborating are the key words --- how do we do that?
Architectural Design
(team or individual activity?)
- In software engineering, many activities are performed as a team effort --- for
- Productivity
- Quality
- Morale and Acceptance
- But for Architectural Design:
- Better done as an individual first
- Bring together all the individual architectural design suggestions
- Evaluate the alternatives
Determine Functional Components
(Using the “AquaLush Irrigation System” Example in textbook – p.82 and p.164)
AquaLush Product Vision:
The AquaLush Irrigation system will use soil moisture sensors to control
irrigation, thus saving money for customers and making better use of
water resources.
AquaLush Major Product Features (from requirements):
- - Monitor water usage and limit usage (by moisture level) to amounts set by users
- - Allow users to specify times when irrigation occurs
- - Be operated from a simple central control panel
- - Have a web-based simulator
What would you list as major “functional components ?”
(e.g.)
1. user interface to initialize, set-up, monitor and control the irrigation system
2. sensor inputs processing
3. water irrigation control
4. web-based simulator
Try this in class (with class) - - - - use components diagram
Determining Functional Components from SRS
(page 289 – 291textbook solution)
1. configure the program at startup
2. controlling irrigation (manually and automatically)
3. providing a user interface
4. allowing users to monitor and repair system
<<component>>
User Interface
<<component>>
Irrigation Control
<<component>>
Monitor and Repair
<<component>>
Startup
Do the functional components and the interaction lines make sense to you?
(Should there be a line between User Interface and Startup ?)
From page 180
From page 289
Determining Functional Components
(page 289 – 291textbook solution for product)
1. configure the program at startup
2. controlling irrigation (manually and automatically)
3. providing a user interface
4. allowing users to monitor and repair system
<<component>>
User Interface
<<component>>
Irrigation Control
<<component>>
Monitor and Repair
<<component>>
Startup
AquaLush Parts
Status
AquaLush
Configuration
<<read & write>>
<< read & write >>
<<startup reads config. data>>
Note that Monitor and
Repair component can use
the Data Store to communicate
with Irrigation Control component,
without a line between them.
How initialized?
Component Responsibilities
- There needs to be some description of each component’s responsibilities:
- User Interface: interacts with control panel hardware and implements control panel interface; obtains data from Monitor and Repair -------
- Monitor and Repair: Obtains data from Parts Status to pass on to ------
- Irrigation Control: Controls valve, reads sensors; reads clock; implements irrigation cycles; ---
- Startup: reads the configuration data of valves, zones, etc. and send them to Irrigation Control & (also alternatively also include Monitor Repair) ----
- Parts Status: a database that keeps track of all failed and repaired parts, etc.
- Configuration: a database of all the installed parts of valves, sensors, etc. of the customer’s Aqualush system
Determining Functional Components
(page 293 textbook - for adding web- simulator)
<<component>>
Simulating User
interaction
<<component>>
Irrigation Control
<<component>>
Monitor and Repair
<<component>>
Startup
AquaLush Parts
Status
AquaLush
Configuration
<<read & write>>
<< read & write >>
<<startup reads config. data>>
<<component>>
Simulating
Valves and sensors
Same initialization
problem?
Determining Components based on
“non-Functional” or “Quality’ attributes
- AquaLush has the following non-functional (NF) requirements:
- Reusability : design must be used in the product, web-simulator, and future versions
- Hardware adaptability: design should consider adaptability to multiple valve types, sensor types, keypads, and screen display types
- Reliability: must not fail “often” in normal usage
- Modifiability: accommodate future changes in irrigation strategy (formula)
Note that reliability of not failing “often” is a nebulous and subjective statement
NF: Reusability Attribute
- Requires components to be cohesive and loosely coupled so that they can be reused.
- Consider each component for these:
- Would you subdivide User Interface/interaction component into several subcomponents (interface to Irrigation Control and to Monitor and Repair separately)?
- Would you separate out Irrigation Control component into a) manual and b) auto subcomponents?
- etc.
Irrigation Control
Manual control
automatic control
NF : Hardware Adaptability & Modifiability
- Requires the component to have device adaptability also implies
- separate cohesive subcomponents
- low coupling subcomponents, each representing different device
- hide the device specific internals and keep the interface unchanging
- In AquaLush, the Irrigation Control has interfaces to multiple devices.
- In AquaLush, Monitor and Repair component and Startup component has interface to a data-store
Virtual Device Interface
valve
sensor
keypad
display
Screen
buttons
Everything inside the Device Interface components are device dependent, but hidden
from outside; all interfaces to outside of the component should stay stable
NF: Reliability and other components
- Reliability may be argued many ways:
- Small cohesive module is by definition more reliable
- Add user interface to control irrigation both manually and automatically AND also have direct control of the devices
User Interface
Irrigation Control
manual
auto
Virtual Device Interface
valve
Sensor
display
keypad
Screen buttons
Agree with
all the interaction
lines ? Do we need
a new component ?
Emergency
Control
Designer’s view of providing reliability ---- “ not fail often in normal usage”
Design Alternatives
- Design alternatives are good to have and can improve the design:
- Generate and document these alternatives as one is developing a design
- Combine some of parts of the generated design alternatives from:
- Functional Components
- Non-functional Components
- Try to alter and fit to an existing Design Style, if applicable
Architectural Design Resolution
Analyzed
SRS
Architectural Design Process
Develop Architectural
Design Alternatives
Evaluate Architectural
Alternatives
Select Architectural
Resolution
Finalize Software
Architectural Document
SAD
[selected ]
[else ]
Evaluating Architecture Alternatives
- What does one look at when evaluating architecture?
- Would the architecture result in a system that will satisfy:
- Functionality requirements
- “Quality” (non-functional) requirements
- Maintainability
- Reusability
- Performance
- Availability
- Reliability
- Security
- Would the architecture result in a system that will
- Have “great” user interface
- Delight the customer and the users
We can not tell what will happen since the architecture is not code, we
can only “guess” whether the architecture will most likely meet the above
conditions
An Architecture Evaluating Technique
- Utilize a “profile,” which is a set of scenarios generated to fit the characteristics of interest. (e.g.)
- Usage profile is a set of scenarios that describes the user requirements (sometimes known as “business” workflow)
- Reliability profile is a set of scenarios that portrays the non-functional requirement of how a system behaves to under adverse situations
- Performance profile is a set of scenarios that portrays the non-functional requirements of how a system behaves under time limit constraints or capacity limit constraints
- etc.
- Each architecture is evaluated by going through the scenarios in the profile and assessing whether the architecture, if implemented, would satisfy the profile.
Developing Profiles with “utility tree”
- A utility tree is a tree whose each sub-tree is a “profile” and the leaves of the sub-tree are the scenarios for that profile
Utility tree
Functionalities
Irrigation control (automatic)
Irrigation control (manual)
Maintenance repair
Hardware adaptability
Valve type modification
Adding new valve types
1. The profiles are generated, using
SRS and some brainstorming
2. The scenarios within each profile
are also developed using SRS, ‘team’
brainstorming, and prioritizations.
3. Within each profile, keep the number
of scenarios to 3 to 10
4. Each scenario should include:
- initial state
- activity flow involving actors and
the product
- post activity state
* think of special circumstances and
non-traditional scenarios
Another Architecture Evaluating Technique
- Build a “prototype” of part of or the complete software product to evaluate certain aspects (functional and non-functional) of the product.
- Advantages:
- Can provide measurements
- Can provide experiential feedbacks
- Disadvantages:
- Prototypes takes resources
- Prototypes takes time
Much of the prototyping and profiling techniques are aimed at evaluating
the architecture against the “basic” design principles (discussed earlier) :
- feasibility,
- adequacy,
- economy, and
- changeability
Selecting Alternatives
- How do we select the architecture from the various alternatives ?
- Evaluate the Pros and Cons of each of the alternatives
- By Number of pros and cons
- By Weights of pros and cons
- Multi-dimensional analysis table (p. 306 of text):
- Column of scenarios
- Weight for each scenario (use normalized weight so each is a fraction of the total and the total is 1)
- Column for each architectural alternative
- Rate all the scenarios for that alternative ( e.g. 1-5)
- Score the scenario by multiplying the scenario weight and the rate
- Sum the scores for that alternative
- Compare the total score for each of the architectural alternatives
Architectural Design Resolution
Analyzed
SRS
Architectural Design Process
Develop Architectural
Design Alternatives
Evaluate Architectural
Alternatives
Select Architectural
Resolution
Finalize Software
Architectural Document
SAD
[selected ]
[else ]
Finalizing The Architectural Design
- This step ensures that the selected architecture does satisfy the various functional and non-functional requirements (and possibly may delight the users) and is clearly documented.
- Architectural design satisfying the “basic” design principles of:
- Feasibility
- Adequacy
- Economy
- Changeability
- The SAD document itself is
- Well formed (organized)
- Complete (include all the components/relationships/descriptions)
- Clear (understandable by others)
- Consistent (no conflicting information)
(from chapter 8 of text)
Design Review in Finalizing the SAD
- A Review is an examination and evaluation of the work by qualified and affected stakeholders
There are many different types of “reviews”:
1. Desk Check – by the author
2. Walkthrough – informal review by team members
3. Inspection – formal review by a trained inspection team with moderator
4. Audit – review conducted by experts who are not part of the team
5. Active Review – inspection by experts who answer specific aspects
of the design (this allows pinpoint reviews and is less
costly)
An inspection requires 3 formal steps:
- preparation
- conducting the inspection
- rework and inspection “closeout” report
Questions
New folder/L12-Detailed Design-Midlevel.ppt
Detailed Design
Software Architecture
*
A Generic Software Engineering Design Process
*
Detailed Design
SRS
Design
Doc.
Design
Analysis
Architectural
Design
Detail
Design
Swft Engr. Design
Analyzed
SRS
Detailed Design Process
Generate/Improve Detailed
Design Alternatives
Evaluate Detailed
Design Alternatives
Select Detailed
Resolution
Finalize Detailed
Design
Detailed
Design
Doc
[selected ]
[else ]
SAD
Analyze SRS and SAD
Architectural Design
Analyzed
SRS
Architectural Design Process
Develop Architectural
Design Alternatives
Evaluate Architectural
Alternatives
Select Architectural
Resolution
Finalize Software
Architectural Document
SAD
[selected ]
[else ]
Detailed Design
SAD
Detailed Design Process
Generate/Improve Detailed
Design Alternatives
Evaluate Detailed Design
Alternatives
Select Detailed Design
Finalize Design
SDD
[selected ]
[else ]
Detailed Design
- Detailed Design starts with Software Architecture Design (SAD) and fill in the details of the architectural components - - - may cause re-work on SAD, too.
- There is no “fixed” boundary between SAD and Detailed Design - - - it is not strictly sequential & we may iterate back and forth.
Detailed Design
- Detailed Design has 2 levels:
- Mid-level (this lecture set)
- Low-level (later lecture)
- Detailed Design may be:
- Static: non-execution oriented (mostly this lecture set)
- Dynamic: execution oriented (next lecture set)
*
Mid-level Detailed Design
- Mid-level design is the activity of specifying software at the level of medium-sized components.
Mid-level Detailed Design
- The mid-level design specifications include (DeSCRIPTR):
- Decomposed mid-level components
- States of these components
- Collaboration among these mid-level components
- Responsibilities of each of these mid-level components to perform some task or maintain data
- Interfaces that these mid-level components use to communicate with each other
- Properties (such as security, reliability, performance) of these components must be specified.
- Transition of states and state behavior of these components are described
- Relationships (inheritance, aggregation, composition, etc.) among the components
*
Low-Level Detailed Design
- In contrast to mid-level, low level detailed design fills in the details for programming purpose (PAID):
- Packaging of the code into compilation unit and libraries is decided
- Algorithms are described in detail steps
- Implementation issues such as visibility and accessibility of entities and low level relationships among entities are described
- Data structures and data types are specified
Sample: Detailed Design Document Content
- Mid-Level Design Models (in the form of Class diagrams, sequence diagrams, state transition diagrams, etc.)
- Low-Level Design Models (specific algorithms, data structures, implementation guidelines for non-functional attributes such as security or performance)
- Mapping between Models (showing how the models are related)
- Description of Design Rationale (describing the design decisions made and factors that contributed to the decision)
- Glossary of terms and acronyms used
very important
average important
Static Descriptions (Design)
(based on text book & thus OO Biased )
- Classes
- Associations Among Classes
- Generalization and inheritance (“is a” relationship)
- Interfaces of classes
- Aggregation (“part-whole” relationship) &Composition
Rest of this lesson lecture notes will focus on the following:
*
Class Generalization and Inheritance
- Generalization is a “parent-child” or “sub-typing” relation between classes:
- e.g. dog “is a” animal
- Association represents relationships between instances of classes
- A person “works” for a company; company “has” a number of buildings
fish
salmon
whale
Generalization
person
company
Association
Works for
*
0..2
Abstract Class for mid-level design
- In design we may not fill in all the details of a design.
- Abstract class is an example of such a situation.
- An abstract class is a class that can not be instantiated because it contains a method or operation without the body.
- Useful as a parent-class which is inherited by some child-class that has “implemented” the method that has no body.
<<abstract>>
animal
move ( ) {abstract}
fish
dog
bird
Each of the sub-classes:
- fish
- dog
- bird
will have a different move( )
operation that needs to be
“implemented” differently
We use abstract class as a design for the purpose of enforcing a certain
set of common attributes and operations that must be inherited by all descendants
If we do not use
stereotype descriptors,
then we must italicize
to show abstract class
*
Interfaces for mid-level design
- Interfaces are important in design because it shows the relationship of dependencies (of features - attributes or/and operations)
- Earlier we have discussed the provided and the required interfaces, along with the “ball” and the “cup” to indicate the provider of the feature versus the dependent of that feature.
- Here we show another notational approach
temperature
gauge
temperature
gauge
<<interface>>
temperature
UpdateTemp (temp: object)
GetTemp ( ): object
thermostat
thermostat
Provided
interface
Required
interface
temp: object
Differentiating “Part-Whole” Relationship Concepts
- Aggregation is a part-whole association.
- Composition is a special kind of aggregation where the part may only belong to one whole at any time.
Replenish-list
Sold-item
list
item
An Item may belong to the
replenish-list and may
also be on the sold-item
list. Is the aggregation symbol
1…*
1…*
kitchen
house
subdivision
A kitchen belongs to only one house,
which in-turn sits in only one subdivision.
is the composition symbol.
Transitivity Property
- Note that some relationships may look like an aggregation.
1. Person Z is biologically-related to father y; father y is biologically
related to family x. The person Z is biologically related to the family x.
(this is a transitive relationship --- thus an aggregation)
2. Joe is a member of a church y; church y is a member of entities that
don’t pay taxes. Is Joe a member of entities that don’t pay taxes? --- but
Joe pays taxes! (be careful with is “a member of” versus “possess the
characteristics” of )
“Coming Up with” or Drafting the Mid-Level Design
- This discussion is primarily OO-based; thus the aim is to come up with mid-level design of classes
- Creational technique :
- Decomposition based on functionality, “quality” attributes, or both (just as we did for High Level Design)
- Transformational technique:
- Converting the conceptual (problem) model to a draft design model (much as what was done with High Level Design)
- Requires a good SRS and SAD or
- Transforming a previously completed, similar design
For experienced people, they usually have some previous, similar design in
their brain and would draw upon that first--- and then create more
Creational Technique
- Generating Classes from Themes
- Developing a list of classes and the class diagram
- Review and improve the class diagram
Creational Technique
- Generate a Design Story (based on what you think are the most important aspects of the solution); list the key “themes” in the story.
- Use the themes and “brainstorm.” For each theme identify and list:
- Entities in charge or involved in the theme
- Things that interact with the solution part of theme
- Things whose data needs to be stored
- Any structure or collections of entities
Generating
Classes from
Themes
Creational Technique
- From the list in step 2, generate “candidate”
classes.
- List their names
- List their responsibilities
4. Evaluate the list of classes:
- Discard those that seem to be unclear in name or responsibilities
- Rework those classes that have overlapping responsibilities
- Discard those that seem to be “out of scope”
5. Draft an initial Class diagram showing
- Classes, each with attributes and operations
- Associations among classes
Developing
a list of
classes and
the class
diagram
Creational Technique
- Check the Class Diagram:
- Check each class for missing/inaccurate attributes and operations
- Combine common attributes and operations into a super-class, if necessary
- Look for “required’ and “provided” components (using design patterns)
Review and
improve the
class
diagram
Transformational Technique
- Start with the conceptual model (requirements and high level design) and convert the actors in the conceptual model to interface classes.
- Add data collection classes for all those actors whose data needs to be recorded
- Add a start-up class to start the execution of the solution.
- Convert controllers and coordinators in the conceptual model into classes and add any that needs to be included as control and coordination classes.
- Data types with complex structure in the conceptual model needs to be converted to classes
- Decide on whether container classes are needed, include them if necessary
- Add Associations and interfaces; draft the class diagram
Some Static Modeling Heuristics
for mid-level design
- Responsibility driven decomposition
- Inheritance
- Delegation
Responsibilities Driven Decomposition
- Responsibility is an obligation to:
- Perform a task (operational responsibility)
- Maintain some data and non-functional information (data responsibility)
- Responsibility driven decomposition
- Generating lower level operational responsibility components based on decomposing the high-level operational responsibilities
- Generating lower level data responsibility components based on decomposing the high-level data responsibilities
- Responsibility and design principles (cohesion and coupling)
- Assign a module (class) with at most one operational responsibility and one data responsibility - - - cohesion
- Assign complementary data and operational responsibilities together- - - cohesion
- Make sure module responsibilities do not overlap - - - cohesion and coupling
- Do not place extra operational and data elements into a module - - - cohesion
- Make sure that all needed operational and data elements are included in the module to fulfill the responsibilities - - - coupling
Starting a Design
Consider designing a component dealing with a bank account.
A bank account handles the deposit and withdrawal of that account.
Each bank account is owned by one to three people. Information about a
bank account such as owner, open date, account type must be kept and
maintained.
Account
amt : real
total_amt:real
act_num: int
Deposit (amt : real, act:int )
Wdraw (amt : real, act ;int)
Capture the Ownership Information & Relationship
Account
amt : real
total_amt:real
act_num: int
Deposit (amt : real, act:int )
Wdraw (amt : real, act ;int)
Owner_Info
addr : string
Tel : int
ss_num: int
B-date: date
Act_num : int
.
setaddr ( )
getaddr ( )
.
.
*
1..3
Account_info
Discussion on Cohesion and Coupling
Consider designing a component dealing with bank account and
account information
Account
amt : real
total_amt:real
a_num: int
deposit(amt : real, a_num:int )
wdraw (amt : real, a_num ;int)
Account_Info
owner: string
act_type:real
act_st_date: date
act_num: int
getOwner (act_num: int) string
setOwner (act_num:int, owner:string)
.
.
Should these be combined as one Class or left separately?
(cohesion and coupling trade-off ?)
0..1
1
More Discussion on Cohesion and Coupling
(cont.)
Account
amt : real
total_amt:real
a_num: int
deposit(amt : real, a_num:int )
wdraw (amt : real, a_num ;int)
Account_Info
owner: string
act_type:real
act_st_date: date
act_num: int
getOwner (act_num: int) string
setOwner (act_num:int, owner:string)
.
.
Should these be somehow combined or left separately?
(cohesion and coupling trade-off ? – and db performance ?)
Owner_Info
addr : string
Tel : int
ss_num: int
B-date: date
.
.
setaddr ( )
getaddr ( )
.
.
Inheritance
- Inheritance is a generalization relationship between a super-class and its sub-classes.
- Inheritance provides a mechanism for re-use in mid-level designs.
1. Combine common attributes and operations in similar classes into a
super-class
2. Use inheritance only when there is a generalization relationship
between the super-class and its sub-classes.
Delegation
- Delegation is a mechanism to decompose the responsibilities and assign some of the responsibilities to different classes.
- This allows classes to re-use a class that has been given a set of responsibilities that is needed by other classes.
Questions
*
*
*
*
*
Generic Software Engineering Design
SRS : Problem
Design Document : Solution
Analysis
Architectural
Design
Design
Document
SRS
[adequate architecture]
[else]
[adequate detailed design]
[adequate architecture]
Analyze SRS
Generate/Improve
Candidate Architectures
Evaluate Candidate
Architectures
Select Architecture
Finalize Architecture
Generate/Improve Detailed
Design Alternatives
Evaluate Detailed
Design Alternatives
[else]
Select Detailed
Design
Finalize Design
[else]
Detailed
Design
New folder/L13-Sequence Diagrams.ppt
Interaction Design &
UML Sequence Diagram
Software Architecture
Chapter 12
Interaction Design &
UML Sequence Diagram
- Once we have decomposed the system and designed the individual components (classes), we need to depict how these pieces collaborate to deliver the services.
- The interactions among the individual participants (classes) can be captured with different UML notations, but mainly through Sequence Diagrams
- Sequence diagram depicts the message flow among the participants and thus depicts the collaboration among the participants.
General Sequence Diagram
- It is composed of a diagram frame:
1) with an identifier name
2) the individual participants (classes) in the form of “lifeline” composed of:
- A rectangle depicting the participating object
- A dotted line that extends for the time period of the interaction
3) messages to communicate among the participants
order process
client
order
inventory
create
Locate item
Message Arrows for Communications
- The message arrows represents the communications between two objects in sequence diagram. It goes from the lifeline of one object to that of another object
- Synchronous message where the sending object suspends action and waits for the response to the message
- Asynchronous message where the sending object continues with its operations without waiting for the response
- A return of control from the synchronous message
- A creation of a new entity
(filled head)
(open head)
Message Specification
- Every synchronous and asynchronous arrow must be labeled with a message specification on top of the message arrow.
- The message format :
return_variable_name = message_name (param_list)
- Both the return_variable_name and the = sign are suppressed if there is no return value
- message_name is never suppressed (required field)
- param_list is a list of arguments separated by commas and is suppressed when there is no argument
See page 364 for details
of param list
Examples of Sequence Diagram’s message specification
- age = getAge or age = getAge( )
- message specifies that the return value from getAge operation is assigned to the variable age. Note that age is a variable accessible by the object that sent the message
- checkStatus (flag = status, machine)
- message specifies that checkStatus operation passes a parameter and gets back the status information which assigned to a “local” variable, flag. (local meaning the object that sent the message)
Execution Occurrence in Sequence Diagram
- An operation is executing when a process is running
- An operation is suspended when it sends a synchronous message and waiting for a return message.
- An operation is considered active when it is either executing or suspended
- An object is active if one or more of its operation is active. While an object is active it is shown with an execution occurrence (a thin rectangle covering the dashed line).
- A synchronous message always initiates a new execution occurrence
(e.g. Order in the diagram)
sample
client
order
inventory
create(ord)
locate_item(i)
Interaction Fragments
- Sequence diagram depicts the interactions among the entities. The natural flow of “control” in the diagram is sequential from top to bottom and follows the direction of the message arrows. The natural sequential control can be broadened with Iteration Fragments:
- Optional Fragment ( “if –then” )
- Alternative fragment ( “if-then-else-if - - -” or “case” )
- Break Fragment ( “break” )
- Loop Fragment ( iterations or “loop” )
Note that these fragments are like the control structures that exist in
a programming language.
Depicting a Fragment Graphically
sd sample
client
order
inventory
create
Locate item
operator
op1
Interaction
Fragment
Interaction
Fragment
Operation
Name:
(e.g. loop)
Interaction Fragment
Operand
Depicting an Optional Fragment
sd sample
client
order
inventory
create_order
locate_item
Opt
cr_custinfo()
Interaction
Fragment
Interaction
Fragment
Operation
Name:
(optional)
Interaction Fragment
Operand
[new_cust]
Interaction
Fragment
guard
The Optional Fragment has only 1 operand and guard in brackets. A guard
is a Boolean expression. The Optional Fragment is performed if the guard is true at
that point of the interaction. It is like the “if” structure of programming language
Depicting an Alternative Fragment
sd sample
client
order
inventory
Cr_order( )
Alt
cr_custinfo()
Interaction
Fragment
Interaction
Fragment
Operation
Name:
(Alternative)
Interaction Fragment
Operands
[new_cust= no]
Interaction
Fragment
guard
The Alternative Fragment has multiple mutually exclusive guards in brackets. The
operand associated with the true guard is executed. This structure is like the “CASE”
or “if-then-else-if” constructs of the programming language
[new_cust=yes]
get_custinfo()
Depicting an Break Fragment
sd sample
client
order
inventory
Cr_order( )
Alt
cr_custinfo()
Interaction
Fragment
Operation
Name:
(Break)
[new_cust= no]
The Break Fragment has a single operand which is processed if the guard is “true,”
and the rest of the processing in the diagram is not performed. It is like the “break”
construct in programming language.
[new_cust=yes]
get_custinfo()
break
[ ! good_status]
error_msg( )
The guard
expression of
NOT good_status
Depicting an Loop Fragment
sd sample
order
inventory
Loop
Process_item()
Interaction
Fragment
Operation
Name:
Loop (min,max)
The Loop Fragment is expressed as Loop(min,max). The loop is performed at
least min times and at most max times. If neither min or max is specified, then min=0
and max is unlimited. If the loop is performed min times but less than max, then it is
performed again as long as the guard is true. The default value of guard is true.
[more]
more = has_item(n_it)
The guard
expression of
[ more]
iterator
more = has_item (n_it)
checking for
more items
n_it = check_items()
create
Some Sequence Diagram Guidelines
- Pick a design level (based on the classes in the static model) and “be consistent” at that level through out the interaction diagram.
- Put the sender of the first message leftmost
- Put pairs of entities that interact heavily next to each other
- Position the entities to shorten the message arrows
- Position the entities to make the message arrows go from let to right
- Suppress return arrows as much as possible when using execution occurrences
Some Thoughts on Designing
- Design is not a sequential process but much more iterative: (“Component/Interaction” Co-Design)
- Design (generate) the components in terms of entities (with class model and express in class diagram)
- Design the interactions among the classes (express in sequence diagram)
- Design is not a single level process. but more top-down: (Outside-In Design)
- Top may be viewed as external (requirement level)
- Down may be viewed class model and interactions representing deeper levels of solutions
- And we progressively move into more details (inwards)
Iterate the above as we evaluate, alter, and improve the model
(See pages 376 -380 example in your book)
Some details on evaluating interaction alternatives
(Example)
SD polling
waterHeatercntrl
clock
loop
opt
time=getTime
[time right]
takeAction
SD notification
waterHeatercntrl
clock
loop
opt
time=getTime
[time right]
takeAction
notify
waterHeatercntrl is constantly
polling the clock with a fixed
rate. - - - efficient for waterHeatercntrl?
clock is constantly checking time and notifies
waterHeatercntrl when the time arrives, then waterHeatercntrl takes action.
Which one would you pick and why ?
Also, note the synchronous message creates an execution occurrence
On Control Mechanism
- In designing, one of the issue is on “point of control,” or the controller, which makes decisions and directs other components.
- There are three major ways to establish control:
- Centralized control where all decisions are made by one or two entities and the rest of the entities receives directions from them
- Delegated control where only the main decisions are made by one or two “main” entities, other decisions are delegated to lower level entities and coordinated among the entities.
- Dispersed control where decision making is spread out widely, with no easily identifiable coordinating entity or entities.
Centralized Control
- Should be used only when the solution is small and only a few decisions are involved. (easy to find control point)
- Lots of drawbacks:
- Centralized control can be “bloated” and too big to manage
- May be less cohesion when too much varieties of decisions are being made
- May increase coupling between the controller and other entities which merely act as data store or simple functions
- Information hiding can not be easily achieved
Central contrl
Heuristics to Avoid Centralized Control
- Avoid interaction design where most messages originate from single component
- Keep components small so that there can not be a “bloated” controller. (This is not very different from the traditional advise on keeping modules small - - - how small is small? --- cohesion?)
- Make sure that operational responsibilities are not assigned to just a few components.
- Make sure operational responsibilities are consistent with data responsibilities. (what happens if they are not? - - - you may have less cohesion among methods in a class )
Look at diagram 12-3-3 on page 386: it is an over-centralized control design:
- AutoCycle delegates nothing and is coupled with all other objects
- it lacks cohesion in that it is doing all types of details
- it is too big in size because it contains all the low level activities
Delegated Control
- Control is in more entities – smaller in size
- Information hiding is easier with different control points
- Increased cohesion with delegated points of control
- Each controller is coupled to less entities. (over-all # of couplings may not decrease)
Delegated contrl
Heuristics for Delegated Control
- Delegated control is the ideal case we are after.
- Ensure that each component is responsible for “high level” tasks and as much of the lower ( more detailed, less functional, just different functional areas, etc.) level tasks are delegated as possible.
- The lower level tasks may be performed in a more collaborative manner among several other components.
Look at diagram 12-3-4 on page 387, where AutoCycle delegates some
responsibilities to Zone. This is mush less coupled and more cohesive
design along with a certain amount of encapsulation of information.
Dispersed Control
- Too many controls and hard to figure out the interactions:
- Too much interactions among the entities – high coupling among the parts and possibly very low cohesion within each entity.
Heuristics for avoiding Dispersed control
- Basically, avoid situations where every component is sending a lot of messages to other components.
- Ensure that there is not an over-delegation, where each component is responsible for too a small portion of the whole and there are a lot of components involved in accomplishing anything.
Control and Communications
delegated &
hierarchical
centralized &
wheel
dispersed &
all-member
[(n x (n-1))/ 2]
potential coupling
(n-1) potential coupling
but deceiving because - -?
(n-1) potential coupling
but deceiving because - -?
Law of Demeter for OO Interaction Design
- An operation (method M) of an object, Obj, should send messages only to the following:
- Within the object, Obj, itself
- Methods within Obj
- Attributes of Obj (its instance variables)
- Argument of the operation (parameters of method M, which may be some object)
- Elements of a collection that is an argument of the operation or an attribute of the object, Obj.
- Objects created within the operation (objects instantiated within the method M)
- Global Classes or objects
The Law of Demeter is meant to help in : (1) information hiding;
(2) lessening centralized control
Note that objects that are returned by messages sent to other object is not included.
“ Talk only to your immediate neighbors”
Example from page 375 of text
- Design a water heater controller based on:
- Caldera is a smart water heater controller that attaches to the thermostat of a water heater and provides more efficient control of water temperature to save money and protects the environment.
- Caldera sets the water heater thermostat high when hot water is much in demand and sets it low when there is no much demand. For example:
- Caldera can be told to set the thermostat high on weekday mornings and evenings and all day on weekends.
- And low during the middle of the week days and nights.
- Caldera can be told to set the thermostat high all the time in case of illness or other needs.
- Caldera can be told to set the thermostat low all the time in case of vacation or some other prolonged absence from house.
Your Caldera Design may progress as follows:
heaterController
thermostat
set_temp
sd Caldera
heaterController
thermostat
set_temp( )
1. Class Model
2. Class
Interactions
Your Caldera Class Design (further Refinement) ?
heaterController
thermostat
set_temp
calendar
clock
manual
notify_time
notify_date
special_set
3. Further “Refined” Class Model
Your Caldera Interaction Design (further Refinement) ?
sd Caldera
heaterController
thermostat
Set_temp( )
Calendar
Clock
manual
Set_temp( )
Special_set( )
Notify_date( )
Notify_time( )
4. Refined Class Interactions in Sequence Diagram
Further Evaluate and Improve the Caldera Design
- Consider the notion of adding another entity to represent the notion of “load scaling” or “temp scaling” which traps the inputs from clock and calendar and sends the controller a binary high or low signal.
- Consider the manual override to go directly to thermostat and be equal to the controller.
Draw the Class diagram and the Sequence diagram for these concepts,
evaluate and see if they are indeed improvements:
- cohesion
- coupling
- size
Questions
New folder/L14. Dynamic Mid-Level State Based Design.ppt
Dynamic Mid-Level State-Based design
SWE 6653-Software Architecture
Chapter 13
Finite State Machines (FSM)
- An FSM consists of a finite set of input symbols, I, a finite set of states, Q, a specific state, S, called the starting state, and a transition function, F, from
{input x state} to {state}.
State Transition Diagrams
- A state transition diagram is a technique to depict:
- The states of an entity
- The transitions of states of the entity
- The trigger or the event that caused the transition of state of the entity
- The entity may be a physical device such as a light switch or a vending machine; it may be a software system or component such as a word processor or an operating system; it may be a biological system such as a cell or a human; or - - - -
Software Program View
- The end product of a software is a program which executes. In depicting the program (or an object) we can consider:
1. Variables which take on different values
2. Control structure and assignment statements in the program change the values of the variables
1. Combination of values of the variables at any point of the program represent the program state at that point.
2. The change made to the values of the variables through assignment statements represent a transition of state
A very simple example
light switch
From
State
(light)
to
State
(light)
Event
(switch)
on turnOff off
off turnOn on
“State transition table”
for light with switch events
on
off
turnOff
turnOn
“State transition diagram”
for light with switch events
A little more on the light switch
off
turnOff
turnOn
on
off
turnOff
turnOn
on
What happens if we turn on
a light that is already on?
turnOn
turnOff
state “transition” to its
current state
Using State Transition Diagram
- Model the entity at the level where the number of states is “manageable.”
Using State Transition Diagram
- Design (list) the number of states (should not be big)
- List the number of events that will trigger the state transition (should not be big)
- There must be an starting state
- There must be a terminating state or states
- Design the transition rules (where the bulk of your design work is)
- The above is not necessarily performed in sequence; iterate through these.
- Even with a modest number of states and events, the state transition diagram, which really depicts the transition rules, can be enormous.
Designing the Voice Recorder
(similar to example on page 397 of text)
- For the entity, voice recorder, design the states of this entity:
- How many states does ( somewhat based on requirement ) a voice recorder have?
- Set of recorder states = { off, on, play, record, erase, stop, error-msg }
- What are the initial and terminating states?
- Initial state = {off}
- Terminating state = {off}
- List the events that will change the state of the entity:
- What are the events that will change the recorder’s states?
- Input signals = { 1, 2, 3, 4, 5, 6 } which corresponds to:
{off, on, play, record, erase, stop}
Designing the Voice Recorder
(example from page 397 of text) – cont.
- Design the transition rules for the voice recorder
from state
to state
events
off 2 on
on 1 off
on 3 play
erase 6 stop
on 4 record
on 5 erase
play 6 stop
record 6 stop
stop 3 play
stop 4 record
stop 5 erase
stop 1 off
More transition rules:
1. Any state transition not described
here will transition to error-msg state
2. once in error-msg state, the system
“displays a message” and
automatically transitions to stop state.
off 1 off
{1=off, 2=on, 3=play, 4=record, 5=erase, 6=stop}
State Transition Diagram of
Voice Recorder
On
play
erase
record
stop
Error-msg
2
1
1
3
5
4
6
6
6
3
5
[always true]
1
4
Off
{1=off, 2=on, 3=play, 4=record, 5=erase, 6=stop}
Finite State Machine (more original usage)
S1
S2
S3
S4
0
0
0
0
1
1
1
1
M1 = {A, S, T, I, term}
where:
A = {0, 1}
S = {s1, s2, s3, s4}
T = {(s1,0)-> s2; (s1,1) -> s4; -----}
I = s1
term = s1
Pseudo code for the design of M1:
Read input string;
If input string includes non - 0’s or 1’s, error msg; break;
if input string length is odd number, error msg; break;
Set state = s1;
While (the string is non-empty)
{ ele = first element from the string
delete the first element from the string
if (state = s1 & ele = 0) then state = s2
if (state = s1 & ele = 1) then state = s4
if (state = s2 & ele = 0) then state = s1
if (state = s2 & ele = 1) then state = s3
if (state = s3 & ele = 0) then state = s4
if (state = s3 & ele = 1) then state = s2
if (state = s4 & ele = 0) then state = s3
if (state = s4 & ele = 1) then state = s1
}
if (state = s1) accept string
else error msg ;
end
M1 is a string checker that accepts all strings that contain even number of 0’s and 1’s
Example
- For an additional example, see page 400 (Vending Machine)
State Diagram Heuristics
- Label transitions
- Check that no arrow leaves a final state
- Label states with adjectives or verb phrases
- Name events with verb phrases or with noun phrases describing actions
- Name actions with verb phrases
- Combine arrows with the same source and target states.
READ AT LEAST ONE EXAMPLE FROM THE TEXT ON YOUR OWN.
Questions
New folder/L15. Low-Level Detailed design.ppt
Low-Level Detailed Design
Chapter 14
Low-Level Detailed Design
SAD
(Soft Arch Design)
Mid-level
Detailed Design
Low-Level
Detailed Design
Design Finalization
Design
Document
Low-level Detailed Design
- Once mid-level design is complete (Class, interactions among Classes, state transitions of the class/system), there are a few more topics that need to be explored at the detail level:
- Packaging and Information Hiding (visibility and accessibility)
- Operation Specification to provide more processing details
- Details of algorithms and data structures
- Design Finalization
Information Hiding
- Information Hiding is a Design Principle discussed earlier that applies to every level of design
- Information Hiding is the hiding of design decisions in a system that are most likely to change so that other parts of the system will be minimally impacted should the design really change.
- The techniques of information hiding includes:
- Limiting visibility
- Not extending access
Notion of Visibility
- A program entity (a variable, a module, a class, a method, etc.) is visible at some point in a program if it can be referred to by name at that point.
- The portion of the program where a program entity is visible is the entity’s visibility
Types of Visibility
- Local visibility: the programming entity is visible only within the module where it is defined.
- Non-local visibility: the programming entity is visible outside the module where it is defined, but not visible from everywhere.
- Global visibility: the programming entity is visible from everywhere.
In general, we want to design our program entity to be visible in as small a
region as possible to minimize any impact to potential future changes.
OO Visibility and Types of Visibility
- Public visibility : entity may be global or non-local depending on whether the entity is defined as public in a public Class (global) or in a non-public Class (non-local)
- Package visibility: entity is non-local in that it is visible in the Class where it is defined as well as all Classes in the same package
- Protected visibility: entity is non-local in that it is visible in the Class where it is defined and all its sub-classes
- Private visibility: entity is local in that it is only visible within the Class where it is defined
Notion of Accessibility
- A program entity is accessible at a point in a program if it can be “used” (read or change its value) at that point.
- A program entity is accessible everywhere it is visible. But it may still be accessible when it is not visible. { visible is a subset of accessible}
- Accessing a variable without visibility can happen when we operate with “pointers” or “reference”
- Making a variable accessible in a portion of the program where it is not visible is called “extending access beyond visibility”
Generally, we should not extend access beyond visibility except possibly for:
- sharing of the variable
- performance
Information Hiding Heuristics
- Limit Visibility:
- Make program entities visible in the smallest possible program region
- Restrict the scope of declarations to the smallest possible program region
- Make Class attributes at least protected and preferably private
- Make class helper operations at least protected and preferably private
- Avoid global visibility
- Avoid package visibility
- Don’t Extend Access:
- Use “defensive copies” instead of actually changing the original variable when the “pointer” of the variable is passed
- Don’t pass parameters by reference (pointer)
- Don’t make aliases
Operations Specifications
- At the low-level detailed design we need to specify more details than the Class, interactions among class, and the state transitions. We need to provide more details in an Operations Specification concerning the behavior of the program:
- Class or Module: identify the operation
- Signature: the operation name, interfaces (parameter types and return type) ---- the “syntax” of the operation
- Description: couple of sentences describing the operations responsibilities
- Behavior: a detailed account of what the operation does, any constraints on the parameters and operations, what exception handling is performed, etc. ----- the “semantics” of the operation
- Implementation: Additional details on algorithms and data structure used for the implementation
More on Behavior Specification
- 2 ways to describe the behavior
- Declarative: describe the inputs, constraints on the operations, and the resulting outputs
- Procedural: describes the sequence of steps that transforms the inputs to the outputs (even though the programmer may choose another algorithm to implement the behavior)
The preferred way is to use the declarative specification unless there is
a specific algorithm or data structure that the designer wants the programmer
to use.
Example from page 441 of text
public static int findMax ( int [ ] a )
throws IllegalArgumentException
Declarative specification: The operation findMax accepts a non-null
array of integers with at least one input and
returns the largest value element of that array
of integers
Procedural specification: - The operation findMax is public and static because the
method can be invoked through the name of the Class
- It accepts a non-null array of integers.
- If the array is null or has no element, then an
IllegalArgumentException is thrown.
- Otherwise, the operation saves the first element
of the array in a variable, temp-max. Then each of the
remaining array elements is compared against the
variable temp-max. If anyone of the array elements is
larger in value than temp-max, then that element is placed
in temp-max. This continues until all the array elements have
been compared against temp-max.
- The final value in the variable temp-max is returned.
Declarative Specification & “Contract”
- A Contract is an agreement between the “caller” and the “provider” of the operation.
- Caller is obliged to provide valid arguments and perform the call under the correct circumstances
- Provider is obliged to provide the services, if the caller has conducted all its obligations properly.
One way to specify the contract between the Caller and the Provider is to
specify the pre-condition and the post-condition of the operation.
- pre-condition : asserts the conditions that must be true at the initiation
of an operation.
- post-condition: asserts the condition that must be true at the completion
of an operation.
Example of Pre-Post conditions
public static int findMax ( int [ ] a )
throws IllegalArgumentException
Pre: ( int[ ] a is not null ) AND (array a length is > 0 )
Post: throws IllegalArgumentException if pre-condition is not met.
Post: for every element, a[i] of array a, a[i] <= temp-max for all i.
Post: return the value of temp-max
Do we need to clarify what “temp-max” is ?
Invariants
- Besides the pre and post conditions, we can also specify those conditions that are true between calls to the operation. These assertions are invariants. Invariants need to be part of the Operation Specification along with pre and post conditions.
- For a Class, invariants
- Must be established by Class constructors
- Must be preserved by every exported operation in the Class
1. In the findMax operation, an “invariant” condition is that the variable temp-max contains
an integer. (It is initialized with the first element of the array, which is an integer, and
temp-max may only be replaced by another array element which is an integer. )
2. Another invariant condition is that (min of array a) <= temp-max <= (max of array a).
Heuristics for Specifying Pre, Post and Invariant
Conditions of the Operation’s Behavior
- Pre-conditions:
- Specify restrictions on parameters
- Specify conditions that must already be established
- Specify empty conditions as either (true or none)
- Post conditions:
- Specify relationships between the parameters and the outcome
- Specify restrictions on the outcome
- Specify any changes to the parameters (e.g. parameters by reference)
- Specify responses to violated preconditions (e.g. exceptions)
- Invariant conditions:
- Specify restrictions on attributes
- Specify relationships among attributes
Operational Specification
- Class name and Signature (or module name and signature)
- Brief Description of the operation’s responsibilities
- A detailed specification of the operation’s Behavior using:
- Declarative specification:
- Pre-conditions
- Post conditions
- Invariants
- Procedural specification:
- Showing step by step algorithms and data structures
Details of the “Procedural” Specification
- Algorithm in the form of;
- Pseudo-code: English augmented with some programming language statements.
- Natural language statements and symbols.
- Data structure in the form of:
- Tree
- Table
- List
- etc.
Abstract Data Type (ADT) is a combination of :
(a) data structure
(b) operations to manage the data structure
Design Finalization
- Complete the Low-Level Detailed Design with a review of the “last” design document and a final review of all the previous design material:
- Software Architecture Document (SAD)
- Detailed Design Document (DDD)
- Low-Level Design in the DDD
Design Finalization Review
- The designers check the design for:
- Completeness (all of the DeSCRIPTOR items and the details of packaging, interfaces, algorithms and data structure)
- Well-formedness (proper notations)
- Clarity (organized and easy to read)
- Consistency (no conflict)
- After the above is fixed, then the design is checked for:
- Feasibility (can be implemented)
- Adequacy (meet the functional and non-functional requirements)
- Economy (meet the budgetary and schedule requirements)
- Changeability (meet the requirements of maintenance/support)
Questions
New folder/L16. Architectural Styles.ppt
Architectural Styles (Patterns)
Chapter 15
Architectural Styles
- An Architectural Style defines a set of rules that describe
- the properties of and constraints on its components and
- The way in which the components interact
Architectural Styles (Patterns)
- Architectural Styles may be viewed as a set of Architectural Design solutions that have been used successfully before.
A software design pattern is a model for a class of solutions to a software design problem. At high level we call these patterns architectural styles.
- These styles (or patterns) offer multiple benefits:
- Promote communications among the designers because the pattern names are used as a shorthand for a lengthy description
- Streamline documentation for the same reason above (last slide)
- Support high level of reuse if the pattern is applicable
- Improve development efficiency and productivity for above reasons and not having to profile or prototype all the existing patterns
- Provide a starting point for additional and new design ideas.
Software Design Patterns
- Software Design Patterns is a recent event, although programming level patterns have been studied in our industry such as Sorts, Search, Access Methods, etc.
Design Patterns come in different levels
1. - the high level architecture is not detailed enough and should only serve as a guideline pattern for further
refining
2. - the middle level ones is where the current work is focused on and may be domain dependent
3. – The low level ones (e.g. data structures and algorithms) have been employed relatively successfully via provided libraries
- A building architect named Christopher Alexander introduced building designs based on “patterns” in the 1970’s and catalogued these designs in a book.
- Has not been widely accepted by building architects
- But has influenced the software design community in the last 15 years in terms of cataloguing and using design patterns
Major Architectural Styles (Patterns)
- Layered Architecture
- Pipe and Filter
- Shared (Central) Data Store
- Event Driven
- Model-View-Controller (MVC)
- “Distributed & Emerging” Service Oriented Architecture (SOA)
Layered architecture
Screen
Presentation layer
Logic layer
File layer
1. If any layer only uses the layer directly below
it, then it is a Strict Layered Style.
2. If a layer may use any of the layers below it,
then it is a Relaxed Layer Style
Problems that seem to fit this architecture include tele-comm and op-sys
Layered architecture
- The high level design solution is decomposed into Layers:
- Structurally, each layer provides a related set of services
- Dynamically, each layer may only use the layers below it
- Using and evoking is not necessarily the same
- Layer A may use layer B because it depends on something B does (e.g. data written to a db by B to be used by A), but never call upon it.
- Layer A calls layer B says Layer A passes control or data or both directly to B.
Simple Example with “Mailing Address” Processing
Recipient Name
Street
City
State
Country
Mail processing to establish which delivery plane/truck to distribute the US Postal mail
The sequence is from top layer to the lower layer.
A Simplified “Experiential” Discussion
customer
info valid.
update
order
info valid.
product
info valid.
add
update
update
delete
add
add
delete
delete
Information i/o Layer
cust info in
ord. info in
prod info in
Viewing and designing directly from
functional requirements
Viewing from internal structure
Ending up with layered architecture
Cust. Info
validation
product Info
validation
. . .
Information validation Layer
Info Processing Layer
Add, Delete, and Update
Sample Layered Architecture for OS
Resource (I/O, page,
network, file, etc.)
management
Utilities (editors, sys commands,
compilers, internet
access, libraries, etc.)
kernel (Device & memory
Processing) drivers
Process (classification &
management)
Sample Layered Communications Architecture
Application layer
Presentation layer
Session layer
Transport layer
Network layer
Data Link layer
Physical layer
Advantages and Disadvantages of
Layered Architecture
Advantages
- Each layer is selected to be a set of related services; thus the architecture provides high degree of cohesion within the layer.
- Each layer may hide private information from other layers
- Layers may use only lower layers, constraining the amount of coupling.
- Each layer, being cohesive and is coupled only to lower layers, makes it easier for reuse by others and easier to be replaced or interchanged (change of DB touches only the data store/access layer)
Disadvantages
- Strict Layered Style may cause performance problem depending on the number of layers
- Debugging in Strict Layered Style may be complex (questionable?)
- May be difficult to decide on the number of layers
Pipe and Filter Architecture
- Main components:
- Filter: process a stream of input data to some out put data
- Pipe: a mechanism that allows the flow of data
read input file
process file
filter
pipe
This architecture style focuses
on the dynamic (interaction)
rather than the structural
Pipe-Filter architecture
- The high level design solution is decomposed into 2 parts (filters and pipes):
- Filter is a service that transforms a stream of input data into a stream of output data
- Pipe is a mechanism or conduit through which the data flows from one filter to another
Input
time cards
Prepare for
Check processing
Process Checks
Problems that require batch file processing seem to fit this: payroll and compilers
An Example
- See Page 474 of textbook
Pipe – Filter with error processing
- Even though interactive error processing is difficult, but batch error processing can be done with pipe and filter architecture
Input
time cards
Validate for
payroll processing
Automatically
Process Checks
Manually Reprocess
Card and Cut Check
Payroll report
Do the data streams
need to be synchronized
here for report?
Splitting the good time
cards from the bad ones
Advantages and Disadvantages of
Pipe-Filter
Advantages
- Filters are self containing processing service that performs a specific function thus it is fairly cohesive
- Filters communicate (pass data most of the time) through pipes only, thus it is constrained in coupling
Disadvantages
- Filters processes and sends streams of data over pipes is a solution that fits well with heavy batch processing, but may not do well with any kind of user-interaction.
- Anything that requires quick and short error processing is still restricted to sending data through the pipes, possibly making it difficult to interactively react to error-events.
Shared Data
- The high level design solution is based on a shared data-store which acts as the “central command” with 2 variations:
- Blackboard style
- Repository style
- Blackboard style:
the data-store alerts the participating parties whenever there is a data-store change
- Repository style:
the participating parties check the data-store for changes
Shared Data
Patient
database
physician
diagnosis
pharmacy &
drug processing
Lab testing
accounting
& administration
Very
Common
In
Business
where
Data is
central
- Problems that fit this style such as patient processing, tax processing system, inventory control system; etc. have the following properties:
1. All the functionalities work off a single data-store.
2, Any change to the data-store may affect all or some of the functions
3. All the functionalities need the information from the data-store
Blackboard Style & DB triggers
- In database management system we can set up a trigger which has 3 parts:
1) Event
2) Condition
3) Action
1) Event :
change to the database that alerts or activates the trigger
2) Condition:
a test that is true when the trigger is activated
3) Action:
a procedure which is executed when the trigger is activated and the condition is true.
1) A trigger may be thought as a monitor of the database for changes to the database that matches the event specification (e.g. deletion of record) .
2) Then the condition is checked to see if it is true (e.g. deleted record has negative accnt amount).
3) If the deleted record has a negative accnt amount, then kick off a procedure to send error message out and delay the execution of record deletion.
Advantages and Disadvantages of
Shared Data
Advantages