1. UNIFIED PROCESS

2. What is Object Oriented Analysis?
The emphasis is on finding and describing real world the objects or concepts in the problem domain.
In the course registration system, some of the concepts include : student , course , enrollment…etc.

3. The Unified Process
A standardized approach to analysis and design helps to ensure that all necessary tasks are understood and completed in software development.
The course, will focus on the Unified Process developed at Rational Software by Ivar Jacobsen, Grady Boch, Jim Rumbaugh, and others.

4. Applying UML
UML is just a standard diagramming notation. It is just a tool.
Knowing UML helps you communicate with others in creating software
NB: Goal of this class:
Learning Object-Oriented Analysis and Design, not how to draw diagrams.

5. Why UP? Think and Design with Objects Apply UML Use Design Patterns
Apply to Agile approaches (XP, scrum)
Incremental requirements analysis
Use cases

6. Phases in RUP (developed by Rational Corporation)
RUP is divided into four phases:
Inception
Elaboration       
Construction
Transition

7. Rational Unified Process
Phases
Process Workflows
Inception
Elaboration
Construction
Transition
Business Modeling
Requirements
Analysis & Design
Implementation
Test
Deployment
Supporting Workflows
Configuration Mgmt
Management
Environment
Preliminary Iteration(s)
Iter. #1
Iter. #2
Iter. #n
Iter. #n+1
Iter. #n+2
Iter. #m
Iter. #m+1
Iterations within phases

8. Most Important Concept in UP
The critical idea in the Rational Unified Process is Iterative, Incremental development.
Iterative Development is successively enlarging and refining a system through multiple iterations, using feedback and adaptation.

9. The Most Important Concept
Each iteration will include requirements, analysis, design, and implementation.
Iterations are timeboxed.
Incremental : system grows over time

10. Example: Building a House
Incremental: Start with a modest house, keep adding rooms and upgrades to it.
Iterative: On each iteration, the house is re-designed and built a new.

11. Iterations Each iteration involves :
Choosing small subset of requirements.
Quick design, implementation and testing
User quickly see partial system
Rapid , early feedback ( ex: usability tests from users)
Yes , that´s exactly what I asked for ………….
I try it , what I really want is something slightely different…
Modify and Adapt understanding of the requirements or design , then involve the user again
Ex: Course registration system !!

12. Iterations

13. Another approach :Waterfall Model
All or most of the requirements are defined before development begins
Requirements
Design
Implementation
Test

14. Inception is not Requirement phasee
Chapter 3 and 4
Applying UML and Patterns
-Craig Larman

15. Preliminary Iteration(s)
Do you remember this ?
Phases
Process Workflows
Inception
Elaboration
Construction
Transition
Business Modeling
Requirements
Analysis & Design
Implementation
Test
Deployment
Supporting Workflows
Configuration Mgmt
Management
Environment
Preliminary Iteration(s)
Iter. #1
Iter. #2
Iter. #n
Iter. #n+1
Iter. #n+2
Iter. #m
Iter. #m+1
time

16. Inception : Initial short step in the process What needs to be done?
Describe the initial common vision and business case for this project.
Exhibiting at least one candidate architecture
based on experience gained from similar systems or in similar problem domains
Determine if the project is feasible
Determine if the organization should build or buy the necessary system
Make a rough estimate of the cost and time .
Determine if we should go ahead with the project or stop

17. Example Questions in Inception
Ask questions such as:
What is the vision and business case for this project?
Feasible?
Buy and/or build?
Buy components and glue them together or from scratch?
Estimate potential risks
Rough estimate of cost: Is it $10K-100K or in the millions?
Should we proceed or stop?
If the answer is
YES …..

18. Feasible ? Legal feasibility
No conflicts with legal requirements, e.g. a data processing system must comply with the local Data Protection Acts..
Schedule feasibility
Schedule feasibility is a measure of how reasonable the project timetable is. Given our technical expertise, are the project deadlines reasonable?
Cultural feasibility
Impact on the local and general culture
Resource feasibility

19. Use Cases
Use cases are stories of how actors use (intercat with) the system to fulfill his goal.
Use cases are ‘tasks’ done by the system and has observable value to the actor
Process sale
Place Order
Loan book

20. Use Case 20

