object-oriented technology and software reuse

1 Copyright© 1999 by Dr. NamYong Lee

Object-Oriented Technology

and Software Reuse

Object-Oriented Technology

and Software Reuse

1-1, Sangdo-dong, Dongjak-gu, Seoul, KoreaPhone:(02)820-0671 Handphone:011-362-5656

Dr. Nam-Yong Lee

[email protected]


Information Technologies

DISTRIBUTION

Office Equipment

Info VendorsTELECOM

GUI & OS/ COMPUTER

CONSUMER ELECTRONICS

MEDIA &

PUBLISHING

NationalInformationSuper Highway

Medium--Transport--Translate--Transform--Present--Message/Content

E.mail, FAX,LAN, WANPhone, Cellular, E-Conference2-Way TV

Videogame, CD & VideodiscFilm, TV, Video, Records &Cassettes

Interactive News,,Newspapers,NewslettersMagazines & JournalsBooks

Copier, PrintersScanners

PC, Engineering WorkstationsSuper-mini, Mainframe


Performance constraints

Time-to-market pressures

Certification requirements

Distributed, real-time requirements

Size & geographic distribution of the engineering team

Reliability and fault-tolerance requirements

Rate of requirements and technology change

The interplay of these factors

Complex software costs

Diseconomy of scale

What Makes Systems Complex?

size/scale

Softwarecost

Software Costs = E * (Size)P


Current Software Technology Thrusts

Software Costs = E * (Size)P

EEnvironment technologiesand tools

Integrated tools (compiler-editor-debugger-CM) Open systems Hardware platform performance Automation

Documentation, testing, quality analyses

Size(Source code)Megaprogrammingtechnologies

Reuse, Commercial-off-the-shelf (COTS) products Object-oriented (analysis/design/programming) Higher level languages (Ada, C++, etc) CASE tools (automatic code generation) Distributed Middleware

PProcess technologies andteamwork

Iterative development Process maturity models Architecture-first development Acquisition reform Training and personnel skill development


Software Maintenance Cost

Total Life Cycle Cost

– Development cost: 30 %

• Design Cost: 40%

• Code: 20 %

• Integration/Testing: 40 %

– Maintenance Cost: 70 %

How to reduce Maintenance Cost ?

Development Cost: 100 %

Design Cost: 40 %

Code: 20 % Integration/Testing: 40 %

Maintenance Cost: 300 %


Establishing a Project’s Focus Every successful project must have a set of primary characteri

stics against which business decisions can be made

Time-to-market Scaleability

Completeness Exensibility

Performance Portability

Quality Architectural reusability

Fault tolerance

All of a project’s characteristics cannot be optimized at once

We can never have a completely rational development process


Every Software Project Has a Particular Focus Calendar-driven

Requirements-driven

Documentation-driven

Quality-driven

Architecture-driven


Requirements-Driven Systems

System function

CommonInfrastructure


Architecture-Driven Systems

System function

CommonInfrastructure

Domain-specific framework

Domain model

Distributed object management

Persistent object store

GUI/decktop environment

Application environment

Domain-independant framework

Networking

Basic operating system


Mitigating Software Failure Success factors include

– Languages Ada95, C++, etc.

– Tools development environments, frameworks, application generators

– Methods Booch, OMT, OOSE, UML

– Processes SEI CMM, ISO 9000, Rational Unified Process

No one factor is sufficient

– It’s an issue of balance


Programming Languages

Smalltalk-74Smalltalk-74




ALGOL60

Simula 67

Pascal

C

Objective CAda83

Eiffel

Ada 95

C with Classes

C++ 1.XX

C++ 2.XX

C++ 3.XX

C++ 4.XX

LOOPs

CommonLoops

CLOS

New Flavors

Common Lisp

Flavors

Lisp

Smalltalk-72

Cluster

1960

1970

1980

1990

ProceduralLanguage

Object-OrientedLanguage

