Upload
zainvisf6018
View
654
Download
2
Tags:
Embed Size (px)
Citation preview
SYED FEROZ ZAINVI
Software Architecture
Writing from:
http://www.computer-science-notes.blogspot.com
Agenda
Software Architecture – Warm UpSoftware Architecture
Definition Elaboration
Architectural Styles/Patterns – OverviewArchitecture & Technologies
Before We Start …
The last decade has seen a tremendous rise in this prominence of a software engineering sub-discipline called Software Architecture
HOWEVER,“Architecture” is one of the most overused
and least understood terms in professional software development circles.
Regularly misused in project reviews and discussions, academic paper presentations at conferences and product pitches.
Software Architecture - Definitions
Easy to understand but no widely accepted definitionTrying to define a term such as software architecture
is always a potentially dangerous activity Difficult to draw a sharp line between design and
architecture Architecture is one aspect of design that concentrates on some
specific features Software architecture is a level of design concerned with issues
To understand the diversity in views, have a browse through the list maintained by the Software Engineering Institute at:
http://www.sei.cmu.edu/architecture/definitions.html
Software Architecture – IEEE Definition
“Architecture is defined by the recommended practice as the fundamental organization of a system, embodied in its components, their relationships to each other and the environment, and the principles governing its design and evolution.”
[ANSI/IEEE Std 1471-2000, Recommended Practice for Architectural Description of Software-Intensive Systems]
Software Architecture – Kazman Definition
“The software architecture of a program or computing system is the structure or structures of the system, which comprise software elements, the externally visible properties of those elements, and the relationships among them.”
[L.Bass, P.Clements, R.Kazman, Software Architecture in Practice (2nd edition), Addison-Wesley 2003]
Software Architecture – RUP Version
Architecture of a software system (at a given point) is the organization or structure of the system's significant components interacting through interfaces, with components composed of successively smaller components and interfaces
Software Architecture – Shaw & Garlan Definition
“[Software architecture goes] beyond the algorithms and data structures of the computation; designing and specifying the overall system structure emerges as a new kind of problem. Structural issues include gross organization and global control structure; protocols for communication, synchronization, and data access; assignment of functionality to design elements; physical distribution; composition of design elements; scaling and performance; and selection among design alternatives.”
[D. Garlan, M. Shaw, An Introduction to Software Architecture, Advances in Software Engineering and Knowledge Engineering, Volume I, World Scientific, 1993]
Architecture Defines Structure
Issue is how to sensibly partition an application into a set of inter-related components
An architecture must be designed to meet the specific requirements and constraints of the application it is intended for
A key structural concern for nearly all applications is minimizing dependencies between components, creating a loosely coupled architecture from a set of highly cohesive components.
Responsibility Driven Design is a technique
Architecture Specifies Component Communication
Issue: How divided components communicate data and control information
Some examples: Within same address space: Method Calls If in different threads or processes: Synchronization
Mechanisms Multiple components to be simultaneously informed
about an event occurrence in application environment MANY POSSIBILITIES
Rescue: Architectural Patterns/Styles
Architecture Specifies Component Communication
Issue: How divided components communicate data and control information
Some examples: Within same address space: Method Calls If in different threads or processes: Synchronization
Mechanisms Multiple components to be simultaneously informed
about an event occurrence in application environment MANY POSSIBILITIES
Rescue: Architectural Patterns/Styles
Overview of Patterns
Essentially reusable architectural blueprints that describe the structure and interaction between collections of participating components.
Has well-known characteristics that make it appropriate to use to satisfy particular types of requirements.
Patterns are quite useful, and convey design information. Proven to work. If used appropriately in an architecture, you leverage existing design knowledge by using patterns.
Large systems tend to use multiple patterns, combined in ways that satisfy the architecture requirements.
Architecture Addresses Non-Functional Requirements
Three distinct areas of non-functional requirements:
Technical constraints: Design constraints by specifying certain technologies Usually non-negotiable.
Business constraints: Design constraints due to business, not technical reasons.
Quality attributes: Requirements in terms of scalability, availability, ease of
change, portability, usability, performance, Address issues of concern to application users &
stakeholders
Architecture Is An Abstraction
Marketecture: 1 pg informal depiction of system structure & interactions
In easy to understand way for team members & stakeholders
Unnecessary details are suppressed or ignoredFocus is on salient architectural issuesComponents as black boxes; specifying only
externally visible propertiesHierarchal decomposition is one such mechanismArchitecture partitions team responsibilities &
dependencies
Describing An Architecture Hierarchicallly
Architecture Views
Software Architecture is a complex design artifact
There are number of ways of looking at and understanding an architecture
Philip Krutchen’s 4+1 View Model (IEEE, 1995) Logical View: Architecturally significant elements Process View: Concurreny & Communication elements Physical View: Mapping of processes/components on to
application’s hardware Development View: Internal organization of software
components
Krutchen's 4+1 … Contd…
Views are tied together by the architecturally significant use cases (UC often called scenarios)
UC basically capture the requirements for the architecture, and hence are related to more
than one particular viewBy working through the steps in a particular
use case, the architecture can be “tested”, by explaining how the design elements in the architecture respond to the behavior required in the use case.
SEI's Views & Beyond
Recommends capturing architecture model using 3 different views:
Module: Structural View – code modules, decomposition, inheritance, association, aggregation
Components & Connectors: Behavioral Aspects- Components: Objects, Threads, Processe
- Connectors: Shared Memory, Sockets, MiddlewareAllocation: Process mapping to hardware,
communication using network/database, source code view in configuration management, dev. responsibility
Uses terminology of Architecture Description Language (ADL)
Architectures & Technologies
Architectural decisions to be made in early project life-cycle
Difficult to validate & test until system is builtJudicious prototyping of key components can helpStill sometimes hard to ascertain success of
particular design choice in given application context
Risks can be reduced by using tried & tested approaches for solving certain classes of problems Architectural Patterns
Patterns - Revisited
Patterns are an abstract representation of an architecture, in the sense that they can be realized in multiple concrete forms.
Abstract architectures must be reified by software engineers as concrete software implementations.
Software products vendors have come to the rescue. Widely utilized architectural patterns are supported in a variety of commercial offthe-shelf (COTS) technologies
Architectural Patterns & Concrete Technologies
Software technologies provide reusable, application-independent software infrastructures that implement proven architectural approaches
Competing commercial and open source products exist (BLESSING) Superficially similar Differs in features,
implementations, constraints, cost Selecting a product that has
quality attributes that satisfy the application requirements is difficult (CURSE)
No one-size-fits-all product available
Identifying strengths & weaknesses of a particular choice is difficult in early stages Poor Choices Failed Projects
References
Ian Gorton, Essential Software Architecture, Springer
Shaw & Garlan, Software Architecture – Perspectives On An Emerging Discipline, PHI
R. Pressman, Software Engineering – A Practitioner’s Approach, McGraw Hill
Pankaj Jalote, Integrated Software Engineering, Narosa Publishing
Special Issue on Software Architecture, CSI Communication, 2008
Notes from RMCS (UK)Rational Suite – Online Help
More computer science notes available at:
http://www.computer-science-notes.blogspot.com
Also linked through:http://
www.crossroadsbyzainvi.blogspot.com