1. What
Actor
Someone or something outside the system that interacts with the use cases developed for the system

2. Use case What A pattern of behavior the system exhibits.
It is a sequence of related transactions performed by an actor and the system in a dialogue.

3. What
Use case
In general, a use case should cover the full sequence of steps from the beginning of a task until the end.
A use case should describe the user’s interaction with the system ...
not the computations the system performs.
A use case should be written so as to be as independent as possible from any particular user interface design.
A use case should only include actions in which the actor interacts with the computer.

4. What
Use Case Diagram
A use case diagram shows the relationships among actors and use cases within the system.
Use case diagrams present an outside view of the system.
The functionality of a use case is captured in its flow of events.

5. What
Extensions
Used to make optional interactions explicit or to handle exceptional cases.
By creating separate use case extensions, the description of the basic use case remains simple.
A use case extension must list all the steps from the beginning of the use case to the end.
Including the handling of the unusual situation.

6. Generalizations What Much like superclasses in a class diagram.
A generalized use case represents several similar use cases.
One or more specializations provides details of the similar use cases.

7. What
Inclusions
Allow one to express commonality between several different use cases.
Are included in other use cases
Even very different use cases can share sequence of actions.
Enable you to avoid repeating details in multiple use cases.
Represent the performing of a lower-level task with a lower-level goal.

8. Example of generalization, extension and inclusion

9. Step 1: Identifying Actors
How
Step 1: Identifying Actors
To fully understand the system's purpose you must know who the system is for, that is, who will be using the system.
Different user types are represented as actors.
An actor is anything that exchanges data with the system.
An actor can be a user, external hardware, or another system.

10. What
Actor and User (1/2)
The difference between an actor and an individual system user is that an actor represents a particular class of user rather than an actual user. Several users can play the same role, which means they can be one and the same actor. In that case, each user constitutes an instance of the actor.

11. What
Actor and User (2/2)

12. How
How to find Actors?
The following set of questions is useful to have in mind when you are identifying actors:
Who will supply, use, or remove information?
Who will use this functionality?
Who is interested in a certain requirement?
Where in the organization is the system used?
Who will support and maintain the system?
What are the system’s external resources?
What other systems will need to interact with this one?

13. How
Actor Description
The brief description of the actor should include information about:
What or who the actor represents.
Why the actor is needed.
What interests the actor has in the system.
The brief description should be, at most, a few sentences long.
Example:
Customer: The Customer collects bottles, cans and crates at home and brings them back to the shop to get a refund.
Operator: The Operator is responsible for maintenance of the recycling machine.
Manager: The Manager is responsible for questions about money and the service the store delivers to the customers.

14. Actor Characteristics
What
Actor Characteristics
The actor's scope of responsibility.
The physical environment in which the actor will be using the system.
The number of users represented by this actor.
The frequency with which the actor will use the system. In most cases, a rough estimate of the number of users and frequency of use will suffice.
The actor's level of domain knowledge.
The actor's level of general computer experience.
Other applications that the actor uses.
General characteristics of the actors, such as level of expertise (education), social implications (language), and age. These characteristics can influence details of the user interface, such as font and language.

15. How to Find Use Cases? How
Following is a set of questions that are useful when identifying use cases:
For each actor you have identified, what are the tasks in which the system would be involved?
Does the actor need to be informed about certain occurrences in the system?
Will the actor need to inform the system about sudden, external changes?
Does the system supply the business with the correct behavior?
Can all features be performed by the use cases you have identified?
What use cases will support and maintain the system?
What information must be modified or created in the system?
Use cases that are often overlooked, since they do not represent what typically are the primary functions of the system, can be of the following kind:
System start and stop.
Maintenance of the system. For example, adding new users and setting up user profiles.
Maintenance of data stored in the system. For example, the system is constructed to work in parallel with a legacy system, and data needs to be synchronized between the two.
Functionality needed to modify behavior in the system. An example would be functionality for creating new reports

16. Brief Description of Use Case
What
Brief Description of Use Case
The brief description of the use case should reflect its purpose. As you write the description, refer to the actors involved in the use case, the glossary and, if you need to, define new concepts.
Example:
Recycle Items: The user uses this machine to automatically have all the return items (bottles, cans, and crates) counted, and receives a receipt. The receipt is to be cashed at a cash register (machine).
Add New Bottle Type: New kinds of bottles can be added to the machine by starting it in ‘learning mode’ and inserting 5 samples just like when returning items. In this way, the machine can measure the bottles and learn to identify them. The manager specifies the refund value for the new bottle type.