Object-BasedLanguage


Tools Development environments

– Apex

Frameworks

– Ship System 2000

– Taligent

– UNAS

– fin++

Application Generators

– Powerbuilder

– Visual Basic, etc.


Methods

Unified Modeling Language

BoochProcess maturity-- SEI CMM-- ISO 9000

Metrics and QA

Patterns

Formalism

Other methods-- CRC cards-- Responsibilty-driven design-- OBA-- Harel

OMT

Objectory


Evolution of the UML

Industrialization

Standardization

Unification

Fragmentation

Booch ´91

Booch ´93

Unified Method 0.8

UML 1.0

OMT - 2

OMT - 1 OOSE

UML 0.9 & 0.91

OOPSLA ´95

June ´96 & Oct ´96

Submission to OMGfor adoption, July ´97

Other methods

publicfeedback

Publication of1.0 Standard Dec ´96

UML PartnersExpertise

UML 1.1


Processes Be deliberate when considering process maturity

– Successful projects will tend to rate high on the SEI CMM

– A high rating on the SEI CMM does not infer success

ISO 9000 emphasizes quality and predictability

MIL-STD-498 emphasizes quality and reusability

ISO 12207 emphasizes processes

Consider acquisition processes as well

– Defense Science Board: Acquiring Defense Software Commercially


Levels of Process Maturity

?A successful organization will rate high in the CMM?A high rating is not necessarily a strong predictor of success

Initial

Applicable

Defined

Managed

Optimized

Performance- Cost- Schedule- Quality

SuccessfulProjects

.. ...

....

...

.


The Artifacts of a Software Project Architecture Design Code Requirements Data Human interface Estimates Project plans Test plans Documentation


Architectural Modeling

Logical View

Process View

Development View

Platform View

Scenarios


Other Issues Managing risk

Planning and scheduling

Costing and staffing

Monitoring, measuring, and testing

Documenting

Projects in crisis

Domain-specific considerations


The Development Team

Q & A

Documentation

Tech Support

Integration Application Engineers

Librarian

Analysis

End UsersProject Manager

Product Manager

Architect

System Administrator

Toolsmith

Patron

Analyst


General Object-Oriented Technology Trends The language wars are over

– C++

– Smalltalk

– Ada95 and others

The method wars are over

– Unified Modeling Language

There are a number of signs of growing maturity and acceptance

– Success in a variety of application domains


The Emergence of Patterns A pattern is a solution to a problem in a context

– A pattern also expresses its author’s intent

A pattern codifies specific knowledge collected from experience in a domain

– Patterns capture common design solutions

All well-structured systems are full of patterns

– Idioms

– Mechanisms

– Frameworks

Domain-specific patterns are emerging; patterns are being collected, cataloged, and used to build systems


Distributed Computing Most interesting applications are rarely single programs

running on isolated computers

Crafting distributed, concurrent systems is very hard

Issues include

– Distribution

– Migration

– Synchronization


Programming without Programming Componentware

– OLE and COM

– OpenDoc

– CORBA

Visual programming

– Visual Basic

– Visual C++

– JAVA(JDK)

– Powerbuilder, SQL/Windows, and ObjectPro

The emergence of domain-specific frameworks


Language Comparisons Function points are essentially language independent

SLOC are definitely language dependent

Language expressiveness as a function of:

– Unadjusted Function Points===> SLOC translation ratios

Language SLOC/UFP

Assembly 320 Source: Capers Jones

C 128

Fortran 77 105

COBOL 85 91

Ada71

C++29

Ada95 ??


Software Technology Language Level Support Software

Micro programming Bits: 100, 010 Machine languages F12, A07, 124, AAF

Low level programming Instructions: LDR, ADDX, Assemblers, linkers CLA, JMPS

High level language Lines: IF A then B Compilersprogramming loop Operating systems

I=I+1

