SOFTWARE ARCHITECTURE

INTRODUCTION TO SOFTWARE ENGINEERING

PHILIPPE LALANDA

PURPOSE OF THIS CLASS

Anintroductiontosoftwarearchitecture• Whatisanarchitecture• Whyitisimportant• Howitisrepresented

2

OUTLINE §  Definition

§  An important activity

§  A difficult activity

§  Representation

§  Conclusion

3

SOFTWARE ARCHITECTURE – DEFINITION “Software architecture is the high level structure of a software system, the discipline of creating such a high level structure, and the documentation of this structure.”

Documenting Software Architecture – Views and Beyond, Clements, Bachmann, Bass, Garlan, Ivers, Little, Merson, Nord, Stafford; Addison-Wesley, 2010

4

THREETYPEOFVIEWS Module-based

•  Structureasasetofimplementationunits•  Packages,Bundles,Jars,Projects

ComponentandConnector(C&C)

•  Structureasasetofelementsthathaveruntimebehaviorandinteractions

Allocation-Centric

•  Howitrelatestonon-softwareelements

5

C&C-DEFINITION How a software system is decomposed into functional units in interaction

•  Functional units are called components •  Interactions are called connectors

Call-Return Event

6

C&C-DEFINITION What C&C views are for

•  Showing how the system works

•  Guiding development by specifying the structure and the behavior of runtime elements

•  Helping architects and others to reason about runtime system quality attributes, such as performance, reliability and availability

7

COMPONENTS-DEFINITION Components

•  Components are the principal computational elements and data stores that execute in a system.

•  Components have interfaces called ports.

Ports

•  A port is an interface of a component. A port defines a point of interaction of a component with its environment.

8

CONNECTOR-DEFINITION Connector

•  A connector is a runtime pathway of interaction between two or more components.

•  Connectors endpoints are component ports.

Role

•  A role is an interface of a connector. A role defines a point of interaction of a connector and indicates how components may use a connector in interactions.

9

SOFTWARECOMPONENT-1 Components

•  Provided and Required functions / ports •  Properties, constraints (formal or informal) •  Possible some code •  Considered independently all along lifecycle

provided ports

required ports

Admin APIs

10

SOFTWARECOMPONENT-2 Two types of components

•  Simple / Primitive / Scalar •  Contains an implementation

•  Composites Abstract Component

Provided functions Required functions Properties Constraints

Simple Component Composite

Contains

code 11

CONNECTORS–1

Interaction specification • First order objects • The role, type of interactions • Possibly a middleware to be used

Architecture Name Constraints Properties

Component Connector

Contains Contains

Connects

(1,n) (1,n) (2,n) (1,n)

12

DIFFERENTTYPESOFCONNECTORS Some examples

Data-flow

Batch sequential

Pipe and filter

Pipeline Unix Pipe and Filter

Call-Return

Client Server

Multi-tier client server

Peer to peer

Service-orientation Restful

Event-based

Publish-subscribe

Point to point

messaging

Repository

Shared data

13

EXAMPLE

C/S

Firewall

Load balancer

Web server I Web server II

Application server

DBMS

C/S

C/S C/S

C/S

C/S Evt Logger

14

EXAMPLE

C/S

Firewall

Web server I Web server II

Application server

DBMS

C/S

C/S C/S

C/S

C/S Evt Logger

15

ASAISANEWLEVELOFABSTRACTION Used at design time and/or at runtime

•  It does not bother with implementation details •  It provides relevant properties of components and

connectors

Assembly language

Data structures

Classes, procedures

Architectural elements

Abstraction

16

ASOFTWAREARCHITECTUREISAMODEL It provides an abstract, simplified view

It is focused on some aspects

At design time and at runtime

Drives implementation and deployment

Execution

Drives maintenance

17

ASAISACOMPLETESPECIFICATION It is a guideline for developers/maintainers

•  Must give all the necessary information •  Possibly used by partners, remote teams, …