21. Use Case 1
Use case
is a collection of related success and failure scenarios that describe an actor using a system to support a goal.
be text documents, not diagrams
Use case modeling is primarily an act of writing text, not drawing diagrams.
There is nothing object-oriented about use cases;
Use cases are a key requirements input to classic OOA/D.
be functional or behavioral requirements that indicate what the system will do. 21

22. The purpose of use cases
Uncover and describe all tasks that need doing in a system (of both human and system actors)
Give a clear and consistent description of what the system should do.
Provide a basis for performing tests that verify the system delivers the functionality stated.
To analyse what functionality that need developing for the system
The use of use cases must mean that the right functional requirements are made of the IT system (the requirements of the business!)

23. Use cases documented in two ways
Use Case diagrams
Give an overview of visible use scenarios in the system
Describes what actors that interact with the system
Describes any linkages between use cases
Verbal description
Describes the content of each use case
Typically uses a pre-defined template

24. Use Case Formats Use case can be written in # formats : Brief Casual
Terse one-paragraph summary, usually the main success scenario.
During early requirements analysis
Casual
Informal, multiple paragraphs that cover various scenarios.
Fully dressed
The most elaborate. All steps and variations are written in detail and there are supporting sections with preconditions etc.
After many use cases have been identified and written in brief format (already in inception % of use cases)

25. Actors - stakeholders
Actor: external entity interacts (behavior) with system, such as a person (identified by role), computer system, or organization; for example, a cashier.
Three kind of Actors - Stakeholders
Primary actor has user goals fulfilled through using services. (e.g., the cashier).
Supporting actor provides a service (e.g., the automated payment authorization service is an example). Often a computer system, but could be an organization or person (external interfaces)
(e.g. : tax calculation )
Offstage actor has an interest in the behavior of the use case, but is not primary or supporting (e.g., a government tax agency). 25

26. How to find Use cases ? Choose the system boundary
Recommended procedure:
Choose the system boundary
Find the primary actor
Find the user goals
Define a use case for each
How?
Ask: what are your goals?
(Instead of what do you do?)

27. How to find Use cases ? Stakeholders Goals Use case Primary actor
Cashier
Xxxxx
Xxxxxx
Xxxxxxx
Xxxxxxxx
xxxxxxxxx
To be able to process sale
Be able to handle return
Process Sale
Handle Return
Supporting actors
Tax calculator
Yyyyyyyy
Offstage actor
Sale tax agency
Zzzzzz

28. Use case diagram
Actor (person)
Actor (system)
use case

29. What we did so far ?

30. Chapter 9 Applying UML and Patterns -Craig Larman
Domain Model
Chapter 9
Applying UML and Patterns
-Craig Larman

31. What is a Domain Model?
Problem domain : area (scope)of application that needed to be investigated to solve the problem
Domain Model : Illustrates meaningful conceptual objects in problem domain.
So domain model are conceptual objects of the area of application to be inestigated

32. Domain model representation?
A domain model is a visual representation of real world concepts (real-situation objects ), that could be : idea, thing , event or object…..etc .
Business objects - represent things that are manipulated in the business e.g. Order.
Real world objects – things that the business keeps track of e.g. Contact , book.
Events that transpire - e.g. sale, loan and payment.
Not of software objects
Is part of business Model artifact (document)

33. Domain Model - UML Notation
Illustrated using a set of domain objects (conceptual classes) with no operations ( no responsibility assigned yet , this will be assigned during design).

34. How to find these conceptual classes and attributes ?

35. Method1: Noun Phrase Identification
Identify Nouns and Noun Phrases in textual descriptions of the domain that could be :
The fully dressed Use Cases
The problem definition.
But not strictly a mechanical process. Why ?
Words may be ambiguous ( such as : System )
Different phrases may represent the same concepts.

36. 2. Cashier starts a new sale. 3. Cashier enters item identifier.
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.
5. System presents total with taxes calculated.
6. Cashier tells Customer the total, and asks for payment.
7. Customer pays and System handles payment.

37. 9. System presents receipt.
8. System logs completed sale and sends sale and payment information to the external
accounting system (for accounting and commissions) and Inventory system (to update inventory).
9. System presents receipt.
10. Customer leaves with receipt and goods (if any).
Extensions (or alternative Flows)
7a. Paying by cash:
1. Cashier enters the cash amount tendered.
2. System presents the balance due, and releases the cash drawer.
3. Cashier deposits cash tendered and returns balance in cash to Customer.
4. System records the cash payment.

