Software Architecture

SOFTWARE ARCHITECTURE

Why Software Architecture?



Why Software Architecture ? 1. 2. 3. 4. 5.

Increasing Size and Complexity of Software Systems. Designing and Specifying the overall system structure. Gross organization and global control of systems structure. Scaling and Performance. Selection among design alternatives.

What is Software Architecture? 

A working definition of Software Architecture: “ A software architecture is a description of the sub-systems and components of a software system along with its inter-relationships. Sub-systems and components can be specified in multiple views or perspectives to show the various functional and nonfunctional properties of a software system. The software architecture of a system is an artifact. This is the result of the software design activity.”

Where does Software Architecture fit in the

Requirements Eng. Deployment Maintenance

Arch. Design Testing

Detailed Design Coding

What is Software Architecture?



3)

4) 5) 6) 7)

Software Architecture - Involves Description of elements from which systems are built. Interactions among those elements. Patterns that guide their composition. Constraints on these patterns Systems built in 1) may be in turn used as a composite element in a larger system design.

Important Terminologies used in Software Arch

    

Component Connectors or Relationships View Functional Property Non-Functional Property

Component.

 An encapsulated part of a software system.  Serves as building blocks of the system and has an interface.  At programming level – modules, classes, objects or related functions.  Categorization of Components:   

Processing Elements Data Elements Connecting Elements.

Connectors or Relationships Denotes a connection between components.  Could be Static or Dynamic.  Static Relationships - Placement of Components within architectural model. eg. - Aggregation and Inheritance  Dynamic Relationships – Temporal Connections and Interactions between components. eg. – Creation of Objects and Communication between Objects.

View

 A partial aspect of a software architecture that shows specific properties of a software system. Eg., - State View, Data Flow View.  Soni, Nord, Hofmeister - Describes four views of SA 1. Conceptual Architecture 2. Module Architecture 3. Code Architecture 4. Execution Architecture.  P.B. Kruchten’s 4 views of Software Architecture: 1. Logical View 2. Process View 3. Physical View 4. Development View

Functional Property

 Deals with particular aspect of a system’s functionality.  Related to Specified Functional requirement.  Seldom explicitly stated in SAs., and mostly assumed implicitly.  Stating explicitly with Functional Properties help in traceability of an architectural element to its functional requirements.

Non-Functional Property

 Not covered by its functional description.  Addresses aspects like reliability, compatibility, maintainability, interoperability , changeability, efficiency, testability and reusability of a software system.

Concerns of Software Architecture ARCHITECTURE Interaction among parts

SOFTWARE IMPLEMENTED Implementation of parts

Structural properties

Computational properties

Declarative

Operational

Mostly static

Mostly dynamic

System level performance Algorithmic performance Outside module boundary Inside module boundary

and

Concerns of Stakeholder in Software Archi Customer

User

1.Schedule and budget est. 2.Feasibility and risk assessment. 3.Requirements traceability. 4.Progress tracking

Architect 1. 2. 3. 4.

SA

1.Consistency with req. and usage scenarios. 2. Future req. growth accom -modation. 3. Performance, reliability, interoperability.

Developer 1.Sufficient detail for design. 2.Reference for selecting and assembling components. 3.Maintain interoperability with existing system.

Requirement traceability. Support of Trade-off-Analysis. Completeness. Consistency of Architecture

Guidance on software modification, architecture evolution and interoperability

Maintainer

Architectural Styles a.What are Architectural Styles? An architectural style  defines a family of systems  in terms of a pattern of structural organization  provides a vocabulary of components and connector types  a set of constraints on how they can be combined  A semantic model may also exist which specify how to determine a system's overall properties from the properties of its parts

Architectural Styles

b.

Various types of Architectural Styles i. Pipes and Filters ( Data flow Architectures). ii. Data Abstraction and Object Oriented. iii. Event Based and Implicit Invocation. iv. Layered Systems. v. Repositories. vi. Interpreters. vii. Process Control

4.Heterogeneous Architectures  The combination of several styles.  Components of a hierarchical system may have an internal structure developed using a different method.  Connectors may also be decomposed into other systems (e.g. pipes can be implemented internally as FIFO queues).  A single component may also use a mixture of architectural connectors. Example- Unix pipes-and-filter system - File system acts as the repository, - Receives control through initialization switches, - Interacts with other components through pipes.

MAPPING REQUIREMENTS TO ARCHITECTURAL DESIGN 1. DATA ARCHITECTING 2. MAPPING

DATA ARCHITECTING  Creates a model of data (data modeling) represented at a higher level of abstraction  Refined progressively more implementation-specific representations  In applications, architecture of data have profound influence on the software architecture  Data architecting at various level: 1. Program Component Level – DS and Algorithms 2. Application level – Database 3. Business level – Data Warehousing

Component Level Data Architecting  Focuses on representation of data structures that are accessed by one or more software components  Data architecting or design begins during the creation of requirement analysis model  Set of principles for data specification or model: 1. Systematic analysis principles should be applied to data as in the cases of function and behavior 2. All Data Structures and operations to be performed on each should be identified 3. A Data-Dictionary should be established and used to define both data and program design

Component Level Data Architecting… 4. Low-level data design decisions should be deferred until late in design 5. Representation of data structures be known only to those modules that must make direct use of the data 6. Library of useful data structures and operations should be developed 7. A software design and programming language should support the specification and realization of abstract data types.

Analyzing Alternative Architectural Designs 1. ATAM 2. QUANTITATIVE TECHNIQUE

ATAM  ATAM – Architectural Trade-off Analysis Method developed at SEI-CMU.  An iterative evaluation process for software architectures  Design analysis activities are: 1. Collect Scenarios 2. Elicit requirements, constraints and environmental description 3. Describe the Architectural Style/Patterns chosen to address the Scenarios and Requirements

ATAM 4. Evaluate quality attributes by considering each attribute in isolation 5. Identify the sensitivity of quality attributes to various architectural attributes for a specific architectural style 6. Critique candidates architectures using the sensitivity analysis conducted in step 5