E183 Business and Object Modeling using PowerDesigner

1
E183Business and Object Modelingusing
PowerDesigner

• Bill Green
• VP Emerging Technologies
• Power3, LLC

2
Introduction

• Power3
• PowerStart Series
• Trainers

• Customized Enterprise Training
• Software Consulting
• Software Development
• Onsite or Offsite

3
Introduction

• Power3
• PowerStart Series
• Trainers

• Basic, Intermediate and Advanced course offerings
• PowerBuilder, PowerDesigner, EAServer tracks
• Onsite Training
• Online Training
• Online Mentoring

4
Introduction

• Power3
• PowerStart Series
• Trainers

5
Business and Object Modeling

• Well explore these aspects of systems
  development looking at what they are, why we
  should do them and how you can get them to work
  together
• Our demos are all based on PowerDesigner v9.5

6
What is Business Process Modeling?

• Business Process Modeling is the modeling of
  business functionality in a workflow form
• Shows the flow of processes and the responsible
  organizational unit
• Capture Business Rules
• Capture Create-Read-Update-Delete (CRUD) data

7
Example

• Swim lanes separate responsible entities
• Relationships between processes and Data create
  CRUD data
• Business Rules can be built and assigned to each
  process

8
What is Object Modeling?

• Object Modeling is the modeling of the expected
  system. Its divided into 4 main categories of
  design (or views)
• Logical Design
• Use Case View
• Logical View
• Physical Design
• Component View
• Deployment View
• Logical Design is typically language independent
  and is a model that represents the expected
  functionality of the system
• Physical Design lays out where pieces of the
  sytem are expected to end up

9
How are they different?

• When you look at a business process model and a
  Use Case diagram, they can appear to be very
  similar.
• Business Process Model models the business
  process from a workflow point of view
• Use Case models the system from a case of use
  point of view, or how the system would be used.

10
Example
11
Progressing from one to the other

• If you use both modeling techniques, the big
  question that comes up is how do you get from one
  to the other without duplicating effort?
• The answer will be very dependent on the modeling
  technique you use, most often called a
  methodology
• Every methodology is different
• Every methodology needs a lot of training
• Following a methodology is the only practical way
  to do modeling

12
Problems and Issues

• Modeling tools are expensive
• Modeling requires a lot of training
• Modeling is often viewed as an expensive process
• Often not clear as to what to do with what
• Often not clear as to how much modeling is needed

13
The Magician Syndrome

• Ever heard this explanation of system modeling?
• Well, first we create use cases
• Then we generate the classes
• Then we put together the sequence diagrams
• Then we write the system
• Huh? Howd you do that?
• Its Magic!!!

14
Following Methodologies

• When you follow a methodology, it gives you a
  guideline for what steps you should take
• Does NOT impose a strict standard
• Very often will leave some things up to the
  imagination This is often OK if you have a good
  group of designers

15
Lets build something

• The Build a house thing has been done to death
• Were gonna build a box-car (and associate
  everything to application design)

16
Business Process Model

• The Driver gets in
• Unlock the brake
• Go as fast you can without crashing
• Stop at the end without crashing

17
Use Case Model

• This shows a Case of Use, or how the
  application might be used by someone or
  something, and which other people or systems it
  might interact with to accomplish the task

18
Class Diagram

• We know were only building one thing a boxcar.
  The Class Diagram would capture the capabilities
  and attributes of the boxcar

19
Other Design Diagrams

• Depending on Methodology, you would create
  Activity Diagrams, Sequence Diagrams,
  Collaboration Diagrams, State Diagrams

20
Physical Models

• You would also create physical models such as a
  Component Diagram and a Deployment Diagram. In
  our case, the Component Diagram would show the
  interaction between the various components of the
  boxcar application
• The Deployment Diagram would actually be a
  blueprint of how the boxcar should be assembled.

21
So, lets poll the audience

• How many of you do Database Design using a
  modeling tool?
• How many of you do Business Process modeling?
• How many of you do Object Modeling?

22
Typical Results

• Almost all organizations do data modeling
• Less than 25 do object modeling

23
Question

• Why is Database Design so accepted as the only
  way you should build databases, and yet Business
  and Object Modeling continue to struggle to get
  acceptance?

24
Some Answers

• Tools are very expensive and often difficult to
  use
• DBAs do Database Design, Business Analysts do
  Business Process Modeling, Developers do Object
  Modeling
• Good developers are not always good designers
• Takes too much time
• Once done, its pretty much throw away (It
  shouldnt be, but it is)
• Project Schedules are too tight to allow time to
  build models
• Methodologies are often conflicting, difficult to
  follow and, in some cases, downright vague as to
  what should be done.

25
This brings up the following

• Business Analysts know the business
• DBAs know the data
• Who brings them together?
• Object Modelers
• How?
• Drive the process from the Business model or the
  Data model (Object modeling can do either)
• Recognize the need to spend the time to do good
  design

26
Why should we design?

• Im a good programmer. The user can tell me what
  they need, Ill check the database (if we already
  have one), and Ill figure out how to get it done
• 60 of all projects fail for one reason or
  another (Gartner)
• More than half of these are because the user
  finds out that the developers really have no clue
  as to what it is they want
• Of those that succeed, more than 80 are due to
  the heroics of the developers
• We developers love to hear that, but thats not
  sound business practice

27
We need to

• Eliminate the need for heroics
• Give the users what they want
• Reduce the risk of project failure
• Define a process that drives success
• DBAs already know this
• Business Analysts already know this
• Its time for the rest of us to figure it out
• DesignDesignDesign

28
OK, lets look at something that is more
applicable

• Report Server System allows me to use my
  datawindows for reports in a browser-based
  environment
• Needs Security, Scheduling capabilities
• Uses the CBM methodology

29
Lets Model!!!

• Demo of the Report Server application
• Uses PowerDesigner for Business, Object and Data
  modeling
• Follows a methodology called Cooperative Business
  Modeling (CBM).

30
Questions?
31
End of Session

• Send questions to Training_at_power3.com
• Visit our website www.power3.com

It's MillerTime!!