IMSE 12

1
IMSE 12

• UML (contd) -
• Objectory, Use Cases and CRC cards

2
Summary of last week

• UML classes, with attributes and operations
• UML relationships
• - generalisation
• - aggregation and composition
• - association and roles
• multiplicity, navigability
• derived attributes, visibility (public, private,
  protected)
• multiple and dynamic classification,
  discriminators, meaningful arrows, meaningful
  joined lines, complete, ltdynamicgt

3
What is a Modeling Language?

• a modeling language is the graphical notation
  used in developing a system
• a modeling language plus a process (the steps to
  take to develop the system) make up the method
  used to produce a system

steps to take to develop the system
4
Processes

• a process is the steps to take to develop the
  system
• e.g. the waterfall life cycle whose steps or
  stages are
• - requirements analysis
• - specification
• - design
• - implementation
• - testing
• - operation and maintenance
• other processes exist, and others are being
  developed

5
The Rational Objectory Process

• the Rational Objectory software development
  process (known as Objectory) is being developed
  by the 3 amigos
• UML and Objectory fit very well together, but UML
  can be paired with another process to produce a
  high quality method more suitable for a
  particular system

modeling language
process
6
Outline of Objectory

• its hard to talk about graphical notation in
  isolation, without some process in mind
• well consider an overview of Objectory to help
  us with UML
• the 4 steps or phases in the Objectory process
  are
• - inception
• - elaboration
• - construction
• - transition
• the phases are iterative and incremental,
  software developed and released in pieces not in
  one big bang
• the construction phase in particular is highly
  iterative

7
The Inception Phase

• ranges from a simple chat to a full blown
  feasibility study
• establish the business rationale for the project
• decide on the scope and size of the project
• consider costs and time scales
• get commitment from the customer to go ahead
• very short phase relative to the others

8
The Elaboration Phase

• collect more detailed requirements
• identify main risks to the projects success, via
  use cases (see later)
• do high level analysis
• do high level design
• create a plan for construction
• elaboration takes about one fifth of the total
  project time
• completed when detailed time estimates are
  established

9
Use Cases

• a use case is a something the user wants the
  system to do, e.g.
• 1) make some selected text bold
• 2) order some goods
• 3) add a new software engineer
• use cases can be large as in 2) or small as 1)
• very useful aid for understanding functional
  requirements
• important to identify all the use cases required
  in the system to be developed
• use case diagrams are part of UML

10
Scenarios

• An example of a use case is buying a product from
  an on-line store. This may incorporate three
  possible scenarios
• successfully buy the product at the normal price
• buy the product and receive discount for loyal
  customers
• fail to buy the product because credit card not
  valid

11
Example of a Use Case Diagram
an actor i.e. a role that a user plays to carry
out a use case - actors need not be human
project leader
a use case
software engineer
12
The Construction Phase

• by far the largest phase, with many iterations
• each iteration contains analysis, design,
  implementation, unit testing, integration,
  documentation, demo to user
• each iteration builds production-quality
  software, tested and integrated
• each iteration satisfies a subset of the
  requirements, i.e. some of the use cases
• each iteration may be delivered to external,
  early users or may be a purely internal delivery
• good use of iteration, forcing developers to get
  used to delivering finished code

13
The Transition Phase

• takes place after all pieces of the
  iteratively-produced software are integrated, and
  system testing is complete
• consists of
• - beta testing and any ensuing bug fixing
• - performance tuning
• - user training
• lasts between the beta release and the final
  release of the software

14
CRC Cards

• Class - Responsibility - Collaboration cards
• not part of UML but should be used with UML to
  produce high quality systems
• Cunningham and Beck 1989
• good points
• they help you to think in an object-oriented way
• they emphasise responsibilities
• they uncover generalisation and aggregation
• they dont use complex notation

15
Example of a CRC Card
class name
responsibilities, services provided by the class
collaborators, other classes needed to work with
16
Using CRC Cards

• set of index cards is created for each class
  identified
• one card created for a particular scenario
• cards shared around developers
• scenarios are acted out
• cards are modified where problems occur
• 4 x 6 cards used so only high level
  responsibilities included

17
Domain model

• the domain model starts to explain how the
  entities (e.g. project leader, software engineer,
  company car) fit together
• the domain model is the starting point for class
  and interaction diagrams which are the basis of
  the design of the system
• the entities are potential classes, the ways they
  fit together are potential relationships
• the domain model, the use cases and the CRC cards
  capture functional requirements, and would all be
  done at a high level in the elaboration phase
• more detail would be added in the construction
  phase, along with detailed design (e.g. class
  diagrams, interaction diagrams), implementation,
  testing, documentation and demos, all produced
  iteratively and incrementally