QFD_OOD

7/30/2019 QFD_OOD

http://slidepdf.com/reader/full/qfdood 1/18

Integrating QFD with Object Oriented Software Design

Methodologiesby

Walter M. Lamia

Software Engineering Institute1

Carnegie Mellon University

Pittsburgh, PA 15213-3890

[email protected]

Abstract: Object oriented (OO) methodologies have emerged as a popular paradigm for software design and

analysis, both in research and practice. Several variants of OO methods are in use, but they all share

significant similarities in their approaches to modeling the application domain. Quality Function

Deployment (QFD) is also a design analysis and domain modeling technique with many parallels to OO

methods. This paper contains an overview of object oriented design concepts, and shows how familiar

QFD techniques are an effective aid for the OO analyst. QFD is a much easier way to approach the

initial information collection and provides easy-to-understand structuring tools that do not require

extensive training in OO concepts and methods.

Overview of Object Oriented Software Concepts

The following section is a brief overview of some object oriented concepts. It is beyond the

scope and purpose of this article to discuss details of OO methodologies in depth. Many good

sources of comprehensive elucidations on object oriented software engineering are given in the

bibliography.

Objects, messages, and encapsulation

The fundamental concept in object oriented methodologies is, appropriately, theobject . An

object is a representation, or model, of a real-world entity. Objects have both data, which are

usually called attributes, and behaviors, which are called methods. Since OO technology washeavily influenced by the analysis and design needs of real time control software applications, it

was appropriate to envision objects as software representations of physical devices, such as sen-

sors, actuators, and displays. A stepper motor, for example, has a state attribute (on or off ) and

behavior (turn_left , turn_right , and stop_motion).

OO methods have also successfully been applied in more traditional information technology

domains such as banking, accounting, personnel, etc. In these data-intensive applications, objects

represent business entities and the data and processing operations that are associated with them.

For example, a banking system might contain objects that represent individual checking accounts.

Each account object contains data attributes for the name of the account owner, address, account

number, current balance, and so forth.

Objects communicate via messages sent to each other, with the assistance of the underlying

language and operating run time support systems. Each message received by an object should

have procedural code that interprets and carries out the function requested by the message; if the

object does not understand the message, an error notification routine is invoked. In the checking

1 Sponsored by the U.S. Department of Defense

1995 QFD Symposium May 14, 1995

7/30/2019 QFD_OOD


account example, methods such as deposit_to_account and debit_from_account are in-

voked by messages exchanged between the account objects and transaction objects.

Because these messages are the only interface that the object presents to the "external

world," the implementer is free to design internal object representations of data and procedures in

any manner, as long as the message interface remains consistent. By taking this approach, details

of the internal representation can be modified as needed without affecting the rest of the system.

For example, temperature might be stored internally by the thermometer object in units of Fahren-

heit, Celsius, or Kelvin, as long as the object accepts and replies correctly to messages requesting

any particular reporting unit. This is known asencapsulation, or information hiding, and is a key

concept in object orientation.

Classes and instances

Obviously, if every object in an application had to be individually and explicitly coded, it

would not be practical to build a system consisting of hundreds of separate objects. Hence, every

object is associated with a specific class. Classes are templates for objects, which specify the

kinds of attributes and methods each object will have. Classes do not hold any of the values for

the attributes of specific objects. Objects come into existence by being created asinstances of a

specific class. When an object instance is built from a class, a complicated process is used to de-

termine the attributes and methods for that object, which involves allocating space, linking the ob-

ject into various system data structures, and perhaps initializing certain attributes.

Users of document processing products such as Ami Pro, Framemaker, or Microsoft Word

for Windows have already encountered the concept of classes and instances. These products use

the notion of paragraph styles to hold templates for various text characteristics, such as fonts, in-

dentations, line alignment, margins, and so forth. Whenever a new paragraph (object) is created

(instantiated) in a document, it inherits the formatting options of the template (class), but does not

