SE: CHAPTER 6 Considering Objects

1
SE CHAPTER 6Considering Objects

• The Special Nature of OO Development
• Use Cases
• Using UML
• OO System Design
• OO Program Design
• OO Measurement

2
Considering Objects

• We will examine more carefully the concepts
  involved in Object-Oriented (OO) development
• We will show how they are used in requirements
  capture, system design, and program design
• To illustrate these concepts, we will use UML,
  the Unified Modeling Language
• We will see that Capturing design in UML helps
  to make problems and the solutions more visible
• The design can be improved as we view it from
  different perspectives

3
6.1 What Is OO ?

• What is OO ?
• Object-Oriented is an approach to software
  development that
• Organizes both the problem and its solution as a
  set of discrete objects
• Both data structure and behavior are included in
  the OO representation
• We can recognize an OO representation by its
  seven characteristics
• Identity, abstraction, classification,
  encapsulation, inheritance, polymorphism and
  persistence

4
Characteristics of OO

• Characteristics of OO
• Identity refers to the fact that the system are
  organized into discrete, distinguishable entities
  called Objects.
• A single object has states and behaviors
  associated
• Each object usually has a Name, also called a
  Reference or Handle the Name distinguishes one
  object from another
• OO uses Classification to group objects that have
  attributes and behaviors in common
• We can represent a class using a box such as the
  one in Fig 6.2
• Class name, attributes, methods
• Each object is an instance of a class. Each
  instance has its own attributes values, but
  shares attribute names and behaviors with the
  other instances of the class
• A class encapsulates an objects behaviors and
  attributes, hiding the implementation details

5
Characteristics of OO

• Characteristics of OO
• We can organize classes hierarchically
• Forming inheritance structures
• We can use an abstract class to simply the
  hierarchy
• Where no objects of the abstract class may be
  defined
• A behavior or method is an action or
  transformation that an object performs or to
  which it is subjected
• The behavior is triggered by receipt of a
  particular message, or entrance into a particular
  state
• The same behavior may exhibit differently on
  different classes this is known as polymorphism

6
Characteristics of OO

• Characteristics of OO
• See graphic representation of class using UML
• Fig 6.3, p.262
• Persistence is the ability of an objects name,
  states and behaviors to transient time and space
• That is, the objects name, states and behaviors
  are saved as the object is transformed

7
6.2 The OO Development Process

• Advantage of OO Development
• One of the advantage is its consistency of
  language
• We can describe both the problem and the solution
  in the same terms classes, objects, methods,
  attributes and behaviors
• Throughout the development process, we should
  have consistency of terminology and of
  perspective
• Describing classes requires 3 perspectives
• Static, dynamic and restrictive
• The static views include descriptions of the
  objects, attributes, behaviors and relationships
• The dynamic views describe communication,
  control/timing, and the states and state changes
• The restrictions describe constraints on the
  structure and the dynamic behavior

8
The OO Development Process

• The difference of development processes
• This cross-the-process consistency is a key
  difference between traditional procedure and the
  OO development process
• OO is a philosophy of problem and solution
  representation, not a life-cycle by itself
• OO can be used in many different software
  life-cycle
• OO is the way to think of objects and classes in
  terms of their likelihood for reuse
• Table 6.1 ,p.263, gives various characteristics
  of a software product or project

9
OO Requirements

• OO development processes
• No matter what the life-cycle,
• an OO development process requires steps for
  describing requirements, designing the system,
  designing the programs, coding and testing.
• OO requirements analysis is usually done in the
  users language
• And discusses the concepts and scenarios likely
  in the application domain
• The concepts include information, services and
  responsibilities
• The requirements definition can be independent of
  its representation as objects

10
OO Coding and Testing

• OO Coding by OO programming language
• Once the design is done, the system is described
  at a very low level using object models
• It is usually necessary to refine the
  hierarchical structures and make adjustments as
  the requirements grow and mature
• Testing an OO system involves some of the same
  activities that are performed when testing any
  kind of system
• See Fig 6.4,p.265.
• There are some characteristics of OO that require
  special attention during testing

11
6.3 Use Cases

• Use Cases
• It describes particular functionality that a
  system is supposed to perform or exhibit
• By modeling the dialog that a user, external
  system, or other entity will have with the system
  to be developed
