CSCE 742 Software Architecture
Lecture 1
Introduction to Software Architecture
January 13, 2009
CSCE 742 Software Architecture
General Information
Description: Software Architecture. Structural
organizations for software systems as collections of
interconnected components: formal models and
languages; design tools and guidelines. Not
auditable.
Instructor
Manton M . Matthews
3A57 Swearingen
Phone: 777-3285
Office Hours: MW 9:15-10:45
Email: mm at sc dot edu
Office Hours: MW 9:30-11:00, others by appointment
–2–
CSCE 742 Spring 09
Course Outcomes
The goal for this course is for you to understand:
• What is software architecture?
• How do you use software architectures in practice?
• What does a software architect do for an
organization?
• What value does software architecture provide?
–3–
CSCE 742 Spring 09
Dates
Date
Significance
TBD
Test 1
Monday, Feb 23
Last day to withdraw without WF
March 8-15, Sun-Sun
Spring break-no classes
TBD
Test 2
May 6@2:00PM
Final Exam
–4–
CSCE 742 Spring 09
Grading policy:
• Assignments: 20%
• Project 25%
• Two Tests: 15% each
• Final: 25%
• No late homework or projects will be accepted. If you
cannot make it to class due to other commitments,
you can hand in your homework the day before it is
due.
–5–
CSCE 742 Spring 09
Topics
• the architecture business cycle
• understanding and achieving quality attributes
• attribute-driven design
• documenting software architecture
• evaluating software architecture
• architecture reuse
–6–
CSCE 742 Spring 09
What do you already know?
–7–
CSCE 742 Spring 09
Email mm@sc.edu
–8–
CSCE 742 Spring 09
Pragmatics of CSCE 742 (cont.)
Books:
1. Software Architecture: Perspectives on an emerging
Discipline by Mary Shaw and David Garlan
http://www-2.cs.cmu.edu/afs/cs/project/able/
www/paper_abstracts/intro_softarch.html
2. Software Architecture in Practice 2nd edition by
Bass, Clements, and Kazman.
All diagrams from tonight’s lecture are from ShawGarlan
–9–
CSCE 742 Spring 09
Architecture
1. the art or science of building ; specifically : the art or
practice of designing and building structures and
especially habitable ones
2. a: formation or construction resulting from or as if
from a conscious act <the architecture of the
garden> b: a unifying or coherent form or structure
<the novel lacks architecture>
3. architectural product or work
4. a method or style of building
5. the manner in which the components of a computer
or computer system are organized and integrated
– 10 –
CSCE 742 Spring 09
Overview
What is Software Architecture?
What do you already know?
Architectural styles:
Pipes and filters
Data abstraction and object-oriented org.
Event based, implicit invocation
Layered Systems
Repositories
Table driven interpreters
Distributed processes
State transition systems
Domain specific software architectures
Process control systems
Heterogeneous Architectures
Case Studies
– 11 –
CSCE 742 Spring 09
Software Architecture Issues
Structural issues
Organization of the systems as in the composition of
components
Global control structures
Protocols for communication, synchronization and
access
Assignment of functionality to design elements
Composition of design elements
Physical distribution
Scaling and performance
– 12 –
CSCE 742 Spring 09
What is Software Architecture? (2)
Software architecture involves:
1. the description of elements from which systems are
built
2. Interactions among those elements
3. Patterns that guide their composition
4. Constraints on these patterns
Thus a system is defined in terms of components and
interactions among those components.
This system may then form an element in a higher level
design.
– 13 –
CSCE 742 Spring 09
Describing Software Architectures
It has been recognized for a long time that “Finding an
appropriate architectural design is key to long-term
success.”
Current practices for describing architectures




typically informal
Idiosyncratic
Ad hoc
Typically box and line diagrams with accompanying prose
But things are getter better. UML and such
– 14 –
CSCE 742 Spring 09
Describing Software Architectures
“Camelot is based on the client-server model and uses
remote procedure calls …”
“Abstraction layering and system decomposition …”
“We have chosen a distributed, object-oriented
approach to managing information.”
“The easiest way to make the canonical sequential
compiler into a concurrent compiler is to pipeline the
execution of the compiler phases.”
– 15 –
CSCE 742 Spring 09
– 16 –
CSCE 742 Spring 09
– 17 –
CSCE 742 Spring 09
Some Perspective on the formalization
of Software Architectures
Consider the development of programming languages as
a sequence:




– 18 –
Introduce
Use to solve problems
Develop patterns that are “good solutions”
Abstract from the patterns new concepts to integrate
CSCE 742 Spring 09
Abstraction in Programming
Languages
1. Pre 1946 – program with plug boards
2. Von Neumann – stored program concept; but
programmed in machine code
3. Symbolic Assemblers – “Load X” instead of 0x251049
4. Formula Translators (Fortran)



