Post on 21-Jan-2016
SE: CHAPTER SE: CHAPTER 66Considering ObjectsConsidering Objects
The Special Nature of OO Development
Use Cases
Using UML
OO System Design
OO Program Design
OO Measurement
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
6.1 What Is OO ?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
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 associatedEach 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 commonWe can represent a class using a box such as the one in Fig 6.2Class 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 object’s behaviors and attributes, hiding the implementation details
Characteristics of OO Characteristics of OO
We can organize classes hierarchicallyForming inheritance structures
We can use an abstract class to simply the hierarchyWhere 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 subjectedThe behavior is triggered by receipt of a particular
message, or entrance into a particular stateThe same behavior may exhibit differently on
different classes; this is known as polymorphism
Characteristics of OO Characteristics of OO
See graphic representation of class using UMLFig 6.3, p.262
Persistence is the ability of an object’s name, states and behaviors to transient time and spaceThat is, the object’s name, states and behaviors are
saved as the object is transformed
6.2 The OO Development Process6.2 The OO Development Process Advantage of OO Development
One of the advantage is its consistency of languageWe can describe both the problem and the solution in the same
terms : classes, objects, methods, attributes and behaviorsThroughout 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
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 processOO is a philosophy of problem and solution
representation, not a life-cycle by itselfOO can be used in many different software life-cycleOO 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
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 user’s languageAnd discusses the concepts and scenarios likely in
the application domainThe concepts include information, services and
responsibilitiesThe requirements definition can be independent of its
representation as objects
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
6.3 Use Cases6.3 Use CasesUse Cases
It describes particular functionality that a system is supposed to perform or exhibitBy 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 scenarioOf how the external entity interacts with the systemThe use case is represented as a drawing plus a brief
textual sketch of how the function is performed
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
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 caseSee Fig 6.5, p.266
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 roleWe 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
Uses Cases Alternative ways of system
requirementsSometimes problems are hidden with
requirements written in natural languageWhen we translate them to use cases, these
problems surface.It is a good check on the requirements qualityOnce 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.
6.4 Representing OO: Using UML6.4 Representing OO: Using UML
UML : Unified Modeling LanguageIs a notational approach that is popular for
describing OO solutionsOMG (Object Management Group) has adopted
UML as the OO notational standardUML can be used to visualize, specify or
document a problem and its solutionsUML diagrams include dynamic view, the static
view, restrictions and formalization of systems
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 processBy describing the activities that the business will
performUse 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
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 diagramThe 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
UML in the Process UML being used throughout the process
Sequence diagrams and collaboration diagramsThe interactions among classes are illustrated using interaction
diagrams of these 2 typesSequence 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 usingPackage diagrams show how classes are divided into modelsComponent diagrams reflect the final system modulesDeployment diagrams show the network links involved with the
application being built
6.5 OO System Design6.5 OO System Design
We begin with use of UML class diagramsThese diagrams describe the object types and
their static relationshipsIn 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
Requirements elicitation We try to extract nouns
To look for particular items that can suggest object classes, we seekStructures, external systems, devices, roles, operating
procedures, places, organizations, …
We can use questions as guidelines about what to include in the list of candidate classesSee questions listed on P.272
Requirements elicitation We try to identify behaviors
From the requirements statements, we extract verbs
We can look for particular items that suggest behaviorsImperative 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
Requirements elicitation Use UML boxes to describe classes
See Fig 6.10, p.274It includes: class name, attributes, operationsSee Fig 6.11, p .275 for Inheritance relationship
Class RelationshipsRelationships usually consist of 4 types
Generalization, association, aggregation, composition
Requirements elicitation Class Relationships
generalizationThe super-class generalizes the subclass
Association2 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, andThe numbers at each end show the cardinality
associated with each member of the relationship
Requirements elicitation Class Relationships
compositionAn composition is recognized when one class is part
of another classWe denote the part-of relationship using a line that
ends in a filled diamondThe numbers at each end show the cardinality
associated with each member of the relationship
AggregationAn unfilled diamond shows an aggregation that is not
an inheritance relationship
See Fig 6.12, p.275 and Fig 6.13,p.276
Requirements elicitation Other ways of associating classes
Association can be enhanced with Associative class that depicts the association relations
in further detailsQualified association makes the related class object
qualified with some attribute valuesSee Fig 6.14, p.276
See example of Fig 6.15, p.277And Fig 6.16, p.278And Fig 6.17, p.279, with cardinality added to
the diagram
Other UML Diagram Class Description Template
Each Class is described in more detail using itSee example on p.278-280The template lays the groundwork for the
program designIt includes information essential for programmers to
implement the design as codePrivate interfacePublic interface
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
Other UML Diagram Package Diagram
See Fig 6.18, p.281 for package diagramThe dashed arrows shows the package
dependenciesAs you can see, package diagram gives a high
level overview of the system and notes the high level dependencies
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 diagramsSequence diagram shows the sequence in which
activities occurObject’s 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
Other UML Diagram Interaction Diagrams
Collaboration diagram shows how the objects are connected statically, based on use caseObjects are icons; arrows used to depict messages;
the sequence of messages is indicated by a numbering scheme
See Fig 6.20, p.282
Dynamic ModelsState diagrams and activity diagrams
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.284Start state is represented by a black dotEnd state is a smaller black dot inside a white dotA rectangle represents a stateAn arrow shows the transition from one state to anotherA condition is noted with a bracket expression next to an arrow
Other UML Diagram Activity Diagrams
Activity diagram is used to model the flow of procedures or activities in a classIt uses a decision node to represent conditional
choiceSee Fig 6.24, p.285 for notions usedStart node is represented by a black nodeThe end node is a smaller black dot inside a white dotA rectangle represents a stateArrows used to show transitions from one state to
anotherHorizontal bar allows broadcasting events and
parallel activities to be representedSee Fig 6.25, p.285
6.6 OO Program Design6.6 OO Program Design
Program design begin with classes & objectsBut we must embellish and modify them to
include more items, includingReused components, reusable components, user
interfaces, data structure and management detailsAnd there are likely more than in the system design
In this stage, we must make more detailed decisions about the data structures and each object’s 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 operationsIt also allow us to take advantages of polymorphism
or dynamic binding.
OO Program Design Design Implementation
The choice of object composition and class inheritanceInheritance is often called white-box reuseComposition 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
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 maintainableA toolkit is a set of related, reusable classes that
provide a well-defined set of functionalityFrameworks and patterns are also design aids
Focused more on design reuse than on code reuseExample : MVC (Model-View-Controller) patternA framework is a reuse of part of a domain-specific design
More specialized than a design patternFramework can be expanded to suit the specific
problem : frozen points, hot points
User Interface Design Several aspects of OO Program Design
In UI program design, we must consider issuesDefining the humans who will use the systemDeveloping scenarios of the UIsDesigning a hierarchy of user commandsRefining the sequence of interactionsDesigning the relevant classesIntegrating the classes
The 1st step in UI design is to layout the interaction on papersee Fig 6.26, p.289see Fig 6.27, p.290
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 themDesign services to manage themFind tools to implement themDesign classes to oversee the management functions
An OO solution can use conventional file or relational databasesSee Fig 6.28, p.291 It might be needed to set up tables and extra tables to capture
the relationships
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 systemIt may be event-driven or time-driven
A task management is designed in 4 stepsIdentify the task and classify them as event- or time-
drivenDetermine the priorities for the tasksCreate a task to coordinate all other tasksDesign the objects for each task and their relations
Task Management Design Task management is a critical part
Each task must be defined formallyto facilitate the programmers understanding for better
implementationFor 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 tasksSee design patterns for task management
see Sidebar 6.3
Task Management Design The Observer Pattern
4 major constructsA 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
6.7 OO Measurement6.7 OO Measurement
An OO implementation needs measureSuch as coupling and cohesionAnd design complexity
This section will discuss the ways to measure characteristics of OO implementation
OO Size MeasuresNumber 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 waysAs a size measure to predicate project effort or
durationAs a test case estimate, it helps team to prepare test
cases and allocate resources
OO Size MeasuresNumber 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 classesThis is targeted at low level design
The average number of support classes per key class and number of subsystemsThese are useful for tracking the structure of the
systemClass size is the sum of the total number of
operations and number of attributesHere we count inherited features as well as features
in the particular class
OO Size MeasuresSpecialization Index (SI)
The number of operations overridden by a subclass (NOO) and the number of operations added by a subclassTo evaluate effects of inheritance
From these, we define the Specialization IndexSI = ( NOO × level ) / (total class methods)
Each of these metrics cab be applied during the different stages of developmentSee Table 6.5, p.295See Fig 6.32, p.296
OO Design MeasuresDesign Measures focused on Design
than on sizeMeasuring 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
OO Design MeasuresWeighted 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
OO Design MeasuresDepth of inheritance
It is the maximum length of the path in the hierarchy of the class inheritanceFrom the class to the root of the inheritance tree
This characteristic makes the class harder to understand and harder to maintain
The number of childrenIs the number of immediate subclasses
subordinate to the given classIt is another indicator of the ease of maintenance,
testing and reuse
OO Design MeasuresCoupling between classes
It is the number of related classes of a given class
We want to maximum the independence of each class
OO Design MeasuresLack of Cohesion in method (LCOM)
It is more complicatedGiven 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
OO Design MeasuresLack of Cohesion in method
That is P = {(Ir,Is) | Ir∩ Is = Q = {(Ir,Is) | Ir∩ 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 variableThe larger the number of similar methods, the more c
ohesive the classThis LCOM is a measure of relative disparate nature
of the methods in the class
OO Design MeasuresThe 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 invokedTesting and repair become far more difficultHigh values indicate the classes need scrutiny
Each above metrics suggest a guideline in terms of likelihood of faults in the design
OO Design MeasuresGuideline for finding faults
The more likely that there will be more faults, ifThe larger the weighted method per classThe larger the number of childrenThe larger the depth of inheritanceThe larger the response for a class
Other metricsMessage-passing coupling
The number of method invocations defined in a class
Data abstraction couplingThat number of abstract data types used in the system
OO Design MeasuresOther metrics
The number of messages sent by an operationIndication of average operation size
The average number of parameters per operationThe complexity of each operationWe can also derive measurements from a class
description, see example on p.301Fan-in : the number of classes calling this classFan-out : the number of classes called by this class
Where to do measurementThe “best” set of metrics is not yet
foundThe 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 documentsUse cases, class diagrams, interaction diagrams, state
diagrams, package diagrams, class descriptionsSee Table 6.7, p.302
ExercisesExercises
On Page 306Problem 2Problem 3Problem 4Problem 5