From Design to Implementation in OpenEdge using UML and MDA

1
From Design to Implementation in OpenEdge using
UML and MDA
Frank Beusenberg
Sr. Technical Consultant
2
Theory vs Practice
Be pragmatic!
The difference between theory and practice is
that, in theory, there is no difference between
theory and practice!
3
Shu Ha - Ri
Learning Curve
Shu - Learn Ha - Understand Apply Ri - Create
4
Agenda

• Introduction
• UML 2.0 Diagrams
• MDA Introduction
• Guidelines
• QA

5
Introduction
What is UML? Some facts

• UML Unified Modeling Language
• First UML spec in 1997
• Current version 2.0
• Object Management Group (OMG)
• Graphical language
• Object Oriented in nature
• Has Syntax
• Extensible
• NOT a methodology!

6
Introduction
What is UML? Evolution
7
Introduction
Why model?

• Manage Complexity
• Mitigate Risk
• Facilitate Communication
• Modeling provides ability to visualize entire
  systems, assess options and designs
• Software has grown from do-it-yourself into
  highly complex systems
• Software is integral part of business process, so
  has to be well planned
• Software has become capital equipment that cannot
  just be removed/changed

8
Introduction
The Software Development Life Cycle
Test
Deploy
Planning
Analysis
Design
Build
COMPRESS
Deploy
Planning
Test
Analysis
Design
Build
9
Introduction
Why UML?

• Specify, visualize, and document models of
  software systems
• Current and New Systems
• Structure and Design
• Behavior and Interaction
• De Facto Standard (Tool Support!)
• Unambiguous and Consistent Notation
• Documentation

10
Agenda

• Introduction
• UML 2.0 Diagrams
• MDA Introduction
• Guidelines
• QA

11
UML 2.0 Diagrams
Commonly used
12
Behavior Use Case Diagram
Describe Functional Requirements
13
Behavior Activity Diagram
Describe (Business) Process Workflow
14
Behavior Sequence Diagram
Describe Chronological Message Flow between
Objects
15
Behavior Communication Diagram
Describe Chronological Message Flow between
Objects
16
Structure Class Diagram
Describe Logical Structure of the System
17
Structure Component Diagram
Describe Physical Structure of the System
18
Structure Deployment Diagram
Describe How and Where the System will be deployed
19
Agenda

• Introduction
• UML 2.0 Diagrams
• MDA Introduction
• Guidelines
• QA

20
UML Modeling
Logical View
Implementation View
Use Case View
Dynamic View
Deployment View
21
Model-Driven Architecture (MDA)
CIM gtgt PIM
PIM gtgt PSM
PSM gtgt Code
22
Model-Driven Architecture (MDA)
Objective and Purpose

• Decouple the way that application systems are
  defined from the technology they run on.
• This is in order to ensure that the investments
  made in building systems can be preserved even
  when the underlying technology platforms change.

23
Agenda

• Introduction
• UML 2.0 Diagrams
• MDA Introduction
• Guidelines
• QA

24
Guidelines
Natural Order

• Create Use Case Diagram(s)
• Create Activity Diagram(s)
• Create Class Diagram(s)
• Create Sequence Diagram(s)
• Create Component Diagram(s)
• Create Deployement Diagram(s)

25
Guideline - Use Case View
Describe System Functionality

• Gathering requirements
• Functional non-functional requirements
• Document functional requirements
• UML Use Case Diagram
• Use Case Description Documents
• Identify actor(s) and association to use case
• Create different levels of use cases (re-use!)

26
Example - AutoEdge
Use different abstraction levels when appropriate
27
Example - AutoEdge
Manage Dealer
28
Guideline - Use Case View
Describe Use Case Scenarios

• Scenario Use Case Activity Flow
• Basic Scenario
• Alternate Scenario(s)
• UML Activity Diagram
• Describe what happens, not how!

29
Example - AutoEdge
Manage Dealer
30
Guideline - Use Case View
Describe Test Scenarios

• Identify paths in activity diagram
• Create minimal test-scenarios (using each path
  once)
• NOTE Test should test use case, not fooling
  around in the system!

31
Guideline Logical View
Describe and design the System Structure

• Identify entities/things used in use case
• Identify attributes
• Identify operations
• Identify entity relations
• Identify multiplicity
• Create class diagram

32
Example - AutoEdge
Logical Data Model Process Testdrive Requests
33
Example - AutoEdge
Dealership Business Entity
34
Guideline Logical View
Identify and use Patterns
A pattern is a proven solution for a problem in
a context.
35
Example AutoEdge
Client-Side Business Entity Pattern
36
Guideline Dynamic View
Describe Behavior

• Identify objects involved
• Identify interactions (messages)
• Only show public operations
• Describe how things work (together)
• Identify missing classes and/or operations
• Ty back into class diagram

37
Example - AutoEdge
Entity Creation within AutoEdge Architecture
38
Guideline Implementation View
Describe Physical Software Artifacts

• Identify Physical Software Artifacts
• Source Compiled files
• Identify Packages Libraries

39
Example - AutoEdge
Dealer Business Entity
40
Guideline Deployment View
Describe Software on Physical Hardware

• Identify Location of Software Artifacts
• Identify how Hardware is related
• Identify (minimum) hardware requirements

41
Guideline Deployment View
Describe Software on Physical Hardware
42
In Summary

• Model Design
• Manage complexity
• Minimize risk
• Facilitate communication
• Use UML
• De facto standard
• Unambiguous
• Documentation

43
Literature
Addison-Wesley Object Technology Series

• UML Distilled Third Edition
• Martin Fowler ISBN 0-321-19368-7
• Use Case Driven Object Modeling with UML
• Doug Rosenberg ISBN 0-201-43289-7
• Developing Software with UML
• Bernd Oestereich ISBN 0-201-75603-X

44
Materials
Materials available on PSDN

• Complete AutoEdge Kit
• www.psdn.com/library/kbcategory.jspa?categoryID29
  8
• Modeling Model Driven Architecture
• www.psdn.com/library/kbcategory.jspa?categoryID24
  7

45
Resources
Training Information

• Check with local subsidiary for UML training
• UML Resource Page
• www.uml.org
• MDA Resource Page
• www.omg.org/mda

46
Questions?
47
Thank you foryour time
48
(No Transcript)