21/05/2012

Design Patterns - Introduction

By V Vn Hi Faculty of Information Technologies

Session objectives

Software Architecture introduction

An introduction to design patterns

Introduction to Unified Modeling

Language

21/05/2012

An introduction to Software Architecture

Why Software Architecture?

Architecting a dog house

Can be built by one person Requires Minimal modeling Simple process Simple tools
Architecting a house

Built most efficiently and timely by a team Requires Modeling Well-defined process Power tools
4

21/05/2012

Architecting a high rise

Differences
o

Scale

o
o o o o

Process
Cost Schedule Skills and development teams Materials and technologies

o
o

Stakeholders
Risks

Whats Software Architecture?

Formal Definition by IEEE 1471-2000:

Software architecture is the fundamental organization of a system, embodied in its components, their relationships to each other and the environment, and the principles governing its design and evolution.

21/05/2012

Architecture defined
Another Go

Software architecture encompasses the set of significant decisions about the organization of a software system
o

Selection of the structural elements and their interfaces by

which a system is composed

o
o

Behavior as specified in collaborations among those elements

Composi tion of these struc tural and behavioral elements into larger subsystems

Architectural style that guides this organization

Architecture defined
Few More

Perry and Wolf, 1992

o

A set of architectural (or design) elements that have a particular form

A software system architecture comprises

Boehm et al., 1995

o

A collection of software and system components, connections, and constraints A collection of system stakeholders' need statements A rationale which de monstrate s that the co mponents, connections, and constraints define a sy ste m that, if i mp le mented, would sa tisfy the co llection o f sy ste m stakeholders' need statements

Clements et al., 1997

o

The software architecture of a program or computing system is the structure

or structures of the system, which comprise software components, the externally visible properties of those components, and the rela tionships among them.
8

21/05/2012

Common elements 1/2

Architecture defines major components

Architecture defines component relationships (structures) and

interactions Architecture omits content information about components that

does not pertain to their interactions

Behavior of components is a part of architecture in so far as it can be discerned from the point of view of another component

Common elements 2/2

Every system has an architecture (even a system composed of one component) Architecture defines the rationale behind the components and

the structure

Architecture definitions do not define what a component is Arc hi tec ture is not a single struc ture -- no single struc ture is the

architecture

21/05/2012

Architecture vs. Design

Architecture: where non-functional decisions are cast, and functional

requirements are partitioned Design: where functional requirements are accomplished

non-functional requirements (ilities) functional requirements (dom ains)

architecture

design

Important : this is a general guideline sometimes the borders are blurred

11

System Quality Attribute

Performance

Availability
Usability

End Users v iew

Security

Maintainability Portability Reusability Testability

Dev elopers view

Time To Market Cost and Benefits Projected life time Targeted Market Integration with Legacy System Roll back Schedule

Business Com m unity v iew

A list of quality attributes exists in ISO/IEC 9126 -2001 Information Technology Software Product Quality

21/05/2012

Software Architecture types

Business Architecture

Concerned with the business model as it relates to an automated solution.

E-business is a good candidate

Structural part of requirements analysis. Domain Specific

13

Software Architecture types

Technical Architecture

Specific to technology and the use of this technology to structure the technical points (Tec hnology Mapping) of an

architecture
o o o

.NET JavaEE Hardware architects

14

21/05/2012

Software Architecture types

Solutions Architecture

Specific to a particular business area (or projec t) but still reliant on being a technical focal point for communica tions

between

the

domain

archi tect,

business

interests

and

development.

15

Software Architecture types

Enterprise Architecture

The organizing logic for a firms core business processes and IT capabilities captured in a set of principles, policies and

technical choices to achieve the business standardiza tion and

integration requirements of the firms operating model.

Concerned

with

cross

projec t/solution

archi tec ture

and

communica tion between different practices in archi tecture.

16

21/05/2012

Software Architecture types

Product Line Architecture

Common Archi tecture for a set of produc ts or systems developed by an organization.

Product Line Initiation:

o

Evolutionary

Product line archi tec ture and components evol ve with the requirements posed by new product line members.
o

Revolutionary

Product line archi tecture and components developed to ma tch requirements of all expec ted produc t-line members

17

Introduction to Architecture Documentation

IEEE 1471 - Recap

Recommended Practice for Architectural Description of Architectural Description of Software-Intensive Systems

o

Define the Relations between

Stakeholders

Concerns Views Viewpoint Models Architectural Description

18

21/05/2012

Introduction to Architecture Documentation

Documentation Conceptual Model

19

An introduction to design patterns

20

10

21/05/2012

Design Patterns intro

History

Pattern s originated a s an archi tec tu ral concept by Christopher Alexander (1977/79). In 1987, Ken t Beck and Ward Cunningham began experimen ting with the idea of applying pa tterns to progra mming and presen ted their results a t the OOPSLA conference that year.

