CSc 230

1
California State University, Sacramento Computer
Science Department
CSc 230 Software System Engineering Spring
2007 System Architectural Design
2
System Architectural DesignVenturing into the
solution space
3
Where are we?
4
Architecture vs. Design

• Specification defines
• The externally-observable behaviour of the
  system.
• Architecture defines
• The major system-level components
• Their methods of interaction
• Technology used
• Design defines
• How the job will get done
• The code that needs to be written.

5
System Architecture

• In the 1990s there was a growing interest in
  architecture as the approach to capturing design
  information that could be reused in multiple
  context.
• So far there is little agreement on the details
  of various approaches
• but some principles are emerging from the
  continuing discussions

6
What is System Architecture?

• The architecture of computing system is the
  structure or structures of the system, which
  comprise system/software components, the
  externally visible properties of those
  components, and the relationships among them.
  CMMI
• The structure of the components of a
  program/system, their interrelationships, and
  principles and guidelines governing their design
  and evolution over time SEI
• fundamentally, components and connectors

7
What is System Architecture?

• System architecture refers to the fundamental
  structural attributes of a software system.
  Barry Horowitz

8
What is System Architecture?

• Software system architecture deals with the
  design and implementation of the high-level
  structure of the system/software.
• It is the result of assembling a certain number
  of architectural elements in some well-chosen
  forms to satisfy the major functionality and
  performance requirements of the system, as well
  as some other, non-functional requirements such
  as reliability, scalability, portability, and
  availability. (IBM-Rational Software Corp.)

9
What system/Software Architecture Is Not!

• Architecture is not the same as
• The directory structure for source code files
• The hardware platform chosen for the system
• System architecture is more than components and
  connectors, or major elements of a system.
• It is a collection of views, patterns,
  stakeholders, and roles SEI.Therefore, System
  architecture provides the necessary means to
  formalize and interpret the properties of a
  system.

10
Architecture Contains Decisions

• System architecture encompasses the set of
  significant decisions about the organization of a
  system
• selection of the structural elements and their
  interfaces by which a system is composed
• behavior as specified in collaborations among
  those elements
• composition of these structural and behavioral
  elements into larger subsystem
• architectural style that guides this organization

11
Properties of Architecture

• Essential properties of System Architecture
• System partitioning (allocation of functions to
  system /software components)
• Flow of data
• Flow of control
• Critical timing and throughput relationships
• Interface layering and protocol standards
• Allocation of software to hardware components

12
More Definitions and References

• More than 50 definitions at,
• http//www.sei.cmu.edu/architecture/definitions.ht
  ml
• http//www.bredemeyer.com/definiti.htm
• For further investigation, visit
• http//www.sei.cmu.edu/ata/ata_init.html

13
Why System/Software Architecture?
14
Why is System Architecture Important?

• Prioritizes Competing Concerns
• Communication Among Stakeholders
• Early Design Decisions
• Transferable Abstraction of a System

15
Competing Concerns

• System/Software architecture enables
• priorities among competing concerns to be
  analyzed
• manifests concerns as system qualities (e.g.,
  performance, maintainability, reliability, etc.)
• The System/Software Architect(s) must balance the
  needs of the different stakeholders in
  determining an appropriate structure

16
Communication Among Stakeholders

• provides a common base for forming consensus,
  enabling mutual understanding, etc.
• Architecture may be used as a focus of discussion
  by different system stakeholders

17
Early Design Decisions

• Analysis of whether the system can meet its
  non-functional requirements is possible
• SwSE must ensure the SRS is correctly converted
  into a suitable design and the project is
  accomplished as planned

18
Early Design Decisions

• Helps predict system qualities, e.g.,
• Performance depends on the volume and complexity
  of inter-component communications (helps identify
  potential communication bottlenecks)
• Modifiability depends on system modularization
• Reusability depends on coupling

19
Early Design Decisions...

• Guideline on an implementation
• Does an implementation conform to an
  architecture?
• Architecture can help system engineering
  /developers understand and reason about change.
• For example, a simple web client-server system
  may have these changes,
• adding a new file type to be recognized on the
  client (local change)
• extending the protocol (non-local change)
• making it a broadcast system (architectural
  change)

20
A Transferable, Reusable Model

• The architecture may be reusable across a range
  of systems
• e.g., build architecture and infrastructure to
  support not just one e-commerce application, but
  several
• Build systems with large existing components
• assemble instead of program
• Restrict vocabulary to aid communication

21
System Architecture provides the basis for

• Team organization and work assignments
• Work-breakdown structure is typically based on
  the architecture
• Work-breakdown structure affects budgeting,
  scheduling, inter-team communication channels,
  file system organization, test plans, etc.

22
System Architecture provides the basis for

• Initial design 
• Subsequent extensibility
• Modular construction and testing
• Integration
• Maintenance and regression testing

23
Lack of System Architecture May Cause

• Performance inadequate and no hardware upgrade
  path available
• Maintenance costly and prone to side-effect
  problems
• Reuse possibilities limited

