Lecture 2: Session I: Basic Modeling Techniques Session II: Challenges and Visions for Software Modeling - PowerPoint PPT Presentation

Loading...

PPT – Lecture 2: Session I: Basic Modeling Techniques Session II: Challenges and Visions for Software Modeling PowerPoint presentation | free to download - id: 496424-ZjE1O



Loading


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation
Title:

Lecture 2: Session I: Basic Modeling Techniques Session II: Challenges and Visions for Software Modeling

Description:

Lecture 2: Session I: Basic Modeling Techniques Session II: Challenges and Visions for Software Modeling * * * * * * * * Write Exclude in Use Case Extension Point ... – PowerPoint PPT presentation

Number of Views:70
Avg rating:3.0/5.0
Slides: 57
Provided by: wei1150
Learn more at: http://phd.gccis.rit.edu
Category:

less

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

Title: Lecture 2: Session I: Basic Modeling Techniques Session II: Challenges and Visions for Software Modeling


1
Lecture 2 Session I Basic Modeling Techniques
Session II Challenges and Visions for Software
Modeling
2
(No Transcript)
3
(No Transcript)
4
Roadmap
Lecture 1 rules for class, overview of the
topics
  • Use case and use case diagram
  • Break
  • Challenges and visions for software modeling

5
Steps Before Coding
Phase Action Results
Initiation Raise a business need domain model, business use cases
Requirement What to accomplish (abstract) use case, activity diagrams
Design How the system works (more details software architecture, components, data types, algorithms) component, class, sequence diagrams, formal specifications
6
Source of Requirements
  • Initial requirements come from the customer, by
  • Documents, such as RFI/RFP
  • Meetings, reports
  • Advanced requirements come from the analysts,
    after studying scope and price
  • Feasibility (technological, organizational etc)
  • Prototypes
  • Final requirements are stabilized in an
    iterative process.

7
Types of Requirements
Visible Functional Requirements The system will
deliver cash to the customer Cash will be
delivered after card was taken out Qualitative
Requirements The authorization process will
take no more than 1 sec The user interface
will be easy to use Hidden Requirements
Database maintenance processes will occur every
night
8
Intro Use Case and Use Case Diagram
9
Use Cases as Means of Communication
Customer
Designer
User
The use case should stimulate a discussion about
what the system should do, mainly with people who
are outside of the development team.
10
Use Case
A use case is a contract of an interaction
between the system and an actor. Use Case
Diagram an integration of use cases
11
Use Case Diagram
A use case diagram illustrates a set of use cases
for a system, the actors, and the interactions
between actors and use cases. A graphical
overview of the functionality provided by a
system in terms of actors, their goals
(represented as use cases), and any dependencies
between those use cases.
12
Use Case Diagram Objectives
  • Create a semi-formal model of the functional
    requirements
  • 2. Analyze and define
  • Scope
  • External interfaces
  • Scenarios and reactions

13
(No Transcript)
14
What makes a good Use Case Diagram?
Lack of ambiguity - Each requirement must be
interpreted in a single manner. Completeness -
The collection of all use cases is everything
that can be done to/with the system.
Consistency - Requirements should not conflict
with each other. If there are, tradeoffs must be
detected and discussed. Avoid design -
Requirements should raise a need, not answer it.
15
Construct a Use Case Diagram
16
Finding actors
  • External objects that produce/consume data
  • Must serve as sources and destinations for data
  • Must be external to the system

Humans Machines External systems Sensors
17
Actor Relationships Generalization/Specializatio
n
Define hierarchy for actors Notation The
child actor inherits all use-cases associations
Should be used if (and only if), the specific
actor has more responsibility than the
generalized one (i.e., associated with more
use-cases)
18
Association Actor and Use Case
  • Solid line
  • Interaction between actors and use case
  • Arrowhead (optional)
  • Control flow
  • Initial invocation, primary actor

19
Use Case Levels
20
Use Case Relationships
  • Goal enable flexibility in requirements
    specification
  • Isolating functionality
  • Enabling functionality sharing
  • Breaking functionality into manageable chunks
  • Relationships
  • Include
  • Extend
  • Generalization

21
Include
  • Goal
  • Decomposing complicated behavior
  • Centralizing common behavior
  • the behavior of the included use case is inserted
    into the behavior of the including use case -
    The first use case often depends on the outcome
    of the included use case.

22
Extend
the behavior of the extension use case may be
inserted in the extended use case under some
conditions Note the direction of the arrow The
base use-case does not know which use-case
extends it
23
Example Amazon
Actors? Base Use Cases? Include? Extend?
24
(No Transcript)
25
Generalization
use case may have common behaviors, requirements,
constraints, and assumptions with a more general
use case.
26
Example Cellphone Company System
Hint - Actors Phones, Phone Companies
27
(No Transcript)
28
Writing Use Cases
  • Name
  • Actors
  • Descriptions
  • Precondition
  • Main flow
  • Sub flow
  • Alternative flow

29
Precondition
  • What the system needs to be true before running
    the use-case.
  • User account exists
  • User has enough money in her account
  • There is enough disk space

