What is Software Architecture?

Typical, uninformative software architecture● What can we tell from it?

Typical, uninformative software architecture● What can we tell

from it?● The system consists

of four elements● Three of the

elements might have common with each other

● All of the elements apparently have some sort of relationship with each other

Typical, uninformative software architecture● What can we not tell

from it?● What is the nature of

the elements?● What are the

responsibilities of the elements?

● What is the significance of the connections?

● What is the significance of the layout?

What is Software Architecture

● 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

● One key aspect of architecture is– its organization of element structure, interfaces,

and operating concepts

Implications of definition

● Architecture defines software elements● Systems can and do comprise more than one

structure , and no one structure can claim to be the architecture

● Every computing system with software has a software architecture

● The behavior of each element is part of the architecture

● Architecture will allow or prevent the system from meeting its – behavioral, – performance, – and life-cycle requirements

Other Points of View

● Software architecture is a growing but still young discipline– it has no single, accepted definition

● Software Engineering community has attempt to abstract the commonalities inherent in system design, and it must account for a wide range of activities, concepts, methods, approaches and results.

Other Points of View

● Architecture is high-level design.– Other tasks associated with design are not

architectural, such as deciding on important data structures that will be encapsulated.

● Architecture is the overall structure of the system.– This definition imply that systems have one

structure.

Other Points of View

● Architecture is the structure of the components of a program or system, their interrelationships, and the principles and guidelines governing their design and evolution over time– This definition is process-centered, guideline,

policy are not Architecture● Architecture is components and connectors.

– This definition concentrates on runtime architectural structures , So the static structure will be disappear.

Architectural Patterns , Architectural style ● An architectural pattern is

– a description of element & relation – with a set of constraints on how they may be

used● An architectural pattern is not an architecture

– Examples● Client-Server● 3 Tiers● N- Tiers

● The most useful aspects of patterns is that they exhibit known quality attributes

● Choosing an architectural pattern is often the architect's first major design choice.

Reference Model

● A reference model is a division of functionality together with data flow between the pieces

● A reference model is a standard decomposition of a known problem into parts that cooperatively solve the problem

● Reference models are a characteristic of mature domains.

● Can you name the standard parts of a compiler or a database management system?– If so, it is because you have been taught a

reference model of these applications.

Reference Architecture

● A reference architecture is a reference model mapped onto software elements and the data flows between them– Whereas a reference model divides the

functionality, – a reference architecture is the mapping of that

functionality onto a system decomposition●

Relationships of RM, AP, RA

● They are not architectures

● They are useful concepts that capture elements of an architecture

Analogous

● People often make analogies to other uses of the word architecture

● A building architect must design a building that provides accessibility, aesthetics, light, maintainability, and so on.

● A software architect must design a system that provides concurrency, portability, modifiability, usability, security, and the like, and that reflects consideration of the tradeoffs among these needs.

Why is Software Architecture Important?● From technical perspective

– Communication among stakeholders– Early design decisions– Transferable abstraction of a system (re-use)

Communication among stakeholder● ARCHITECTURE IS THE VEHICLE FOR

STAKEHOLDER COMMUNICATION– Software architecture represents a common

abstraction of a system that most stakeholders can use as a basis for mutual understanding, negotiation, consensus, and communication.

– Each stakeholder of a software is concerned with different system characteristics

● Customer● User● project manager● Coder● Tester● and so on

Early design decisions

● ARCHITECTURE MANIFESTS THE EARLIEST SET OF DESIGN DECISIONS– The Architecture Defines Constraints on

Implementation● Architecture define elements and interaction between

each elements, these are constraints for developer

Early design decisions

● The Architecture Dictates Organizational Structure– The normal method for dividing up the labor in a

large system is called the work breakdown structure (WBS)

– Architecture used as the basis for WBS, which in turn dictates

● units of planning, scheduling, and budget;● interteam communication channels; ● configuration control and file system organization;● integration and test plans and procedures;

Early design decisions

● The Architecture Enables a System's Quality Attributes , Keep these in mind– If your system requires high performance, you

