1. Object Oriented Design
Chapter Three
Object Oriented Design

2. Object Oriented Design
Object oriented design transforms the analysis model created using OO analysis into design model that serves as a blueprint for software construction.
There are four layers of OO design pyramid.
1. The Subsystem Layer- subsystems to achieve customers requirements.
2. The Class and Object Layer- contains hierarchies.
3. The Message Layer- design details for communication.
4. The Responsibilities Layer- contains data structure & algorithmic design for attributes and operations for each objects.

3. Object Oriented Design

4. Object Oriented Design Steps
To perform object-oriented design, a software engineer should perform the following generic steps:
Describe each subsystem and allocate it to processors and tasks.
Choose a design strategy for implementing data management, interface support, and task management.
Design an appropriate control mechanism for the system.
Perform object design by creating a procedural representation for each operation and data structures for class attributes.
Perform message design using collaborations between objects and object relationships.
Create the messaging model.
Review the design model and iterate as required.

5. Relationship Between OOA and OOD

6. Relationship Between OOA and OOD
Subsystem design is derived by:
considering overall customer requirements (represented with use-cases)
events and states that are externally observable (the object-behavior model)
Class and object design :
mapped from the description of attributes, operations, and collaborations contained in the CRC model.
Message design driven by:
the object-relationship model
Responsibilities design:
is derived using the attributes, operations, and collaborations described in the CRC model.

7. Design Issues
Five criteria for judging a design method's ability to achieve modularity:
Decomposability
Composability
Understandability
Continuity
Protection
Decomposability—the facility with which a design method helps the designer to decompose a large problem into sub problems that are easier to solve.
Composability—the degree to which a design method ensures that program components (modules), once designed and built, can be reused to create other systems.
Understandability—the ease with which a program component can be understood without reference to other information or other modules.
Continuity—the ability to make small changes in a program and have these changes manifest themselves with corresponding changes in just one or a very few modules.
Protection—an architectural characteristic that will reduce the propagation of side effects if an error does occur in a given module.

8. Most important early OOD methods:
The Booch method.
encompasses both "micro development process" and  "macro development process."
The Rumbaugh method.
encompasses a design activity that encourages design to be conducted at two different levels of abstraction: System design and Object design.
The Jacobson method.
design model emphasizes traceability to the OOSE analysis model.
The Coad and Yourdon method.
design approach addresses not only the application but also the infrastructure for the application
focuses on the representation of major system components:
Most important early OOD methods:
The Booch method.
encompasses both "micro development process" and  "macro development process."
design context
macro development encompasses:
architectural planning activity that:
 clusters similar objects in separate architectural partitions
layers objects by level of abstraction
identifies relevant scenarios
creates a design prototype
validates the design prototype by applying it to usage scenarios.
micro development:
defines a set of "rules" that govern:
the use of operations and attributes and the domain-specific policies for memory management
error handling and other infrastructure functions
develops scenarios that describe the semantics of the rules and policies
creates a prototype for each policy
instruments and refines the prototype
reviews each policy so that it "broadcasts its architectural vision"
The Rumbaugh method.
encompasses a design activity that encourages design to be conducted at two different levels of abstraction:
 System design -  
focuses on the layout of components that are needed to construct a complete product or system
analysis model is partitioned into subsystems -> allocated to processors and tasks.
strategy for implementing data management is defined
global resources and the control mechanisms required to access them are identified
Object design –
emphasizes the detailed layout of an individual object.
operations are selected from the analysis model and algorithms are defined for each operation.
data structures appropriate to attributes and algorithms are represented.
classes and class attributes are designed so they optimize data access and improve computational efficiency.
a messaging model is created to implement the object relationships (associations).
The Jacobson method.
design model emphasizes traceability to the OOSE analysis model
1.     idealized analysis model is adapted to fit the real world environment.
2.     primary design objects, called blocks are created and categorized as interface blocks, entity blocks, and control blocks
3.     communication between blocks during execution is defined
4.     blocks are organized into subsystems.
The Coad and Yourdon method.
design approach addresses not only the application but also the infrastructure for the application
focuses on the representation of four major system components:
1.     problem domain component
2.      human interaction component
3.      task management component
4.      data management component.