17. Step 1 and 2: Documenting Actors and Use Cases
How
Actor
Potential Member
Club Member
Past Member
Marketing
Time
Use Case Name
SUBMIT NEW SUBSCRIPTION
PLACE NEW MEMBER ORDER
MAKE ACCOUNT INQUIRY
MAKE PURCHASE INQUIRY
MAINTAIN MEMBER ORDER
SUBMIT CHANGE OF ADDRESS
SUBMIT RESUBSCRIPTION
SUBMIT NEW MEMBER SUBSCRIPTION PROGRAM
SUBMIT PAST MEMBER RESUBSCRIPTION PROGRAM
SUBMIT NEW PROMOTION
GENERATE QUARTERLY PROMOTION ANALYSIS
GENERATE QUARTERLY SALES ANALYSIS
GENERATE QUARTERLY MEMBERSHIP ANALYSIS
GENERATE ANNUAL SALES ANALYSIS
GENERATE ANNUAL MEMBERSHIP ANALYSIS
Use Case Description
Potential member joins the club by subscribing. (“Take anu 12 CDs for one penny and agree to buy 4 more at regular club prices within two years.”)
Club member places order.
Club member wants to examine his or her account history. (90-day time limit)
Club member inquires about his/her purchase history. (three-year time limit)
Club member wants to revise an order or cancel an order.
Club member changes address. (including and privacy code)
Past member rejoins the club by resubscribing.
Marketing establishes a new membership resubscription plan to entice new members.
Marketing establishes a new membership resubscription plan to lure back former members.
Marketing initiates a promotion. (Note: A promotion features specific titles, usually new, that company is trying to sell at a special price. These promotions are integrated into a catalog sent (or communicated) to all members.)
Print quarterly promotion analysis report.
Print annual sales analysis report.
Print annual membership analysis report.
Print annual sales analysis report. Print annual membership analysis report.
Teaching Notes
The above figure is the result of identifying use cases and actors of the previous figure.

18. Step 3: Constructing a Use Case Model
How
Operations Subsystem
Order Subsystem
Promotion Subsystem
Subscription Subsystem
Submit Past
Member
Resubscription
Program
Time
Marketing
Past Member
Club Member
Potential Member
Generate Annual
Sales Analysis
Membership
Analysis
Generate Quarterly
Promotion Analysis
Submit New
Promotion
Subscription
Submit
Submit Change of
Address
Maintain Member
Order
Make Purchase
Inquiry
Make Account
Place New
Member Order
initiates
Teaching Notes
A use case model diagram can be used to graphically depict the system scope and boundaries in terms of use cases and actors. The use case model diagram for the Member Services System is shown in the above figure. It was created using Popkin Software’s System Architect and represents the relationships between the actors and use cases defined for each business subsystem. The subsystems (UML package symbol) represent logical functional areas of business processes. The partitioning of system behavior into subsystems is very important in understanding the system architecture and is very key to defining your development strategy — which use cases will be developed first and by whom.

19. Step 4: Describe the Use Cases
What
Step 4: Describe the Use Cases
The Flow of Events of a use case contains the most important information derived from use-case modeling work.
It should describe the use case's flow of events clearly enough for an outsider to easily understand it.
Remember the flow of events should present what the system does, not how the system is design to perform the required behavior.

20. Guidelines for Flow of Events
How
Guidelines for Flow of Events
Describe how the use case starts and ends.
Describe what data is exchanged between the actor and the use case.
Do not describe the details of the user interface, unless it is necessary to understand the behavior of the system. For example, it is often good to use a limited set of web-specific terminology when it is known beforehand that the application is going to be web-based. Otherwise, your run the risk that the use-case text is being perceived as too abstract. Words to include in your terminology could be "navigate", "browse", "hyperlink" "page", "submit", and "browser". However, it is not advisable to include references to "frames" or "web pages" in such a way that you are making assumptions about the boundaries between them - this is a critical design decision. 
Describe the flow of events, not only the functionality. To enforce this, start every action with "When the actor ... ".
Describe only the events that belong to the use case, and not what happens in other use cases or outside of the system.
Avoid vague terminology such as "for example", "etc. " and "information".
Detail the flow of events—all "whats" should be answered. Remember that test designers are to use this text to identify test cases.

21. Flow of Events: Structure
What
Flow of Events: Structure
The basic flow of events should cover what "normally" happens when the use case is performed.
The alternative flows of events cover behavior of optional or exceptional character in relation to the normal behavior, and also variations of the normal behavior.

22. How to describe a single use case?
Use case name: Give a short, descriptive name to the use case.
Actor(s): List the actors who can perform this use case.
Brief Description: Explain what the actor or actors are trying to achieve.
Preconditions: State of the system before the use case.
Basic Flow of Events: Describe the use case steps.
Alternative Flow of Events: Describe behavior of optional or exceptional steps.
Extension Points
Postconditions: State of the system in following completion.

23. Course Registration Example
At the beginning of each semester students may request a course catalogue containing a list of course offerings for the semester. Information about each course, such as professor, department, and prerequisites will be included to help students make informed decisions.
The new system will allow students to select four course offerings for the coming semester. In addition, each student will indicate two alternative choices in case a course offering becomes filled or canceled. No course offering will have more than ten students. No course offering will have fewer than three students. A course offering with fewer than three students will be canceled. Once the registration process is completed for a student, the registration system sends information to the billing system so the student can be billed for the semester.
This problemwill be used as examples throughout the course. It is the same problem that appears in the Successfully Applying the Booch and OMT Methods book.

24. Course Registration Example
Professors must be able to access the on-line system to indicate which courses they will be teaching. They will also need to see which students signed up for their course offerings.
For each semester, there is a period of time that students can change their schedule. Students must be able to access the system during this time to add or drop courses.

25. Actors in the Course Registration Example
Who
Actors in the Course Registration Example
The actors are
Student
Professor
Billing System
Registrar

26. Use Cases What Student Registrar Professor Register for courses
Maintain course information, Maintain student information, Maintain professor information, Generate catalogue
Professor
Request course roster, Select courses to teach

