OO Software Life Cycle Use Case

Modeling

Lecture#2
Overview
•Collaborative Object Modeling and architectural design mEThod (COMET)
– Object Oriented Analysis and Design Method
– Uses UML (Unified Modeling Language) notation
• Standard approach for describing a software design
– COMET = UML + Method
•Provides steps and guidelines for
– Software Modeling and Design
– From Use Case Models to Software Architecture
•H. Gomaa, Software Modeling and Design:
UML, Use Cases, Patterns, and Software Architectures, Cambridge University Press, February 2011
Model Driven Architecture

• Promoted by Object Management Group (OMG)

• Model Driven Architecture
– Develop UML models of software architecture before implementation
• Platform Independent Model (PIM)
– Precise model of software architecture before commitment to specific platform
• Platform Specific Model (PSM)
– Map PIM UML model to a specific middleware technology
• CORBA, .NET, J2EE, Web Services
– Tool support for mapping from PIM to PSM
Unified Modeling Language (UML)

• UML
– A standardized notation for object-oriented development
– Combines notations of OMT, Booch, and use cases
– A graphical language for describing the products of OO requirements, analysis,
and design
– Approved as a standard by Object Management Group (OMG)
– Methodology independent
• Needs to be used with an analysis and design method
Object-Oriented Software Life Cycle with UML

• COMET object-oriented software life cycle model

Object-Oriented Software Life Cycle
Requirements Modeling

• Requirements Modeling
• Use Case Modeling
– Define software functional requirements in
terms of use cases and actors
Object-Oriented Software Life Cycle
Analysis Modeling

• Analysis Modeling consists of

• StaticModeling
• DynamicModeling
• State Machine modeling using statecharts
• Object interaction modeling
Object-Oriented Software Life Cycle
Analysis Modeling

• Static Modeling
– Define structural relationships between classes
– Depict classes and their relationships on class diagrams
Object-Oriented Software Life Cycle
Analysis Modeling

• DynamicModeling
– Define statecharts for state dependent control objects
– Defines how objects participate in use cases using communication diagrams or
sequence diagrams
Object-Oriented Software Life Cycle Design Modeling

• Develop overall software architecture

– Structure system into subsystems
• Design software architecture
– Design object-oriented software architectures
– Design client/server software architectures
– Design service-oriented architectures
– Design component-based software architectures.
– Design concurrent and real-time software architectures
– Design software product line architectures
Object-Oriented Software Life Cycle

• Incremental Software Construction

– Select subset of system based on use cases
– Detailed design, code, unit test of classes in subset
• Incremental Software Integration
– Integration testing of each system increment
– Integration test based on use cases
• System Testing
– Testing of software functional requirements
– Based on use cases
Steps in Using COMET/UML

1 Develop Software Requirements Model

– Develop Use Case Model (Chapter 6)
2 Develop Software Analysis Model
– Develop static model of problem domain (Chapter 7)
– Structure system into objects (Chapter 8)
– Develop statecharts for state dependent objects (Chapter 10)
– Develop object interaction diagrams for each use case (Chapter 9, 11)
3 Develop Software Design Model
Requirements Modeling

• Objectives of Software Requirements Specification

• Communication vehicle among multiple audiences
– Customers
– Users
– Analysts
– Designers
• Basis for Software Design
– Provide precise statement of requirements to designers
• Basis for Software Validation
• Basis for system acceptance criteria
• Basis for controlling evolution of system
– Changes to existing requirements
– Addition of new requirements
Components of Software Requirements Specification

• Functional Requirements
• Behavioral Requirements
• Information Requirements
• External Interface Requirements
• Non-Functional Requirements
• Design Constraints
Components of Software Requirements Specification

• Functional Requirements
– Inputs to software system
– Outputs from software system
– Processing to be performed
• Behavioral Requirements
– Externally observable states
– Transitions between states
• Information Requirements
– Entities (classes), Attributes, Relationships
– Data Dictionary
Components of Software Requirements Specification

• External Interface Requirements

– User Interfaces
• Specify characteristics of user interface
– E.g., Windows, WWW
• Can be detailed
– Specify individual screens
– Hardware Interfaces
• Very important for embedded systems
– Software Interfaces
• Interfaces to other software systems
• System context model
– Depict boundary of system
Non-Functional Requirements

