Object-Oriented Modeling

Modeling is breaking the complex problem into small elements and arriving at the solution of the problem Models help you visualize and specify different parts of a system Models also show how different parts are related to one another and help in visualizing their working

Unified Modeling Language (UML)

Is a standard modeling language used for modeling software systems of varying complexities Provides a set of notations and rules for using any kind of system Focus is on creating simple, welldocumented and easy-to-understand software models

Goals of UML

To provide a simple and ready-to-use expressive visual modeling language To be process-independent To be language-independent

UML defines various models in the software engineering domain. The models and their description are given below:

The class model describes the static structure The Object model describes the static structure of the system at particular instance of time The state model represents behavior of objects the dynamic

The use case model explains the requirements of the user

The collaboration diagram represents a set of classes and the messages sent and received by those classes A sequence diagram describes the messages between classes An activity diagram depicts the activities of of a class. Component Diagram describe organization and dependency between the software implementation components. Deployment Diagram describe the configuration of processing resource elements and the mapping of software implementation components onto them.

ARCHITECTURAL VIEW OF UML

USER VIEW

BEHAVIORAL VIEW

ENVIRONMENTAL VIEW

Each view represents particular view of the system

USER VIEW :Represents the goals and objective of the system from users view point. STRUCTURAL VIEW: Represents the static and idle state of system BEHAVIORAL VIEW : Represents the dynamic and changing state of the system

IMPLEMENTATION VIEW: Represents the distribution of logical elements of the system, such as source code structure and runtime implementation structure of the system. ENVIRONMENTAL VIEW: Represents the
distribution of the physical elements of the system, such it depicts the nodes that form a part of the physical hardware requirement for the deployment of the system.

USER VIEW

Represents the part of the system with which user interacts. Consist of: 1.System Users - System users can be human users or other systems that interact directly with the system 2.Actors - Actors are the elements that lie outside the system, and therefore are called the external entities of a system. They are used to model system users

ACTORS

Are divided into four main categories:

Principal actors people who directly interact with the system. Secondary actors people who are involved in maintenance of the system External hardware The hardware that is a part of system other than the computer that runs an application Other systems The external systems with which your system needs to interact for its working

Use Case Diagrams

The user view of a system consists of use case diagrams A use case diagram contains actors, use cases, and their relationships A use case diagram represents the functionality provided by the system to external entities Use case diagrams consist of actors and use cases

Following is the diagrammatic representation of use case diagrams

<Use Case Name>

<Actor Name> ACTOR NAME

 USE CASES

Consist of elements that lie inside the system Are responsible for functionality and behavior of the system Are set of transactions performed by the system when an actor initiates an event or an action Represent all the possible events that can occur in all possible scenarios

SYSTEM BOUNDARY
A system boundary of a use case diagram defines the limits of the system

Relationships in Use Cases

Include : When a use case is depicted as using the functionality of another use case in a diagram, this relationship between the use cases is named as an include relationship An include relationship is depicted with a directed arrow having a dotted shaft

Extend

In an extend relationship between two use cases, the child use case adds to the existing functionality and characteristics of the parent use case. An extend relationship is depicted with a directed arrow having a dotted shaft, similar to the include relationship.

Use Case Specification

The visual depiction of the business requirements is translated into clear and welldefined requirements in the form of use case specifications A use case specification enables us to easily document the business flow A use case specification document should cover the following areas :

Actors List the actors that interact and

Pre-conditions Pre-conditions that need to be

Post-conditions Define the different states in

Alternative flows :Any subsidiary events that

Use case relationships : For complex systems, it

Structural View

Represents the static aspect of a system Represents the static aspect of a system Comprises : Class Diagrams Depict various classes and their associations Describes the classes that are declared within the system Object Diagrams Depict various objects and their links with each other

CLASS DIAGRAM

A class diagram is a diagram showing a collection of classes and interfaces, along with the collaborations and relationships among classes and interfaces. A class diagram is a pictorial representation of the detailed system design

Elements of a Class Diagram

CLASS

: It is represented by a rectangle.
Class

List of Attributes/ Variables

List of Methods

Analysis classes are of the following types :

Boundary :mapping of information to relevant classes during the in flow and out flow of information Control :Transfers control to the appropriate business logic class Entity : Contains the business functionality. Any interactions with back-end systems are generally done through these classes.

Relationships Between Classes

Association: It represents relationship between classes.

Multiplicity defines how many objects participate in relationships

Multiplicity
represents exactly one

represents zero or more

represents one or more

represents zero or one

represents specified range

Aggregation : When a class is formed as a collection of other classes, it is called an aggregation relationship between these classes .

Inheritance/Generalization

Generalization is the basic type of relationship used to define reusable elements in the class diagram

Creating a Class Diagram

Classes in a class diagram should be descriptive and must be named after business entities Relationships between classes may not be apparent in the first iteration. Revise and refine your class diagrams to determine possible relationships during each iteration. Designing is an incremental process and class diagrams are updated as the system gets built

Object Diagrams

Describe the static structure of a system at a particular instance in time Describe the instantiation of a class diagram Contain objects and links Cover instances of the classes found in the class diagram Use the object diagram as a means of debugging the functionality of your system Object diagrams can be used to check whether the system has been designed as per the requirements, and behaves how the business functionality needs the system to respond.