9. Collaboration
A collaboration is the specification of how an element such as classifier(including a class, interface, component, node or use case) or an operation is realized by a set of classifiers and associations playing specific roles used in a specific ways.
Collaborations have two aspects:
Structural part-
Specifies the classes, interfaces and other elements that work together.
Structural part of collaboration is typically rendered by a class diagram.
Behavioral part-
Specifies the dynamics of how those elements interact.
Behavioral part is rendered by using interaction diagram.

10. A Collaboration

11. Structural Aspects of Collaboration
Class Diagram

12. Behavioral Aspects of Collaboration

13. Organizing Collaborations

14. Collaboration Diagram
A collaboration diagram, also called a communication diagram or interaction diagram, is an illustration of the relationships and interactions among software objects in the Unified Modeling Language (UML).
An interaction diagram emphasizes the structural organization of the objects that send and receive messages.

15. Collaboration Diagram
Collaboration diagrams have two features that distinguish them from sequence diagrams.
First, there is the path. To indicate how one object is linked to another.
Second, there is the sequence number. To indicate the time order of a message, you prefix the message with a number.
As Shown in following diagrams:

16. Example of Collaboration Diagram

17. Message – Link - Sequence
Flow of control within an operation, a class, a component, a use case, or the system as a whole.
Set of messages in a particular context to accomplish a purpose.

18. Links and Association • A Link is a semantic connection among objects
• A Link is an instance of an association

19. Link specification for an Object

20. Action Categories

21. Messages

22. Flow of Control - by Time

23. Flow of Control - by Organization

24. Case Study of simple HMS
A simple Hospital Management System (HMS) consists of receptionist, doctor, nurse and patient. Firstly the patient should get appointment from receptionist. The receptionist takes appointment from doctor. If the doctor is available, receptionist confirms to the patient. Then the patient consults to the doctor, so that doctor treats the patient. After completing treatment, receptionist asks for payment so that the patient pays fees and leaves the hospital.
Draw a collaboration diagram for above mentioned scenario of HMS.

25. Collaboration diagram for simple HMS

26. Class Work
Draw a Collaboration diagram for online banking system with authentication. OR
Draw a Collaboration diagram for facebook authentication system.
Hint: User/client, fb application/web browser, fb authentication server, fb web server.

27. Case Study -A
Ministry of Health and Population is willing to computerize its system. This new system will be able to tell the population of the country, zone and district and even of the ward of specific place. The system will update its data in monthly basis so that the birth rate and death rate can be easily seen. The home page is displayed when a person enters to the system. Administrators can enter to the admin panel by logging in with an ID and a password. He/she has privileges to enter and modify the data into the database. On the other hand, normal users can view the data but not modify them. They can also visualize the data in graphical form with animated charts, maps as well as in tabular form based on their selection of data. Besides, they can also view the forecasted data. (Make your assumptions if necessary)

28. Case Study- B
“Buy a landline telephone service scenario” Customer arrives at the reception of Telephone office and makes query about landline telephone. Receptionist requests to fill up an application form and send him to Sales department. Sales department asks for nearest/neighbor’s telephone number and search in the system (Sales Division system) so that SD system displays all information including availability of telephone distribution point (DP). If point is not available, sales department tells customer to submit application form and tells him that he will make contact if point became available in future. And customer leaves the office. Otherwise, sales officer enters customer details in SD system and sends him to telephone distribution department. Telephone distribution department makes cost estimation and forward him to cash counter for payment. Cashier receives cash and prints receipt after payment process and send him back to telephone distribution department. Customer presents receipt to the telephone distribution department so that telephone distribution department provides new landline telephone service to the customer.

29. Object Diagram
An object diagram is a diagram that shows a set of objects and their relationships at a point in time.
Object diagrams are derived from class diagrams so object diagrams are dependent upon class diagrams.
Object diagrams represent an instance of a class diagram. The basic concepts are similar for class diagrams and object diagrams. Object diagrams also represent the static view of a system but this static view is a snapshot of the system at a particular moment.

30. Example Object Diagram

31. Modeling Object Structure

32. Autonomous Robot : Object Structure Modeling

33. A well-structured object diagram
Drawing an object diagram

34. Component Diagrams
Component diagrams are different in terms of nature and behavior. Component diagrams are used to model physical aspects of a system.
Now the question is what are these physical aspects? Physical aspects are the elements like executables, libraries, files, documents etc which resides in a node.
So component diagrams are used to visualize the organization and relationships among components in a system. These diagrams are also used to make executable systems.