yet contain any data (text). All instances of paragraphs of a certain type (class) share the same

formatting characteristics, but have different data attributes.


Instance of a 2-door, red, ... van

Class of Vans» # doors» length» color» engine option

» VIN

Figure 1

7/30/2019 QFD_OOD


Inheritance and multiple inheritance

Object classes are assembled into a hierarchy of classes and superclasses, analogous to the

way we assemble affinity groups in QFD. This is a convenient way to abstract the common char-

acteristics of objects into a tree structure, thus avoiding redundant descriptions of data and proce-

dure attributes. Each subclass inherits the characteristics of its superclasses, on up to a root class,

often named the Object class. This has the additional advantage that whenever a change is made

to a superclass, all of its subclasses automatically inherit the changes as well. Again, this is a fa-

miliar idea from document processing products; changing the font for a paragraph style changes

all of the paragraphs using that style, without requiring the user to manually modify each individ-

ual paragraph instance. In the example shown in Figure 3, all vehicles share some data attributes,

such as length, weight, and speed, but attributes such as number of wheels would not apply toseagoing vehicles.

Some, but not all, object oriented programming languages implement what is called multiple

inheritance. This is a mechanism whereby instances of objects can inherit characteristics from

more than one class. In the example in Figure 2, the instantiated van inherits characteristics from

both the body style class and the engine class, to synthesize a complete object. Some theoretical

and practical problems arise from the possibility of inheriting conflicting information; interested

readers may consult the references for more details.

Polymorphism

Polymorphism is the term used when two different methods have the same name, but do dif-ferent processes in different objects. The idea comes from the fact that in a large system several

objects may respond to the same message, but the behaviors each exhibit are different. Polymor-

phism adds to the semantic richness of an object system and relies on the objects to correctly im-

plement the requested behavior without needing to be aware of the specific details encapsulated in

each object. In the example in Figure 4, thedisplay_balance message sent to different objects

yields different, but semantically compatible, results.


Class of Engines

gasoline diesel turbine

Instance of a van multiply inheritingattributes from two classes.

# cylinders

(super)Class of Vans» # doors» length» color» engine option

» VIN

Figure 2

7/30/2019 QFD_OOD



Vehicles

SeaVehiclesAirVehicles

LandVehicles

TrucksVans

Instances of specific objects from the class Trucks

Instance of a specific objectfrom the class Vans

Figure 3

AccountReport

display_balancedisplay_balance

aJapaneseAccount

" ¥ ""£"

aBritishAccount

Figure 4

7/30/2019 QFD_OOD


Brief survey of popular OO methodologies

Very broadly, OO technology divides into practices for Object Oriented Analysis (OOA),

Object Oriented Design (OOD) and Object Oriented Programming (OOP). OOD focuses on tools

and techniques for creating specific design schemes which are implemented in actual code using

an OOP language, such as C++ or Smalltalk. In this paper I do not address OOD or OOP, but

concentrate on the practices of OOA and its connection to QFD.

Appendix A has a list of major OO methodologies which have been published and are in use

in the industry. This list was taken from a widely distributed document of Frequently Asked

Questions about OO information, which can be found in its entirety at:

http://iamwww.unibe.ch/~scg/OOinfo/FAQ/oo-faq-S-3.7.html#S-3.7

It should be apparent from the number of methodologies cited that there is no generally ac-

cepted standard reference model for OO analysis. The ANSI X3H7 working group has produced

a Features Matrix to compare various object model interoperability issues, which may be obtained

at the location given in [6].Object Oriented Analysis

It is difficult to determine where OOA ends and OOD begins, and various methodologies

distinguish the demarcation differently. For purposes of this discussion, I shall use the definitions

from Monarchi and Puhr [7]: "Analysis deals with the problem domain, and design with the solu-

tion domain; OOA focuses on problem domain objects and OOD on solution domain objects.

Problem domain objects represent things or concepts used in describing the problem rather than

