Towards Design Patterns

Software Engineering Course

Requirements
Specification Elicitation
Analysis Validation Management

Architectural
Development design
System Design Detailed design Implementation

Integration Acceptance
Validation Unit testing
(system) testing testing

Changes Changes Changes

Design Patterns 2
Rappel sur la modélisation
• Définir : Modèle, Modélisation
• A quoi sert la modélisation?
• Expression des modèles (notation et langage)
• Approche objet et mécanismes de réutilisation

Design Patterns 3
What is a Model?
A model is a simplification of reality.
A model may provide
• blueprints of a system
• Organization of the system
• Dynamic of the system
• “A successful software organization is one that consistently deploys
quality software that meets the needs of its users. An organization
that can develop such software in a timely and predictable fashion,
with an efficient and effective use of resources, both human and
material, is one that has sustainable business.”
Design Patterns 4
Why We Model
• Model is built to
• Communicate the desired structure and behavior of the system
• Visualize and control the system’s architecture
• Better understand the system that being built
• Manage risk
• Expose opportunities for simplification and reuse
• We build models so that we can see and better understand the
system we are developing.

Design Patterns 5
Importance and Principles of Modeling
• Models help us
• to visualize a system as it is or as we want it to be.
• to specify the structure or behavior of a system.
• in providing a template that guides us in constructing a system.
• in providing documenting the decisions we have made.
• The choice of what models to create has a major influence on how a
problem is approached and how a solution is shaped.
• Every model may be expressed at different levels of precision.
• The best models are connected to reality.
• No single model is sufficient. Every nontrivial system is best
approached through a small set of nearly independent models.

Design Patterns 6
Objected-Oriented Modeling
• Two most common ways in modeling software systems are
• Algorithmic
• Procedures or functions
• A system is made up with Data and Functions (with operate on data)
• 2 kinds of models: data model (determines the data structures) and processing model
(determine the
• Object oriented
• Objects or classes
• System = set of classes with interact together
• UML is the standard in this category

Design Patterns 7
System modeling
• System modeling is the process of developing abstract models of a
system, with each model presenting a different views or perspectives
of that system.
• System modeling has now come to mean representing a system using
some kind of graphical notation, which is now almost always based on
notations in the Unified Modeling Language (UML).
• System modelling helps the analyst to understand the functionality of
the system and models are used to communicate with customers.

Design Patterns 8
Existing and planned system models
• Models of the existing system are used during requirements
engineering. They help clarify what the existing system does and can
be used as a basis for discussing its strengths and weaknesses. These
then lead to requirements for the new system.
• Models of the new system are used during requirements engineering
to help explain the proposed requirements to other system
stakeholders. Engineers use these models to discuss design proposals
and to document the system for implementation.
• In a model-driven engineering process, it is possible to generate a
complete or partial system implementation from the system model.

Design Patterns 9
System perspectives
• An external perspective, where you model the context or
environment of the system.
• An interaction perspective, where you model the interactions
between a system and its environment, or between the components
of a system.
• A structural perspective, where you model the organization of a
system or the structure of the data that is processed by the system.
• A behavioral perspective, where you model the dynamic behavior of
the system and how it responds to events.

Design Patterns 10
UML diagram types
• Activity diagrams, which show the activities involved in a process or in
data processing .
• Use case diagrams, which show the interactions between a system
and its environment.
• Sequence diagrams, which show interactions between actors and the
system and between system components.
• Class diagrams, which show the object classes in the system and the
associations between these classes.
• State diagrams, which show how the system reacts to internal and
external events.

Design Patterns 11
Use of graphical models
• As a means of facilitating discussion about an existing or proposed
system
• Incomplete and incorrect models are OK as their role is to support discussion.
• As a way of documenting an existing system
• Models should be an accurate representation of the system but need not be
complete.
• As a detailed system description that can be used to generate a
system implementation
• Models have to be both correct and complete.

Design Patterns 12
Motivation
• OOD methods emphasize design notations
• Fine for specification & documentation
• But OOD is more than just drawing diagrams
• Good draftsmen are not necessarily good architects!
• Good OO designers rely on lots of experience
• At least as important as syntax
• Most powerful reuse combines design & code reuse
• Patterns: Match problem to design experience
• Frameworks: Reify patterns within a domain context

Design Patterns 13