; Network Security Essentials 2e
Learning Center
Plans & pricing Sign in
Sign Out
Your Federal Quarterly Tax Payments are due April 15th Get Help Now >>

Network Security Essentials 2e


  • pg 1
									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
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
• What value does software architecture provide?

–3–                                             CSCE 742 Spring 09

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

–5–                                           CSCE 742 Spring 09
• 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.)
1. Software Architecture: Perspectives on an emerging
   Discipline by Mary Shaw and David Garlan

2. Software Architecture in Practice 2nd edition by
   Bass, Clements, and Kazman.

All diagrams from tonight’s lecture are from Shaw-

–9–                                                  CSCE 742 Spring 09
 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
 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
 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
 Global control structures
 Protocols for communication, synchronization and
 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
 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

– 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

 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:
            Introduce
            Use to solve problems
            Develop patterns that are “good solutions”
            Abstract from the patterns new concepts to integrate

– 18 –                                                        CSCE 742 Spring 09
Abstraction in Programming
 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
 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

– 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
 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
 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
 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:
 Call backs

– 25 –                        CSCE 742 Spring 09
 Layered Systems

– 26 –             CSCE 742 Spring 09
  In a repository architecture there are two types of
  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:
 Remote procedure calls

– 29 –                    CSCE 742 Spring 09

– 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


 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

To top