the solution. We call them semantic objects because they have meaning in the problem domain."

For example, a library information system might have semantic classes such as library patron, li-

brarian, book, and transaction terminals. During analysis, the focus is on representing the prob-

lem, identifying abstractions that are meaningful given the system requirements, and determiningspecifications.

Domains and Subsystems of Application

Circulation

Operations

Acquisition Operations User Interface

Steps of OOA Find book Check out ... Add a book Remove ... Screendisplays

User Inputmech.

...

InformationModels

StateModels

ProcessModels

Project matrix for a Library Information System. The matrix cells represent units of work to be

accomplished during analysis.

Table 1


7/30/2019 QFD_OOD


OOA concepts analogs in QFD

Most of the OOA methodologies start by partitioning the application into functional systems

and subsystems. These may be called domains and subsystems [8] or high level structures [2].

They are usually diagrammed with the familiar interrelationship digraph such as the one in Figure

5.2 In the Shlaer-Mellor [8] methodology, three separate but related models are then constructed

by the analyst (see Table 1.) Other methodologies have similar modeling techniques, but Shlaer-Mellor defines them particularly clearly.

The Information Model identifies conceptual entities: the objects, their associated data at-

tributes, and relationships among the objects, that make up the subsystem. A complete descrip-

tion of each object, attribute, and relationship must be prepared for documentation for the graphic

model. I will demonstrate later how QFD methods and artifacts provide a very natural and com-

prehensible way to produce this documentation.

The State Model represents the conditions through which the objects that participate in the

subsystem pass over the course of execution of a complete transaction or operation. For instance,

an elevator object transitions from the state of door_is_open through the state door_is_closed

while in motion, then back to the state door_is_open. State transition tables and diagrams are

used to depict this model.

Finally, the Process Model defines each action the subsystem performs in terms of processes

and object data stores, where a process is a fundamental unit of operation and an object data store

corresponds to the data attributes of an object in the information model. These are depicted

graphically in an action data flow diagram (ADFD). These are rather dense graphs which contain

a great deal of detail. I will demonstrate how QFD matrices can depict much of the same infor-

mation, in a way that is easier to construct initially than the Shlaer-Mellor ADFD.

I find many interesting parallels between the OOA approaches and QFD. While the termi-

nology is somewhat different, the underlying concepts are virtually identical. Hence, I believe thatthe approaches to product and service design used in QFD offer valuable tools to enhance the

practice of OO analysis.

Incorporating QFD in OOA

The methodologies I researched give little guidance about where to start when undertaking

an object oriented development project. If fact, many authors admit that getting started is one of

the hardest parts of the OO paradigm. Ian Graham [2] states: "The outstanding issue is how to

identify objects in a real application. This issue is one that provokes deep philosophical debate

and often much confusion."

Ivar Jacobson [4] proposes what he calls the requirements model, which is the beginning

point of his Objectory methodology. All subsequent models are derived from the requirementsmodel, and the final product is tested and verified against it. The requirements model consists of

the use case model, the problem domain object model, and the user interface descriptions.

Instead of starting out by identifying objects, he suggests starting with identifying actors, which

represent the functional roles that users can play, and use cases, which are comprehensive se-

quences of actions the actors perform with the system to accomplish a complete task. A real

2 The example diagram is adapted from [2], p20.


7/30/2019 QFD_OOD


person can appear as instances of (play the role of) several different actors. For instance, a system

may have the actor roles of librarian and patron; Pat Smith may sometimes act as a librarian, andsometimes as a library patron, but performs different use cases depending on the role being

played.

A use case is a specific way of using the system to accomplish an identifiable task. It com-

prises a complete course of events initiated by an actor and it specifies the interaction that takes

place between the system and actors. The collection of all use cases specifies all the ways of us-

ing the system. For each use case, a detailed description is made, and when the system is in op-

eration, instances are created from the descriptions in this model. These descriptions are crucial

for the identification of the actual objects in the system.