need to manage the time-based behavior of elements and the frequency and volume of inter-element communication.

– If modifiability is important, you need to assign responsibilities to elements such that changes to the system do not have far-reaching consequences.

Early design decisions

– If you believe scalability will be needed in your system, you have to carefully localize the use of resources to facilitate the introduction of higher-capacity replacements.

– If your project needs to deliver incremental subsets of the system, you must carefully manage inter-component usage.

– If you want the elements of your system to be re-usable in other systems, you need to restrict inter-element coupling so that when you extract an element it does not come out with too many attachments to its current environment to be useful.

Early design decisions

● Predicting System Qualities by Studying the Architecture

● The Architecture makes it Easier to Reason about and manage change– 80 percent of a typical software system's cost

occurs after initial deployment.– Software systems change over their lifetimes– Every architecture partitions possible changes

into three categories: local, nonlocal, and architectural

Early design decisions

● The Architecture Helps in Evolutionary Prototyping– Once an architecture has been defined, it can be

analyzed and prototyped as a skeletal system● The system is executable early in the product's life

cycle● Potential performance problems can be identified early

in the product's life cycle.●

Early design decisions

● The Architecture Enables more accurate cost and schedule estimates– the organizational structure of a project is based

on its architecture.– Each team will be able to make more accurate

estimates for its piece. – the initial definition of an architecture has been

reviewed by each team

Transferable abstraction of a system● ARCHITECTURE AS A TRANSFERABLE, RE-

USABLE MODEL● While code re-use is beneficial, re-use at the

architectural level provides tremendous leverage for systems with similar requirements.

● When architectural decisions can be re-used across multiple systems, all of the early decision consequences we just described are also transferred.

Transferable abstraction of a system● Software Product Lines Share a Common

Architecture● Product line architects choose an architecture

that will serve all envisioned members of the product line.

● by making design decisions that apply across the family early and by making other decisions that apply only to individual members late.

Transferable abstraction of a system● Systems Can Be Built Using Externally

Developed Elements– Architecture-based development focuses on

composing or assembling elements that are likely to have been developed separately, even independently, from each other.

– This composition is possible because the architecture defines the elements that can be incorporated into the system

Transferable abstraction of a system● Less Is More: It Pays to Restrict the

Vocabulary of Design Alternatives– we wish to minimize the design complexity of the

system we are building. – Advantages to this approach include enhanced

re-use, more regular and simpler designs that are more easily understood and communicated, more capable analysis, shorter selection time, and greater interoperability.

● An Architecture Can Be the Basis for Training– The architecture can serve as the introduction to

the system for new project members

System Arch VS Software Arch

● In fact, there is little difference,● In creating a software architecture, system

considerations are seldom absent● Most of the architect's freedom is in the

software choices, not in the hardware choices.–

System Arch VS Software Arch

● Hardware choices may be out of the architect's control (for example, when creating a system that needs to work on arbitrary client machines on the Internet) or specified by others (for reasons of economics, legal issues, or compliance with standards); or they will likely change over time.

Architectural Structures and Views

● A structure is the set of elements● Architectural structures can be divided into 3

groups ● These 3 structure groups correspond to the

types of decision that architectural design involves:

● How is the system to be structured as a set of code units (modules)?

● How is the system to be structured as a set of elements that have runtime behavior (components) and interactions (connectors)?

● How is the system to relate to nonsoftware structures in its environment (i.e., CPUs, file systems, networks, development teams, etc.)?

●

Architectural Structures and Views

Structure & View :Module

Structure & View : Component and Connector

Structure & View : Allocation

Relating structures to each other

● Each of these structures provides a different perspective

● They are not independent. ● Elements of one will be related to elements of

others– a module in a decomposition structure may be

manifested as one, as part of one, or as several components in one of the component-and-connector structures, reflecting its runtime

Summary

● Software architecture definitions● Concepts of reference model, reference

architecture, and architectural pattern.● Systems comprise many structures.● We showed several of the most commonly

used structures and explained how each serves as an engineering leverage point into the design process.