Software architecture
is a representation that enables a software engineer to
Analyze the effectiveness
of the design in meeting stated requirements
Consider architectural
alternatives
Reduce the risk associated
with the construction of the software
Examine the system as
a whole
Why Is Architecture
Important?
Enable communication
between all parties (stakeholders) interested in the development of a computer-based
system.
Highlights early design
decisions that will have a profound impact on all software engineering
work that follows and on the ultimate success of the system as an operational
entity.
Architecture "constitutes
a relatively small, intellectually graspable model of how the system is
structured and how its components work together".
Data Design
refine data objects
and develop a set of data abstractions
implement data object
attributes as one or more data structures
review data structures
to ensure that appropriate relationships have been established
simplify data structures
as required
Data Design Principles
Systematic analysis
principles applied to function and behavior should also be applied to data.
All data structures
and the operations to be performed on each should be identified.
Data dictionary should
be established and used to define both data and program design.
Low level design processes
should be deferred until late in the design process.
Representations of data
structure should be known only to those modules that must make direct use
of the data contained within in the data structure.
A library of useful
data structures and operations should be developed.
A software design and
its implementation language should support the specification and realization
of abstract data types.
Architectural Styles
Each style describes
a system category that encompasses:
a set of components
(e.g., a database, computational modules) that perform a function required
by a system
a set of connectors
that enable “communication, coordination and cooperation” among components
constraints that define
how components can be integrated to form the system
semantic models that
enable a designer to understand the overall properties of a system by analyzing
the known properties of its constituent parts.
Data centered
- data store (e.g. file or database) lies at the center of this architecture
and is accessed frequently by other components that modify data
Data flow -
input data is transformed by a series of computational or manipulative
components into output data
Call and return
- program structure decomposes function into control hierarchy with main
program invokes several subprograms
Main program/subprogram
architectures: Classic program structure decomposes function into a
control hierarchy where a "main" program invokes a number of program components,
which in turn may invoke still other components.
Remote procedure
call architectures: Components of a main program/subprogram architecture
are distributed across multiple computers on a network
Object-oriented -
components of system encapsulate data and operations, communication between
components is by message passing
Layered
- several layers are defined, each accomplishing operations that progressively
become closer to the machine instruction set
Architecture Design
Assessment Questions
How is control managed
within the architecture?
Does a distinct control
hierarchy exist?
How do components transfer
control within the system?
How is control shared
among components?
What is the control
topology?
Is control synchronized
or asynchronous?
How are data communicated
between components?
Is the flow of data
continuous or sporadic?
What is the mode of
data transfer?
Do data components exist?
If so what is their role?
How do functional components
interact with data components?
Are data components
active or passive?
How do data and control
interact within the system?
Architecture Trade-off
Analysis Method
Collect scenarios
Elicit requirements,
constraints, and environmental description
Describe architectural
styles/patterns chosen to address scenarios and requirements:
Identify sensitivity
points for architecture (any attributes significantly affected by variation
in the architecture)
Critique candidate architectures
(from step 3) using the sensitivity analysis (conducted in step 5)
Architectural Complexity
(similar to coupling)
Sharing dependencies
- represent dependence relationships among consumers who use the same resource
or producers who produce for the same consumers
Flow dependencies
- represent dependence relationships between producers and consumers of
resources
Constrained dependencies
- represent constraints on the relative flow among a set of components
Mapping Requirements
to Software Architecture in Structured Design
Establish type of information
flow:
transform flow
- overall data flow is sequential and flows along a small number of straight
line paths
transaction flow
-
a single data item triggers information flow along one of many paths
Flow boundaries indicated
DFD is mapped into program
structure
Control hierarchy defined
Resultant structure
refined using design measures and heuristics
Architectural description
refined and elaborated
Transform Mapping
Set of design steps
that allows a DFD with transform flow characteristics to be mapped into
a specific architectural style
Example:
Steps:
Review fundamental system
model with an evaluation of both the System Specification and the
Software
Requirements Specification
Context level DFD for SafeHome
Review and refine data
flow diagrams for the software
Level 1 DFD for SafeHome
Level 2 DFD that refines the monitor sensors
process
Level 3 DFD for monitor sensors with flow boundaries
Determine whether the
DFD has transform or transaction characteristics
Isolate the transform
center by specifying incoming and outgoing flow boundaries
Perform first level
factoring
Top-level modules perform
decision making
Low-level modules perform
most input, computation, and output work
Middle-level modules
perform some control and do moderate amounts of work
e.g First-level factoring
for monitor sensors
An incoming information
processing controller, called sensor input controller, coordinates receipt
of all incoming data.
A transform flow controller,
called alarm conditions controller, supervises all operations on data in
internalized form (e.g., a module that invokes various data transformation
procedures).
An outgoing information
processing controller, called alarm output controller, coordinates production
of output information.
Perform second level
factoring
Map individual transforms
(bubbles) of a DFD into appropriate modules within the architecture
Refine the first iteration
architecture using design heuristics for improved software quality
Transaction Mapping
Example
Level 2 DFD for user interaction subsystem
with flow boundaries
Review fundamental system
model
Review and refine data
flow diagrams for the software
Determine whether the
DFD has transform or transaction characteristics
Identify the transaction
center and flow characteristics along each action path
Map the DFD to a program
structure amenable to transaction processing
Transaction mapping
Factor and refine the
transaction structure and the structure of each action path
Refine the first iteration
architecture using design heuristics for improved software quality
Define interaction in
such a way that the user is not forced into performing unnecessary or undesired
actions
Provide for flexible
interaction (users have varying preferences)
Allow user interaction
to be interruptible and reversible
Streamline interaction
as skill level increases and allow customization of interaction
Hide technical internals
from the casual user
Design for direct interaction
with objects that appear on the screen
Reduce User Cognitive
(Memory) Load
Reduce demands on user's
short-term memory
Establish meaningful
defaults
Define intuitive short-cuts
Visual layout of user
interface should be based on a familiar real world metaphor
Disclose information
in a progressive fashion
Make Interface Consistent
Allow user to put the
current task into a meaningful context
Maintain consistency
across a family of applications
If past interaction
models have created user expectations, do not make changes unless there
is a good reason to do so
User Interface Design
Models
Design model (incorporates
data, architectural, interface, and procedural representations of the software)
User model (end
user profiles - novice, knowledgeable intermittent user, knowledgeable
frequent users)
User's model or system
perception (user's mental image of system)
System image
(look and feel of the interface and supporting media)
User Interface Design
Process (Spiral Model)
User, task, and environment
analysis and modeling
Where will the interface
be located physically?
Will the user be sitting,
standing, or performing other tasks unrelated to the interface?
Does the interface hardware
accommodate space, light, or noise constraints?
Are there special human
factors considerations driven by environmental factors?
Interface design
define a set of interface
objects and actions (and their screen representations) that enable a user
to perform all defined tasks in a manner that meets every usability goal
defined for the system
Interface construction
Interface validation
the ability of the interface
to implement every user task correctly, to accommodate all task variations,
and to achieve all general user requirements
the degree to which
the interface is easy to use and easy to learn
the users' acceptance
of the interface as a useful tool in their work
Task Analysis and Modeling
Study tasks users must
complete to accomplish their goal without the computer and map these into
a similar set of tasks that are to be implemented in the user interface
Study existing specification
for computer-based solution and derive a set of tasks that will accommodate
the user model, design model, and system perception
Interface Design Activities
Establish the goals
and intentions of each task
Map each goal/intention
to a sequence of specific actions (objects and methods for manipulating
objects)
Specify the action sequence
of tasks and subtasks (user scenario)
Indicate the state of
the system at the time the user scenario is performed
Define control mechanisms
Show how control mechanisms
affect the state of the system
Indicate how the user
interprets the state of the system from information provided through the
interface
Interface Design Issues
System response time
(time between the point at which user initiates some control action and
the time when the system responds)
User help facilities
(integrated, context sensitive help versus add-on help)
Error information handling
(messages should be non-judgmental, describe problem precisely, and suggest
valid solutions)
Command labeling (based
on user vocabulary, simple grammar, and have consistent rules for abbreviation)
User Interface Implementation
Tools
User-interface toolkits
or user-interface development systems (UIDS)
Provide components or
objects that facilitate creation of windows, menus, device interaction,
error messages, commands, and many other elements of an interactive environment
E.G.
managing input devices
(such as a mouse or keyboard)
validating user input
handling errors and
displaying error messages
providing feedback (e.g.,
automatic input echo)
providing help and prompts
handling windows and
fields, scrolling within windows
establishing connections
between application software and the interface
insulating the application
from interface management functions
allowing the user to
customize the interface
User Interface Evaluation
Cycle
Preliminary design
Build first interface
prototype
User evaluates interface
Evaluation studied by
designer
Design modifications
made
Build next prototype
If interface is not
complete then go to step 3
User Interface Design
Evaluation Criteria
Length and complexity
of written interface specification provide an indication of amount of learning
required by system users
Number of user tasks
and the average number of actions per task provide an indication of interaction
time and overall system efficiency
Number of tasks, actions,
and system states in the design model provide an indication of the memory
load required of system users
Interface style, help
facilities, and error handling protocols provide a general indication of
system complexity and the degree of acceptance by the users