35. Purpose of the component diagram
The purpose of the component diagram can be summarized as:
Visualize the components of a system.
Construct executables by using forward and reverse engineering.
Describe the organization and relationships of the components.

36. How to draw Component Diagram?
Before drawing a component diagram the following artifacts are to be identified clearly:
Files used in the system.
Libraries and other artifacts relevant to the application.
Relationships among the artifacts.
After identifying the artifacts the following points needs to be followed:
Use a meaningful name to identify the component for which the diagram is to be drawn.
Prepare a mental layout before producing using tools.
Use notes for clarifying important points.

37. Where to use Component Diagrams?
The usage of component diagrams can be described as:
Model the components of a system.
Model database schema.
Model executables of an application.
Model system's source code.

38. Component Diagrams

39. Component Diagrams

40. Component Diagram [for withdrawal of cash]
policy.dll
Bank
Server.exe
Branch
customer.dll
Bank.dll
Branch
Bank.exe
ATM.exe

41. Forward Engineering of Component Diagram
To forward engineer a component diagram:-
For each component, identify the classes or collaborations that the component implements.
Choose the target for each component. Your choice is basically between source code (a form that can be manipulated by development tools) or a binary library or executable (a form that can be dropped into a running system).
Use tools to forward engineer your models.

42. Reverse Engineering of Component Diagram
To reverse engineer a component diagram:-
Choose the target you want to reverse engineer. Source code can be reverse engineered to components and then classes. Binary libraries can be reverse engineered to uncover their interfaces. Executables can be reverse engineered the least.
Using a tool, point to the code you'd like to reverse engineer. Use your tool to generate a new model or to modify an existing one that was previously forward engineered.
Using your tool, create a component diagram by querying the model. For example, you might start with one or more components, then expand the diagram by following relationships or neighboring components. Expose or hide the details of the contents of this component diagram as necessary to communicate your intent.

43. Deployment Diagram
Deployment diagrams are used for describing the hardware components where software components are deployed. 
Component diagrams are used to describe the components and deployment diagrams shows how they are deployed in hardware.
A deployment diagram consists of :
Nodes
Relationships among nodes

44. The Purpose/Uses of deployment diagrams
To model the hardware topology of a system.
To model embedded system.
To model hardware details for a client/server system.
To model hardware details of a distributed application.
Forward and reverse engineering.

45. .

46. Deployment diagram Branch Bank_ Bank.exe Ethernet Ethernet Bank_
ATM_
server
machine
BankServer.exe
ATM.exe

47. Deployment Diagram

48. To model embedded systems

49. To model client/server systems

50. To model distributed systems

51. Activity Diagram
An activity diagram shows the flow from activity to activity.
The execution of an activity ultimately expands into the execution of individual actions,, each of which may change the state of the system or communicate messages.
Actions encompass calling another operation, sending a signal, creating or destroying an object, or some pure computation such as evaluating an expression.

52. Activity Diagram

53. Transitions

54. Branching

55. .

56. Fork and Join
A fork may have one incoming transition and two or more outgoing transitions, each of which represents an independent flow of control.
In the join, the activities associated with each of the paths continues in parallel. At the join, the concurrent flows synchronize, meaning that each waits until all incoming flows have reached the join, at which point one flow of control continues on below the join.
NOTE: Joins and forks should balance, meaning that the number of flows that leave a fork should match the number of flows that enter its corresponding join.

57. .

58. Swimlanes in Activity diagrams
You'll find it useful, especially when you are modeling workflows of business processes, to partition the activity states on an activity diagram into groups, each group representing the business organization responsible for those activities.
In the UML, each group is called a swimlane because, visually, each group is divided from its neighbor by a vertical solid line,
A swimlane specifies a set of activities that share some organizational property.
Each swimlane may be implemented by one or more classes. In an activity diagram partitioned into swimlanes, every activity belongs to exactly one swimlane, but transitions may cross lanes.

59. Activity diagram of ATM Scenario

60. Object Flow
Objects may be involved in the flow of control associated with an activity diagram.
For example, Process order will create an Order object, Ship order will change the state of the Order object to filled.

61. Object Flow

