1. Chapter

2. Agenda Object Oriented Design Object Oriented Modeling UML CASE tools
Use Case
Class Diagrams
Activity Diagrams
Sequence Diagram
CASE tools

3. Introduction
OO software development, just like the normal software development process is concerned with designing and developing quality applications using OO tools and processes

4. Stages in OO Software Development
Conceptualization
Object-oriented analysis and modeling
Object-oriented design
Implementation
Maintenance

5. Conceptualization
A conceptual model can be defined as a model which is made of concepts and their relationships.
A conceptual model is the first step in OO Software Development Life Cycle.
It helps to understand the entities in the real world and how they interact with each other.

6. OO Analysis Now the most important purpose of OO analysis is to:
Identifying objects
Organizing the objects by creating object model diagram (classes)
Defining the internals of the objects, or object attributes (properties)
Defining the behavior of the objects, i.e., object actions (behavior)
Describing how the objects interact (relationships)

7. Example: Parking lot system
Identify objects
Identify behavior of the objects
Identify properties of objects
Identify relationships
Identify classes

8. Advantages of OOA over Structured Analysis
Focuses on data rather than the procedures as in Structured Analysis
The principles of encapsulation and data hiding help the developer to develop systems that cannot be tampered by other parts of the system or external systems
It allows effective management of software complexity by the virtue of modularity
It can be upgraded from small to large systems at a greater ease than in systems following structured analysis

9. OO Design In which technology−independent concepts, are
mapped onto implementing classes,
constraints are identified and
interfaces are designed, resulting in a model for the solution domain, i.e., a detailed description of how the system is to be built on concrete technologies.

10. Design (contd)
Grady Booch (one of the pioneers of OOP) has defined object-oriented design as “a method of design encompassing the process of object- oriented decomposition and a notation for depicting both logical and physical as well as static and dynamic models of the system under design”

11. OO Implementation
The principal design of the implementation should directly follow that of the design phase, provided that a OO programming language was selected that supports the OO model of the OO design.
It is common to restrict the implementation to a subset of the programming language chosen. This can be useful to ease portability and maintainability.

12. Software Modeling

13. What is Modeling?
Modeling consists of building an abstraction of reality
Abstractions are simplifications because
They ignore irrelevant detail
They only represent the relevant details.
What is relevant or irrelevant depends on the purpose of the model

14. Why Model Software Software is getting increasingly more complex
Windows XP > 40 million lines of code
A single programmer cannot manage this amount of code in its entirety.
Code is not easily understandable by developers who did not write it
We need simpler representations for complex systems
Modeling is a mean for dealing with complexity

15. Dynamic vs Static modeling
Static Modeling - develops the static structure of the software system in terms of objects. It identifies the objects, the classes and the relationships between the objects.
Dynamic Modeling – examines a system's behavior with regards to external changes. Dynamic Modelling can be defined as “a way of describing how an individual object responds to events, either internal events triggered by other objects, or external events triggered by the outside world”.

16. Dynamic Modeling
The dynamic model represents the time– dependent aspects of a system.
It is concerned with the temporal changes in the states of the objects in a system.
The main concepts are:
State, which is the situation at a particular condition during the lifetime of an object.
Transition, a change in the state
Event, an occurrence that triggers transitions
Action, an uninterrupted and atomic computation that occurs due to some event, and
Concurrency of transitions.

17. Systems, Models and Views
A system is an organized set of communicating parts
A model is an abstraction describing a subset of a system
A view depicts selected aspects of a model
A notation is a set of graphical or textual rules for depicting views
Views and models of a single system may overlap each other

18. UML
UML is a standard language for specifying, visualizing, constructing, and documenting the artifacts of software systems.
UML was created by Object Management Group and UML 1.0 specification draft was proposed to the OMG in January 1997.
A standardization of other three models namely: Object Modeling Technique, Grady Booch's Method and Object Oriented Software Engineering
ISO standardized in 2005

19. Role of UML in OO design
The OO design is transformed into UML diagrams according to the requirement.
Before understanding the UML in details the OO concepts should be learned properly.
Once the OO analysis and design is done the next step is very easy.
The input from the OO analysis and design is the input to the UML diagrams.

20. UML Elements
Conceptual model of UML can be mastered by learning the following three major elements:
UML building blocks
Rules to connect the building blocks
Common mechanisms of UML

21. 1. UML Building Blocks The building blocks of UML can be defined as:
Things/Entities
Relationships
Diagrams

22. 1.1 Things Things can be: 1.1Structural 1.1Behavioral 1.1Grouping
1.1Annotational

23. 1.1 Structural Things
The Structural things define the static part of the model.
They represent physical and conceptual elements that do not change during the system's life span.

24. Example of Structural Things
Following are the brief descriptions of the structural things:
Class: represents set of objects having similar responsibilities
Interface: defines a set of operations which specify the responsibility of a class.
Collaborations: defines interaction between elements.
Use case: represents a set of actions performed by a system for a specific goal.
Component: Component describes physical part of a system.
Node : A node can be defined as a physical element that exists at run time.

25. 1.2 Behavioral Things
A behavioral thing consists of the dynamic parts of UML models.
Following are the behavioral things:
Interactions: Interaction is defined as a behavior that consists of a group of messages exchanged among elements to accomplish a specific task.
State Machines: useful when the state of an object in its life cycle is important. It defines the sequence of states an object goes through in response to events. Events are external factors responsible for state change.

