CMPSCI520/620 07 Requirements & UML Intro
07 Requirements SW Requirements Specification
• Readings • How do we communicate the Requirements to others? • [cK99] Cris Kobryn, Co-Chair, “Introduction to UML: Structural and Use Case Modeling,” UML Revision Task Force Object Modeling with OMG UML Tutorial • It is common practice to capture them in an SRS Series © 1999-2001 OMG and Contributors: Crossmeta, EDS, IBM, Enea Data, • But an SRS doesn’t need to be a single paper document Hewlett-Packard, IntelliCorp, Kabira Technologies, Klasse Objecten, Rational Software, Telelogic, Unisys http://www.omg.org/technology/uml/uml_tutorial.htm • Purpose • [OSBB99] Gunnar Övergaard, Bran Selic, Conrad Bock and Morgan Björkande, “Behavioral Modeling,” UML Revision Task Force, Object Modeling with OMG UML • Contractual requirements Tutorial Series © 1999-2001 OMG and Contributors: Crossmeta, EDS, IBM, Enea elicitation Data, Hewlett-Packard, IntelliCorp, Kabira Technologies, Klasse Objecten, Rational • Baseline Software, Telelogic, Unisys http://www.omg.org/technology/uml/uml_tutorial.htm • for evaluating subsequent products • [laM01] Maciaszek, L.A. (2001): Requirements Analysis and System Design. • for change control requirements Developing Information Systems with UML, Addison Wesley Copyright © 2000 by analysis Addison Wesley • Audience • [cB04] Bock, Conrad, Advanced Analysis and Design with UML • Users, Purchasers requirements http://www.kabira.com/bock/ specification • [rM02] Miller, Randy, “Practical UML: A hands-on introduction for developers,” • Systems Analysts, Requirements Analysts Copyright © 2002 TogetherSoft, Inc. [now at Borland site] • Developers, Programmers http://bdn.borland.com/article/0,1410,31863,00.html requirements • Testers validation • Project Managers
UNIVERSITY OF MASSACHUSETTS AMHERST • DEPARTMENT OF COMPUTER SCIENCE • CMPSCI 520/620 FALL 2004 UNIVERSITY OF MASSACHUSETTS AMHERST • DEPARTMENT OF COMPUTER SCIENCE • CMPSCI 520/620 FALL 2004
What about RFP/RFB/RFIs? Appropriate Specification
• RFP = ‘SRS’ written by the procurer (or by an • Consider two different projects: independent RE contractor) • Tiny project, 1 programmer, 2 months work • Selected developer may create a more detailed ‘SRS’ • Programmer talks to customer, then writes up a 5-page memo • developer’s understanding of the customers needs • Large project, 50 programmers, 2 years work • basis for evaluation of contractual performance • Team of analysts model the requirements, then document • Not typically response to RFP them in a 500-page SRS • IEEE Standard recommends SRS jointly developed by Project A Project B procurer and developer Purpose of spec? Crystalizes programmer’s Build-to document; must understanding; feedback to contain enough detail for all • When to issue RFP/RFB? customer the programmers Management Spec is irrelevant; have Will use the spec to estimate • Early (conceptual stage) view? already allocated resource needs and plan the resources development • Late (detailed specification stage) Readers? Primary: Spec author; Primary: programmers, Secondary: Customer testers, managers; Secondary: customers
UNIVERSITY OF MASSACHUSETTS AMHERST • DEPARTMENT OF COMPUTER SCIENCE • CMPSCI 520/620 FALL 2004 UNIVERSITY OF MASSACHUSETTS AMHERST • DEPARTMENT OF COMPUTER SCIENCE • CMPSCI 520/620 FALL 2004
Rick Adrion 2004 (except where noted) 1 CMPSCI520/620 07 Requirements & UML Intro
Hints & Guidelines There is no Perfect SRS
• Validity (or “correctness”) • Ambiquity • expresses only the real needs of • every statement can be read in condense the stakeholders (customers, exactly one way users,…) • defines confusing terms ambiguousambiguous • Completeness • e.g. in a glossary • specifies all the things the system • Verifiablility expand must do and all the things it must • includes a process exists to test not do! satisfaction of each requirement expand • Conceptual Completeness • every requirement is specified • e.g. responses to all classes of input behaviorally • Structural Completeness • Understandablility (Clarity) redundantredundant formalize inconsistentinconsistent • e.g. no “to be determined” functions • e.g. by non-computer specialists • Consistency • technical notations should only be • not self-contradictory used as backup (e.g. in an reduce add • satisfiable appendix) explanations resolve • all terms used consistently • Modifiability not • inconsistency can be hard to • easy to change and modify not detect especially in timing aspects • good structure and cross- understandableunderstandable and business logic referencing incompleteincomplete • Necessary • must be kept up to date! • doesn’t contain anything that isn’t “required” see IEEE-STD-830-1993 © Steve Easterbrook 2000-2002
UNIVERSITY OF MASSACHUSETTS AMHERST • DEPARTMENT OF COMPUTER SCIENCE • CMPSCI 520/620 FALL 2004 UNIVERSITY OF MASSACHUSETTS AMHERST • DEPARTMENT OF COMPUTER SCIENCE • CMPSCI 520/620 FALL 2004
Typical mistakes IEEE std offers different templates
• Noise • Jigsaw puzzles • External stimulus or external situation • text that carries no relevant • distributing key information across • e.g., for an aircraft landing system, each information to any feature of the a document and then cross- 1.Introduction different type of landing situation: wind gusts, no problem. referencing 1.Introduction fuel, short runway, etc • Purpose • Silence • Duckspeak requirements • Purpose • System feature •• ScopeScope • e.g., for a telephone system: call forwarding, call • a feature that is not covered by • requirements that are only there to • Definitions, acronyms, abbreviations blocking, conference call, etc any text. conform to standards • Definitions, acronyms, abbreviations • Reference documents • System response Over-specification Unnecessary invention of terminology • Reference documents • • • Overview • e.g., for a payroll system: generate pay-cheques, • text that describes a feature of the • e.g. ‘user input presentation • Overview report costs, print tax info; 2.Overall Description solution, rather than the problem. function’ 2.Overall Description • External object • Contradiction • e.g. ‘airplane reservation data •• ProductProduct perspective perspective • e.g. for a library information system, organize by • text that defines a single feature in validation function’ •• ProductProduct functions functions book type a number of incompatible ways. • Inconsistent terminology •• UserUser characteristics characteristics • User type • Ambiguity • inventing and then changing • Constraints • e.g. for a project support system: manager, • Constraints technical staff, administrator, etc. • text that can be interpreted in at terminology • Assumptions and Dependencies • Assumptions and Dependencies • Mode least two different ways. • Putting the onus on the development 3.Specific Requirements staff 3.Specific Requirements • e.g. for word processor: page layout mode, • Forward reference outline mode, text editing mode, etc • i.e. making the reader work hard to Appendices • text that refers to a terms or Appendices • Object features yet to be defined. decipher the intent Index Index • e.g., in a patient monitorng system, objects • Wishful thinking • Writing for the hostile reader include patients, sensors, nurses, rooms, • text that defines a feature that • fewer of these than friendly physicians, medicines, etc. cannot possibly be validated. readers from Steve Easterbrook © 2000-2002; he adapted from Kovitz, 1999 UNIVERSITY OF MASSACHUSETTS AMHERST • DEPARTMENT OF COMPUTER SCIENCE • CMPSCI 520/620 FALL 2004 UNIVERSITY OF MASSACHUSETTS AMHERST • DEPARTMENT OF COMPUTER SCIENCE • CMPSCI 520/620 FALL 2004
Rick Adrion 2004 (except where noted) 2 CMPSCI520/620 07 Requirements & UML Intro
Maciaszek vs. IEEE SRS using a UML “package” construct
1.1.IntroductionIntroduction •• PurposePurpose •• ScopeScope •• Definitions,Definitions, acronyms, acronyms, abbreviations abbreviations •• ReferenceReference documents documents •• OverviewOverview 2.2.OverallOverall Description Description •• ProductProduct perspective perspective •• ProductProduct functions functions •• UserUser characteristics characteristics •• ConstraintsConstraints •• AssumptionsAssumptions and and Dependencies Dependencies 3.3.SpecificSpecific Requirements Requirements Appendices Appendices Index Index Probasco and Leffingwell Rational Software
UNIVERSITY OF MASSACHUSETTS AMHERST • DEPARTMENT OF COMPUTER SCIENCE • CMPSCI 520/620 FALL 2004 UNIVERSITY OF MASSACHUSETTS AMHERST • DEPARTMENT OF COMPUTER SCIENCE • CMPSCI 520/620 FALL 2004
SRS using a UML “package” construct UML & SRS
• SRS • may include a single document, multiple documents, use case specifications and even the graphical use case model which describes relationships amongst the use cases. • Stakeholders • system analyst • use-case specifier • designers • implementers • project manager • testers • Features Drive Use Case Models “Combining Software Requirements Specifications with Use-Case Modeling,” Use Cases Interpret Leslee Probasco and Dean Leffingwell Requirements www.spc.ca/downloads/srs_usecase.doc
UNIVERSITY OF MASSACHUSETTS AMHERST • DEPARTMENT OF COMPUTER SCIENCE • CMPSCI 520/620 FALL 2004 UNIVERSITY OF MASSACHUSETTS AMHERST • DEPARTMENT OF COMPUTER SCIENCE • CMPSCI 520/620 FALL 2004
Rick Adrion 2004 (except where noted) 3 CMPSCI520/620 07 Requirements & UML Intro
Example SRS format and style
• openCMSstruts • Modifiability • http://opencmsstruts.sourceforge.net/vision.html • well-structured, indexed, cross-referenced, etc. • redundancy should be avoided or must be clearly marked as such • We’ll come back to UML & RUP • An SRS is not modifiable if it is not traceable... • Traceability • Need a way of referring to each requirement • Backwards - the specification must be “traced” • each requirement traces back to a source or authority • e.g. a requirement in the system spec; a stakeholder; etc • Forward - the specification must be “traceable” • each requirement will eventually trace forwards to parts of the design that satisfy it
UNIVERSITY OF MASSACHUSETTS AMHERST • DEPARTMENT OF COMPUTER SCIENCE • CMPSCI 520/620 FALL 2004 UNIVERSITY OF MASSACHUSETTS AMHERST • DEPARTMENT OF COMPUTER SCIENCE • CMPSCI 520/620 FALL 2004
Requirements Negotiation & Validation Issues
Conversation Schedule Phone Conversation Campaign Negotiation Supporter • Outcome Campaign Details Database
•Based on draft of document Ticket CRUD* Campaign Telemarketing Telemarketer Supporter Placement and Supporter Details “business” •Validation Supporter •Scope Supporter Ticket Order Database Details Order Processing use case model
Based on (almost) complete document •Dependencies Enter Conversation • Maciaszek Requirements Analysis and System Design © Addison Wesley, 2000 System scope model Outcome •Risks Maciaszek Requirements Analysis and System Design © Addison Wesley, 2000 •Issues requirements elicitation • Technical •Scope • Performance requirements •Dependencies analysis • Database integrity • Development process •Risks requirements specification • Political •Priorities • Legal Requirements dependency matrix requirements validation • Volatility
UNIVERSITY OF MASSACHUSETTS AMHERST • DEPARTMENT OF COMPUTER SCIENCE • CMPSCI 520/620 FALL 2004 UNIVERSITY OF MASSACHUSETTS AMHERST • DEPARTMENT OF COMPUTER SCIENCE • CMPSCI 520/620 FALL 2004
Rick Adrion 2004 (except where noted) 4 CMPSCI520/620 07 Requirements & UML Intro
But first, let’s discuss Project 1
• Goal - Develop a Software Requirements Specification for a Course Management System “tool” to be designed, developed and incorporated in the Sakai framework using the RUP template or the IEEE Std. or the OpenCms-Struts “template” • Vision Document • SRS • Introduction Section 1: Purpose, Scope, Definitions, Acronyms and Abbreviations, and provide References Seque to a quick UML overview • Overall Description Section 2: a list of names and brief descriptions of all use cases and actors, along with applicable diagrams and relationships • In Section 3, for each use case diagram in Section 2 define a use-case report, making sure that each feature or requirement is clearly labeled and traceable to the Vision document. • Appendices, including: a) Table of contents, b) Index, and c) use-case storyboards or user-interface prototypes, if needed. • Process • Identify Stakeholders -- October 7 • Develop questionnaires -- October 7 • Plan and carry out interviews -- by October 28 • Define Vision Document • Define Use-Cases -- November 4 • Complete the SRS
UNIVERSITY OF MASSACHUSETTS AMHERST • DEPARTMENT OF COMPUTER SCIENCE • CMPSCI 520/620 FALL 2004 UNIVERSITY OF MASSACHUSETTS AMHERST • DEPARTMENT OF COMPUTER SCIENCE • CMPSCI 520/620 FALL 2004
How shall we do this? Note - UML overheads are adapted from
• Pick the CMS “tool” • “Introduction to UML: Structural and Use Case Modeling,” Cris Kobryn, Co- • Common or different for each group? Chair UML Revision Task Force Object Modeling with OMG UML Tutorial • Project 1 prelim: each group email me the selected tool and get approval Series © 1999-2001 OMG and Contributors: Crossmeta, EDS, IBM, Enea • Develop questionnaires Data, Hewlett-Packard, IntelliCorp, Kabira Technologies, Klasse Objecten, • Stakeholders to be interviewed Rational Software, Telelogic, Unisys • Department staff & associate chair • OIT • “Behavioral Modeling,” Gunnar Övergaard, Bran Selic, Conrad Bock and • Registrar Morgan Björkande, UML Revision Task Force, Object Modeling with OMG • CCBIT UML Tutorial Series © 1999-2001 OMG and Contributors: Crossmeta, EDS, • Faculty IBM, Enea Data, Hewlett-Packard, IntelliCorp, Kabira Technologies, Klasse • Yourselves • Sample “portal” questions/interview outline Objecten, Rational Software, Telelogic, Unisys • Plan and carry out interviews • MACIASZEK, L.A. (2001): Requirements Analysis and System Design. • 30 minutes/stakeholder-group Developing Information Systems with UML, Addison Wesley Copyright © • In class or another scheduled time -- last weeks of October? 2000 by Addison Wesley • Videotape! • “Analysis and Design with UML,” Rational Copyright © 1997 by Rational • For selected “tool,” define Vision Document Software Corporation • Assign one member of the group for this? • For selected “tool,” define Use-Cases • “Practical UML: A hands-on introduction for developers,” Copyright © 2002 • Assign rest of the group for this? TogetherSoft, Inc. • Complete the SRS
UNIVERSITY OF MASSACHUSETTS AMHERST • DEPARTMENT OF COMPUTER SCIENCE • CMPSCI 520/620 FALL 2004 UNIVERSITY OF MASSACHUSETTS AMHERST • DEPARTMENT OF COMPUTER SCIENCE • CMPSCI 520/620 FALL 2004
Rick Adrion 2004 (except where noted) 5 CMPSCI520/620 07 Requirements & UML Intro
O-O problem solving O-O System Development
problem
• underlying tenet begins with the construction of a model statement Requirements • a model is an abstraction of the underlying problem Requirements • the domain is the actual world from which the problem elicitation comes nonfunctional functional use case • models consist of objects that interact by sending each requirements model diagram other messages Requirements • objects have things they know (attributes) and things analysis they can do (behaviors or operations) statechart
diagram High-Level values of an object's attributes determine its state class analysis dynamic • diagram object model model classes are the "blueprints" for objects sequence • diagram
• a class wraps attributes (data) and behaviors (methods Design or functions) into a single distinct entity System design • objects are instances of classes. system design subsystem design goals object model decomposition
Copyright © 2002 TogetherSoft, Inc adapted from Bruegge/Dutoit O-O SW Engr
UNIVERSITY OF MASSACHUSETTS AMHERST • DEPARTMENT OF COMPUTER SCIENCE • CMPSCI 520/620 FALL 2004 UNIVERSITY OF MASSACHUSETTS AMHERST • DEPARTMENT OF COMPUTER SCIENCE • CMPSCI 520/620 FALL 2004
O-O System Development Rational Unified Process
System design High-Level Design
Architectural Architectural Describe Describe Review the Architecture system design subsystem Analysis Design Concurrency Distribution Architecture Reviewer design goals Architect object model decomposition
Object design Detailed Design
class object design Use-Case Subsystem diagram model Review the Analysis Design Use-Case Design Design Designer Design Reviewer
Implementation Code Code Class Test Design
source & Test code
Database Design Database deliverable Designer system
adapted from Bruegge/Dutoit O-O SW Engr
UNIVERSITY OF MASSACHUSETTS AMHERST • DEPARTMENT OF COMPUTER SCIENCE • CMPSCI 520/620 FALL 2004 UNIVERSITY OF MASSACHUSETTS AMHERST • DEPARTMENT OF COMPUTER SCIENCE • CMPSCI 520/620 FALL 2004
Rick Adrion 2004 (except where noted) 6 CMPSCI520/620 07 Requirements & UML Intro
Rational Unified Process UML Overview
nonfunctional functional use case requirements model diagram
Requirements analysis statechart diagram class analysis dynamic diagram object model model sequence specifying diagram The UML is a the artifacts System design visualizing graphical constructing of software system design subsystem design goals object model decomposition Architectural ArchitecturalDescribe Describe Review theArchitecture systems Reviewer language for Architect Analysis Design ConcurrencyDistribution Architecture documenting
Use-Case Subsystem Review the Analysis Design Use-Case Design Design Designer Design Reviewer
Class Design
Database Database Design Designer
UNIVERSITY OF MASSACHUSETTS AMHERST • DEPARTMENT OF COMPUTER SCIENCE • CMPSCI 520/620 FALL 2004 UNIVERSITY OF MASSACHUSETTS AMHERST • DEPARTMENT OF COMPUTER SCIENCE • CMPSCI 520/620 FALL 2004
UML Goals Unifying Concepts in UML
•an easy-to-learn but • classifier-instance dichotomy semantically rich visual modeling language • e.g., an object is an instance of a class OR a class is the classifier of an object •unify the Booch, OMT, and Objectory modeling languages • specification-realization dichotomy •ideas from other modeling • e.g., an interface is a specification of a class OR a class languages + industry best is a realization of an interface practices • building blocks: •enable model interchange and • model elements (classes, interfaces, components, use define repository interfaces cases, etc.) •provide a common vocabulary to talk about object-oriented • relationships (associations, generalization, software design. dependencies, etc.) • diagrams (class diagrams, use case diagrams, interaction diagrams, etc.)
UNIVERSITY OF MASSACHUSETTS AMHERST • DEPARTMENT OF COMPUTER SCIENCE • CMPSCI 520/620 FALL 2004 UNIVERSITY OF MASSACHUSETTS AMHERST • DEPARTMENT OF COMPUTER SCIENCE • CMPSCI 520/620 FALL 2004
Rick Adrion 2004 (except where noted) 7 CMPSCI520/620 07 Requirements & UML Intro
Well-formedness rules What is use case modeling?
• Well-formed: indicates that a model or model fragment • use case model adheres to all semantic and syntactic rules that apply to it. • a view of a system that emphasizes the behavior as it appears • UML specifies rules for: naming, scoping, visibility, to outside users. A use case model partitions system integrity & execution (limited) functionality into transactions (‘use cases’) that are meaningful to users (‘actors’) • However, during iterative, incremental development it is expected that models will be incomplete and inconsistent. • example: Make Appointment • use case for the medical clinic • actor is a Patient • connection between actor and use case is a communication association (or communication for short) communication actor make appointment
Patient use case
UNIVERSITY OF MASSACHUSETTS AMHERST • DEPARTMENT OF COMPUTER SCIENCE • CMPSCI 520/620 FALL 2004 UNIVERSITY OF MASSACHUSETTS AMHERST • DEPARTMENT OF COMPUTER SCIENCE • CMPSCI 520/620 FALL 2004
Use-Case diagrams Use Case Modeling: Core Elements
• emphasis is on what a system does rather than Construct Description Syntax how • Use case diagrams are closely connected to use case A sequence of actions, including variants, that a system (or other scenarios UseCaseName entity) can perform, interacting with • a scenario is an example of what happens when actors of the system. someone interacts with the system, e.g., actor A coherent set of roles that users "A patient calls the clinic to make an appointment for of use cases play when interacting a yearly checkup. The receptionist finds the nearest with these use cases. empty time slot in the appointment book and ActorName schedules the appointment for that time slot." system Represents the boundary between • a use case is a summary of scenarios for a single boundary the physical system and the actors task or goal who interact with the physical system. • an actor is who or what initiates the events involved in that task
UNIVERSITY OF MASSACHUSETTS AMHERST • DEPARTMENT OF COMPUTER SCIENCE • CMPSCI 520/620 FALL 2004 UNIVERSITY OF MASSACHUSETTS AMHERST • DEPARTMENT OF COMPUTER SCIENCE • CMPSCI 520/620 FALL 2004
Rick Adrion 2004 (except where noted) 8 CMPSCI520/620 07 Requirements & UML Intro
Use Case Modeling: Core Relationships The ESU University
• wants to computerize their registration system Registrar sets up the curriculum for a semester Construct Description Syntax • • One course may have multiple course offerings association The participation of an actor in a use • students select 4 primary courses and 2 alternate courses case. i.e., instance of an actor and instances of a use case communicate • once a student registers for a semester, the billing system is with each other. notified so the student may be billed for the semester generalization A taxonomic relationship between a • students may use the system to add/drop courses for a more general use case and a more period of time after registration specific use case. extend A relationship from an extension use • professors use the system to receive their course offering case to a base use case, specifying rosters how the behavior for the extension <
Registrar Professor Student Billing System
UNIVERSITY OF MASSACHUSETTS AMHERST • DEPARTMENT OF COMPUTER SCIENCE • CMPSCI 520/620 FALL 2004 UNIVERSITY OF MASSACHUSETTS AMHERST • DEPARTMENT OF COMPUTER SCIENCE • CMPSCI 520/620 FALL 2004
Use Cases Use Case Diagram
• A use case is a pattern of behavior the system exhibits • Use case diagrams are created to visualize the • Each use case is a sequence of related transactions relationships between actors and use cases performed by an actor and the system in a dialogue • Actors are examined to determine their needs • Registrar -- maintain the curriculum • Professor -- request roster Request Course Roster Student Professor • Student -- maintain schedule • Billing System -- receive billing information Maintain Schedule
Maintain Curriculum Request Course Roster Maintain Schedule Maintain Curriculum Registrar Billing System
Copyright © 1997 by Rational Software Corporation Copyright © 1997 by Rational Software Corporation
UNIVERSITY OF MASSACHUSETTS AMHERST • DEPARTMENT OF COMPUTER SCIENCE • CMPSCI 520/620 FALL 2004 UNIVERSITY OF MASSACHUSETTS AMHERST • DEPARTMENT OF COMPUTER SCIENCE • CMPSCI 520/620 FALL 2004
Rick Adrion 2004 (except where noted) 9 CMPSCI520/620 07 Requirements & UML Intro
Documenting Use Cases Maintain Curriculum Flow of Events
• A flow of events document is created for each use • This use case begins when the Registrar logs onto the cases Registration System and enters his/her password. The system verifies that the password is valid (E-1) and prompts • Written from an actor point of view the Registrar to select the current semester or a future • Details what the system must provide to the actor when semester (E-2). The Registrar enters the desired semester. the use cases is executed The system prompts the Registrar to select the desired activity: ADD, DELETE, REVIEW, or QUIT. • Typical contents • If the activity selected is ADD, the S-1: Add a Course • How the use case starts and ends subflow is performed. • Normal flow of events • If the activity selected is DELETE, the S-2: Delete a Course subflow is performed. • Alternate flow of events • If the activity selected is REVIEW, the S-3: Review • Exceptional flow of events Curriculum subflow is performed. • If the activity selected is QUIT, the use case ends. • ...
Maintain Curriculum Copyright © 1997 by Rational Software Corporation Copyright © 1997 by Rational Software Corporation Registrar
UNIVERSITY OF MASSACHUSETTS AMHERST • DEPARTMENT OF COMPUTER SCIENCE • CMPSCI 520/620 FALL 2004 UNIVERSITY OF MASSACHUSETTS AMHERST • DEPARTMENT OF COMPUTER SCIENCE • CMPSCI 520/620 FALL 2004
Documenting use cases Narrative use case specification
• Brief Description Use Case Add a course to the curriculum Actors involved • Brief Description This use case allows a Registrar to enter a new course. • Preconditions necessary for the use case to start … • Detailed Description of flow of events that includes: Actors Registrar • Main Flow of events, that can be broken down to show: Preconditions Registrar has a valid password (E-1), has selected a semester default or E-2), and has selected the Add (S- • Subflows of events (subflows can be further divided into smaller 1) function at the system prompt subflows to improve document readability) • Alternative Flows to define exceptional situations Main Flow The system enters the Add a Course subflow • Postconditions that define the state of the system after the use case ends Alternative Flows The Registrar activates the Delete, Review, or Quit functions Postconditions If the use case was successful, the Registrar has accessed the Add a Course function
UNIVERSITY OF MASSACHUSETTS AMHERST • DEPARTMENT OF COMPUTER SCIENCE • CMPSCI 520/620 FALL 2004 UNIVERSITY OF MASSACHUSETTS AMHERST • DEPARTMENT OF COMPUTER SCIENCE • CMPSCI 520/620 FALL 2004
Rick Adrion 2004 (except where noted) 10 CMPSCI520/620 07 Requirements & UML Intro
Uses and Extends Relationships University Enrollment
• As the use cases are documented, other use case • The university offers relationships may be discovered • Undergraduate and postgraduate degrees • To full-time and part-time students • A uses relationship shows behavior that is common to The university structure one or more use cases • • Divisions containing departments • An extends relationship shows optional behavior • Single division administers each degree • Degree may include courses from other divisions
<
Maintain curriculum MACIASZEK, L.A. (2001): Requirements Analysis and System Design. Developing Information Systems with Copyright © 1997 by Rational Software Corporation UML, Addison Wesley Copyright © 2000 by Addison Wesley
UNIVERSITY OF MASSACHUSETTS AMHERST • DEPARTMENT OF COMPUTER SCIENCE • CMPSCI 520/620 FALL 2004 UNIVERSITY OF MASSACHUSETTS AMHERST • DEPARTMENT OF COMPUTER SCIENCE • CMPSCI 520/620 FALL 2004
University Enrolment (cont) Example 4.12 •Pre-enrolment activities • The system is required to •Mail-outs of •Last semester's examination grades to • Assist in pre-enrolment activities Provide Examination Results students • Handle the enrolment procedures •Enrolment instructions <
Registrar Office MACIASZEK, L.A. (2001): Requirements Analysis and System Design. Developing Information Systems with MACIASZEK, L.A. (2001): Requirements Analysis and System Design. Developing Information Systems with UML, Addison Wesley Copyright © 2000 by Addison Wesley UML, Addison Wesley Copyright © 2000 by Addison Wesley
UNIVERSITY OF MASSACHUSETTS AMHERST • DEPARTMENT OF COMPUTER SCIENCE • CMPSCI 520/620 FALL 2004 UNIVERSITY OF MASSACHUSETTS AMHERST • DEPARTMENT OF COMPUTER SCIENCE • CMPSCI 520/620 FALL 2004
Rick Adrion 2004 (except where noted) 11 CMPSCI520/620 07 Requirements & UML Intro
When to model use cases Use Case Modeling Tips
• Model user requirements with use cases. • Make sure that each use case describes a significant chunk of system usage that is understandable by both domain experts and • Model test scenarios with use cases. programmers • If you are using a use-case driven method • When defining use cases in text, use nouns and verbs accurately and consistently to help derive objects and messages for interaction • start with use cases and derive your structural and diagrams (see Lecture 2) behavioral models from it. • Factor out common usages that are required by multiple use cases • If you are not using a use-case driven method • If the usage is required use <
UNIVERSITY OF MASSACHUSETTS AMHERST • DEPARTMENT OF COMPUTER SCIENCE • CMPSCI 520/620 FALL 2004 UNIVERSITY OF MASSACHUSETTS AMHERST • DEPARTMENT OF COMPUTER SCIENCE • CMPSCI 520/620 FALL 2004
Use Case Realizations sequence diagram
• The use case diagram presents an outside view of the • an interaction diagram that details how operations are carried system out • what messages are sent and when • Interaction diagrams describe how use cases are • are organized according to time realized as interactions among societies of objects • time progresses as you go down the page • Two types of interaction diagrams • objects involved in the operation are listed from left to right • Sequence diagrams according to when they take part in the message sequence. • Collaboration diagrams Symbol Meaning simple message which may be synchronous or asynchronous simple message return (optional) a synchronous message
an asynchronous message
Copyright © 1997 by Rational Software Corporation
UNIVERSITY OF MASSACHUSETTS AMHERST • DEPARTMENT OF COMPUTER SCIENCE • CMPSCI 520/620 FALL 2004 UNIVERSITY OF MASSACHUSETTS AMHERST • DEPARTMENT OF COMPUTER SCIENCE • CMPSCI 520/620 FALL 2004
Rick Adrion 2004 (except where noted) 12 CMPSCI520/620 07 Requirements & UML Intro
Sequence Diagram Example 4.17 – Maciaszek
• A sequence diagram displays object interactions arranged in a time sequence
Enter Program of Study registration registration use case : Student math 101 math 101 form manager section 1
1: fill in info
2: submit
3: add course(mary, math 01)
4: are you open? 5: are you open? 6: add (mary) 7: add (mary)
Copyright © 1997 by Rational Software Corporation
UNIVERSITY OF MASSACHUSETTS AMHERST • DEPARTMENT OF COMPUTER SCIENCE • CMPSCI 520/620 FALL 2004 UNIVERSITY OF MASSACHUSETTS AMHERST • DEPARTMENT OF COMPUTER SCIENCE • CMPSCI 520/620 FALL 2004
Collaboration Diagrams
• also interaction diagrams • focus on object roles instead of the times that messages are sent
course form : 1: set course info CourseForm 2: process
: Registrar 3: add course
theManager : aCourse : Course CurriculumManager 4: new course
UNIVERSITY OF MASSACHUSETTS AMHERST • DEPARTMENT OF COMPUTER SCIENCE • CMPSCI 520/620 FALL 2004
Rick Adrion 2004 (except where noted) 13