ObjectOriented Programming

1
Object-Oriented Programming

• Shyh-Kang Jeng
• Department of Electrical Engineering/Graduate
  Institute of Communication Engineering
• National Taiwan University

2
References

• R. C. Lee and W. M. Tepfenhart, UML and C, A
  Practical Guide to Object-Oriented Development,
  2nd ed., Prentice Hall, 2001.
• G. Booch, J. Rumbaugh, and I. Jacobson, The
  Unified Modeling Language User Guide, Addison
  Wesley, 1999.
• H. M. Deitel and P. J. Deitel, C How to
  Program, 4th ed., Prentice-Hall, 2003.

3
Outline

• Object-Oriented Thinking
• Case Study
• Extreme Programming
• Views of Software Systems

4
Outline

• Object-Oriented Thinking
• Case Study
• Extreme Programming
• Views of Software Systems

5
Key OO Concepts

• Encapsulation
• Information hiding
• Message passing
• Instantiation
• Inheritance
• Polymorphism

6
Object-Oriented Thinking

• What is the required function of the system?
• What are the objects/classes in the system (to
  provide this function)?
• How is the required system behavior distributed
  among these objects/classes (to provide this
  function)?

7
Results of the Object-Oriented Thinking

• Structure
• Inheritance
• Association
• Behavior
• Static
• Dynamic

8
Major OOP Activities

• Bound the domain
• Find the objects and related services
• Identify classes and related attributes
• Specify static behavior
• Specify dynamic behavior
• Identify relationships
• Design and Implement

9
1. Bound the Domain usingUse Cases

• Specifies a sequence of actions, including
  variants, that a system performs and that yields
  an observable result of value to a particular
  actor
• Ease discussions between stakeholders and
  analysis/developers
• Typically written using business terms that are
  natural to the majority of stakeholders

10
Use Case Diagram
11
Use Case Specification

• Withdraw Money
• 1. The Bank Customer identifies himself or
  herself
• 2. The Bank Customer chooses from which account
  to withdraw money and specifies how much to
  withdraw
• 3. The system deducts the amount from the account
  and dispenses the money

12
Scenarios

• A use case describes a set of sequences in which
  each sequence in the set represents one possible
  flow through all these variations.
• Each sequence is called a scenario.
• A scenario is a specific sequence of actions that
  illustrates behavior.

13
A Scenario Example

• Withdraw Money Basic Flow
• Input
• The Bank Customers account 12-121-1211 has a
  balance of 350.
• The Bank Customer identifies himself correctly.
• The Bank Customer request to withdraw 200 from
  account 12-121-1211.
• There is enough money (at least 200) in the ATM.
• Result
• The balance of the Bank Customers account
  12-121-1211 decreases to 150.
• The Bank Customer receives 200 from the ATM.

14
Guidelines for Developing Use Cases

• Avoid analysis paralysis
• Identify actors
• Identify high-level and essential use cases
• Develop use case details
• Identify supporting use cases

15
Detailed Description of Use Case

• Precondition
• Flow of Events
• Basic Path
• Alternative Paths
• Statechart Diagrams for States and Transitions
• Activity Diagrams for Sequence of Actions
• Interaction Diagrams for Interactions between Use
  Case and the Actors

16
Example of Flow of Events

• ATM Validate User
• Main flow of events
• Exceptional flow of events
• Customer cancel a transaction
• Customer clear a PIN number
• Customer enters an invalid PIN number

17
Activity Diagrams
18
2. Find Objects Using Nouns

• Use the nouns, pronouns, and noun phrases to
  identify objects and classes
• Singular proper nouns and nouns of direct
  reference (the sixth player, the one-millionth
  purchase) are used to identify objects
• Plural nouns and common nouns are used to
  identify classes
• Verbs and predicate phrases are used to identify
  the services

19
Identify Services

• In a sentence in the form subject-action
  verb-object, the verb usually defining a method
  that must be provided by the object of the
  sentence
• Example
• A person hit the ball
• The ball object must have a prototype service,
  e.g., beingHit(), to receive the hit message
  request from a person object
• Try to be as generic as possible to find abstract
  classes

20
Algorithmically Simple Services

• Create
• Creates and initializes a new object
• Connect
• Connects an object with another object
• Access
• Gets or sets attribute values
• Disconnect
• Disconnects an object from another object
• Delete
• Deletes an object