27. Use Case Diagram What Billing System Request Course Roster
Student
Billing System
Register for Courses
Request Course Roster
Select Courses to Teach
Professor
Maintain Student Info
Maintain
Professor Info
Maintain Course Info
Generate Catalogue
Registrar

28. Brief Description -- Register for Courses Use Case
What
Brief Description -- Register for Courses Use Case
This use case is initiated by a student. It provides the capability for the student to create, delete, modify and/or review a course schedule for a given semester.

29. Flow of Events -- Register for Courses Use Case
What
Flow of Events -- Register for Courses Use Case
This use case begins when the student enters the student id number. The system verifies that the student id number is valid and prompts the student to select the current semester or a future semester. The student enters the desired semester. The system prompts the student to select the desired activity:
Create a schedule
Review a schedule
Change a schedule
Delete a course
Add a course
The student indicates that the activity is complete. The system will print the student schedule and notify the student that registration is complete. The system sends billing information for the student to the billing system for processing.

30. Flow of Events -- Register for Courses Use Case
What
Flow of Events -- Register for Courses Use Case
Alternate flow If an invalid id number is entered, the system will not allow access to the registration system If an attempt is made to create a schedule for a semester where a schedule already exists the system will prompt for another choice to be made.
Create a schedule The student enters 4 primary course offering numbers and 2 alternate course offering numbers. The student then submits the request for courses. The system then : Checks that prerequisites are satisfied for the requested course : Adds the student to the course offering if the course offering is open Alternate flow If a primary course offering is not available, the system will substitute an alternate course offering.

31. Flow of Events -- Register for Courses Use Case
What
Flow of Events -- Register for Courses Use Case
Review a Schedule The student requests information on all course offerings in which the student is registered for a given semester. The system displays all course offerings for which the student is registered including course name, course number, course offering number, days of the week, time, location, and number of credit hours.
Change Schedule -- Delete a Course Offering The student indicates which course offering to delete. The system checks that the final date for changes has not been exceeded. The system deletes the student from the course offering. The system notifies the student that the request has been processed.

32. Flow of Events -- Register for Courses Use Case
What
Flow of Events -- Register for Courses Use Case
Change Schedule -- Add a Course The student indicates which course offerings to add. The system checks that the final date for changes has not been exceeded. The system then : Verifies that the maximum course load for the student has not been exceeded : Checks that prerequisites are satisfied for the requested course : Adds the student to the course offering if the course offering is open.

33. راهنماي مدرس ( اسلايدهاي 93-124)
در اين مجموعه، Class Modeling و Class Diagram ، اجزاء و مراحل و نحوه ساخت آن مورد بررسي قرار مي گيرند. بدين منظور
در اسلايدهاي : نمادهاي اصلي Class Diagram معرفي شده و به تشريح و با مثال توضيح داده مي شوند.
در اسلايدهاي : قدمهاي اصلي ساخت Class Diagram معرفي شده و با مثال شرح داده مي شوند.

34. How
Classes
A class is simply represented as a box with the name of the class inside
The diagram may also show the attributes and operations
The complete signature of an operation is:
operationName(parameterName: parameterType …): returnType

35. Associations and Multiplicity
What
Associations and Multiplicity
An association is used to show how two classes are related to each other
Symbols indicating multiplicity are shown at each end of the association

36. Labelling associations
How
Labelling associations
Each association can be labelled, to make explicit the nature of the association

37. Analyzing and validating associations
Which
Analyzing and validating associations
Many-to-one
A company has many employees,
An employee can only work for one company.
This company will not store data about the moonlighting activities of employees!
A company can have zero employees
E.g. a ‘shell’ company
It is not possible to be an employee unless you work for a company

38. Analyzing and validating associations
Which
Analyzing and validating associations
Many-to-many
A secretary can work for many managers
A manager can have many secretaries
Secretaries can work in pools
Managers can have a group of secretaries
Some managers might have zero secretaries.
Is it possible for a secretary to have, perhaps temporarily, zero managers?

39. Analyzing and validating associations
Which
Analyzing and validating associations
One-to-one
For each company, there is exactly one board of directors
A board is the board of only one company
A company must always have a board
A board must always be of some company

40. Analyzing and validating associations
How
Analyzing and validating associations
Avoid unnecessary one-to-one associations
Avoid this do this

41. A more complex example A booking is always for exactly one passenger
no booking with zero passengers
a booking could never involve more than one passenger.
A Passenger can have any number of Bookings
a passenger could have no bookings at all
a passenger could have more than one booking

42. Association classes What
Sometimes, an attribute that concerns two associated classes cannot be placed in either of the classes
The following are equivalent
Registration
grade
Student
CourseSection *
Registration
grade
Student
CourseSection *

43. Reflexive associations
How
Reflexive associations
It is possible for an association to connect a class to itself
successor *
Course
isMutuallyExclusiveWith * * *
prerequisite

44. Directionality in associations
How
Directionality in associations
Associations are by default bi-directional
It is possible to limit the direction of an association by adding an arrow at one end * *
Day
Note

45. What
Aggregation
Aggregations are special associations that represent ‘part-whole’ relationships.
The ‘whole’ side is often called the assembly or the aggregate
This symbol is a shorthand notation association named isPartOf
Vehicle * * * *
VehiclePart * * * * * *
Country
Region