Algebraic expression evaluation
Patterns lead to formalization
Loops, arrays, …
5. Abstract data types / Object Oriented Programming
– 19 –
CSCE 742 Spring 09
Why are we now in Software
Architectures?
Mid 1990’s (Shaw and Garlan) realization of examples of
good architectural sytle.
Abstract from these examples concepts and features
leading to the development of systems for
representing, documenting, and evaluating software
architectures.
– 20 –
CSCE 742 Spring 09
Common Architectural Styles
We now will overview some commonly used
architectural styles.
The framework that we will use in this discussion is to
Treat an architecture as a collection of computational
components together with their interactions.
A graph with annotations for the connections
describing how the components interact.
– 21 –
CSCE 742 Spring 09
Pipes and Filters
In a pipe and filter style each component has a set of inputs and a set of
outputs. The output is frequently viewed as a function of just the input but it
also could remember some state.
e.g., Unix shell scripts
– 22 –
CSCE 742 Spring 09
Pipes and Filters
Advanatges:
1. allow understanding overall behavior as composition
of simpler behaviors
2. They support reuse; a good filter gets used many times.
3. Systems can easily be maintained and extended.
4. Permit certain kinds of analysis; throughput, deadlock
analysis.
Disadvantages
1. Not good for handling highly interactive systems.
2. They force lowest common denominator in I/O; sending
characters then reparsing words etc.
– 23 –
CSCE 742 Spring 09
Data Abstraction and Object-Oriented
Organization
UML diagrams; ER diagrams for Databases
Objects interact through method invocation
Many nice features including data hiding
Disadvantage: for interaction you must know the other object
– 24 –
CSCE 742 Spring 09
Event-based, Implicit Invocation
Graphical user interfaces
X windows:
Events
Call backs
– 25 –
CSCE 742 Spring 09
Layered Systems
– 26 –
CSCE 742 Spring 09
Repositories
In a repository architecture there are two types of
components:
1) A central data structure (the blackboard) for storing
the current state
2) independent components that manipulate the central
state (figure taken from Shaw and Garlan)
– 27 –
CSCE 742 Spring 09
Table Driven Interpreters
– 28 –
CSCE 742 Spring 09
Distributed processes:
Client-Server
Remote procedure calls
– 29 –
CSCE 742 Spring 09
Client-Server
– 30 –
CSCE 742 Spring 09
Domain-specific software architectures:
Architectures that are developed for very distinct
specific problems
Specializing the architecture allows one to increase the
descriptive power of structures
Air-traffic control
Banking
Medical image processing
– 31 –
CSCE 742 Spring 09
State transition systems:
– 32 –
CSCE 742 Spring 09
Process control systems:
Systems designed to monitor and maintain control over
physical devices
Characterized by a feedback loop
– 33 –
CSCE 742 Spring 09
Heterogeneous Architectures
– 34 –
CSCE 742 Spring 09
Case Studies
 Key word in context
 Instrumentation Software
 Compilers
 Layered Design with Different Styles for the Layers
 Interpreter using Different Idioms for Components
 A Blackboard
– 35 –
CSCE 742 Spring 09
Case Study: Key word in context
In 1972, Parnas proposed the following problem KWIC:
The KWIC [Key Word in Context] index system:
1. Accepts an ordered set of lines, each line is an
ordered set of words, and each word is an ordered
set of characters.
2. Any line may be ``circularly shifted'' by repeatedly
removing the first word and appending it at the end
of the line.
3. The KWIC index system outputs a listing of all
circular shifts of all lines in alphabetical order.
Reference: “On the Criteria for Decomposing Systems
into Modules,” David Parnas. CACM, 1972
– 36 –
CSCE 742 Spring 09
Case Study: Decomposition in KWIC
Parnas used the problem to contrast different criteria
for decomposing a system into modules:
1. Functional decomposition with shared access to
data representations, and
2. A decomposition that hides design decisions.
Examples: permuted index of the Unix man
– 37 –
CSCE 742 Spring 09
KWIC: Software Arch. Considerations
Changes in processing algorithm
Changes in data representation
Enhancement to system function
Performance: Both space and time.
Reuse: To what extent can the components serve as
reusable entities.
– 38 –
CSCE 742 Spring 09
Architectural Approaches to KWIC
Solution 1: Main Program/Subroutine with Shared Data
Solution 2: Abstract Data Types
Solution 3: Implicit Invocation
Solution 4: Pipes and Filters
– 39 –
CSCE 742 Spring 09
KWIC: Main Program/Subroutine with
Shared Data
– 40 –
CSCE 742 Spring 09
KWIC: Abstract Data Types
– 41 –
CSCE 742 Spring 09
KWIC: Implicit Invocation
– 42 –
CSCE 742 Spring 09
KWIC: Pipes and Filters
– 43 –
CSCE 742 Spring 09
KWIC: Comparison
– 44 –
CSCE 742 Spring 09
Case Studies
 Key word in context
 Instrumentation Software
 Compilers
 Layered Design with Different Styles for the Layers
 Interpreter using Different Idioms for Components
 A Blackboard
– 45 –
CSCE 742 Spring 09