62. State Machine
A state machine is a behavior that specifies the sequences of states an object goes through during its lifetime in response to events, together with its responses to those events.
A state is a condition or situation during the life of an object during which it satisfies some condition, performs some activity, or waits for events.
An event is the specification of a significant occurrence that has a location in time and space.
In the context of state machines, an event is an occurrence of a stimulus that can trigger a state transition.
A transition is a relationship between two states indicating that an object in the first state will perform certain actions and enter the second state when a specified event occurs and specified conditions are satisfied.
An activity is ongoing nonatomic execution within a state machine.
An action is an executable computation that results in a change in state of the model or the return of a value.

63. Example
Suppose a person is taking a taxi from place X to place Y. The states of the person may be: Waiting (waiting for taxi), Riding (he has got a taxi and is travelling in it), and Reached (he has reached the destination). The following figure depicts the state transition.

64. Example Cont..

65. State Machine

66. Composite State

67. Example ATM

68. Explanation
Here, the Active state has a substructure, containing the substates Validating, Selecting, Processing, and Printing.
The state of the ATM changes from Idle to Active when the customer enters a ATM card in the machine.
On entering the Active state, the entry action readCard is performed.
Starting with the initial state of the substructure, control passes to the Validating state, then to the Selecting state, and then to the Processing state. After Processing, control may return to Selecting (if the customer has selected another transaction) or it may move on to Printing. After Printing, there's a completion transition back to the Idle state.
Notice that the Active state has an exit action, which ejects the customer's credit card.

69. 52 Example Statecharts OFF ON 1 2 counting
The following simple statechart depicts the life of a push/push light switch :-
push/turn-on
OFF ON
push/turn-off
Folding of states
The state of an object can be characterised entirely it’s location in the diagram,
but frequently this leads to an explosion of states. These can be folded on each
other by introducing attributes, e.g. the two ways of representing a counter :-
pulse/
pulse/
pulse/ 1 2
or, when folded with count attribute
pulse/count++
counting

70. Statechart for a simple ATM54
Statechart for a simple ATM
The following represents a very simple ATM machine and illustrates
some of these features :-
insert card/
prompt for pin
digit/
display
AWAIT
PIN
[not valid 4th time]/
timeout
[not valid]/
re-prompt
4th digit/
validate
[timeout]/
eat card
IDLE
Enter choice/
dispense & eject
VERIFYING
PIN
AWAIT
CHOICE
[valid]/
prompt for choice
complete
eject card/
take card/
complete
AWAIT
TAKE CARD
cancel trans/
eject card

71. Statechart for a simple ATM55
Statechart for a simple ATM
This becomes the following at a higher level of abstraction:-
insert card/
prompt for pin
OBTAIN
PIN & CHOICE
[timeout]/
eat card
IDLE
eject card/
take card/
complete
AWAIT
TAKE CARD
cancel trans/
eject card
complete

72. Statechart for a simple ATM56
Statechart for a simple ATM
Or at an even higher level of abstraction :-
insert card/
prompt for pin
PROCESS
TRANSACTION
[timeout]/
eat card
IDLE
complete

73. Class work
Draw a State machine diagram for any one scenario of your minor project or of your choice. OR
See Next Slides

74. Exam Question IOE 2069 Bhadra

75. Exam Question IOE 2070 Bhadra

76. Sate diagram of control unit of given digital clock

77. Objects and Visibility
Q. What is visibility? A. Visibility is the ability of one object to see or have reference to another.

78. Visibility Between Objects
Q. When is visibility necessary? A. To send a message from one object to another, the receiver object must be visible to the sender, so the sender has to have a pointer or reference to the receiver.

79. Visibility Between Objects
Example: Q. If A sends messages to B, which must be visible to which? A. B is visible to A means A can send a message to B. Some say that "B is an acquaintance of A".

80. Visibility Between Objects

81. Four Kinds of Visibility
How visibility can be achieved from object A to object B:
Attribute visibility - B is an attribute of A
Parameter visibility - B is a parameter of a method of A
Local visibility - B is a local object in a method of A
Global visibility - B is in some way globally visible

82. Attribute Visibility
Attribute visibility from A to B exists when B is an attribute of A
Relatively permanent visibility because it persists as long as A and B exist
Common form of visibility

83. Attribute Visibility
To Illustrate this, in a Java class definition for Register, a Register instance may have attribute visibility to a ProductCatalog, since it is an attribute(Java instance variable) of the Register.
public class Register {
private ProductCatalog catalog; }

84. Attribute Visibility

85. Parameter Visibility
Parameter visibility from A to B exists when B is passed as a parameter to a method of A.
Relatively temporary visibility because it persists only within the scope of the method
It is second most common form of visibility in the OO systems.

