1

How Ricoh Has Been Trying to Adopt MDD Internally .

Atsushi KITAZAKI

Ricoh Company,LTD.

22

KITA-ZAKI Atsushi 　embedded system engineer since 1976encountered SMM in 1995developed 3 prototypes by SMM and 2 products by xUML as engineering manager since 1996

translated chapters 3 and 4 of Executable UML book into Japanese

work for Ricoh since June 2003engineering manager in software engineering department

33

ContentsBackground and past activities

OO development history in RicohRecent activities

Quantitative evaluation for choosing MDD tool Actual productivity evaluation of MDDBe Involved in software related NPOs

Current activityBuilding win-win situation

Conclusion

How Ricoh has been trying to adopt MDD internally .

44

Background and past activitiesRICOHOffice automation equipments trendsLarge-scale reuseHistoryWhat we learned

55

RICOH www.ricoh.comis a leading global manufacturer of office automation equipment.

major productsCopiersPrinting machinesFacsimile machinesMFP ｓ（ Multi Function Printers ）

66

Office automation equipment trends

difficult to control by code based development.started model based object oriented development in 1996.

targeted at large-scale reuse

Analog

ColorMonochrome

Digital

Multi-functionSingle-function

Software dependent

Difficult Control

Increase software size and complexity

77

Large-scale reuseThe differential development makes

a framework component.

Model frameHot spotsFramework component

Variable part

Differential

88

History1996 2001 2002

Trying to adopt MDD again

2003

Model based OO development(the differential development)

Rose was chosen as the major tool.

OO development training for newly hired employees

Modeling technique was learned from SMM at the beginning.

Bridge Point was one of the proposed tools.

Bridge Point was not chosen as the major tool.

but, still automatic code generation was promising.

developed a part of printer engine controller by Bridge Point with a consultant.

MDD was not adopted. OMG began

advocating MDA.

2000 2004

Then,proposed MDD to a production side.

99

What we learned from past activitiesWhy was not Bridge Point chosen?

did not match the differential development.partially adopted SMM modeling technique.

Why was not MDD adopted?anxiety for new technology big difference between BP model and a framework-model. difficult to understand implementation from a model.

accept SMM completelyevaluate tools quantitatively

prove worth adoptingpresent consistent samplesestablish implementation technique internally

1010

Recent activitiesQuantitative evaluation for choosing MDD tool

Code size comparisonMemory size comparison

Actual productivity evaluation of MDDCode size comparisonMemory size comparison

Be Involved in software related NPOs

1111

Quantitative evaluation for choosing MDD tool

replaced a few RTOS tasks of a legacy system by Bridge Point or Rose Real Time.

built implementation environment.customized BP MC-3020customized RRT service library

BP generated

high-efficiency codes.Chose better MDD tool

Bridge Point

1212

Code size comparison

Size of hand coded [LOC]

Quantitative evaluation for choosing MDD tool

C

Action

C++C

C

Legacy Bridge Point RRT[LOC]

2,000

4,000

6,000

8,000

Legacy Bridge Point RRT

Automated 11,929LOC 26,354LOC

Hand coded 8,113LOC

4,150LOC(C:2,780 and Action:1,37

0)

5,610LOC(C:1,857 and C++:3,75

3)

Whole 8,113LOC 14,709LOC 28,211LOC

1313

Memory size comparisonQuantitative evaluation for choosing MDD tool

ROM ROM

ROMRAM RAM

RAM

Legacy Bridge Point RRT

100,000

200,000

300,000

byte

(dynamic)(static)

Legacy Bridge Point RRT

ROM 57,232byte 62,071byte 214,289byte

RAM(static) 1,176byte 12,676byte 1,934byte

RAM(dynamic) approx. 45,000byte

1414

Actual productivity evaluation of MDDdeveloped same product software in parallel.

Production sidedomain and OO expert developed by Rose.

MDD sideMDD expert (not domain expert) developed by BP.

measured work time required for specification changes.

30% reduction with MDDproved high-productivity of MDD.

They admitted the results, but not accepted to adopt MDD immediately.

1515

Code size comparisonActual productivity evaluation of MDD

AutomatedC++

Hand coded

C++ Action2,000

4,000

6,000

8,000

10,000

Rose Bridge Point

AutomatedC

[LOC]

Hand codedC

Rose Bridge PointAutomated 4,330LOC 9,449LOCHand coded

4,572LOC2,067LOC

　 (C:472 and Action:1,595)Whole 8,902LOC 9,921LOC

1616

Memory size comparisonActual productivity evaluation of MDD

Rose Bridge Point

ROM 40,930byte 26,335byte

RAM(instance area excluded) 1,235byte 906byte

ROM

RAM

10,000

20,000

30,000

byte

Rose Bridge Point

40,000RAM

ROM

1717

Be involved in software related NPOsMany NPOs are very active in Japan now.

provided them with executable model samples.for good reputation of our MDD from outside.

Toppers(www.toppers.jp)Toyohashi OPen Platform for Embedded Real-time Systemswww.toppers.jp/docs/education/BridgePointSozeX002.pdf

ShiShi-Odoshi modelSessame(www.sessame.jp)

Society of Embedded Software Skill Acquisition for Managers and Engineersee.bof.jp/vm/Shared%20Documents/modeling/040217/index.htm

Vending machine modelUMTP (www.umtp-japan.org)

UML based Modeling Technologies PromotionElevator model (not released on web)

1818

What we learned from recent activities

Why did not production side accepted immediately?They satisfy the existing method.They have no immediate trouble to resolve.

Have we got good reputation of our MDD? Yes, but only outside

find someone who really want help.

advertise our MDD internally.

1919

Current activityBuilding win-win situation

2020

Building win-win situationsatisfy needs from a production side first.

provide them with what they need.Then they accept to adopt MDD.Finally both sides are happy.

found someone who want help. A production side needs compact printer

middle-ware, but no sufficient resources for development.

developing that middle-ware now. also developing that application domain by

Bridge Point.

2121

ConclusionAdoption of new technology is very

challenging!!xUML with BP makes higher productivity.BP is better MDD tool for high-efficiency

code generation.We need a much better MDD tool.

reasonable price, user friendly, perfect interoperability,etc

I hope Bridge Point will be the best MDD tool.

22

Thank you for listening!

How Ricoh Has Been Trying to Adopt MDD Internally .Atsushi KITAZAKI

Ricoh Company,LTD.