Rational Rose and UML

1
Rational Rose and UML

• Yuefeng Li
• Ph [phone]
• Email y2.li_at_qut.edu.au

2
Overview

• Object Oriented Software Engineering
• Incremental Development
• Unified Modeling Language
• Using rational rose
• Use case diagram
• Class diagram
• Dynamic model
• sequence diagram
• state diagram

3
References

• R. Thomas, Object oriented analysis and design
  using the UMR, 2001
• Paul R. Reed, Jr., Developing application with
  Visual Basic and UML, Addison-Wesley, 2000.

4
OO Software Engineering

• Ideally you use the same type of models during
  all stages of development
• Incremental and Iterative development model
• Vaguely similar to iterative waterfall or spiral
  models
• Overall goal needs to be clear from the beginning
• Inside each increment, refine models by iteration
• Need clear completion guidelines to indicate when
  to move from one increment to another

5
Incremental Development
Static models
Release Cycle
DB design
Use case analysis
Project scope
UI prototype
Finalize architecture
Component design
Imp.
Preliminary models
Network design
Initial architecture
Dynamic models
Elaboration
Inception
Construction
6
Incremental Development

• Inception phase
• Key inputs
• The features that the system must support
• The stakeholders who will fund and/or oversee the
  systems use
• The actor who will actually interface with the
  system
• The events that the system must be aware of and
  respond to
• The constrains and risks placed on the project

7
Incremental Development

• Synergy process model,
• Which is based on iterative, incremental software
  development
• Projects phases
• Inception
• Elaboration
• Construction
• Transition

8
Unified Modeling Language

• UML
• is not a software process model or a systems
  development methodology it is a notation, a
  mechanism to pen the problem in such a way as
  to uncover the essence of an application domain.
• The goal of UML
• Providing consistency in giving feedback to the
  project sponsor that the problem domain is well
  understood, and a consistent model for proper
  software implementation.

9
Rational Rose for UML
10
Rational Rose Windows
11
Use Case Diagrams

• They describe the functionality of a system and
  users of the systems. They contain
• Actors, human users and other systems
• Use cases, which represent functionality or
  services provided by a system to users

12
Use Case Diagrams

• Use case are goal-oriented. They represent the
  what of the system, not the how.
• The pathways through the use case
• Happy path, the basic course of events (BCOE)
• Alternate pathway, alternate course of events
  (ACOE)
• Exception pathway, an exception is an error
  condition.
• Getting to use cases

13
Use Case Diagrams

• Example
• Remulak, a very small compony, specializes in
  finding hard-to-locate musical instruments, in
  particular guitars. It also sells and in-demand
  sheet music. Further, it is considering adding to
  its product line other products that are not as
  unique as its instruments. It hopes to open a
  second order processing location.

14
Use Case Diagrams
Use case
Happy path (Typical sequence of events)
A customer calls in to inquire about an orders
status
Maintain orders
Maintain inventory
The products arrive at the warehouse with a copy
of the P. O. attached
Process the order
A customer calls in and orders a guitar and
supplies and pays with a credit card
Ship the order
An entire order is shipped from stock on hand to
a customer
15
Use Case Diagrams
Use case
Happy path (Typical sequence of events)
An order is invoiced and sent to the customer,
indicating that payment was satisfied via credit
card billing.
Invoice the order
Maintain relationships
A customer calls in to change its mailing
address.
Provide decision support
The manager requests backorder status report.
16
Use Case Diagrams
Use case
Alternate pathway
To change a product quantity for one order
item. To cancel an order. To add a new item to an
order. To change the billing method.
Maintain orders
Process the order
A customer calls in and orders a guitar and does
not have a P. O. A customer calls in and orders
an organ and pays with a credit card.
17
Use Case Diagrams
Use case
Exception pathway
Maintain orders
A customer calls in to cancel an order that isnt
found in the system.
Process the order
A customer calls in to place an order using a
credit card and the card is invalid.
18
Use Case Diagrams
Features
Event List
Event able
Use Cases
19
Use Case Diagram
20
Tools ? Options Add Toolbars
21
Use Case Diagram cont.
22
Class Diagrams