Actors in Objectory are comparable to the idea of types of customers in QFD terminology.

Use cases parallel the notion of "function" in QFD. (Since there is no commonly accepted opera-tional definition of function in QFD practice, I will use the intuitive notion that it is something

useful the system does for the user.) The very strong emphasis in Objectory on modeling the us-

ers of a system and the demands they place on it to perform useful work, and the importance of

this model as the driving impetus of the subsequent design, are very similar to the QFD doctrine

of comprehending and deploying the voice of the customer throughout product design and

delivery.

Objectory does not, however, incorporate the concept of customer demanded quality with

which we are familiar in QFD. This QFD principle, which holds that quality is defined by custom-

ers in their own words, and that there are quantifiable differences in the perceived importance of

these demands, would be an excellent extension to OO analysis. This principle would providevaluable guidance to designers and project managers on where to allocate their most critical re-

sources, and how to make implementation choices that optimize the satisfaction derived by users

of the finished system. Conversely, the use case model provides QFD an extremely useful tool for

identifying and conveying functional descriptions of the product under study. Many practitioners

have recognized the need for a robust functional modeling technique within QFD, but no one ap-

proach has ever achieved much popularity. I suggest that the use case models from Objectory are

an attractive solution to this need.


Stock

control

layer

Pricing/billinglayer Customer

information

layer

Product

requirements

layer

Employee

information

layer

Figure 5

7/30/2019 QFD_OOD


QFD can be used as an excellent starting point for OO analysis. Techniques which have

been successfully used in the practice of QFD, such as Contextual Inquiry (CI) [3], can effectively

and quickly identify salient OO features within a system. (An exceedingly oversimplified defini-

tion of CI is "data gathering by walking around."3)

In CI, a fundamental principle is that users are to be studied in their normal working context

("going to the gemba.") Users are studied as they perform ordinary work tasks. Analysts follow-

ing the CI technique observe users working and record both what the users do and how they in-

teract with their work environment. Once data are collected, affinity diagrams are constructed to

structure the information into understandings of what is taking place, and to discover any gaps or

weaknesses in the data. Follow-up interviews are used to validate the interpretations, and to ad-

dress any weaknesses. The CI technique has the advantage that analysts can note the way in

which users organize their workplaces, including hardware and software tools, reference materi-

als, working papers, furniture arrangement, etc. Analysts strive to understand the purpose of the

work performed and how the environment supports or hinders that purpose.

Experience demonstrates that both the analysts and users/participants can easily understand

these information collection methods without requiring extensive training in OO theory and con-cepts. While these methods are themselves an interesting domain of study, this paper is focused

specifically on QFD related artifacts that are useful in OOA.

Suggestions for QFD style matrices useful in OOA

In the following section, I present a number of matrices that are derived from QFD, and dis-

cuss briefly how each is related to OOA. I also introduce the labeling notation A×B, where A

represents the data type contained in the left hand column of the matrix, and B the data type con-

tained in the top row of the main body of the matrix. I find this notation easy to use and more de-

scriptive than the customary "A-1" nomenclature. It also permits faster location of related

matrices— just find the same type label on different matrices. This, in fact, is an object oriented

concept applied to QFD.

Users × Actor Role

Actor role

Individual Users Patron Librarian Volunteer ...

Jan¤ ¡

Pat¤ ¡

Prioritization of role 5 3 1 ...

In Objectory terminology, this matrix summarizes the different roles people in the systemplay at various times. This matrix is easy to assemble by interviewing individuals and recording

the actions performed in their daily activities. It will most likely be incrementally developed, be-

cause it is not easy for people to categorize all their activities extemporaneously, especially in ad-

ministrative and technical jobs. The bottom row, which is optional, shows the relative importance

of the roles. In this example, the Patron role has the highest priority, followed by the Librarian

3 This is a pun on Tom Peters' "Management by Walking Around."


7/30/2019 QFD_OOD


