1

ModellingModelling II II

2

Objects

• Object – direct relationship with the real world

• Object– memory -> data -> Attributes– processes -> Operations -> Messages

• Object - Organization – Hierarchy– aggregation– generalization

3

Object Orientation

• Most famous:– Booch– OMT– Jacobson

4

UMLBirth

• 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

5

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

6

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

7

UMLBasic Representation:

• Static Model– ERD evolution

• Internal Dynamic Model– Data Flow – State Machines

• External Dynamic Model– use cases– Languages for interconecting objects

8

UML - Diagrams

• Use Case Diagrams

• Static Structure Diagrams

• Use Case Diagrams– Actors and their connections with

the system

• Textual description for the Use Case

• Class Diagram– Static Structure for the system

classes

• Object Diagram– Simplify the class diagram

9

UML - Diagrams

• State Diagram • State Diagram– Possible states an object may have

and events that cause state change– Activity Diagram– Sequential flow of activities

10

UML - Diagrams

• Interaction Diagrams

• Implementation 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)

• Component Diagram– Physical structure of the code in the form of

code components

• Distribution Diagram– Hardware and Software Physical

Architecture

11

Use Cases

Sequence

Colaboration

Classes

States

Activity(object behavior,

operation algorithms)

Components

Distribution

Activity(work flow, use

cases)

Requirements Design Implementation

UML - Diagrams

12

Use Case

Print Receipt

SalemanMake a Sale

Finance System

<<extend>>

13

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”

14

Use Case

• Textual Part– Use Case << name>>

• pre-condition• Main flow • sub-flow<<name>>• Alternative flow

– pre-condition

– steps

15

Use Cases

Open Cash Register

Manager

Close cash register

Stock Manager

Salesman

Manage stock Manually

Make a sale

Finance System

Exemplo:

16

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”

17

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.

18

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.

19

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…

20

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…)

21

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

22

Class / Object

car B

instanciation

instanciationcar A

Properties: Fuel capicityKm/galonavailabilitykm

Behavior:travelrefuel

23

Car FuelCapacity: Integerkmpergalon: Realavailability: RealKm: Integer

travel (Kms: Real)Refuel (quantity: Real)

name

attributes

operations

Class

24

Class whit attributes

Car - FuelCapcity: Integer- Kmpergalon: Real- availability: Real = 0- km: Real = 0

...

rj5015: Car FuelCapacity: 200kmpergalon: 40Availability: 40km: 1400

Object with Values

Class

• Attributes• Examples:

25

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

26

Inheritance

• Multiple• A class inherits attributes, operations and

association from multiple classes

• Offers a greater modelling power but leads to a greater complexity

27

Example

• Multiple

Vehicle

land water

Car Amphibian Boat

28

Inheritance

Employee

YeartoDate: Real

calculatePay() {abstract}

MonthlyBasis

Normalhours: RealExtraHours: Real

calculatePay()

HourBasis

Normalhours: RealExtraHours: Real

calculatePay()

29

Class Schema • Example: Company

Employee

Company Managers

Association

Agregation

HourBasis MonthlyBasis

Generalization

Class0..N

10..N

Project

Employee schedule

30

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?

31

Communication

• It is necessary to have a good communication between user/stakeholder and developers

Compreender modelo

AnlysisIs my understanding (vision) correct?

CenáriosDomínio do problemaProblem Domain

Understand the Models

Scenarios

32

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

33

Scenarios

Mundo RealReal World

Universe of Discourse

Situations

List of Situations

34

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.

35

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

36

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

37

Scenarios

38

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

39

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.

40

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)

41

Notation• Title

• [ 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

42

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 “

43

Notation

• Constraints on Context– local is Phrase +

{Constraint}

– Time is Phrase + {Constraint}

– Pre-condition is

• [Subject| Actor| Resource] + Verb + Predicate + {Restriction}

44

Notation

• Resource– Relevant Physical elements or information that

should be available to the scenario

• [ Substantive + {Constraint} ]

45

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

46

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

47

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

48

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

49

Organization• Lexicon --> hypertext

• Scenarios --> Relations (complement, pre-condition, equivalent, exception, sub-set, possible, precedence, inclusion).

• Sentences (numerical itemization, chapters)

50

Organization

Scenarios

Include client

Exclude client

Change clientinformation

Ask for quote

Change quote

Calculate quote

Approve quote

Fill orderform

Emit order form

Cancel form

Emit invoice

Receive payments

ComplementPre conditionEquivalenceexception

LEGEND

51

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)

52

Lexicon• Identify symbols

– Apply elicitation techniques

– list

• Classify symbols

• Describe symbols– Apply elicitation techniques

– Follow rules

– Gather inputs

• Verify

• Validate

53

Scenarios• Derivate

– identify actors

– identify scenarios

– create candidates

• Describe

– Use representation

– Follow tips

– gather scenarios

• Organize

– reorganize

– Define

– integrate

• Verify

• Validate

54

Scenarios

55

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”

“Tips”

56

Requirement Sentences

• Derivate from scenarios

• Classify by type

• Number them (organization)

57

Lexicon and Glossary

• +– Less ambiguity– Avoid “misunderstandings”– Increase specification accuracy– Improve communication

• Con– Time consuming– Needs validation