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.

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

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

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

6. Schedule – current -- Proposed

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

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

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

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

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

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

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

14. Architecture Handbook

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

16. CAD -

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

32. Layered Systems

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

34. Table Driven Interpreters

35. Distributed processes:
Client-Server
Remote procedure calls

36. Client-Server

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

38. State transition systems:

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

40. Heterogeneous Architectures

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

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

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

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

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

46. KWIC: Main Program/Subroutine with Shared Data

47. KWIC: Abstract Data Types

48. KWIC: Implicit Invocation

49. KWIC: Pipes and Filters

50. KWIC: Comparison

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