CHAPTER 1

BASIC TERMS OF SOFTWARE

ARCHITECTURE
LEARNING OBJECTIVES
 The participants should be able to:
 Understand and distinguish between different types of
software-intensive systems.
 Discuss definition of software architecture.
 Understand and identify the benefits and objectives of
software architecture.
 Understand the place of software architecture within the
software life cycle.
 Understand software architects tasks and responsibilities.
 Relate the role of software architects to other stakeholders.
 Explain the correlation between development approaches
and software architecture .
2
 Know the roles and responsibilities of software architects
OUTLINE

 Introduction to software architecture

 Development approaches and software architectures

 Formation and refinement of software architecture

 Architect roles and tasks

3
 INTRODUCTION TO SOFTWARE
ARCHITCETURE
4
WHAT ARE THE MOST IMPORTANT SUCCESS
KEYS FOR A SOFTWARE DEVELOPMENT?

 User centric method

 Good software architecture

 Approved design and development techniques

 Performance Integrated development environment

(IDE)
 Quality management system

 Confirmed developer

 Teams working in harmony

 Strict project management

 Processes, methods and organization

5
DEFINITIONS :
SOFTWARE / SOFTWARE SYSTEM
 Software system :
 A system of intercommunicating software components
as a part of a computer system.
 It consists of a number of :
 Separate programs.
 Configuration files.

 System documentation.

 User documentation.

 Types of software systems:

 Embedded, mobile, information systems

6
TYPES OF SOFTWARE SYSTEMS
 Embedded system :

 A software system embedded as part of a complete device

often including hardware and mechanical parts.
 Has a dedicated function within a larger mechanical or
electrical system, often with real-time computing constraints.
 Controls many devices.

 Examples : ADSL modem, MP3 players, traffic lights, hybrid

vehicles, avionics, etc.

7
TYPES OF SOFTWARE SYSTEMS
 Information system:

 A software system to collect, filter, process, create and

distribute data.
 Supports operation, management and decision making.

 Implies many users.

 Examples : Insurance system, simulation tools, data

warehouses, enterprise resource planning, etc.

8
TYPES OF SOFTWARE SYSTEMS
 Mobile systems :
 A software system that operates on smartphone, tablet,
PDA or other mobile device.
 Set of data and programs that runs mobile device.
 Manage mobile multimedia functions, mobile and
internet connectivity and so on in a mobile device.

 Examples : Android systems and applications, etc.

9
SOFTWARE INTENSIVE SYSTEMS - DEFINITION
 Software intensive systems:
 Systems in which software interacts with other software,
systems, devices, sensors and with people.

 Examples : Embedded system for automative and

avionics applications, telecommunication systems,
business applications with an emphasis on web
services, etc.

10
WHAT IS SOFTWARE ARCHITECTURE?
 Architectures capture three primary dimensions:
 Structure
 Communication

+ Non functional requirements (NFR)

 NFR
 Technical constraints: restrictions made for technical reasons
 Business constraints: restrictions made for business reasons
 Quality attributes:
 Scalability
 Security
 Performance
 Maintainability
 Evolvability
 Reliability/Dependability
 Deployability 11
SOFTWARE ARCHITECTURE - DEFINITIONS

 Definition 1 : The fundamental concepts or

properties of a system in its environment
embodied in its elements, relationships, and in
the principles of its design and evolution.

[ISO/IEC/IEEE 42010]

12
SOFTWARE ARCHITECTURE - DEFINITIONS

 Definition 2: 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.

[SEI]

13
SOFTWARE ARCHITECTURE - DEFINITIONS
 Definition 3: An architecture is the set of significant
decisions about the organization of a software
system, the selection of the structural elements and
their interfaces by which the system is composed,
together with their behavior as specified in the
collaborations among those elements, the
composition of these structural and behavioral
elements into progressively larger subsystems, and
the architectural style that guides this organization –
these elements and their interfaces, their
collaborations, and their composition.

[Booch, Rumbaugh, and Jacobson – The UML Modeling Language User

Guide, Addison-Wesley, 1999] 14
SYNTHESIS..
 Software architecture describes the structures of
