Department of Computer Science

Slides:



Advertisements
Similar presentations
UML Diagrams Jung Woo. What is UML? Standard language for specifying, visualizing, constructing, and documenting the artifacts of software systems, business.
Advertisements

UML: Use Cases Michael L. Collard, Ph.D. Department of Computer Science Kent State University.
Unified Modeling Language UML Jonathan I. Maletic, Ph.D. Department of Computer Science Kent State University.
Use Cases and Scenarios
C++ Training Datascope Lawrence D’Antonio Lecture 11 UML.
© Copyright Eliyahu Brutman Programming Techniques Course.
UML Sequence Diagrams Eileen Kraemer CSE 335 Michigan State University.
UML Sequence Diagrams Michael L. Collard, Ph.D. Department of Computer Science Kent State University.
2005/05/25 Unified Modeling Lanauage 1 Introduction to Unified Modeling Language (UML) – Part One Ku-Yaw Chang Assistant Professor.
SOFTWARE ENGINEERING BIT-8 APRIL, 16,2008 Introduction to UML.
The Unified Modeling Language Part I Omar Meqdadi SE 2730 Lecture 6 Department of Computer Science and Software Engineering University of Wisconsin-Platteville.
UML Diagrams: Class Diagrams The Static Analysis Model Instructor: Dr. Hany H. Ammar Dept. of Computer Science and Electrical Engineering, WVU.
UML diagrams What is UML UML diagrams –Static modeoing –Dynamic modeling 1.
1 Structuring Systems Requirements Use Case Description and Diagrams.
1 System Analysis and Design Using UML INSTRUCTOR: Jesmin Akhter Lecturer, IIT, JU.
Logical view –show classes and objects Process view –models the executables Implementation view –Files, configuration and versions Deployment view –Physical.
R R R CSE870: Advanced Software Engineering: UML-- Use Cases1 Use Cases and Scenarios.
OMT Modeling 1. Object Model : presented by the object model and the data dictionary. 2. Dynamic Model: presented by the state diagrams and event flow.
Architecture View Models A model is a complete, simplified description of a system from a particular perspective or viewpoint. There is no single view.
1 Technical & Business Writing (ENG-715) Muhammad Bilal Bashir UIIT, Rawalpindi.
UML (Unified Modeling Language)
Chapter 6: System Models Omar Meqdadi SE 273 Lecture 6 Department of Computer Science and Software Engineering University of Wisconsin-Platteville.
From Use Cases to Implementation 1. Structural and Behavioral Aspects of Collaborations  Two aspects of Collaborations Structural – specifies the static.
1 Architectural Blueprints—The “4+1” View Model of Software Architecture (
Unified Modeling Language. What is UML? Standard language for specifying, visualizing, constructing, and documenting the artifacts of software systems,
From Use Cases to Implementation 1. Mapping Requirements Directly to Design and Code  For many, if not most, of our requirements it is relatively easy.
1 Team Skill 3 Defining the System Part 1: Use Case Modeling Noureddine Abbadeni Al-Ain University of Science and Technology College of Engineering and.
Engineering Quality Software Week02 J.N.Kotuba1 SYST Engineering Quality Software.
Design Review.
CHAPTER
UML Diagrams: Class Diagrams The Static Analysis Model
UML(Unified Modeling Language)
Business System Development
Instructor: Dr. Hany H. Ammar
Case Study -- Weather system
UML Diagrams By Daniel Damaris Novarianto S..
Component and Deployment Diagrams
Chapter 5 System modeling
Use Cases and Scenarios
Chapter 5 – System Modeling
Course Outcomes of Object Oriented Modeling Design (17630,C604)
Object-Oriented Analysis and Design
Architecture Concept Documents
Unified Modeling Language
UML Use Case Diagrams.
OO Domain Modeling With UML Class Diagrams and CRC Cards
UML Diagrams Jung Woo.
Online Shopping APP.
Software Architecture & Design Pattern
Use Cases CS/SWE 421 Introduction to Software Engineering Dan Fleck
Unified Modeling Language
Joey F. George, Dinesh Batra, Joseph S. Valacich, Jeffrey A. Hoffer
University of Houston-Clear Lake
Use Cases 1.
CIS 375 Bruce R. Maxim UM-Dearborn
Design and Implementation
Analysis models and design models
Software Design Lecture : 15.
Use Cases CS/SWE 421 Introduction to Software Engineering Dan Fleck
An Introduction to Software Architecture
Software Engineering System Modeling Chapter 5 (Part 1) Dr.Doaa Sami
Use Cases CS/SWE 421 Introduction to Software Engineering Dan Fleck
Engineering Quality Software
Design Yaodong Bi.
Chapter 22 Object-Oriented Systems Analysis and Design and UML
CIS 375 Bruce R. Maxim UM-Dearborn
Week 8 Lecture 1: Identifying Actors and Activities
Use Cases CS/SWE 421 Introduction to Software Engineering Dan Fleck
Software Development Process Using UML Recap
From Use Cases to Implementation
Presentation transcript:

Department of Computer Science UML: Use Cases Michael L. Collard, Ph.D. <SDML> Department of Computer Science Kent State University

Requirements Describes what the system is supposed to do Often is given in english (i.e., not in a formal language) If a system does not meet the actual requirements, then it has failed Requirements Engineering, Requirements Elicitation

Types of Requirements functional non-functional System must perform the given action non-functional System must perform actions within certain constraints time, space, security, etc.

Diagram Types (Review) Structural Diagrams focus on static aspects of the software system Class, Object, Component, Deployment Behavioral Diagrams focus on dynamic aspects of the software system Use-case, Interaction, State Chart, Activity

Structural Diagrams (Review) Class Diagram set of classes and their relationships. Describes interface to the class Object Diagram set of objects (class instances) and their relationships Component Diagram logical groupings of elements and their relationships Deployment Diagram set of computational resources (nodes) that host each component.

Behavioral Diagrams (Review) Use Case Diagram high-level behaviors of the system, user goals, external entities: actors Sequence Diagram focus on time ordering of messages Collaboration Diagram focus on structural organization of objects and messages State Chart Diagram event driven state changes of system Activity Diagram flow of control between activities

Diagrams & Process (Review) Requirements elicitation – High-level capture of user/system requirements Use Case Diagram Identify major objects and relationships Object and Class Diagrams Create scenarios of usage Class, Sequence and Collaboration Diagrams Generalize scenarios to describe behavior Class, State and Activity Diagrams Refine and add implementation details Component and Deployment Diagrams

UML Driven Process (Review)

Modeling a System’s Architecture System assembly Configuration management Vocabulary Functionality Design View Implementation View Use Case View Behavior Process View Deployment View Performance Scalability Throughput System topology Distribution Delivery Installation

Use Case Diagrams Description of a system’s behavior as it responds to a request that originates from outside of that system. Describes a set of sequences. Each sequence represents the interactions of things outside the system (actors) with the system itself (and key abstractions) Use cases represent the functional requirements of the system (non-functional requirements must be given elsewhere)

Use case Each use case has a descriptive name Describes what a system does but not how it does it. Use case names must be unique within a given package Examples: withdraw money, process loan

Actor Actors have a name An actor is a set of roles that users of use cases play when interacting with the system They are external entities They may be external an system or DB Examples: Customer, Loan officer

What is a Use Case Use case captures some user-visible functionality Granularity of functionality depends on the level of detail in your model Each use case achieves a discrete goal for the user Use Cases are generated through requirements elicitation

Goals vs. Interaction Goals – something the user wants to achieve Format a document Ensure consistent formatting of two documents Interaction – things the user does to achieve the goal Define a style Change a style Copy a style from one doc to the next

Developing Use Cases Understand what the system must do – capture the goals Understand how the user must interact to achieve the goals – capture user interactions Identify sequences of user interactions Start with goals and refine into interactions

Example

Refining Use Cases Separate internal and external issues Describe flow of events in text, clearly enough for customer to understand Main flow of events Exceptional flow of events Show common behaviors with includes Describe extensions and exceptions with extends

Extend and Include

System Boundary

Use Case – Buy Item Actors: Customer (initiator), Cashier Type: Primary Description: The costumer arrives at the checkout with items to purchase. Cashier records purchases and collects payment. Customer leaves with items

Example (generalization)

Example: Weather Monitoring Station This system shall provide automatic monitoring of various weather conditions. Specifically, it must measure: wind speed and direction temperature barometric pressure humidity The system shall also proved the following derived measurements: wind chill dew point temperature temperature trend barometric pressure trend

Weather Monitoring System Requirements The system shall have the means of determining the current time and date so that it can report the highest and lowest values for any of the four primary measurements during the previous 24 hour period. The system shall have a display that continuously indicates all eight primary and derived measurements, as well as current time and date. Through he use of a keypad the user may direct the system to display the 24 hour low or high of any one primary measurement, with the time of the reported value. The system shall allow the user to calibrate its sensors against known values, and set the current time and date.

Hardware Requirements Use a single board computer (486?) Time and date are supplied by an on-board clock accessible via memory mapped I/O Temperature, barometric pressure, and humidity are measured by on board circuits with remote sensors. Wind direction and speed are measure from a boom encompassing a wind vane (16 directions) and cups (which advance a counter every revolution) User input is provided through an off the shelf keypad, managed by onboard circuit supplying audible feed back for each key press. Display is off the self LCD with a simple set of graphics primitives. An onboard timer interrupts the computer every 1/60 second.

Display and Keypad N W E S LCDDisplay – Values and current system state (Running, Calibrating, Selecting, Mode) Operations: drawtext, drawline, drawcircle, settextsize, settextstyle, setpensize Keypad allows user input and interaction Operations: last key pressed Attributes: key N Date: Time: Temp: Pressure: Humidity: Temp Hum Press W E Wind Time Date Select Cal Mode S

Use Diagrams

Scenario: Powering Up Power is turned on Each sensor is constructed User input buffer is initialized Static elements of display are drawn Sampling of sensors is initialized The past high/low values of each primary measurement is set to the value and time of their first sample. The temperature and Pressure trends are flat. The input manager is in the Running state

Scenario: Setting Time and Date User presses Select key System displays selecting User presses any one of the keys Time or Date. Any other key is ignored except Run System flashes the corresponding label Users presses Up or Down to change date or time. Control passes back to step 3 or 5 User may press Run to abandon the operation.

Scenario: Display highest and lowest User presses Select key System displays selecting User presses any one of the keys (Wind, Temp, Humidity, Pressure). Any other key is ignored except Run System flashes the corresponding label Users presses Up or Down to select display of highest or lowest in 24 hour period. Any other key press is ignored except for Run System displays value with time of occurrence Control passes back to step 3 or 5 User may press Run to abandon the operation.

Use Diagrams

Well-Structured Use Cases Names a single identifiable and reasonably atomic behavior of the system Factors common behavior by pulling such behavior from other use cases that include it Factors variants by pushing such behavior into other uses cases that extend it Describes flow of events clearly Described in a minimal set of scenarios