introduction to software architecture l.
Skip this Video
Loading SlideShow in 5 Seconds..
Introduction to Software Architecture PowerPoint Presentation
Download Presentation
Introduction to Software Architecture

Loading in 2 Seconds...

play fullscreen
1 / 42

Introduction to Software Architecture - PowerPoint PPT Presentation

  • Uploaded on

Introduction to Software Architecture . TV Prabhakar. Antecedents of Software Architecture. What is Software Architecture?. 150+ definitions What are they? Both a process and a product. What type of requirements drive architectural design?.

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

Introduction to Software Architecture

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
what is software architecture
What is Software Architecture?
  • 150+ definitions
  • What are they?
  • Both a process and a product
what type of requirements drive architectural design
What type of requirements drive architectural design?

Answer: Quality attribute requirements are the primary drivers for architecture design.

Do you agree?

architecture and functionality
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.
effects of architectural decisions on quality attributes
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.
architecture centric development
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.

attribute driven design
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.
add method s inputs and outputs
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
architecture documentation
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.
issues addressed by an architectural design
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
schools of thought
Schools of Thought
  • 4 + 1 View
  • Zachmann Framework
  • RM - ODP
  • IEEE
  • OMG
  • Product Lines
4 1 view
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
what do the views do
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
taxonomy of styles
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)
  • Interacting Processes
    • LW processes, distributed objects
    • Event systems
      • implicit invocation, pure events
  • Data-oriented repository
    • Transactional databases
      • True client/server
      • Blackboard
      • Modern compiler
  • Data-sharing
    • compound documents
    • Hypertext
    • Fortran COMMON
    • LW processes
  • Hierarchical
    • Layered
      • Interpreter
architectural styles
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”
styles patterns and idioms
Styles, Patterns and Idioms
  • POSA, Buschmann etal
  • GOF
  • IEEE
  • OMG
  • POSA
  • GOF