Design pa tterns gained popula rity in compu ter science af ter the book Design Pa tterns: Elemen ts of Reusa ble O bjec t-Orien ted Sof tware was published in 1994 by the so-called "Gang of Four" (Gamma et al.).

In 2009 over 30 con tribu tors colla bora ted with Tho mas Erl on his book,
SOA Design Pattern s.The goal of this book was to esta blish a de facto

catalog of design patterns for SOA and service-orientation.

21

What is a Design Pattern?

A design pattern is a documented best practice or core of a solution
tha t has been applied successfully in multiple environments to solve

a problem that recurs in a specic set of situations.

Architect Christopher Alexander describes a pattern as a

recurring solution to a common problem in a given context and system of forces.
o

The term con tex t refers to the set of con ditions/si tua tions in which a

given pattern is applicable.

o

The term sy stem of forces refers to the set of constraints tha t occur in

the specic context.

22

11

21/05/2012

More about Design Patterns

Design patterns are not theoretical constructs. A design pattern
can be seen as an encapsulation of a reusable solution that has been applied successfully to solve a common design problem.

Though design patterns refer to the best known ways of solving

problems, not all best practices in problem resolution are
considered as patterns. A best practice must satisfy the Rule of Three to be treated as a design pattern.

Design patterns do not provide solutions to every problem found in

real-world software design and development. Design patterns are
about providing elegant, reusable solutions to commonly encountered software development problems in a particular context.
23

Design Patterns versus Frameworks

Design Pat t erns Frameworks
Desi gn patterns are recurring sol uti ons to pr obl ems A fr amew ork i s a gr oup of c omponents that that ari se during the life of a sof tware applicati on in c ooper ate with each other to pr ovide a reusable a par ticular context. ar c hitecture for applications with a given domai n.
Help i mpr ove the quality of the ex tensible, etc. Reduce the development time Patterns are logic al in nature.

The pr imary goal is to: sof twar e i n ter ms of the softw are

b eing reusabl e, maintainable,

Fr amew ork s ar e more physic al in nature, as they ex i st in the form of some software. Patter n descripti ons are usually independent of Bec ause framew ork s exist i n the f or m of some pr ogr ammi ng language or implementation details. sof tw are, they are implementation-specic. Patter ns are mor e generic in natur e and c an b e used Fr amew orks provide domai n-specic functionality. i n al most any kind of application. A desi gn pattern does not exi st in the f or m of a Fr amew ork s are not c omplete applic ati ons on their softw are c omponent on its ow n. It needs to b e own. Complete applicati ons c an b e built by either i mpl emented explicitly each time it is used. i nheriting the c omponents c onst directly. Patter ns pr ovi de a way to do good desi gn and ar e Desi gn patter ns may be used in the desi gn and used to hel p design frameworks. i mpl ementati on of a framew ork . In other w or ds, fr amew ork s typically emb ody sever al design 24 patterns.

12

21/05/2012

Introduction to Unified Modeling Language (UML)

25

UML Introduction

"The Unified Modeling Language (UML) is a language for specifying, visualizing, construc ting, and documenting the

artifacts of sof tware systems, a s well as for business modeling

and other non-software systems". OMG UML Specification

"UML is a graphical nota tion for modeling various aspec ts of

software systems." William H. Mitchell.

26

13

21/05/2012

UML : A quick reference

UML offers 12 diagra ms towards representing an applications requirements analysis and solution design. Structure diagrams Behav ior diagrams Model m anagement diagram s

1. 2. 3. 4.

Class diagrams Object diagrams Component diagrams Deploy ment diagrams

1. 2. 3. 4. 5.

Use Case diagrams 1. Packages Sequence diagrams 2. Subsy stems Activity diagrams 3. Models Collaboration diagrams Statechart diagram

27

UML : Use case diagram

Use Case diagrams show the various acti vi ties the users can perform on the system. (System is somet hing that performs a
function.)

28

14

21/05/2012

UML : Use Case Diagrams

Relationships

Inclusion: enables to reuse one use case's steps inside another use case.

Extension: Allows creating a new use case by adding steps to

existing use cases Generaliza tion: Allows child use cases to inheri t beha vior from

parent use cases

29

UML : Use case diagram

Relationships example 1

Open account
A

Request Catalog
<< ex tend >>
C

<< include>> << include>> << include>>

Supply Customer data

Supply Account type

Supply Initial balance

30

15

21/05/2012

UML : Use case diagram

Relationships example 2

31

UML : Class diagrams

A class diagram describes the types of objects in the system and
the various kinds of static relationships that exist among them.

Essential Elements of a UML Class Diagram:

o

Class

o
o o

Attributes
Operations Relationships
Associ ati ons Generali zati on Dependency Reali zati on

