1. CSCE 742 Software Architectures
Lecture 1
What is Architecture?
Topics
Architectural Styles
Key Word In Context (KWIC)
Other Cases Studies
Evolution of Software Engineering
May 08, 2017

2. CSCE 742 Software Architecture
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 3A53 Swearingen Phone: mm at sc dot edu
Office Hours: M-W 9:15-10:45 , others by appointment
Previous offerings:
Fall 2003, 2005, 2009, 2014
Summer 2011, 2016
Lots of reading, writing, design, analysis meetings and some presentations.

5. Software Architecture = Top-level design

6. The Changing World of Software Arch.

7. Layered Architecture

8. Layered Architecture e.g. TCP/IP
The transfer path
Why?
Architectural Advantages

9. 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

10. 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?

11. Important Dates MySC then to Registration  schedule “Important
Significance
Last day to drop
Last Day W assigned

12. CSCE 742 Summer 2017 Schedule Class Date Day Topic Reading Labs
Minutes in class 1
8-May
Mon
Overview
Garlan and Shaw
Soft. Engr. Background Evaluation 85 2
10-May
Wed
Case Studies; What is Software Architecture
Chap 1-3
Call graph generation,& drawing 3
15-May
Quality Attrubutes
Chap 4 4
17-May
Software Architecture Reconstruction
Chap 20; Eclipse Projects
UML & Reconstruction project 5
22-May
Availability; Avionics Case Study
Chap 5 6
24-May
Interoperability, Modifiability, and Performance
Chap 6-8
Quality Attributes 7
29-May
Security, Testability, and Usability; Interoperability Case Study
Chap 9-11 8
31-May
Test 1 9
5-Jun
Tactics, Patterns, Modelling
Chap 13-14 10
7-Jun
Arch. Significant Requirements; SA in Agile projects
Chap 15 11
12-Jun
Designing Architecture; Case Study
Chap 16-17, + Designing SA text
Self-Service Carolina Design 12
14-Jun
Architecture Evaluation - ATAM
Chap 21 13
19-Jun
ATAM Case Study - BCS
ATAM homework 14
21-Jun
Documenting Software Architectures
Chap 18

13. 15
26-Jun
Mon
ATAM Team Competencies
Documenting Project 85 16
28-Jun
Wed
ATAM Case Study - Earth Observing System
3-Jul
No classes 17
5-Jul
Designing Architectures Again; ATAM again 18
10-Jul
Test 2
12-Jul
No class 19
17-Jul
out (Team meeting - Finalize Architecture)
Architecture meeting Report
19-Jul
Software Architecture 20
24-Jul
out (Team meeting - ATAM 0)
ATAM 0 - minutes
26-Jul
ATAM plan 21
31-Jul
Cloud Computing Architectures
Chap 26 22
2-Aug
ATAM Evaluation Team1 evaluates Team 3's SA
180 23
7-Aug
ATAM Evaluation Team2 evaluates Team 1's SA 24
9-Aug
ATAM Evaluation Team3 evaluates Team 2's SA
15-Aug
Tue
Exam - Aug. 15, Tuesday - 12:30 p.m.
Total Minutes
2325
Team not involved
Minutes each student
2145

14. Grading policy: Assignments: 15% Project 25% Two Tests: 15% each
Final: 30%
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.

15. What do you already know?
Survey on website
Degree you are working on
Tools you have used
IDE – Emacs vs Eclipse vs
Languages
Courses in Software Engineering 740, 741, 743, 747 or elsewhere
Student/Working status

16. Pragmatics of CSCE 742 (cont.)
Books:
Software Architecture: Perspectives on an emerging Discipline by Mary Shaw and David Garlan www/paper_abstracts/intro_softarch.html
Software Architecture in Practice 3rd edition by Bass, Clements, and Kazman.
Many diagrams from lecture are from Shaw-Garlan

17. Topics the architecture business cycle
understanding and achieving quality attributes
attribute-driven design
documenting software architecture
evaluating software architecture
architecture reuse

18. Architecture (not Software Architecture)
the art or science of building ; specifically : the art or practice of designing and building structures and especially habitable ones
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>

19. Architecture Handbook

20. Technical Sketches  Drafting
Architectural drafting is basically pictorial images of buildings, interiors, details, or other items that need to be built. These are different from other types of drawings as they are drawn to scale, include accurate measurements and detailed information, and other information necessary to build a structure.

21. CAD -

22. Innovation Center – New CSE home 1/1/17

23. Computer Architecture
“computer architecture is a set of rules and methods that describe the functionality, organization, and implementation of computer systems” (Wikipedia) the components and their interactions

24. 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
Quality Attributes

25. Quality Attributes Requirements – Functional requirements
Non-functional requirements == Quality Attributes
Examples:
Availability
Usability
Security
Performance
Latency
throughput

26. What is Software Architecture? (2)
Software architecture involves:
the description of elements from which systems are built
Interactions among those elements
Patterns that guide their composition
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.

27. 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

28. 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.”

29. 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

30. Abstraction in Programming Languages
Pre 1946 – program with plug boards
Von Neumann – stored program concept; but programmed in machine code
Symbolic Assemblers – “Load X” instead of 0x251049
Formula Translators (Fortran)
Algebraic expression evaluation
Patterns lead to formalization
Loops, arrays, …
Abstract data types / Object Oriented Programming

31. Where 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.
Reflection on 20 Years of Architecture – Linda Northrop

32. 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.

33. 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

34. Pipes and Filters Advanatges:
allow understanding overall behavior as composition of simpler behaviors
They support reuse; a good filter gets used many times.
Systems can easily be maintained and extended.
Permit certain kinds of analysis; throughput, deadlock analysis.
Disadvantages
Not good for handling highly interactive systems.
They force lowest common denominator in I/O; sending characters then reparsing words etc.

35. 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

36. Event-based, Implicit Invocation
Graphical user interfaces
X windows:
Events
Call backs

37. Layered Systems

38. Repositories
In a repository architecture there are two types of components:
A central data structure (the blackboard) for storing the current state
independent components that manipulate the central state (figure taken from Shaw and Garlan)

39. Table Driven Interpreters

40. Distributed processes:
Client-Server
Remote procedure calls

41. Client-Server

42. 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

43. State transition systems:

44. Process control systems:
Systems designed to monitor and maintain control over physical devices
Characterized by a feedback loop

45. Heterogeneous Architectures

46. 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

47. Case Study: Key word in context
In 1972, Parnas proposed the following problem KWIC:
The KWIC [Key Word in Context] index system:
Accepts an ordered set of lines, each line is an ordered set of words, and each word is an ordered set of characters.
Any line may be ``circularly shifted'' by repeatedly removing the first word and appending it at the end of the line.
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

48. Case Study: Decomposition in KWIC
Parnas used the problem to contrast different criteria for decomposing a system into modules:
Functional decomposition with shared access to data representations, and
A decomposition that hides design decisions.
Examples: permuted index of the Unix man

49. 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.

50. 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

51. KWIC: Main Program/Subroutine with Shared Data

52. KWIC: Abstract Data Types

53. KWIC: Implicit Invocation

54. KWIC: Pipes and Filters

55. KWIC: Comparison

56. 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