the system, including:
 Software Elements
 Elements are captured as abstractions
 Correspond to high level system modules or components

 External Visible Properties of elements

 Describe element features exposed to others
 Typically represent services provided to other elements

 Relationships of elements
 Describe how elements interact with others
15
SOFTWARE ARCHITECTURE STRUCTURES -
EXAMPLES

Modules Components and connections

16
SOFTWARE ARCHITECTURE STRUCTURES -
EXAMPLES

Distribution

17
STRUCTURES FROM MULTIPLE VIEWS
 Large software systems requires structures from
multiple perspectives (views)
 A single view is not sufficient to address requirements

 Examples of views
 The context view focuses on the system functionality
 The deployment view reflects the physical deployment
of software components to computing hardware

18
ANALOGY : BUILDING ARCHITCETURE VIEWS

 Examples:

2D Front view Floor plan view

19

Room plan view

WHY SOFTWARE ARCHITECTURE?
JUSTIFYING THE NEED FOR ARCHITECTURE
 Crucial changes in software engineering have
increased the importance of architecture:
 Scale
 Distribution
 Security

Minimally distributed system

Higly distributed system

20
FORMATION AND REFINEMENT OF
SOFTWARE ARCHITECTURE
SOFTWARE ARCHITECTURE IN SOFTWARE
DEVELOPMENT PROCESS

22
SOFTWARE ARCHITECTURE IN SOFTWARE
DEVELOPMENT PROCESS

23
FORMATION OF SOFTWARE ARCHITECTURE
 What must be known?
 Functional requirements
 Non functional requirements (quality attributes)
 Influencing factors

 When?
 At project begining
 During the development and the maintenance of the
system
 How?
 Incremental refinement and extension
 Small teams
24
 Using experience
REFINEMENT OF SOFTWARE ARCHITECTURE

 Initial formation:
 Study requirements
 Design a rough architecture

 Refine software architecture iteratively:

 Study requirements in detail
 Consider feedbacks
 Extend software architecture

Software Design
Requirements
architecture Implementation

25
CHARACTERISTICS OF A GOOD SOFTWARE
ARCHITECTURE

 A good software architecture must:

 Consider for the system:

 The functional requirements.
 The non-functional requirements.

 The entire system life cycle.

 Help us to understand the system:

 Divide the system meaningfully.
 Form aspects-oriented views.

 Abstract complicated details.

26
CHARACTERISTICS OF A GOOD SOFTWARE
ARCHITECTURE

 Provide the framework for:

 Realization.
 Project planning.

 Project organization.

 Integrate all the development artefacts.

 Provide documentation.

27
QUALITY OF SOFTWARE ARCHITECTURE
 Software quality attributes = non functional requirements (NFR)

 Risks of inadequate software quality:

 May cause high costs
 May complicates the error correction
 Bug fixing may lead to new bugs because of interdependency
 may lead to variance from current to target state

 NFR must be quantified:

 Mean Time Between Failure (MTBF)
 Average response time
 Specification of quality scenarios
 Requirements for load behavior and scalability
 Words like “often”, “many”, “safe”, “fast” are not realizable

 Exceptions and fault situations must be declared

28
CONSIDERING THE FUTURE
 Software architecture is realistic clairvoyance.
 Change requirements in the future?
 Changes in the system environment.
 System extension.

 Are the decision sustainable?

 Reuse of the product in the future?

 Compare costs and benefits of decisions!

29
 DEVELOPMENT APPROACHES &
SOFTWARE ARCHITECTURES
30
PROGRAMMING PARADIGMS EVOLUTION

31
Source : école Hes SO
PROCEDURAL APPROACH
 The main program coordinate procedure invocation
and manage data through parameters

32
MODULAR APPROACH
 Similar functionalities are grouped into seperated
modules
 The main program coordinates procedure
invocation

33
OBJECT ORIENTED APPROACH
<<Programming in the small>>
 Each object encapsulates its internal state (data)
and behavior (functionalities), and interacts with
each other by procedure invocation

34
COMPONENT ORIENTED APPROACH
<<Programming in the large>>
 A component is an architectural entity that
 encapsulates a subset of the system’s functionality and/or
