You are on page 1of 18

Moving Towards Specifications

• What functions will the new system
provide?
Picturing Programs – How will people interact with it?
– Describe functions from a user’s perspective

Jennifer Campbell • UML Use Cases
– Used to show:
(slightly edited by Greg Wilson) • the functions to be provided by the system
CSC301 – Fall 2007 • which actors will use which functions

CSC301 University of Toronto 2

UML Use Case Diagrams Notation for Use Case Diagrams
Communication
Capture the relationships between actors association Use case

and use cases.
Change a
client contact Place book order
Add a Staff contact
Campaign
new client
Manager Customer
Actor
Record
client payment
Accountant System
boundary

CSC340 University of Toronto [BMF99] 3 CSC301 University of Toronto [BMF99] 4

1

– also models a separate sub-case which is executed conditionally. – puts the common behavior in a use case of its own. Use cases and Actors Example: Staff Management Add new Staff staff member Management • Use case: System – a pattern of behavior that the new system is required Add new to exhibit staff category – a sequence of related actions performed by an actor and the system via a dialogue. – used to model a part of a use case that the user may see as – used to avoid describing the same flow of events several times optional system behavior. Change rate for staff category • Actor: Accountant – anything that needs to interact with the system: Change category • a person for staff member • a role that different people may play • another (external) system. Check out item Distribute info to students Cashier <<uses>> Registrar <<extends>> Swipe UPC Distribute schedule code info to students CSC340 University of Toronto 7 CSC340 University of Toronto 8 2 . Calculate staff bonuses CSC340 University of Toronto 5 CSC340 University of Toronto 6 <<extends>> <<uses>> When one use case adds behaviour to a base case One use case invokes another (like a procedure call).

or store some kinds of information in the system ? – Who will be a primary user of the system? (primary actor) – Who will need support from the system to do her daily tasks? – Does the actor have to be notified about events in the system? – Who will maintain. create. keep the system working? – Does the actor need to notify the system about something? (secondary actor) – What do those events require in terms of system functionality? – Who or what has an interest in the results that the system – Could the actor’s daily work be simplified or made more efficient produces ? through new functions provided by the system? • To find actors that are external systems ask: – Which hardware devices does the system need? – With which other systems does the system need to interact with? CSC340 University of Toronto 11 CSC301 University of Toronto 12 3 . ask the following questions: – the users who directly use the system – Which functions does the actor require from the system? – also others who need services from the system – What does the actor need to do ? • To find actors that are people/roles ask: – Does the actor need to read. administrate. Example: Car Example: Meeting Scheduler Driver GasAttendant Mechanic Initiator Participant <<uses>> <<uses>> Fill Up Check Oil Fix Car Edit <<extends>> Provide Generate Withdraw constraints Drive Schedule Constraints Schedule < < us <<uses>> meeing >> <<uses>> <<extends>> es us << es>> <<uses>> Turn On << us Fix car on Engine >> es the road ses <<u >> Validate User CSC301 University of Toronto 9 CSC301 University of Toronto 10 Identifying Actors Finding Use Cases • Look for: • For each actor. modify. destroy.

• …do not include complex control logic CSC301 University of Toronto 13 CSC301 University of Toronto 14 Example: Place book order Example: Calculate staff bonuses Place book order Customer Customer Customer Invokes initiates the the search method iteration sequence in OnlineStore :Accountant :PayrollSystem :Staff :Bank :Customer :OnlineStore :OrderDepartment :Bank list payroll [for each staff] *get account search for book Activation [for each staff] *calculate bonus Time [book exists] order book update payroll submit order request *[for each staff] update account debit account *[for each staff] schedule direct deposit CSC301 University of Toronto 15 CSC301 University of Toronto 16 4 .g. – Sometimes useful to identify a • Each sequence diagram describes one possible scenario for generalization of several use cases the use case – Sequence diagrams… • …should remain easy to read and understand. where several actors belong to a single class – Sequence diagrams show step-by-step what’s • Some use cases are needed by all members in the class involved in a use case • Other use cases are only needed • Which objects are relevant to the use case by some members of the class • How those objects participate in the function – Actors inherit use cases from the class – You may need several sequence diagrams to • Use Case classes describe a single use case. Generalizations UML Sequence Diagrams Generalization relations: “is a” • Actor classes – It’s sometimes useful to identify classes of actor • Describe a Use Case using Sequence Diagrams • E.

