Principals of Object Orientation

1

• Principals of Object Orientation
• OO Analysis
• Modeling with UML
• UML Views
• User model view
• Structural view
• Behavioral view
• Implementation view
• Environment view

Functional View Static View Dynamic View
2

• Principals of Object Orientation

3
What is an Object?

• A thing
• A Visible Thing
• It has
• Identity
• Behavior
• What the object do and what can be done to it
• State this includes
• static properties and dynamic values of these
  properties
• Structure and behavior of similar objects are
  defined in a common CLASS.

4
What is an Object

• Behavior of objects is achieved via its
• Operations and
• Methods.
• The state of an object is realized thought the
  contents of its data.
• Objects can communicate via messaging protocols

5
Object Behavior - Object Life Cycle
InitializeObject
Wait forRequest
HandleRequest
TerminateObject
6
Principals of OO - Abstraction

• Abstraction
• Denotes the essential characteristics of an
  object that distinguishes it from all kinds of
  objects.
• What does the object do without any implication
  on how does it do it
• A software object is an abstraction
• A representation of something in the real word
  like a student, a book,

7
Principals of OO - Encapsulation

• Encapsulation
• The process of Compartmentalizing the elements of
  an object that constitute its structure and
  behavior
• Data hiding
• Localize design decisions
• What are the encapsulated elements?
• Information that describes the object (the things
  an object know about itself)
• No of pages, cover type, ISBN, and other Book
  information
• State, the objects current condition (or state)
• Behavior
• What the object can do (register, drop etc.)
• What can be done to it (a pencil object can
  Write!!)

Encapsulation
8
Principals of OO - Encapsulation

• Encapsulation
• What you need to know to use the object
• The interface
• What you need to know in order to make the object
  work properly
• Mechanism to respond to the interface, THE
  IMPLEMENATION FOR EACH INTERFACE
• Example
• Driving a car!
• You need to know the ignition, steering, brake,
  and gas pedal
• No need to know about the mechanics of the
  engine, spark plugs, etc.

9
Principals of OO

• Modularity
• OO is different from Structured Paradigm
• In Structured Paradigm module and function are
  the same
• In OO Paradigm Classes and objects are the lowest
  form of Modularity.
• A module could have multiple classes

10
Principals of OO

• Hierarchy
• Ranking of ordering of abstraction
• Inheritance (is a)
• The relationship between classes
• One class share the structure and behavior of one
  or more classes
• Generalization and Specialization

11
Inheritance
Class Furniture
Object Chair
Cost Dimensions Weight Color
Cost Dimensions Weight Color
Chair inherits all attributes and operations of
class Furniture
Buy Sell
Buy Sell
12
Principals of OO

• Polymorphism
• The same operation may behave differently on
  different classes.
• Example sign
• When an object is substituted with one of its
  children at run time
• (The is-a relationship)
• Overloading of operations
• Same operation with different signatures

13
Principals of OO

• Identifying Classes
• External Entities (devices, people)
• Things (reports, forms, Features, Estimates)
• Occurrences or Events (Moving)
• Roles (Mangers, Engineers, Group, Team)
• Places (Loading dock, Shipping Floor)
• Structures(Computers)

14

• OO Analysis

15
OO Modeling

• OO has its own Modeling Techniques
• UML Unified Modeling Language
• Grady Booch Method
• James Rumbaugh Method
• Ivar Jacobson Method

16
OO Modeling

• Grady Booch Method
• Micro Development Process
• Defines a set of analysis tasks that are
  re-applied in the Macro process
• Identifies classes, objects, and relationships
• Macro development Process
• Refine

17
OO Modeling

• James Rumbaugh Method
• Object Modeling Technique (OMT) for
• Analysis, creates
• The object model objects, classes, and
  relationships
• The dynamic model objects and system behavior
• The Functional Model DFD like
• System level design
• Object level design

18
OO Modeling

• Ivar Jacobson Method
• Object Oriented Software Engineering
• Use Cases Oriented method

19

• The Unified Modeling Language

20
Why do we model?

• Provide structure for problem solving
• Experiment to explore multiple solutions
• Furnish abstractions to manage complexity
• Reduce time-to-market for business problem
  solutions