Object based and Object- Objects & packages: Compilersoriented programming Type color is (red, yellow, green); Operating systems

package traffic_light Runtime libraries when green go;

Megaprogramming Components & Services Compilers Operating systems

- Reuse Overlay map with grid; Runtime libraries- Automatic coding When failure switchover; Networks- COTS components Shutdown all test processes; Middleware

CASE tools

Megaprogramming


Hardware Engineering Analogs to Megaprogramming

Cobol C Ada83 Ada95 Smalltalk Mega-programming

System

Rack

Card

LSI chip

SSI/MSI chip

Systems

Layers

Categories,Subsystems,Class Libraries

Classes,Objects,

Functions, Arguments, Return values, Strong typing

GateVariables,Expressions,Statements

C++


Technology State-of-the-Art Evolution

Custom - ad hoc

100% Custom

Ad hoc

Separate butoff-the-shelf

30% Megaprogrammed70% Custom

Repeatable

Off-the-Shelfand integrated

Managed & measured

Environment/Tools

Size

Process/Team

Conventional Software Engineering Target

ProjectPerformance over budget

over scheduleAlways

Predictable

Infrequently on budgeton schedule

Unpredictable PredictableCompetitive budget & schedule performance

70% Megaprogrammed30% Custom


60s 70s

Functional

Waterfall

Proprietary centralized

FORTRAN-COBOL

Functionality

Software Cost Evolution Software Engineering Modern Best Practices

ProjectCost

ConventionalDiseconomy of Scale

90s

Object-Oriented

Iterative development

Open distributed

Ada 95, C++

Adaptability

80s 90s

Declarative

2167

Proprietary distributed

C-Ada

Performance

Era

Design methods

Process

Architecture

Languages

Risk focus

Economy of scale

Functionality, scale and complexity

Software ROI


General Observations Software development is hard

– And demands keep increasing

You need all the help you can get

– Methods

– Patterns

– Languages

– Tools

– Shared experiences

Object-oriented technology is here to stay


Object-Oriented Technology Risk Evolution

Experience: 1986 vs 1994

TIMES HAVE CHANGED - OOT IS VERY MATURE

Early risk focus Today’s risk focus

Compiler maturity/performancePersonnel trainingEnvironment/tool existenceProcess definitionDevelopment costIntegration complexityRequirements freeze

Hardware resource adequacyPersonnel skillExtent of automationProcess improvementReuse costFormal test complexityArchitecture adaptability


SOFTWARE PRODUCTSIMPROVE SOFTWAREPRODUCTIVITY

PROCESS

HUMAN TOOLSPARTS ORCOMPONENTS

GET THE BESTFROM HUMAN

MAKE STEPSMORE EFFICIENT ELIMINATE

STEPSELIMINATEREWORK

BUILD SIMPLERPRODUCTS

REUSECOMPONENTS

SOFTWARE PRODUCTION FACTORS

SOFTWARE PRODUCTIVITY IMPROVEMENT FACTORS

Software Production


C h art T it le

ReliabilityAccuracy

Anom aly m anagem entSim plicity

UsabilityOperability

T raining

IntegrityAccess control

Access audit

Effic iencyEffective processing

Effective storage

Perform ance

VerifiabilityM odularity , Self-descriptiveness

Sim plicity , Docum entAccessibility and T est

M aintainabilityM odularity , Accessibility

Self-descriptiveness, ConsistencySim plicity and Docum ent

CorrectnessCom pletenessConsistencyT raceability

Design

ReusabilityS im plicity , Independence, Docum ent accessibility

G enerality , M odularity , System clarityApplication independence and S lef-descriptiveness

PortabilityIndependence

M odularitySelf-descriptiveness

FlexibilityM odularity and S im plicity

Self-descriptivenessG enerality

InteroperabilityM odularity and M om m onnality

IndependenceSystem com patibility

ExpandabilityExtensibility , M odularity

