Upload
others
View
1
Download
0
Embed Size (px)
Citation preview
CMPSCI520/620
”Rick Adrion 2003 (except where noted) 1
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI 520/620 CI 520/620 FFALL 2003ALL 2003
13 - Requirements Specifications
Rick Adrion
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI 520/620 CI 520/620 FFALL 2003ALL 2003
Software Requirements Specification
ßHow do we communicate the Requirements to others?ßIt is common practice to capture them in an SRSßBut an SRS doesn’t need to be a single paper document
ßPurposeßCommunicates an understanding of the requirementsßexplains both the application domain and the system to bedeveloped
ßContractualßMay be legally binding!ßExpresses an agreement and a commitment
ßBaseline for evaluating subsequent productsßsupports system testing, verification and validation activitiesßshould contain enough information to verify whether thedelivered system meets requirements
ßBaseline for change controlßrequirements change, software evolves
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI 520/620 CI 520/620 FFALL 2003ALL 2003
Audience
ßUsers, PurchasersßMost interested in system requirementsßNot generally interested in detailed softwarerequirements
ßSystems Analysts, Requirements AnalystsßWrite various specifications that interrelateßDevelopers, ProgrammersßHave to implement the requirementsßTestersßDetermine that the requirements have been metßProject ManagersßMeasure and control the analysis and developmentprocesses
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI 520/620 CI 520/620 FFALL 2003ALL 2003
Appropriate Specification
ßConsider two different projects:ßTiny project, 1 programmer, 2 months workßProgrammer talks to customer, then writes up a 5-pagememo
ßLarge project, 50 programmers, 2 years workßTeam of analysts model the requirements, then documentthem in a 500-page SRS
Project A Project BPurpose of spec? Crystalizes programmer’s
understanding; feedback tocustomer
Build-to document; mustcontain enough detail for allthe programmers
Managementview?
Spec is irrelevant; havealready allocatedresources
Will use the spec to estimateresource needs and plan thedevelopment
Readers? Primary: Spec author;Secondary: Customer
Primary: programmers,testers, managers;Secondary: customers
CMPSCI520/620
”Rick Adrion 2003 (except where noted) 2
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI 520/620 CI 520/620 FFALL 2003ALL 2003
What about the SIS RFP/RFB?
ßRFP = ‘SRS’ written by the procurer (or by anindependent RE contractor)ßgeneral enough to yield a good selection of bidsßspecific enough to exclude unreasonable bidsßBidders response to the RFPßspecific enough to demonstrate feasibility and technicalcompetenceßgeneral enough to avoid over-commitmentßSelected developer – more detailed ‘SRS’ßdeveloper’s understanding of the customers needsßbasis for evaluation of contractual performanceßIEEE Standard recommends SRS jointly developed byprocurer and developer
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI 520/620 CI 520/620 FFALL 2003ALL 2003
When to issue RFP/RFB?
ßEarly (conceptual stage)ßCan only evaluate bids on apparent competence &ability
ßLate (detailed specification stage)ßLots of work for the procurerßthe appropriate RE expertise may not be availablein-house!
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI 520/620 CI 520/620 FFALL 2003ALL 2003
Hints & Guidelinesß Validity (or “correctness”)ß expresses only the real needs of
the stakeholders (customers,users,…)
ßCompletenessß specifies all the things the system
must do and all the things it mustnot do!ßConceptual Completenessß e.g. responses to all classes of input
ß Structural Completenessß e.g. no “to be determined” functions
ßConsistencyß not self-contradictoryß satisfiableß all terms used consistentlyß inconsistency can be hard to
detect especially in timing aspectsand business logic
ßNecessaryß doesn’t contain anything that isn’t
“required”
ß Ambiquityß every statement can be read in
exactly one wayß defines confusing termsß e.g. in a glossary
ß Verifiablilityß includes a process exists to test
satisfaction of each requirementß every requirement is specified
behaviorallyßUnderstandablility (Clarity)ß e.g. by non-computer specialistsß technical notations should only be
used as backup (e.g. in anappendix)
ßModifiabilityß easy to change and modifyß good structure and cross-
referencingßmust be kept up to date!
see IEEE-STD-830-1993UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI 520/620 CI 520/620 FFALL 2003ALL 2003
ambiguousambiguous
notunderstandable
notunderstandable
inconsistentinconsistentredundantredundant
incompleteincomplete
formalize
expand
resolve
condense
expand
addexplanations
There is no Perfect SRS
reduce
© Steve Easterbrook 2000-2002
CMPSCI520/620
”Rick Adrion 2003 (except where noted) 3
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI 520/620 CI 520/620 FFALL 2003ALL 2003
Typical mistakesß Noiseß text that carries no relevant
information to any feature of theproblem.
ß Silenceß a feature that is not covered by
any text.ß Over-specificationß text that describes a feature of the
solution, rather than the problem.ß Contradictionß text that defines a single feature in
a number of incompatible ways.ß Ambiguityß text that can be interpreted in at
least two different ways.ß Forward referenceß text that refers to a terms or
features yet to be defined.ß Wishful thinkingß text that defines a feature that
cannot possibly be validated.
ß Jigsaw puzzlesß distributing key information across
a document and then cross-referencing
ß Duckspeak requirementsß requirements that are only there to
conform to standardsß Unnecessary invention of terminologyß e.g. ‘user input presentation
function’ß e.g. ‘airplane reservation data
validation function’ß Inconsistent terminologyß inventing and then changing
terminologyß Putting the onus on the development
staffß i.e. making the reader work hard to
decipher the intentß Writing for the hostile readerß fewer of these than friendly
readers
from Steve Easterbrook © 2000-2002; he Adapted from Kovitz, 1999
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI 520/620 CI 520/620 FFALL 2003ALL 2003
Use Appropriate Notations
ßNatural Language?ß“The system shall report to the operator all faults thatoriginate in critical functions or that occur duringexecution of a critical sequence and for which there is nofault recovery response.”ß(adapted from a real NASA spec for the international spacestation)
ßA decision table?
ßUse cases?
Originate in critical functions F T F T F T F TOccur during critical seqeunce F F T T F F T TNo fault recovery response F F F F T T T TReport to operator?
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI 520/620 CI 520/620 FFALL 2003ALL 2003
SRS using a UML “package” construct
ßmay include a single document, multiple documents, usecase specifications and even the graphical use case modelwhich describes relationships amongst the use cases. ßcontrols the evolution of the system throughout the
development and release phases of the project
Probasco and Leffingwell
Rational Software
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI 520/620 CI 520/620 FFALL 2003ALL 2003
SRS using a UML “package” construct
ß the following use the SRS Package:ßThe system analyst creates and maintains the Vision, the use-case model overview and supplementary specifications, whichserve as input to the SRS and are the communication mediumbetween the system analyst, the customer, and otherdevelopers.ßThe use-case specifier creates and maintains the individualuse cases of the use-case model and other components of theSRS package,ßDesigners use the SRS Package as a reference whendefining responsibilities, operations, and attributes on classes,and when adjusting classes to the implementationenvironment.ßImplementers refer to the SRS Package for input whenimplementing classes.ßThe project manager refers to the SRS Package for inputwhen planning iterations.ßThe testers use the SRS Package to verify systemcompliance.
CMPSCI520/620
”Rick Adrion 2003 (except where noted) 4
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI 520/620 CI 520/620 FFALL 2003ALL 2003
SRS format and style
ßModifiabilityßwell-structured, indexed, cross-referenced, etc.
ßredundancy should be avoided or must be clearlymarked as such
ß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 ofthe design that satisfy it
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI 520/620 CI 520/620 FFALL 2003ALL 2003
SRS format and style
ßTraceability links are two-wayßother documents will be traced into the SRSßevery requirement must have a unique label.ßa given term, acronym, or abbreviation means the samething in all documentsßa given item or concept is referred to by the same nameor description in the documents
ßIn short:ßdemonstration of completeness, necessity andconsistencyßclear allocation/flowdown path (down through thedocument hierarchy)ßa clear derivation path (up through the documenthierarchy)
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI 520/620 CI 520/620 FFALL 2003ALL 2003
1. Introductionß Purposeß Scopeß Definitions, acronyms, abbreviationsß Reference documentsß Overview
2. Overrall Descriptionß Product perspectiveß Product functionsß User characteristicsß Constraintsß Assumptions and Dependencies
3. Specific Requirements Appendices Index
1. Introductionß Purposeß Scopeß Definitions, acronyms, abbreviationsß Reference documentsß Overview
2. Overrall Descriptionß Product perspectiveß Product functionsß User characteristicsß Constraintsß Assumptions and Dependencies
3. Specific Requirements Appendices Index
IEEE Standard for SRS
Anything that will limit the developer’s options (e.g. regs, reliability, criticality, hardware limitations, parallelism, etc)
Summary of major functions, e.g. use cases
All the requirements go in here (i.e.this is the body of the document)IEEE STD provides 8 different templates for this section
Identifies the product & application domain
Describes contents and structure of the remainder of the SRS
Describes all external interfaces: system, user, hardware, software;also operations and site adaptation,and hardware constraints
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI 520/620 CI 520/620 FFALL 2003ALL 2003
IEEE std offers different templatesßExternal stimulus or external situationße.g., for an aircraft landing system, each different type of landing
situation: wind gusts, no fuel, short runway, etcßSystem featureße.g., for a telephone system: call forwarding, call blocking,
conference call, etcßSystem responseße.g., for a payroll system: generate pay-cheques, report costs, print
tax info;ßExternal objectße.g. for a library information system, organize by book type
ßUser typeße.g. for a project support system: manager, technical staff,
administrator, etc.ßModeße.g. for word processor: page layout mode, outline mode, text editing
mode, etcßObjectße.g., in a patient monitorng system, objects include patients, sensors,
nurses, rooms, physicians, medicines, etc.
CMPSCI520/620
”Rick Adrion 2003 (except where noted) 5
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI 520/620 CI 520/620 FFALL 2003ALL 2003
Template of SRS 3 organized by object
3. Specific requirements3.1 External interface requirements3.1.1 User interfaces3.1.2 Hardware interfaces3.1.3 Software interfaces3.1.4 Communications interfaces3.2 Classes/Objects3.2.1 Class/Object 13.2.1.1 Attributes (direct or inherited)3.2.1.1.1 Attribute 1…3.2.1.1.n Attribute n3.2.1.2 Functions (services, methods, direct or inherited)3.2.1.2.1 Functional requirement 1.1…3.2.1.2.m Functional requirement 1.m3.2.1.3 Messages (communications received or sent)3.2.2 Class/Object 2…3.2.p Class/Object p3.3 Performance requirements3.4 Design constraints3.5 Software system attributes3.6 Other requirements
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI 520/620 CI 520/620 FFALL 2003ALL 2003
Maciaszek vs. IEEE
1. Introductionß Purposeß Scopeß Definitions, acronyms, abbreviationsß Reference documentsß Overview
2. Overrall Descriptionß Product perspectiveß Product functionsß User characteristicsß Constraintsß Assumptions and Dependencies
3. Specific Requirements Appendices Index
1. Introductionß Purposeß Scopeß Definitions, acronyms, abbreviationsß Reference documentsß Overview
2. Overrall Descriptionß Product perspectiveß Product functionsß User characteristicsß Constraintsß Assumptions and Dependencies
3. Specific Requirements Appendices Index
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI 520/620 CI 520/620 FFALL 2003ALL 2003
Requirements Negotiation & Validation
ßNegotiationßBased on draft of document
ßValidationßBased on (almost) complete document
ßIssuesßScope
ßDependencies
ßRisks
ßPriorities
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI 520/620 CI 520/620 FFALL 2003ALL 2003
System scope model
Ticket Placement
Outcome
Conversation
Ticket Order
Supporter Details
Campaign Details 0
Telemarketing
Order Processing
Supporter Database
SupporterCampaign Database
CMPSCI520/620
”Rick Adrion 2003 (except where noted) 6
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI 520/620 CI 520/620 FFALL 2003ALL 2003
Business use case model
Schedule Phone Conversation
CRUD* Campaignand Supporter DetailsTelemarketer
Enter ConversationOutcome
Supporter
CRUD* - create, read, update, delete
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI 520/620 CI 520/620 FFALL 2003ALL 2003
Requirements dependency matrix
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI 520/620 CI 520/620 FFALL 2003ALL 2003
Requirements risks
ßTechnical
ßPerformance
ßDatabase integrity
ßDevelopment process
ßPolitical
ßLegal
ßVolatility
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI 520/620 CI 520/620 FFALL 2003ALL 2003
Credits
ßMany of the following are derived from:ßKenneth M. Anderson © University of Colorado, 2003
ßMaciaszek Requirements Analysis and SystemDesign © Addison Wesley, 2000
CMPSCI520/620
”Rick Adrion 2003 (except where noted) 7
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI 520/620 CI 520/620 FFALL 2003ALL 2003
Requirements Specification
ßThree types of modelsßState ModelsßUse Cases (some actors become classes)ßClass DiagramsßBehavior ModelsßActivity DiagramßInteraction Diagrams
ßState Change ModelsßState Chart Diagrams
ß Models are developed iterativelyßaccounting for use cases and constraints developedduring requirements elicitationßeach representing a view into the systemßtaken together, the models allow developers andcustomers to view the system from multipleperspectives
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI 520/620 CI 520/620 FFALL 2003ALL 2003
State specifications
ßThe state of an object is determined by the values of itsattributes and associationsßA BankAccount may be “overdrawn” when its balance isnegative
ßSince object states are determined from data structures,the models of the data structures (e.g. classes) arecalled state specificationsßState specifications provide a static view of the systemßThe attributes and associations of classes do notchange dynamically
ßThe main task is to specify the classes of an applicationdomainßonly attributes and associations; operations are derivedfrom the behavior specification
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI 520/620 CI 520/620 FFALL 2003ALL 2003
State Specification
ßDefine entity classesßPersistent classes in the application domain
ßProcess is highly dependent on the analyst’sß knowledge of class modeling
ß understanding of the application domain
ß experience with similar and successful designs
ß ability to think forward and predict consequences willingness to revise the model iteratively
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI 520/620 CI 520/620 FFALL 2003ALL 2003
Discovering Classes
ß Four Approachesß Noun Phrase Approach
ß Common Class Patterns
ß Use Case Driven
ß CRC (Class-Responsibility-Collaboration)
CMPSCI520/620
”Rick Adrion 2003 (except where noted) 8
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI 520/620 CI 520/620 FFALL 2003ALL 2003
Noun Phrase Approach
ß Examine the requirements and underline each nounß Each noun is a candidate class
ß Divide list of candidate classes intoß Relevant Classesß Part of the application domain; occur frequently in reqs
ß Irrelevant Classesß Outside of application domain
ß Fuzzy Classesß Unable to be declared relevant with confidence; requireadditional analysis
ß Experience will eventually enable designers to avoidgenerating irrelevant classes
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI 520/620 CI 520/620 FFALL 2003ALL 2003
Fuzzy
Find Classes from requirements
ßConsider Maciaszek’s University Enrollmentsystem:ßeach university major has a number ofcompulsory courses and a number of electivecourses.
Major
Course
ElectiveCourse
CompulsoryCourse
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI 520/620 CI 520/620 FFALL 2003ALL 2003
University Enrolment - Maciaszek
ßMore requirements:
ßA course can be part of any number of majors
ßEach major specifies minimum total credits required
ßStudents may combine course offerings into programs
of study suited to their individual needs and leading to
the degree/major in which enrolled
CourseOffering
SudyprogramStudent
ElectiveCourseMajor
CompulsoryCourseCourse
Fuzzy classesRelevant classes
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI 520/620 CI 520/620 FFALL 2003ALL 2003
Noun Phrase Approach
ßmay help in identifying domain objects
ßnot good at identifying objects that live in theapplication domainßThus, it can help at the beginning of analysis, but youwill not return to it as you move into design
ßFinding good objects during design means identifyingabstractions that are part of your application domain andits execution machinery
ßObjects that are part of your application domain will havea tenuous connection, at best, to real-world thingsße.g. what’s the correspondence of a scrollbar to the realworld
CMPSCI520/620
”Rick Adrion 2003 (except where noted) 9
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI 520/620 CI 520/620 FFALL 2003ALL 2003
Common Class Patterns
ß Derive classes from the generic classificationtheory of objectsß Concept classßa notion shared by a large community
ß Events classßcaptures an event that demarks intervals within a system
ß Organization classßa collection or group within the domain
ßPeople classßroles people can play
ßPlaces classßa physical location relevant to thesystem
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI 520/620 CI 520/620 FFALL 2003ALL 2003
Common Class Patterns
ß Rumbaugh proposes a different schemeß Physical Class (Airplane)
ß Business Class (Reservation)
ß Logical Class (FlightTimeTable)
ß Application Class (ReservationTransaction)
ß Computer Class (Index)
ß Behavioral Class (ReservationCancellation)
ß These taxonomies are meant to help a designer think ofclasses, however it is difficult to be systematic
ß Probably only useful during early analysis
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI 520/620 CI 520/620 FFALL 2003ALL 2003
Copyright © 1997 by Rational Software Corporation
Registrar
Professor
Billing System
Student
Maintain Schedule
Maintain Curriculum
Request Course Roster
Use Case Diagram
ßUse case diagrams are created to visualize therelationships between actors and use cases
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI 520/620 CI 520/620 FFALL 2003ALL 2003
Copyright © 1997 by Rational Software Corporation
: Studentregistration
formregistration
managermath 101
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)
math 101 section 1
Sequence Diagram
ßA sequence diagram displays object interactionsarranged in a time sequence
CMPSCI520/620
”Rick Adrion 2003 (except where noted) 10
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI 520/620 CI 520/620 FFALL 2003ALL 2003
Copyright © 1997 by Rational Software Corporation
Professor
ScheduleAlgorithm
: Studentregistration
formregistration manager
math 101
1: fill in info
2: submit
3: add course(mary, math 01)
4: are you open?
5: are you open?
6: add (joe)7: add (mary)
math 101 section 1
RegistrationForm RegistrationManager
Student
CourseOffering
Course
Classes
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI 520/620 CI 520/620 FFALL 2003ALL 2003
Maciaszek’s Guidelines
ß Each class must have a statement of purpose in thesystem
ß Each class is a template for a set of objectsß avoid singleton classes
ß Each class must house a set of attributes
ß Each class should be distinguished from an attributeße.g. Color may be an attribute of a Car class, but may beneeded as a full class in a paint program
ß Each class houses a set of operations that representsthe interface of the classßoperations can be derived from the statement ofpurpose
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI 520/620 CI 520/620 FFALL 2003ALL 2003
CRC Cards
ß CRC = Candidates, Responsibilities, Collaborators
ß Meant primarily as a brainstorming tool for analysis anddesign
ß In place of use diagrams fi use index cards
ß In place of attributes and methods fi recordresponsibilities
ßSee Object Design by Wirfs-Brock and McKean, ©2003
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI 520/620 CI 520/620 FFALL 2003ALL 2003
Index Cards
ß On the unlined side of theindex cardßwrite an informaldescription of eachcandidate class’ purposeand role
ßOn the lined side of theindex cardß identify responsibilities andcollaborators
DocumentPurpose: A Document acts as a container for graphicsand textRole: ContainerPattern: Composite text,graphics, other
elements
Inserts and removes
Knows storage location
TextFlowKnows contents
¨candidateDocument
responsibilities collaborators
CMPSCI520/620
”Rick Adrion 2003 (except where noted) 11
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI 520/620 CI 520/620 FFALL 2003ALL 2003
Not Just Index Cards
ß Post-It Notes can be used for even less “structure”;ßmight be easier when brainstorming
DocumentPurpose: A document Represents a containerthat holds text and/orgraphics that the user can enter and visually arrange on pages
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI 520/620 CI 520/620 FFALL 2003ALL 2003
Why index cards?
ß Forces you to be concise and clear and focus on majorresponsibilities since you must fit everything onto oneindex card
ß Inherent Advantagesß cheap, portable, readily available, and familiar
ß Affords Spatial Semantics…
ß Close collaborators can be overlapped
ß Vertical dimension can be assigned meanings
ß Abstract classes and specializations can form piles …which provides benefits
ß Beck and Cunningham report that they have seendesigners talk about a new card by pointing at where itwill be placed
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI 520/620 CI 520/620 FFALL 2003ALL 2003
University Enrolment - Maciaszekß A student's choice of courses may be restricted by timetable clashes and by
limitations on the number of students who can be enrolled in the currentcourse offering.ß A student's proposed program of study is entered on on-line enrolment
system SPIREß The system checks the program's consistency and reports any problemsß The problems need to be resolved with the help of an academic adviserß The final program of study is subject to academic approval by the
Department head (or delegate) and it is then forwarded to the Registrarß The student's academic record to be available on demandß The record to include information about the student’s grades in each course
that the student enrolled in (and has not withdrawn without penalty)ß Each course has one professor in charge of a course, but additional
professors (inc instructors) may also teach in itß There may be a different professor in charge of a course each semesterß There may be professor for each course each semester
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI 520/620 CI 520/620 FFALL 2003ALL 2003
University Enrolment - Maciaszek
ßMore requirements:
CourseOffering
StudyprogramStudent
ElectiveCourseMajor
CompulsoryCourseCourse
Fuzzy classesRelevant classes
CMPSCI520/620
”Rick Adrion 2003 (except where noted) 12
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI 520/620 CI 520/620 FFALL 2003ALL 2003
Specifying Attributes
ß Attributes are specified in parallel withclasses initial set of attributes will be “obvious” important to initially select attributes that help todetermine the states of the class additional attributes can be added in subsequentiterations
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI 520/620 CI 520/620 FFALL 2003ALL 2003
AcademicRecord
course_code : Stringyear : Datesemester : Integergrade : String
Course<<PK>> course_code : String<<CK>> course_name : Stringcredit_points : Integer
ProfessorinCharge
Student<<PK>> student_id : Stringstudent_name : Stringcurrent_fees : Money
CourseOffering
year : Datesemester : Integerenrolment_quota : Integer
0..1
Maciaszek Solution
StudyProgramyear : Datesemester : Integer
Major<<PK>> major_iname : Stringtotal_credit_points : Integer
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI 520/620 CI 520/620 FFALL 2003ALL 2003
Specifying Associations
ß Associations connect objects in the systemß they facilitate collaboration between objects
ß Specifying associations involvesß naming them
ß naming the rolesß especially useful in self associations
ß note, a role name becomes an attribute in the class onthe opposite end of the association
ß determining multiplicity
ß What associations might we put into theUniversity example?
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI 520/620 CI 520/620 FFALL 2003ALL 2003
Specifying Aggregation/Composition
ß “Whole-part” relationships between composite andcomponent classesß UML models aggregation as a constrained form ofassociation
ß Maciaszek suggests additional powerß ExclusiveOwns and Owns
ß Has and Member
ß Litmus test: “has” or “is-part-of” is needed toexplain relationship
CMPSCI520/620
”Rick Adrion 2003 (except where noted) 13
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI 520/620 CI 520/620 FFALL 2003ALL 2003
AcademicRecord
course_code : Stringyear : Datesemester : Integergrade : String
Course<<PK>> course_code : String<<CK>> course_name : Stringcredit_points : Integer
ProfessorinCharge
Student
<<PK>> student_id : Stringstudent_name : Stringcurrent_fees : Money
0..*0..*CourseOffering
year : Datesemester : Integerenrolment_quota : Integer
0..*0..*
0..*
0..1
0..*
0..1
*
* takes
*
*
takes_crsoff
has_stud
Maciaszek Solution
Student and AcademicRecord participate in a composition
relationship
a Course aggregates its various CourseOfferings
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI 520/620 CI 520/620 FFALL 2003ALL 2003
Specifying Generalizations
ß Looking for common features among classesß Move common features up a class hierarchy andspecialized features down
ß Apart from inheritance, generalization hastwo objectivesß substitutability and polymorphism
ß Litmus test: “can be” and “is-a-kind-of” required toexplain relationship
ß Are there any generalizations that we can make in theUniversity example?
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI 520/620 CI 520/620 FFALL 2003ALL 2003
Behavior Specifications (I)
ßBehavior of a system, as it appears to an outside user,is specified in use casesßDuring analysis, use cases specify “what” a systemneeds todo (not “how”)
ßUse cases require computations to be performed
ßComputations are divided into activitiesßcan be modeled using activity diagrams
ßActivities are carried out by interacting objectsßinteractions are modeled using sequence diagrams
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI 520/620 CI 520/620 FFALL 2003ALL 2003
Behavior Specifications (II)
ßProvide an operational view of the system
ßMain TasksßDefine use cases and determine which classes are usedto execute a use case
ßIdentify operations on classes
ßState specifications in analysis typically reveal entityclasses
ßBehavior specifications will often reveal controllerclasses and boundary classes (user interface classes)
CMPSCI520/620
”Rick Adrion 2003 (except where noted) 14
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI 520/620 CI 520/620 FFALL 2003ALL 2003
Maciaszek’s Take: Use Cases
ßA use case representsßa complete piece of functionalityß including main and alternate flows of logic
ßa piece of externally visible functionality
ßan orthogonal piece of functionalityßuse cases can share objects but execute independentlyfrom each other
ßa piece of functionality initiated by an actor
ßa piece of functionality that delivers value to anactor
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI 520/620 CI 520/620 FFALL 2003ALL 2003
Finding Use Cases
ßUse cases are discovered via analysis ofßrequirements in the requirements documents
ßactors and their purpose
ßJacobson suggests asking the following questionsconcerning actors to help identify use casesßWhat are the main tasks performed by the actor
ßWill an actor access or modify information in the system
ßWill an actor inform the system about changes in othersystems?
ßShould an actor be informed about unexpected changes inthe system?
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI 520/620 CI 520/620 FFALL 2003ALL 2003
Use Case Relationships
ßAssociationßa communication path
ßGeneralizationßa specialized use case can change any aspect of the baseuse case
ß Includeßdirectly includes steps of another use case
ßExtendßcustomize an extension point
ßSee (poor) example on page 137 for the UniversityEnrollment case studyin general, the material from Lecture 9 and 10 supercedesany use case material provided by MaciaszekFebruary 20, 2003 © University of Colorado, 2003 9
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI 520/620 CI 520/620 FFALL 2003ALL 2003
Example 4.12
Provide Enrolment Instructions
Student Office
Provide Examination Results
Student
Pre-enrolment activitiesßMail-outs of
ßLast semester's examination grades tostudentsßEnrolment instructions
<<extend>>
Data Entry Person
Enter Program of Study
Registrar Office
Validate Program of Study
ßDuring enrolmentßAccept students'proposed programs ofstudyßValidate
<<include>>
CMPSCI520/620
”Rick Adrion 2003 (except where noted) 15
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI 520/620 CI 520/620 FFALL 2003ALL 2003
Better Example
Enroll Student
Student
<<extend>>
<<include>>
Enroll in Seminar
Enroll Family MemberEnroll International StudentInternational Student
invokes, not dataflow
logic included
logic may be includedgeneralization
generalization
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI 520/620 CI 520/620 FFALL 2003ALL 2003
Modeling Activities
ßActivities capture the flow of logic within a systemßboth sequential and parallel control can be modeled
ßSince activities do not reference classes, they can becreated without the need for a class diagram
ßMost often used to graphically represent the steps ofa use caseßcan show main flow and extensions at once
ßActivities are best discovered by analyzing the actionsteps of use cases, with verbs indicating candidateactivities
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI 520/620 CI 520/620 FFALL 2003ALL 2003
University enrollment example
Scott W. Ambler , Copyright 2003 www.agilemodeling.com/
Fill outforms
Enroll inUniversity
[correct]
[incorrect]
Enrolling inUniversity forfirst time
Obtain help
on forrms
AttendUniversityOverview
Enroll inSeminar
Pay Tuition
& Fees
[trivial problem]
[otherwise]
[help available]
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI 520/620 CI 520/620 FFALL 2003ALL 2003
Modeling Interactions
ßOne level of abstraction below activities
ß Interaction models require at least one iteration ofstate specification to be performed
ßSince we need to have classes to which each object belongs
ß Interaction diagrams do not model object statechanges; however they may show the actions thatlead to a state change
ß Interactions can help determine operations; anymessage to an object in a interaction must behandled by an operation (actually a method)ßRecall that a method implements an operation; indeed theremay be many methods available for a single operation
CMPSCI520/620
”Rick Adrion 2003 (except where noted) 16
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI 520/620 CI 520/620 FFALL 2003ALL 2003
Discovering Message Sequences
ßThe sequence of messages in an interaction isdetermined by its associated activity (from the activitydiagram)ßThe event that starts the activity is the first message inthe interaction
ßThe event that ends the activity is the last message inthe interaction
ßWe need to figure out what occurs in between; typicallystraightforward
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI 520/620 CI 520/620 FFALL 2003ALL 2003
Specifying message sequences
ßUseful to distinguish betweenßsignalsßasynchronous inter-object communication
ßoften shown with “half-arrow notation”
ßCallsßsynchronous inter-object communication control returns tocaller (usually)
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI 520/620 CI 520/620 FFALL 2003ALL 2003
Sequence Diagram
Student<actor>
EnrollinSeminar<controller>
SecurityLogIn<UI>
Seminar
theStudent:Student
provides name
<<create>>wish to enroll
provides student id
<<destroy>>
isValid(name, number)
yes
getAvailableSeminar():vectorX
Scott W. Ambler , Copyright 2003 www.agilemodeling.com/
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI 520/620 CI 520/620 FFALL 2003ALL 2003
Defining Operations
ßA public interface of a class consists of operations thatoffer services to entities external to the classßoperations are best discovered from sequencediagrams,since every message must be serviced by an operation
ßOther operations can be found using the CRUD (create,read, update, delete) paradigm; classes need to providethese services regardless of their domain specificfunctionality
Course<<PK>>course_code:string<<CK>>course_name:stringcredit_points: integercrs_off: set<CourseOffering>areYouOpen(out c_check)addStudent(stdOID)
CourseOfferingyear:Datesemester:integerenrollment_quota:integerstd: list<Student>crs: CourseareYouOpen(out c_check)addStudent(stdOID)
CMPSCI520/620
”Rick Adrion 2003 (except where noted) 17
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI 520/620 CI 520/620 FFALL 2003ALL 2003
Example 4.17 – Maciaszek
Enter Program of Studyuse case
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI 520/620 CI 520/620 FFALL 2003ALL 2003
Example 4.17 – Maciaszek
Enter Program of Studyuse case
Course<<PK>>course_code:string<<CK>>course_name:stringcredit_points: integercrs_off: set<CourseOffering>areYouOpen(out c_check)addStudent(stdOID)
CourseOfferingyear:Datesemester:integerenrollment_quota:integerstd: list<Student>crs: CourseareYouOpen(out c_check)addStudent(stdOID)
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI 520/620 CI 520/620 FFALL 2003ALL 2003
State Change Specifications
ßDefines how an object changes state over time inresponse to particular eventsßStates are discovered by analyzing the values ofattributes and determining which have special interest touse cases
ße.g., having or not having a phone number is a state fora customer; the specific value of the phone number isirrelevant to the state