38. Method2 : By Category List (read p 140-141)
Common Candidates for classes include:
Descriptions , Roles , Places , Transactions
Containers , Systems , abstract nouns , Rules
Organizations, Events, Processes, catalogs , Records , services.

39. How to find these associations and multiplicities?

40. Association:
Relationship between classes (more precisely, between instances of those classes)indicating some meaningful and interesting connection
Fig. 9.12

41. Fig 10.1 Summary from previous lectures

42. Fig 10.3 Relationship between SSD and Use case

43. Chap 11 Operation Contracts
Chapter 11
Applying UML and Patterns
-Craig Larman

44. Operation Contract
Operation contract identifies system state changes when an operation happens.
Define what each system operation does
An operation is a single event from the system sequence diagram
A domain model is used to help generate an operation contract

45. Operation Contract
When making an operation contract, think of the state of the system before the action and the state of the system after the action.
The conditions both before and after the action should be described in the operation contract.
The pre and post conditions describe state, not actions.

46. Sections of an Operation Contract
Operation: Name of the operation and parameters
Cross References: Use cases and scenarios this operation can occur within
Preconditions: Noteworthy assumptions about the state of the system or objects in the Domain Model before execution of the operation.
Postconditions: This is the most important section. The state of objects in the Domain Model after completion of the operation

47. Postconditions: most important
Describe changes in the state of objects in the domain model after completion of the operation
what instances were created ?
what associations were formed/broken?
what attributes changed?
Are not actions to be performed during the operation

48. Examples of Operation Contracts
From Process Sale Use Case

49. 2. Cashier starts a new sale. 3. Cashier enters item identifier.
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.
5. System presents total with taxes calculated.
6. Cashier tells Customer the total, and asks for payment.
7. Customer pays and System handles payment.

50. POS Domain Model

51. Operation Contract for makeNewSale operation
Operation: makeNewSale()
Cross References:
Use Case: Process Sale
Scenario: Process Sale
Preconditions: none
Postconditions
a sale instance “s” was created (instance creation)
s was associated with the Register (association formed)
attributes of s were initialized

52. s:Sale was created
association was created
attributes of s:Sale were initialized

53. Logical architecture using a UML package diagram.

54. GRASP PATTERN

55. Creator

56. Creator principle Problem: Who creates an A object
Solution: Assign class B the responsibility to create an instance of class A if one of these is true
B “contains or aggregate ” A
B “records” A
B “closely uses” A
B “ has the Initializing data for ” A

57. Creator principle
B “has the Initializing data for ” A that will be passed to A when it is created.
Often initiation is done using a constructor with parameters.
e.g. a Payment instance, when created
needs to be initialized with the Sale total.
Sale class knows Sale total. Good candidate for creating Payment is Sale.
If more than one of the above applies, prefer a class B which aggregates or contains A.

58. Creator Pattern in Monoply

59. Problem Who should create a SalesLineItem?

61. Creating a SalesLineItem
Sale objects are given a responsibility to create SaleLineItem.
The responsibility is invoked with a makeLineItem message

62. Creating a SalesLineItem

63. Why Catalog is reating a Book ?

64. Information Expert

65. Information Expert
Problem : What is a basic principle by which to assign responsibilities to objects?
Solution (advice ) : Assign a responsibility to the information expert , that is the class with the information necessary to fulfill the responsibility.
“Objects do things related to the information they have.”

66. Applying Expert in POS Application
Start assigning responsibilities by clearly stating the responsibility.
Who should be responsible for knowing the grand total of a sale?

67. Who should be responsible for knowing/getting the grand total of a sale?

68. Who responsible for knowing the grand total of a sale?

69. Partial interaction and class diagrams
Add a Sale class to the Design Model.
Express responsibility of knowing the total of a sale with the method named getTotal.
What information do we need to know to determine the line item subtotal?
Sale knows about neighbours (associations), SaleLineitems who is responsible for knowing its subtotal

70. SalesLineItem is Expert for Subtotal
How does the SalesLineItem find out the product price?
SaleLineItem knows about neighbours ( ProductDescription) to get the price.

71. ProductDescription is Expert for Price
“Partial” information experts collaborate to fulfill the responsibility.

