Sie sind auf Seite 1von 30


Object-oriented design is the discipline of defining the objects and their interactions to solve a problem that was identified and documented during object-oriented analysis. The input for object-oriented design is provided by the output of object-oriented analysis. Analysis and design may occur in parallel, and in practice the results of one activity can feed the other in a short feedback cycle through an iterative process. Both analysis and design can be performed incrementally, and the artifacts can be continuously grown instead of completely developed in one shot.

What is UML?
The Unified Modeling Language (UML) is a standard language for specifying, visualizing, constructing, and documenting the artifacts of software systems, as well as for business modeling and other non-software systems. The UML represents a collection of best engineering practices that have proven successful in the modeling of large and complex systems The UML is a very important part of developing object oriented software and the software development process. The UML uses mostly graphical notations to express the design of software projects. Using the UML helps project teams communicate, explore potential designs, and validate the architectural design of the software.

Goals of UML
The primary goals in the design of the UML were: 1. 2. 3. 4. 5. 6. 7. Provide users with a ready-to-use, expressive visual modeling language so they can develop and exchange meaningful models. Provide extensibility and specialization mechanisms to extend the core concepts. Be independent of particular programming languages and development processes. Provide a formal basis for understanding the modeling language. Encourage the growth of the OO tools market. Support higher-level development concepts such as collaborations, frameworks, patterns and components. Integrate best practices.

When you make a model you are making a mapping from the problem domain to a representation of the system you are modeling

When you work object-oriented the model tends to be close to the system modeled, and a program execution can be regarded as a simulation of the behavior of the system.

Why Do We Model?
If you want to make a building you first make a blueprint of the building to make, in the same way you should make a model of the system you want to make. As the complexity of systems increases, so does the importance of good modeling techniques. Models give us a template that guides us in constructing a system. Models help us visualize a system at different levels of abstraction, this makes it easier to manage complexity and to understand the system. Models document the decisions we have made. Models help for communication between different stakeholders.

The importance of modeling

A model is a simplification of reality. We build models so that we can better understand the system we are
Developing. Through modeling, we achieve four aims 1. Models help us to visualize a system as it is or as we want it to be. 2. Models permit us to specify the structure or behavior of a system. 3. Models give us a template that guides us in constructing a system. 4. Models document the decisions we have made.

Relationships in the UML

A relationship is a connection among things.

Five kinds of relationships in the UML

1. Dependency 2. Association 3. Generalization 4. Realization 5. Aggregation

1) Dependency
In UML, a dependency relationship is a relationship in which one element, the client, uses or depends on another element, the supplier.

You can use dependency relationships in class diagrams, component diagrams, deployment diagrams, and use-case diagrams to indicate that a change to the supplier might require a change to the client. Dependency is a semantic relationship between two things. in which a change to one thing
may affect the semantics of the other thing

Graphically, a dependency is rendered as a dashed line

Dependencies Example

2) Association :
Association is a structural relationship that specifies that objects of one thing are connected to objects of another.


Describe a group of links with common structure and semantics Are to links what classes are to objects. Can have a different name in each direction
An association is a structural relationship that specifies that objects of one thing are connected to
objects of another.

An association that connects exactly two classes is called a binary association. Associations that connect more than two classes; these are called n-ary associations. Graphically, an association is rendered as a solid line connecting the same or different

An association can have a name, and you use that name to describe the nature of the relationship. Give a direction to the name by providing a direction triangle that points in the direction you intend to read the name


When a class participates in an association, it has a specific role that it plays in that relationship. Explicitly name the role a class plays in an association.
person playing the role of employee is associated with a Company playing the role of employer.



An association represents a structural relationship among objects. The number of instances of one class that may be related to an instance of another constrains the number of links between objects
In many modeling situations, its important for you to state how many objects may be connected across an instance of an association. This "how many" is called the multiplicity of an association's role,


One class can be relate to another in a

One-to-one One-to-many One-to-one or more One-to-zero or one One-to-a bounded interval (one-to-two through twenty) One-to-exactly n One-to-a set of choices (one-to-five or eight)

Multiplicity can be expressed as