21
Algorithmically Complex Services

• Calculate
• Calculations that the object is responsible for
  performing on its values
• Monitor
• Monitors that the object is responsible for in
  order to detect or respond to external system or
  device or internal object
• Query
• Computes a functional value without modifying the
  object

22
Identify Objects Using CRC Cards

• Start the effort as a brainstorming session for
  classes
• Use the use cases to generate scenarios for the
  system
• Position all of the classes on a white board and
  draw association arcs between the classes to
  represent the collaboration

23
CRC Card for an Object
Object Name withdrawManager
Collaborators
Responsibilities Ask user for amount to
withdraw Verify amount with
AccountManager Tell cash dispenser to release
cash
accountManager cashDispenser
24
UML Notation for an Object
25
3. Identify Classes

• Group objects with the same services into a class
• Refine later
• Can be modified

26
CRC Card for a Class
Class Name WithdrawManager
Collaborators
Responsibilities Ask user for amount to
withdraw Verify amount with
AccountManager Tell CashDispenser to release
cash
AccountManager CashDispenser
27
UML Notation for a Class
28
Properties of Attributes

• Must capture a characteristic that is consistent
  with the semantic domain in which the object
  resides
• An instance has exactly one value for each
  attribute at any given time
• Must not contain an internal structure
• Must be a characteristic of the entire entity and
  not a characteristic of its composite parts

29
UML Notations for Attributes
30
4. Specifying Static Behavior

• Behavior is the set of actions that an object is
  responsible for a specific service
• Usually captured as a method in the object
• A static behavior is implemented as the operation
  (code) within the method, and is not affected by
  any internal or external events
• Use interaction diagrams to document the static
  behavior
• Pseudo code and/or other support documents may be
  necessary to specify complicated behavior

31
Instances
32
Messages
33
Sequence Diagrams
34
Collaboration Diagrams
35
5. Specifying Dynamic Behavior

• Dynamic modeling mechanisms provide a way to
  capture the behavior of objects, and thus the
  behavior of the application, over time
• Events
• The stimuli
• States
• Object configurations that exist between events

36
A Simple Statechart Diagram
37
Implementing States

• enum MachineState INITIAL, IDLE, RUNNING, FINAL
  
• enum Event KEY_PRESS, FINISHED, SHUTDOWN
• class Machine
• //
• MachineState state
• //
• void respond( const Event e )
• //

38
Implementing State Transitions

• void respond( const Event e )
• switch( state )
• case INITIAL
• state IDLE
• break
• case IDLE
• if( e KEY_PRESS ) state RUNNING
• break
• case RUNNING
• if( e SHUT_DOWN ) state FINAL
• if( e FINISHED ) state IDLE
• break
• case FINAL

39
Statechart Diagrams

• Example

40
6. Identifying Relationships

• Objects typically depend on other objects for
  services and possibly for error handling,
  constant data, and exception handling
• Interdependencies of objects are called
  relationships
• Major relationships
• Generalization
• Association
• Link
• Aggregation

41
Class Diagrams
42
Generalization
43
Implementing Generalization

• class Shape
• //
• Class Rectangle public Shape
• //
• class Square public Rectangle
• //

44
Association Name, Role, Multiplicity
1..

Works for
Company
Person
employee
employer
45
Implementing Association

• class Person
• //
• Company employer
• //
• class Company
• //
• Person employee
• //

46
Association Object

• class WorksForPair
• //
• Person employee
• Company employer
• //
• class WorksFor
• //
• WorksForPair w
• //

47
Association Aggregation

• Example

Company
1

Department
48
Modeling Structural Relationships
49
Implementing Aggregation

• class School
• //
• Department departments
• // created and destructed by School objects
• Student students
• // created and destructed outside the
• // School objects
• //

50
7. Preparation for Design and Implementation

• Form
• Class diagrams for relationship
• Function
• Interaction diagrams for static behavior
• Statechart diagrams for dynamic behavior
• Pseudo code and/or other support documents when
  necessary

51
Dependency
52
Visibility
53
Notes
54
Outline

• Object-Oriented Thinking
• Case Study
• Extreme Programming
• Views of Software Systems