• The entity interacting with the system is called
  an Actor, and it can be a user, a device, or
  other system
• Each use case describes a possible scenario
• Of how the external entity interacts with the
  system
• The use case is represented as a drawing plus a
  brief textual sketch of how the function is
  performed

12
Uses Cases

• The system functionality
• The use cases in their entirety constitute a
  complete description of all possible ways using
  the system by all possible entities
• The collection of use cases paints a picture of
  the complete functionality of the system
• Use Cases are useful for requirements
• They are particularly useful for communicating
  with customers, designers and testers
• Customers read them to make sure the desired
  functions
• Designers use them to lay out the objects in
  appropriate places
• Use cases feed all stages of the life cycle,
  acting as a means of communication across all
  roles

13
Uses Cases

• Use Case Diagrams
• They are a graphical representation of system
  functions
• They have 4 elements actors, extensions, and
  uses
• An actor is a role that an entity plays with
  respect to the system
• The case is a depiction of some aspect of the
  system functionality that is visible to the
  actors
• An extension extents a use case to illustrate a
  different or deeper perspective
• A use is a reuse of an already defined use case
• See Fig 6.5, p.266

14
Uses Cases

• Use of the Use Case
• We use the use case to help to understand the
  customer and the problems
• For each use case diagram, we write a scenario
  script to describe the system functionality
• Example see Fig 6.6, p.267, for the extension
  of Fig 6.5, and Fig 6.7, p.267, for the further
  extension of Fig 6.6, and Fig 6.8, p.268, for the
  further extension of Fig 6.7
• In each case, we think a participant as a role
• We use a set of questions to help to identify
  participants
• The result is a comprehension description of how
  the system will work
• Including its interactions with system beyond its
  boundary

15
Uses Cases

• Alternative ways of system requirements
• Sometimes problems are hidden with requirements
  written in natural language
• When we translate them to use cases, these
  problems surface.
• It is a good check on the requirements quality
• Once we have use cases, we can examine them
  further to find existing and potential problems,
  and
• We can ask questions (see p.268-269) for doing so.

16
6.4 Representing OO Using UML

• UML Unified Modeling Language
• Is a notational approach that is popular for
  describing OO solutions
• OMG (Object Management Group) has adopted UML as
  the OO notational standard
• UML can be used to visualize, specify or document
  a problem and its solutions
• UML diagrams include dynamic view, the static
  view, restrictions and formalization of systems

17
UML in the Process

• UML being used throughout the process
• Fig 6.9, p.270, shows how UML can be used in
  requirements specification, design and coding.
• In the requirements process, workflow diagrams
  define the entire business process
• By describing the activities that the business
  will perform
• Use case diagram can also describe the system to
  be built by describing the general processes that
  the system must perform
• These diagrams can be supplemented with the UML
  object models

18
UML in the Process

• UML being used throughout the process
• Once the requirements are in good shape, design
  begins with UML state diagram and the activity
  diagram
• The activity diagrams display all the activities
  that can occur in the system as the values of
  objects change
• In concert with the activity diagrams, we use
  state diagrams to show all possible states that
  object can take
• Object diagrams describes how each class is
  associated with others, including inheritance
  relationships

19
UML in the Process

• UML being used throughout the process
• Sequence diagrams and collaboration diagrams
• The interactions among classes are illustrated
  using interaction diagrams of these 2 types
• Sequence diagrams show how messages flow from one
  object to another, formalizing the information
  descriptions of events in the requirements
• Collaboration diagrams use object and sequence
  information to show the flow of events between
  objects
• Finally, the design can be implemented using
• Package diagrams show how classes are divided
  into models
• Component diagrams reflect the final system
  modules
• Deployment diagrams show the network links
  involved with the application being built

20
6.5 OO System Design

• We begin with use of UML class diagrams
• These diagrams describe the object types and
  their static relationships
• In particular, we want to depict associations
  among objects and class and subclass
  relationships
• We use the diagrams to illustrate the attributes
  of each object, their individual behaviors, and
  restrictions on each class or object

21
Requirements elicitation

• We try to extract nouns
• To look for particular items that can suggest
  object classes, we seek
• Structures, external systems, devices, roles,
  operating procedures, places, organizations,
