Software Engineering

Summary
Software Engineering 1 Introduction

Introduction with UML Small reminder
What is the purpose?
Unified Modeling Language
Hakim Belhaouari
hakim.belhaouari@sic.univ-poitiers.fr 2 Modeling design aspect
1 University of Poitiers
Object diagram
Computer Science Department Class diagram
2 University Science and Technology of Ha Noi
USTH
3 Modeling dynamic aspect
Use case diagram
November 11, 2013 Sequence diagram
Communication diagram
Hakim Belhaouari hakim.belhaouari@sic.univ-poitiers.fr

Introduction
(UP-USTH)
with UML November 11, 2013 1 / 66 Hakim Belhaouari hakim.belhaouari@sic.univ-poitiers.fr
Introduction
(UP-USTH)
with UML November 11, 2013 2 / 66
Table of Contents Table of Contents
1 Introduction 1 Introduction
Small reminder Small reminder
What is the purpose? What is the purpose?
Unified Modeling Language Unified Modeling Language
2 Modeling design aspect 2 Modeling design aspect

Object diagram Object diagram
Class diagram Class diagram
3 Modeling dynamic aspect 3 Modeling dynamic aspect

Use case diagram Use case diagram
Sequence diagram Sequence diagram
Communication diagram Communication diagram

Introduction
(UP-USTH)
Introduction
(UP-USTH)
Small reminder on OOP and Java Table of Contents
Object = State + Behavior 1 Introduction

OOP is reduced to the 3 pillars: Small reminder
1 Encapsulation: visibility of attribute, functions, constructors, . . . What is the purpose?
2 Inheritance: interfaces, classes, anonymous classes, root of all Unified Modeling Language
classes, keyword super, . . .
2 Modeling design aspect
3 Polymorphism: substitution, references, early/late-binding,
Object diagram
generics, . . .
Class diagram
Thus:
Gives a pretty good representation of our world thus facilitates 3 Modeling dynamic aspect
the design of the organization of our problem. Use case diagram
Increases the reuse of classes (enough well modeled). Sequence diagram
Does not avoid completly the coupling problem (not goal of this Communication diagram
course but just for your general knowledge).
Paradigm is mature! many IDE and many well accepted solution
(design
Hakim Belhaouari pattern) Introduction
hakim.belhaouari@sic.univ-poitiers.fr (UP-USTH)
Introduction
(UP-USTH)
Why do we use model? The tree swing cartoon1
Your student skills: programming-in-the-small

individual programming on small problems
Algorithms, programming languages, data
(possibly) some methodology: downward analysis
Working in a software company: programming-in-the-large
Work in team on long and complex projects
Requirements expression is usually not precise
Relation with the user (client): professional jargon, not related
to computer science.
Organization, planning and risk management
1
http://www.paragoninnovations.com/guide.shtml
Introduction
(UP-USTH)
Introduction
(UP-USTH)
Examples of failure When software fails. . .
Mariner spacecraft to Venus (in the sixties): error that can be
detected at compile time in a Fortran program (comma where a
point was needed).
In 1971, in France: 72 weather balloon were destroyed because Numerous problem can be cited
of a software bug
More important to understand why?:
In 1981, American space shuttle: 2 days late on launching,
Software are complex manufactured products
launch was done without resolving the problem. Errors can be easily introduced
In 1990, AT& T subscribers on the East coast (USA) could not It is hard to obtain precise specifications
phone outside this area: chain reaction due to a version change It is hard to test the software against specifications
of the software
In 1990, train ticket system fails down in France: the national
company has reused a software from an airline company.
In 2000, Ariane 5 rocket destroyed: reuses software from Ariane
4, type verification problem.
Introduction
(UP-USTH)
Introduction
(UP-USTH)
Overview Development practice
Avoid problems! Fortunately, some possible remedies exist:

Software engineering tools
Programming environments
Develop theoretical foundations
Improve the quality control

Introduction
(UP-USTH)
Introduction
(UP-USTH)
What are our goals? Software development
Understand the importance of activities related to specification,