30
Main flow
The success scenario is the main story-line of
the use-case Assumption everything is okay,
no errors or problems occur, and it leads
directly to the desired outcome of the use-case
It is composed of a sequence of subflows
Example Step 1 Administrator enters course
name, code and description (interaction) Step 2
System validates course code Step 3 System adds
the course to the db and shows a confirmation
message (interaction)
31
Sub flow
Branches If the user has more than 10000 in
her account, the system presents a list of
commercials Otherwise Repeats User enters
the name of the item he wishes to buy System
presents the items User selects items to buy
Systems adds the item to the shopping cart User
repeats steps 1-4 until indicating he is done
32
Alternative flows
  • Used to describe exceptional functionality
  • Examples
  • Errors
  • Unusual or rare cases
  • Failures
  • Starting points
  • Endpoints
  • Shortcuts

33
Write Include in User Case
Reference
34
Write Exclude in Use Case
Extension Point
35
Effective Use Cases
  • Only one side (system or actor) is doing
    something in a single step
  • Write from an objective point of view using
    active tense
  • Any step should lead to some progress

36
Effective Use Cases
ATM
Get the amount form the user and give him the
money User click the enter key
37
Effective Use Cases Common Mistakes
  • No actor
  • Too many user interface details User types ID
    and password, clicks OK or hits Enter
  • Very low goal details
  • User provides name
  • User provides address
  • User provides telephone number

38
From Use-Case to Use-Case Diagrams
  • Top down ?
  • Starting with an overview of the system, and
    then splitting Use-cases
  • Bottom up ?
  • Starting with throwing all scenarios on the
    page, and then combining them
  • Most of the analysis process are actually
    combined

39
Common Rules
  • Number Limit The diagram should have between 3
    to 10 base use-cases. No more than 15 use cases
    (base included extending).
  • ---- If the dependency between two parts of a
    use-case is weak, they should be divided.
  • Abstraction All use-cases should be in similar
    abstraction levels.
  • Size Use cases should be described in half a
    page or more.
  • - split using include/exclude

40
When we are done
  • When every actor is specified.
  • When every functional requirement has a use-case
    which satisfies it.
  • A tractability matrix can help us determine it

41
Use Case and Use Case Diagram a Summary
  • When to use
  • What is Use Case and Use Case Diagram
  • How to Construct Use Case Diagram
  • How to Write Use Case
  • Questions?

42
(No Transcript)
43
Wild and Crazy Ideas Session
  • Extreme Programming (coding, testing, listening,
    and designing)
  • vs. Product life cycle
  • .

44
Session II Challenges and Visions of Software
Modeling
45
How to read and present papers
  • Survey/roadmap papers
  • Important Abstract, Subtitles, Conclusions
  • Reading Notes
  • What is about? List knowledge learned, vision
  • Like/Dislike agree/disagree
  • Improvement other visions, correction or
    addition of the existing knowledge

46
How to read and present papers
  • Problem/Solution papers
  • Important abstract, intro, conclusion
  • Reading Notes
  • What is about?
  • Problems, Challenges, Existing Solutions, New
    solution, Experiments
  • Like/Dislike pros/cons of the solutions
  • Improvement Future work what to do to make it
    better?

47
Goals, Challenges, Initiatives
  • Problem/Solution papers
  • Important abstract, intro, conclusion
  • Reading Notes
  • What is about?
  • Problems, Challenges, Existing Solutions, New
    solution, Experiments
  • Like/Dislike pros/cons of the solutions
  • Improvement Future work what to do to make it
    better?

48
What this paper is about?
  • Challenges of software modeling
  • Create software models
  • Manage software models
  • Use software models

49
Create Software Models
  • Modeling languages
  • General purpose and domain-specific languages
  • Formalism
  • Level of abstraction
  • Models for software running in different
    platforms
  • Model-driven architecture
  • Views PIM (computation), CIM (environment), PSM
  • Models for software consistently changing at
    runtime (agent)
  • Modularity, separate concerns

50
Manage Software Models
  • Find information from the models (query)
  • Correctness of the models
  • Model consistencies
  • Model checking models
  • Transformations
  • Decomposition
  • Composition
  • Between models
  • Evolutions of models

51
Use Software Models
  • Generate code
  • Monitor runtime software behavior (interacting
    with environments, adaptation)
  • Testing (model-based testing criteria and test
    input generation)

52
Like/Dislike
  • This paper gives directions for further exploring
    the topics
  • Keyword automatic
  • Good breadth but lack of depth discussions on
    each issue
  • More of the knowledge paper rather than new ideas
    and arguments

53
Thoughts Interesting Research Problems
  • Selection of models for certain types of software
    What is the key characters that determine which
    model we should use?
  • Learn more from models code decisions, hardware
    running and debugging the software (parallelism?
    type-safe language? more efficient algorithms?
    Who is going to code this part?)

54
Discussion Questions
  • More research problems related to create, use,
    manage models?
  • Which one is easier to manage, verifier model or
    code?

55
Summary
  • Use case and use case diagrams
  • Challenges of software modeling
  • To do
  • Reading assignment 2
  • Homework 2

56
Reading Assignment for next Monday
  • Detecting Software Modularity Violations
About PowerShow.com