• Class diagrams describe the static structure of a
  system, or how it is structured rather than how
  it behaves. They contain
• Classes, represent entities with features
  attributes, operations and associations
• Associations, which represent relationships
  between classes

23
Class Diagrams Use case analysis Static
models

• Detailing pathways
• Use case template
• Use case name
• Description
• Authors
• Actors
• Priority
• Assumptions
• Preconditions
• Postconditions
• Pathways
• Business rules

24
Class Diagrams Use case analysis Static
models

• Business rules
• Structural fact requires certain facts or
  conditions to be true, each order must have an
  order-taken date
• Action restricting prohibits one or more actions
  based on its condition
• Action triggering instigates one or more actions
  when its condition become true
• Inference states that if certain facts are true,
  a conclusion is inferred or new knowledge is
  known
• Derivation performs computations and
  calculations.
• PS some of these rules will map to attributes,
  operations, or associations between classes.

25
Class Diagrams Use case analysis Static
models

• Class
• Select class
• A class represents an interesting abstraction of
  something that contains structure (attributes) as
  well as behavior (operations)
• Applying filter rules (redundant, irrelevant,
  attribute, operation, role, event,implement
  construct)
• Get the initial list of nouns from use cases
• Apply filtering rules to winnow it down

26
Class Diagrams Use case analysis Static
models

• Type of classes
• Entity represent the core of the application
  domain. They are meant to keep information about
  the persistent application entities over time, as
  well as capture the services that drive the
  majority of interactions in the application.
• Interface serve as a boundary between the
  external actors wishing to interact with the
  application and the entity classes.
• Control are coordinators of activity in
  application domain
• Relationships
• association, aggregation, inheritance

27
Class Diagrams Use case analysis Static
models

• Creating class diagram
• Identifying attributes
• Identifying operations
• Identifying Relationships

28
Class Diagrams Use case analysis Static
models
UML attribute definition
Attribute name
Attribute default
firstNameStringYuefeng
Attribute type
29
Class Diagrams Use case analysis Static
models
UML operation specification
Operation name
Input type 1
Input type 2
calcTotal(periodInteger, rateFloat)Float
Return type
Input attribute 1
Input attribute 2
30
Class Diagram
31
Class Diagrams Use case analysis Static
models

• Object diagram (option)
• Is an improvisation of a class diagram, a
  snapshot of the lifecycle of a collection of
  objects.
• It is most often used to depict the system to
  management and to members of the organization who
  are not as familiar with the project as the
  project team is.

32
Prototype

• The user interface prototype serves many
  functions
• Further refines the actor and use case boundaries
  and clarifies any misconceptions or missing
  details
• Provides early feedback to the project sponsors
  of the many visual features that the application
  will provide
• Further details the use cases by adding an
  additional section, user interface artifacts.

33
Prototype

• The goal of the prototype
• Assess specific user interface requirements for
  the key pathways
• Provide feedback in the form of visual clues that
  stated requirements found in the use cases are
  understood and can be realized
• Begin the early development of user interface
  standards for the project
• Begin constructing the working on-screen
  templates to be used during the construction
  phase

34
Dynamic Model

• The dynamic models focus on the interaction
  between objects

35
Dynamic Model

• Types of dynamic models
• Sequence diagram, or one of interaction diagrams,
  focus on the linear flow of messages between
  objects
• Collaboration diagram, one of interaction
  diagrams, focus on the individual objects and the
  messages that they send and receive.
• State diagram, models the lifecycle of one class
• Activity diagram, models the steps in a complex
  operation, and steps of a use case pathway (close
  to traditional flow chart).

36
Dynamic Model -- the sequence diagram

• Sequence diagram of the happy path
• Use case templete (example)
• Use case name process orders
• Description
• Precondition order clerk has logged onto the
  system
• Postcondition - order is placed
• - inventory is reduced
• Primary path customer calls in and orders a
  guitar and
• supplies and pays with credit

37
Dynamic Model -- the sequence diagram