46. When to use an aggregation
As a general rule, you can mark an association as an aggregation if the following are true:
You can state that
the parts ‘are part of’ the aggregate
or the aggregate ‘is composed of’ the parts
When something owns or controls the aggregate, then they also own or control the parts

47. Composition What A composition is a strong kind of aggregation
if the aggregate is destroyed, then the parts are destroyed as well
Two alternatives for addresses * * * * *
Building
Room

48. What
Generalization
Specializing a superclass into two or more subclasses
The discriminator is a label that describes the criteria used in the specialization

49. Avoiding unnecessary generalizations
How
Avoiding unnecessary generalizations
Inappropriate hierarchy of
classes, which should be
instances
Recording *
RecordingCategory
Improved class diagram,
with its corresponding
instance diagram
hasCategory *
title
description
subcategory
artist
:RecordingCategory
:RecordingCategory
video
audio
subcategory
subcategory
subcategory
subcategory
subcategory
:RecordingCategory
:RecordingCategory
:RecordingCategory
:RecordingCategory
:RecordingCategory
music video
jazz
classical
blues
rock
:Recording
:Recording
9th Symphony
Let it be
Beethoven
The Beatles

50. Use Case with Nouns Highlighted
ANALYSIS USE CASE
Author: S. Shepherd Date: 10/25/2000
USE CASE NAME:
ACTOR(S):
DESCRIPTION:
REFERENCES
TYPICAL COURSE OF EVENTS:
Place New Member Order
Club Member
This use case describes the process of a club member submitting a new order for SoundStage products. On completion, the club member will be sent a notification that the order was accepted.
MSS-1.0
Actor Action
Step 1: This use case is initiated when a member submits an order to be processed.
Step 9: This use case concludes when the member receives the order confirmation notice.
System Response
Step 2: The member’s personal information such as address and phone number is validated against what is currently on file.
Step 3: For each product being ordered, validate the product number.
Step 4: For each product being ordered, check the availability in inventory and record the ordered product information such as the quantity being ordered.
Step 5: Invoke extension use case Calculate Order Subtotal & Sales Tax.
Step 6: The member’s credit card information is verified based on the amount due and Accounts Receivable transaction data is checked to make sure no payments are outstanding.
Step 7: Invoke extension use case Generate Warehouse Packing Order.
Step 8: Generate an order confirmation notice indicating the status of the order and send it to the member.
(continued)
No additional notes

51. Use Case with Nouns Highlighted (concluded)
ALTERNATE COURSES:
PRECONDITION:
POSTCONDITION:
ASSUMPTIONS:
Step 2: If the club member has indicated an address or telephone number change on the order, invoke abstract use case Revise Street Address.
Step 3: If the product number is not valid, send a notification to the member requesting the member to submit a valid product number.
Step 4: If the product being ordered is not available, record the ordered product information and mark the order as “backordered.”
Step 6: If member’s credit card information is invalid or if member is found to be in arrears, a credit problem notice is sent to the member. Modify the order’s status to be “on hold pending payment.”
Orders can only be submitted by members.
Member order has been recorded and the Packing Order has been routed to the Warehouse.
None at this time.
No additional notes

52. Potential Objects Extracted from Use Case
What
Potential Objects Extracted from Use Case
POTENTIAL OBJECT LIST
Accounts Receivable Department
Amount Due
Club Member
Credit Card Information
Credit Problem Notice
Credit Status
File
Marketing Department
Member Address
Member Order
Member Phone Number
Member Services Department
Member Services System
Order
Order Confirmation Notice
Order Sales Tax
Order Status
Order Subtotal
Ordered Product
Ordered Product Information
Ordered Product Quantity
Past Member
Payments
Potential Member
Product
Product Inventory
Product Number
Street Address
Transaction
Warehouse
Warehouse Packing Order
Teaching Tips
Have students discuss which of the potential objects should be selected.

53. Analysis of the Potential Objects
POTENTIAL OBJECT LIST
Accounts Receivable Department
Amount Due
Club Member
Credit Card Information
Credit Problem Notice
Credit Status
File
Marketing Department
Member Address
Member Order
Member Phone Number
Member Services Department
Member Services System
Order
Order Confirmation Notice
Order Sales Tax
Order Status
Order Subtotal
Ordered Product
Ordered Product Information
Ordered Product Quantity
Past Member
Payments
Potential Member
Product
Product Inventory
Product Number
Street Address
Transaction
Warehouse
Warehouse Packing Order
Not relevant for current project
Attribute of “MEMBER ORDER”
Type of “MEMBER”
Attribute of “MEMBER”
Potential Interface item to be addressed in object-oriented design
“MEMBER ORDER”
Another name for “MEMBER ORDER”
“MEMBER ORDERED PRODUCT”
Unclear noun
Attribute of “MEMBER ORDERED PRODUCT”
Type of “TRANSACTION”
“PRODUCT”
Attribute of “PRODUCT”
“TRANSACTION”
REASON x /
No additional notes.

54. Results of Analysis PROPOSED OBJECT LIST CLUB MEMBER MEMBER ORDER
MEMBER ORDERED PRODUCT
PAST MEMBER
PAYMENT
POTENTIAL MEMBER
PRODUCT
TRANSACTION
AGREEMENT
AUDIO TITLE
MERCHANDISE
GAME TITLE
PROMOTION
RETURN
TITLE
VIDEO TITLE
-- PLUS --
Teaching Notes
Additional objects were included that are part of the case study but were not identified in the use case. These additional objects are introduced here because they appear in later diagrams.

