Introduction to Software Architecture

1. Introduction toSoftware Architecture TV Prabhakar

2. Antecedents of Software Architecture

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

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

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.

14. Effects of Architectural Decisionson 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.

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.

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.

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

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.

27. Issues Addressed byan 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

28. Schools of Thought • 4 + 1 View • Zachmann Framework • RM - ODP • IEEE • OMG • TOGAF • Product Lines

29. 4 + 1 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

30. 4+1 view

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

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)

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

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

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”

41. Styles, Patterns and Idioms • POSA, Buschmann etal • GOF

42. References • sei.cmu.edu • IEEE • OMG • POSA • GOF • WWISA • www.cetus-links.org • Bredemeyer.com