• Decrease development costs
• Manage the risk of mistakes

21
The Challenge
Tijuana shantytown http//www.macalester.edu/j
schatz/residential.html
22
The Vision
Fallingwater http//www.adelaide.net.au/jpolias
/FLW/Images/FallingWater.jpeg
23
Why do we model graphically?

• Graphics reveal data.
• 1 bitmap 1 megaword.
• Anonymous visual modeler

24
What is UML

• The UML is a graphical language for
• Specifying, can be used to communicate "what" is
  required of a system, and "how" a system may be
  realized.
• Visualizing, it can be used to visually depict a
  system before it is realized
• Constructing, can be used to guide the
  realization of a system similar to a "blueprint".
  
• Documenting, can be used for capturing knowledge
  about a system throughout its life-cycle
• the artifacts of software systems

25
What is UML

• Added to the list of OMG adopted technologies in
  November 1997 as UML 1.1
• Most recent minor revision is UML 2.0,
• MDA

26
OMG UML Contributors
AonixColorado State University Computer
Associates Concept Five Data Access EDS Enea
Data Hewlett-Packard IBM I-LogixInLine
Software Intellicorp Kabira TechnologiesKlasse
Objecten Lockheed Martin
Microsoft ObjecTimeOraclePtech OAO Technology
SolutionsRational SoftwareReich SAP Softeam Ster
ling Software Sun Taskon TelelogicUnisys
27
OMG UML Specification

• UML Summary
• UML Semantics
• UML Notation Guide
• UML Standard Profiles
• Software Development Processes
• Business Modeling
• UML CORBAfacility Interface Definition
• UML XML Metadata Interchange DTD
• Object Constraint Language

28
the Language

• language syntax semantics
• syntax how the symbols should look and how are
  they combined (i.e words in natural language)
• semantics rules that tells us the meanings of
  each symbol.
• UML Notation Guide defines UMLs graphic syntax
• UML Semantics defines UMLs semantics

29
UML Views

• User model view
• The system from the users perspective.
• Use-cases
• Structural model view
• Static structure
• Classes, objects, and relationships
• Behavioral model view
• Dynamic aspect of the system including
  collaborations between elements identified in the
  user-model and the structural model views.
• Implementation model view
• Describes the structural and behavioral aspects
  of the implementation.
• Environment model view
• Shows the actual hardware that is required to
  implement the solution.

30
UML Diagrams
31
UML Views
Static ViewClass DiagramObject Diagram
Dynamic ViewSequence DiagramCollaboration
Diagram State Chart Diagram
Functional ViewUse Case DiagramActivity Diagram
32
UML Views
Structural model view or Static View

• Structural model view
• Class Diagram
• User model view
• Behavioral model view
• Implementation model view
• Environment model view

33
What is structural modeling?
Structural model view or Static View

• Structural model a view of a system that
  emphasizes the structure of the objects,
  including their classes, relationships,
  attributes and operations.
• Used to model the static structure and
  relationships among the classes of an OO software
  system
• A class diagram is made of
• Nodes (Classes and Interfaces)
• Links (Relationships)

34
UML Class Diagram

• Source for code generation
• It represents classes, their members, and
  relationships. It includes
• Attributes
• Operations
• Stereotypes
• Associations
• Inheritance
• Properties
• It shows static view
• Blueprint for building
• Does not show behavior

35
UML Class Diagram - Modeling Attributes

• An Attribute describes a piece of information
• Show type of attribute
• Primitive (Language supplied data type, int,
  boolean)
• User defined class (String)
• Show visibility
• - private
• public
• protected
• package
• Show default value
• Show Constraints Integrity rules
• Show static values by underlining the attribute
• Example
• Visibility / attribute Name Data Type default
  value constraint

36
UML Class Diagram - Modeling Operations

• An operation denotes behavior
• Things an object can do and
• Things can be done to an object
• Show Name
• Show arguments use attribute notation
• Show return type use attribute notation
• Visibility (-,,,)
• Example
• totalOrderAmount (order Order) Dollar total
  gt0

37
Class Representation in UML
Structural model view or Static View

