1. Object-Oriented Analysis and Design

2. Learning Objectives Key terms Association Class diagram Event Object
Object class
Operation
Sequence diagram
State
State transition
Unified Modeling Language (UML)
Use case
A.2

3. The Object-Oriented Modeling Approach
Benefits
The ability to tackle more challenging problem domains
Improved communication among users, analysts, designers, and programmers
Reusability of analysis, design, and programming results
Increased consistency among the models developed during object-oriented analysis, design, and programming
A.3

4. The Object-Oriented Modeling Approach (continued)
Object-Oriented Systems Development Life Cycle
Process of progressively developing representation of a system component (or object) through the phases of analysis, design, and implementation
The model is abstract in the early stages
As the model evolves, it becomes more and more detailed
A.4

5. The Object-Oriented Systems Development Life Cycle
Analysis Phase
Model of the real-world application is developed showing its important properties
Model specifies the functional behavior of the system independent of implementation details
Design Phase
Analysis model is refined and adapted to the environment
Implementation Phase
Design is implemented using a programming language or database management system
A.5

6. The Object-Oriented Systems Development Life Cycle (continued)
Unified Modeling Language (UML)
A notation that allows the modeler to specify, visualize and construct the artifacts of software systems, as well as business models
Techniques and notations
Use cases
Class diagrams
State diagrams
Sequence diagrams
A.6

7. Use-Case Modeling
Applied to analyze functional requirements of the system
Performed during the analysis phase to help developers understand functional requirements of the system without regard for implementation details
Use Case
A complete sequence of related actions initiated by an actor
A use case that documents the interaction between the system user and the system.
Actor
An external entity that interacts with the system
A.7

8. What Is Use-Case Modeling?
See student notes.
A means for capturing the desired behavior for the system under development
A way to communicate the system's behavior
Identifies who or what interacts with the system and what the system should do
A way to verify all requirements are captured
A planning instrument
A use-case model describes a system's functional requirements in terms of use cases.
It is a model of the system's intended functionality (use cases) and its environment (actors).
You can think of a use-case model as a menu, much like the menu you'd find in a restaurant. By looking at the menu you know what's available to you; the individual dishes as well as their prices. You also know what kind of cuisine the restaurant serves: Italian, Mexican, Chinese, and so on. By looking at the menu, you get an overall impression of the dining experience that awaits you in that restaurant. The menu, in effect, "models" the restaurant's behavior.
Because it is a very powerful planning instrument, the use-case model is generally used in all phases of the development cycle by all team members.

9. Relevant Requirements Artifacts
Use-Case Model
These are the artifacts that drive the analysis and design of the system, and each will be discussed, in detail, later in this module.
Emphasize that the Use-Case Model not only contains the actors and use cases and their relationships, but also contains the detailed information for each use case (documented in Use-Case Specifications).
The other artifacts produced during Requirements do not have as much of an impact on the Analysis and Design activities, so they are not listed here and will not be covered in this course. For more information on the Requirements workflow, suggest the Requirements Management with Use Cases (RMUC) course.
Though not explicitly listed as a Requirements artifact, the Use-Case Modeling Guidelines document is very important, as it is where the conventions for how to write use cases are described (e.g., how to reference actors, glossary terms; use of caps, italics, bold-face, etc.)
Templates for these artifacts are delivered with the Rational Unified Process.
Glossary
Actors
Use Cases
The Use-Case Model describes what the system will do. The Use-Case Model serves as a contract between the customer, the users, and the system developers. It allows customers and users to validate that the system will become what they expected and allows System developers to ensure that what they build is what is expected. The Use-Case Model consists of use cases and actors. Each use-case in the model is described in detail, showing step-by-step how the system interacts with the actors and what the system does in the use case. The Use-Case Specification is the document where all of the use-case properties are documented (e.g., brief description, use-case flows of events, etc.). Note: The OOAD course requirements documentation includes use-case specifications rather than use-case specifications because it is the textual description that will drive analysis and design activities. (Use-case specifications only include the textual use-case properties).
The Supplementary Specification contains those requirements that don’t map to a specific use case (e.g., non-functional requirements). The Supplementary Specification is an important complement to the use-case model. Together they capture all requirements (functional and nonfunctional) that need to be described for a complete system requirements specification.
The Glossary defines a common terminology for all models and contains textual descriptions of the required system.
...
Supplementary
Specification
Use-Case Specifications

