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