Exactly one - 1 Zero or one - 0..1 Many - 0..* or * One or more - 1..* Exact Number - e.g. 3..4 or 6 Or a complex relationship e.g. 0..1, 3..4, 6..* would mean any number of objects other than 2 or 5

Association Multiplicity
A cricket team has 11 players. One of them is the captain. A player can play only for one Team. The captain leads the team members.


3) Generalization :
Relationship which organizes classes based on their similarities and differences Relationship between a general thing (the super class) and a more specific thing (the subclass) sometimes called is-a-kind-of or is-a relationship Child is substitutable for the parent Child inherit properties of parent corresponds to inheritance in object-oriented languages
A generalization is a relationship between a general thing (called the super class or parent) and a more specific kind of that thing (called the subclass or child). Generalization is sometimes calledan "is-a-kind-of" relationship

Graphically, generalization is rendered as a solid directed line with a large open arrowhead,
Pointing to the parent

A class may have zero, one, or more parents. A class that has no parents and one or more children is called a root class or a base class. A class that has no children is called a leaf class. A class that has exactly one parent is said to use single inheritance A class with more than one parent is said to use multiple inheritance.


In UML modeling, a generalization relationship is a relationship in which one model element (the child) is b

Generalization relationship examples

Example 1 Example 2

4) Realization
Realization is a semantic relationship between classifiers, wherein one classifier specifies a contract that another classifier guarantees to carry out.

A realization relationship exists between two model elements when one of them must realize, or implement, the behavior that the other specifies. The model element that specifies the behavior is the supplier, and the model element that implements the behavior is the client. Realization relationship is normally used to specify those elements that realize or implement the behavior of a component . You'll encounter realization relationships in two places: between interfaces and the classes or components that realize them,and between use cases and the collaborations that realize them.

Graphically represented


5) Aggregation
An aggregation relationship depicts a classifier as a part of, or as subordinate to, another classifier. Sometimes, you will want to model a "whole/part" relationship, in which one class represents a larger thing (the "whole"), which consists of smaller things (the "parts"). This kind of relationship is called aggregation.

A special form of association between a whole and its parts Data flows from the whole classifier to the part.
Data flows from the whole classifier, or aggregate, to the part. A part classifier can belong to more one aggregate classifier and it can exist independently of the aggregate


An object of the whole has objects of the part. Graphically represented open diamond


Types of UML Diagrams

1 Use Case Diagram 2 Class Diagram 3 Object Diagram 4 Sequence Diagram 5 Collaboration Diagram 6 State chart Diagram 7 Activity Diagram 8 Component Diagram 9 Deployment Diagram


1) Use Case Diagram

A use case diagram displays the relationship among actors and use cases Use Case A use case is a set of scenarios that describing an interaction between a user and a system. . The two main components of a use case diagram are use cases and actors

When to Use: Use Cases Diagrams

Use cases are used in almost every project. Use cases are helpful in exposing requirements and planning the project.

How to Draw: Use Cases Diagrams

Start by listing a sequence of steps a user might take in order to complete an action. For example a user placing an order with a sales company might follow these steps. 1. 2. 3. 4. 5. Browse catalog and select items. Call sales representative. Supply shipping information. Supply payment information. Receive conformation number from salesperson.


Use Cases Diagrams Example

2) Object diagram

In UML, object diagrams provide a snapshot of the instances in a system and the relationships between the instances. By instantiating the model elements in a class diagram, you can explore the behavior of a system at a point in time. An object diagram is a UML structural diagram that shows the instances of the classifiers in models. Object diagrams use notation that is similar to that used in class diagrams. An Object diagram focuses on some particular set of object instances and attributes, and the links between the instances. A link between instances is generally referred to as a link Object diagrams are helpful in the following situations: During the analysis phase of a project, you might create a class diagram to describe the structure of a system and then create a set of object diagrams as test cases to verify the accuracy and completeness of the class diagram. Before you create a class diagram, you might create an object diagram to discover facts about specific model elements and their links, or to illustrate specific examples of the classifiers that are required.


Object diagram Example




3) Class Diagrams
Class diagrams are widely used to describe the types of objects in a system and their relationships. Class diagrams model class structure and contents using design elements such as classes, packages and objects Class diagrams describe three different perspectives when designing a system, conceptual, specification, and implementation. Class diagram describe the static structure of a system Classes are composed of three things: a name, attributes, and operations. Example of a class.

