myth and reality of ooa: the lack of domain knowledge in the representation

Myth and Reality of OOA:the lack of domain knowledge in the

representation

Matti Sadeh

Roi Gelbard

Dov Te’eni

Myth and Reality of OOA2

informatics

Computer Science IS

ACM – IEEE MIS Quarterly

ISR

Management Science

)HCI )International Journal of Human computer studies


1. Facts about practice of OOA

• Object-Orientation is the most widely discussed Systems Development approach.

• Books, Researches, Papers, Interest groups…• What happens in practice?

2. Speculation

In practice, no inclusion of relevant theories


The OO Promise

Many see the OO approach as a panacea to software problems:

“It is a major premise of this book that the object-oriented approach to systems development helps to avoid many of the problems and pitfalls described in earlier chapters" [of the structured or functional analysis]

)Bennett, McRobb and Farmer, 2002)

However, little empirical evidence exist to support such premise, and most of them are lab results.


The Current Research

• The current research tests empirically the application of the OO approach, with special emphasis on analysis.


The promise of OOA

The OO approach holds the promise to cope with the traditional waterfall life cycle pitfalls:

• Real world projects don’t follow a simple sequential life-cycle.• Inadequacies in the requirements analysis will arise in the late

stages of the project • A long time may elapse between the initial system requirements

stage and final installation.• The traditional life-cycle tends to be unresponsive to changes in

client requirements or technology.• The transition between stages is not smooth - in OO smooth.• OO designs are more suited to real world problems• The OO software will be easier to understand• Better support for software reuse


OOA Principles

Since the late ’80 many OO methodologies where suggested, but one can treat the work of the OMG )2001) as a conclusive work.

The essentials of OO are:• Seeing the system as a collection of object that interact.• Classification of the objects into classes• Generalizations of classes to super-classes• Inheritance• Encapsulation• Polymorphism• Use of visual language )diagrams)• Continuance evolving approach

to system life-cycle


Sample characteristics

Company TypeTotal

Defense Industry2

Governmental2

Hitech11

Services1

Software House4

start-up4

Main focusSystem TypeTotal

R/TCommunication and Multimedia2

Embedded3

Operating System and Communication1

Security and communication5

CombinedCommand and Control3

UIInformation System8

Internet Commerce Site2

Project Size )MY)Total

Up to One year6

Up to 35

Up to 109

Up to 501

Above 503

# of professionalsTotal

Up to 39

Up to 1012

More than 503

DevelopTotal

Product12

One-Time-System12


Research method - Interviews

• Diversity between projects suggested interviews best.– Project differ by: LC models, language, deliverables and more.

• To manage risks )researcher bias, social desire) of such research few steps where adopted:– Structured interviews – skeletons, questions phrased up-front– Assuring the interviewees confidentiality– Gradual questions from ‘what’ through ‘How’ to ‘Why’ –

postponing judgment questions to the end– Clear translation map from interview to quantitative measures


The generic life-cycle

Customer Requirements

Software Requirements

Software Analysis

Software Design

Although much is discussed about the iterative LC and its benefits the practice follows a more structured LC

RFP, SOW, MRD, or other.

Might be divided into Sys. Req and SRS

May be divided HLD & LLD


Findings – Activities in stages

Customer Req.

Software Req.

AnalysisDesignCode

User Requirements

Technical description of requirements

UC descriptions

UI

S/W Architecture

API between components

Classes )structure and operation)

Class collaboration

Conceptual DB schema

Classes )structure and methods)

Logical and physical DB structure

Analysis and design activities are pushed down the LC


Findings – Requirements specification

• Requirements state the functionality needed from the system )not the objects that it will handle)

• Requirements are broken-down by their functionality.


Findings – Analysis• In small projects and in some cases of information

system development - might be neglected, jumping straight to implementation )overhead?)

• In most cases – functions allocated to components.• Most times – not yet dealing with objects • When classes identified, almost never use the OO power

of inheritance.• Declair interfaces within the system )between

components) and with external systems.• Most times – UI design )specifically)


Findings – Design

• Hardly ever full specification of system – the gap between the specification and the S/W system relate to – the complexity of the system, – knowledge and experience of the programmer, – usage of CASE tools– customer demands

• Not all the classes are designed or even identified• Complex methods tend to be more specified

Might suggest cost-effectiveness of design not fully proven.


Findings – Design

• In most cases the design model is not kept updated.– implies about the usefulness of the model for maintenance


Findings - Graphical Language

DiagramUsageNotes

UCVery fewDoesn’t express much

ActivityVery often

ClassFrequentSometimes drawn as Entities-Relations

SequenceVery oftenIn many cases present interaction between large components of the system – not in classes resolutions.

State-chartVery few

PackageSometimesSometimes will look like block diagram

CollaborationVery few

InstanceNever observed


Findings - Graphical Language

• The graphical language is not fully adopted• Usually, text complements diagrams• Nevertheless, diagrams deliver quickly the overall picture

• Two exceptions: – one very large project – design is completely graphical. Text is not

feasible in such huge system.

– Another, medium-scale project – completely textual descriptions of process )diagrams are overhead)


Story II )a little speculative):

we do not in practice, include theory


)Systems modeling, 2000)


Type of information – theory implications?


A cognitive-affective model of organizational communication:

theory informs design

MIS Quarterly, 2001

An example of theory


Design Principles of Communication support systems

)forthcoming Communications ACM)

• Principle 1: Design must simultaneously consider enhancing mutual understanding and promoting relationships between communicators

• Principle 2: Design should support adaptive behavior, including the contingent use of alternative communication strategies, alternative message forms and alternative media.

• Principle 3: Design should control complexity.•


• Principle 4: Design should support multiple levels of communication and easy travel between levels.

• Principle 5: Memory should consist of speech act components, situations, norms and values.

• Principle 6: Memory should consist of associative information, accessible through multiple media, and represented in multiple forms, allowing for indeterminate and emergent views too

Design Principles of Communication support systems )Cont.)


Original message

IEEE Trans. Intelligent systems 2000 w Schwartz


Contextualized message

myth and reality of ooa: the lack of domain knowledge in the representation

Documents

reality of ooa1

oo smooth

oo designs

oo methodologies

essentials of oo

lc myth

objectoriented approach

traditional lifecycle