86. Parameter Visibility

87. Explanation
To illustrate, when a makeLineItem message is sent to a Sale instance, a ProductSpecification instance is passed as a parmeter. Within the scope of makeLineItem method, the Sale has parameter visibility to a ProductSpecification .

88. Local Visibility
Local visibility from A to B exists when B is declared as a local object within a method of A.
Relatively temporary visibility since it persists only within the scope of the method.

89. Local Visibility There are two common means by which
local visibility is achieved:
Create a new local instance and assign it to a local variable.
Assign the returning object from a method invocation to a local variable. A variation of this method does not explicitly declare a variable, but one implicitly exists as the result of a returning object from a method invocation.

90. Global Visibility
Global visibility from A to B exists when B is global to A.
Relatively permanent visibility since it persists as long as A and B exist.
The least common form of visibility in OO Systems.
Ways to achieve global visibility:
Assign an instance to a global variable.
Use the Singleton pattern.

91. Design Pattern
Design pattern is a way of reusing abstract knowledge about a problem and its solution.
A design pattern is not a finished design that can be transformed directly into code.
It is a description or template for how to solve a problem that can be used in many different situations.
Design pattern captures the static and dynamic structure and collaboration among key participants in software designs. They can be used across different domains.
Such as GRASP, GoF.

92. GRASP
General Responsibility Assignment Software Patterns (or Principles), abbreviated GRASP, consist of guidelines for assigning responsibility to classes and objects in object-oriented design.
The different patterns and principles used in GRASP are:
Controller,
Creator,
Indirection,
Information Expert,
High Cohesion,
Low Coupling,
Polymorphism,
Protected Variations, and
Pure Fabrication.
All these patterns provide solution to some software problem, and in almost every case these problems are common to almost every software development project.

93. GRASP Cont.. Controller:
Who should be responsible for handling the actor requests?
Creator:
Who should be responsible for creating a new instance of some class?
Information Expert:
Which class should be responsible for doing certain things?
High Cohesion- degree to which elements of a module belong together.
Low Coupling- degree of interdependence between software modules.

94. Gang of Four (GoF) Design Pattern
In 1994, four authors Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides published a book titled Design Patterns - Elements of Reusable Object-Oriented Software which initiated the concept of Design Pattern in Software development.
These authors are collectively known as Gang of Four (GoF).
GoF describes 23 design patterns which can be classified in three categories:

95. .

96. Gang of Four (GoF) Design Pattern

97. Gang of Four (GoF) Design Pattern Cont..

98. Factory Pattern
Factory pattern is one of most used design pattern in Java.
This type of design pattern comes under creational pattern as this pattern provides one of the best ways to create an object.
In Factory pattern, we create object without exposing the creation logic to the client and refer to newly created object using a common interface.

99. Implementation/Example
We're going to create a Shape interface and concrete classes implementing the Shape interface. A factory class ShapeFactory is defined as a next step.
FactoryPatternDemo, our demo class will use ShapeFactory to get a Shape object. It will pass information (CIRCLE / RECTANGLE / SQUARE) to ShapeFactory to get the type of object it needs.

100. Cont..

101. Cont.. Step 1 Step 2 Step 3 Step 4 Create an interface : Shape.java
Create concrete classes implementing the same interface: Rectangle.java
Step 3
Create a Factory to generate object of concrete class based on given information. : ShapeFactory.java
Step 4
Use the Factory to get object of concrete class by passing an information such as type. :
FactoryPatternDemo.java

102. Singleton Pattern Intent/Problem:
Ensure a class has only one instance, and provide a global point of access to it.
Solution:
Define a class method that returns the singleton object, instantiating it if it does not exist.
Example:
A print queue—many programs must access one queue.
Only one file system, window manager.
Digital filter will have only one A/D convertor.

103. e.g. in php Creation of single instance for database connection.
$con=mysql_connect(“host”, “user”, “password”);
if (!$con)
die(“Couldn’t connect to the database ”);
mysql_select_db($db_name, $con) or die(“can not find database”);

104. Implementation/Example of Singleton pattern

105. Explanation
We're going to create a SingleObject class. SingleObject class has its constructor as private and has a static instance of itself.
SingleObject class provides a static method to get its static instance to outside world. SingletonPatternDemo, our demo class will use SingleObject class to get a SingleObject object.

106. Let us implement above scenario using java

