Modelling II - PowerPoint PPT Presentation

Loading...

PPT – Modelling II PowerPoint presentation | free to download - id: 719a58-NDgxO



Loading


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation
Title:

Modelling II

Description:

RE Lecure 5.ppt ... Modelling II – PowerPoint PPT presentation

Number of Views:36
Avg rating:3.0/5.0
Slides: 58
Provided by: yor69
Learn more at: http://www.eecs.yorku.ca
Category:

less

Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: Modelling II


1
Modelling II
2
Objects
  • Object direct relationship with the real world
  • Object
  • memory -gt data -gt Attributes
  • processes -gt Operations -gt Messages
  • Object - Organization Hierarchy
  • aggregation
  • generalization

3
Object Orientation
  • Most famous
  • Booch
  • OMT
  • Jacobson

4
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
5
UML
  • Unified Method
  • Grady Booch e Jim Rumbaugh
  • First presented at OOPSLA95
  • 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
UML
  • Basic 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
UML - Diagrams
Requirements
Design
Implementation
12
Use Case
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 ltlt namegtgt
  • pre-condition
  • Main flow
  • sub-flowltltnamegtgt
  • Alternative flow
  • pre-condition
  • steps

15
Use Cases
Exemplo
16
Use Cases
  • Example
  • Use Case ltlt Make a Salegtgt
  • 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 dont
    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
instanciation
instanciation
car B
23
Class
name
attributes
operations
24
Class
  • Attributes
  • Examples

Class whit attributes
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

28
Inheritance
29
Class Schema
  • Example Company

Agregation
0..N
1
Association
Class
0..N
Generalization
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 Patients
    Record?

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

Scenarios
Problem Domain
Understand the Models
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
Real World
Universe of Discourse
Situations
List of Situations
34
Scenarios
  • Situations 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 clients registration
  • Goal Verify if information on clients
    registration is correct
  • Context Client hand over clients registration
    and show a photo id
  • Actors Store clerk, Client.
  • Resources photo id, clients registration
  • Episodes
  • Store Clerk verifies id number on clients
    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 clients 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
  • Dont 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 clients
    registration
  • Objective
  • Subject Verb Predicate
  • Example
  • Verify if information on clients 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 clients 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 --gt hypertext
  • Scenarios --gt Relations (complement,
    pre-condition, equivalent, exception, sub-set,
    possible, precedence, inclusion).
  • Sentences (numerical itemization, chapters)

50
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
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
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 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

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
About PowerShow.com