Slide 1 Introduction to Software Architecture TV Prabhakar

Slide 2 Antecedents of Software Architecture

Slide 3 What is Software Architecture? 150+ definitions What are they? Both a process and a product

Slide 4

Slide 5

Slide 6

Slide 7

Slide 8

Slide 9

Slide 10 What type of requirements drive architectural design? Answer: Quality attribute requirements are the primary drivers for architecture design. Do you agree?

Slide 11

Slide 12

Slide 13 Architecture and Functionality Functionality is largely orthogonal to quality attribute requirements. Functionality is the ability of a system to do the work it was intended to do. Systems are decomposed into elements to achieve a variety of purposes other than function. –Architectural choices promote certain qualities as well as implement the desired functionality.

Slide 14 Effects of Architectural Decisions on Quality Attributes The degree to which a system meets it’s quality attribute requirements is dependent on architectural decisions. A change in structure improving one quality often affects the other qualities. Architecture is critical to the realization of quality attributes. These product qualities should be designed into the architecture. Architecture can only permit, not guarantee, any quality attribute.

Slide 15 Architecture-centric development? Architecture-centric development involves –Creating the business case for the system –Understanding the requirements –Creating or selecting the architecture –Documenting and communicating the architecture –Analyzing or evaluating the architecture –Implementing the system based on the architecture –Ensuring that the implementation conforms to the architecture –Maintaining the architecture The architecture must be both prescriptive and descriptive.

Slide 16

Slide 17

Slide 18

Slide 19

Slide 20

Slide 21

Slide 22 Attribute-Driven Design The Attribute-Driven Design (ADD) method, developed at the SEI, is an approach to defining a software architecture that bases the decomposition process on the quality attributes the software must fill. a recursive decomposition process where, at each stage in the decomposition, tactics and architectural patterns are chosen to satisfy a set of quality scenarios.

Slide 23

Slide 24 ADD Method's Inputs and Outputs Inputs –constraints –functional requirements –quality attribute requirements Outputs –first several levels of module decomposition –various other views of the system as appropriate –set of elements for functionality and the interactions among them

Slide 25 Architecture Documentation Architecture documentation is important if and only if communication of the architecture is important. –How can an architecture be used if it cannot be understood? –How can it be understood if it cannot be communicated? Documenting the architecture is the crowning step to creating it. Documentation speaks for the architect, today and 20 years from today.

Slide 26

Slide 27 Issues Addressed by an Architectural Design Gross decomposition of a system into interacting components –typically hierarchical –using rich abstractions for component interaction(or system “glue”) –often using common design idioms/styles Emergent system properties –performance, throughput, latencies –reliability, security, fault tolerance, evolvability Rationale and assignment of function to components –relates requirements and implementations Envelope of allowed change –“load-bearing walls”, limits of scalability and adaptation –design idioms and styles

Slide 28 Schools of Thought View Zachmann Framework RM - ODP IEEE OMG TOGAF Product Lines

Slide view Philips Kruchten, Rational Software, Architectural Blueprints - The 4+1 View Model of Software Archtecture, IEEE Software, 1995 –Use case view –Logical view –Process view –Implementation view –Deployment view

Slide view

Slide 31 What do the views do? logical view is the object model of the design (when an object-oriented design method is used), process view captures the concurrency and synchronization aspects of the design, physical view which describes the mapping(s) of the software onto the hardware and reflects its distributed aspect, development view describes the static organization of the software in its development environment illustrated by a few selected use cases, or scenarios

Slide 32 Taxonomy of Styles Data Flow –Batch Sequential –Dataflow Network(pipes & filters) »acyclic, fanout, pipeline, Unix –Closed loop control Call-and-return –Main program/subroutines –Information hiding(ADT, Object naïve client/server)

Slide 33 Taxonomy.. Interacting Processes –LW processes, distributed objects –Event systems »implicit invocation, pure events Data-oriented repository –Transactional databases »True client/server »Blackboard »Modern compiler

Slide 34 Taxonomy.. Data-sharing –compound documents –Hypertext –Fortran COMMON –LW processes Hierarchical –Layered »Interpreter

Slide 35

Slide 36

Slide 37

Slide 38

Slide 39

Slide 40 Architectural Styles An architectural style consists of: –component/connector types, topology –constraints on the topology and behavior –an informal description of the costs and benefits of the style, e.g. “use the pipe and filter style when reuse is desired and performance is not a top priority”

Slide 41 Styles, Patterns and Idioms POSA, Buschmann etal GOF

Slide 42 References sei.cmu.edu IEEE OMG POSA GOF WWISA Bredemeyer.com