Class diagrams also display relationships such as Association ,Aggregation Generalization ,Realization, Composition ,Extend.

When to Use: Class Diagrams

Class diagrams are used in nearly all Object Oriented software designs. Use them to describe the Classes of the system and their relationships to each other.

How to Draw: Class Diagrams

Class diagrams are some of the most difficult UML diagrams to draw. Before drawing a class diagram consider the three different perspectives of the system the diagram will present; conceptual, specification, and implementation. Try not to focus on one perspective and try see how they all work together. When designing classes consider what attributes and operations it will have.


Then try to determine how instances of the classes will interact with each other. These are the very first steps of many in developing a class diagram. Example

When designing classes consider what attributes and operations it will have. Then try to determine how instances of the classes will interact with each other. These are the very first steps of many in developing a class diagram.


Interaction Diagrams (sequence and collaboration)

Interaction diagrams model the behavior of use cases by describing the way groups of objects interact to complete the task. The two kinds of interaction diagrams are sequence and collaboration diagrams. .Interaction diagrams are used when you want to model the behavior of several objects in a use case. They demonstrate how the objects collaborate for the behavior. Interaction diagrams do not give a in depth representation of the behavior.

How to Draw: Interaction Diagrams

Sequence diagrams, collaboration diagrams, or both diagrams can be used to demonstrate the interaction of objects in a use case. Sequence diagrams generally show the sequence of events that occur. Collaboration diagrams demonstrate how objects are statically connected. Both diagrams are relatively simple to draw and contain similar elements.

4) Sequence diagram
Sequence diagram is an Interaction Diagram that emphasizes the time ordering of messages Sequence diagrams demonstrate the behavior of objects in a use case by describing the objects and the messages they pass. The diagrams are read left to right and descending. The example below shows an object of class 1 start the behavior by sending a message to an object of class 2. Messages pass between the different objects until the object of class 1 receives the final message.


5) Collaboration Diagram

A collaboration diagram describes interactions among objects in terms of sequenced messages. Collaboration diagrams represent a combination of information taken from class, sequence, and use case diagrams describing both the static structure and dynamic behavior of a system. Collaboration diagrams are also relatively easy to draw. They show the relationship between objects and the order of messages passed between them. The objects are listed as icons and arrows indicate the messages being passed between them. The numbers next to the messages are called sequence numbers. As the name suggests, they show the sequence of the messages as they are passed between the objects.


Eample 1

Example 2

6) State Diagrams
State diagrams are used to describe the behavior of a system. State diagrams describe all of the possible states of an object as events occur. Each diagram usually represents objects of a single class and track the different states of its objects through the system. Use state diagrams to demonstrate the behavior of an object through many use cases of the system. Only use state diagrams for classes where it is necessary to understand the behavior of the object through the entire system. State diagrams have very few elements. The basic elements are rounded boxes representing the state of the object and arrows indicting the transition to the next state.


The activity section of the state symbol depicts what activities the object will be doing while it is in that state.

All state diagrams being with an initial state of the object . This is the state of the object when it is created. After the initial state the object begins changing states.

Conditions based on the activities can determine what the next state the object transitions to.



7) Activity Diagrams
Activity diagrams describe the workflow behavior of a system. Flow of control from one activity to another activity Activity diagrams can show activities that are conditional or parallel.

How to Draw: Activity Diagrams

Activity diagrams show the flow of activities through the system. Diagrams are read from top to bottom and have branches and forks to describe conditions and parallel activities. A fork is used when multiple activities are occurring at the same time. The branch describes what activities will take place based on a set of conditions. All branches at some point are followed by a merge to indicate the end of the conditional behavior started by that branch. After the merge all of the parallel activities must be combined by a join before transitioning into the final activity state.


Action Flow
Action flow arrows illustrate the relationships among action states

Object Flow
Object flow refers to the creation and modification of objects by activities. An object flow arrow from an action to an object means that the action creates or influences the object. An object flow arrow from an object to an action indicates that the action state uses the object.

Initial State
A filled circle followed by an arrow represents the initial action state.


Final State
An arrow pointing to a filled circle nested inside another circle represents the final action state.

