Scribd
Upload
89 views

Chapter 1-What Is Software Architecture

This document discusses software architecture. It defines software architecture as the set of structures that comprise software elements, relations among them, and their properties. There are three categories of architectural structures: module, component-connector, and allocation. Module structures show how a system is partitioned into implementation units. Component-connector structures show how elements interact at runtime. Allocation structures map software to environments like hardware. Views represent structures. Good architecture depends on context and stakeholder goals.

Uploaded by

MD HOSSAIN
Copyright
© © All Rights Reserved
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
89 views

Chapter 1-What Is Software Architecture

This document discusses software architecture. It defines software architecture as the set of structures that comprise software elements, relations among them, and their properties. There are three categories of architectural structures: module, component-connector, and allocation. Module structures show how a system is partitioned into implementation units. Component-connector structures show how elements interact at runtime. Allocation structures map software to environments like hardware. Views represent structures. Good architecture depends on context and stakeholder goals.

Uploaded by

MD HOSSAIN
Copyright
© © All Rights Reserved
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
You are on page 1/ 22

BISE2013

Software Architecture & Design


CHAPTER 1
Introduction to Software Architecture
CHAPTER OUTLINE
1. What is Software Architecture

2. Architectural Structures and Views

3. Architectural Patterns

4. What Makes a “Good” Architecture?

5. Summary
What is Software Architecture
 The software architecture of a computing system is the set of structures needed to reason
about the system, which comprise software elements, relations among them, and properties of
both.

 Shaw and Garlan


 Software architecture [is a level of design that] involves
 the description of elements from which systems are built,
 interactions among those elements,
 patterns that guide their composition, and
 constraints on these patterns.

 A structure is a set of elements held together by a relation.


 Software systems are composed of many structures, and no single structure holds claim to being
the architecture.
Architectural Structures and Views
There are three important categories of architectural structures.
1. Module
How is the system to be structured as a set of code units (modules)?
2. Component and Connector
How is the system to be structured as a set of elements that have runtime behaviour
(components) and interactions (connectors)?
3. Allocation
How is the system to relate to non software structures in its environment (i.e., CPUs, file
systems, networks, development teams, etc.)?
Module
1. Some structures partition systems into implementation units, which we call
modules.
2. Modules are assigned specific computational responsibilities, and are the
basis of work assignments for programming teams.
3. In large projects, these elements (modules) are subdivided for assignment
to sub-teams.
4. Module structures allow us to answer questions such as:
- What is the primary functional responsibility assigned to each module?
- What modules are related to other modules
Module View Example
Some Useful Module Structures
A. Class (or generalization) structure
1. The module units in this structure are called classes.
2. The relation is inherits from or is an instance of.
3. This view supports reasoning about collections of similar behavior or
capability. e.g : the classes that other classes inherit from and parameterized
differences
4. The class structure allows one to reason about reuse and the incremental
addition of functionality.
5. If any documentation exists for a project that has followed an object-
oriented analysis and design process, it is typically this structure.
B. Data model

The data model describes the static information structure in terms of data
entities and their relationships.
 For example, in a banking system, entities will typically include Account,
Customer, and Loan.
 Account has several attributes, such as account number, type (savings
or checking), status, and current balance.
C. Component-and-connector Structures
1. Other structures focus on the way the elements interact with each other at runtime to carry
out the system’s functions.
2. We call runtime structures component-and-connector (C&C) structures.
3. In our use, a component is always a runtime entity.
- Suppose the system is to be built as a set of services.
- These services are made up of (compiled from) the programs in the various
implementation units – modules.
4. Component-and-connector structures help answer questions such as:
- What are the major executing components and how do they interact?
- What are the major shared data stores?
- How does data progress through the system?
- What parts of the system can run in parallel?
- How can the system's structure change as it executes?
Component-and-connector View Example
Allocation Structures
1. Allocation structures describe the mapping from software structures to
the system’s environments
 Developmental
 Installation
 Execution

2. For example:
 Modules are assigned to teams to develop, and assigned to places in a file structure for
implementation, integration, and testing.
 Components are deployed onto hardware in order to execute.

3. They answer questions such as:


 What processor does each software element execute on?
 In what files is each element stored during development, testing, and system building?
Deployment Diagram
Some Useful Allocation Structures
Deployment structure
 The deployment structure shows how software is assigned to hardware
processing and communication elements.
 The elements are software elements, hardware entities (processors), and
communication pathways.
 This structure can be used to reason about performance, data integrity,
security, and availability.
 It is of particular interest in distributed and parallel systems.
Some Useful Allocation Structures
Work assignment structure
 This structure assigns responsibility for implementing and integrating the
modules to the teams who will carry it out.
 Having a work assignment structure be part of the architecture makes it clear
that the decision about who does the work has architectural as well as
management implications.
 The architect will know the expertise required on each team.
 This structure will also determine the major communication pathways among
the teams: regular teleconferences, wikis, email lists, and so forth.
What Makes a “Good” Architecture?
 There is no such thing as an inherently good or bad architecture.

 Architectures are either more or less fit for some purpose

 Architectures can be evaluated but only in the context of specific


stated goals.

 There are, however, good rules of thumb.


Rules of Thumb
1. Process Recommendations:
 include functional requirements and a prioritized list of quality attributes the
system must satisfy
 analyze & formally evaluate before it is too late to change

2. Product Recommendations:
 well-defined modules using principles of information hiding & separation of
concerns
 separate modules that produce data from those that consume data to increase
modifiability & staged upgrades
 write tasks or processes to allow easy reallocation, perhaps at runtime
Stakeholders in a System’s Architecture
1. Architects
2. Developers
3. Testers
4. Managers
5. Customers
6. Users
7. Vendors
Figure 1.2 Influence of stakeholders on the architect
Architectural Influences
 Stakeholders
 each stakeholder has different concerns & goals, some contradictory
 Development Organization
 immediate business, long-term business, and organizational (staff skills,
schedule, & budget)
 Background & Experience of the Architects
 repeat good results, avoid duplicating disasters
 The Technical Environment
 standard industry practices or common SE techniques
Summary
1. The software architecture of a system is the set of structures
needed to reason about the system, which comprise software
elements, relations among them, and properties of both.
2. A structure is a set of elements and the relations among them.
3. A view is a representation of a coherent set of architectural
elements.
4. A view is a representation of one or more structures.
5. There are three categories of structures:
 Module structures show how a system is to be structured as a set of code or data
units that have to be constructed or procured.
 Component-and-connector structures show how the system is to be structured as a
set of elements that have runtime behavior (components) and interactions
(connectors).
 Allocation structures show how the system will relate to nonsoftware structures in its
environment (such as CPUs, file systems, networks, development teams, etc.).
6. Structures represent the primary engineering leverage points of an
architecture.
 Every system has a software architecture, but this architecture may be documented
and disseminated, or it may not be.
 There is no such thing as an inherently good or bad architecture. Architectures are
either more or less fit for some purpose.
THE END

You might also like