•  Must be precise •  No place for fuzzy information

•  Complete regarding the covered aspects!

18

ARCHITECTUREANDLIFECYCLE First design step

•  Decompose the system into software components to reduce its complexity

Legacy + wrapper

Architectural design 2

Specification 1 Analyse Validation

3

4 Detailed design

19

CONCLUSION Architectureexplicitlyappearsineverysoftwareprocess

•  Design time •  Cornerstone •  Agile methods stress the role of architecture

Alsoimportantduringmaintenance

• Locate issues / bugs • Retro-engineering is often required

20

OUTLINE §  Definition

§  An important activity

§  A difficult activity

§  Representation

§  Conclusion

21

A KEY STEP

Specification

Deadline

Budget

22

A KEY STEP Communication

Project structuration

Lead technology

choices

Impact on quality and

business 23

COMMUNICATION VECTOR

Architecture provides a framework allowing most stakeholders to interact

•  Presentation •  Negotiation

•  Change requests •  Project management

•  Quality evaluation, progress assessment

Sometimes, too many interactions !

24

PROJECT STRUCTURATION

Development plan definition •  Tasks definition •  Task allocation definition •  Roles / duties definition

Interaction definition •  How teams are going to interact •  Methods, documents to be

produced

25

TECHNOLOGIES DEFINITION

Technological choices •  Technologies to be used

•  JavaEE, .Net, …

•  Components to be developed •  Components to be reused •  Components to be bought

•  Components Off the Shelves (COTS)

•  Partnership definition •  IBM, Microsoft support

26

EXAMPLE

C/S

Firewall

Load balancer

Web server I Web server II

Application server

DBMS

C/S

C/S C/S

C/S

C/S Evt Logger

Acquisition

Reuse

Open Source

Internal JavaEE expertise

Internal DBMS expertise 27

IMPACT ON SOFTWARE QUALITY

Architecture has a strong impact on the system final properties •  An architecture favors or degrades

non functional properties •  Performance and efficiency •  Security and safety •  Reliability and availability, …

•  A first compromise is made at the architectural level. In a definitive manner …

28

EXAMPLE

On the same machine

+ reliability + performance

On two different machines

+ availability (caches, …) + maintainability + large scale performance

Application server DBMS

29

EXAMPLE

More examples •  A small number of components favors performance

but not maintainability •  A large number of components favors maintenance

but not performance •  Redundancy favors safety but not security

I t i s the beginning of design headaches

30

IMPACT ON BUSINESS

Deployment of an architecture allows •  the creation of a common assets

•  Reusable components, specialized tools, training sessions

•  Various optimizations •  Learning curve, infrastructure costs, …

A n e n t e r p r i s e a r c h i t e c t u r e i s a n infrastructure shared by the whole company

•  Hard to change !

31

CONCLUSION Architectural decisions have an important, lasting impact

Architectures must be carefully validated as soon as possible

•  Evaluation reviews •  Prototypes development •  Key technologies evaluation

Architecture influences quality … but does not provide any guarantees

32

OUTLINE Definition

An important activity

A difficult activity

Representation

Conclusion

33

MULTIPLE INFLUENCES

Different actor

Technological factors

The architect

Organizational factors

Starting from the same requirements, two architects will end up with two architectures.

Why ? 34

DEALING WITH PEOPLE, DEALING WITH INFLUENCES

Architect Customer

Marketing/Strategy

User

Customer Project Leader

Ops

Developers

35

MARKETING / STRATEGY

Architect Customer

Marketing/Strategy

User

Customer Project Leader

Ops

Developers

•  Market tendency •  Coherence with company plans •  Coherence with company image (innovative, safe, …) •  Partnership coherence

36

PROJECT LEAD

Architect Customer

Marketing/Strategy

User

Customer Project Leader

Ops

Developers

