How Ricoh Has Been Trying to Adopt MDD Internally .

1. How Ricoh Has Been Trying to Adopt MDD Internally. Atsushi　KITAZAKI Ricoh　Company,LTD.

2. embedded system engineer since 1976 encountered SMM in 1995 developed 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 2003 engineering manager in software engineering department KITA-ZAKI Atsushi

3. Background and past activities OO development history in Ricoh Recent activities Quantitative evaluation for choosing MDD tool Actual productivity evaluation of MDD Be Involved in software related NPOs Current activity Building win-win situation Conclusion How Ricoh has been trying to adopt MDD internally . Contents

4. Background and past activities • RICOH • Office automation equipments trends • Large-scale reuse • History • What we learned

5. RICOH www.ricoh.com • is a leading global manufacturer of office automation equipment. • major products • Copiers • Printing machines • Facsimile machines • MFPｓ（Multi Function Printers）

6. difficult to control by code based development. started model based object oriented development in 1996. targeted at large-scale reuse Office automation equipment trends Analog Digital Software dependent Monochrome Color Difficult Control Single-function Multi-function Increase software size and complexity

7. Model frame Hot spots Variable part Differential Large-scale reuse • The differential development makes a framework component. Framework component

8. History 2000 2001 2002 2003 2004 1996 Model based OO development(the differential development) Rose was chosenas the major tool. OO development training for newly hired employees Modeling technique was learned from SMM at the beginning. developed a part of printer engine controller by Bridge Point with a consultant. Bridge Point was one of the proposed tools. Then,proposed MDD to a production side. Trying to adopt MDD again but, stillautomatic code generation was promising. MDD was not adopted. Bridge Point was not chosen as the major tool. OMG began advocating MDA.

9. Why 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. What we learned from past activities • accept SMM completely • evaluate tools quantitatively • prove worth adopting • present consistent samples • establish implementation technique internally

10. Recent activities • Quantitative evaluation for choosing MDD tool • Code size comparison • Memory size comparison • Actual productivity evaluation of MDD • Code size comparison • Memory size comparison • Be Involved in software related NPOs

11. 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-3020 • customized RRT service library • BP generated high-efficiency codes. • Chose better MDD tool • Bridge Point

12. Size of hand coded [LOC] Quantitative evaluation for choosing MDD tool Code size comparison 8,000 6,000 C 4,000 C C 2,000 C++ Action [LOC] Legacy Bridge Point RRT

13. byte 300,000 RAM 200,000 ROM 100,000 RAM ROM RAM ROM Bridge Point RRT Legacy Memory size comparison Quantitative evaluation for choosing MDD tool (dynamic) (static)

14. Actual productivity evaluation of MDD • developed same product software in parallel. • Production side • domain and OO expert developed by Rose. • MDD side • MDD expert (not domain expert) developed by BP. • measured work time required for specification changes. • 30% reduction with MDD • proved high-productivity of MDD. • They admitted the results, but not accepted to adopt MDD immediately.

15. Code size comparison Actual productivity evaluation of MDD 10,000 Automated C++ 8,000 Automated C 6,000 Hand coded C++ 4,000 Hand coded C 2,000 Action [LOC] Bridge Point Rose

16. Memory size comparison Actual productivity evaluation of MDD byte RAM 40,000 ROM 30,000 RAM ROM 20,000 10,000 Bridge Point Rose

17. Be involved in software related NPOs • Many 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 Systems • www.toppers.jp/docs/education/BridgePointSozeX002.pdf • ShiShi-Odoshi model • Sessame(www.sessame.jp) • Society of Embedded Software Skill Acquisition for Managers and Engineers • ee.bof.jp/vm/Shared%20Documents/modeling/040217/index.htm • Vending machine model • UMTP(www.umtp-japan.org) • UML based Modeling Technologies Promotion • Elevator model (not released on web)

18. 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 What we learned from recent activities • find someone who really want help. • advertise our MDD internally.

19. Current activity • Building win-win situation

20. satisfy needs from a production side first. provide them with what they need. Then they accept to adopt MDD. Finally both sides are happy. Building win-win situation • 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.

21. Conclusion • Adoption 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.