• class Point
• int x,y
• public void move (int dx, int dy)
• x dx
• y dy

38
Object Representation in UML
Structural model view or Static View

• Point p1 new Point ()
• p1.x 0 p2.y0
• p1.move (20,15)

After sending the move message to p1 object
39
Modeling Relationships With UML

• Association

40
Relationships in UML
Structural model view or Static View

• Association
• To permit the exchange of messages
• Associations are the mean for objects to
  communicate
• Default is bi-directional (support messages in
  either way)
• When an object uses the services of another
  object but does not own it.
• Client server

41
Class Diagram Association
Structural model view or Static View

• General Binary Relationship

42
Association Elements - Association Name

• Association Name
• Expresses the purpose of the association (verb)
  that describes how objects of one type (class)
  relate to objects of another type (class)
• A Person owns a Car
• A Person drives a Car
• A Person rents a Car
• You can show the direction to read the
  association name

43
Association Elements - Multiplicity

• Association Multiplicity
• Defines rules on how objects in each class are
  related
• A value can be assigned to each participant in
  the association
• Min..Max
• denotes zero or more
• 1.. no upper limit

0..
1..1
44
Association Elements - Roles

• Association Roles
• Generates code

45
Association Elements - Constraints

• Association Constraints

Must have valid driver license
46
Association Elements - Class

• Association Class
• Encapsulate the association in a class to include
  information about the association

47
Association Elements - Reflexive

• Reflexive Association
• Objects in the same class can be associated and
  related to one another
• Common for modeling Hierarchies

48
Association Elements - Qualified

• Qualified Association
• Indexes
• The customer uses the order number to lookup the
  order
• Used to reduce multiplicity just like indexes are
  used to reduce time to search a table

49
Associations
50
Modeling Relationships With UML

• Inheritance Specialization and Generalization

51
Modeling Relationships With UML - Inheritance
Structural model view or Static View

• Inheritance
• Not a form of Association (no multiplicity)
• Extension Relationship (specialization and
  generalization)
• Extension between two interfaces
• Implementation (when a class implements an
  interface)