analysis and design.
Overview:
With respect to programming activity
Requirements expression: help to develop the right software
Learn to abstract (simplify) concepts: modelling!
Requirements analysis: determine software functionalities
To do this with a unified language between teams (UML):
Design: what must be done?
Support for understanding the problems
Support for technical documentation Programming: translates from the detailed design to a set of
Take care of the code architecture and not only of the code programs
performances: Validation: does it answer correctly to the user requirements?
Modularity Verification: does it follow correctly the specification?
Reusability
Scalability
⇒ Design is before programming!!!
Introduction
(UP-USTH)
Introduction
(UP-USTH)
Development process Development models: the V model
Development:
The software is designed more precisely at each step
Iteration: after validation and verification the design may be
re-evaluated
Invisibility: documentation is crucial
Several different models:
Waterfall, spiral, V
corresponds to several development types
Goal: obtain a controllable development process and
reproducible.
But. . . it definitively depends on the team willingness

Introduction
(UP-USTH)
Introduction
(UP-USTH)
Development models: the V model Table of Contents
1 Introduction
Small reminder
Arrows semantic: What is the purpose?
The arrow (ց or ր) indicates that we go from one step to the Unified Modeling Language
other step
The sub-arrow −→ (from left to right) indicates that when the Object diagram
design is done the corresponding tests can be designed Class diagram
The sub-arrow ←− (from right to left) indicates that tests are
passed to check against the design. 3 Modeling dynamic aspect
Use case diagram
Sequence diagram

Introduction
(UP-USTH)
Introduction
(UP-USTH)
Unified Modeling language History of UML

Begin to be mature
Object Management Group (OMG)
Created in 1989 in order to formalize and promote the OOP
(www.omg.org).
international open membership (regroup many company,
academic institutions and some government agencies).
Definition
It is a abstract graphic language dedicated to the specification,
construction and documentation of object-oriented software-intensive
systems.

Introduction
(UP-USTH)
Introduction
(UP-USTH)
Studies diagrams Studies diagrams
In brief, UML contains 14 kinds of diagrams.
Requirements analysis:
Use case diagram Design (architectural and detailed):
Specification: Class diagram
Sequence diagram Statechart diagram
Introduction
(UP-USTH)
Introduction
(UP-USTH)
Common notation Table of Contents

Stereotype
1 Introduction
Define a specific semantic for an element
Small reminder
Notation: ≪stereoName≫, {stereoName} or an icon What is the purpose?
Many predefined: ≪interface≫, ≪actor≫, ≪use≫,. . . Unified Modeling Language
Comment 2 Modeling design aspect

Gives informations for Humans Object diagram
MyClass Class diagram
Notation: I am a note
Use case diagram
Sequence diagram
Constraint
Logic constraint can be added, use the Object Constraint Language
(OCL). Larger than Design by contract
Introduction
(UP-USTH)
Introduction
(UP-USTH)
What that means? Table of Contents
1 Introduction
Small reminder
We consider here the technical structure of the program. Then, we Unified Modeling Language
do not take into consideration the time or any functional aspcect.
(usually students prefer this ones) 2 Modeling design aspect
1 Object diagram Object diagram
Class diagram
2 Class diagram
Use case diagram
Sequence diagram

Introduction
(UP-USTH)
Introduction
(UP-USTH)
Object diagram Exercice
Definition
Represent objects and their link at a time t. It is useful for
documenting test case and/or use of your architecture. Peter, Alice and Carl are students in UP
Similar to a graph where: John and Cameron are teachers in UP
Node corresponds to an instance of a class John teaches the C++ and CUDA
Edge represents link between nodes (usually corresponds to
Cameron techs the Java and math
attributes)
Peter and Alice follow the C++, Java and math
Carl follow the Java and math.
Not supported by all tools
Often drawn by hand

Introduction
(UP-USTH)
Introduction
(UP-USTH)
Table of Contents Class diagram
1 Introduction
Small reminder
What is the purpose? Definition
Unified Modeling Language It is just an abstraction of the previous map:
2 Modeling design aspect Node represents a class
Object diagram Arc/Edge represent relationship between nodes. There is two
Class diagram kinds of relation:
associations lead attributes
3 Modeling dynamic aspect inheritance influence the form of the child
Use case diagram
Sequence diagram

Introduction
(UP-USTH)
Introduction
(UP-USTH)
Representation of a class Format for the attributes

