ARCHITECTURAL BUSINESS CYCLE

How organizational goals influence frequirements and developing strategy

How requirements lead to architecture
How architectures are analyzed
How architectures yield systems that suggest new organizational capabilities and
Requirements
WHERE DO ARCHITECTURES COME FROM?/ARCHITECTURES INFLUENCES
*Architectures are influenced by system stakeholders
*Architectures are influenced by the developing organizations
*Architectures are influenced by the background and experience of the architects
*Architectures are influenced by the technical environment
*Ramifications of influences on an architecture
*The architecture affects the factors that influence them
SOFTWARE PROCESSES AND THE ABC (ARCHITECTURE ACTIVITIES)
*Creating the business case for the system
*Understanding the requirements
*Creating or selecting the architecture
*Documenting and communicating the archiotecture
*Analyzing or evaluating the architecture
*Implementing the system based on the architecture
*Ensuring that the implementation conforms to the architecture
WHAT MAKES A GOOD ARCHITECTURE ?
*Process recommendations
*Product(structural) recommendations
WHAT IS S/W ARCHITECTURE IS AND IT ISN'T IT?
*Is this an architecture? What can we not tell from the diagram?
*What is the nature of the elements?
*What are the responsibilities of the elements?
*What is the significance of the layout?
*What is the significance of the connection?
4 process-->*Prop Loss Model(MODP),,*Reverb Model(MODR)
*Noise Model(MODN),,*ControlProcess(CP)
OTHER POINTSOF VIEW
*Architecture is a high level design
*Architecture is the overall structure of the system
* Architecture is the structure of the components of a program or system
*Architecture is components and connectors
ARCHITECTURAL PATTERNS ,REFERENCE MODELS & REFERENCE ARHITECTURES
*An architectural pattern is a description of element and relation
*A reference model is a division of functionality together with dataflow b/w pieces
*A reference architecture is a reference model mapped onto software elements
-->Reference model(a)-->Architectural pattern(b)-->(2)Reference architecture-->(3)s/w
architecture
WHY S/W ARCHITECTURE IS IMPORTANT
*Communicatin among Stackholders
*Early design decisions
*Transferable abstraction of a system
-->ARCHITECTURE IS THE VEHICLE FOR STACKHOLDER COMMUNICATION
-->ARCHITECTURE MANIFESTS THE EARLIEST SET OF DESIGN DECISIONS
*The architecture defines constraints on implementation
*The architecture dictates organizational structure
*Architecture inhibits or enables a system's quality attributes
*Predicting system qualities by studying the architecture
*Architecture makes it easier to reason about and manage change
*architecture helps in evolutionary prototyping
*Architecture enables more accurate cost and schedule estimates
ARCHUTECTURE AS A TRANSFERABLE AND REUSABLE MODEL
*Software product lines share a common architecture
*Systems can be built using large. Externally developed elements
*Less is more: it pays to restrict the vocabulary of design alternatives
*An architecture permits template-based development
*An architecture can be the basis for training
ARCHITECTURAL STRUCTURES AND VIEWS
*Module Structures--- Decomposition,Uses,Layered,Class or Generalization
*Component and connector structures ---Process,Concurrency,Shared data ,Client-server
*Allocation structures---Deployment,Implementation,Work Assignment
RELATING STRUCTURES TO EACH OTHER
*Logical *Process *Deployment *Physical
"4+1" VIEW MODEL(Scenarios)

ARCHITECTURE IN THE LIFE CYCLE

Software concepts…….Preliminary requirements analysis…..Design of architecture and
System core…..Develop a version(1)…..Deliver the version(2)……Ellicit customer
feedback(3)……Incorporate customer feedback(4)……Deliver the final version(5)
DESIGNING THE ARCHITECTURE --- ATTRIBUTE-DRIVEN DESIGN
Begininning ADD

ADD STEPS

*Choose the module to decompose

*Refine the module according to these steps:
--->Choose the architectural drivers
--->Choose an architectural pattern
--->Instantiate modules and allocate functionality using multiple views
*Instantiate modules *Allocate functionality
--->Define interfaces of the child modules
-->Verify & refine usecases and quality scenarios as constraints for the child modules
--->*Functional requirements *Constraints *Quality scenarios
*Repeat the above steps
REPRESENT THE ARCHITECTURE WITH VIEWS
*Module decomposition view *Concurrency view *Deployment view
FUNCTIONAL REQUIREMENTS
*User interface *Raising/lowering door module. *Obstacle detection *Scheduler
*Communication virtual machine. *Sensor/actuator virtual machine. *Diagnosis
SOFTWARE ARCHITECTURAL STYLES
*Component types *Connectors *Semantic constraints * A topological layout
PIPE AND FILTER ARCHITECTURAL STYLES
*Pipe and filter invariants *Pipe & Filter speciaizations(pipelines,Batch sequential)
*Pipe and filter examples *Active or passive components
*Pipe and Filter Advantages *pipe and Filter Disadvantages
OBJECT ORIENTED AND DATA ABSTRACTION
*Object oriented invariants *Object oriented specializations
*Objectoriented advantages *Object oriented disadvantages
EVENT BASED,IMPLICIT INVOCATION STYLES
*Implicit invocation variants *Implicit invocation specializations
*Implicit invocation Examples *Implicit invocation advantages
*Implicit invocation Disadvantages
LAYERED SYSTEM STYLES
*Layered style specialization *Layered style examples
*Open vs Closed layered architecture *Layered style advantages *Disadvantages
REPOSITORY STYLES
*The blackboard model
-->Knowledge sources
-->Blackboard datastructure
-->Control
*Repositary style specializations
*Repository style examples
*Repository style advantages
*Repository style disadvantages
INTERPRETER STYLE
*Interpreter style examples
*Interpreter style adavantages
*Interpreter style disadvantages