CSCE 742 Software Architecture Lecture 1 Introduction to Software Architecture January 13, 2009

CSCE 742 Software Architecture CSCE 742 Software Architecture Lecture 1 Lecture 1CSCE 742 Software Architecture CSCE 742 Software Architecture Lecture 1 Lecture 1

Introduction to Software ArchitectureIntroduction to Software Architecture

January 13, 2009

– 2 – CSCE 742 Spring 09

CSCE 742 Software Architecture CSCE 742 Software Architecture

General InformationGeneral Information

Description: Software Architecture. Structural organizations for Description: Software Architecture. Structural organizations for software systems as collections of interconnected software systems as collections of interconnected components: formal models and languages; design tools and components: formal models and languages; design tools and guidelines. Not auditable. guidelines. Not auditable. InstructorInstructor

Manton M . Matthews 3A57 Swearingen 3A57 Swearingen Phone: 777-3285 Phone: 777-3285 Office Hours: MW 9:15-10:45 Office Hours: MW 9:15-10:45 Email: Email: mm at sc dot edu

Office Hours: MW 9:30-11:00, others by appointmentOffice Hours: MW 9:30-11:00, others by appointment

Lots of reading, writing, design, analysis meetings and some Lots of reading, writing, design, analysis meetings and some presentations.presentations.


Course OutcomesCourse Outcomes

The goal for this course is for you to understand: The goal for this course is for you to understand:

• What is software architecture? What is software architecture?

• How do you use software architectures in practice? How do you use software architectures in practice?

• What does a software architect do for an What does a software architect do for an organization? organization?

• What value does software architecture provide? What value does software architecture provide?


DatesDates

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


Grading policy:Grading policy:

• Assignments: 20%Assignments: 20%

• Project 25% Project 25%

• Two Tests: 15% eachTwo Tests: 15% each

• Final: 25%Final: 25%

• No late homework or projects will be accepted. If you No late homework or projects will be accepted. If you cannot make it to class due to other commitments, cannot make it to class due to other commitments, you can hand in your homework the day before it is you can hand in your homework the day before it is due.due.


TopicsTopics

• the architecture business cycle the architecture business cycle

• understanding and achieving quality attributes understanding and achieving quality attributes

• attribute-driven design attribute-driven design

• documenting software architecture documenting software architecture

• evaluating software architecture evaluating software architecture

• architecture reuse architecture reuse


What do you already know?What do you already know?


Email [email protected] [email protected]


Pragmatics of CSCE 742 (cont.)Pragmatics of CSCE 742 (cont.)Books:Books:

1.1. Software Architecture: Perspectives on an emerging Software Architecture: Perspectives on an emerging Discipline by Mary Shaw and David Garlan Discipline by Mary Shaw and David Garlan http://www-2.cs.cmu.edu/afs/cs/project/able/ www/paper_abstracts/intro_softarch.htmlwww/paper_abstracts/intro_softarch.html

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

All diagrams from tonight’s lecture are from Shaw-All diagrams from tonight’s lecture are from Shaw-GarlanGarlan


ArchitectureArchitecture

1.1. the art or science of building ; the art or science of building ; specificallyspecifically : the art : the art or practice of designing and building structures and or practice of designing and building structures and especially habitable onesespecially habitable ones

2.2. a: formation or construction resulting from or as if a: formation or construction resulting from or as if from a conscious act <the from a conscious act <the architecturearchitecture of the of the garden> b: a unifying or coherent form or structure garden> b: a unifying or coherent form or structure <the novel lacks <the novel lacks architecturearchitecture>>

3. architectural product or work product or work

4.4. a method or style of buildinga method or style of building

5.5. the manner in which the components of a computer the manner in which the components of a computer or computer system are organized and integratedor computer system are organized and integrated


OverviewOverviewWhat is Software Architecture?What is Software Architecture?

What do you already know?What do you already know?

Architectural styles:Architectural styles:

Pipes and filtersPipes and filters

Data abstraction and object-oriented org.Data abstraction and object-oriented org.

Event based, implicit invocation Event based, implicit invocation

Layered Systems Layered Systems

RepositoriesRepositories

Table driven interpretersTable driven interpreters

Distributed processesDistributed processes

State transition systems State transition systems

Domain specific software architecturesDomain specific software architectures

Process control systems Process control systems

Heterogeneous ArchitecturesHeterogeneous Architectures

Case StudiesCase Studies


Software Architecture IssuesSoftware Architecture Issues

Structural issuesStructural issues

Organization of the systems as in the composition of Organization of the systems as in the composition of componentscomponents

Global control structuresGlobal control structures

Protocols for communication, synchronization and Protocols for communication, synchronization and accessaccess

Assignment of functionality to design elementsAssignment of functionality to design elements

Composition of design elementsComposition of design elements

Physical distributionPhysical distribution

Scaling and performanceScaling and performance


What is Software Architecture? (2)What is Software Architecture? (2)

Software architecture involves:Software architecture involves:

1.1. the description of elements from which systems are the description of elements from which systems are builtbuilt

2.2. Interactions among those elementsInteractions among those elements

3.3. Patterns that guide their compositionPatterns that guide their composition

4.4. Constraints on these patternsConstraints on these patterns

Thus a system is defined in terms of components and Thus a system is defined in terms of components and interactions among those components.interactions among those components.

This system may then form an element in a higher level This system may then form an element in a higher level design.design.


Describing Software ArchitecturesDescribing Software Architectures

It has been recognized for a long time that “Finding an It has been recognized for a long time that “Finding an appropriate architectural design is key to long-term appropriate architectural design is key to long-term success.”success.”

