Requirements Specification - Department of...
Transcript of Requirements Specification - Department of...
MACIASZEK, L.A. (2005): Requirements Analysis and System Design, 2nd ed.
Addison Wesley, Harlow England, 504p.ISBN 0 321 20464 6
Chapter 4 Requirements Specification
© Pearson Education Limited 2005
© Pearson Education 2005© Pearson Education 2005 Chapter 4 (Maciaszek Chapter 4 (Maciaszek -- RASD 2/e)RASD 2/e) 22
TopicsTopics
Architectural prerogatives
• BCED in RASD 1ed → PCMEF in RASD 2ed
State specifications
Behavior specifications
State change specifications
© Pearson Education 2005© Pearson Education 2005 Chapter 4 (Maciaszek Chapter 4 (Maciaszek -- RASD 2/e)RASD 2/e) 33
Architectural designArchitectural designDesign• detailed• architectural
Object dependencies → complexity and supportabilityArchitectural model• hierarchical layers• restrictions on object inter-communications
RASD 1/e → BCED (boundary, control, entity, database)RASD 2/e → PCMEF (presentation, control, mediator, entity, foundation)
© Pearson Education 2005© Pearson Education 2005 Chapter 4 (Maciaszek Chapter 4 (Maciaszek -- RASD 2/e)RASD 2/e) 44
PCMEF frameworkPCMEF framework<<subsystem>>presentation
<<subsystem>>control
<<subsystem>>mediator
<<subsystem>>foundation
<<subsystem>>entity
© Pearson Education 2005© Pearson Education 2005 Chapter 4 (Maciaszek Chapter 4 (Maciaszek -- RASD 2/e)RASD 2/e) 55
PCMEF subsystemsPCMEF subsystemsThe presentation subsystem
• classes that handle the graphical user interface (GUI) and assist in human-computer interactions.
The control subsystem • classes capable to understand what program logic is
–– searching for information in entity objectssearching for information in entity objects–– asking the mediator layer to bring entity objects to memory fromasking the mediator layer to bring entity objects to memory from the database.the database.
The entity subsystem • manages business objects currently in memory• container classes • containers are linked
The mediator subsystem • mediates between entity and foundation subsystems to ensure that
control gets access to business objects• manages the memory cache and synchronizes the states of business
objects between memory and the databaseThe foundation subsystem
• classes that know how to talk to the database• produces SQL to read and modify the database
© Pearson Education 2005© Pearson Education 2005 Chapter 4 (Maciaszek Chapter 4 (Maciaszek -- RASD 2/e)RASD 2/e) 66
Architectural principlesArchitectural principlesDDP – downward dependency principle
UNP – upward notification principle
NCP – neighbor communication principle
APP – acquaintance package principle
EAP – explicit association principle
CEP – cycle elimination principle
CNP – class naming principle
© Pearson Education 2005© Pearson Education 2005 Chapter 4 (Maciaszek Chapter 4 (Maciaszek -- RASD 2/e)RASD 2/e) 77
DDP, UNP, NCPDDP, UNP, NCPDDP • higher PCMEF layers depend on lower layers• lower layers should be designed to be more
stableUNP • upward communication that minimizes object
dependencies• lower layers rely on interfaces and event
processing (publisher/subscriber protocols) to communicate with objects in higher layers
NCP • objects can communicate across layers only by
using direct neighbors• chains of message passing
© Pearson Education 2005© Pearson Education 2005 Chapter 4 (Maciaszek Chapter 4 (Maciaszek -- RASD 2/e)RASD 2/e) 88
APP, EAP, CEP, CNPAPP, EAP, CEP, CNPAPP
• separate layer of interfaces to support more complex object communication under strict supportability guidelines
• subsystem of interfaces only–– other objects in the system can use these interfaces, and pass tother objects in the system can use these interfaces, and pass them in hem in
arguments to method calls, instead of concrete objects arguments to method calls, instead of concrete objects →→ classes in nonclasses in non--neighboring subsystems can communicate without knowing the concrneighboring subsystems can communicate without knowing the concrete ete suppliers of services (and, therefore, without creating dependensuppliers of services (and, therefore, without creating dependencies on cies on concrete classes). concrete classes).
EAP • legitimizes run-time object communication in compile-time data
structures.CEP
• cyclic dependencies, between classes and other structures (methods, packages, subsystems)
• unavoidable, but can be neutralized –– extra classes to reduce a network of calls to a hierarchy extra classes to reduce a network of calls to a hierarchy –– purposeful use of interfacespurposeful use of interfaces
CNP• name of each class and each interface in the system should identify the
subsystem/package layer to which it belongs• ensuring that each class begins with a single letter identifying the PCMEF
layer (i.e. P, C, etc.)–– EVideoEVideo means that the class is in the entity subsystemmeans that the class is in the entity subsystem–– IMVideoIMVideo means that the interface is in the mediator subsystem.means that the interface is in the mediator subsystem.
© Pearson Education 2005© Pearson Education 2005 Chapter 4 (Maciaszek Chapter 4 (Maciaszek -- RASD 2/e)RASD 2/e) 99
State specificationsState specificationsObject state is determined by the values of
its attributes and associations
State specification:
• Model of data structures
• Static view on the system
• Class operations left out in initial specs
• Emphasis on entity classes (“business objects”)
© Pearson Education 2005© Pearson Education 2005 Chapter 4 (Maciaszek Chapter 4 (Maciaszek -- RASD 2/e)RASD 2/e) 1010
Modeling classesModeling classesCornerstone of OO development – a system
is a set of collaborating (and classified)
objects
Iterative and incremental process
CASE tool
• For collaborative development
• For personal productivity otherwise
© Pearson Education 2005© Pearson Education 2005 Chapter 4 (Maciaszek Chapter 4 (Maciaszek -- RASD 2/e)RASD 2/e) 1111
Discovering classesDiscovering classesNo two analysts will come up with the identical class models for the same application domain
Discovering classes
• Noun phrase
• Common class patterns
• Use case driven
• CRC
• Mixed
© Pearson Education 2005© Pearson Education 2005 Chapter 4 (Maciaszek Chapter 4 (Maciaszek -- RASD 2/e)RASD 2/e) 1212
Noun phrase approachNoun phrase approachNouns considered candidate classes
Three kinds of candidate classes
• Irrelevant (can be skipped)
• Relevant
• Fuzzy
Assumes that the Requirements Document
is complete and correct
© Pearson Education 2005© Pearson Education 2005 Chapter 4 (Maciaszek Chapter 4 (Maciaszek -- RASD 2/e)RASD 2/e) 1313
Common class pattern approachCommon class pattern approachDerives candidate classes from the classification theory of objectsOne possible classification pattern:• Concept (e.g. Reservation)• Event (e.g. Arrival)• Organization (e.g. Department)• People (e.g. Passenger)• Place (e.g. TravelOffice)
Just a guidanceOnly loosely bound to user requirementsPossible naming misinterpretations
© Pearson Education 2005© Pearson Education 2005 Chapter 4 (Maciaszek Chapter 4 (Maciaszek -- RASD 2/e)RASD 2/e) 1414
Use case driven approachUse case driven approachAssumes that:• Use Case Diagrams (and possibly some high-
level Sequence Diagrams) have been developed
• Narrative descriptions for each use case exist
Similar to the noun phrase approach
Function-driven (problem-driven)
Relies on the completeness of use case models
© Pearson Education 2005© Pearson Education 2005 Chapter 4 (Maciaszek Chapter 4 (Maciaszek -- RASD 2/e)RASD 2/e) 1515
CRC approachCRC approachCRC – classes, responsibilities, collaboratorsMore than a technique for class discoveryAnimated brainstorming sessionsIdentifies classes from the analysis of how objects collaborate to perform business functions (use cases)Suitable also for:• Verification of classes discovered with other
methods• Determination of class properties
© Pearson Education 2005© Pearson Education 2005 Chapter 4 (Maciaszek Chapter 4 (Maciaszek -- RASD 2/e)RASD 2/e) 1616
Mixed approachMixed approachPerhaps with elements of all four previous approachesMiddle-out rather than top-down or bottom-upOne possible scenario:• Initial classes – domain knowledge• Common class patterns approach to guide• Noun phrase approach to add more classes• Use case approach to verify• CRC to brainstorm
© Pearson Education 2005© Pearson Education 2005 Chapter 4 (Maciaszek Chapter 4 (Maciaszek -- RASD 2/e)RASD 2/e) 1717
Guidelines for class discoveryGuidelines for class discoveryStatement of purpose
Description for a set of objects• Singleton classes
Houses a set of attributes• Identifying attributes - keys
• OID
Class or attribute?
Houses a set of operations (what does the class do?)
© Pearson Education 2005© Pearson Education 2005 Chapter 4 (Maciaszek Chapter 4 (Maciaszek -- RASD 2/e)RASD 2/e) 1818
Example 4.1 Example 4.1 –– University EnrolmentUniversity EnrolmentConsider the following requirements for the University Enrolment system and identify the candidate classes:• Each university degree has a number of
compulsory courses and a number of elective courses.
DegreeCourse
CompulsoryCourseElectiveCourse
Relevant Fuzzy
© Pearson Education 2005© Pearson Education 2005 Chapter 4 (Maciaszek Chapter 4 (Maciaszek -- RASD 2/e)RASD 2/e) 1919
Example 4.1 Example 4.1 –– University EnrolmentUniversity EnrolmentMore requirements:• Each course is at a given level and has a credit-
point value
• A course can be part of any number of degrees
• Each degree specifies minimum total credit points value required for degree completion
• Students may combine course offerings into programs of study suited to their individual needs and leading to the degree in which enrolled
© Pearson Education 2005© Pearson Education 2005 Chapter 4 (Maciaszek Chapter 4 (Maciaszek -- RASD 2/e)RASD 2/e) 2020
Example 4.1Example 4.1–– University Enrolment (solution)University Enrolment (solution)
CourseOffering
SudyprogramStudent
ElectiveCourseDegree
CompulsoryCourseCourse
Fuzzy classesRelevant classes
© Pearson Education 2005© Pearson Education 2005 Chapter 4 (Maciaszek Chapter 4 (Maciaszek -- RASD 2/e)RASD 2/e) 2121
Example 4.2 Example 4.2 –– Video StoreVideo StoreConsider the following requirements for the Video Store system and identify the candidate classes:The video store keeps in stock an extensive library of current and popular movie titles. A particular movie may be held on video tapes or disks.
MovieTitleVideoTapeVideoDisk
VideoStoreStockLibrary
Relevant Irrelevant
© Pearson Education 2005© Pearson Education 2005 Chapter 4 (Maciaszek Chapter 4 (Maciaszek -- RASD 2/e)RASD 2/e) 2222
Example 4.2 Example 4.2 –– Video StoreVideo StoreMore requirements:• Video tapes are in either "Beta" or "VHS" format• Video disks are in DVD format• Each movie has a particular rental period
(expressed in days), with a rental charge to that period
• The video store must be able to immediately answer any inquiries about a movie's stock availability and how many tapes and/or disks are available for rental
• The current condition of each tape and disk must be known and recorded
© Pearson Education 2005© Pearson Education 2005 Chapter 4 (Maciaszek Chapter 4 (Maciaszek -- RASD 2/e)RASD 2/e) 2323
Example 4.2 Example 4.2 –– Video Store (solution)Video Store (solution)
VHSTape
BetaTape
VideoDisk(or DVDDisk)
VideoTape
RentalConditionsMovieTitleVideoMedium
Fuzzy classesRelevant classes
© Pearson Education 2005© Pearson Education 2005 Chapter 4 (Maciaszek Chapter 4 (Maciaszek -- RASD 2/e)RASD 2/e) 2424
Example 4.3 Example 4.3 –– Contact ManagementContact ManagementConsider the following requirements for the Contact Management system and identify the candidate classes:• To "keep in touch" with current and prospective customer
base • To win new contracts• To store the names, phone numbers, postal and courier
addresses, etc. of organizations and contact persons in these organizations
• To schedule tasks and events for the employees with regard to relevant contact persons
• Employees can schedule tasks and events for other employees or for themselves
• A task is a group of events that take place to achieve a result (e.g. to solve customer's problem)
• Typical types of events are: phone call, visit, sending a fax, arranging for training, etc.
© Pearson Education 2005© Pearson Education 2005 Chapter 4 (Maciaszek Chapter 4 (Maciaszek -- RASD 2/e)RASD 2/e) 2525
Example 4.3 Example 4.3 –– Contact Management (solution)Contact Management (solution)
Event
CourierAddressTask
PostalAddressEmployee
ProspectiveOrgContact
CurrentOrgOrganization
Fuzzy classesRelevant classes
© Pearson Education 2005© Pearson Education 2005 Chapter 4 (Maciaszek Chapter 4 (Maciaszek -- RASD 2/e)RASD 2/e) 2626
Specifying classesSpecifying classesIn Class Diagram• Each class given a name (and possibly a code)• Singular noun
–– Recommendation Recommendation –– multiple words joined; each word starting multiple words joined; each word starting with a capital letter (e.g. with a capital letter (e.g. PostalAddressPostalAddress))
• Meaningful• Short (less than 30 characters)
Class properties to be defined• Attributes (initially those that capture interesting object
states)–– Recommendations: Recommendations:
• small letters; underscore to separate words (e.g. street_name)
• start with a small letter; capitalize successive words (streetName)
• Operations (can be delayed till later analysis stages or even till design)
© Pearson Education 2005© Pearson Education 2005 Chapter 4 (Maciaszek Chapter 4 (Maciaszek -- RASD 2/e)RASD 2/e) 2727
Example 4.4 Example 4.4 –– University EnrolmentUniversity EnrolmentRefer to Example 4.1 Consider the following additional requirements from the Requirements Document:• 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 current course offering.
© Pearson Education 2005© Pearson Education 2005 Chapter 4 (Maciaszek Chapter 4 (Maciaszek -- RASD 2/e)RASD 2/e) 2828
Example 4.4 Example 4.4 –– University EnrolmentUniversity EnrolmentMore requirements:
• A student's proposed program of study is entered on on-
line enrolment system T
• 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 delegate of the Head of Division and it is then
forwarded to the Registrar
© Pearson Education 2005© Pearson Education 2005 Chapter 4 (Maciaszek Chapter 4 (Maciaszek -- RASD 2/e)RASD 2/e) 2929
Example 4.4 Example 4.4 –– University Enrolment (solution)University Enrolment (solution)
ECourseOfferingyear : shortsemester : shortenro lmentQuota : int
EDegree<<PK>> degreeName : StringtotalCreditPoints : int
ECourse<<PK>> courseCode : String<<CK>> courseName : StringcreditPoints : short
EStudyProgramyear : shortsemester : short
EStudent<<PK>> studentId : StringstudentName : String
© Pearson Education 2005© Pearson Education 2005 Chapter 4 (Maciaszek Chapter 4 (Maciaszek -- RASD 2/e)RASD 2/e) 3030
Example 4.5 Example 4.5 –– Video StoreVideo StoreRefer to Example 4.2 The additional requirements are:• The rental charge differs depending on
video medium: tape or disk (but it is the same for the two categories of tapes: Beta and VHS).
© Pearson Education 2005© Pearson Education 2005 Chapter 4 (Maciaszek Chapter 4 (Maciaszek -- RASD 2/e)RASD 2/e) 3131
Example 4.5 Example 4.5 –– Video StoreVideo StoreMore requirements:• The system should accommodate future
video storage formats in addition to VHS tapes, Beta tapes and DVD disks
• The employees frequently use a movie code, instead of movie title, to identify the movie
• The same movie title may have more than one release by different directors
© Pearson Education 2005© Pearson Education 2005 Chapter 4 (Maciaszek Chapter 4 (Maciaszek -- RASD 2/e)RASD 2/e) 3232
Example 4.5 Example 4.5 –– Video Store (solution)Video Store (solution)EMovieTitle
movieCode : StringmovieTitle : Stringdirector : String/ isInStock : boolean
EVideoMediumvideoCondition : charpercentExcellentCondition : float
EVideoTape EVideoDisk
EBetaTape EVhsTape EDvdvDisk EVcdDisk
ERentalrentalId : StringrentalDate : java.util.DaterentalDuration : intrentalCharge : float
ERentalRatesrentalPeriod : intrentalChargeTape : floatrentalChargeDisk : float
EEmployeeemployeeName : String
for movie titles
each concrete medium (e.g. VcdDisk) contains one or more movies
defines each rental transaction
ECustomercustomerName : S tring
© Pearson Education 2005© Pearson Education 2005 Chapter 4 (Maciaszek Chapter 4 (Maciaszek -- RASD 2/e)RASD 2/e) 3333
Example 4.6 Example 4.6 –– Contact ManagementContact ManagementRefer to Example 4.3 and consider the following additional information• A customer is considered current if there
exists a contract with that customer for delivery of our products or services. Contract management is, however, outside the scope of our system.
CurrentOrgProspectiveOrg
Fuzzy
© Pearson Education 2005© Pearson Education 2005 Chapter 4 (Maciaszek Chapter 4 (Maciaszek -- RASD 2/e)RASD 2/e) 3434
Example 4.6 Example 4.6 –– Contact ManagementContact ManagementMore requirements: • Reports on contacts based on postal and courier addresses (e.g.
find all customers by post code) • Date and time of the task creation are recorded• The "money value" of a task can be stored• Events for the employee are displayed on the employee's screen
in the calendar-like pages (one day per page). –– The priority of each event (low, medium or high) is visually The priority of each event (low, medium or high) is visually
distinguished on the screen distinguished on the screen
• Not all events have a “due time” - some are “untimed”• Event creation time cannot be changed, but the due time can. • Event completion date and time are recorded • The system stores identifications of employees who created
tasks and events, who are scheduled to do the event (“due employee”), and who completed the event
© Pearson Education 2005© Pearson Education 2005 Chapter 4 (Maciaszek Chapter 4 (Maciaszek -- RASD 2/e)RASD 2/e) 3535
Example 4.6 Example 4.6 –– Contact Management (solution)Contact Management (solution)EPostalAddress
street : StringpoBox : Stringcity : Stringstate : StringpostCode : Stringcountry : String
ECourierAddressstreetAndDirections : Stringcity : Stringstate : Stringcountry : String
EOrganizationorganizationId : StringorganizationName : Stringphone : Stringfax : Stringemail : String/ isCurrent : boolean
EContactcontactId : StringfamilyName : StringfirstName : Stringphone : Stringfax : Stringemail : String
ETaskdescription : StringcreatedDateTime : Datevalue : float
EEventdescription : StringcreatedDateTime : DatedueDateTime : DatecompletedDateTime : Datepriority : char
EEmployeeemployeeId : StringfamilyName : StringfirstName : StringmiddleName : String
© Pearson Education 2005© Pearson Education 2005 Chapter 4 (Maciaszek Chapter 4 (Maciaszek -- RASD 2/e)RASD 2/e) 3636
Example 4.7 Example 4.7 -- TelemarketingTelemarketingConsider the following additional information• Each campaign
–– Has a title that is generally used for referring to itHas a title that is generally used for referring to it–– Has also a unique code for internal reference Has also a unique code for internal reference –– Runs over a fixed period of timeRuns over a fixed period of time
• Soon after the campaign is closed, the prizes are drawn and the holders of winning tickets are advised
© Pearson Education 2005© Pearson Education 2005 Chapter 4 (Maciaszek Chapter 4 (Maciaszek -- RASD 2/e)RASD 2/e) 3737
Example 4.7 Example 4.7 -- TelemarketingTelemarketingMore requirements:• Tickets are uniquely numbered within each campaign• The total number of tickets in a campaign, number of
tickets sold so far, and the current status of each ticket are known (e.g. available, ordered, paid for, prize winner)
• To determine the performance of the society's telemarketers, the duration of calls and the successful call outcomes (i.e. resulting in ordered tickets) are recorded
• Extensive information about supporters is maintained–– Contact details (address, phone number, etc.)Contact details (address, phone number, etc.)–– Historical details such as the first and most recent dates Historical details such as the first and most recent dates
when a supporter had participated in a campaign when a supporter had participated in a campaign –– Any known supporter's preferences and constraints (e.g. Any known supporter's preferences and constraints (e.g.
times not to call, usual credit card number)times not to call, usual credit card number)
© Pearson Education 2005© Pearson Education 2005 Chapter 4 (Maciaszek Chapter 4 (Maciaszek -- RASD 2/e)RASD 2/e) 3838
Example 4.7 Example 4.7 -- TelemarketingTelemarketingMore requirements:• Telemarketing calls are made according to their priorities
• Calls which are unanswered or where an answering machine was found, are rescheduled
–– Times of repeat calls are alternatedTimes of repeat calls are alternated
–– Number of repeat calls is limitedNumber of repeat calls is limited• Limits may be different for different call types (e.g. a normal
"solicitation" call may have different limit than a call to remind a supporter of an outstanding payment)
• Call outcomes are categorized - success (i.e. tickets ordered), no success, call back later, no answer, engaged, answering machine, fax machine, wrong number, disconnected.
© Pearson Education 2005© Pearson Education 2005 Chapter 4 (Maciaszek Chapter 4 (Maciaszek -- RASD 2/e)RASD 2/e) 3939
Example 4.7 Example 4.7 –– Telemarketing (solution)Telemarketing (solution)ECallType
typeDescr : StringcallAttemptLimit : shortalternateHours : String
ECallOutcomestartTime : DateendTime : Date
ECampaigncampaignCode : S tringcampaignTitle : S tringdateStart : DatedateClose : DatedateDrawn : DatenumTickets : intnumTicketsSold : int
EOutcomeTypeoutcomeTypeDescr : StringfollowUpAction : String
ECampaignTicketticketNumber : StringticketValue : floatticketStatus : String
EPrizeprizeDescr : StringprizeValue : floatprizeRanking : int
0..n0..nESupporter
supporterId : StringsupporterName : StringphoneNumber : StringmailingAddress : StringdateFirst : DatedateLast : DatecampaignCount : intpreferredHours : StringcreditCardNumber : String
ECallScheduledphoneNumber : Stringpriority : StringattemptNumber : int
0..n
1
0..n
1
0..1
1
0..1
1
1
0..n
1
0..n
ETelemarketertelemarketerId : StringtelemarketerName : StringaveragePerHour : floatsuccessPerHour : float
0..1
0..n
0..1
0..n
© Pearson Education 2005© Pearson Education 2005 Chapter 4 (Maciaszek Chapter 4 (Maciaszek -- RASD 2/e)RASD 2/e) 4040
Discovering associationsDiscovering associations
Side effect of discovering classes
Some attributes are associations
“Dry-run” of use cases to discover more
associations
Avoid ternary associations
Cycles of associations that do not commute
© Pearson Education 2005© Pearson Education 2005 Chapter 4 (Maciaszek Chapter 4 (Maciaszek -- RASD 2/e)RASD 2/e) 4141
Specifying associationsSpecifying associationsNaming associations
• Recommendation – small letters; capitalizing the first letters of successive words (e.g. empTask)
Naming association roles
Determining multiplicity
• Lower and/or upper multiplicity bounds can be
omitted initially
Rolenames for recursive associations
© Pearson Education 2005© Pearson Education 2005 Chapter 4 (Maciaszek Chapter 4 (Maciaszek -- RASD 2/e)RASD 2/e) 4242
Example 4.8 Example 4.8 –– Contact Management (solution Contact Management (solution –– 1)1)
© Pearson Education 2005© Pearson Education 2005 Chapter 4 (Maciaszek Chapter 4 (Maciaszek -- RASD 2/e)RASD 2/e) 4343
Example 4.8 Example 4.8 –– Contact Management (solution Contact Management (solution –– 2)2)
© Pearson Education 2005© Pearson Education 2005 Chapter 4 (Maciaszek Chapter 4 (Maciaszek -- RASD 2/e)RASD 2/e) 4444
Modeling aggregation and compositionModeling aggregation and compositionFour semantics for aggregation possible• ExclusiveOwns (e.g. Book has Chapter)
–– ExistenceExistence--dependencydependency–– TransitivityTransitivity–– AsymmetricityAsymmetricity–– Fixed propertyFixed property
• Owns (e.g. Car has Tire)–– No fixed propertyNo fixed property
• Has (e.g. Division has Department)–– No existence dependencyNo existence dependency–– No fixed propertyNo fixed property
• Member (e.g. Meeting has Chairperson)–– No special properties except membershipNo special properties except membership
© Pearson Education 2005© Pearson Education 2005 Chapter 4 (Maciaszek Chapter 4 (Maciaszek -- RASD 2/e)RASD 2/e) 4545
Discovering aggregationDiscovering aggregation
Discovered in parallel with discovery of
associations
The litmus test phrases
• “has”
• “is-part-of”
Can relate more than two classes
© Pearson Education 2005© Pearson Education 2005 Chapter 4 (Maciaszek Chapter 4 (Maciaszek -- RASD 2/e)RASD 2/e) 4646
Specifying aggregationSpecifying aggregationUML supports• Aggregation
–– ByBy--reference semanticsreference semantics
–– Hollow diamondHollow diamond
–– Corresponds to Has and Member aggregationsCorresponds to Has and Member aggregations
• Composition –– ByBy--value semanticsvalue semantics
–– Solid diamondSolid diamond
–– Corresponds to Corresponds to ExclusiveOwnsExclusiveOwns and Owns and Owns aggregationsaggregations
© Pearson Education 2005© Pearson Education 2005 Chapter 4 (Maciaszek Chapter 4 (Maciaszek -- RASD 2/e)RASD 2/e) 4747
Example 4.9 Example 4.9 –– University EnrolmentUniversity EnrolmentConsider the following additional requirements:• 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 academic in charge of a course, but additional academics may also teach in it
–– There may be a different academic in charge of a course There may be a different academic in charge of a course each semester each semester
–– There may be different academics for each course each There may be different academics for each course each semestersemester
© Pearson Education 2005© Pearson Education 2005 Chapter 4 (Maciaszek Chapter 4 (Maciaszek -- RASD 2/e)RASD 2/e) 4848
Example 4.9 Example 4.9 –– University Enrolment (solution)University Enrolment (solution)
EAcademicRecordcourseCode : Stringyear : shortsemester : shortgrade : String
ECoursecourseCode : S tringcourseName : Stringcred itPoints : short
EAcademicInCharge
EStudentstudentId : StringstudentName : StringcurrentFees : float
0..n0..n ECourseOfferingyear : shortsemester : shortenrolmentQuota : int
0..n0..n
0..1
0..n
0..1
0..n
0..n
0..n-takesCrsoff
0 ..n
Takes-hasS tud
0..n
© Pearson Education 2005© Pearson Education 2005 Chapter 4 (Maciaszek Chapter 4 (Maciaszek -- RASD 2/e)RASD 2/e) 4949
Modeling generalizationModeling generalizationCommon features abstracted into a more generic classSubclasses inherit (reuse) superclass featuresSubstitutability – subclass object is a legal value for a superclass variable (e.g. a variable holding Fruit objects can have an Appleobject as its value)Polymorphism – the same operation can have different implementations in different classesAbstract operation – implementation provided in subclassesAbstract class – class with no direct instance objects• A class with an abstract operation is abstract
© Pearson Education 2005© Pearson Education 2005 Chapter 4 (Maciaszek Chapter 4 (Maciaszek -- RASD 2/e)RASD 2/e) 5050
Discovering and specifying generalizationDiscovering and specifying generalization
Some discovered in parallel with discovery
of associations
The litmus test phrases
• “can-be”
• “is-a-kind-of”
Multiple inheritance possible
Solid line with an arrowhead pointing to the
superclass
© Pearson Education 2005© Pearson Education 2005 Chapter 4 (Maciaszek Chapter 4 (Maciaszek -- RASD 2/e)RASD 2/e) 5151
Example 4.10 Example 4.10 –– Video StoreVideo StoreThe classes identified so far imply a generalization hierarchy rooted at the class VideoMediumExtend the model to include relationships between classes, and specify generalization relationshipsAssume that the Video Store needs to know if a VideoTape is a brand new tape or it was already taped over (this can be captured by an attribute is_taped_over) Assume also that the storage capacity of a VideoDisk allows holding multiple versions of the same movie, each in a different language or with different endings
© Pearson Education 2005© Pearson Education 2005 Chapter 4 (Maciaszek Chapter 4 (Maciaszek -- RASD 2/e)RASD 2/e) 5252
Example 4.10 Example 4.10 –– Video Store (solution)Video Store (solution)
EVideoTapeisTapedOver : boolean
EVideoDiskdifferentLanguages : booleandifferentEndings : boolean
EBetaTape EVhsTape EDvdvDisk EVcdDisk
ERentalRatesrentalPeriod : intrentalChargeTape : floatrentalChargeDisk : float
EVideoMediumvideoCondition : charpercentExcellentCondition : float
computePercentExcellentCondition() : floatEMovieTitle
movieCode : StringmovieTitle : Stringdirector : String/ isInStock : boolean
0..n
1
0..n
1
1..n 0..n1..n 0..n-theEMovieTitle
-theEVideoMedium
© Pearson Education 2005© Pearson Education 2005 Chapter 4 (Maciaszek Chapter 4 (Maciaszek -- RASD 2/e)RASD 2/e) 5353
Modeling interfacesModeling interfacesInterfaces • do not have attributes (except constants), associations or states• they only have operations, but all operations are implicitly public
and abstract–– perationsperations are declared (i.e. turned into implemented methods) in are declared (i.e. turned into implemented methods) in
classes which implement these interfaces.classes which implement these interfaces.
Interfaces do not have associations to classes but they may be targets of one-way associations from classes• this happens when an attribute that implements an association is
typed with an interface, rather than with a class• the value of any such attribute will be a reference to some class
that implements the interfaceAn interface may have a generalization relationship to another interface• this means that an interface can extend another interface by
inheriting its operations
© Pearson Education 2005© Pearson Education 2005 Chapter 4 (Maciaszek Chapter 4 (Maciaszek -- RASD 2/e)RASD 2/e) 5454
Discovering and specifying interfacesDiscovering and specifying interfacesInterfaces are not discovered from the analysis of the application domainThey are discovered based on design considerations• fundamental for enforcing architectural frameworks, such
as the PCMEF framework• interface reveals only a limited portion of the behavior of
an actual classClass that uses (requires) the interface can be indicated by a dashed arrow pointing to the interface• the arrow can be stereotyped with the keyword «use»
Class that implements (realizes) the interface is indicated by a dashed lined with a triangular end• the line can be stereotyped with the keyword «implement»
© Pearson Education 2005© Pearson Education 2005 Chapter 4 (Maciaszek Chapter 4 (Maciaszek -- RASD 2/e)RASD 2/e) 5555
Example 4Example 4--11 11 –– Contact ManagementContact ManagementConsider classes EContact and EEmployee• some attributes in common (firstName, familyName)• operations that provide access to these attributes can be
extracted into a single interface.
There is a need to display information about overdue events to the screen• presentation-layer class has the responsibility to display a
list of overdue events together with names of contacts and employees, as well as with the additional contact details (phone and email) to contacts
Propose a model such that the presentation class uses one or more interfaces implemented by EEmployee and EContact to support part of the “display overdue events” functionality
© Pearson Education 2005© Pearson Education 2005 Chapter 4 (Maciaszek Chapter 4 (Maciaszek -- RASD 2/e)RASD 2/e) 5656
Example 4Example 4--11 11 –– Contact ManagementContact Management
EContactcontactId : StringfamilyName : StringfirstName : Stringphone : Stringfax : Stringemail : String
EEmployeeemployeeId : StringfamilyName : StringfirstName : StringmiddleName : String
POverdueEvents
displayEvent(ev : IAEvent) : voiddisplayEmployee(emp : IAPerson) : voiddisplayContact(cnt : IAContactInfo) : void
IAPerson
getFirstName() : StringgetFamilyName() : String
<<use>>
<<extend>> <<implement>>
<<implement>>
<<use>>
IAContactInfo
getPhone() : StringgetEmail() : String
© Pearson Education 2005© Pearson Education 2005 Chapter 4 (Maciaszek Chapter 4 (Maciaszek -- RASD 2/e)RASD 2/e) 5757
Modeling and specifying objectsModeling and specifying objects
Only to exemplify
• To illustrate complex relationships between
objects
• To demonstrate changes to objects over time
• To illustrate object collaboration
© Pearson Education 2005© Pearson Education 2005 Chapter 4 (Maciaszek Chapter 4 (Maciaszek -- RASD 2/e)RASD 2/e) 5858
Example 4.12 Example 4.12 –– University EnrolmentUniversity Enrolment
Don Donaldson : Student
COMP224 :AcademicRecord
COMP325 :Course
COMP326 :AcademicRecord
COMP225 :Course
2000 Sem2 :CourseOffering
Rick Richards :AcademicInCharge
© Pearson Education 2005© Pearson Education 2005 Chapter 4 (Maciaszek Chapter 4 (Maciaszek -- RASD 2/e)RASD 2/e) 5959
Behavior specificationBehavior specificationDepicted in use casesDetermines which classes are involved in execution of use cases• Main class operations identified• Message passing between objects captured• Control classes and boundary classes
considered Computations modeled in Activity DiagramsInteractions modeled in Sequence Diagrams or Collaboration Diagrams
© Pearson Education 2005© Pearson Education 2005 Chapter 4 (Maciaszek Chapter 4 (Maciaszek -- RASD 2/e)RASD 2/e) 6060
Modeling use casesModeling use casesComplete piece of functionality• Main flow
• Subflows
• Alternate flows
Piece of externally visible functionality
Orthogonal piece of functionality
Piece of functionality initiated by an actor
Piece of functionality that delivers an identifiable value to an actor
© Pearson Education 2005© Pearson Education 2005 Chapter 4 (Maciaszek Chapter 4 (Maciaszek -- RASD 2/e)RASD 2/e) 6161
Discovering use casesDiscovering use casesDiscovered from• Requirements identified in the Requirements
Document• Actors and their purpose in the system
Questions to ask• What are the main tasks performed by each
actor?• Will an actor access or modify information in the
system?• Will an actor inform the system about any
changes in other systems?• Should an actor be informed about unexpected
changes in the system?
© Pearson Education 2005© Pearson Education 2005 Chapter 4 (Maciaszek Chapter 4 (Maciaszek -- RASD 2/e)RASD 2/e) 6262
Specifying use casesSpecifying use casesActorsUse casesFour kinds of relationships• Association (between actor and use case)• Include (stereotyped with the word: «include»)
–– Included use case is always necessary for the Included use case is always necessary for the completion of the activating use casecompletion of the activating use case
• Extend (stereotyped with the word: «extend»)–– Another use is activated occasionally at specific Another use is activated occasionally at specific
extension pointextension point
• GeneralizationRelationships to be used with restrain
© Pearson Education 2005© Pearson Education 2005 Chapter 4 (Maciaszek Chapter 4 (Maciaszek -- RASD 2/e)RASD 2/e) 6363
Example 4.13 Example 4.13 –– University EnrolmentUniversity Enrolment
Data Entry Person
Registrar Office
Validate Program of StudyEnter Program of Study
<<include>>
Provide Enro lment Instructions
S tudent OfficeStudent
Provide Examination Results
<<extend>>
© Pearson Education 2005© Pearson Education 2005 Chapter 4 (Maciaszek Chapter 4 (Maciaszek -- RASD 2/e)RASD 2/e) 6464
Example 4.14 Example 4.14 –– Contact ManagementContact Management
Customer Services Manager
Create Task
Schedule Event
<<include>>
Customer Services Employee
Complete Event
Maintain Organization
<<extend>>
Maintain Contact
<<extend>>
Employee
© Pearson Education 2005© Pearson Education 2005 Chapter 4 (Maciaszek Chapter 4 (Maciaszek -- RASD 2/e)RASD 2/e) 6565
Example 4.15 Example 4.15 –– Video StoreVideo Store
Rent Video
Return Video
Scanning Device Reserve Video
Maintain Customer Answer Enquiry
Order V ideo
Employee
<<depends on>>
© Pearson Education 2005© Pearson Education 2005 Chapter 4 (Maciaszek Chapter 4 (Maciaszek -- RASD 2/e)RASD 2/e) 6666
Example 4.15 Example 4.15 –– Video Store (Rent Video)Video Store (Rent Video)
Video tape or disk is available to be hired. Customer has a membership card. Scanner devices work correctly. Employee at the front desk knows how to use the system.
Preconditions
Employee, Scanning DeviceActors
A customer wishes to rent a video tape or disk that is picked from the store's shelves or that has been previously reserved by the customer. Provided the customer has a non-delinquent account, the tape is rented out once the payment has been received. If the tape is not returned in a timely fashion, an overdue notice is mailed to the customer.
Brief Description
© Pearson Education 2005© Pearson Education 2005 Chapter 4 (Maciaszek Chapter 4 (Maciaszek -- RASD 2/e)RASD 2/e) 6767
Example 4.15 Example 4.15 –– Video Store (Rent Video)Video Store (Rent Video)A customer may ask an employee about video availability (including a reserved video) or may pick a tape or disk from the shelves. The video and the membership card are scanned and any delinquent or overdue details are brought up for the employee to query the customer about. If the customer does not have a delinquent rating, then he/she can hire up to a maximum of eight videos. However, if the rating of the customer is ‘unreliable’ then a deposit of one rental period for each tape or disk is requested. Once the amount payable is received, the stock is updated and the tapes and disks are handed out to the customer together with the rental receipt. Thecustomer pays by cash, credit card or electronic transfer. Each rental record stores (under the customer’s account) the check-out and due-in dates together with the identification of the employee. A separate rental record is created for each video hired.The use case will generate an overdue notice to the customer if the video has not been returned within two days of the due date, and a second notice after another two days (and at that time the customer is noted as ‘delinquent’).
Main Flow
© Pearson Education 2005© Pearson Education 2005 Chapter 4 (Maciaszek Chapter 4 (Maciaszek -- RASD 2/e)RASD 2/e) 6868
Example 4.15Example 4.15–– Video Store (Rent Video)Video Store (Rent Video)
Videos are rented out and the database is updated accordingly.
Postconditions
A customer does not have a membership card. In this case, the ‘Maintain Customer’ use case may be activated to issue a new card.An attempt to rent too many videos.No videos can be rented because of the customer’s delinquent rating.The video medium or membership card cannot be scanned because of damage to them.The electronic transfer or credit card payment is refused.
Alternative Flows
© Pearson Education 2005© Pearson Education 2005 Chapter 4 (Maciaszek Chapter 4 (Maciaszek -- RASD 2/e)RASD 2/e) 6969
Example 4.16 Example 4.16 –– Telemarketing (solution)Telemarketing (solution)
Update Supporter
Telemarketer
D isplay Campaign Details
Display Supporter History
<<extend>>
Display Prize Details
D isplay Call Details
<<extend>><<extend>>
<<extend>>
Supporter
Schedule and Make Next Call
<<include>>
Supporter
Record Ticket Sale Schedule Callback
Record Call Outcome
<<extend>><<extend>>
Telemarketer
© Pearson Education 2005© Pearson Education 2005 Chapter 4 (Maciaszek Chapter 4 (Maciaszek -- RASD 2/e)RASD 2/e) 7070
Modeling activitiesModeling activitiesActivity Diagrams
Flow of logic
• Sequential control
• Concurrent control
Can be used at different levels of
abstraction
• To define execution of a use case
• To define execution of an operation
© Pearson Education 2005© Pearson Education 2005 Chapter 4 (Maciaszek Chapter 4 (Maciaszek -- RASD 2/e)RASD 2/e) 7171
Discovering and specifying actionsDiscovering and specifying actionsThe execution proceeds from one action state to the nextAn action state completes when its computation is completedActions can be discovered from the narrative specifications of use casesActions are connected by transition linesSynchronization bars (fork and re-join)Branch diamonds (branch and merge)External events not normally modeled on activity graphs
© Pearson Education 2005© Pearson Education 2005 Chapter 4 (Maciaszek Chapter 4 (Maciaszek -- RASD 2/e)RASD 2/e) 7272
Example 4.17 Example 4.17 –– Video Store (solution)Video Store (solution)
Rent Videouse case (excerpt)
Scan Customer Card
Scan Video Medium
Verify Customer
Initiate Rent Transaction
Remove Excessive Videos
Request Deposit
[ is unreliable ]
[ is delinquent ]
[ more than 8 videos ]
Create Rental Record for Each Video
[ deposit refused ]
[ 8 videos or less ]
© Pearson Education 2005© Pearson Education 2005 Chapter 4 (Maciaszek Chapter 4 (Maciaszek -- RASD 2/e)RASD 2/e) 7373
Modeling interactionsModeling interactionsSequence Diagrams • Show an exchange of messages between
objects arranged in a time sequence• More useful in analysis
Collaboration Diagrams• Emphasize the relationships between objects
along which the messages are exchanged• More useful in design
Can be used to determine operations in classes
© Pearson Education 2005© Pearson Education 2005 Chapter 4 (Maciaszek Chapter 4 (Maciaszek -- RASD 2/e)RASD 2/e) 7474
Message sequencesMessage sequencesActions in Activity Diagrams are mapped to messages to Sequence DiagramsMessage can be a:• Signal
–– Denotes asynchronous interDenotes asynchronous inter--object communicationobject communication–– The sender continues executing after sending the The sender continues executing after sending the
signal messagesignal message
• Call–– Denotes synchronous invocation of an operationDenotes synchronous invocation of an operation–– The return message can return some values to the The return message can return some values to the
caller or it can just acknowledge that the operation caller or it can just acknowledge that the operation completedcompleted
© Pearson Education 2005© Pearson Education 2005 Chapter 4 (Maciaszek Chapter 4 (Maciaszek -- RASD 2/e)RASD 2/e) 7575
Example 4.18 Example 4.18 –– UE (centralized interaction)UE (centralized interaction)
Enter Program of Studyuse case
: Data Entry Person : CEnroll : EStudent : ECourse : ECourseOffering
1. add(std, crs, sem)
1.1. getEligibility()
1.2. getAvailability()
1.2.1. getAvailability()
multiple instances
1.3. addCourseOff(crs)
1.4. addStudent(std)
© Pearson Education 2005© Pearson Education 2005 Chapter 4 (Maciaszek Chapter 4 (Maciaszek -- RASD 2/e)RASD 2/e) 7676
Example 4.18 Example 4.18 –– UE (distributed interaction)UE (distributed interaction)
: Data Entry Person : CEnroll : EStudent : ECourse : ECourseOffering
1. add(std,crs,sem)
1.1. addCrs(crs,sem)
multiple instances
1.1.1. checkEligibility()
1.1.1.1. addStd(std)
1.1.1.1.1. checkAvailability()
1.1.1.1.1.1. addStd(std)
1.1.1.2. addCrsOff()
: Data Entry Person : CEnroll : EStudent : ECourse : ECourseOffering
1. add(std,crs,sem)
1.1. addCrs(crs,sem)
multiple instances
1.1.1. checkEligibility()
1.1.1.1. addStd(std)
1.1.1.1.1. checkAvailability()
1.1.1.1.1.1. addStd(std)
1.1.1.2. addCrsOff()
© Pearson Education 2005© Pearson Education 2005 Chapter 4 (Maciaszek Chapter 4 (Maciaszek -- RASD 2/e)RASD 2/e) 7777
Modeling public interfacesModeling public interfacesDetermined by the set of operations that the class offers as its serviceIn analysis• Signature of each operation is defined
–– Operation nameOperation name–– List of formal argumentsList of formal arguments–– Return typeReturn type
In design• Algorithm of a method that implements the operation is
defined
Operation can have• Instance scope• Class (static) scope ($ in front of operation name)
© Pearson Education 2005© Pearson Education 2005 Chapter 4 (Maciaszek Chapter 4 (Maciaszek -- RASD 2/e)RASD 2/e) 7878
Discovering class operationsDiscovering class operationsFrom Sequence Diagrams• Message to an object must be serviced by an
operation in that object
From expected object responsibilities, including the CRUD operations• Create – a new object instance
• Read –the state of an object
• Update – the state of an object
• Delete – i.e. destroy itself
© Pearson Education 2005© Pearson Education 2005 Chapter 4 (Maciaszek Chapter 4 (Maciaszek -- RASD 2/e)RASD 2/e) 7979
Example 4.19 Example 4.19 –– UE (centralized interaction)UE (centralized interaction)
EStudentstudentId : StringstudentName : StringcurrentFees : float
getEligibility() : booleanaddCourseOff(crs : ECourseOffering) : Void
ECoursecourseCode : StringcourseName : StringcreditPoints : short
getAvailability() : ECourseOffering
0..n0..n
ECourseOfferingyear : shortsemester : shortenrolmentQuota : int
getAvailability() : booleanaddStudent(std : EStudent) : Void
-takesCrsoff0..n0..n
0..nTakes
-hasStud0..n
© Pearson Education 2005© Pearson Education 2005 Chapter 4 (Maciaszek Chapter 4 (Maciaszek -- RASD 2/e)RASD 2/e) 8080
Example 4.19 Example 4.19 –– UE (distributed interaction)UE (distributed interaction)
EStudentstudentId : S tringstudentName : S tringcurrentFees : float
addCrs(crs : ECourse, sem : S tring) : VoidcheckEligib ility() : VoidaddCrsOff() : Void
ECoursecourseCode : StringcourseName : StringcreditPoints : short
addStd(std : EStudent) : ECourseOfferingcheckAvailability() : Void
0..n
0..n-hasStud
Takes-takesCrsoff
0..n
0..n
ECourseOfferingyear : shortsemester : shortenrolmentQuota : int
addStd(std : EStudent) : Void
0..n0..n
© Pearson Education 2005© Pearson Education 2005 Chapter 4 (Maciaszek Chapter 4 (Maciaszek -- RASD 2/e)RASD 2/e) 8181
State change specificationsState change specifications
Statechart Diagrams
For each class that exhibits an interesting
dynamic behavior
Changes to some attributes signify state
changes
© Pearson Education 2005© Pearson Education 2005 Chapter 4 (Maciaszek Chapter 4 (Maciaszek -- RASD 2/e)RASD 2/e) 8282
Specifying object statesSpecifying object statesState transition fires when a certain event occurs or a certain condition is satisfied• transition line does not have to be labeled with
an event name • condition itself (written in square brackets) can
fire the transition Transition can be triggered by• Signal event • Call event• Change event• Time event
© Pearson Education 2005© Pearson Education 2005 Chapter 4 (Maciaszek Chapter 4 (Maciaszek -- RASD 2/e)RASD 2/e) 8383
Example 4.19 Example 4.19 –– Video StoreVideo StoreAvailable Not in
S tockrent out( quantity )[ last item ] / subtract item
return item( quantity )[ no items ] / add quantity
In Stock
put on shelf( quantity )
Ordered
order item( quantity )
replenish stock( quantity )
Reserved
entry/ update number reserved
order item( quantity )[ insufficient stock ]
Not Reserved
[ no more reserved ]
reserve( medium type )
© Pearson Education 2005© Pearson Education 2005 Chapter 4 (Maciaszek Chapter 4 (Maciaszek -- RASD 2/e)RASD 2/e) 8484
SummarySummaryThe critical importance of architecture in system development (BCED → PCMEF)State specifications describe the IS world from the static perspective of classes, their attribute content and their relationships• There are many methods of class discovery • Class diagrams visualize classes and relationships :
associations, aggregations and generalizationsBehavioral specifications describe the IS world from the operational (functional) perspective• Use case diagrams provide simple visualization – each
use case is given narrative specification• Other behavioral diagrams include activity diagrams,
interactions diagrams, and addition of operations to classes.
State change specifications describe the IS world from the dynamic perspective• Statechart diagrams allow modeling of state changes