26. 1.3Grouping Things and 1.4 Annotational Things
Grouping things can be defined as a mechanism to group elements of a UML model together.
Package is the only one grouping thing available for gathering structural and behavioral things.
Annotational things can be defined as a mechanism to capture remarks, descriptions, and comments of UML model elements.
Note is the only one Annotational thing available. A note is used to render comments, constraints etc of an UML element.

27. Structural things - Class
A class is a description of a set of objects that share the same attributes, operations, relationships, and semantics.
A class is represented using a compartmented rectangle
Objects
Professor Smith
Professor Jones
Professor Mellon
Attributes
Operations

28. Review: Class Compartments
A class is comprised of three sections
The first section contains the class name
The second section shows the structure (attributes)
The third section shows the behavior (operations)
In Rose:
You may select which compartments are displayed via Diagram Object Properties for the diagram element.
You may select which items appear in which compartments using the Edit Compartment function for the diagram element.
Professor
name
empID
create( )
save( )
delete( )
change( )
Class Name
Attributes
Operations
Attributes and operations are discussed on subsequent slides.
The second and third compartments may be suppressed if they need not be visible on the diagram.
While any compartment can be fully suppressed, it can also have some subset of the values showing

29. Review: Representing Objects
An object is represented as rectangles with underlined names
: Professor
Professor Clark
a + b = 10
ProfessorClark
Class Name Only
ProfessorClark :
Professor
Classes are discussed in a later slide.
The above objects are from a course registration system.
Object Name Only
Class and Object Name

30. Structural things - Interface
An interface is a collection of operations that specify a service of a class or component.
Interfaces support “plug-and-play” architectures
Interfaces are not abstract classes, as abstract classes allow you to provide default behavior for some/all of their methods. Interfaces provide no default behavior.
Tube
Shape
Draw
Move
Scale
Rotate
<<interface>>
Pyramid
From the UML User’s Guide (Booch, 1999): An interface is “a collection of operations that are used to specify a service of a class or a component.”
Interfaces formalize polymorphism. Interfaces allow us to define polymorphism in a declarative way, unrelated to implementation. Two elements are polymorphic with respect to a set of behaviors if they realize the same interfaces (e.g., any two “things” which realize the same interface can be said to be polymorphic). You always heard that polymorphism was this big benefit of object orientation, but without interfaces there was no way to enforce it, verify it, or even express it except in informal ways, or language-specific ways. Formalization of interfaces strips away the mystery, and gives us a good way to describe, in precise terms, what polymorphism was trying to do all along. Interfaces are testable, verifiable, and precise.
Interfaces are the key to the “plug-and-play-ability” of an architecture: Any classifiers (e.g., classes, subsystems, components) which realize the same interfaces may be substituted for one another in the system, thereby supporting the changing of implementations without affecting clients.
Realization relationships are discussed later in this module.
Cube
Realization relationship

31. Structural things - Collaboration
In the context of a system's architecture, a collaboration allows you to name a conceptual chunk that encompasses both static and dynamic aspects.
A collaboration names a society of classes, interfaces, and other elements that work together to provide some cooperative behavior that's bigger than the sum of all its parts.
You use collaborations to specify the realization of use cases and operations, and to model the architecturally significant mechanisms of your system.

32. Structural things - Collaboration
A collaboration is a society of classes, interfaces, and other elements that work together to provide some cooperative behavior that's bigger than the sum of all its parts.
A collaboration is also the specification of how an element, such as a 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 way.
Graphically, a collaboration is rendered as an ellipse with dashed lines.
Login
Login

33. Structural things – Use Case
a use case is a description of set of sequence of actions that a system performs that yields an observable result of value to a particular actor.
A use case is used to structure the behavioral things in a model.
A use case is realized by a collaboration.
Graphically, a use case is rendered as an ellipse with solid lines, usually including only its name.

34. Structural things – Component
A component is a modular physical part of the system design that hides its implementation behind a set of external interfaces.
The implementation of a component can be expressed by wiring together parts and connectors.
Graphically, a component is rendered like a class with a special icon in the upper right corner.

35. Component Example

36. Structural things – Node
a node is a physical element that exists at run time and represents a computational resource, generally having at least some memory and, often, processing capability.
A set of components may reside on a node and may also migrate from node to node.
Graphically, a node is rendered as a cube, usually including only its name.
Node #1
<<Node>>

37. Notations

38. 2. Relationships
It shows how elements are associated with each other and this association describes the functionality of an application.
There are four kinds of relationships available:
Dependency: relationship between two things in which change in one element also affects the other one.
Association: is basically a set of links that connects elements of an UML model
Generalization: It basically describes inheritance relationship in the world of objects
Realization: This relationship exists in case of interfaces

39. Notations of Relationships

40. 3. UML Diagrams
UML diagrams are the ultimate output of the entire discussion.
All the elements, relationships are used to make a complete UML diagram and the diagram represents a system.
The visual effect of the UML diagram is the most important part of the entire process.
All the other elements are used to make it a complete one.

41. UML Diagrams (cont) Structural Modeling Behavioral Modeling
Class and Object diagram
Package Diagrams
Deployment Diagram
Component Diagram
Behavioral Modeling
Use case diagram
Activity Diagrams
Sequence diagram