55. Constructing a Class Diagram
How
Constructing a Class Diagram
Step 1: Identify Associations and Multiplicity
Underlining (or highlighting) the use case nouns
Step 2: Identify Generalization/Specialization Relationships
Step 3: Identify Aggregation Relationships
Step 4: Prepare the Class Diagram
Teaching Notes
It is very important that the analyst not only identify relationships that are obvious or recognized by the users. On way to help ensure that possible relationships are identified is to use a object/class matrix. This matrix lists the objects/class as column headings as well as row headings. The matrix can then be used as a check list to ensure that each object/class appearing on a row is checked against each object/class appearing in a column for possible relationships. The name of the relationship and the multiplicity can be recorded directly in the intersection cell of the matrix.
Generalization/Specialization relationships may be discovered by looking at the class diagram. Do any associations exist between two objects that have a one-to-one multiplicity? If so, can you say the sentence “object X is a object Y” and it be true? If it is true, you may have a generalization/specialization relationship. Also look for objects which have common attributes and behaviors. It may be possible to combine the common attributes and behaviors into a new super-object. Why do we want generalization/specialization relationships? It allows us to take advantage of inheritance which facilitates the reuse of objects and programming code.
Aggregation relationships are asymmetric, in that object B is part of Object A but, object A is not part of object B. Aggregation relationships do not imply inheritance, in that object B does not inherit behavior or attributes from object A. Aggregation relationships propagate behavior in that behavior applied to the whole is automatically applied to the parts.

56. Member Services System Class Diagram
<<actor>>
Club Member
Member-Date-Of-Last-Order
Member-Daytime-Phone-Number
Member-Credit-Card-Expire-Date
Member-Credit-Card-Number
Member-Credit-Card-Type
Member-Balance-Due
Member-Bonus-Balance-Available
Audio-Category-Preference
Audio-Media-Preference
Date-Enrolled
-Address
Game-Category-Preference
Game-Media-Preference
Number-Of-Credits-Earned
Privacy-Code
Video-Category-Preference
Video-Media-Preference
persistent
Member Order
Order-Number
Order-Creation-Date
Order-Fill-Date
Shipping-Address-Name
Shipping-Street-Address
Shipping-City
Shipping-State
Shipping-Zip-Code
Shipping-Instructions
Order-Sub-Total
Order-Sales-Tax
Order-Shipping-Method
Order-Shipping-&-Handling-Cost
Order-Status
Order-Prepaid-Amount
Order-Prepayment-Method
Product
Product-Number
UPC-
Quantity-In-Stock
Product-Type
Suggested-Retail-Price
Default-Unit-Price
Current-Special-Unit-Price
Current-Month-Units-Sold
Current-Year-Units-Sold
Total-Lifetime-Units-Sold
Video Title
Producer
Director
Video-Category
Video-Sub-Category
Closed-Captioned
Language
Running-Time
Video-Media-Type
Video-Encoding
Screen-Aspect
MPA-Rating-Code
Audio Tilte
Artist
Audio-Category
Audio-Sub-Category
Number-Of-Units-In-Package
Audio-Media-Code
Content-Advisory-Code
Transaction
Transaction-Reference-Number
Transaction-Date
Transaction-Type
Transaction-Description
Transation-Amount
Member
Member-Number
Member-Name
Member-Status
Member-Street-Address
Member-PO-Box
Member-City
Member-State
Member-Zip-Code
Agreement
Agreement-Number
Agreement-Expire-Date
Agreement-Active-Date
Fulfillment-Period
Required-Number-Of-Credits
Game Title
Manufacturer
Game-Category
Game-Sub-Category
Game-Platform
Game-Media-Type
Number-Of-Players
Parent-Advisory-Code
Title
Title-Of-Work
Title-Cover
Catalog-Description
Copyright-Date
Entertainment-Company
Credit-Value
Member Ordered Product
Quantity-Ordered
Quantity-Shipped
Quantity-Backordered
Purchase-Unit-Price
Credits-Earned
Merchandise
Merchandise-Name
Merchandise-Description
Merchandise-Type
Unit-of-Measure
Promotion
Promotion-Number
Promotion-Release-Date
Promotion-Status
Promotion-Type
Potential Member
Past Member
Expiration-Date
Return
1..* 1
binds
0..*
Conduct s
Has
purchased
0..1
Generate
Feature
Sold as
Places
Sells
(Figure A.15, page 667)
No additional notes.

57. The “Register for Courses” Scenario Nouns
John Student ID number
System Number
Semester Current semester
New schedule List of available courses
Primary courses English 101
Geology World History 200
College Algebra 110 Alternate courses
Music Theory 110 Introduction to Java Programming 180
Necessary prerequisites Course roster
Activity Student schedule
Billing information Four courses
Billing system
Answer
Monday -- external -- no meaning for the problem
Registration system -- the system itself
Student -- good candidate class -- a person registered to take courses at the university
Mary Smith -- attribute -- name of the Student
Course -- good candidate class -- a class offered by the university
English object -- an instance of the Course class
What nouns should be filtered ?