then the Volunteer. These were determined by the consensus judgment of the analysis team. This

prioritization will be deployed through subsequent matrices in the customary QFD manner.

Actor role × Use Case

Use Case

Actor roles Search for book Find book on shelf Check out book ... Role wt

Librarian¡ i ¤ i ¤ s 3

Patron¤ i ¤ i 5

Function Wt. 54 18 72 ...

In this matrix, we show the functions and operations in which each actor role participates.

Each use case represents a coherent, useful function which the system performs for a user playing

one (or more) of the actor roles. This example uses the matrix to connote which actor roles have

greater or lesser reliance on different use case functions. In point of fact, some use cases are initi-

ated by one actor role, but engage the participation of other roles during their execution, such asthe role of the librarian in service to the patron during book check out. Additional notations, such

as i for initiator and s for server could be included in the cells to convey this information.

This example illustrates calculating function weights for each use case. Using the de facto

standard encoding of ¡ = 3 and ¤ =9 for the correlation symbols, and the role weights brought

forward from the Users×Actor Role table, the function weight is calculated by multiplying the

role weight by the correlation strength and summing the columns, following the usual QFD dot-

product computation algorithm. Different encodings could be used as appropriate for the situa-

tion being analyzed.

Subsequent examples omit the prioritization calculations for the sake of brevity. The same

procedure could be applied in all matrices to deploy priority weights. I believe, however, that de-tailed weight calculations should only be used as necessary to make important design and devel-

opment decisions. Excessive reliance on numeric results frequently obscures the real objective of

the QFD study, which is to facilitate the attainment of a complete, consistently understood model

of the application by the design and user team, and rational decision making based on that model.

User Demanded Quality × Use Case

Use Case

Demanded Quality Search for book Check out book ...

Must be fast¤

Must be mistake proof¤

This matrix shows the user demanded quality characteristics of the functions (use cases) the

system performs. Although it might sound somewhat heretical to QFD practitioners, it is not al-

ways absolutely necessary to construct this matrix. Particularly in highly technical, embedded

software applications, the function specifications which are embodied in the description of the

use cases contain all the important demanded quality characteristics. However, for products and


7/30/2019 QFD_OOD


services which will be used extensively by humans or will be sold to a wide market, I strongly rec-

ommend this step. This connection to the voice of the customer is notably absent from all of the

standard OOA methodologies I studied. This is an important contribution which QFD has to of-

fer to OOA.

Use Cases × Objects

Object

Use Case Patron Book Terminal Librarian ...

Search for book¤ ¤ ¤

Check out book¡ ¤ ¤

This matrix shows which objects participate in the various identified use cases. Recall that

objects are models of, and correspond to, real-world entities. A potential problem, deliberately

shown in this example, is the ambiguous use of the names Patron and Librarian. These terms are

used for both the name of actor roles and for system objects. Good practice in both QFD and

OOA recommends that unique names be used for all entities in the system being modeled. This is

the sort of human perception problem that is very effectively revealed by teamwork-based QFD

practices which should be used to fill in the correlation cells of the matrix.

This matrix is particularly useful for collecting information to be used in defining the com-

plete state models and process models. Additional details, such as whether the object is created,

removed, modified, or provides information to the use case, could be added to the matrix cells.

Use Cases × Data Attributes

Data Attribute

Use Case Title Author Subject Call number Library card number ...Search for book

¤ ¤ ¤ ¡

Check out book¤ ¤

This matrix shows which data attributes participate in carrying out various use cases. No-

tice that we do not show objects in this matrix. I see this is as an advantage because it greatly

simplifies the analysis activity. It is often easier to ask participants during initial analysis what in-

formation they need to carry out a function without regard to the source or repository of the in-

formation. By combining this matrix with the UseCase×Object and Object×Attribute matrices,

we have all the information needed to construct the process model. I recommend this incre-

mental, QFD-based approach to initial information collection and tabulation rather than the moreformidable graphic models which most OOA methods employ. The matrix representations are