10. A.10

11. A Scenario Is a Use-Case Instance
Student
Course
Catalog
System
Register for Courses
We’ve touched on the term “scenario” before, but this slide gives an example. Explain the two scenarios for the same use case. Mention that there are dozens of other scenarios for this use case. Ask for a few more examples of scenarios for the Register for Courses use case.
See student notes for additional points to emphasize.
Scenario 2
Log on to system
Approve log on
Enter subject in search
Invalid subject
Re-enter subject
Get course list
Display course list
Select courses
Confirm availability
Display final schedule
Scenario 1
Log on to system
Approve log on
Enter subject in search
Get course list
Display course list
Select courses
Confirm availability
Display final schedule
A use-case instance describes one particular path through the flows of events described in a use case. It is a specific sequence of actions that illustrates the behavior of the system. This is also called a scenario. In the example here, the sketch of Scenario 1 for the Register for Courses use case shows a Student interacting with the Course Registration System and successfully enrolling in a course the first time. Scenario 2 shows a Student interacting with the Course Registration System and entering an invalid subject; that student must re-enter the subject before successfully getting the course list.
A use case defines a set of related scenarios. A use case represents all the possible sequences that might happen until the resulting value is achieved (or until the system terminates the attempt). The Register for Courses use case represents both of these sequences, and all the other possible sequences of interactions that may occur when a Student tries to enroll in a course.
Users and stakeholders can often identify the sequence of actions they want to perform to obtain a result. Asking stakeholders for the sequence of actions they perform is a good way to start identifying the steps in a use case.

12. Use Case description A Use Case has: Name Brief description
Primary actor
Stakeholders and interest lists
Pre-conditions and Post -condition
Flow of events
Usually structured in sections
One section for ‘Basic flow of events’
Several sections for ‘Alternative flow of events’
Special Requirement
Specific requirements on the Use Case (performance, security, reliability and so on.) that are not expressed in the previous description

13. Use Case : Process Sale(1/4)
Primary Actor: Cashier
Stakeholders and Interests:
Cashier: Wants accurate, fast entry, and no payment errors, as cash drawer short- ages are deducted from his/her salary.
Salesperson: Wants sales commissions updated.
…..
Preconditions: Cashier is identified and authenticated.
Success Guarantee (Postconditions): Sale is saved. Tax is correctly calculated. Accounting and Inventory are updated. Commissions recorded. Receipt is generated. Payment authorization approvals are recorded.

14. Use Case : Process Sale(2/4)
Main Success Scenario (or Basic Flow):
1. Customer arrives at POS checkout with goods and/or services to purchase.
2. Cashier starts a new sale.
3. Cashier enters item identifier.
4. System records sale line item and presents item description, price, and running total. Price calculated from a set of price rules.
Cashier repeats steps 3-4 until indicates done. ……

15. Use Case : Process Sale(3/4)
Extensions (or Alternative Flows):
3a. Invalid identifier:
1. System signals error and rejects entry.
3b. There are multiple of same item category and tracking unique item identity not important (e.g., 5 packages of veggie-burgers):
1. Cashier can enter item category identifier and the quantity.
3-6a: Customer asks Cashier to remove an item from the purchase:
1. Cashier enters item identifier for removal from sale.
2. System displays updated running total.
7b. Paying by credit:
Customer enters their credit account information. ….