58. Filtering Decisions John -- filtered (actor)
Student ID number filtered (property of a student)
System -- filtered (what is being built)
Number -- filtered (same as student ID number)
Semester -- filtered (state -- when the selects apply)
Current semester -- filtered (same as semester)
New schedule -- candidate object
List of available courses -- candidate object
Primary courses -- filtered (state of a selected course)
English candidate object
Geology candidate object

59. Filtering Decisions World History 200 -- candidate object
College Algebra candidate object
Alternate courses -- filtered (state of a selected course)
Music Theory candidate object
Introduction to Java Programming candidate object
Necessary prerequisites -- candidate object
Course roster -- candidate object
Activity -- filtered (English expression)
Student schedule -- filtered (same as new schedule)
Billing information -- candidate object
Four courses -- filtered (information needed by billing information)
Billing system -- filtered (actor)

60. Candidate Objects
New schedule -- list of courses for a semester for a student
List of available courses -- list of all courses being taught in a semester
English an offering for a semester
Geology an offering for a semester
World History an offering for a semester
College Algebra an offering for a semester
Music Theory an offering for a semester
Introduction to Java Programming an offering for a semester
Necessary prerequisites -- a list of courses that must be taken before another course
Course roster -- list of students for a specific course offering
Billing information -- information needed by the billing system actor

61. راهنماي مدرس ( اسلايدهاي 126-144)
در مجموعه اسلايدهاي ارائه شده در اين قسمت، State Transition Diagram و Behavioral Modeling و مفاهيم و اجزاء و نحوه ساخت آنها مورد بررسي قرار مي گيرد. بدين منظور
در اسلايدهاي : State Transition Diagram، نحوه نمايش State و Attribute هاي آن و ارتباطات بين State ها و انواع خاص State ها بررسي مي شوند.
در اسلايدهاي : ديگر مفاهيم در State Transition Diagram شامل Event، Transition، Action، Activity و Nested State بررسي مي شوند.
در اسلايدهاي مثال آورده شده است.
در اسلايدهاي : Behavioral Model و مراحل ساخت State Machine Diagram با يک مثال ذکر شده اند.

62. How
Drawing States
A state is represented as a rounded rectangle on a state transition diagram (STD)
State Name

63. State and Attributes How
States may be distinguished by the values of certain attributes
Course
numStudents
numStudents = 7
English101 : Course
This implies that the relationship must be optional in the class diagram (may or may not teach a course)
The maximum number of students per course is 10
numStudents < 10
numStudents > = 10
Open
Professor
Course
Closed

64. How
States and Links
States may also be distinguished by the existence of certain links
Instances of class Professor can have two states:
Teaching when a link to a course exists
On sabbatical when no link exists
John:Professor
Biology:Course

65. What
Special States
The start state is the state entered when an object is created
A start state is mandatory
Only one start state is permitted
The start state is represented as a solid circle
A stop state indicates the end of life for an object
A stop state is optional
More than one stop state may exist
A stop state is indicated by a bull’s eye
Start state
Stop state

66. What
Events
An event is an occurrence that happens at some point in time
The state of the object determines the response to different events
Example:
Adding a student to a course
Creating a new course

67. What
Transitions
A transition is a change from an originating state to a successor state as a result of some stimulus
The successor state could possibly be the originating state
A transition may take place in response to an event
Transitions can be labeled with events
Show the students the transitions.
Open
Canceled
Cancel course
Add student

68. What
Guard Conditions
A guard condition is a Boolean expression of attribute values which allows a transition only if the condition is true
Open
Add student[ numStudents < 10 ]
Closed
Add student[ numStudents = 10 ]
Show the students the guard conditions.
If a student asks, the transition without an event name is called an automatic transition which is covered in a few slides.

69. What
Actions
An action is an operation that is associated with a transition
Takes an insignificant amount of time to complete
Considered to be non-interruptible
Action names are shown on the transition arrow preceded by a slash
Creation
Open
Registration open / Initialize
numStudents to 0
Add student[ numStudents < 10 ]
Show the students the action.

70. What
Activities
An activity is an operation that takes time to complete
Activities are associated with a state
An activity
Starts when the state is entered
Can run to completion or can be interrupted by an outgoing transition
Show the activities.
Closed
do: Report course is full

71. Automatic Transitions
What
Automatic Transitions
Sometimes, the sole purpose of a state is to perform an activity
An automatic transition occurs when the activity is complete
If there are multiple automatic transitions
A guard condition is needed on each transition
The conditions must be mutually exclusive
Show the automatic transition (no event).
Closed
do: finalize course
Offered

72. Entry and Exit Actions What
When an action must occur no matter how a state is entered or exited, the action can be associated with the state
In reality, the action is associated with every transition entering or exiting the state
The action is shown inside the state icon preceded by the keyword entry or exit
Show the entry action. Explain that this action occurs whenever the Open state is entered.
Unassigned
do: Assign professor to course
/ numStudents = 0
Open
entry: Register a student
addStudent [ numStudents < 10]

73. What
Nested States
State transition diagrams can become unmanageably large and complex
Nested states may be used to simplify complex diagrams
A superstate is a state that encloses nested states called substates
Common transitions of the substates are represented at the level of the superstate
Any number of levels of nesting is permitted
Nested states can lead to substantial reduction of graphical complexity, allowing us to model larger and more complex problems
Although any level of nesting is permitted, 1 to 2 levels is typical.

