software architecture and quality by
DESCRIPTION
Software Architecture and Quality BY. Touseef Tahir [email protected] Lecturer CS COMSATS Institute of Information Technology, Lahore. Architecture defined Formal Definition. IEEE 1471-2000 - PowerPoint PPT PresentationTRANSCRIPT
Software Architecture and QualityBY
Touseef [email protected]
Lecturer CSCOMSATS Institute of Information Technology, Lahore
IEEE 1471-2000◦ Software architecture is 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
Architecture definedFormal Definition
IEEE 1471-2000
Software architecture encompasses the set of significant decisions about the organization of a software system◦Selection of the structural elements and their interfaces by
which a system is composed◦Behavior as specified in collaborations among those
elements◦Composition of these structural and behavioral elements
into larger subsystems◦Architectural style that guides this organization
Architecture definedAnother Go
Booch, Kruchten, Reitman, Bittner, and Shaw
Perry and Wolf, 1992◦ A set of architectural (or design) elements that have a particular form
Boehm et al., 1995◦ A software system architecture comprises A collection of software and system components, connections, and constraints A collection of system stakeholders' need statements A rationale which demonstrates that the components, connections, and constraints define a system that,
if implemented, would satisfy the collection of system stakeholders' need statements
Clements et al., 1997 ◦The software architecture of a program or computing system is the structure or structures of the system, which comprise software components, the externally visible properties of those components, and the relationships among them
Architecture definedFew More
http://www.sei.edu/architecture/definitions.html
Architecture defines major components Architecture defines component relationships
(structures) and interactions Architecture omits content information about
components that does not pertain to their interactions Behavior of components is a part of architecture insofar
as it can be discerned from the point of view of another component
Common elements 1/2
Architecture defines major components Architecture defines component relationships
(structures) and interactions Architecture omits content information about
components that does not pertain to their interactions Behavior of components is a part of architecture insofar
as it can be detected from the point of view of another component
Common elements 1/2
Every system has an architecture (even a system composed of one component)
Architecture document defines the rationale behind the components and the structure
Common elements 2/2
Architecture represents the set of earliest design decisions◦ Hardest to change◦ Most critical to get right
Architecture is the first design artifact where a system’s quality attributes are addressed
Architecture is Early
Architecture serves as the blueprint for the system but also the project:◦ Team structure◦ Documentation organization◦ Work breakdown structure◦ Scheduling, planning, budgeting◦ Unit testing, integration
Architecture establishes the communication and coordination mechanisms among components
Architecture Drives
Architecture vs. Design
non-functional requirements
functional requirements
(domains)
Important : this is a general guideline – sometimes the borders are blurred
Architecture: where non-functional decisions are cast, and functional requirements are partitionedDesign: where functional requirements are accomplished
architecture
design
Performance Availability Usability Security
System Quality Attribute
MaintainabilityPortabilityReusabilityTestability
End User’s view
Developer’s view
Time To MarketCost and BenefitsProjected life timeTargeted MarketIntegration with Legacy System
BusinessCommunityview
A list of quality attributes exists inISO/IEC 9126-2001 Information Technology – Software Product Quality
Design patterns
Producer consumer problem
You have◦ legacy code◦ current client
Adapter changes interface of legacy code so client can use it
Adapter fills the gap b/w two interfaces e.g date formats
No changes needed for either◦ legacy code, or◦ Client
Adapter
In object-oriented programming, the command pattern is a design pattern in which an object is used to represent and encapsulate all the information needed to call a method at a later time. This information includes the method name, the object that owns the method and values for the method parameters.
Three terms always associated with the command pattern are client, invoker and receiver. The client instantiates the command object and provides the information required to call the method at a later time. The invoker decides when the method should be called. The receiver is an instance of the class that contains the method's code.
Command
You have commands that need to be◦ executed,◦ undone, or◦ Queued
All commands derive from Command and implement do(), undo(), and redo()
You◦ have a set of related classes◦ want to shield the rest of the system from these details
Facade provides a simplified interface Encapsulates a subsystem e-g
◦ wrap a poorly-designed collection of APIs with a single well-designed API
Facade
You want uniformly to treat ◦ items (atomic elements), and◦ groups (containing items or other groups)
Composite interface specifies operations that are shared between items and groups
Examples: hierarchy of files and directories, groups of draw able elements
Composite
You want to◦ delay expensive computations,◦ use memory only when needed, or◦ check access before loading an object into memory
Proxy ◦ has same interface as Real object◦ stores subset of attributes
◦ Example : thread pools
Proxy
You want to◦ use different algorithms depending upon the context◦ avoid having to change the context or client
Strategy ◦ decouples interface from implementation◦ shields client from implementations◦ Context is not aware which strategy is being used; Client
configures the Context
Strategy
You◦ have several different implementations◦ need to choose one, possibly at run time
Bridge ◦ decouples interface from implementation◦ shields client from implementations◦ Abstraction creates and initializes the Concrete Implementations◦ Example:
optimized code execution time, memory usage, disk space, bandwidth, power
consumption
Bridge
Software Architectures
Copyright © 2001 DeLorme28 November 2001
Model view controller
Thin Client Fat Client
Client server architecture
Single tier Two Tier N Tier
Client Server Architectures
Server downloads files from shared location to Desktop environment
Job is run at the desktop environment Works if
◦ Shared usage is low◦ Data transferred is low
File Sharing Architecture
File-Server Architecture
Database server to replace File server Query based approach Reduced traffic, since required content is only
transferred Improves multi-user updating RPC or SQL typically used
Client/Server Architecture
Two Tier Architecture
N-Tier Architecture
Common Architecture for a set of products or systems developed by an organization
Product Line Architecture
Boxes and lines
Software Architecture
Software Architecture
Copenhagen city VIEWS
“4+1 Approach”
4+1 Approach
Process view
Development View
Scenario View
Conceptual viewModule view Execution viewCode view
Siemens Four view model
Develop software architecture for your project….!!!
Assignment
THANK YOU!!!!