Main format:
Always with a Rectangle [Vis]Name[Card][′ :′ Type][′ =′ Value][Prop]
Inside it, three parts:
Name (required): start with a upper case Vis: (+ : public), (− : private), (# : protected) or ∼: package
Attributes: see next for format Name of the attribute (lower cases in Java)
Card cardinality (ex.: [10] or [1..10])
Operations: set of others methods (cf. format)
Type type of the attribute
Remarks: Value the default value
Full detailed: Class Partial detailed: Simply view: safe Prop extra properties on it (constant, . . . )
public information place for big Statics attributes have underline
architecture Examples:
+data : int
−coord[3] : double
+pi : double = 3.14159 {const}
Introduction
(UP-USTH)
Introduction
(UP-USTH)
Format for the operation Association relationship
Main format: A x y B
[Vis]Name ′ (′ [[Dir ]NameArg : TypeArg ]∗′ )′ [′ :′ Type] * 1
Vis: (+ : public), (− : private), (# : protected) or ∼: package The link can be read ”has a”. Sometimes another verb is more
Name of the method (lower cases in Java) appropriate, thus we add relation name in the middle.
Dir direction of the attribute: Interpretation:
in read-only
out write only The class A has an attribute called y of type B
inout read and write The class B has an attribute called x which is a collection of
NameArg name of the parameter type A.
TypeArg type of the parameter Multiplicity: 1, *, 1..*,0..1, . . .
Type return type of the method
Example:
Abstracts or virtuals methods write in italic
Statics methods use underline Company employer employee Person
Operations can be overloaded (same name but distinguish 0..1 1..*
parameters)
Introduction
(UP-USTH)
Introduction
(UP-USTH)
Navigable association Association class
Definition On complex association you want to add extra informations, which

the ability for objects of a Class at one end of an Association to are not in end point classes ⇒ a association class.
retrieve Objects from the other end. By default, it navigates in both Equivalent:
direction. Notations:
A C B
m 1 1 n
A B a c + extra : int c b
a b
Notation: m n
A b B
More easy to understand and to design.
1 C
+ extra : int
Here:
The class A has one reference on an object B
The class B has NO reference on A. ⇒ We can generalize that for N-ary associations

Introduction
(UP-USTH)
Introduction
(UP-USTH)
N-ary associations Specific association: Aggregation and Composition
Aggregation
Special type of association used to represent a stronger relationship
Equivalent: between two classes than a regular association; typically read as
Notations:
C ”owns a”.
C
*
Example:
*
A B
A a 0..1 B Polygon owner pts Point
a 1
* * 0..1
bla bla 1 D 1 * 3..n
A Point may live without a polygon

A Polygon need at least 3 points
Polygon is a large thing constituted of smaller things (Point).
Introduction
(UP-USTH)
Introduction
(UP-USTH)
Specific association: Aggregation and Composition Generalization and Realization

Composition Definition
A specific type of relationship describing how one Object is composed A relationship between a class to a more general class asserting that
of another Object; a form of Aggregation where the child object is the general classifer contains common features among both them.
destroyed if the parent object is destroyed. The use of generalization is often logically restricted to cases where
the specific classifier is a ”kind-of” or ”sort-of” the general classifier.
Example: ⇒ In common OOP, it corresponds to the inheritance!
Example: Animal
Book owner ch Chapter pr Paragraph
1 1..* 1..*
Mammal Insect
The lifecycle of an object Paragraph depends of its own chapter,

which it depends itself of the own book. Cat Dog
An object belongs to at most one owner

Introduction
(UP-USTH)
Introduction
(UP-USTH)
Generalization and Realization Constraint on inheritance
We can express constraint on inheritance as stereotype on the
Interface
generalization arc.
Class without attribute and only abstracts operations:
≪disjoint≫ or ≪overlapping≫
Cannot be instantiated
≪complete≫ or ≪incomplete≫
Must be realized (implemented) by a concrete class
≪leaf≫ or ≪root≫
Can inherit others interfaces
Example:
⇒ Caution between abstract and concrete entities!
Examples:
A complete, disjoint indicating that
a Person may be subtyped as either
a Female or Male.
A person can also be an Employee or
not (unemployed).

Introduction
(UP-USTH)
Introduction
(UP-USTH)
Dependency Remarks
A last kind of arrow of UML for ”others” cases, where you can add
(or not) a stereotype.
Examples:
Use interface as parameter of an Inheritance from a generic class: All classes must be reached with navigable arrow
operation: More NEVER make lonely entity
Don’t forget multiplicity
Avoid create new stereotype, give priority to predefined ones
Avoid redundancy in associations.

Introduction
(UP-USTH)
Introduction
(UP-USTH)
Exercice Table of Contents
1 Introduction
Implements a Car composed of: Small reminder
four wheels What is the purpose?
one engine Unified Modeling Language
one chassis 2 Modeling design aspect
four braking system (brake disc front and brake drum at back) Object diagram
one fuel tank Class diagram
one steering wheel 3 Modeling dynamic aspect
lights Use case diagram
... Sequence diagram

Introduction
(UP-USTH)
Introduction
(UP-USTH)
Modeling dynamic aspect Table of Contents

Describe the behavior of the system.
1 Introduction
Consider the system as blackbox Small reminder
Who interact with the system and why? Unified Modeling Language
⇒ use case diagram (functionality part).
How does it interact with the system? 2 Modeling design aspect
⇒ system sequence diagram. Object diagram
Class diagram
Consider the system as white box 3 Modeling dynamic aspect
How do objects of the system interact between them? Use case diagram
⇒ sequence diagram and/or communication diagram. Sequence diagram
Evolution of object state with a state chart.
Introduction
(UP-USTH)
Introduction
(UP-USTH)
Use case diagram How do you identify the use cases
Definition Define perimeter:
Allows to client to describe his requirements: Determine what is in the project
Help to formalize the contract between the client and the Determine what are the options
provider Take decision with the client
First step of all development model Identify all actors (those who use the system and those who
provide services for the system)
What is a use case Among them identify the mains actors (those who must achieve
Describe how an actor use the system: a goal).
Actor: external entity to the system. An actor can be a person Deduce the use cases correspond to these objectives.
or a software entity (data base, agent, printer, . . . ).
A use case is composed of many scenarios:
Usually we call the main scenario the one who describe the Use case diagram
default behavior. The use case diagram is just a graphic summary.
others scenarios are called variant of the default scenario.
we represent each scenario with system sequence diagram.
Introduction
(UP-USTH)
Introduction
(UP-USTH)
Example of use case diagram Use case diagram
Actor can use generalization arrow

No connector in interaction between
actor and use case
Between uses cases, 2 kinds of
dependency:
1 inclusion
2 extension (avoid use it, semantic
not stable)

Introduction
(UP-USTH)
Introduction
(UP-USTH)
Documentation of use case Table of Contents
1 Introduction
Many UML tools offer the possibility to add some documentations. Small reminder
You must adopt intuitively this feature. What is the purpose?
Short description Unified Modeling Language
Indicate direct interacting actors
Precondition and postcondition Object diagram
At least one scenario: Class diagram
Precise the trigger event
Main stream 3 Modeling dynamic aspect
Variants workflow Use case diagram
Exceptions Sequence diagram

Introduction
(UP-USTH)
Introduction
(UP-USTH)
Sequence diagram Example
Difference
In the system version, we allow some sentence (no formal
version). We see only the system and actors
In the object version, we must be more precise and use only
existent method.
Give interaction along the time!!

Life lines represent the elapsed time
Horizontal arrow for interaction (messages)
Interaction frame divided into fragments, which is subject to an
algorithmic Operator such as iteration, parallelism or optionality.

Introduction
(UP-USTH)
Introduction
(UP-USTH)
Life line Interaction frame
Always vertical line (dashed)

loop: repeat while the guard is true
No preference on order. But mains classes should be on the left
alt: at least two alternative, and the unique guard evaluates to
We can create new instance of an object true is executed (condition mutually exclusive!)
An object can die ⇒ its life line end with a cross. (Not all tools opt: execute the frame only if the guard is true.
supported it, cause of garbage collector).
sd: allow naming a sequence diagram.
A box around the life line indicates an active object (usually only
ref: references a named diagram (declared with sd).
one object is active at same time).
Do you find my BIG error in my previous example?

Introduction
(UP-USTH)
Introduction
(UP-USTH)
Table of Contents Communication diagram
1 Introduction
Small reminder
What is the purpose? It is just an alternative of sequence diagram! It represents
Unified Modeling Language message interaction between object.
It focuses on the localization of object.
Object diagram The exchanged message are numbered and then ordered.
Class diagram Sometimes we can make sub-numbering in order to regroup
common feature
3 Modeling dynamic aspect There is no fragment mechanism.
Use case diagram
Sequence diagram

Introduction
(UP-USTH)
Introduction
(UP-USTH)
Table of Contents Project (loosely definition)
I am the client:
I want a game based on letter and more precisely on a
real dictionary. I want optimized access to the
dictionary as binary tree search. I want only the
functional part, thus i don’t ask explicitly a GUI
4 Project: LetterGame (console can be enough).
I want necessarily at least the following games2
The hungman
The longest word
The mystery word
The boogle
2
You can add your owns games
Introduction
(UP-USTH)
Introduction
(UP-USTH)
Project: games’ rules I Project: games’ rules II
Hungman The longest word

The computer chooses a word (length ≤ 5) and the human tries to The computer chooses at least three letters (the beginning of a word)
guess it by suggesting letters. and the human tries to complete these letters with the longest word.
If the computer can find a longer one, the human loses. Otherwise
If the letter occurs all positions are revealed
the human wins.
Otherwise the computer draws one element of the hanged man. Example:
The game stops when: Computer gives long
Human finds all letters of the word The human answers longest
The computer searches a longer one (ex: longitudinal). Then
Computer completes the diagram as follow: the human lose

Introduction
(UP-USTH)
Introduction
(UP-USTH)
Project: games’ rules III Project: games’ rules IV
The mystery word The boogle
This feature is not a real game but the complementary of the The game consists in a grid of letters, in which players attempt to
hangman for crosswords. The player gives a word with hole(s), and find longest words in sequences of adjacent letters. Traditionally, the
the computer must retrieve all compatible words. grid is a square 4x4 but we want let the player decide this parameter
Example: (but we must keep a square).
1 The player ask the word cross???? 1 at beginning the computer creates a new grid
2 The computer searches all possibles words: 2 then the player enters a word
crossover 3 computer checks if the word is correct for this grid (specifically
crossword the adjacency constraint)
crosswise 4 it checks then if the word exists in the dictionary
crosswind
crosstalk
5 it updates score
crossroad 6 when the user cannot find word anymore, the computer searches
... all possibles words that the player misses.
Introduction
(UP-USTH)
Introduction
(UP-USTH)

Software Engineering

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Software Engineering

Uploaded by

Copyright:

Available Formats

Summary

Software Engineering 1 Introduction

Hakim Belhaouari hakim.belhaouari@sic.univ-poitiers.fr

Table of Contents Table of Contents

2 Modeling design aspect 2 Modeling design aspect

3 Modeling dynamic aspect 3 Modeling dynamic aspect

Hakim Belhaouari hakim.belhaouari@sic.univ-poitiers.fr

Object = State + Behavior 1 Introduction

Why do we use model? The tree swing cartoon1

Your student skills: programming-in-the-small

Overview Development practice

Avoid problems! Fortunately, some possible remedies exist:

Hakim Belhaouari hakim.belhaouari@sic.univ-poitiers.fr

Understand the importance of activities related to specification,

Development process Development models: the V model

Hakim Belhaouari hakim.belhaouari@sic.univ-poitiers.fr

Hakim Belhaouari hakim.belhaouari@sic.univ-poitiers.fr

Unified Modeling language History of UML

Hakim Belhaouari hakim.belhaouari@sic.univ-poitiers.fr

Common notation Table of Contents

Comment 2 Modeling design aspect

Hakim Belhaouari hakim.belhaouari@sic.univ-poitiers.fr

Object diagram Exercice

Hakim Belhaouari hakim.belhaouari@sic.univ-poitiers.fr

Hakim Belhaouari hakim.belhaouari@sic.univ-poitiers.fr

Representation of a class Format for the attributes

Navigable association Association class

Definition On complex association you want to add extra informations, which

Hakim Belhaouari hakim.belhaouari@sic.univ-poitiers.fr

A Point may live without a polygon

Specific association: Aggregation and Composition Generalization and Realization

The lifecycle of an object Paragraph depends of its own chapter,

An object belongs to at most one owner

Hakim Belhaouari hakim.belhaouari@sic.univ-poitiers.fr

Hakim Belhaouari hakim.belhaouari@sic.univ-poitiers.fr

Hakim Belhaouari hakim.belhaouari@sic.univ-poitiers.fr

Modeling dynamic aspect Table of Contents

Example of use case diagram Use case diagram

Actor can use generalization arrow

Hakim Belhaouari hakim.belhaouari@sic.univ-poitiers.fr

Hakim Belhaouari hakim.belhaouari@sic.univ-poitiers.fr

Sequence diagram Example

Give interaction along the time!!

Hakim Belhaouari hakim.belhaouari@sic.univ-poitiers.fr

Always vertical line (dashed)

Do you find my BIG error in my previous example?

Hakim Belhaouari hakim.belhaouari@sic.univ-poitiers.fr

Table of Contents Communication diagram

Hakim Belhaouari hakim.belhaouari@sic.univ-poitiers.fr

Project: games’ rules I Project: games’ rules II

Hungman The longest word

Hakim Belhaouari hakim.belhaouari@sic.univ-poitiers.fr

You might also like