UMLChina Seminar面向对象实践之路

Gordon Li

2

Agenda

Introduction The background rationale The current situation Development Trends Summary

3

The Background Rationale

DELPHI源代码分析

面向对象实践之路

SOAP/Web Service

Solution OOA/OOD/MDA/DDA

Horizontal

Ver

tica

l

Delphi 使用手冊

Books Category

Mastering Delphi

Delphi Developer Guide

電子商務篇

分散式系統篇

ADO/COM+

dbExpress

DELPHI深度歷險

Still need to be addressed!

4

The Background Rationale

DELPHI源代码分析

面向对象实践之路

SOAP/Web Service

Solution OOA/OOD/MDA/DDA

Horizontal

Ver

tica

l

Delphi 使用手冊

Books Category

Mastering Delphi

Delphi Developer Guide

電子商務篇

分散式系統篇

ADO/COM+

dbExpress

DELPHI深度歷險

MDA/DDA

OO With Web Programming

5

Modeling CodeModeling Code

Modeling Development

Modeling Development

Modeling Process

Modeling Process

Modeling Cycle

Modeling Cycle

其實我們一直在做 Modeling!

為什麼需要 Modeling 為什麼需要 Modeling

6

Modeling Is Everywhere

Modeling Database

Schema

Transformation(By 3rd-Normal Form)

7

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(); } }}

Modeling Your Code!

Transformation(By Refactoring)

8

Modeling Is Everywhere

Modeling Your Code!

Transformation(QVT)

9

Development Trends!

OOA/OOD/UMLOOA/OOD/UMLConcepts, SymbolsConcepts, Symbols

OOA/OOD/UMLOOA/OOD/UMLConcepts, SymbolsConcepts, Symbols

Combing with ToolsCombing with ToolsCombing with ToolsCombing with Tools

Applied In IndustryApplied In IndustryApplied In IndustryApplied In Industry

Audits/MetricsAudits/MetricsAudits/MetricsAudits/Metrics

I started here back to 1992

10

Development Trends!

1 – Business Model1 – Business Model1 – Business Model1 – Business Model

2 – Requirement Model2 – Requirement Model2 – Requirement Model2 – Requirement Model

3 – Conceptual Model3 – Conceptual Model3 – Conceptual Model3 – Conceptual Model

4 – Implementation Model4 – Implementation Model4 – Implementation Model4 – Implementation Model

Applying UML And Patterns

Object-Oriented Software Engineering

11

Agenda

12

13

14

15

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

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.

A

Association classes and n-aryassociations should be avoided

19

Sequence Diagram Audits

Avoid Modeling Return Arrows (AMRA)To reduce clutter on diagrams, the explicit modeling of return arrows is

discouraged.

A

Return arrows tend to clutter sequence diagrams

20

State Diagram Audits

Avoid “Black Hole” States (ABHS)Only End states should have an incoming transition with no outgoing

transition.

A

Only end states should have no outgoing transition

21

Familiar

HumanAdult

Man Boy GirlWoman

HumanChild

[1]Mother

<<depends on>>

22

Classifier Generalization

[1]

specific

[1]

parent

[0..*]DirectedRelationshipClass{general=self.parents()}{not self.allParents()->includes(self)}

MetaModels of Languages not so familiar

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 ModelSelect 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 DiagramSelect 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

謝謝大家

Have A Good Day!

33

34