107. Cont..

108. Framework
Framework is made up of group of concrete classes which can be directly implemented on an existing platform.
Frameworks are often written in programming languages.
It is a large entity comprising of several design patterns.
Frameworks are concerned with specific application domain e.g. database, web application etc.
 A design pattern is a type of pattern and is more like a concept, whereas a framework is something already coded and to be used repetitively.
Patterns support reuse of software architecture and design. 
Frameworks support reuse of detailed design and code .
Together, design patterns and frameworks help to improve software quality and reduce development time – e.g., reuse, extensibility, modularity, performance etc.

109. Visibility in the UML Public:
Any outside classifier with visibility to the given classifier can use the feature; specified by the symbol “+”
Protected:
Any descendant of the classifier can use the feature; specified by the symbol “#”
Private:
Only the classifier itself can use the feature; specified by the symbol “-”

110. Terms: Classifier
A classifier is a mechanism that describes structural and behavioral features.
Modeling elements that can have instances are called classifiers.
Classifiers include classes, interfaces, datatypes, signals, components, nodes, use cases, and subsystems.
A classifier has structural feature (in the form of attributes), as well as behavioral features (in the form of operations).

111. CRC Card
A Class Responsibility Collaborator (CRC) model is a collection of standard index cards that have been divided into three sections, as depicted in Figure (see next slide).
A class represents a collection of similar objects.
A responsibility is something that a class knows or does.
A collaborator is another class that a class interacts with to fulfill its responsibilities.

112. CRC Card

113. Class Diagram

114. What is Class diagram?
A class diagram shows the existence of classes and their relationships in the logical view of a system
UML modeling elements in class diagrams are:
Classes, their structure and behavior.
relationships components among the classes like association, aggregation, composition, dependency and inheritance
Multiplicity and navigation indicators
Role names or labels.

115. Major Types of classes:
Concrete classes
A concrete class is a class that is instantiable; that is it can have different instances.
Only concrete classes may be leaf classes in the inheritance tree.
Abstract classes
is a class that has no direct instance but whose descendants classes have direct instances.
can define the protocol for an operation without supplying a corresponding method we call this as an abstract operation.
operation defines the form of operation, for which each concrete subclass should provide its own implementation.

116. Association Aggregation Composition Inheritance Dependency
RELATIONSHIP
Association
Aggregation
Composition
Inheritance
Dependency
Instantiation

117. ASSOCIATION These are the most general type of relationship:
It denotes a semantic connection between two classes
It shows Bi-directional connection between two classes
It is a weak coupling as associated classes remain somewhat independent of each other
Example:
CUSTOMER
ATM system

118. AGGREGATION
This is a special type of association
The association with label “contains” or “is part of” is an aggregation  represents “has a “ relationship
It is used when one object logically/physically contains other
The container is called as aggregate
It has a diamond at its end
The components of aggregate can be shared with others
It expresses a whole - part relationships, like …
ATM card
Customer

119. AGGREGATION
This is a special type of association
The association with label “contains” or “is part of” is an aggregation  represents “has a “ relationship
It is used when one object logically/physically contains other
The container is called as aggregate with diamond at end
The components of aggregate can be shared with others
It expresses a whole - part relationships, like …

120. COMPOSITION This is a strong form of aggregation
It expresses the stronger coupling between the classes
The owner is explicitly responsible for creation and deletion of the part
Any deletion of whole is considered to cascade its part
The aggregate has a filled diamond at its end
Window
Client Area

121. INHERITANCE
The inheritance relationship helps in managing the complexity by ordering objects within trees of classes with increasing levels of abstraction. Notation used is solid line with arrowhead, shown below.
Generalization and specialization are points of view that are based on inheritance hierarchies.
Account
CurrentAccount
SavingAccount

122. Generalization

123. DEPENDENCY
Dependency is semantic connection between dependent and independent model elements.
This association is unidirectional and is shown with dotted arrowhead line.
In the following example it shows the dependency relationship between client and server.
The client avails services provided by server so it should have semantic knowledge of server.
The server need not know about client.
Client
Server

124. INSTANTIATION
This relationship is defined between parameterized class and actual class.
Parameterized class is also referred as generic class.
A parameterized class can’t have instances unless we first instantiated it
Example:
Queue<int>
Queue
Element

125. Different Relationships

126. Adornments : Name & Role

127. Adornments : Multiplicity