55
Statement of the Problem
56
Use case diagram
Simulate Operation
57
Use case description

• The user starts by entering the fabrication
  mode of every machine and execution time. The
  system then simulates the production line for the
  entered execution time. After that the system
  reports the sizes of all queues. The user
  decides to quit or continue. If continue, the
  user enters the fabrication modes and execution
  time again, and the system repeats. The system
  stops when the user decides to quit.

58
List of Object Candidates

• production line
• m1, m2
• rm, q1, q2, q3

59
Initial Class Diagram
ProductionLine
5
2
Queue
Machine
4
Connects to
2 input queues 2 output queues
60
Statechart Diagram for Machine
61
Statechart Diagram for Machine Modes
Input Queue is Empty
62
Collaboration Diagram
1decrease
4increase
3decrease
2increase
2increase
4increase
3decrease
1decrease
63
Flow-of-Events Description

• First, machine m1 responds according to the
  statechart diagrams related to its fabrication
  mode and state. If in Idle state and the input
  queue is not empty, decrease the input queue (1).
  If in InProduction state and the In Production
  Hour reaches the Required Work Hours, increase
  the output queue (2). Similarly, machine m2
  responds according to the statechart diagrams
  related to its fabrication mode and state (3,4).

64
Initial Class Design -- ProductionLine
ProductionLine
Responsibilities -- simulate one hour -- set
fabricate modes -- add raw material
65
Initial Class Design Queue
66
Outline

• Object-Oriented Thinking
• Case Study
• Extreme Programming
• Views of Software Systems

67
Extreme Programming

• Proposed by Kent Beck (ref K. Beck, Extreme
  Programming Explained, Addison Wesley, 2000.
  ????, ??????, ??, 2002)
• Suitable for a team of less than a dozen
  individuals
• A discipline of software development based on
  values of simplicity, communication, and courage
• 12 practices

68
XP Practice for Programming

• Writing test first
• Simple design
• Refactoring
• Coding standards

69
An XP Programming Cycle

• Write a test program
• Compile the test program and see it fail
• Write and compile programs just for testing
  (refactor first if necessary)
• Execute the test program and see it fail
• Write programs just for passing the test
• Refactor the program and eliminate redundancy
• Repeat the whole cycle

70
Some Tips

• The XP programming cycle should take less than 10
  minutes. If it takes more than 5 minutes, try to
  reduce the scale of the test program
• Write test programs that can be executed
  automatically and repeatedly

71
Advantages

• Program is testable
• The test can be used as a document. If some body
  wants to know how the object operates or how to
  use the program, we can just give them the test
  program and related programs
• Design is simplified, since our design is just
  enough for passing the test
• If the program has to be modified, we will find
  the newly introduced bugs quickly.
• A more robust interface can be evolved earlier

72
Refactoring

• Improves the program code without changing its
  exterior behavior
• To keep the program simple and prepare for future
  changes
• Needs the original source code and the related
  test programs (to ensure that we dont change the
  programs exterior behavior)
• Make slight change and test repeatedly

73
Some Signs for Programs Need Refactoring

• Classes or methods too long
• Repeated or almost repeated codes
• Some data members can be moved to local variables
  of methods
• Comments useless
• Too many temporary variables
• Complicated switch statements

74
Outline

• Object-Oriented Thinking
• Case Study
• Extreme Programming
• Views of Software Systems

75
Views of a Software System
Logical View
Component View
Use Case View
Process View
Deployment View
76
Subsystems
User Interface
Business Object
Utility
Database
77
Use Case View

• Understandability
• Usability
• Use case diagrams (structural modeling)
• Activity diagrams (behavioral modeling)

78
Logical View

• Functionality
• Class diagrams (structural modeling)
• Interaction diagrams (static behavioral modeling)
• Statechart diagrams (dynamic behavioral modeling)

79
Component View

• Software management
• Reuse
• Portability
• Component Diagrams

80
Component Diagram

• Example

Registration.exe
Database.dll
Mfc.dll
81
Process View

• Performance
• Availability
• Fault tolerance

82
Deployment View

• Performance
• Availability
• Fault tolerance
• Scalability
• Delivery and installation
• Deployment diagram

83
Deployment Diagram

• Example

Database Server
Registration
DBServer.exe
Registration.exe
Printer