more understandable to people untrained in OOA concepts, and the diagrams, which are still use-

ful to the specialist, can be synthesized more easily from the information contained in the matrix.

Objects × Data Attributes

Data Attribute


7/30/2019 QFD_OOD


Object-class Name Address Library card number Employee ID ...

Patron-class¤ ¤ ¤

Librarian-class¤ ¤ ¤

This matrix, in which I have distinguished objects from actor roles, is very useful to the OOanalyst and the OO designer. It explicitly identifies objects which share common data attribute

definitions, a key indicator for constructing an abstract superclass type. In fact, in a completely

normalized hierarchy of classes, a matrix with all the classes and superclasses as rows and all the

data attributes as columns would have exactly one correlation symbol in each column, signifying

that there are no redundant data definitions in the design. This is the theoretic ideal, however.

Various pragmatic reasons, such as system performance, sometimes require redundant attributes

in a design. Unfortunately, this admits the vexing problem of inconsistent definitions. By using a

matrix such as this, the configuration management problem is made more tractable.

Objects × Objects, Showing Entity Relationships

Object

Object Patron Book Shelf Floor ...

Patron 0..n

Book 0..1 1 1

Shelf 0..n 1

Floor 0..n 1..n

...

This matrix is read across, e.g. "A Patron is associated with zero to many Books", or "ABook is associated with exactly one Shelf." This matrix shows the association relationship be-

tween pairs of entities in the system. This is an important relationship used in defining the set as-

sociations among objects. This table embodies the same information as graphic entity-relationship

diagrams used in OOA, but does not depend on symbology to convey meaning, so it is somewhat

more explicit. In addition, the matrix cells can be annotated with additional processing rules, such

as the maximum number of books on a particular subject any one patron may check out or the

rule that no one with overdue books may check out any more books.


7/30/2019 QFD_OOD


Objects × Classes, Showing the AKO Relationships

Class

Object Person Holding ...

Patron¤

Librarian¤

Book¤

Periodical¤

...

This is a simple matrix showing the relationship between objects (actually, leaf-node object

classes) and superclasses. In a strictly hierarchical class structure tree, this matrix would not be

very interesting, since the entire class structure could be represented by an affinity grouping along

the side of the matrix. However, when multiple inheritance is introduced, this matrix clearly indi-

cates all of the source superclasses which contribute to object instances and helps uncover poten-

tially conflicting attribute or method definitions.

Use Cases × IEEE Quality Factors

Quality Factor

Use Case Efficiency

Integrity

Reliability

Survivability

Usability

Correctness

Maintainability

Verifiability

Expandability

Flexibility

Interoperability

Portability

Reusability

......

Search for book

Check out book

This matrix can be used to map the functions of the system to a set of quality factors. Thequality factors are suggested in Appendix A of the IEEE Draft Standard for a Software Quality

Metrics Methodology [13] as example factors and sub-factors. AppendixC gives an illustration

using a matrix to map system functions to quality factors for an example application, which is very

similar to the familiar methods of QFD. This document also uses a triangular matrix to show

complementing and conflicting relationships between each pair of quality factors, isomorphic to

the triangular "roof" matrix of the House of Quality (A-1) matrix.

Some practitioners of QFD, myself included, are uncomfortable with a standardized set of

quality factors. It is risky to rely on a list of factors that are by necessity very general in nature.

Designers and engineers will be seduced into believing that they need only consider the "standard

quality factors" to do all that is necessary to assure that a quality product has been developed.The history of QFD, if it has shown anything, has been that successful designs are those which

meticulously incorporate the voice of the customer as it directly relates to the users' experience

with the product in actual use. Every attempt of which I am aware to create generic QFD tables,

customer demands, or quality characteristics has been a disappointment. The use of generic lists

of "-ilities" should be limited to verification and completeness checking of distinct quality tables

that have been constructed according accepted QFD practices.