Current practices for describing architecturesCurrent practices for describing architectures typically informal Idiosyncratic Ad hoc Typically box and line diagrams with accompanying prose

But things are getter better. UML and suchBut things are getter better. UML and such


Describing Software ArchitecturesDescribing Software Architectures

““Camelot is based on the Camelot is based on the client-server modelclient-server model and uses and uses remote procedure callsremote procedure calls …” …”

““Abstraction layering and system decomposition …”Abstraction layering and system decomposition …”

““We have chosen a We have chosen a distributed, object-orienteddistributed, object-oriented approach to managing information.”approach to managing information.”

““The easiest way to make the canonical sequential The easiest way to make the canonical sequential compiler into a concurrent compiler is to compiler into a concurrent compiler is to pipelinepipeline the the execution of the compiler phases.”execution of the compiler phases.”




Some Perspective on the formalization of Software ArchitecturesSome Perspective on the formalization of Software ArchitecturesConsider the development of programming languages as Consider the development of programming languages as

a sequence:a sequence: Introduce Use to solve problems Develop patterns that are “good solutions” Abstract from the patterns new concepts to integrate


Abstraction in Programming LanguagesAbstraction in Programming Languages

1.1. Pre 1946 – program with plug boardsPre 1946 – program with plug boards

2.2. Von Neumann – stored program concept; but Von Neumann – stored program concept; but programmed in machine codeprogrammed in machine code

3.3. Symbolic Assemblers – “Load X” instead of 0x251049Symbolic Assemblers – “Load X” instead of 0x251049

4.4. Formula Translators (Fortran)Formula Translators (Fortran) Algebraic expression evaluation Patterns lead to formalization Loops, arrays, …

5.5. Abstract data types / Object Oriented ProgrammingAbstract data types / Object Oriented Programming


Why are we now in Software Architectures?Why are we now in Software Architectures?

Mid 1990’s (Shaw and Garlan) realization of examples of Mid 1990’s (Shaw and Garlan) realization of examples of good architectural sytle.good architectural sytle.

Abstract from these examples concepts and features Abstract from these examples concepts and features leading to the development of systems for leading to the development of systems for representing, documenting, and evaluating software representing, documenting, and evaluating software architectures.architectures.


Common Architectural StylesCommon Architectural Styles

We now will overview some commonly used We now will overview some commonly used architectural styles.architectural styles.

The framework that we will use in this discussion is to The framework that we will use in this discussion is to

Treat an architecture as a collection of computational Treat an architecture as a collection of computational components together with their interactions.components together with their interactions.

A graph with annotations for the connections A graph with annotations for the connections describing how the components interact.describing how the components interact.


Pipes and FiltersPipes and FiltersIn 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


Pipes and FiltersPipes 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.


Data Abstraction and Object-Oriented OrganizationData Abstraction and Object-Oriented OrganizationUML diagrams; ER diagrams for DatabasesUML diagrams; ER diagrams for Databases

Objects interact through method invocationObjects interact through method invocation

Many nice features including data hidingMany nice features including data hiding

Disadvantage: for interaction you must know the other objectDisadvantage: for interaction you must know the other object


Event-based, Implicit InvocationEvent-based, Implicit Invocation

Graphical user interfacesGraphical user interfaces

X windows:X windows:

EventsEvents

Call backsCall backs


Layered SystemsLayered Systems


RepositoriesRepositoriesIn a repository architecture there are two types of

components:1) A central data structure (the blackboard) for storing

the current state2) independent components that manipulate the central

state (figure taken from Shaw and Garlan)


Table Driven InterpretersTable Driven Interpreters


Distributed processes:Distributed processes:

Client-ServerClient-Server

Remote procedure callsRemote procedure calls


Client-ServerClient-Server


Domain-specific software architectures:Domain-specific software architectures:

Architectures that are developed for very distinct Architectures that are developed for very distinct specific problemsspecific problems

Specializing the architecture allows one to increase the Specializing the architecture allows one to increase the descriptive power of structuresdescriptive power of structures

Air-traffic controlAir-traffic control

BankingBanking

Medical image processingMedical image processing


State transition systems:State transition systems:


Process control systems:Process control systems:

Systems designed to monitor and maintain control over Systems designed to monitor and maintain control over physical devicesphysical devices

Characterized by a feedback loopCharacterized by a feedback loop


Heterogeneous ArchitecturesHeterogeneous Architectures


Case StudiesCase Studies Key word in contextKey word in context

Instrumentation Software Instrumentation Software

CompilersCompilers

Layered Design with Different Styles for the LayersLayered Design with Different Styles for the Layers

Interpreter using Different Idioms for ComponentsInterpreter using Different Idioms for Components

A Blackboard A Blackboard


Case Study: Key word in contextCase 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


Case Study: Decomposition in KWICCase 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


KWIC: Software Arch. ConsiderationsKWIC: 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.


Architectural Approaches to KWICArchitectural 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


KWIC: Main Program/Subroutine with Shared Data KWIC: Main Program/Subroutine with Shared Data


KWIC: Abstract Data Types KWIC: Abstract Data Types


KWIC: Implicit InvocationKWIC: Implicit Invocation


KWIC: Pipes and FiltersKWIC: Pipes and Filters


KWIC: ComparisonKWIC: Comparison


Case StudiesCase Studies Key word in contextKey word in context

Instrumentation Software Instrumentation Software

CompilersCompilers

Layered Design with Different Styles for the LayersLayered Design with Different Styles for the Layers

Interpreter using Different Idioms for ComponentsInterpreter using Different Idioms for Components

A Blackboard A Blackboard

Documents

CSCE 742 Software Architecture Lecture 1 Introduction to Software Architecture January 13, 2009