Use Cases

1
MIS 160 Systems Development Life Cycle I Lecture
9Object-Oriented Systems Development(OOSD)Unif
ied Modeling Language
2
A New Paradigm

• Paradigm
• a pattern or way of thinking and believing that
  serves to organize the way we approach knowledge,
  learning and understanding.
• Paradigm shift
• a major change in the way we think about
  something.
• occurs when we adopt a radically different way of
  organizing all or part of our worldview.

3
Introducing .Object-Oriented Technology

• A fundamentally different way of thinking about
  developing systems
• Object-oriented means that we organize software
  as a collection of discrete objects that
  incorporate both data and behavior
• Object-oriented development an approach to
  systems development that proposes the use of
  objects in the building of new systems and the
  rebuilding of old ones
• The change to Object Oriented thinking is so
  dramatic and far-reaching that it qualifies as a
  true paradigm shift

4
UML

• Unified Modeling Language a common notation set
  for object modeling
• Adopted by Object Management Group (OMG) on
  November 17, 1997
• Not a methodology! Notation only.
• Created by Rational, Inc. by Booch, Rumbaugh, and
  Jacobson

5
UML

• The UML is a language for
• visualizing
• specifying
• constructing
• documenting
• a software-intensive system

6
OO Life Cycle Using UML

• Planning
• High level (project identification and selection)
• Low level (project initiation and planning)
• Analysis
• Determine system requirements
• Use cases
• Structure requirements
• Preliminary class diagram
• State diagrams
• Preliminary interaction diagrams
• Activity diagrams
• Package diagrams
• Design
• Logical
• screens, reports, etc.
• Physical
• Detailed interaction diagrams
• Add layers
• data management

7
Fountain Model

• Henderson-Sellers and Edwards, 1980
• Object-oriented methodology
• Based on the Waterfall model

8
Fountain Model

• Framework for OOSD
• undertake object-oriented system requirements
  specification
• identify the objects (entities) and the services
  each provides (interface)
• establish interactions between objects in terms
  of services required and services rendered
• analysis stage merges into design stage use of
  lower level entity data-flow diagrams/information
  flow diagrams

9
Fountain Model
10
Unified Process Structure
Phases
Process Workflows
Elaboration
Transition
Inception
Construction
Business Modeling
Requirements
Analysis Design
Implementation
Test
Deployment
Supporting Workflows
Configuration Mgmt
Management
Environment
Preliminary Iteration(s)
Iter.1
Iter.2
Iter.n
Iter.n1
Iter.n2
Iter.m
Iter.m1
Iterations
11
Iterations and Workflow
Requirements
Analysis
Design
Implementation
Test
12
Overview of the UML

• Modeling elements
• Relationships
• Extensibility Mechanisms
• Diagrams

13
Modeling Elements

• Structural elements
• class, interface, collaboration, use case,
  active class, component, node
• Behavioral elements
• interaction, state machine
• Grouping elements
• package, subsystem
• Other elements
• note

14
Relationships

• Dependency
• Association
• Generalization
• Realization

15
Extensibility Mechanisms

• Stereotype
• Tagged value
• Constraint

16
Models, Views, and Diagrams
A model is a complete description of a
system from a particular perspective
Models
Activity Diagrams
17
Diagrams

• A diagram is a view into a model
• Presented from the aspect of a particular
  stakeholder
• Provides a partial representation of the system
• In the UML, there are nine standard diagrams
• Static views use case, class, object, component,
  deployment
• Dynamic views sequence, collaboration,
  statechart, activity

18
Use Case Diagram

• Captures system functionality as seen by users

19
Use Case Diagram

• Captures system functionality as seen by users
• Built in early stages of development
• Purpose
• Specify the context of a system
• Capture the requirements of a system
• Validate a systems architecture
• Drive implementation and generate test cases
• Developed by analysts and domain experts

20
Use Case Model
Use Case Diagrams
Object Diagrams
Class Diagrams
Component Diagrams
Deployment Diagrams
Sequence Diagrams
Collaboration Diagrams
Statechart Diagrams
Activity Diagrams
21
Class Diagram

• Captures the vocabulary of a system

22
Class Diagram

• Captures the vocabulary of a system
• Built and refined throughout development
• Purpose
• Name and model concepts in the system
• Specify collaborations
• Specify logical database schemas
• Developed by analysts, designers, and implementers

23
Object Diagram

• Captures instances and links

24
Object Diagram

• Shows instances and links
• Built during analysis and design
• Purpose
• Illustrate data/object structures
• Specify snapshots
• Developed by analysts, designers, and implementers

25
Sequence Diagram

• Captures dynamic behavior (time-oriented)

26
Sequence Diagram

• Captures dynamic behavior (time-oriented)
• Purpose
• Model flow of control
• Illustrate typical scenarios

27
Collaboration Diagram

• Captures dynamic behavior (message-oriented)

28
Collaboration Diagram

• Captures dynamic behavior (message-oriented)
• Purpose
• Model flow of control
• Illustrate coordination of object structure and
  control

29
Statechart Diagram

• Captures dynamic behavior (event-oriented)

30
Statechart Diagram

• Captures dynamic behavior (event-oriented)
• Purpose
• Model object lifecycle
• Model reactive objects (user interfaces, devices,
  etc.)

31
Activity Diagram

• Captures dynamic behavior (activity-oriented)

32
Activity Diagram

• Captures dynamic behavior (activity-oriented)
• Purpose
• Model business workflows
• Model operations

33
Deployment and Implementation Model
Use Case Diagrams
Object Diagrams
Class Diagrams
Component Diagrams
Deployment Diagrams
Sequence Diagrams
Collaboration Diagrams
Statechart Diagrams
Activity Diagrams
34
Component Diagram

• Captures the physical structure of the
  implementation

35
Component Diagram

• Captures the physical structure of the
  implementation
• Built as part of architectural specification
• Purpose
• Organize source code
• Construct an executable release
• Specify a physical database
• Developed by architects and programmers

36
Deployment Diagram

• Captures the topology of a systems hardware

37
Deployment Diagram

• Captures the topology of a systems hardware
• Built as part of architectural specification
• Purpose
• Specify the distribution of components
• Identify performance bottlenecks
• Developed by architects, networking engineers,
  and system engineers