umlchina seminar 面向对象实践之路 gordon li. 2 agenda introduction the background...
TRANSCRIPT
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