• Detail happy path
• Example
• Customer supplies customer number
• Request product ID
• Calculate order total
• Apply tax
• Customer supplies credit card number
• Validate credit card
• Reduce inventory
• Finalize and complete the sale

38
Dynamic Model -- the sequence diagram

• Determine the objects needed to build the
  sequence diagram
• Example
• Customer
• Invoice
• Order
• OrderHeader
• OrderLine
• OrderSummary
• Payment
• Product

39
(No Transcript)
40
Sequence Diagram
41
Dynamic Model -- state diagram

• Model the lifecycle of one class
• UML also supports the nation of sending events to
  other classes while modeling a class as to state
• Some classes may be uninteresting concerning
  state, e.g. Customer, what states could it be in?
  Active and Inactive? We couldnt leant very much
  about the domain of Customer by modeling it in a
  state diagram
• Not all classes warrant a state diagram

42
Dynamic Model --state diagram

• A state diagram consists of a set states
  connected by transition lines. On each transition
  line are captured (usually) events that stimulate
  an object to transition from one state to another

43
State Diagram (for Order class)
44
State diagram and flow chart
Initiate Order
Add item
No
No more items?
Yes
No, failed
Check credit
Cubstomer.reject
Yes, passed
45
Dynamic Model -- activity diagram

• The activity diagram is the new kid on the
  block, a special form of state diagram. Each
  state is considered an activity state that
  executes and then progresses to the next activity
  state.
• An activity diagram models workflows,
  computations, and complex operation steps
• It focus on the what of the flow, and not the how
• For the complex method, e.g., Order.checkCredit

46
Dynamic Mode -- select right diagram

• General rules
• Sequence use for the majority of dynamic
  modeling as it pertains to the use case pathway.
  The big payback here is the creation of the
  operational signatures for the classes in the
  application.
• Collaboration use when the application includes
  complex branching dialogs that dont render well
  in the sequence diagram.

47
Dynamic Mode -- select right diagram

• State useful only for a class that exhibits
  interesting and complex dynamic behaviour.
• Activity can clearly depict a complex workflow.

48
Finalize architecture

• This block in synergy process actually consists
  of three distinct architectures called
  execution architecture
• Technology
• deals with the many tools required to construct
  the application
• Data access technology
• Deals with how the data will be accessed in the
  application
• Application technology
• Deals with how to segment the application

49
Finalize architecture

• Logical layers of the application architecture

Presentation services
Business Services
Data services
50
Finalize architecture

• Presentation services
• Traditionally it is graphical in nature but also
  may take the form of a report or event an
  external feed to some interface The GUI layer
  evolves with time
• Scop data presentation, acceptance, GUI
• Business Services
• Will likely be the most dynamic of all of the
  layers, when possible it needs to be void of all
  user interface and data access logic
• Scop core business rules, flow control, data
  integrity
• Data services
• Is the most static aspect of the application
• Scopdurable data storage and retrieval DBMS
  accessed via APIs, concurrency control

51
Finalize architecture

• Microsofts tiering strategy
• Six logical tier model

Presentation services
Uer interface (MS windows)
Provides syntax and context editing
Business context services
Implements the business rules
Business rule services
Translates business layer request into A suitable
language, (i.e., SQL)
Data translation services
Relays the language (SQL) via a given access API
(i.e., ADO)
Data access services
Database services
Physical database technology (Oracle)
52
Finalize architecture

• Communication among six layers
• Inter-process communication architect
• Microsofts COM (component object model), each
  layer is packaged as an ActiveX DLL/EXE
• Layer communication
• Pass individual attributes and objects, ADO,

53
Database Design/build

• Mapping classes to tables
• The easiest and simplest way
• Mapping simple associations
• Mapping inheritance to the relational database
• Mapping aggregation and composition to the
  relational database

54
Summary

• What we have learn
• Incremental development model
• UML
• Rational Rose based development
• Use cases
• Class diagram
• Dynamic diagram
• Further contents
• Applying the infrastructure
• Generating code from the UML class diagram