Architecture Design
• Architecture design ---- used in verb form
Rephrased from page 254 of text
Architecture design is a problem-solving activity whose
input is the SRS document and whose output is the
“abstract” specification of a software solution which
realizes the desired characteristics
What does “abstract specification” really mean ----? Does it have anything to do with
the problem solving technique of abstraction – where only the “major” components ,
their “major” responsibilities and characteristics, and their “major” relationships are
described ?
Architecture Design
• Architecture design - - - used in a noun form
Also, rephrased from page 254 of text
Architecture design is a specification (document) of
the solution’s major components, their
responsibilities and properties, and the relationship
and collaboration among the major components.
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 “basic”
design principles:
– (Feasibility): During Product Design, we may need to
understand the feasibility of some specific architecture by
creating a “prototype”
– (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
Requirements
(Product Design)
Architectural
Design
Detail Design
Variations in Architectural Design
•
Not all architectural designs are the same in terms of their level
of abstraction:
1.
2.
3.
•
number of components (main components),
description of each component
relationships among components
Two important Considerations:
–
Problem context: the larger the problem the more levels of
abstraction, # of components, # of relationships among
components
–
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
Deciding on the “right” level of architectural depth has always been a problem!
Introduction To Architectural Design
Architectural Design Process
Swft Engr. Design
SRS
Analyzed
SRS
Design
Analysis
Evaluate Architectural
Alternatives
Architectural
Design
Detail
Design
Develop Architectural
Alternatives
Design
Doc.
Select Architectural
Resolution
[else ]
[selected ]
Finalize Software
Architectural Document
SAD
Software Architecture Document (SAD)
Content
1.
Product Overview: summarizes the overall product
description, stakeholders and target market descriptions,
key assumptions and constraints, and the basic business
requirements (or refer to SRS document)
2.
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)
The “meat’ of the document are the sections that describe the different models
and the relationship among the models; but don’t forget the rationale
Discussion not in your Textbook
Decompose into main components ----one of the first considerations of DeSCRIPTR
How do we do this ?
Is there some guidance?
Components based on Functionalities?
Component Relationship based on:
Central Control oriented (e.g. Hierarchical) vs
Distributed control (e.g. OO)?
think about your Solar System again -----
• Architectural “styles” --- we will introduce
you to some standard ones later, but ---- can
you think of one?
Design of Non-Functional Requirements
• Major Functional Requirements can be directly
mapped into key architectural components, but how
about “non-Functional requirements (or attributes)”?
– Operational Attributes (for users):
•
•
•
•
•
Performance: time limits, space capacity, transaction limits
Availability: readiness for use (borders on performance)
Security: resistance or protection from harm
Reliability: error resistance and performing to requirements
Usability: easy to understand and navigate
– Developmental attributes (for software engineers):
• Maintainability: easy to understand (cohesive) and modify
• Reusability: portable, easy to modify, loose coupling, etc.
Note:
Your text
calls these
“quality”
attributes
(p.257)
- Architectural Design of Functional requirements is much more straightforward.
- The non-Functional requirements puts constraints and forces one to look for
alternatives in architecture; some nonfunctional requirements turn into functional
solution (e.g. security)
Non-Functional Considerations for Architects
For class discussion ---- not in text book
•
Performance: number of transactions per second ---- how would we
assess this ?
– (# of instructions per transaction) x (time/instruction) = time/transaction
•
Availability: percentage of system up-time ---- how would you assess
this?
– # of hours up/ total hours ----- architect needs to think about what brings the
down time. (include design for performance scalability and redundancy?)
•
Security: percentage of non-compromised data ---- how would you
assess this?
– # of non-compromised tables/total number of tables per year ---- what could
cause table compromise (bad or improper inputs)?
•
Reliability: number of defects in the product ----- how would assess this?
– # of problems/10,000 usage-hour ----- defect causes? (input processing,
algorithm, output processing, interface, etc.)
•
Usability: customer satisfaction ----- how do we assess this as
architects?
– # of discrete steps to functional completeness
human psychological bounds?)
(worst case number versus
(from P.258 of text) “Finger Print Matching”
• Functionalities: A system-program responsible for
matching fingerprints read from scanners against a
file/database to allow people into and out of a
“secure” facility.
• Non-Functional: 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.” (note: mostly
usage/operationally oriented as opposed to software
engineering oriented --- e.g. nothing about how to
build this or maintain this)
Fingerprint Matching “Design” via Decomposition
Example Using “cooked up” box and line notation
(p 258 –text)
Fingerprint
Reading
device
“matching --against a database”
Input
validation
Fingerprint
validation
validating “fingerprints”
read from scanners
Finger
Print
DB
Fingerprint Matching Software “Initial Design”
Example Using Activity Diagram notation to
portray activity flow (p 258 –text)
Fingerprint Matching Architecture
fingerprint
input
Input validation
[bad input]
Fingerprint
Reading
device
Finger
Print
DB
What about these?
error
message
[good input]
fingerprint validation
Set-up / send message
pass/
no-pass
message
Fingerprint Matching “Design Refinement”
Example Using Activity Diagram +
(p 258 –text)
Input validation
Fingerprint
Reading
device
Fing_prt
input
validate
input
[else]
1.Easier to handle functions.
Error
message
[good print]
2. BUT what about ? :
- performance
- reliability
- security
- availability
3. Do we need to depend on
experience and insights to
design these non-functional
requirements?
- how about design pattern?
Error
process
Evoke
F-prt-digi
Digitized
Fing prt
Dig. Finger
Print
DB
Fing_prt
table
Digitized
Fing prt
Fingerprint validation
validate
F-print
Pass/No-pass
message
Compare this with box-and line diagram on page 265 of text – it’s “broader”
What about these “non-functional” attributes?
“respond quickly” - Performance
1.
–
–
–
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?
“must be available the entire time - - -” - Availability
2.
–
–
–
–
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?
“must perform matching at a reliable rate” – Reliability
3.
–
–
–
–
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?
“must resist attacker” – Security
4.
–
–
–
–
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 for
system maintenance to activity diagram
How do we show physical protection on the activity diagram?
What about Cohesion and Coupling?
• Had we put input validation and fingerprint validation
together as “validation”---- would we have some issue
related to “cohesion?”
– Input validation: a single related function
– Fingerprint validation: a single related function
• Now that we have separated these two, what is the issue
on “coupling?”
– Digitized fingerprint passed from input validation to fingerprint
validation ( one finger print at a time --- or can we batch the
fingerprints for performance reason?)
- Is there some other way to “cohesively” Decompose and
Integrate with “minimal coupling” ?
Affinity of Data and Processing
• Recall our earlier discussion of (Cohesion)
“processing where the data is kept”
concept?
– How does that apply to the fingerprint processing
software ?
• Where is the input data? --- processed at input validation
“module”
• Where is the fingerprint data? --- processed at the
fingerprint validation “module”
For OO aficionados:
Should these be two different Methods within the same FingerPrint Class
or possibly two different Classes, :ScannerValidator and IdentityValidator ?
Specifying Architecture Design
•
There are both static structure and dynamic
behavior models to specify.
There are various notations that may be used:
•
–
–
–
Box-and-Line diagram (in this lecture note)
Text
UML
1.
Activity Diagram √
2.
Use Case diagram √
3.
4.
5.
6.
Class diagram √
Interaction diagrams : sequence, communication, timing, overview
State diagram
Package, Component, and Deployment diagrams (in this lecture)
A Table of Notations and their usage for
DeSCRIPTR
Type of Specification
Possible Notations to Use
1. Decomposition
box and line diagrams; class diagram;
package diagrams; component
diagrams; deployment diagrams
2. States
state diagrams
3. Collaborations
sequence and communication
diagrams; activity diagrams; box and
line diagrams; use case model diagrams
4. Responsibilities
text; box and line diagrams; class
diagrams
5. Interfaces
text; class diagrams
6. Properties
Text; class diagram
7. Transitions
state diagrams
8. Relationships
Box and line diagrams; component
diagrams; class diagrams; deployment
diagrams; text
Box-and-Line Diagrams
•
This is a notation of boxes (figures) and lines which
connect the figures that represent “components.”
–
–
•
Has no specific notation besides box and line
May be used to represent either static or dynamic modeling,
but mostly for static modeling
There are some guidelines:
1.
2.
3.
4.
5.
Use box-and-line only when there is no standard notation
that can meet the needs
Make boxes for different items look different
Be consistent in using the symbols and figures
Use noun-phrase to name things (information) and verbphrase to name actions
Don’t mix static and dynamic elements
Box-and-Line chart should employ a legend to help clarify the symbols.
Textual Notation
•
Text is very useful in specifying items that are not easy to
describe with graphical notations such as:
•
•
•
•
•
clarity
Responsibilities (details of)
Relationships (details of)
System/Program Interfaces (not just user interface)
Properties (especially non-functional properties such as availability)
Some guidelines on using Text:
1.
2.
Write good technical prose using meaningful names when specifying
responsibilities and relationships in an architecture
Use a template to specify interfaces:
–
–
–
–
3.
4.
Services provided
»
Syntax
»
Semantics
»
Pragmatics
Services required
Usage guide
Design rationale
See page 264 of text for an example
of a template usage
Use pre-condition & post-condition to help describe semantics and
pragmatics of interfaces
Specify properties and attributes with the help of scenarios
A Simple example of syntax, semantics &
pragmatics
•
Syntax Example:
– IO_Routine (IOCntrl: integer) : return_type
– The parameter IOCntrl may take on the integer values of 0,1,2, or 3
•
Semantics:
– This method provides the service of performing different I/O functions
based on the IOCntrl parameter and returns a success/failure code
– IOCntrl values:
0 – do nothing
1 – read information
2 – write information
3 – update information
•
Pragmatics:
– The passed integer type IOCntrl parameter is not to be operated on as an
integer, but just as a control information that can be evaluated.
– For example, IOCntrl of 3 does NOT mean 1 + 2, even though 1+2 =3 and
read followed by write may be the same as update.
What’s pre-condition and post-condition?
• Pre-condition : state of the system or the component
or the entity that must be true prior to the
“operation” of interest.
– Only consider the attribute (or “state”) that matters
• e.g. The input coming in from the fingerprint scanner is
“valid” [e.g. meaning “input is “90% digitizable”] prior to
evoking the fingerprint digitizer function.
• Post-Condition: state of the system or the
component or the entity that must be true at the
conclusion of the “operation” of interest.
– Only the consider the attribute (or state) that matters
• e.g. digitized fingerprint is produced
In stating the pre and post condition, we have also been forced to think of
error or alternative conditions --- (e.g. if the input is valid, the digitizer will
NOT fail ----- regardless of any other reason?)
How do we attach many of the “textual”
information to a graphical design notation
such as UML?
• For UML use:
– “Notes”
– “Extensions”
Some “COMMON” UML concepts/notations for design
• Note: any explanation, in text form, attached to a model element;
this is helpful in explaining the design, especially the design for
non-functional requirements
– UML notation is a “dog-eared” box connected to the model element
by a dashed line
• Extensions: a mechanism to extend the notations of UML
elements to further characterize the design of the element
– Constraint is a restriction on the design element written as text
inside {- - - } in UML.
– Properties is an attribute of a design element written as tagged
values inside { tag = value} in UML. If tag has a Boolean value of
true, then just the tag without the value can suffice. (e.g. {constant})
– Stereotype is an additional explanation about the modeled element
to give more meaning. It is written in text form as keywords in side
<<keyword>> in UML notation. (Some use this to explain the level of
perspective of the design element)
Constraints, Properties, and Stereotype extensions may be placed next
to the applicable element. If it applies to multiple design elements, then
a dashed line may be used to connect the extension to multiple elements
More “COMMON” concept/notation : Dependency
• A Dependency: is a binary relationship between 2 elements such
that changes to one (independent) element may cause changes to
the other (dependent) element.
(e.g. A is “dependent” on B)
– A uses B
– A compiles with B
– A imports data from B
• A dashed arrow is used to portray dependencies in UML (points
from the dependent to the independent entity)
{regional}
{regional}
sales
<<imports>>
expenses
{HQ}
accounting
Adds all
sales and
subtracts
all expenses
net: real
{net = *.xx}
<<imports>>
- {regional} and {HQ} are properties
- <<imports>> is a stereotype
- {net =*.xx} is a property/constraint
- dog-eared explanation is a note
about the algorithm( )
algorithm( )
*Note: { - - -} used for both property and constraint
Logical and Physical Architecture
• In the example of fingerprint matching
architectural design, both logical and
physical entities were mixed in the diagram.
• To be clearer, we sometimes differentiate the
two as:
– Logical Architecture
• A configuration of the major components and their
relationships to one another at the abstract level
– Physical Architecture
• A configuration of the components and their
relationships to each other at the realization level (as
code and data residing on and executing on physical
computational resources).
Logical Architecture Represented with
Package and Component Diagrams
• A Package is a collection of model elements
(components) that represent a grouping of logical
constructs (components) where
– the elements of a Package (logical grouping) should be
“related”
– the relationships among the elements should be shown
• A Component is a reusable & replaceable construct
which is used as a member of a package or as a self
standing entity by itself. As such it has the following
characteristics
– The details of its internals are often hidden
– ** The interfaces must be “extremely” clear (well defined)
This is key
UML Diagrams of Package Design
for grouping of related entities
A
Financial app
Basic Package symbol, with a tab
A
B
Package A composed of Package B
and Package C, each with its elements
C
- note the difference in representing
composition in Package B and
Package C
A
financial
<<uses>>
K
regulatory
A relationship of Package A
useing Package K
UML Diagram of Component Design
for Reusable and/or Replaceable Component
<<component>>
MathPack
<<component>>
StatsPack
<<component>>
MathPack
<<component>>
MathPack
MathPack
Two ways to denote component
Provided interface to be “called” by others
Required interface to “call” others
<<component>>
StatsPack
component MathPack uses
the required interface to
access the provided
interface of StatsPack
component
Modeling the constituents of a Component
<<component>>
DrawFigures
Draw2D
Draw3D
<<delegate>>
ScreenDisplay
<<delegate>>
UnZipData
ZippedData
The “delegate” connector ties the component interface to one or more internal
Components (in this case --- to UnZipData internal component)
Component Design can/may already influence
implementation
interface Drawfigures {
public unZipData( );
public pict draw_meth ( ) ;
}
class Draw2D implements Drawfigures
{ .
.
.
}
class Drawfigures {
.
.
protected unzipd data
.
public void unzip (zipd x, int cntrl ) ;
protected Draw2D ( );
protected Draw3D ( );
.
Class Draw3D implements Drawfigures
{ .
.
.
}
( A – java language interface implementation )
}
( B – more likely single Class
implementation)
Alternative ways to Specify Component
(A)
(B)
<< component>>
OrderProc
OrderEntry
<< provided interf.>>
OrderEntry
InventoryProc
<< component>>
OrderProc
<< required interf.>>
InventoryProc
These 2 diagrams portray the same concept
OrderProc component provides the interface for OrderEntry
and requires the interface to InventoryProc by some other component.
Component Interface “forms”
•
What forms do these interface come in?
1.
2.
•
Transfer of control
Transfer of information
More specific examples?
–
–
–
Protocol (e.g. network)
Database linkage (e.g. SQL link between app and db)
Procedure calls (e.g. invoking a method)
–
–
–
Shared variable access (e.g. “global” variable)
Buffers (e.g. I/O buffers, paging)
Table entries (e.g. shared db table)
Are we constrained by the “implementation” language and “middleware” language ?
More items to consider for Component Interface
• How do we specify certain properties about the
component interfaces ?
– Is the communications always one way from component A
to component B; what do we do if we care about two way
communications?
– What do we do about synching --- if component A wants to
send data to component B but B is not ready; do we have to
define a “buffer’ for resend?
– What if the material component A sends to component B is
not understood by component B; should there be error
messages and retry - - - and how many retries?
– ** What do we do about the “required” interface if there
needs to be more than one or if it changes** ?
** If more interested in this topic ---- search on the topic “software connectors”
Also, think about “coupling” both static and dynamic cases
Physical Architecture
• Physical architecture is a representation of the
design entities in terms of artifacts residing on
nodes where:
– Artifacts are physical representation of logical entities
produced – documents, code, messages, database tables,
screens, etc. This definition makes sense to you ?
– Nodes are computational resources such as a device or an
execution environment:
• Devices may be printers, cpu, controller, etc.
• Execution environment may be a db system, os, etc.
<<db artifact>>
AccntTable
<<device>>
HP100:printer
Artifact notation for
an AccntTable, a db table
Node notation for a device
named HP100 of type
printer
UML Deployment Diagram to Represent
Physical Architecture
•
A Deployment Diagram shows:
1.
2.
3.
Computational resource (nodes)
Communication path between computational resources
Artifacts that reside and execute on the computational resources
<<device>>
HP3100:ServerPC
<<TCP/IP>>
<<artifact>>
AppCode
<<TCP/IP>>
<<device>>
ClientPC
<<artifact>>
ScreenBrowser
<<CPU device>>
IBM201: Server
<< data base syst.>>
Oracle14:db
<<artifact>>
<<artifact>>
AppData
DataTable