Delphi Modeling Guide: Object-Oriented Development and Trends

1. UMLChina Seminar面向对象实践之路 Gordon Li

2. Agenda • Introduction • The background rationale • The current situation • Development Trends • Summary

3. The Background Rationale Still need to be addressed! Books Category Solution OOA/OOD/MDA/DDA DELPHI源代码分析 DELPHI深度歷險 面向对象 实践之路 Delphi Developer Guide Vertical ADO/COM+ SOAP/Web Service Mastering Delphi 電子商務篇 dbExpress 分散式系統篇 Delphi使用手冊 Horizontal

4. The Background Rationale Books Category Solution OOA/OOD/MDA/DDA DELPHI源代码分析 MDA/DDA OO With Web Programming DELPHI深度歷險 面向对象 实践之路 Delphi Developer Guide Vertical ADO/COM+ SOAP/Web Service Mastering Delphi 電子商務篇 dbExpress 分散式系統篇 Delphi使用手冊 Horizontal

5. 為什麼需要Modeling 其實我們一直在做Modeling! Modeling Cycle Modeling Process Modeling Development Modeling Code

6. Modeling Database Schema Transformation(By 3rd-Normal Form) Modeling Is Everywhere

7. Modeling Your Code! Transformation(By Refactoring) Modeling Is Everywhere int countLetters(List<List<String>> doc) { int count = 0; for (Iterator<List<String>>i = doc.iterator(); i.hasNext();) { List<String>line = i.next(); for (Iterator<String>j = line.iterator(); j.hasNext();) { String word = j.next(); count += word.length(); } } return count; } int countLetters(List<List<String>> doc) { int cont = 0; for (List<String>> line : doc) { for (String word : line) { count += word.length(); } } }

8. Modeling Your Code! Transformation(QVT) Modeling Is Everywhere

9. Development Trends! Audits/Metrics Applied In Industry Combing with Tools OOA/OOD/UML Concepts, Symbols I started here back to 1992

10. Development Trends! 4 – Implementation Model 3 – Conceptual Model 2 – Requirement Model Applying UML And Patterns Object-Oriented Software Engineering 1 – Business Model

11. Agenda

16. Sample Audits • Avoid Aggregation, Favor Composition • Avoid Dangling Model Elements • Always Indicate Multiplicity • Always Indicate Navigability • Avoid Multiplicities Involving Max and Mins • Avoid * Multiplicity • Always Name Associations • Avoid Using Dependencies • Do not Overlap Guards • Do not Use Disjoint Guards • Identifier Conflicts with Keyword • Indicate Role Name on Association Ends • Indicate Role Names on Recursive Associations • Lines Should Not Cross • Naming Conventions • Never Place Guard on Initial Transition • Provide Comment for OCL Constraints • Use Plural Names on Association Ends with Multiplicity > 1 • Avoid Generalization Between Use Cases • Avoid Unassociated Actors • Avoid <<uses>>, <<includes>>, and <<extends>> • Avoid Weak Verbs at Beginning of Use Case • Avoid Association Classes • Abstract Class Declaration • Avoid Cyclic Dependencies Between Packages • Avoid N-ary Associations • Avoid Qualifiers • Always Specify Type on Attributes and Parameters • Class Should be Interface

17. Sample Audits • Conflict With System Class • Do not Model Elements of Implemented Interfaces • Do not Model Scaffolding Code • Do not Name Associations that have Association Classes • Hiding Inherited Attribute • Hiding Inherited Static Method • List Static Operations/Attributes Before Instance Operations/Attributes • Overriding Non-abstract Method with Abstract Method • Subclasses have the Same Member • Use Singular Names for Classes • Avoid Modeling Destruction • Avoid Modeling Return Arrows • Avoid “Black Hole” States • Avoid “Miracle” States • Avoid Recursive Transitions With no Entry or Exit Actions • Avoid “Black Hole” Activites • Avoid “Miracle” Activities • All Transitions Existing a Decision Must Have Guards • Forks Should Have Only One Entry Transition • Joins Should Have Only One Exit Transition • Components Should only Depend on Interfaces

18. A Class Diagram Audits • Avoid Association Classes (AAC) • Association Classes can be decomposed into a separate class that associates two others. These may confuse generators, or be decomposed anyway. Association classes and n-ary associations should be avoided

19. A Sequence Diagram Audits • Avoid Modeling Return Arrows (AMRA) • To reduce clutter on diagrams, the explicit modeling of return arrows is discouraged. Return arrows tend to clutter sequence diagrams

20. A State Diagram Audits • Avoid “Black Hole” States (ABHS) • Only End states should have an incoming transition with no outgoing transition. Only end states should have no outgoing transition

21. Familiar

22. MetaModels of Languages not so familiar

23. Model Transformation

24. Model TransformationCurrently available in Borland Together • MDA Term: Model Transformation • Deployment diagrams • From Platform Independent Model to AppServer Specific model • ER Diagramming • From Logical ER Diagram (PIM) to Physical Diagram (PSM) • Design Language • From Design Language (PIM) to Source code specific model (PSM) • Support for Patterns • Applying, changing, and creation of… • Tool interoperability • Common File and Diagram format

25. Model transformation TodayDeployment model Deployment Model Select target Platform Platform Specific Deployment

26. Model transformation TodayDesign Language Platform Independent Model Select Target Platform C++ Specific Model

27. Model transformation TodayER Diagrams Database Independent ER Diagram Select Deployment Platform Oracle Specific Diagram

28. Model TransformationFuture extensions to Borland Together • Java based Transformation • OpenTool integration • Pattern based transformation • Predefined ‘Java based transformation’ • XSLT based transformation • On design language files Borland Confidential

29. Java Based Transformation • Provides a hook into the transformation process • The transformation process can manually be manipulated • Query element properties • Apply a framework or pattern to the element at hand • Transformed model will be stored in target location • Requires deep technical knowledge/integration • Potentially well suited for Java developers • Target audience: ISVs that want to provide very specialized transformations

30. Pattern based transformation • A predefined Java based transformation • Discovers Model • Applies Patterns based upon stereo types of classes • Pattern parameters are obtained from the class properties • Such as class name, attributes, etc. • Transformed model will be stored in target location • Requires enough knowledge to add/change patterns • Target audience: System Integrators and advanced IT shops

31. XSLT based transformation • Design only diagrams • Input: Diagram in format XML or XMI file • Output: Language specific PSM • Pro: ‘Easiest’ form of integration • Pro: Open and flexible enough to run stand alone on server • Con: Transformation errors harder to detect • Target audience: ISVs that want to provide generic additional transformations

32. 謝謝大家Have A Good Day!