• We can use questions as guidelines about what to
  include in the list of candidate classes
• See questions listed on P.272

22
Requirements elicitation

• We try to identify behaviors
• From the requirements statements, we extract
  verbs
• We can look for particular items that suggest
  behaviors
• Imperative verbs, passive verbs, actions, events,
  roles, operating procedures, services provided by
  various organizations
• The behaviors will become actions and
  responsibilities taken by a class or object, or
  actions done to a class or object

23
Requirements elicitation

• Use UML boxes to describe classes
• See Fig 6.10, p.274
• It includes class name, attributes, operations
• See Fig 6.11, p .275 for Inheritance relationship
• Class Relationships
• Relationships usually consist of 4 types
• Generalization, association, aggregation,
  composition

24
Requirements elicitation

• Class Relationships
• generalization
• The super-class generalizes the subclass
• Association
• 2 classes are associated when they occur
  together, and when the relationship must be
  preserved for some period of time
• The association is depicted with a straight line,
  and
• The numbers at each end show the cardinality
  associated with each member of the relationship

25
Requirements elicitation

• Class Relationships
• composition
• An composition is recognized when one class is
  part of another class
• We denote the part-of relationship using a line
  that ends in a filled diamond
• The numbers at each end show the cardinality
  associated with each member of the relationship
• Aggregation
• An unfilled diamond shows an aggregation that is
  not an inheritance relationship
• See Fig 6.12, p.275 and Fig 6.13,p.276

26
Requirements elicitation

• Other ways of associating classes
• Association can be enhanced with
• Associative class that depicts the association
  relations in further details
• Qualified association makes the related class
  object qualified with some attribute values
• See Fig 6.14, p.276
• See example of Fig 6.15, p.277
• And Fig 6.16, p.278
• And Fig 6.17, p.279, with cardinality added to
  the diagram

27
Other UML Diagram

• Class Description Template
• Each Class is described in more detail using it
• See example on p.278-280
• The template lays the groundwork for the program
  design
• It includes information essential for programmers
  to implement the design as code
• Private interface
• Public interface

28
Other UML Diagram

• Package Diagram
• The package diagrams show the dependencies among
  classes as they belong to different packages
• We say that 2 items are dependent if changes to
  the definition of one may cause changes to the
  other
• 2 packages are dependent if there is a dependency
  between classes in each of the packages
• In this way, we can view a system as a small
  collection of packages

29
Other UML Diagram

• Package Diagram
• See Fig 6.18, p.281 for package diagram
• The dashed arrows shows the package dependencies
• As you can see, package diagram gives a high
  level overview of the system and notes the high
  level dependencies

30
Other UML Diagram

• Interaction Diagrams
• Used to describe how operations and behaviors are
  handled by the objects in the design
• We usually generate one interaction diagram from
  each use case
• There are 2 kinds of interaction diagrams
• Sequence diagram shows the sequence in which
  activities occur
• Objects lifeline an arrow between 2 lifelines
  represent a message a on the arrow indicates
  that the message is sent many times.
  Self-delegation
• See Fig 6.19, p.282

31
Other UML Diagram

• Interaction Diagrams
• Collaboration diagram shows how the objects are
  connected statically, based on use case
• Objects are icons arrows used to depict
  messages the sequence of messages is indicated
  by a numbering scheme
• See Fig 6.20, p.282
• Dynamic Models
• State diagrams and activity diagrams

32
Other UML Diagram

• State Diagrams
• State diagram shows the possible states an object
  can take, the events that trigger the transition
  from one state to another, and actions that
  result from each change
• A State diagram is needed only for classes that
  exhibit dynamic behavior
• The state diagram is similar to state transition
  diagram, see Fig 6.21,p.283, Fig 6.22,p.284, Fig
  6.23,p.284
• Start state is represented by a black dot
• End state is a smaller black dot inside a white
  dot
• A rectangle represents a state
• An arrow shows the transition from one state to
  another
• A condition is noted with a bracket expression
  next to an arrow

33
Other UML Diagram

• Activity Diagrams
• Activity diagram is used to model the flow of
  procedures or activities in a class
• It uses a decision node to represent conditional
  choice
• See Fig 6.24, p.285 for notions used
• Start node is represented by a black node
• The end node is a smaller black dot inside a
  white dot