Class Nam e A t tributes Operations

Window
size: Size v isibility: boolean display() h ide()

Constraint Rules and Notes

32

16

21/05/2012

Class Diagram

Access modifiers can also be represented in a class diagram.

o o

The + symbol is used for public modifier The - symbol is used for private modifier

The # symbol is used for protected modifier.

33

Class Diagram

Multiplicity in Relationships

In a class diagram, relationships between objects are shown using connectors.

Connectors have different kinds of ends such as a diamond, an arrow, and others.
The line ends depict the nature of the relationships.
o

0..1:No instances, or one instance.

o
o o

1 : Exactly one instance

0..* or * :Zero or more instances 1..*: At least one instance
34

17

21/05/2012

Class Diagram Association

Association defines the rela tionship between two or more classes in the System. These generally rela tes to the one objec t

having instance or reference of another object inside it.

Association

Directed Association

Reflexive Association
35

Class Diagram

Dependency relationship

Is a rela tionship in which changes to one ob jec t i mpac ts another object.

In UML graphical representa tion, the rela ted objec ts a re joined by

dashed line with the arrow pointing towards the dependent object.

36

18

21/05/2012

Generalization

In generalization rela tionship, one objec t or subtype is based on another object or super type.

Generalization

rela tionships

can

be added

to

reuse

the

attributes, opera tions, and relationships present in the super type with one or more subtypes.

The UML graphical representa tion of generalization is a hollow

triangle shape on the super type end of the line tha t connec ts i t to one or more subtypes. The generalization rela tionship is also

known as inheritance or is a relationship

37

Class Diagram Generalization

38

19

21/05/2012

Class Diagram

Realization

Realization rela tionship is between two objec ts, in which one object realized the behavior that the other object specifies.

Its usually implemented in an application as an interface and its

behavior is realized by any class that implements that interface. In UML graphical representa tion, the rela ted objec ts are joined

by dashed line with an unfilled arrowhead towards the main

object. An interface is depic ted in the sa me way as a class but with the word, <<interface>> is written on top of the interface

name.
39

Class Diagram

Realization

40

20

21/05/2012

Class Diagram

Aggregation

Is a rela tionship in which one objec t ac ts as a container of the other object or objects.

There are essentially two kinds of aggregation relationships:

o

Basic: there is a rela tionship between objec ts but the lifecycle of both the superset and subset i s not dependent on

one another.
o

Composition: both the superset objec t and subset objec t do not have independent existence. They cannot exist without one

another and the subset can be related to only one instance of

the superset.
41

Class Diagram

Aggregation

Basic Aggregation relationship

Composition Aggregation relationship

42

21

21/05/2012

Class Diagram

Constraint Rules and Notes

Constraints and notes annotate among other things

associations, attributes, operations and classes.

Constraints are semantic restrictions noted as Boolean

expressions.
o

UML offers many pre-defined constraints.

Customer
id: long { v alue > 0 }

* { total < $50 }

Order

m ay be canceled

Constraint
UML Class Diagrams

Note
43

UML Packages

A package is a general purpose grouping mechanism.

o

Can be used to group any UML element (e.g. use case, actors, classes, components and other packages.

Commonly used for specifying the logical distribution of classes.

A package does not necessarily translate

physical sub-system.
Name

into a

44

22

21/05/2012

Packages and Class Diagrams

Add package information to class diagrams b b.a

b.a.F

a
a.A

b.b
b.b.E b.b.D a.B

b.a.G a.C

45

UML
Exercises

46

23

21/05/2012

UML: Sequence Diagrams

Sequence diagra ms are used to depic t interac tions a mong collaborating objects in terms of messages exchanged over ti me

for a specic result.

In addition, a sequence diagra m may also be used to model business ows.

47

Sequence Diagrams
Terminologies

An object is represented with the na me of the class in a rectangle preceded by a colon.

An interaction between two objects is performed as a message

sent from one object to another . Return values is an optionally indicated using a dashed arrow

with a label indicating the return value.

Self calls is a message call from an object onto itself.

48

24

21/05/2012

Sequence Diagrams
Example 1
X-Axis (objects)

m em ber: LibraryMember
borrow(book)

book:Book

:Book Copy
Object

ok = m ayBorrow() m essage [ok] borrow(member) condition

Life Line

Sequence Diagrams
Example 2

Client
print(doc,client) enqueue(job)

Y-Axis (time)

setTaken(member)

Activation box

49

Printing A Docum ent

Active object

:PrintServer

:Queue

:Printer Proxy

[job] done(status)

Repeated forev er with 1 m in interludes

job=dequeue() [job]print(job.doc) status

50

25

21/05/2012

Other Diagrams

See more at http://www.omg.org/spec/.

51

Summary

Software Architecture introduction

An introduction to design patterns

Introduction to Unified Modeling Language

52

26