16. Use Case : Process Sale(4/4)
Special Requirements:
Touch screen Ul on a large flat panel monitor. Text must be visible from 1 meter.
Credit authorization response within 30 seconds 90% of the time.
Somehow, we want robust recovery when access to remote services such the inventory system is failing.
Language internationalization on the text displayed.
Pluggable business rules to be insertable at steps 3 and 7.
Technology and Data Variations List:
3a. Item identifier entered by bar code laser scanner (if bar code is present) or keyboard.
3b. Item identifier may be any UPC, EAN, JAN, or SKU coding scheme.
7a. Credit account information entered by card reader or keyboard.
7b. Credit payment signature captured on paper receipt. But within two years, we predict many customers will want digital signature capture.

17. Object Modeling: Class Diagrams
An entity that has a well-defined role in the application domain, and has state, behavior, and identity
State
A condition that encompasses an object’s properties and the values those properties have
Behavior
A manner that represents how an object acts and reacts
Object Class
A set of objects that share a common structure and a common behavior
A.17

18. Object Modeling: Class Diagrams (continued)
Class is represented as a rectangle with three compartments
Objects can participate in relationships with objects of the same class
A.18

19. Object Modeling: Object Diagrams
A graph of instances that are compatible with a given class diagram; also called an instance diagram
Object is represented as a rectangle with two compartments
Operation
A function or service that is provided by all the instances of a class
Encapsulation
The technique of hiding the internal implementation details of an object from its external view
A.19

20. A.20

21. Representing Associations
A relationship between object classes
Degree may be unary, binary, ternary or higher
Depicted as a solid line between participating classes
Association Role
The end of an association where it connects to a class
Each role has multiplicity, which indicates how many objects participate in a given association relationship
A.21

22. A.22

23. Finding associations – common association List
Category
System
A is a physical part of B
Register一CashDrawer
A is a logical part of B
SalesLinteItem一Sale
A is physically contained in/on B
Register一Store
Item一Store
A is logically contained in B
ProductSpecification一ProductCatalog
ProductCatalog一Item
A is a description for B
ProductSpecification一Item
A is a line item of a transaction or report B
A is logged/recorded/reported/captured in B
(completed)Sales一Store
(current) Sale一Register
A is a member of B
Cashier一Store
A is an organizational subunit of B
Not applicable
A uses or manages B
Cashier一Register
Manager一Register
A communicates with B
Customer一Cashier
A is related to a transaction B
Customer一Payment
Cashier一Payment

24. Representing Generalization
Abstraction of common features among multiple classes, as well as their relationships, into a more general class
Subclass
A class that has been generalized
Superclass
A class that is composed of several generalized subclasses
A.24

25. Representing Generalization (continued)
Discriminator
Shows which property of an object class is being abstracted by a generalization relationship
Inheritance
A property that a subclass inherits the features from its superclass
Abstract Class
A class that has no direct instances but whose descendents may have direct instances
Concrete Class
A class that can have direct instances
A.25

26. A.26

27. Representing Aggregation
A part-of relationship between a component object and an aggregate object
Example: Personal computer
Composed of CPU, Monitor, Keyboard, etc
A.27

28. Dynamic Modeling: State Diagrams
A condition during the life of an object during which it satisfies some conditions, performs some actions or waits for some events
Shown as a rectangle with rounded corners
State Transition
The changes in the attributes of an object or in the links an object has with other objects
Shown as a solid arrow
Diagrammed with a guard condition and action
Event
Something that takes place at a certain point in time
A.28

29. A.29

30. Finding and Identifying the Business Objects
Find the Potential Objects
Use a conceptual class category list
Review each use case to find nouns that correspond to business entities or events.
Select the Proposed Objects
Not all nouns represent business objects.
Is it a synonym of another object?
Is it outside the scope of the system?
Is it a role without unique behavior, or an external role?
Is it unclear or in need of focus?
Is it an action or an attribute that describes another object?
Teaching Notes
Using use cases as a source for finding objects is a popular approach for object identification.