• UML uses hollow triangle (pointing toward the
  super class
• Inheritance
• specialization and Generalization
• is-a
• One class is a specialization of another
• The child has all the characteristics of a parent
  and it might specialize them
• Example A mammal is-a-kind-of Animal
• A cat is-a-kind-of Animal

52
Class Diagram Inheritance
Structural model view or Static View
Student
is-a Relationship
Undergrad
Graduate
Interface
PhD
Master
Implementation
Extension Relationship
Implementation of an Interface
53
Generalization is-a or type-of
Structural model view or Static View

• Vehicle
• Car
• Motorcycle
• Truck

Representation of inheritance
A car is-a Vehiclea Truck is-a Vehicle
Specialization occurs when sub-classes add
additional functionality or override existing ones
54
Generalization - Inheritance
Structural model view or Static View

• Credit Card Class is a subclass of the Bank Card
  Class
• Credit Card Class is a specialization of the Bank
  Card Class
• Credit Card Class is a Bank Card Class
• Credit Card Class inherits from the Bank Card
  Class
• Credit Card Class is derived from the Bank Card
  Class

• Bank Card Class is a supper class of the Credit
  Card Class
• Bank Card Class is a Generalization of the Credit
  Card Class
• Bank Card Class is base/ parent class of the
  Credit Card Class

• Specialization occurs when sub-classes add
  additional functionality or override existing
  ones
• Inheritance is an implementation of the
  generalization relationship

Credit card is a special kind of card
55
Modeling Relationships With UML

• Aggregation and Composition

56
Relationships in UML- Aggregation Composition
Structural model view or Static View

• Aggregation (diamond at the owner)
• Is a type of Association used to indicate that
  objects are not independent , rather they (the
  parts) are assembled or configured together to
  create another object (the whole)
• A number of different parts are assembled to
  create a Car object
• One object contains another.
• The aggregation class is referred to as the
  owner, or whole. The aggregated class is the
  owned, or part.
• Example a window has a drawing area, the drawing
  area can't stand on its own.

57
Relationships in UML- Aggregation Composition
Structural model view or Static View

• Composition (filled in diamond at the owner)
• Strong aggregation
• the owner is responsible for creating and
  destroying of the part object.
• Composite object that creates its components
• Example an active object with multiple threads
  of control.
• Is used for aggregation where the life span of
  the part is dependent on the whole. The
  aggregate has control over the creation and
  destruction of the parts
• Aggregation Composition Modeling
• Small diamond at the end of association denotes
  Aggregation
• If diamond is filled its a Composition (Consist
  of)

58
Aggregation Composition Examples
Structural model view or Static View
59
Composition
Structural model view or Static View
60
Example

• See Figure 2.7 Page 35 for Class Diagram
  Aggregation and Composition Example

61
Modeling Relationships With UML

• Dependency

62
Class Diagram Dependency
Structural model view or Static View

• One operation of a class1 depends on another
  operation of class2
• Use relationship
• Class C1 depends on class C2 if C1 uses C2.
• In many instances, a client-server relationship
  exists between two classes.
• In such cases, a client-class depends on the
  server-class in some way and a dependency
  relationship is established

63
Structural Modeling Core Relationships
Structural model view or Static View
64
UML Views

• User model view
• Use-cases
• Structural model view
• Behavioral model view
• Implementation model view
• Environment model view

65
Modeling Requirements with UML
User Model view or Functional View

• Use-Case Diagram

66
Modeling Requirements With USE-CASES
User Model view or Functional View

• Used to model Requirements
• Describes the behavior of the system as seen by
  external entities called actors
• Each actor represent a role played by a set of
  external entities that interact with the system
• Describes what
• Each use case represent a scenario

67
Software Engineering A Practitioners Approach,
6/e Use-case diagram
Modeling Requirements with UML
68
Modeling Requirements With USE-CASES

• Used to model Requirements
• Describes the behavior of the system as seen by
  external entities
• Actors
• Other Systems
• Each actor represent a role played by a set of
  external entities that interact with the system
• Describes what
• Each use case represent a scenario

69
Modeling Requirements With USE-CASES

• Model the system from the end-user's perspective.
• Objectives
• Define the functional and operational
  requirements of the system (product) by defining
  a scenario of usage. (These should be agreed upon
  by the users and developers.) 
• Describes how the system and the users will
  interact.
• use case model a view of a system that
  emphasizes the behavior as it appears to outside
  users.
• A use case model partitions system functionality
  into transactions (use cases) that are
  meaningful to users (actors).

70
Use Case Modeling

• Use Case model has three views
• The use case diagram
• High level definition of the relationship between
  the system and its users (actors)
• Block box view of the system
• The use case narrative
• Standard set of information that is required to
  guide for the development of the feature
• Textual description
• The use case scenarios
• One logical sequence of the execution of the use
  case.

71
Use Case Modeling
System
Name Assumption Pre Conditions Dialog Post
Conditions Exceptions Future Enhancements Open
Issues
Use Case Narrative
Use Case diagramDefined by UML
Use Case Scenario
72
Modeling Requirements With USE-CASES

• A use case diagram is made of
• System
• Use cases defines required feature of the system
• Actors
• Association Relationships
• between use-cases and actors
• It represents the fact that Actors communicate
  with the use case
• Dependencies Relationships
• Defines a communication relationship between 2
  use cases
• Include
• Extend
• Generalization Relationships
• Inheritance relationship between 2 actors or 2
  use cases

73
Use Case Modeling Core Elements
User Model view or Functional View
74
Use Case Modeling Core Relationships
ltltextendgtgt
75
Use Case Modeling Core Relationships (contd)
User Model view or Functional View
ltltincludegtgt
76
Use Case Diagram
User Model view or Functional View
77
Use Case Diagram - Relationships
User Model view or Functional View

• Association
• Communication between actors and use cases
• Uni or Bi directional
• ltltincludegtgt
• When one use case seeks help form another
• Example Deposit Money use case includes the
  Update Account use case
• Delegate
• Dashed arrow form the using use case to the used
  use case

Update Account
Withdraw Cash
ltltincludegtgt
78
Use Case Diagram - Relationships
User Model view or Functional View

• ltltextendgtgt
• The extend Dependency says that one use case
  might need help from another use case
• The extension point is the point where the
  extended use cases is tested to see weather its
  needed or not
• Arrow is going from the use case that is
  providing help to the main use case

Update Account
Withdraw Cash
ltltincludegtgt
Protect Overdraft
Withdraw Cash with Overdraft
ltltextendgtgt
79
Use Case Diagram - Relationships
User Model view or Functional View

• Generalization
• Inheritance relationship between use cases

Customer
80
Use Case Relationships
User Model view or Functional View
81
Actor Relationships
User Model view or Functional View
82
Use Case Description Change Flight
User Model view or Functional View

• Actors traveler, client account db, airline
  reservation system
• Preconditions
• Traveler has logged on to the system and
  selected change flight itinerary option
• Basic course
• System retrieves travelers account and flight
  itinerary from client account database
• System asks traveler to select itinerary segment
  she wants to change traveler selects itinerary
  segment.
• System asks traveler for new departure and
  destination information traveler provides
  information.
• If flights are available then
• System displays transaction summary.
• Alternative courses
• If no flights are available then

83
When to model use cases
User Model view or Functional View

• Model user requirements with use cases.
• Model test scenarios with use cases.
• If you are using a use-case driven method
• start with use cases and derive your structural
  and behavioral models from it.
• If you are not using a use-case driven method
• make sure that your use cases are consistent with
  your structural and behavioral models.

84
Use Case Modeling Tips
User Model view or Functional View

• Make sure that each use case describes a
  significant chunk of system usage OR FEATURE that
  is understandable by both domain experts and
  programmers
• When defining use cases in text, use nouns and
  verbs accurately and consistently to help derive
  objects and messages for interaction diagrams
• Factor out common usages that are required by
  multiple use cases
• If the usage is required use ltltincludegtgt
• If the base use case is complete and the usage
  may be optional, consider use ltltextendgtgt
• A use case diagram should
• contain only use cases at the same level of
  abstraction
• include only actors who are required

85
Example Online HR System
User Model view or Functional View
86
Online HR System Use Case Relationships
User Model view or Functional View
87
Online HR System Update Benefits Use Case
User Model view or Functional View

• Actors employee, employee account db, healthcare
  plan system, insurance plan system
• Preconditions
• Employee has logged on to the system and
  selected update benefits option
• Basic course
• System retrieves employee account from employee
  account db
• System asks employee to select medical plan
  type include Update Medical Plan.
• System asks employee to select dental plan type
  include Update Dental Plan.
• Alternative courses
• If health plan is not available in the
  employees area the employee is informed and
  asked to select another plan...

88
Modeling Behavior with UML

• Sequence Diagram
• State Diagram

89
Sequence Diagram

• Depicts Object Interaction in time
• Used to capture Scenarios (Use cases)
• Step-by-step sequence of messages exchanges among
  objects.
• Map directly to use cases
• Used to realize a use case
• Example 2.11 Page 37

90
State Diagram

• Each class must be associated with a statechart
  that describes its behavior.
• Sequence diagrams show behavior of objects and
  how they collaborate to achieve the goal at hand
  (Inter-Object).
• State Diagram show the behavior of an object
  (Intra-Object)
• Depicts flow of control using states and
  transitions

91
State Diagram
Lamp On
Lamp Off
92
State Diagram
ON
93
The States of a System

• statea set of observable circumstances that
  characterizes the behavior of a system at a given
  time
• state transitionthe movement from one state to
  another
• eventan occurrence that causes the system to
  exhibit some predictable form of behavior
• actionprocess that occurs as a consequence of
  making a transition

• Event-List Guard / Action
• Example 2.11 Page 37

94
Object Behavior - Object Life Cycle
Can be captured by Statecharts
InitializeObject
Wait forRequest
HandleRequest
TerminateObject
95
Statecharts

• Statechart is a behavioral language for the
  specification of real-time, event driven, and
  reactive systems.
• states
• events
• actions
• Transitions

FULL
PARTIAL
Event Condition / Action
96
Basic UML Statechart Diagram
top state
State
Initial pseudostate
Trigger
Ready
Transition
/ctr 0
stop
Done
Final state
Action