• User interface characteristics

• Reliability
• Security
• Availability
• Performance
• Modifiability
• Portability
• Cost
Examples of Design Constraints

• Hardware to be supported
• System configuration
• – Centralized v. Distributed
• – Windows v. Unix
• Existing software to be utilized
• Portability requirements
• Anticipated changes to be accommodated
Attributes of Well-Written Software Requirements
Specification

1.Correct
– Each requirement is accurate interpretation of user needs
2.Complete
– Includes every significant requirement
– Defines system responses to every realizable input – No "TBD"s
3.Unambiguous
– Every stated requirement has only one interpretation
4.Consistent
– Individual requirements do not conflict
5.Conflicting Terms
• Conflicting characteristics • Temporal inconsistency
Attributes of Well-Written Software Requirements
Specification

• V erifiable
– Every requirement can be tested to determine that system meets requirement
• Understandable by non-computer specialists
– Formal vs informal notations ( Consistent/unambiguous vs Understandability
dilemma)
• Modifiable
– Need Table of Contents, Index, Cross-references
– Redundancy
• Modifiability vs Understandability dilemma
Attributes of Well-Written Software Requirements
Specification

1. Traceable
– Backwards:
2. To System Level Requirements
3.To User Needs – Forwards:
1.To design component(s) that satisfy requirement
2.To code components that satisfy requirement
Approaches to Developing Software Requirements
Specification

• Black Box Requirements Specification

– System considered as black box
– Specify
• External inputs and outputs
• Externally visible states and transitions
• Functions that produce outputs
• Methods for Requirements Analysis and Specification
– Structured Analysis
– Object-Oriented Analysis
– Use Case Modeling
Use Case Modeling

• Use Case
• Requirements 2 Modeling
• Analysis Modeling
– Describes sequence of interactions between user (actor) and system
– Narrative description
• Use Case model
– Define system functional requirements in terms of Actors and Use cases
• Use case relationships
– include
– extend
Actors

• Actor models external entities of system

• Actors interact directly with system
– Human user
– External I/O device
– External system
– Timer
• Actor initiates actions by system
– May use I/O devices or external system to physically interact with system
– Actor initiates use cases
Actors

• Primary Actor
– Starts the use case by providing input to the system
• Secondary Actor
– Participates in use case
– Can be Primary Actor of a different use case
• Actor
– Represents all users who use system in the same way
• A user is an instance of an actor

– Represents a role played by all users of the same type

• Human user may play more than one role
Use Cases

• Identifying use cases

• Calculate Trip Speed
• Use Cases
– Consider each major function an actor needs to perform
– Provides value to actor
– Use case is a complete sequence of events initiated by an actor
• Specifies interaction between actor and system
– Use case starts with input from an actor
– Basic path
Use Cases

• Most common sequence

– Alternative branches
• Variants of basic path
– E.g., for error handling
Banking system actor & use cases
Documenting Use Cases
• Name
• Summary
• – Short description of use case
• • Dependency (on other use cases)
• Actors
• Preconditions
• – Conditions that are true at start of use case
• Description
• – Narrative description of basic path
• Alternatives
• – Narrative description of alternative paths
• Postcondition
• – Condition that is true at end of use case
Example of Use Case
Example of Use Case
 Use Case Relationships

• Include relationship
– Identify common sequences of interactions in several use cases
• Extract common sequence into inclusion use case
• Base use cases includes abstract use case
• Example
– Withdraw Funds use case includes Validate PIN use case
Example of inclusion use case and include relationships
 Use Case Relationships

• Extend relationship
– Use case A is an extension of use case B
– Under certain conditions use case B will be extended by description given in
use case A
– Same use case can be extended in different ways
• When to use extend
– Show conditional parts of use case
– Model complex or alternative paths
• Example
– Pay by Cash extends Checkout Customer
Example of extend relationship
 Case Study: Banking System

• Multiple Automated Teller Machines (ATM)

– Customer inserts ATM Card
– Enters Personal Identification Number (PIN)
– ATM Transactions
• PIN Validation
• Withdraw Funds from Checking or Savings Account
• Query Account
• Transfer funds between accounts
• Banking System maintains information about
– Customers
– Debit cards
– Checking and Savings Accounts
Banking System use case model