Download presentation
Presentation is loading. Please wait.
1
Modelling II
2
Models – Main Objectives
Represent a viewpoint for the environment before the system is implemented Show alternative solutions Show future needs Represent parts of the system Allow to incrementally deal with complexity – from the more abstract level to the detailed level Provide quantitative information about the scope and complexity of the problem Allow to communicate with developers and stakeholders
3
Objects Object – direct relationship with the real world Object
memory -> data -> Attributes processes -> Operations -> Messages Object - Organization – Hierarchy aggregation generalization
4
Object Orientation Most famous: Booch OMT Jacobson
5
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 Differences among different approaches (authors) There was the need for a standard notation
6
UML “Unified Method” Rational Software Grady Booch e Jim Rumbaugh
First presented at OOPSLA’95 Rational Software Grady Booch, Jim Rumbaugh e Ivar Jacobson Rational Rose CASE tool
7
UML It is a Modelling language not a method !
A method consists of notation language + process The proposed processes are called Objectory or Rational Unified Process We can use UML regardless the process we use
8
UML - Diagrams Use Case Diagrams Textual description for the Use Case
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
operation algorithms)
UML - Diagrams Requirements Design Implementation States Use Cases Sequence Distribution Classes Collaboration Components Activity (work flow, use cases) Activity (object behaviour, operation algorithms)
12
Use Case Print Receipt <<Include>> Make a Sale Salesman
Finance System
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 auxiliary Test cases
14
Use Case Textual Part Use Case << name>> pre-condition
Main flow sub-flow<<name>> Alternative flow steps
16
Use Cases Example: Make a sale Salesman Finance System
Open Cash Register Manager Close cash register Stock Manager Salesman Manage stock Manually Make a sale Finance System
17
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”
18
Use Cases Identifying actors; Identifying use cases:
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.
19
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. Interaction Diagrams
20
Requirements and Use Cases
Use cases are NOT 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…
21
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, aggregation…)
22
Class/Object Class: Object:
Describe a set of objects that share the same properties (Attributes), behaviour (operation), relationships with other objects and semantics Object: An Object is an instance or occurrence of a class
23
Class / Object Properties: instantiation Fuel capacity Km/gallon
availability km Behaviour: travel refuel instantiation car A instantiation car B
24
Class name attributes operations Car FuelCapacity: Integer
kmpergalon: Real availability: Real Km: Integer travel (Kms: Real) Refuel (quantity: Real) attributes operations
25
Class Attributes Examples: Car rj5015: 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
26
Class Schema Example: Company Aggregation Company Managers 0..N 1
Association Class 0..N Employee Project Generalization Employee schedule HourBasis MonthlyBasis
27
Inheritance Inheritance Can be
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
28
Inheritance Account AccoountNumber:integer Withdraw() Regular Savings
Interest: Real calculateInterest() Minimum: Real ServiceFee: Real chargeFee()
29
Inheritance Multiple A class inherits attributes, operations and association from multiple classes Offer a greater modelling power but leads to a greater complexity
30
Example Multiple Vehicle land water Car Amphibian Boat
31
What is this a model of ?
32
State Machines Notation States are system/Object states that can be seen from outside. Examples: Elevator on the 5th floor Switch on Account closed
33
State Machines Notation Input/Output S0 S1 “data oriented”
f1 S0 S1 “function oriented“ f2
34
State Machine - Lets get the control (partial) of a chemical plant Ghezzi et al. pp. 169 temperature and pressure levels have to be monitored for safety reasons Sensors are installed to generate appropriated signal when any of these levels exceed a certain limit Warnings are generated if there is an over heating or if values are too high When one of these signals is activated, a recovery temperature and pressure recovery task is carried out If the recovery task does not succeed than the system must shut down plant .
35
State Machine Example: Pression Activity Normal Off Temperature Signal
Pressure signal Pression Activity Recovery OK Recovery no OK Normal Off Recovery OK Recovery not ok Temperature Signal Temperature Signal
38
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?
39
Objects “ The world outside the machine is very rich, full of whim and recalcitrantly multifaceted to be captured in the form of objects. M. Jackson
40
Communication It is necessary to have a good communication between user/stakeholder and developers Compreender modelo Anlysis Is my understanding (vision) correct? Cenários Domínio do problema Scenarios Problem Domain Understand the Models
41
Goals Goal-Oriented Models For Example KAOS
System goals x Client Goals
42
KAOS Developed in the early 90’s
Has been applied to a number of industrial cases Is supported by a stable and well defined tool
43
Composition Informal Goal structuring model
Producing Formal definitions in temporal logic for each entity
44
Example – Goals (Kaos)
45
Agents Actors and devices are very important
They are responsible for carrying out the tasks Agent-Oriented Models New properties Pro-Active Autonomous Distributed Intelligent, etc.
46
Organizational Modelling
Models about organizational aspects Must portrait aspects relate to management/business Software Engineering models are restricted Modelling elements linked to organizational concepts are needed
47
Organizational Models
has has Company has Supplier Strategic Goal Checks Supplies has has Process Function Client
48
Business Rules Policies (not procedures) identification Stability
limits responsibilities Stability
49
Business Rules Business Rules Functional Business Non-Functional Rules
Quality Rules Rules from the Microsystem
50
Examples Functional Rules Microsystem Rules
A meeting can be rescheduled or cancelled Supervisors answer to the VP Microsystem Rules CIT and CPP must be deducted every month
51
Modelling Requirements
Models are necessary (languages to build a software system) Requirements Model Specification Model Multi-purpose models
52
Modelling Representation Organization Storage
Perspective about the Product
53
Representation Lexicon Scenarios Sentences Requirements Documents
Glossary
54
Language Extended Lexicon (LEL)
Technique that aims to describe the symbols a certain language. LEL’s main idea is the existence of an application language. This idea departs from the notion that in the UofD there is one (or more) cultures (social group) and each has its own language. Thus, the main objective to be followed by REs is the identification of words or sentences that are peculiar to the social environment under study. Only after these words and sentences are identified the RE will search for their meaning.
56
Language Extended Lexicon
Use one or more technique for fact gathering (interviews, observation, document reading) Goal: Identify Words or sentences that seem to have a special/relevant meaning in the application Words or sentences that are frequently used or that brings doubts or that seem to be out of context. List of words and sentences. Big difference: Elicit functions vs Elicit symbols.
57
Language Extended Lexicon
Each symbol is described with Notions and Behavioural Responses. Notion represents what the symbol means (denotation). Behavioural Responses describe the effects from the use of this symbol. Characterize constraints imposed to the symbol or imposed by the symbol
58
Language Extended Lexicon
Circularity and Minimum vocabulary principles. Minimal Vocabulary: Refers to the sole use of frequent words with clear meaning and that are part of a restricted vocabulary Circularity: Refers to the use of symbols from the language (LEL symbols) to described notions and behavioural responses Studies show that while explaining a symbol actors (stakeholders/users) use symbols from their language.
59
Language Extended Lexicon
Renew Book Notions: Book exemplar is lent to a library user User wants to keep the book exemplar longer. Behavioural Responses: Library Employee changes return date for the book exemplar
60
Language Extended Lexicon
Return Date Notion Established Date to return book Behavioural Response: If return date is prior to current date the book exemplar is overdue
62
LEL
63
Scenarios Real World Universe of Discourse Situations
List of Situations
64
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
65
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.
66
Write Scenarios Describes situations of the macro system
Describes situations and their relationship with the system-to-be May be used to describe interaction between system components Use a semi-structured natural language (similar to LEL)
67
Why Semi-Structured? Minimize 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
68
Scenarios Title: Store checks client’s registration
Objective : Verify if information on client’s registration are correct Context: Client hand over client’s registration and show a photo id Actors: Store, Client. Resources: photo id, client’s registration Episodes Store fills up blank spaces in client’s registration using the initial “NE” (Non-existent) Stores verify id number on client’s registration against the one in the photo id Constraint: id number must comply with standards Store verify address and phone number calling the number in client’s registration
69
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.
70
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)
71
Notation Title Objective
[ Sentence | ( [ Actor | Resource ] + Verb + Predicate ) ] Example: Store 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
72
Notation Context The context is described detailing time, place and pre-conditions. At least one of them should appear “Client hand over client’s registration and show a photo id “
73
Notation Constraints on Context local is Phrase + {Constraint}
Time is Phrase + {Constraint} Pre-condition is [Subject| Actor| Resource] + Verb + Predicate + {Restriction}
74
Notation Resource Relevant Physical elements or information that should be available to the scenario [ Substantive + {Constraint} ]
75
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
76
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
77
Style Short phrases Try to avoid more than one verb per phrase
The objective 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
78
Scenarios Title: Add Book Exemplar to library collection
Objective: Book Exemplar belongs to 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 file book exemplar in the library management system 4 Library clerk reserve a physical space to place book exemplar according to information retrieved from the library management system, 5. Library Clerk place book exemplar in the correct physical space
79
Organization Lexicon --> hypertext
Scenarios --> Relations (complement, pre-condition, equivalent, exception, sub-set, possible, precedence, inclusion). Sentences (numerical itemization, chapters)
80
Organization Scenarios Emit order form Include client Change client
information Fill order form Cancel form Ask for quote Exclude client Change quote Emit invoice Calculate quote LEGEND Complement Pre condition Equivalence exception Receive payments Approve quote
81
Storage To be helpful scenarios must be organized in such a way that makes it easier to find it when needed We need Classification, Indexing and Presentation.
82
Lexicon Identify symbols Classify symbols Describe symbols Verify
Apply elicitation technique list Classify symbols Describe symbols Follow rules Gather inputs Verify Validate
83
Scenarios Derivate identify actors identify scenarios
create candidates Describe Use representation Follow tips gather scenarios Organize reorganize Define integrate Verify Validate
84
Scenarios “Tips” 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 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”
Similar presentations
© 2025 SlidePlayer.com Inc.
All rights reserved.