74. State Transition Diagram for the Course Class Without Nested States
How
State Transition Diagram for the Course Class Without Nested States
Initialize
do: Initialize course
object
Unassigned
do: Assign professor
to course
Open
entry: Register a
student
Closed
do: Report
course is full
Canceled
do: Send cancellation
notices
addStudent/
numStudents = 0
cancelCourse
RegistrationComplete
do: Generate class
roster
InsufficientStudents
do: Drop all students registered
[ numStudents = 10 ]
registrationComplete[
numStudents > = 3 ]
addStudent [numStudents < 10]
numStudents < 3 ]
Walk the students through the diagram.

75. State Transition Diagram for the Course Class With Nested States
How
State Transition Diagram for the Course Class With Nested States
Initialize
DoneInitializing
Unassigned
do: Assign professor to course
Open
entry: Register a student
Closed
Canceled
RegistrationComplete
do: Generate class roster
InsufficientStudents
do: Drop all students registered
Add student / numStudents = 0
[ numStudents = 10 ]
cancelCourse
registrationComplete[ numStudents > = 3 ]
registrationComplete[ numStudents < 3 ]
addStudent
[numStudents < 10]
Why are there two start states? There is a start for each level of the diagram.
The start at creation is when the object is the initial state
The other start is where you start when you enter the superstate.

76. Member Order State Diagram
Order Shipped
Order Released
Order Filled
Order Invoiced
Pending
In Process
Order Backordered
Order Closed
Member Order final
state
Member Order
initial state
Order pending awaiting payment or additional member information
Order rejected based on Member's past history
Member order archived after 90 days
Invoice sent to member for payment
Response received from member
Order released
to the warehouse
Order shipped to club member
Order filled by the warehouse
Not all product
available
Final payment received
Order submitted
Product received
Teaching Notes
A state diagram models the life cycle of a single object. It depicts the different states an object can have, the events that cause the object to change state over time, and the rules that govern the object’s transition between states. In other words, it specifies from which state an object is allowed to transition to another state.
State diagrams are not required for all objects. Typically, a state diagram is only constructed for those objects that clearly have identifiable states and complex behavior.

77. راهنماي مدرس ( اسلايدهاي 146-177)
در اين مجموعه، Pattern معرفي شده و نحوه شرح آن بررسي شده و انواع Pattern مورد بررسي قرار مي گيرند. بدين منظور
در اسلايدهاي 146 و 147 : Pattern معرفي شده و نحوه توصيف آن آورده شده است.
در اسلايدهاي : Abstraction Occurrence Pattern معرفي شده است.
در اسلايدهاي : General Hierarchy Pattern معرفي شده است.
در اسلايدهاي : Player Role Pattern با مثال معرفي شده است.
در اسلايدهاي 160 و 161: Singleton Pattern معرفي شده است.
در اسلايدهاي : Observer Pattern ارائه مي شود.
در اسلايدهاي : Delegation Pattern معرفي شده است.
اسلايدهاي : Adapter Pattern را شرح داده است.
اسلايدهاي 172و 173 به Façade Pattern اختصاص داده شده است.
در اسلايد 174، Immutable Pattern معرفي شده است.
و اسلايدهاي به Proxy Pattern مي پردازند.

78. The Abstraction-Occurrence Pattern
What
The Abstraction-Occurrence Pattern
Context:
Often in a domain model you find a set of related objects (occurrences).
The members of such a set share common information
but also differ from each other in important ways.
Problem:
What is the best way to represent such sets of occurrences in a class diagram?
 Forces:
You want to represent the members of each set of occurrences without duplicating the common information

79. Abstraction-Occurrence
What
Abstraction-Occurrence
Solution: * * * * * *
«Abstraction»
«Occurrence»
TVSeries
Episode * * * * * *
seriesName
number
producer
title
storySynopsis
Title
LibraryItem * * * * * *
name
barCodeNumber
author
isbn
publicationDate
libOfCongress

80. Abstraction-Occurrence
What
Abstraction-Occurrence
Antipatterns:

81. Abstraction-Occurrence
What
Abstraction-Occurrence
Square variant
ScheduledTrain
SpecificTrain * *
number
date * *
ScheduledLeg
SpecificLeg *
scheduledDepTime
actualDepTime
scheduledArrTime
actualArrTime * *
origin
destination
Station

82. The General Hierarchy Pattern
What
The General Hierarchy Pattern
Context:
Objects in a hierarchy can have one or more objects above them (superiors),
and one or more objects below them (subordinates).
Some objects cannot have any subordinates
Problem:
How do you represent a hierarchy of objects, in which some objects cannot have subordinates?
Forces:
You want a flexible way of representing the hierarchy
that prevents certain objects from having subordinates
All the objects have many common properties and operations

83. General Hierarchy What Solution: «Node» «NonSuperiorNode»*
«Node»
«subordinate»
Solution:
0..1
«NonSuperiorNode»
«SuperiorNode»
Employee *
supervises
FileSystemItem *
contains
0..1
0..1
Secretary
Technician
Manager
File
Directory

84. General Hierarchy What Antipattern: Recording VideoRecoding
AudioRecording
MusicVideo
JazzRecording
ClassicalRecording
BluesRecording
RockRecording