72. Another Example

73. Low Coupling Principle

74. “Low Coupling” Principle
Problem:
How to support low dependency, Low change impact, and increased reuse?
Solution: Assign responsibilities so that coupling remains low. Use this principle to evaluate alternatives.
Coupling is a measure of how strongly one class is
connected to,
has knowledge of, or
relies upon other classes.

75. What is a coupling ?
Coupling between classes is dependency of one class on another class
Common form of coupling from Class A to Class B are:
Class A has an attribute (data member or instance variable) that refers to a Class B instance, or Class B itself.

76. What is a coupling ?
Common form of coupling from Class A to Class B are:
Class A has a method which references an instance of Class B, or Class B itself, by any means. These typically include a parameter or local variable of type Class B, or the object returned from a message being an instance of Class B.

77. What is a coupling (continued) ?
Common form of coupling from Class A to Class B are:
Class A is a direct or indirect subclass of Class B.
Class B is an interface, and Class A implements that interface.

78. Common Forms of Coupling in OO Languages
Type X has an attribute (data member, instance variable) that refers to type Y or an instance of Y.
An object of type X calls on services of a type Y object.
Type X has a method that references an instance of type Y (e.g., parameter, local variable, object returned from a method).
Type X is a subclass of type Y.
Type X implements the interface Y.

79. Low Coupling - POS Case Study
What class should be responsible for creating a Payment instance and associating it with the Sale?
Register?
Sale?
Creator pattern suggests Register should create the Payment.
A register records a payment in the real world.

80. What if Register creates Payment
Register is coupled to both Sale and Payment.

81. What if Sale creates Payment ?
Assuming that the Sale must eventually be coupled to knowledge of a Payment, having Sale create the Payment does not increase coupling.
NB : Low Coupling and Creator may suggest different solutions.

82. Controller Pattern

83. Controller Pattern UI layer does not contain any business logic
Problem:
How to connect UI layer to the business logic layer?
Solution:
If a program receive events from external sources
other than its graphical interface, add an event class
to decouple the event source(s) from the objects
that actually handle the events.

84. Controller Pattern
What first object beyond the UI layer receives and coordinates (“controls”) a system operation message?
Solution: Assign the responsibility to a class that represents one of the following options:

85. Options for Control Responsibility
Represents the overall system or a root object.
e.g., an object called System or Register
Suitable when there are not too many system events or when UI cannot choose between multiple controllers.
A controller for each use case
e.g. processSaleHandler

86. Controller choices ?
Controllers
Register (POS Terminal) is a specialized device with software running on it.
ProcessSaleHandler represents a receiver of all system events of a use case scenario.

87. What should be Controller for enterItem?

88. Bad Design

89. Good Design
Controller should delegate the work that needs to be done to other objects.

90. A use case controller handles system events for a single use case.
Can maintain information about the state of the use case.
Different controller for each use case.
Not a domain object, but artificial construct to support the system.
Use when there are many system events.
Factors handling into separate classes.

91. Controller

92. Controller: Benefits Increased potential for reuse
Ensures that the application logic is not handled in the interface layer. Thus, the external event raisers are independent of internal event handlers
Plug & Play interfaces
Since the interface is not bound to the controllers, it can be replaced or updated without much impact
Verifying the reasoning of the use case
Allows us to verify that the system operations occur in a logical sequence. For example: makePayment() is not called before endSale()

93. High Cohesion

94. High Cohesion
A class with low cohesion does too much unrelated work and are:
Hard to comprehend
Hard to reuse.
Hard to maintain.
Delicate and constantly affected by change
Cohesion is a measure of how strongly related the responsibilities of an element (classes, subsystems) are.

95. High Cohesion Problem How to keep complexity manageable? Solution
Assign a responsibility so that cohesion remains high

96. Reduced cohesion of Register(creator pattern)
Low cohesion:
Register is taking part of the responsibility for fulfilling “makePayment” operation and many other unrelated responsibility ( 50 system operations all received by Register).then it will become burden with tasks and become incohesive

97. Better solution Higher Cohesion and Lower Coupling
Delegate the payment creation responsibility to “Sale” to support high cohesion

98. Conclusion
Like Low Coupling, High Cohesion is a principle to keep in mind during all design decisions
It is important to evaluate design constantly with respect to GRASP principles, regardless of the design result.