Self-descriptivenessSim plicity and G enarlity

Adaptation

Softw a re Q ua lity Metrics

Software Quality Metrics


SYSTEM

SEGMENTSEGMENT

CSCI HWCIIRS HWCI

IRS

CSC

CSCI HWCI

CSCI IRS HWCI HWCI HWCI HWCI

CSCCSC

CSC CSCCSCCSC CSCCSU CSU

CSU

CSU CSU

CSU CSU

CSC CSC

CSCCSC

CSU

CSU

CSU CSU CSU CSU

CSC CSC

CSUCSU

동일한 CSU 가 서로다른CSCs 에서 사용됨

기개발된 소프트웨어

Software Components


Empirical Studies on Software Reuse

0

10

20

30

40

50

60

70

80

90

AXE

HAR

TO

S

RAY

UO

C

JAP

GTE

NAS

REU

PRO

MAI

LEGEND– REU: Reusability

– PRO: Productivity

– MAI: Maintenability

GROSSORY– AXE: AXE developed by Erisson Teleco

m in Sweden(Oskarsson, 1983)

– HAR: Hartford(Cavaliere, 1983)

– TOS: Toshiba’s Software Factory(Matsumoto, 1984)

– RAY: Raytheon’s Missile Systems Division(Lanergan & Grasso, 1984)

– UOC: University of California at Irvine(Standish, 1984)

– JAP: Japanese Software Factory(Standish, 1984)

– GTE: GTE Data Services(McClure, 1992)

– NAS: NASA(Selby, 1987)


Three Rs

Reusability is an approach to software development that is based on

creating software systems from reusable components that are stored in automated libraries.

Re-engineering is the counterpart technology to CASE and the application of the

newest technologies and tools to software maintenance.

Repository is more than a CASE repository because it integrates CASE tools,

re-engineering tools, third-generation, fourth-generation, and fifth-generation tools.


Reusability

Reusability is a much broader concept than simple reusable code.

Possibilities of reusable components include: Abstract Higher-level software components such as design,

models, data, and project management information Higher levels of reusability offers greater promise

because they have greater potential to increase software productivity.

Repository provides the library mechanism and representation formalism needed for reusability.

The repository and re-engineering tools are the enabling tools for reusability.


Re-engineering

Re-engineering Technologies:– Program code analyzers and metrics

– Program logic restructuring

– Data restructuring

– Reverse engineering

– Configuration and change management

Re-engineering tools:– Program analyzers

– Metrics tools

– Restructuring tools

– Reverse engineering tools

– Translators and converters


Reverse Engineering

Reverse engineering is the process of deriving a conceptual or logical description of a software system’s contents and components from its physical level description with the aid of automated tools

Reverse Engineer

JCLSource codeDDLFile Description

Spec. LanguageData ModelsProcess ModelsInterrelationships

PHYSICAL LEVEL(IMPLEMENTATION-ORIENTED)

LOGICAL LEVEL(DESIGN-ORIENTED)

REVERSE ENGINEERING PROCESS


Process Reuse Framework

PLAN

CREATE

MANAGE

UTILIZE

Goals, Strategies, Tailed Processes,Resources

Needs, Lessons learned,Process Assets

Assets

Assets andDescriptions

LessonsNeeds

Lessons


Reuse Process

Adaptive Process to Support Reuse

Parameterized Process to Support Reuse

Engineered Process to Support Reuse


Adaptive Process to Support Reuse

EXISTINGSOFTWARE

ADAPTIVE ENGINEERING

MODIFIEDSYSTEM

NEWPLATFORM

Domain Artifact

New Artifact

Reused Software

Ported Software


Parameterized Process to Support Reuse

EXISTINGSOFTWARE

PARAMETERIZEDENGINEERING

STANDARDPRODUCTS

MODIFIEDSYSTEM

NEW APPLICATION

DOMAINARTIFACT

NEW ARTIFACT