data
 restricts access to that subset via an explicitly defined

interface
 has explicitly defined dependencies on its required execution

context

Component
Object

35
SERVICE ORIENTED APPROACH
 Both components and services are self-contained
functionality. Services enable your components to go across
language boundary.
 For example, a component in .Net can talk to a
component in Java through generalized messages in XML
via Web services (i.e SOAP or RESTFul).

36

Object Component Service

ROLES OF SOFTWARE ARCHITECT
THE IDEAL SOFTWARE ARCHITECT

Vitruvis (Roman author, architect, and civil engineer during the 1st century BC)

38
SOFTWARE ARCHITECT

 Brings the development phases

together
 Analysis, design, implementation,
management and maintenance of
the software
 Central role in software projects
 The main tasks of the software
project
 Knowledge in width (not always
in depth)
39
SOFTWARE ARCHITECT: INTERFACES TO
OTHER ROLES

40
INTERFACES TO OTHER ROLES

 Accepts requirements from the analyst

 Examines the feasibility requirements
 Recognizes inconsistencies
 Defines structure for the result of analysis

41
INTERFACES TO OTHER ROLES

 “Layer” of customer
 Ensures that requirements are realizable
 Ensures that requirements are implemented

42
INTERFACES TO OTHER ROLES

 “advisor” of the project management

 Project planning
 Planning of iterations
 Risk analysis and prevention
 Definition of work packages

43
INTERFACES TO OTHER ROLES

 Contact person of the developer

 Build understanding
 Development specification
 Experience transfer
 Code reviews
44
INTERFACES TO OTHER ROLES

 Contact person of the tester

 Test framework conditions
 Test cases
 Order and dependencies during testing
 Accepts error messages

45
INTERFACES TO OTHER ROLES

 Contact person for security manager

 Provides security related information
 Accepts security analysis
 Consider security policies
 Consider privacy policy
46
INTERFACES TO OTHER ROLES

 Contact person of operation

 Uses operationnal framework
 (Network topology, available hardware and software operating
systems)
 Defines deployment structure
 Defines configuration possibilities
47
TASKS OF SOFTWARE ARCHITECT

48
OTHER TASKS OF SOFTWARE ARCHITECT…

49
USE OF NOTATION AID

50
ARCHITECTURE MODELING USING UML
 Use class diagrams to describe the domain model

51
ARCHITECTURE MODELING USING UML
 Use interaction diagrams to model the interaction
and data communication between components
 Interaction diagrams include communication and
sequence diagrams
 A communication diagram example

52
ARCHITECTURE MODELING USING UML
 Use component diagrams to model essential
system components and their relationship

53
ARCHITECTURE MODELING USING UML
 Use deployment diagrams to show the layout of
hardware nodes and the deployment of
components

54
ARCHITECTURE MODELING USING UML
 Use package diagrams to describe the organization of
systems, technologies and components

55
CONSIDER SERVICE QUALITY

56
CHOOSE TECHNOLOGIES AND TOOLS
 Technologies
 Existing best practise solutions for problems
 Frameworks, libraries, components

 Tools
 Software development tools

 Architect knows existing solutions

 Cost/effective
 Cost/benefit

57
SUPPORT PROJECT STAFFS
 Architect
 Plans architecture activities
 Reviews artifacts (code, model, test,…)
 Transfers knowledge
 Integrates other teams
 Presents products
 Soft skills of an architect
 Capacity of abstraction
 Assertiveness
 Capacity for teamwork

58
SUPPORT PROJECT MANAGEMENT
 Suggests a suitable team structure for the
architecture
 Provides cost estimation

 Suggests adapted approach

 Reports status of development

 Provides dependencies between artifacts

59
 REFERENCES
 Oracle Support “Developing Architectures for Enterprise Java
Applications »

 Essential Software Architecture by Gorton, Ian, 2nd ed. 2011

 Software Architecture: A Comprehensive Framework and Guide for

Practitioners by Oliver Vogel, Ingo Arnold, Arif Chughtai, Timo
Kehrer, September 17, 2011

60