• A rectangle represents a state
• Arrows used to show transitions from one state to
  another
• Horizontal bar allows broadcasting events and
  parallel activities to be represented
• See Fig 6.25, p.285

34
6.6 OO Program Design

• Program design begin with classes objects
• But we must embellish and modify them to include
  more items, including
• Reused components, reusable components, user
  interfaces, data structure and management details
• And there are likely more than in the system
  design
• In this stage, we must make more detailed
  decisions about the data structures and each
  objects interfaces
• That is, the levels of abstraction in this stage
  are different from that of during the system
  design stage
• The interface is a collection of operations
• It also allow us to take advantages of
  polymorphism or dynamic binding.

35
OO Program Design

• Design Implementation
• The choice of object composition and class
  inheritance
• Inheritance is often called white-box reuse
• Composition is often called black-box reuse
• It enforces the encapsulation built into the
  system design
• One way to moderate the effects of composition is
  to allow an object to delegate its operations to
  another object
• The object interfaces must be designed very
  carefully
• Each construction paradigm has advantages and
  disadvantages

36
Design Aids

• Design for Change
• The only guideline that applies to all systems is
  this Design for Change
• There are many OO-related techniques to help make
  the system more flexible and maintainable
• A toolkit is a set of related, reusable classes
  that provide a well-defined set of functionality
• Frameworks and patterns are also design aids
• Focused more on design reuse than on code reuse
• Example MVC (Model-View-Controller) pattern
• A framework is a reuse of part of a
  domain-specific design
• More specialized than a design pattern
• Framework can be expanded to suit the specific
  problem frozen points, hot points

37
User Interface Design

• Several aspects of OO Program Design
• In UI program design, we must consider issues
• Defining the humans who will use the system
• Developing scenarios of the UIs
• Designing a hierarchy of user commands
• Refining the sequence of interactions
• Designing the relevant classes
• Integrating the classes
• The 1st step in UI design is to layout the
  interaction on paper
• see Fig 6.26, p.289
• see Fig 6.27, p.290

38
Data Management Design

• Address ways to store and recover persistent
  objects
• It takes into account the system requirements
  concerning performance and space
• We can perform this task in 4 steps
• Identify the data, data structures and
  relationships among them
• Design services to manage them
• Find tools to implement them
• Design classes to oversee the management
  functions
• An OO solution can use conventional file or
  relational databases
• See Fig 6.28, p.291
• It might be needed to set up tables and extra
  tables to capture the relationships

39
Task Management Design

• Task management is a critical part
• We must scrutinize the requirements and determine
  how to coordinate the activities the system is to
  perform
• A task refers a process in the system
• It may be event-driven or time-driven
• A task management is designed in 4 steps
• Identify the task and classify them as event- or
  time-driven
• Determine the priorities for the tasks
• Create a task to coordinate all other tasks
• Design the objects for each task and their
  relations

40
Task Management Design

• Task management is a critical part
• Each task must be defined formally
• to facilitate the programmers understanding for
  better implementation
• For each task, we include
• Task name, description, priority, services,
  communication mechanism, and place in the
  hierarchy
• Example see p.291
• Design pattern can assist us in deciding how to
  manage tasks
• See design patterns for task management
• see Sidebar 6.3

41
Task Management Design

• The Observer Pattern
• 4 major constructs
• A subject know its registered observers, and
  provides notice to the observers once something
  happens
• An observer can register to a subject to
  express its interesting for a subject
• a concrete subject store a state of interest
  and notify the observers when the state changes
• a concrete observer once get notified of the
  change of the state, get the interested state
• See Fig 6.29,p.293, Fig 6.30, p.293

42
6.7 OO Measurement

• An OO implementation needs measure
• Such as coupling and cohesion
• And design complexity
• This section will discuss the ways to measure
  characteristics of OO implementation

43
OO Size Measures

• Number of Scenario Scripts (NSS)
• It measures the number of scenario scripts in use
  cases
• It is correlated with application size and number
  of test cases
• This measure is useful in at lest 2 ways
• As a size measure to predicate project effort or
  duration
• As a test case estimate, it helps team to prepare
  test cases and allocate resources

44
OO Size Measures

