Design Pattern using Class

Diagram

©2011
 Big questions
• What is a design pattern?

• What is the advantage of knowing/using

design patterns?

• Why design pattern?

• MVC design pattern and its example

©2011
 Design Pattern

• A Design Pattern systematically names, explains, and

implements an important recurring design.
• These define well-engineered design solutions that
practitioners can apply when crafting their applications.

Design pattern is a solution to a common software problem

in a context

– describes a recurring software structure

– is abstract from programming language
– identifies classes and their roles in the solution to a
problem
– patterns are not code or designs; must be
instantiated/applied
©2011
 Design Pattern advantages
• patterns are a common design vocabulary
– allows engineers to abstract a problem and talk about
that abstraction in isolation from its implementation
– represent a culture; domain-specific patterns increase
design speed

• patterns capture design expertise and allow that expertise

to be communicated
– promotes design reuse and avoid mistakes

• improve documentation (less is needed) and

understandability (patterns are described well once)

©2011
 Why Design Pattern

• Good designers do not solve every problem from first

principles. They reuse solutions.

• Practitioners do not do a good job of recording experience

in software design for others to use. Patterns help solve
this problem.

©2011
 Parts of MVC
• A Model View Controller pattern is made up of the following
three parts:

• Model
• View
• Controller

©2011
Parts of MVC

©2011
Parts of MVC

©2011
©2011
©2011
©2011
©2011
©2011
©2011
©2011
©2011
©2011
©2011
©2011
©2011
©2011
©2011
©2011
©2011
©2011
©2011
©2011
 Entity, Boundary and Control
Objects
• Entity Objects: Representation of persistent information
hold by the system
• Boundary Objects: Representation of interactions
between
user and system
(external interfaces)
• Control Objects: Representation for the realization of use
cases (system's behavior, between boundary and entity
objects)

©2011
 Entity, Boundary and Control
Objects

• All the following illustrations of the individual analysis

activities are based on the ReportEmergency UseCase
from requirement elicitation.

©2011
Report Emergency Use Case
Detail

©2011
Identify Entity Object

©2011
Boundary and Entity Objects

©2011
Boundary, Control and Entity
Objects

©2011
Refined Boundary, Controls
and Entity Objects

©2011
Identifying Associations

©2011
Class Diagram with
Association

©2011
Identifying in general

©2011
Thank You

©2011