objects have to collaborate. but can ask for it. – To carry out business processes. Initial State Initial state Activities Final state Final State Receive Credit Card Activate Credit Card Fork/Join Decision CSC301 University of Toronto 19 CSC301 University of Toronto 20 5 . CSC301 University of Toronto 17 CSC340 University of Toronto 18 UML Activity Diagrams: Example 1: Legend Credit Card Activation Activity The customer receives the card. • …by sending messages to one another to invoke each others’ operations – Objects can only send messages to one another if they “know” each other • I. and then activates the card. Example: Add an advertisement Modelling Sequences of Events • Objects “own” information and behaviour – Objects don’t “know” about other objects’ information. if there is an association between them.e.

– put the initial and final states in those locations • Each activity should have at least one transition etc) who performs them. • Swimlanes can be used to group activities • Diagrams are read from top-left to bottom-right based on the actor (person. • If an activity diagram is partitioned into • The diagram should be decidable swimlanes. than each activity must appear – transitions out of a decision points should have mutually exclusive guards in exactly one swimlane. – the set of guards should be complete • Transitions may cross swimlanes. business unit. into it and at least one transition out of it. • Each fork should have a corresponding join. [Amb03] CSC301 University of Toronto 23 CSC301 University of Toronto 24 6 . Example 3: Order System Example 2: Order System (with loop) Receive Guard Receive [failed] [failed] Order Cancel Order Order Cancel Order Authorize Authorize Payment Decision Payment [succeeded] [succeeded] Assign Items Dispatch Order Assign Item Dispatch Order to Order * [for each to Order Fork item in order] Join CSC301 University of Toronto 21 CSC301 University of Toronto 22 A few style guidelines Swimlanes • The diagram should have start and end state(s).

Ship Order an employee is hired. an employee works on one or more projects :Employee name Name (mandatory) Receive Order Attributes Bill Customer (optional) employee number department hire Add Remainder fire Operations Pay Bill Close Order to Stock [BRJ99] works on projects (optional) CSC301 University of Toronto 25 CSC301 University of Toronto 26 Objects vs. Process Line Item Pull Materials • Example: – Employee: has a name. – and common meaning (“semantics”). Classes UML Class Diagrams • The instances of a class are called objects. Request – common behaviour (operations). employee number and department.g.g. • UML Class Diagrams show classes and their Fred_Bloggs:Employee relationships name: Fred Bloggs employee number: 234609234 • Relationships: connections between classes department: Marketing – Objects do not exist in isolation from one another – Types of UML relationships: – Two different objects may have identical attribute values (like two people with identical name and address) • Association • Objects have associations with other objects • Aggregation and Composition – E. you don’t want both managerName and manager# as attributes of Project! (…Why??) CSC301 University of Toronto 27 CSC301 University of Toronto 28 7 .Example 3: Diagram with Swimlanes Classes Customer Sales Warehouse • A class describes a group of objects with – similar properties (attributes). and fired. Product – common relationships to other objects. Fred_Bloggs:employee is associated with the KillerApp:project object • Generalization – But we will capture these relationships at the class level (why?) • Dependency – Note: Make sure attributes are associated with the right class • Realization } not useful for analysis • E.

.g..15.? 0. then the multiplicity is – If yes.* mailing address • Examples: id number email start date contact fax – Optional (0 or 1) 0.* date 0. scheduled by at least one patient. initial mileage – No..* 1. – If not.. Class Associations Association Multiplicity Multiplicity Multiplicity A Client has A StaffMember is Name assigned zero or exactly one StaffMember of the more Clients • Multiplicity: the minimum and maximum as a contact person association times an object can be associated with the :Client related object :StaffMember company name name 1 assigned to 0.19.? • …and that information doesn’t naturally live in the classes at the reason specialization book appointment ends of the association explain symptoms assess patient • E.* primary office 1.? 0..* Role read in this direction – A range of values 1.3.* owns 1 name address • Can the same appointment be year made appointments? mileage owner drivers licence number schedule by multiple patients? – Yes.*..* The “assigned to” association should be – One or more 1..7....6 The StaffMember’s role in this association – A set of ranges 1.. then the multiplicity is 0. • Does an appointment need to be attended by at least one doctor? :Title • Does a patient have to schedule year bought an appointment? – Yes... a “title” is an object that represents information about the relationship cancel without between an owner and her car notice • Does an appointment need be • Does a doctor need to attend scheduled by a patient? appointments? :Car :Person – Yes! An appointment is – No... • Can a doctor attend multiple VIN(vehicle Id Number) 0.10. CSC301 University of Toronto [DWT05]31 CSC301 University of Toronto 32 8 .? 0.* 1...1 Direction – Zero or more 0.1 person phone – Exactly one 1 = 1...* is as a contact person CSC301 University of Toronto 29 CSC301 University of Toronto 30 Exercise: Multiplicities Association Classes :Appointment :Patient :Doctor Sometimes the association is itself a class schedules time attends insurance carrier • …because we need to retain information about the association 1 1. then exactly one Patient schedules each appointment. • Can an appointment be attended price paid • Can a patient schedule more than by multiple doctors? licence plate number one appointment? – If yes.

“Most of our work is on advertising for the press. that’s newspapers and magazines. and they can all be [Amb03] lent out and reserved” CSC301 University of Toronto 35 CSC301 University of Toronto 36 9 .. a car should always [Amb03] have (at least) one engine). Aggregation Composition The “is part of” or “whole-part” relationship • Strong form of aggregation that implies ownership: – if the whole is removed from the model.” student id employee id major department – Bottom Up salary • You notice similarities between classes you have identified add course • E.* 1.g. so is the part – the whole is responsible for the disposition of its parts An employee is part of a team..* lives at 1 street changes name city SIN province • Look for generalizations in two ways: postal code – Top Down • Subdivide an existing class • Or you have an association that expresses a “kind of” relationship :Student :Professor • E.g. but drop course teach course they are all filed using the Dewey system. :Team :Employee :Car :Engine 0.e. associations. & operations from • Usefulness the superclass :Address – Can easily add new subclasses if the organization :Person 0...* 1 1 Note: The multiplicity should be 1 when the association is compostion (i. CSC301 University of Toronto 33 CSC301 University of Toronto 34 Generalization More on Generalization Subclasses inherit attributes. “We have books and we have CDs in the collection.

a assembly of objects :Sensor control action.g. • E. etc.g. displays. manufacturing floor. division. sensors. reports.g. – Be sure that the superclass is useful as a class in its own right • It’s better to include many candidate – Don’t add subclasses or superclasses that are classes at first not relevant to your analysis – You can always eliminate them later if they turn out not to be useful – Explicitly deciding to discard classes is better than just not thinking about them CSC301 University of Toronto 37 CSC301 University of Toronto 38 Possible Classes Possible Classes [2] :PrimeMinister • External Entities :PayrollSystem • Roles – …that interact with the system – played by people who interact being modeled with the system • E. four-wheeled vehicles. people. More on Generalization [2] Finding Classes • Don’t generalize just for the sake of it • Look for nouns and noun phrases in – Be sure that everything about the superclass stakeholders’ descriptions of the problem applies to the subclasses – include in the model if they explain the nature or structure of information in the application. :LandTransfer – …that occur in the context of • Structures the system – that define a class or • E. group. devices. – …that establish the context of etc. loading dock. team. :Warehouse the problem being modeled • Occurrences or Events • E. [Pre97] [Pre97] CSC301 University of Toronto 39 CSC301 University of Toronto 40 10 . being modeled • Places • E. computers. signals. – …that are part of the domain etc.g. other • Organizational Units systems – that are relevant to the :HumanResources application • Things :Invoice • E. etc.g.g. transfer of resources. etc.

g.g.g. partialPayment().partialPayment. although we normally ignore it) finalPayment() event • Example: Invoice object: state finalPayment() partialPayment() fully paid final state :Invoice partialPayment() • The model specifies a set of traces unpaid partially paid – E.finalPayment() initialBalance – E. Coad & Yourdon’s Criteria Selecting Classes for Selecting Classes • Discard classes for concepts which: • Retained information: Will the system need to remember information about this class of objects? – Are beyond the scope of the analysis • Needed Services: Do objects in this class have – Refer to the system as a whole identifiable operations that change the values of their – Duplicate other classes attributes? • Multiple Attributes: Does the class have multiple – Are too vague or too specific attributes? • e. have too many or too few instances • Common Attributes: Does the class have attributes that • Include external entities as classes if they: are shared with all instances of its objects? – Produce or consume information essential to • Common Operations: Does the class have operations that are shared with all instances of its objects? the system [Pre97] CSC301 University of Toronto 41 CSC301 University of Toronto 42 Object Behaviour Statecharts • There are a finite number of states (all attributes have finite ranges) • All objects have “state” initial state partialPayment() – An object has a value for each of its attributes partialPayment() – Each possible assignment of values to attributes is a state unpaid partially paid transition • (and non-existence is a state. no trace may have a finalPayment() followed by a partialPayment() fully paid [Mac01] CSC301 University of Toronto 43 CSC301 University of Toronto 44 11 .g.finalPayment() currentBalance finalPayment() – There may be an infinite number of traces (and traces may be of infinite length) partialPayment() • The model excludes some behaviours finalPayment() finalPayment() – E. partialPayment().

• The action is a procedural expression to be performed when the transition fires. Abstraction Exercise: Abstraction For each state. 18≤age≤65. and if they are met.g. the state space is infinite initialBalance partialPayment() • Only part of that state space is “interesting” currentBalance unpaid partially paid – Some states are not reachable partialPayment() – Integer and real values usually only vary within some relevant finalPayment() finalPayment() range finalPayment() – Often not interested in the actual values.g.g. then transitions from it are enabled. cost==0. cost > budget. • States are either “on” or “off” at a given point in time. object with five boolean attributes: 2 +1 states 5 • E. printClassList() transition fires. • If a state is on. what are the properties or value ranges of • The state space of most objects is enormous initialBalance and currentBalance that interest us? – State space size is the product of the range of each attribute 5 • E. object with five integer attributes: (maxint) +1 states initialBalance > currentBalance • E. removeStudent() openEnrollment() – When an event occurs the guard conditions closeEnrollment() are checked. age>65 • Example for Cost: cost ≤ budget. just certain ranges: fully paid • Example for Age: age<18. addStudent() [currCapacity < = maxCapacity] action • Transitions are triggered by events. then the • A transition is the movement from one state to another. object with five real-valued attributes: …? :Invoice partialPayment() – If we ignore computer representation limits. closeEnrollment()/ printClassList space available partialPayment() partialPayment() closeEnrollment()/ printClassList unpaid partially paid removeStudent() closed to enrollment finalPayment() addStudent()[ currCapacity = = maxCapacity] full finalPayment() fully paid guard CSC301 University of Toronto [SJB05]47 CSC301 University of Toronto 48 [Amb03] 12 . initialBalance == currentBalance cost > (budget+10%) currentBalance == 0 CSC301 University of Toronto 45 CSC301 University of Toronto [Mac01]46 Transitions : CourseRegistration maxCapacity Transitions [2] currCapacity A transition consists of three parts: enrollmentStatus event [guard] / action classList • A guard is a Boolean condition that must be event [guard] / action addStudent() true in order for a transition to “fire”.

only working age senior (concurrent substates) one of its substates is “on” – When the superstate is “on”. – Superstates make it possible to view a state diagram at adult different levels of abstraction. Events Events [2] • Call events occur when an object receives a call for one • Change events occur when a condition becomes true of its operations to be performed – denoted by the keyword ‘when’ – Example: Bill class – Example: Invoice class payBalance() when: [ currentBalance == 0] unpaid paid unpaid paid • Signal events occur when an object receives an explicit • Time events mark the passage of a designated period of (real-time) signal time – Example signal: Mouse click – Example: Exam class – More useful in design after: [3 hours] – Syntax is the same as call events in progress complete CSC301 University of Toronto [BMF99] 49 CSC301 University of Toronto [BMF99] 50 Superstates Example: Person States can be nested. the AND substates will be single coupled nested further as OR superstates employed married widowed unmarried probationary after [6 months] on payroll divorced separated deceased full assigned to project CSC301 University of Toronto 51 CSC301 University of Toronto 52 13 . to make diagrams simpler child – A superstate consists of one or more states. OR superstates AND superstates – when the superstate is “on”. all of its states are also “on” employed – Usually.

and Sale information system. • Each state should have at least one transition into it and – All events in a statechart should appear as: at least one transition out of it. Department. – e. • An instance of an entity is an object in the • Direct. – All actions in a statechart should appear as: • It is fine for guards on transitions from a state to not form • operations (methods) of an appropriate class in the a complete set. • The diagram should be deterministic. • Diagrams are usually read from top-left to bottom-right. – Each statechart should correspond to one so put the start and end states in those locations. Employee. City. Class Diagrams and Statecharts Style Tips • Consistency Checks between diagrams • The diagram should have start and end state(s). • operations (methods) of an appropriate class in the class diagram • Use a superstate when multiple states have a common entry or exit condition. class diagram [Amb03] CSC301 University of Toronto 53 CSC301 University of Toronto 54 Entity Relationship (ER) Schema Entities • Comparable to UML class diagrams • Classes of objects with properties in – Not equivalent common and an autonomous existence • Good for describing data requirements for a new – E.g.g. easy-to-understand graphical notation class represented by the entity • Translates readily to relational schema for • E. can represent an entity without knowing its properties City Department Employee Sale CSC301 University of Toronto 55 CSC301 University of Toronto 56 14 .g. Helsinki. Stockholm. are examples of instances of the entity City database design – more abstract than relational schema • Usually described using nouns. class on the Class diagram.

the pair (Johanssen. • Usually described using verbs (sometimes Employee Department nouns) WorksIn Meets Resides Owns CSC301 University of Toronto 57 CSC301 University of Toronto [RG00] 58 Attributes Internal Identifiers • Associate a value belong to a set (domain) with each • Identifiers are also known as keys. is an instance in the relationship Resides. instance of an entity or relationship. the identifier for the relationship Person-Owns-Car is a tuple of the Person and Car identifiers S tu d en t Student W rite s Writes E xa m Exam internal. multi-attribute internal.g. Resides is a relationship that can exist between a City entity and a Person entity • An instance of a relationship is an n-tuple of instances of entities Manages – E.Stockholm). single-attribute s in ce Manages M a n a g es nam e firstName lastName model nam e Employee Department registration E m p lo y e e D e p a rtm en t dateOfBirth address colour WorksIn W o rks In b u d ge t S IN Person Owns Car s in ce CSC301 University of Toronto [RG00] 59 CSC301 University of Toronto 60 15 . Student Writes Exam – E.g. Relationships Examples • Logical links between two or more entities.g. • An identifier may be formed by one or more attributes of the entity y ea r itself p ro gra m c o u rs e • A relationship is identified using identifiers for all the entities it s tu d e n tID relates – E.

hour> – E.room> • Cardinality is any pair of non-negative integers (min.Many-to-Many CSC301 University of Toronto 63 CSC301 University of Toronto 64 16 . Course instances Room instances CSC301 University of Toronto 61 CSC301 University of Toronto 62 Exercise: Selecting Identifiers Cardinalities Course Meets Room • Cardinalities constrain participation in relationships – minimum and maximum number of relationship instances in which an • What attributes should we use to describe Meets? entity instance can participate.One-to-One – (1.day. – <courseinstructor. – <coursename.50) Employee Assigned Task – <coursename> • Only one meeting per given course name Employee is assigned 1 to 5 tasks. where • Only one meeting for a given instructor and room min <= max – An instructor must have all her meetings in different rooms! – (1.1) . Example: Instances for Owns Meaning of ER Diagrams Course Meets Room o1 P1 • Course and Room are entities.N) .5) (0.g. Tasks are assigned to 0 to 50 employees.N) .Many-to-One • An instructor participates in at most one meeting – (M. o2 C1 – Their instances are particular courses (eg CSC340S) and rooms o3 (eg BA1130) P2 • Meets is a relationship. o4 – Each meeting has exactly one associated course and room P4 o5 C3 P5 o6 Person Owns Car • The unique identifiers for Person and Car clearly identify each entity.max). • Only one section of a course can meet at a time (day and hour) (1. • Instances of the Owns relationship are tuples of (Person.1) . Meets instances Car).One-to-Many – <courseinstructor> – (N. P3 C2 – Its instances describe particular meetings.

– …need to indicate the – It must be in a (1.N) city city Student Student Enrolls Enrols University University itself… surname surname address address • Student is a weak entity.1) surname LicenceNumber Person surname Registration CSC301 University of Toronto 65 CSC301 University of Toronto 66 Weak Entities Recursive Relationships studentID studentID name name • An entity can have year year relationships with (1.1) CarRegistration (0.1) (0.1) (1. • If the relationship is not – Need to know which university she is enrolled in.1) relation with the relationship used to two roles that the entity uniquely identify it.1) (1.1) linked by one-to-many (or many-to-many) Owns CarRegistration relationships (0. symmetric… • A weak entity can only be identified using the attributes of another entity. – Cannot be uniquely identified using only the studentID. • Also called an external identifier plays in the relationship.N) – Optional attributes have cardinality (0. Cardinalities of Attributes Cardinalities of Attributes [2] • Attributes can also have cardinalities • Multi-valued attribute surname LicenceNumber – To describe the minimum and maximum number of values of the cardinalities are attribute associated with each instance of an entity or a problematic relationship. CSC301 University of Toronto 67 CSC301 University of Toronto 68 17 .N) Car LicenceNumber Person (0.N) (1. – Usually better Person – The default is (1.1) modelled with additional entities (0.

Ternary Relationships Generalizations • Show “is-a” relationships between entities age surname taxCode address taxCode Person Professional Man Woman Lawyer Engineer Doctor maternityStatus specialization • Inheritance: – Every instance of a child entity is also an instance of the parent entity – Every property of the parent entity (attribute. relationship or other generalization) is also a property of a child entity CSC301 University of Toronto 69 CSC301 University of Toronto 70 Types of Generalizations In My Opinion Total generalization surname age taxCode Partial • every instance of Person generalization • Models are only as useful as the tools the parent entity is used to work with them an instance of one salary of its children • The act of modeling is more useful than Woman Man Employee Student the models themselves • But: the more concurrency there is in a maternityStatus system. the more important modeling and Manager Programmer Analyst proofs become language Programmer CSC301 University of Toronto 71 CSC301 University of Toronto 72 18 . identifier.