• Number of Key Classes
• It is intended to evaluate high-level design,
  suggesting effort needed to build the system
• It also tally the number of support classes
• This is targeted at low level design
• The average number of support classes per key
  class and number of subsystems
• These are useful for tracking the structure of
  the system
• Class size is the sum of the total number of
  operations and number of attributes
• Here we count inherited features as well as
  features in the particular class

45
OO Size Measures

• Specialization Index (SI)
• The number of operations overridden by a subclass
  (NOO) and the number of operations added by a
  subclass
• To evaluate effects of inheritance
• From these, we define the Specialization Index
• SI ( NOO level ) / (total class methods)
• Each of these metrics cab be applied during the
  different stages of development
• See Table 6.5, p.295
• See Fig 6.32, p.296

46
OO Design Measures

• Design Measures focused on Design than on size
• Measuring the coupling between objects, the
  response for a class, the lack of cohesion in
  methods
• Table 6.6 shows where these metrics can be
  collected

47
OO Design Measures

• Weighted Methods per class
• Table 6.6 shows what are these metrics and where
  they can be collected
• Weighted methods per class ?ci
• Ci is the method complexity
• If the complexity of each method is 1, it is
  simply the number of per class
• The number of methods and the complexity of the
  methods suggest the amount of time and effort
  needed to build and maintain the class
• The larger the number of methods, the more effort
  and the greater the impact on the children of the
  class

48
OO Design Measures

• Depth of inheritance
• It is the maximum length of the path in the
  hierarchy of the class inheritance
• From the class to the root of the inheritance
  tree
• This characteristic makes the class harder to
  understand and harder to maintain
• The number of children
• Is the number of immediate subclasses subordinate
  to the given class
• It is another indicator of the ease of
  maintenance, testing and reuse

49
OO Design Measures

• Coupling between classes
• It is the number of related classes of a given
  class
• We want to maximum the independence of each class

50
OO Design Measures

• Lack of Cohesion in method (LCOM)
• It is more complicated
• Given a class C with n methods, M1,,Mn
• Suppose Ii is the set of instance variables
  used by the method Mi
• There are n such sets, one for each method
• We define P to be the collection of pairs (Ir,Is)
• Where Ir and Is share no common members
• We define Q to be the collection of pairs (Ir,Is)
• Where Ir and Is share at least one common members

51
OO Design Measures

• Lack of Cohesion in method
• That is
• P (Ir,Is) Irn Is ?
• Q (Ir,Is) Irn Is ? ?
• Then, We define the lack of cohesion in method
  for class C to be
• LCOM P - Q , if P is greater than
  Q
• LCOM 0, Otherwise
• This metric is based on the notion that 2 methods
  are similar if they share an instance of variable
• The larger the number of similar methods, the
  more cohesive the class
• This LCOM is a measure of relative disparate
  nature of the methods in the class

52
OO Design Measures

• The Response for a Class
• It is the set of methods that might be executed
  in response to a message received by an object in
  that class
• If many methods can be invoked
• Testing and repair become far more difficult
• High values indicate the classes need scrutiny
• Each above metrics suggest a guideline in terms
  of likelihood of faults in the design

53
OO Design Measures

• Guideline for finding faults
• The more likely that there will be more faults,
  if
• The larger the weighted method per class
• The larger the number of children
• The larger the depth of inheritance
• The larger the response for a class
• Other metrics
• Message-passing coupling
• The number of method invocations defined in a
  class
• Data abstraction coupling
• That number of abstract data types used in the
  system

54
OO Design Measures

• Other metrics
• The number of messages sent by an operation
• Indication of average operation size
• The average number of parameters per operation
• The complexity of each operation
• We can also derive measurements from a class
  description, see example on p.301
• Fan-in the number of classes calling this class
• Fan-out the number of classes called by this
  class

55
Where to do measurement

• The best set of metrics is not yet found
• The measurement is valuable only when we can
  apply it to increase our understanding,
  predication and control
• There are metrics related to each of the 6 types
  of UML documents
• Use cases, class diagrams, interaction diagrams,
  state diagrams, package diagrams, class
  descriptions
• See Table 6.7, p.302

56
Exercises

• On Page 306
• Problem 2
• Problem 3
• Problem 4
• Problem 5