A diamond represents a decision with alternate paths. The outgoing alternates should be labeled with a condition or guard expression. You can also label one of the paths "else."

A synchronization bar helps illustrate parallel transitions. Synchronization is also called forking and joining.


When to Use: Activity Diagrams

Activity diagrams should be used in conjunction with other modeling techniques such as interaction diagrams and state diagrams. The main reason to use activity diagrams is to model the workflow behind the system being designed. Activity Diagrams are also useful for: analyzing a use case by describing what actions needs to take place and when they should occur; describing a complicated sequential algorithm; and modeling applications with parallel processes.



Activity diagram for: processing an order. The diagram shows the flow of actions in the system's workflow. Once the order is received the activities split into two parallel sets of activities. One side fills and sends the order while the other handles the billing. On the Fill Order side, the method of delivery is decided conditionally. Depending on the condition either the Overnight Delivery activity or the Regular Delivery activity is performed. Finally the parallel activities combine to close the order.


8) Component Diagram
Component diagrams are used to visualize the organization and relationships among components in a system. These diagrams are also used to make executable systems. Component diagrams are different in terms of nature and behavior. Component diagrams are used to model physical aspects of a system.

Physical aspects
Physical aspects are the elements like executables, libraries, files, documents etc which resides in a node. Component diagram is a special kind of diagram in UML. The purpose is also different from all other diagrams discussed so far. It does not describe the functionality of the system but it describes the components used to make those functionalities.

Component diagrams can also be described as a static implementation view of a system. Static implementation represents the organization of the components at a particular moment single component diagram cannot represent the entire system but a collection of diagrams are used to represent the whole. So 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.

How to draw Component Diagram?

Component diagrams are used to describe the physical artifacts of a system. This artifact includes files, executables, libraries etc. So the purpose of this diagram is different, Component diagrams are used during the implementation phase of an application. But it is prepared well in advance to visualize the implementation details. Initially the system is designed using different UML diagrams and then when the artifacts are ready component diagrams are used to get an idea of the implementation. This diagram is very important because without it the application cannot be implemented efficiently. A well prepared component diagram is also important for other aspects like application performance, maintenance etc. So before drawing a component diagram the following artifacts are to be identified clearly: 1) Files used in the system. 2) Libraries and other artifacts relevant to the application. 3) Relationships among the artifacts.


After identifying the artifacts the following points needs to be followed

1) Use a meaningful name to identify the component for which the diagram is to be drawn. 2) Prepare a mental layout before producing using tools. 3) Use notes for clarifying important points.

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. Component diagram example 1) example

2) example


3) example

9) Deployment Diagram
Deployment diagrams are used to represent the physical architecture of a system. They present the distribution of the software components on the set of execution units (nodes). Nodes and artefacts are the main concepts in a deployment diagram. Deployment diagrams are created in packages, classes, interfaces, components, artefacts or nodes.


Deployment diagrams are used for describing the hardware components where software components are deployed. So deployment diagrams are used to describe the static deployment view of a system. Deployment diagrams consist of nodes and their relationships. Deployment diagrams are used to visualize the topology of the physical components of a system where the software components are deployed.

Deployment diagrams and Component diagrams are closely related. Component diagrams are used to describe the components and deployment diagrams shows how they are deployed in hardware. UML is mainly designed to focus on software artifacts of a system. But these two diagrams are special diagrams used to focus on software components and hardware components. So most of the UML diagrams are used to handle logical components but deployment diagrams are made to focus on hardware topology of a system. Deployment diagrams are used by the system engineers.

The purpose of deployment diagrams can be described as:

Visualize hardware topology of a system. Describe the hardware components used to deploy software components. Describe runtime processing nodes.

How to draw Deployment Diagram?

Deployment diagram represents the deployment view of a system. It is related to the component diagram. Because the components are deployed using the deployment diagrams. A deployment diagram consists of nodes. Nodes are nothing but physical hardware used to deploy the application. Performance Scalability Maintainability Portability


So before drawing a deployment diagram the following artifacts should be identified: Nodes Relationships among nodes The following deployment diagram is a sample to give an idea of the deployment view of

Order management system.

Monitor Modem Caching server Server