DOMAINRESOURCES

FEEDBACK

PARAMETERIZEDSOFTWARE

REUSED SOFTWARE


Engineered Process to Support Reuse

EXISTINGSOFTWARE DOMIAIN

ENGINEERING

DOMAINANALYSIS

REUSEENGINEERING

NEWAPPLICATION

DOMAIN DATATechnology base Domain ExpertiseTheory

Dmain Artifact

Domain Knowledge

Domain Resources

Domain andSoftwareArchitectures

Feedback

Reuse-Based Software Practices

Reuse-Engineered Software


Domain Analysis Techniques

FODA(Feature-Oriented Domain Analysis) Jaworski Technique Prieto-Diaz technique Synthesis Technique


Concept Development Data Items

– Mission Need Statement

– Automation Economic Analysis

– System Decision Paper

– Project Manager Charter

– Acquisition Strategy and Plan

– Statement Of Work

– Work Breakdown Structure

– Independent Cost Estimation

– Product Management Plan

– Development and Implementation Plan

– Operational Concept Document

– Data Requirement Document

– System Segment Specification

Management Data Items

– System Engineering Management Plan

– Data Communication Network Master Plan

– Software Development Plan

– Software Configuration Management Plan

– Software Standards and Procedures Manual

– Software Quality Evaluation Plan

– Integration Test Plan

– System Security Plan

Engineering Data Items

– System/Segment Specification

– Software Requirement Specification

– Interface Requirement Specification

– Software Top Level Design Document

Selected and Reusable Data Items


Engineering Data Items

– System Allocation Document

– Software Detailed Design Document

– Interface Design Document

– Data-Base Design Document

– Software Product Specification

– Version Description Document

– Engineering Change Proposal

– Specification Change Notice

– Interface Control Document

– Others:• System/Design Trade-Off

Study Report• System/Equipment Failure &

Repair Study Report• Program Review Documents• Safety Evaluation Report

Test Data Items

– Hardware Test Plan

– Software Test Plan

– Software Test Description

– Software Test Procedures

– Software Test Reports

– System Integration Test Plan

– Vendor Acceptance Test Plan

– Software Quality Test Plan

– Software Acceptance Test Plan

– System Acceptance Test Plan

– Others



Operational & Support Data Items Computer Systems Operator’s Manual Software User’s Manual Computer System Diagnostic Manual Software Programmer’s Manual Firmware Support Manual Computer Resources Integrated Support Document Others



WindchillInformation

Modeler

Federation

Administrator

Windchill Foundation

Future Applications

Customer Applications

Life Cycle Management

Document Management

Workflow Management

View Management

Product Structure Management

Change Control

WindchillEnterpriseDocumentManager

WindchillEnterprise

ConfigurationManager

Windchill Product Families


Information Infrastructure

Cross Functional / Cross Service Integration

ENTERPRISE INTEGRATION

FunctionalApplications

Shared Services,Technologies & Data

TechnicalInfrastructure

Foundation

Tactical Integration

C2Applications

IntelligenceApplications

DMS EC/EDI

Base/ Tactical Applications

Mission Support Applications

FutureApplications

DII COE Shared Data

FututeServices

Base/ TacticalInfrastructure

Mega centers

DII Control Concept

DISN FutureInfrastructure

Modeling/ SystemSimulation

Technology Base Standards

Test andEvaluation

Information Warfare/Information Security

SoftwareEngineering Architecture DII Policy


Strategies for Software Development

Language

Method andProcess

Tools

X+1 Year X+2 Year X+3Year Approach X+3 Year

Structured Method US DoD-2167A, etc. BOOCH, OMT, etc.

MIL-STD-498, etc.

Tools for SA/SDTools for BOOCH, etc.

Unified Modeling LanguageISO 12207, Unified Process

Tools for supporting UML and CORBA/DCOM

Object-Oriented Language(Ada’95, C++, JAVA)

Solution