7/30/2019 QFD_OOD


Looked at another way, these "-ilities" represent the "must-be" quality (dissatisfiers in

Kano's terminology.) From this perspective, it is easy to see that this analysis, while useful, is in-

sufficient to assure exciting quality in a system design.

Failure Mode Analysis

System event PriorityWt

Failure Modes Likelihood DetectionMechanisms

Counter Measures

Search for book 54 Title misspelled byuser

Medium (or othermetric)

Spell checkwords

Suggestcorrections to user

Check out book 72 Bar code misread Low Check digit Request rescan

This matrix is actually a Failure Mode and Effects Analysis (FMEA) table, another of the

tools used by the QFD practitioner. It is valuable as an OOA tool because there is so little men-

tion of failure analysis in the OO literature. The only occurrence I found was in Shlaer-Mellor.

Their book simply suggests some broad questions to consider in looking for failure in the externalprocess, such as equipment malfunction, personnel error, and actuator failure and guidelines for

identifying potential sources of failure in the OOA modeled system, such as "Is each event

guaranteed to occur?" and "What happens if the event is delayed?"

I believe the extensive literature and experience of FMEA is a much more robust approach

to understanding and coping with failure modes of the system. The fact that object orientation in-

tentionally attempts to apply the mechanical piece-part engineering paradigm to model software

systems instead of the classical functional paradigm makes FMEA all the more appropriate as a

reliability enhancement tool.

One of the reviewers of this paper suggested that the FMEA and Quality Factor tables

could be combined to good effect. In this mode, each system event is checked against each Qual-ity Factor to see how it might fail along that dimension. For example, the designer might ask:

"How can the implementation of 'Search for book' fail to be efficient?" and

"How can the implementation of 'Search for book' fail to be reliable?" etc.

When possible failures are thus identified, the details are entered in the FMEA table and

dealt with accordingly.


7/30/2019 QFD_OOD


Transforming Object Oriented Analysis into Object Oriented Design

OOA Models(ref. Shlaer-Mellor)

QFD OO Tables InformationModels

StateModels

ProcessModels

Users × Actor Role¤ u u

Actor Role × Use Case¤

User Demanded Quality × Use Case¡

Use Cases × Objects¡ ¤

Use Cases × Data Attributes¤ u ¡

Objects × Data Attributes¤

Objects × Objects - Entity Relationships ¤

Objects × Classes - AKO Relationships¤

Use Cases × IEEE Quality Factors¡

Failure Mode Analysis¡

Table 2: Contribution of QFD matrices to Shaler-Mellor OOA Models

After the OOA phase of a project has been completed, it must be transformed into an object ori-

ented design. There are many ways to do this. The design task is further complicated by con-

straints emanating from the functions and features of the particular OO development language and

run-time services selected for the project.

Shlaer-Mellor have devised one such technique that uses a language-independent graphical

notation for depicting the design of an object oriented system. They further describe a systematic

process for deriving the OOD directly from the OOA models. Interested readers are referred to

Chapter 9 of [8]. Table 2 summarizes how the proposed QFD analysis matrices contribute infor-

mation to each of the Shlaer-Mellor OOA models.

Table 3 is another summary table which shows how system analysis information is used in

the matrices suggested in this paper. The left column shows the information type appearing on

the left side of an analysis matrix, and the top row shows the information type that appears on the

top. The table cells have reminders of the purpose of each matrix. I find this kind of display to be

useful in seeing how the various kinds of information available to the analyst interact, and to sug-

gest possible new uses of the available information by considering what the unused table cells

might represent.


7/30/2019 QFD_OOD


7/30/2019 QFD_OOD


techniques have been refined for ease of comprehension and use, and are therefore much more ap-

proachable for the non-specialist.

A number of QFD-based tabular forms are proposed in the paper which parallel the graphi-

cal diagrams used in OOA. QFD does not, however, completely supplant the analysis phase of

objected oriented software development because many technical details needed by the OO design-

ers and programmers are not fully elaborated in the QFD studies. The paper concludes with some

suggestions for opportunities to integrate QFD and OO automated support tools.

Final Note

I quote the following from Shlaer-Mellor [8, p.64]:

Once the subject of abnormal behavior comes up, it is easy to get carried away and in-

vestigate myriads of possible failures, from the real and reasonable to the outstandingly

far-fetched. Abnormal behavior can be very complex, and the models become corre-

spondingly larger and more complicated as more and more abnormal cases are consid-

ered. This is the time to draw upon the best engineering judgment available in your

particular situation, and use it to prioritize the cases investigated and to keep the work within bounds. [my emphasis]

This sound advice, from a text on object oriented analysis and design, is eminently applica-

ble to the entire practice of QFD. What better demonstration is there of the synergy between the

two disciplines!


7/30/2019 QFD_OOD


Appendix A: Major Object Oriented Methodologies

Berard

BON

Booch

Coad/YourdonColbert

de Champeaux

Embley

EVB

FUSION

HOOD

IBM

Jacobson

Martin/Odell

ROOM

Reenskaug (OOram, was OORASS)Rumbaugh et al.

Shlaer and Mellor

Wasserman

Winter Partners (OSMOSYS)

Wirfs-Brock et al.

Further Ideas And Techniques:

Meyer

Stroustrup

Note: Readers interested in full reference citations for the listed methods listed are encour-

aged to consult the Frequently Asked Questions list at the World Wide Web site

cited in [12].


7/30/2019 QFD_OOD


References

1 Arnold, P. et. al. An Evaluation of Five Object-Oriented Development Methods. HP

Laboratories Bristol (UK): Hewlett Packard report HPL-91-52, June 1991.

2 Graham, Ian. Object Oriented Methods. Reading, MA (USA): Addison-Wesley, 1991.

3 Holtzblatt, K. and Beyer, H. "Making Customer-Centered Design Work for Teams,"

Communications of the ACM 36 , 10 (Oct 1993): 92-103.

4 Jacobson, Ivar. Object-Oriented Software Engineering: A Use Case Driven Approach.

Reading, MA (USA): Addison-Wesley, 1992.

5 Korson, T. and McGregor, J.D. "Understanding Object-Oriented: A Unifying Paradigm"

Communications of the ACM 33, 9 (Sept 1990): 40-60.

6 Manola, Frank (ed.) "X3H7 Object Model Features Matrix", available via anonymous FTPat ftp://ftp.gte.com/pub/dom/x3h7/x3h7.rtf (Rich Text Format file)

- Also see the X3H7 World Wide Web home page at

http://info.gte.com/ftp/doc/activities/x3h7.html

7 Monarchi, D.E. and Puhr, G.I. "A Research Typology for Object-Oriented Analysis and

Design," Communications of the ACM 35, 9 (Sept 1992): 35-47.

8 Shlaer, S. and Mellor, S.J. Object Lifecycles: Modeling the World in States. Englewood

Cliffs, NJ (USA): Yourdon Press, 1992.

9 Sward, R.E and Cook, D.A. "Object-Oriented Design Tutorial."˝ Salt Lake City, UT(USA): The Sixth Annual Software Technology Conference, (10-15 April 1994).

10 Uchimaru, K., Okamoto, S., and Kurahara, B. (translated by Scott Decker) TQM for

Technical Groups: Total Quality Principles for Product Development. Portland, OR

(USA): Productivity Press, 1993.

11 Yourdon, Edward. Object-Oriented Systems Design. Englewood Cliffs, NJ (USA):

Yourdon Press, 1994.

12 Object Oriented FAQ World Wide Web page found at

http://iamwww.unibe.ch/~scg/OOinfo/FAQ/

13 IEEE Draft Standard P-1061/D24, Standard for a Software Quality Metrics Methodology,

May 1, 1992.


QFD_OOD

Documents

Transcript of QFD_OOD