•  Overall simplicity •  Opportunity to assess progress •  Requirements meeting •  Mastered technology •  Structuration in line with existing teams •  Reuse of internal components and expertise •  Risk management

37

DEVELOPERS

Architect Customer

Marketing/Strategy

User

Customer Project Leader

Ops

Developers

•  Well defined components, simple interfaces •  Hot technology •  No constraints on his components

38

OPS

Architect Customer

Marketing/Strategy

User

Customer Project Leader

Ops

Developers

•  Component isolation •  Administration oriented interfaces •  Known technologies

39

CUSTOMER

Architect Customer

Marketing/Strategy

User

Customer Project Leader

Ops

Developers

•  Guarantee of good behavior •  Efficient, cheap technologies •  Deadline meetings

40

USER

Architect Customer

Marketing/Strategy

User

Customer Project Leader

Ops

Developers

•  To the job •  Easiness of use •  Performance, security, robustness

41

EXAMPLE

Webserver

Applicationserver

Developer:cool!

Manager:cool,itisgoingtocostalot!

Client:no,tooexpensive!

Architect:necessarytomeettherequirementsIhave!

Ops:no,tooinstable!User:interfacestability?

42

ORGANIZATIONAL FACTORS Architectural decisions are deeply influenced by the organization goals and strategy

•  Use of existing expertise and targeted expertise •  Existing internal methods •  Needs regarding reuse ( to amort i ze past

investments) •  Partnerships

43

EXAMPLE

IBM : Good ! Both are needed (WS et DB2) !

ORACLE : DBMS rules. No need for an application server !

Application server

Database server

1..* 1

JBOSS: Application server matters. DBMS is not an issue.!

Microsoft : Ok, but forget about Java!

44

TECHNOLOGICAL FACTORS Technological changes

•  Centralized vs. Distributed •  Rich client vs. thin client •  XML vs. JSON vs. YAML •  Web services vs. RestFul

There is a fashion dimension!

45

ARCHITECT INFLUENCE

Architects use their past experiences •  Good experiences will lead to reuse

successful solutions •  Bad experiences will lead them to

give up related solutions •  … but conditions have changed

Tools, runtimes, technologies evolve a lot !

46

ORGANIZATIONAL FACTORS Architectural decisions are deeply influenced by the organization goals and strategy

•  Use of existing expertise and targeted expertise •  Existing internal methods •  Needs regarding reuse (to amort ize past

investments) •  Partnerships

The architect must have a deep knowledge of the development team and technologies

47

OUTLINE Definition

An important activity

A difficult activity

Representation

Conclusion

48

APPLICATION TO SOFTWARE Several views also coexist in software programs (Parnas, 74)

•  Organization, control flow, data flow •  Different programming tools are provided to express

these structures •  Type definition, loop operators, …

This has to be applied to software architecture

•  As for any software structure

49

SOFTWARE VIEWS - DEFINITION A view provides a focused perspective on a software

•  It deals with a specific aspect •  It is a model

A view defines

•  Software artifacts •  Relationships between these artifacts •  Constraints and properties •  A formalism and a vocabulary

50

Concernedwiththetargetaspect

USUAL VIEWS A number of different views can be described

•  There is no consensus – depends on target domains

Most commonly used

•  Module views •  Code structuration

•  C&C / Structural views •  How the software is structured into components

•  Dynamic/Behavior views •  What are the interactions between components at

runtime •  Allocation views

•  Where the components are executed

51

SYNTHESIS

52

Architecture = high-level structure

Representation = a set of views

COMPONENT & CONNECTOR VIEW It defines the structure of the architecture

•  Decomposition into functional elements

All components and connectors are described

•  Connections are potential •  Connectors can be complex

53

Component 1 port1

Component 2 port2

connector

sender receiver

C&C What C&C views are for

•  Showing how the system works

•  Showing where are the data

•  Guiding development by specifying the structure and the behavior of runtime elements

•  Helping architects and others to reason about runtime system quality attributes, such as performance, reliability and availability