128. What is Cardinality?
Definition: Number of instances of each class involved in the dialogue is specified by cardinality.
Common multiplicity values:
Symbol Meaning
1 One and only one
Zero or one
M…N From M to N (natural integer)
0..* From zero to any positive integer
1..* From one to any positive integer
Also thought can be given about navigability to every applicable relationship.

129. Structural Relationships

130. Prep by: Arun Timalsina.
Prep by: Arun Timalsina

131. Draw a class diagram of your minor project.CW
Draw a class diagram of your minor project.

132. A Class Diagram Class diagram commonly contains Classes Interfaces
Collaborations
Dependency, generalization associations etc.

133. Class Diagram : Static design view
To model the vocabulary of a system
Modeling the vocabulary; a decision about which abstractions are part of the system under consideration and about which fall outside its boundaries; abstractions and their responsibilities
To model simple collaborations
A collaboration is a society of classes, interfaces, & other elements that work together to provide some cooperative behavior
To model a logical database schema
A schema as the blueprint for the conceptual design of the database

134. Simple Collaboration Model

135. Modeling a Schema

136. Forward Engineering
Primary product of development team : software code but not a diagram
Why Modeling ? - predictably deliver at the right time the right SW that satisfies the evolving goals of its users and the business
Model – Implementation : sync with one another
Not all UML models map to Code
Business process activity diagram (people oriented activities)
HW piece component of Systems model
Forward Engineering : The process of transforming a model into code through a mapping to an implementation language.

137. Forward Engineering Why do we need models in addition to code?
Forward Engineering results in a loss of information.
UML models are semantically richer than implemented code in any particular OO language.
Structural features, such as collaborations, and behavioral features, such as interactions can be visualized clearly in the UML, but not so clearly from raw code.

138. Forward Engineer : A class Diagram
Indentify the rules for mapping to the implementation language
Matching the semantics of the chosen language with UML features. E.g. Smalltalk permits only single inheritance
Tools available to forward engineer UML models
public abstract class EventHandler {
EventHandler successor;
private Integer currentEventID;
private String source;
EventHandler() {}
public void handleRequest() {} }

139. Reverse Engineering
Reverse Engineering : The process of transforming code into a model through a mapping from a specific implementation language.
Code : lower detail ; Model : higher level info
Reverse engineering is incomplete due to loss of info at forward engineering process.
Without source comments and other details, reverse engineering is hard.
Both opportunity and challenge.

141. OOAD---Iterative & Incremental Approach
Identify objects
Validate Classes
& Objects
Identify Messages
Group Objects
into classes
Group classes
into domains
Identify & classify
Class relationships
Identify class
behavior

142. Refinement attributes
Constraints:
Constraints are functional relationship between the entities and object
model. The entities include objects, classes, attributes, association, links.
A constraint restricts the values that entities can assume.
UML doesn't specify a particular syntax for constraints, other than they should appear between braces, so they may therefore be expressed using natural language, pseudo code, navigation expression or mathematical expression
UML1.2 does prefer the use of a constraint language OCL i.e. Object Constraint Language, which is subset of UML.

143. Refinement attributes
Example:Constraints
Number of withdrawal transaction should be less than five per day.
Constraint on the same class.
Transaction
{No. of transaction <=5 /day}
No window will have an aspect ratio i.e. (length/width) of less than 0.8 or > 1.5
Window
length/width
A constraint between the
properties of the same object
{0.8<=length/width <= 1.5}

144. Refinement attributes
Qualifier:
UML provides a role of constraint notation to indicate different kind of collections that may be inherent in the analysis model
Common role constraints for multi valued roles include
{ordered} Collection is maintained in sorted manner
{bag} Collection may have multiple copies of same item.
{set} Collection may have at most one copy of given item.
Some constraints may be combined such as: {ordered set}

145. Refinement attributes
Qualifier:
Another common design scheme is to use a key value to retrieve an item from the collection. This is called as qualified association and the key value as qualifier.
A qualified association is the UML equivalent of a programming concept variously known as associative arrays, maps,dictionaries
A qualified association relates two object classes and a qualifier
The qualifier is a special attribute that reduced the effective multiplicity of an association.
One to many and many to many association may be qualified.

146. Refinement attributes
Check for many to many relationship, if any, normalize with qualifier or association class.
Check for the scope forming abstract classes and template classes.
Check for helper functions.
Thought can be given for using the design patterns.