24
Lack of System Architecture May Cause

• Inefficient or infeasible projects
• e.g., where the architecture partitions the work
  in such a way that every engineer must
  communicate with every other engineer.
• Throughput problems, processing bottlenecks, etc.

25
Modular System/Software Design
26
Modular System/Software Design

• Reduces Complexity.
• Facilitates Change (Easier Maintainability).
• Easier Implementation by encouraging parallel
  development.

27
Modular System/Software Design

• Module is the basic unit of subsystem used in a
  design description.
• Determined using step-wise refinement
• Modules, sub-systems, components, packages, and
  classes are all system elements used for
  abstraction and information hiding.

28
Levels of Abstraction

• Data Structures and Algorithms
• Classes (data structures and many algorithms)
• Packages/Modules (groups of related, possibly
  interacting classes through design patterns).
• Modules/Subsystems (interacting modules each
  containing many classes, but only the public
  interfaces interact with other modules/subsystems)
  .
• Systems (systems interacting with other systems,
  hardware, software and human).
• System/Software Architecture is about the last
  two.

29
Subsystem/Module Cohesion

• A measure of how functionally coherent a
  system/software module is.
• A system/software module should have High
  Cohesion.
• This means that a system/software module is
  concerned with only doing one thing and doing
  that thing well.
• For large modules, their components/classes
  should be functionally related.

30
Types of Cohesion
Coincidental
Temporal
Communicational
Functional
Procedural
Logical
Low Cohesion Spectrum
High
Single-Minded
Scatter-Brained
Good
A measure of the relative functional strength of
a system/software module
Coincidental multiple, completely unrelated
actions or components Logical series of related
actions or components (e.g. library of IO
functions) Temporal series of actions related
in time (e.g. initialisation modules)Procedura
l series of actions sharing sequences of
steps. Communicational procedural cohesion but
on the same data. Functional one action or
function
31
Subsystem/Module Coupling

• Coupling is a measure of how inter-related or
  interdependent subsystem /software modules are.
• There should be LOW COUPLING between subsystem
  modules.
• This means that should be only a few well
  defined, functionally relevant dependencies
  between subsystem modules.
• Highly coupled systems/software is usually not
  efficient and optimized systems
• (difficult to understand, maintain, debug etc)

32
Types of Coupling
No Direct Coupling
Stamp Coupling
External
Content
Control Coupling
Common Coupling
Data Coupling
Low Coupling Spectrum
High
Good
A measure of the interdependence among
system/software modules
Data Simple argument passing Stamp Data
structure passing Control One module passes the
element of control (flag) to another. External
Modules are tied to environment external to
software (device) Common Modules have access to
the same global data. Content One module
directly references the content of another
33
Creating System/Software Architecture
34
Characteristics of a Good System Architecture

• Resilient
• Simple
• Clear separation of concerns
• Balanced distribution of responsibilities
• Balances economic and technology constraints

35
Characteristics of a Good System Architecture

• System Architecture should address
• Performance
• Having many layers can result in performance
  issues.
• Design your architecture with high cohesion and
  low coupling and then adapt it to iron out
  performance issues.
• Reuse
• Reusable Components/Modules are general
• Reusable Components are Loosely Coupled
• Requires High Cohesion and well-defined interface

36
Architectural Stability

• Architecture should be designed after
  requirements have been gathered and analysed.
• Should be documented and should remain relatively
  stable throughout the life of the system /project.

37
Architectural Stability

• May be updated, but shouldnt grow dramatically.
  Changes may include
• Finding new abstract classes and interfaces
• Adding new functionality to existing
  sub-systems/modules
• Upgrading to new versions of re-useable
  components
• Re-arranging the process structure.

38
What Influences the System Architecture
Constraints and Enablers
Use Cases (Requirements)
System Software Middleware (e.g.
Frameworks) Legacy Systems Standards and
Policies Non Functional Requirements Distributio
n Needs
Architecture
Experience (Previous Architectures) (Architectural
Patterns)
39
Steps in Creating an Effective Architecture

• Identify major modules (or sub-systems) and
  sub-modules.
• Identify interactions with external actors and
  systems.
• Identify dependencies between modules/sub-systems.
  
• Determine the public classes, functions or
  sub-modules for each module.
• Identify which public classes from each module
  will interact with each other.
• Determine the interaction order between the
  modules.

40
Steps in Creating an Effective Architecture

• Determine the dynamic interactions
• Document it.
• Review it.
• Iterate through it a couple of times to make sure
  it is modular, extensible, satisfies requirements
  (including performance etc).
• Compile it

41
System/Software Architecture Team Charter

• Defining the architecture of the system
• Maintaining the architectural integrity of the
  system
• Assessing technical risks related to the software
  design
• Proposing the order and contents of the
  successive iterations
• Consulting services
• Assisting marketing for future product definition
• Facilitating communications between project teams

42
Next

• Possible client visit
• Lab session (for design and implementation)
• Continue on Design Documents and implementation
• More on Design concepts -
• Simulation