slide 1 introduction to software architecture tv prabhakar
TRANSCRIPT
Slide 1
Introduction toSoftware 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 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.
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 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
Slide 28
Schools of Thought• 4 + 1 View• Zachmann Framework• RM - ODP• IEEE• OMG• TOGAF• Product Lines
Slide 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
Slide 30
4+1 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• www.cetus-links.org• Bredemeyer.com