Modelling II
1
Objects
• Object – direct relationship with the real
world
• Object
– memory -> data -> Attributes
– processes -> Operations -> Messages
• Object - Organization – Hierarchy
– aggregation
– generalization
2
Object Orientation
• Most famous:
– Booch
– OMT
– Jacobson
3
UML
Birth
• Several methods and techniques
for OO, with many common
aspects but using different
notations
• Difficult to learn, to apply, to
build and to use tools
• Diferences among different
approaches (authors)
There was the
need for a
standard
notation
4
UML
• “Unified Method”
• Grady Booch e Jim Rumbaugh
• First presented at OOPSLA’95
• Rational Software
• Grady Booch, Jim Rumbaugh e Ivar Jacobson
• Rational Rose CASE tool
5
UML
It is a Modelling language not a method !
• A method consists of notation language +
process
• The proposed process is called Objectory
• We can use UML regardless the process we
use
6
UML
Basic Representation:
• Static Model
– ERD evolution
• Internal Dynamic Model
– Data Flow
– State Machines
• External Dynamic Model
– use cases
– Languages for interconecting objects
7
UML - Diagrams
• Use Case Diagrams
• Use Case Diagrams
– Actors and their connections with
the system
• Textual description for the
Use Case
• Static Structure Diagrams
• Class Diagram
– Static Structure for the system
classes
• Object Diagram
– Simplify the class diagram
8
UML - Diagrams
• State Diagram
• State Diagram
– Possible states an object may have
and events that cause state change
– Activity Diagram
– Sequential flow of activities
9
UML - Diagrams
• Interaction Diagrams • Sequence Diagram
– Dynamic collaboration expressed as
messages exchanges among objects triggered
by a function or a sequence in time
• Collaboration Diagram
– Dynamic Collaboration using interaction
among objects (context)
• Implementation Diagrams
•
Component Diagram
– Physical structure of the code in the form of
code components
•
Distribution Diagram
– Hardware and Software Physical
Architecture
10
UML - Diagrams
Requirements
Implementation
Design
States
Sequence
Distribution
Use Cases
Classes
Colaboratio
n
Activity
(work flow, use
cases)
Component
s
Activity
(object behavior,
operation algorithms)
11
Use Case
<<extend>>
Print Receipt
Saleman
Make a Sale
Finance System
12
Use Case
• An Use Case performs a broader aspect
of the product functionality:
– Must produce one or more benefits for the
client or users
– represent:
• User interaction
• User manual auxiliar
• Test cases
Filho, W.P.P em “Engenharia de Software: Fundamentos, Métodos e Padrões”
13
Use Case
• Textual Part
– Use Case << name>>
• pre-condition
• Main flow
• sub-flow<<name>>
• Alternative flow
– pre-condition
– steps
14
Use Cases
Exemplo:
Salesman
Make a sale
Finance System
Stock Manager
Manage stock Manually
Open Cash Register
Manager
Close cash register
15
Use Cases
• Example:
– Use Case << Make a Sale>>
• pre-conditions: Every Product on sale must have been previously
registered in the system. The system must be in the Sale mode
• Main flow
– Salesman start the sale.
– The System generates a code for the sale operation
– For each item to be sold call the sub-flow Register
– Salesman register form of payment
– Salesman finishes sale
– For each item call the sub-flow Print Receipt Line
Filho, W.P.P em “Engenharia de Software: Fundamentos, Métodos e Padrões”16
Use Cases
• Identifying actors;
–
–
–
–
–
•
Who is interested in the requirements
Who will benefit from the product;
Who will give information to the software;
Who will use the software;
Who will remove information from the software.
Identifying use cases:
– What are the actors’ tasks ;
– Which information each actor creates, stores, consults, changes
or removes;
– Which information each use case creates,consults, changes or
removes.
17
Use Cases
• Determining use case flow
–
–
–
–
When and how a use cases starts.
How the use case interacts with the actors.
Standard Sequences (steps) for a use case.
Exceptions Sequences and alternative sequences for a use case.
18
Requirements and Use Cases
• Use cases are requirements. If written
carefully they can be seen as requirements
per se.
• Use cases are not ALL requirements. They
don’t detail external interfaces, data format,
business rules NFR…
19
Class Diagrams
• Describe system objects and their static
relations
• Objects can be part of the real world or
conceptual entities
• Objects are connected to other objects
through relationships (association,
agregation…)
20
Class/Object
• Class:
• Describe a set of objects that share the same
properties (Attributes), behavior (operation),
relationships with other objects and semantics
• Object:
• An Object is an instance or occurrence of a class
21
Class / Object
Properties:
Fuel capicity
Km/galon
availability
km
instanciation
car A
Behavior:
travel
refuel
instanciation
car B
22
Class
name
Car
FuelCapacity: Integer
kmpergalon: Real
availability: Real
Km: Integer
attributes
travel (Kms: Real)
Refuel (quantity: Real)
operations
23
Class
• Attributes
• Examples:
Car
- FuelCapcity: Integer
- Kmpergalon: Real
- availability: Real = 0
- km: Real = 0
rj5015: Car
FuelCapacity: 200
kmpergalon: 40
Availability: 40
km: 1400
Object with Values
...
Class whit attributes
24
• Inheritance
Inheritance
• A subclass inherits attributes, operations, state
diagram and associations from a superclass
• Inherited properties may be reused from the
superclass or redefined in the subclass
• New properties can be added to the subclass
• Can be
• Simple: only one superclass
• Multiple: more than one superclass
25
Inheritance
• Multiple
• A class inherits attributes, operations and association
from multiple classes
• Offers a greater modelling power but leads to a
greater complexity
26
Example
• Multiple
Vehicle
water
land
Car
Amphibian
Boat
27
Inheritance
Employee
YeartoDate: Real
calculatePay() {abstract}
HourBasis
MonthlyBasis
Normalhours: Real
ExtraHours: Real
Normalhours: Real
ExtraHours: Real
calculatePay()
calculatePay()
28
Class Schema
• Example: Company
Agregation
Manager
s
0..N
Company
1
Association
Class
0..N
Project
Employee
Generalization
HourBasis
Employee
schedule
MonthlyBasis
29
Problems with OO
• Disadvantages (Jackson):
– The idea of objects comes from programming
languages and it is not suitable to most of the
individuals in a real worlds.
• When have someone sent a message to the pay
check?
• When have a doctor sent a message to Patient’s
Record?
30
Communication
• It is necessary to have a good
communication between user/stakeholder
and developers
Scenarios
Cenários
Problemdo
Domain
Domínio
problema
Anlysis
Is my understanding (vision)
correct?
Compreender
Understand the
modelo
Models
31
Scenarios
• Easy to understand (written using the problem
language)
• Help to unify criteria
• Stimulate thinking
• Help with training
• Help on tracking/traceability
• Help identifying Non-Functional Requirements
Scenarios are situations
32
Scenarios
Real World
Mundo
Real
Universe of Discourse
Situations
List of Situations
33
Scenarios
• Situation’s Characteristics
– Purpose – A situation deals with the satisfaction of a goal.
– Actors – A situation encompass a certain and identifiable numbers of
actors (people or devices within organizations).
– Resources – Elements that are necessary in one particular situation.
– Time – represent a specific moment.
– Place – Situations take place within a geographical context.
– Constraints – There might be pre-conditions to a situation to happen.
– Independent – need to be understood alone.
– Inter-related – Are related to other situations, although still independent.
– Concrete – Are anchored in reality.
– Alternatives – May lead to alternative actions.
34
Write Scenarios
• Describe situations of the macro system
• Describe situations and their relationship
with the system-to-be
• May be used to describe interaction
between system components
• Use a semi-structured natural language
35
Why Semi-Structured?
• Avoid confusion
• Provide an homogeneous description style
• Works as a reminder of the several aspects
that might be considered within a scenario
• Facilitates to validate it with the
users/stakeholders
36
Scenarios
37
Scenarios
•
•
•
•
•
•
Title: Store clerk checks client’s registration
Goal : Verify if information on client’s registration is correct
Context: Client hand over client’s registration and show a photo id
Actors: Store clerk, Client.
Resources: photo id, client’s registration
Episodes
– Store Clerk verifies id number on client’s registration against the one in
the photo id
– Constraint: id number must comply with standards
– Store Clerk verifies address and phone number calling the number in
client’s registration
38
Identifying Scenarios
• List Situations
– 1. Is there a goal? Is it general (abstract)
enough)? Are there different outputs or is it a
sole case?
– 2. Who is involved? Are there other important
artifacts or important structures?
– 3. Are there any information or physical
elements that are important to this situation?
– 4. Organize identified situations in a list.
39
Fill in the scenarios
• Don’t Guess !!! Stick to what you know and
can validate
• Use the application vocabulary (LEL)
• Using the scenario grammar, fill in the
candidate scenarios (pair working with
clients is always best)
40
• Title
Notation
• [ Sentence | ( [ Actor | Resource ] + Verb +
Predicate ) ]
• Example: Store Clerk checks client’s registration
• Objective
• [ [ Subject ] + Verb + Predicate ]]
• Example:
• Verify if information on client’s registration is
correct
Where:
+ - composition
{x} – zero or more occurrences of x
( ) - group
| - or
[ ] - optional
41
Notation
• Context
– The context is described detailing time, place
and pre-conditions. At least one of them should
appear
“Client hands over client’s registration and show a photo
id “
42
Notation
• Constraints on Context
– local is
Phrase + {Constraint}
– Time is
Phrase + {Constraint}
– Pre-condition is
• [Subject| Actor| Resource] + Verb + Predicate +
{Restriction}
43
Notation
• Resource
– Relevant Physical elements or information that
should be available to the scenario
• [ Substantive + {Constraint} ]
44
Notation
• Episodes
– Main course of action
– Includes variations and alternatives
– Exceptions may happen, enforcing the presence
of obstacles to the goals (objectives)
– Exceptions may be simple actions but can also
be other scenarios
SUB SCENARIO
45
Notation
• Episodes
– There are 3 types of episodes
• Simple – needed to complete the scenario
• Conditionals – depend on essential conditions (If ..
Then)
• Optional – May happen or not depending on the
course of action
46
Style
•
•
•
•
Short phrases
Try to avoid more than one verb per phrase
The goal must be concrete and precise
At least one of the components for the
context must be filled
• Resources must be those directly involved
in the episodes. Avoid trivial things
47
Scenarios
•
•
•
Title: Add Book Exemplar to library collection
Goal: Expand library collection
Context: Number of Book exemplars available on library collection is not
sufficient
• There is enough physical space to store new book exemplar
• Book exemplar can be bought or donated
• Library clerk is always present
• Library Management System is working
•
•
•
•
Actors:
Library clerks
Resources: Book Exemplar, book, library collection, library management
system
Episodes
1
Library clerk gets book exemplar to be added to library collection
•
2.
If book data is not yet filed in the library management system, library
clerk must file book in library collection
•
3
Library clerk reserves a physical space to place book exemplar
according to information retrieved from the library management system,
4.
Library Clerk places book exemplar in the correct physical space
•
48
Organization
• Lexicon --> hypertext
• Scenarios --> Relations (complement, pre-condition,
equivalent, exception, sub-set, possible, precedence,
inclusion).
• Sentences (numerical itemization, chapters)
49
Organization
Scenarios
Emit order
form
Include
client
Change
client
information
Fill order
form
Cancel
form
Exclude
client
Ask for
quote
Change
quote
Emit
invoice
Calculate
quote
LEGEND
Complement
Pre condition
Equivalence
exception
Receive
payments
Approve
quote
50
Storage
• To be helpful, scenarios must be organized in such
a way that makes it easy to find them when needed
• We need
– Classification,
– Indexing and
– Presentation.
• Facet schemes (Reuse) : Functional Facets
(function, object, way), Non-Functional Facet
(type of the system, functional area, context)
51
Lexicon
• Identify symbols
– Apply elicitation techniques
– list
• Classify symbols
• Describe symbols
– Apply elicitation techniques
– Follow rules
– Gather inputs
• Verify
• Validate
52
Scenarios
•
Derivate
– identify actors
– identify scenarios
– create candidates
•
Describe
– Use representation
– Follow tips
– gather scenarios
•
Organize
– reorganize
– Define
– integrate
•
Verify
•
Validate
53
Scenarios
54
“Tips”
•
•
•
•
•
•
•
•
•
•
•
Scenarios
Short phrases
Maximize the use of LEL symbols
Use only one verb per phrase
Actors and resources must be LEL symbols
The objective must be concrete and precise
The context must have at least one item( place, time, pre-condition)
Resources must list all the resources used in the episodes, except for
those that will be used in sub-scenario
Actors must list all people/software involved in the episodes except for
those used in sub-scenarios
Each episode verb should be punctual
Episodes must happen within the limits/constraints imposed by the
context
Avoid using verbs such as “could”, “control”, “must”
55
Requirement Sentences
• Derivate from scenarios
• Classify by type
• Number them (organization)
56
Lexicon and Glossary
• +
–
–
–
–
Less ambiguity
Avoid “misunderstandings”
Increase specification accuracy
Improve communication
• Con
– Time consuming
– Needs validation
57