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

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: 777-3285 Email: 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.

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

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?

Important Dates MySC then to Registration  schedule “Important Significance Last day to drop Last Day W assigned http://registrar.sc.edu/html/bannerApps/POTDates.aspx

Schedule – current -- Proposed

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

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

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.

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

Pragmatics of CSCE 742 (cont.) Books: 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 Software Architecture in Practice 3rd edition by Bass, Clements, and Kazman. Many diagrams from lecture are from Shaw-Garlan

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

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>

Architecture Handbook

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. http://www.iar.unicamp.br/lab/luz/ld/Arquitetural/livros/interior%20design%20student%20handbook.pdf

CAD - http://www.iar.unicamp.br/lab/luz/ld/Arquitetural/livros/interior%20design%20student%20handbook.pdf

Innovation Center – New CSE home 1/1/17

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

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

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

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.

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

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

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

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

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 http://resources.sei.cmu.edu/asset_files/Presentation/2012_017_001_23736.pdf

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.

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

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.

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

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

Layered Systems

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)

Table Driven Interpreters

Distributed processes: Client-Server Remote procedure calls

Client-Server

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

State transition systems:

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

Heterogeneous Architectures

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

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

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

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.

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

KWIC: Main Program/Subroutine with Shared Data

KWIC: Abstract Data Types

KWIC: Implicit Invocation

KWIC: Pipes and Filters

KWIC: Comparison

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