31. Use a conceptual class category list
Examples
Physical or tangible objects
Register, Airplane
Specifications,designs,or descriptions of things
Product Specification, FlightDescription
Places
Store,Airport
Transactions
Sale,Payment,Reservation
Roles of people
Cashier,Pilot
Containers of other things
Store,Airplane
Thing in a container
Item,Passenger
Other computer or electro-mechanical systems external to the system
CreditPaymentAuthorizationSystem,AirTrafficControl
Abstract noun concepts
Hunger,Acrophobia
Organizations
SaleDepartment,ObjectAirline
………………..
……………….

32. Partial Use-Case with Nouns Highlighted
No additional notes.

33. Potential Object List
No additional notes.

34. Cleaning Up List of Candidate Objects
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.

35. Proposed Object List
No additional notes.

36. Dynamic Modeling: Sequence Diagrams
A depiction of the interaction among objects during certain periods of time
Activation
The time period during which an object performs an operation
Messages
Means by which objects communicate with each other
A.36

37. Dynamic Modeling: Sequence Diagrams (continued)
Synchronous Message
A type of message in which the caller has to wait for the receiving object to finish executing the called operation before it can resume execution itself
Simple Message
A message that transfers control from the sender to the recipient without describing the details of the communication
A.37

38. A.38

39. Dynamic Modeling: Activity Diagram
Activity diagram – a diagram that can be used to graphically depict the flow of a business process, the steps of a use case, or the logic of an object behavior (method).
Conversion Notes
In UML 2.0 the activity diagram renames some symbols and uses them more formally.

40. Activity Diagram Notations
Initial node - solid circle representing the start of the process.
Actions – rounded rectangles representing individual steps. The sequence of actions make up the total activity shown by the diagram.
Flow - arrows on the diagram indicating the progression through the actions. Most flows do not need words to identify them unless coming out of decisions.
Decision - diamond shapes with one flow coming in and two or more flows going out. The flows coming out are marked to indicate the conditions.
Merge - diamond shapes with multiple flows coming in and one flow going out. This combines flows previously separated by decisions. Processing continues with any one flow coming into the merge.
Conversion Notes
This slide has been extensively revised for the seventh edition to correspond with UML 2.0 notation.

41. Activity Diagram Notations (cont.)
Fork – a black bar with one flow coming in and two or more flows going out. Actions on parallel flows beneath the fork can occur in any order or concurrently.
Join – a black bar with two or more flows coming in and one flow going out, noting the end of concurrent processing. All actions coming into the join must be completed before processing continues.
Activity final – the solid circle inside the hollow circle representing the end of the process.
Conversion Notes
This slide has been extensively revised for the seventh edition to correspond with UML 2.0 notation.

42. Activity Diagram with Partitions
Subactivity indicator – the rake symbol in an action indicates that this action is broken out in another separate activity diagram. This helps you keep the activity diagram from becoming overly complex.
Connector – A letter inside a circle gives you another tool for managing complexity. A flow coming into a connector jumps to the flow coming out of a connector with a matching letter.
Conversion Notes
This slide has been extensively revised for the seventh edition to correspond with UML 2.0 notation.
Teaching Notes
In addition to the subactivity indicator and the connector, this activity diagram shows partitions (formerly swmlanes). Partitions are especially useful when including receiver actors.

43. Guidelines for Constructing Activity Diagrams
Start with one initial node as a starting point.
Add partitions if it is relevant to your analysis.
Add an action for each major step of the use case (or each major step an actor initiates.
Add flows from each action to another action, a decision point, or an end point. For maximum precision of meaning, each action should have only one flow coming in and one flow going out with all forks, joins, decisions, and merges shown explicitly.
Add decisions where flows diverge with alternating routes. Be sure to bring them back together with a merge.
Add forks and joins where activities are performed in parallel.
End with a single notation for activity final.
Conversion Notes
This is a new slide for the seventh edition.

44. Moving to Design Start with existing set of analysis model
Progressively add technical details
Design model must be more detailed than analysis model
Component Diagram
A diagram that shows the software components or modules and their dependencies
Deployment Diagram
A diagram that shows how the software components, processes and objects are deployed into the physical architecture of the system
A.44

45. A.45