85. The Singleton Pattern What Context: Problem: Forces:
It is very common to find classes for which only one instance should exist (singleton)
Problem:
How do you ensure that it is never possible to create more than one instance of a singleton class?
Forces:
The use of a public constructor cannot guarantee that no more than one instance will be created.
The singleton instance must also be accessible to all classes that require it

86. Singleton What Solution: «Singleton» Company theInstance getInstance
if (theCompany==null)
theCompany
theCompany= new Company();
Company «private»
getInstance
return theCompany;

87. The Observer Pattern What Context: Problem: Forces:
When an association is created between two classes, the code for the classes becomes inseparable.
If you want to reuse one class, then you also have to reuse the other.
Problem:
How do you reduce the interconnection between classes, especially between classes that belong to different modules or subsystems?
Forces:
You want to maximize the flexibility of the system to the greatest extent possible

88. What
Observer
Solution:

89. Observer What Antipatterns:
Connect an observer directly to an observable so that they both have references to each other.
Make the observers subclasses of the observable.

90. The Delegation Pattern
What
The Delegation Pattern
Context:
You are designing a method in a class
You realize that another class has a method which provides the required service
Inheritance is not appropriate
E.g. because the isa rule does not apply
Problem:
How can you most effectively make use of a method that already exists in the other class?
Forces:
You want to minimize development cost by reusing methods

91. Delegation What Solution: «Delegator» «Delegate» Stack LinkedList
delegatingMethod()
«Delegator»
«Delegate» {
delegate.method();
delegatingMethod
method }
push()
Stack
LinkedList {
list.addFirst();
push
addFirst }
pop
addLast
isEmpty
addAfter
removeFirst
removeLast
delete
isEmpty

92. What
Delegation
Example:

93. Delegation What Antipatterns
Overuse generalization and inherit the method that is to be reused
Instead of creating a single method in the «Delegator» that does nothing other than call a method in the «Delegate
consider having many different methods in the «Delegator» call the delegate’s method
Access non-neighboring classes
return specificFlight.regularFlight.flightNumber();
return getRegularFlight().flightNumber();

94. The Adapter Pattern What Context: Problem: Forces:
You are building an inheritance hierarchy and want to incorporate it into an existing class.
The reused class is also often already part of its own inheritance hierarchy.
Problem:
How to obtain the power of polymorphism when reusing a class whose methods
have the same function
but not the same signature
as the other methods in the hierarchy?
Forces:
You do not have access to multiple inheritance or you do not want to use it.

95. Adapter What Solution: «Adaptee» «Superclass» «Adapter» adaptedMethod
polymorphicMethod
«Adapter»
polymorphicMethod()
return
adaptee.adaptedMethod(); { }

96. Adapter What Example: TimsTorus ThreeDShape Sphere Torus volume() {
calcVolume
ThreeDShape
volume
Sphere
Torus
volume()
return
adaptee.calcVolume(); { }

97. The Façade Pattern What Context: Problem: Forces:
Often, an application contains several complex packages.
A programmer working with such packages has to manipulate many different classes
Problem:
How do you simplify the view that programmers have of a complex package?
Forces:
It is hard for a programmer to understand and use an entire subsystem
If several different application classes call methods of the complex package, then any modifications made to the package will necessitate a complete review of all these classes.

98. What
Façade
Solution:

99. The Immutable Pattern What Context: Problem: Forces: Solution:
An immutable object is an object that has a state that never changes after creation
Problem:
How do you create a class whose instances are immutable?
Forces:
There must be no loopholes that would allow ‘illegal’ modification of an immutable object
Solution:
Ensure that the constructor of the immutable class is the only place where the values of instance variables are set or modified.
Instance methods which access properties must not have side effects.
If a method that would otherwise modify an instance variable is required, then it has to return a new instance of the class.

100. The Proxy Pattern What Context: Problem: Forces:
Often, it is time-consuming and complicated to create instances of a class (heavyweight classes).
There is a time delay and a complex mechanism involved in creating the object in memory
Problem:
How to reduce the need to create instances of a heavyweight class?
Forces:
We want all the objects in a domain model to be available for programs to use when they execute a system’s various responsibilities.
It is also important for many objects to persist from run to run of the same program

101. Proxy What Solution: «ClassIF» «Client» «Proxy» «HeavyWeight»
«interface»
«ClassIF» * * * * * * *
«Client»
«Proxy»
«HeavyWeight»

102. Proxy What Example: ListIF ListProxy PersistentList Student
«interface»
ListIF
The list elements will
be loaded into local
memory only when
needed.
ListProxy
PersistentList
Example:
«interface»
Student
PersistentStudent
StudentProxy

103. راهنماي مدرس ( اسلايدهاي 179-180)
در اين دو اسلايد ريسکهاي موجود در ايجاد Class Diagram و راه حلهاي آنها مورد بررسي قرار مي گيرند.

104. پاسخ به پرسشها: مدلسازي يعني چه؟
روشهاي Object Oriented در چه مواردي استفاده مي شوند؟
مزاياي تحليل Object Oriented چيست؟
UML چيست؟
انواع دياگرامهاي UML کدامند؟
Use Case چيست؟
مفهوم Composition چيست؟
مراحل ساخت State Machine Diagram را بيان کنيد.
Pattern چيست؟