54

C&C Elements

•  Components: principal processing unit and data stored. •  Connectors: pathways of interaction between

components Relations

•  Attachment: component’s ports are associated with connector roles to yield a graph of components

•  Interface delegation: component’s ports may be associated with one or more ports of a composite

Constraints

•  Components are attached to connectors •  Connectors are attached to components •  Attachments can be made only between two

compatible ports

55

COMPONENTS-DEFINITION Components

•  Components are the principal computational elements and data stores that execute in a system.

•  Components have interfaces called ports. •  Properties (performance, persistence, robustness, …) •  Constraints

Ports

•  A port is an interface of a component. A port defines a point of interaction of a component with its environment.

56

CONNECTOR-DEFINITION Connector

•  A connector is a runtime pathway of interaction between two or more components.

•  Connectors endpoints are component ports. •  Provided service / Required Service •  Constraints

•  Pre/Post-conditions •  Ordering, Orchestration

57

LOGICAL VIEW: INTERACTIONS Role

•  A role is an interface of a connector. A role defines a point of interaction of a connector and indicates how components may use a connector in interactions.

Type

•  Communication: Data-Flow •  Coordination: Control Flow •  Mediation: Data Transformation, monitoring, non-

functional operations Communication modes

•  Procedure Call: CR, RPC, C/S… •  Event-based: broadcast, Publish/Subscribe, ...

58

TYPESOFCONNECTORS

Data-flow

Batch sequential

Pipe and filter

Pipeline Unix Pipe and Filter

Call-Return

Client Server

Multi-tier client server

Peer to peer

Service-orientation RestFul

Event-based

Publish-subscribe

Point to point

messaging

Repository

Shared data

59

C&C VIEW: FORMALISM

60

component port1

port2

Component 1 port1

Component 2 port2

Client/server

sender receiver

Port

Connector

Role

Type

C&C VIEW: UML FORMALISM

61

Port

Connector

Role

Type

C&C VIEW: INTERESTS Provides answers to the following questions

•  What are the main computing elements? •  What are the main data sources? •  What are the main control flows? •  What are the critical paths and the performance

criteria? •  What are the possible bottlenecks? •  What are the needs in terms of computing

platforms?

•  What are the levels of coupling and cohesion?

62

LOGICAL VIEW: USAGE EXAMPLE

63

C1

C2

C4

C3 C5

Bottlenecks, Not used ports

OUTLINE Definition

An important activity

A difficult activity

Representation

Conclusion

64

MAJOR POINTS

Software Architecture is a model •  Module •  C&C •  Allocation

65

MAJOR POINTS

Decomposition of a system into components and connectors

•  Hard to remain in sync w i th developments

•  Hard to recover •  Hard to change once defined

66

SOFTWARE ARCHITECT

The architect ʼs role is to define architectures and to make them resilient

•  Project and organization level

A hard job •  High technical skills •  Ability to abstract problems out •  Good knowledge of SE principles •  High communication skills

67

ARCHITECTURE IMPORTANCE

Today recognized as a major step in software production

•  This is reinforced by outsourcing

Creation of the software architect position •  In many companies since 2000ʼs

Bill Gates was Microsoft chief architect!

68

PROBLEMS •  A recent, immature domain

•  No standard representation •  No standard process •  No evaluation tools •  Many different types of architectures: functional,

technique, etc.

•  Many companies are struggling to define/install guiding processes

•  Ad-hoc solutions today

69

REFERENCES •  Software architecture in practice - second edition

Len Bass, Paul Clements, Rick Kazman Addison Wesley, 2003

•  Pattern-oriented software architecture Buschmann, Meunier, Rohnert, Sommerlad, Stal Wiley, 1996

•  Applied software architecture Hofmeister, Nord, Soni Addison Wesley, 2000

•  Design and use of software architectures Jan Bosch Addison Wesley, 2000

70