UMLChina Seminar ????????

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 Is Everywhere
7
Modeling Is Everywhere
int countLetters(ListltListltStringgtgt doc) int
count 0 for (IteratorltListltStringgtgti
doc.iterator() i.hasNext())
ListltStringgtline i.next() for
(IteratorltStringgtj line.iterator()
j.hasNext()) String word j.next()
count word.length() return
count
int countLetters(ListltListltStringgtgt doc) int
cont 0 for (ListltStringgtgt line doc)
for (String word line) count
word.length()
8
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
12
(No Transcript)
13
(No Transcript)
14
(No Transcript)
15
(No Transcript)
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 gt 1 Avoid
Generalization Between Use Cases Avoid
Unassociated Actors Avoid ltltusesgtgt, ltltincludesgtgt,
and ltltextendsgtgt 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.

Association classes and n-ary associations 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.

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.

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!
33
(No Transcript)
34
(No Transcript)