Book: Applying UML and Patterns

December 9th, 2014


Table Of Contents

01. OOA & OOD

02. Iterative, Evolutionary and Agile


04. Inception

05. Evolutionary Requirement

06. Use-case

07. Other Requirements

08. Iteration 1: Basics

09. Domain Models (A)

09. Domain Models (B)


01. OOA & OOD

paper: Dr Frederick Brooks - "No silver bullet"

book: Dr Frederick Brooks - "Myhtical Man Month"


article: "Death by UML Fever"

"What UML is and Isn't"





Martin Fowler - "UML Distilled"


Rumbaugh - "TheUnified Modelling Language Reference Manual"

02. Iterative, Evolutionary and Agile

Source URL:

iterative/agile methods:

  1. XP extreme programming

  2. Scrum (30 day iteration, daily meeting with 3/4 specific questions per person)

  3. UP Unified Process

  4. EVO


  • iterative lifecycle

  • risk driven development

CASE: a case tool for reverse engeneering into UML

UP tries to balance "stabilize set of requirements VS changing requirements"


  1. requirements

  2. design

  3. implementation

  4. test

  5. show/feedback

  6. requirements

rapid feedback

load testing: change of architecture required?

timeboxing: deadline > scope (failing deadline means descoping)

testing: Unit, acceptance, load, usability, ...

Risk Driven:

  • identify & drive down high risks

  • architecture-centered in early iterations

Client Driven: build visible & important features (from the client point of view)


  • timeboxed

  • iterative

  • evolutionary refinement

    • plans

    • requirements

    • design

  • adaptation planning

  • incremental delivery

purpose of modelling: understand, communicate (not document)

Book: Agile Modelling - Ambler02

Phase plan: major milestones (not detail)

Iteration plan: detailed, only 1 iteration ahead

UP development:

  • short timeboxed iterative

  • evolutionary

  • adaptive

UP phases: IECT

  1. inception feasable?

  2. elaboration core architecture & high risk

  3. costruction low risk & prepare deployment

  4. transition beta, deployment

IID: Iterative Incremental Development

Book: Mythical Man Month - Dr F. Brooks

Book: recommended resources p40

04. Inception

Source URL:

H4 Inception (not requirements phase)

"Le mieux est l'ennemie du bien" - Voltaire



Inception:purpose + feasibility

  • common vision

  • basic scope

  • Envision

    • product scope

    • vision

    • business case

  • Do stakeholders agree

    • vision

    • worth investigating

cf oil drilling: no physical tests, only gathering of feasibility

"In preparing for battle I have always found that plans are useless, but planning indispensable" - Nixon90, BF00

05. Evolutionary Requirement

Source URL:

H5 Evolutionary Requirement


manage requirements: systematic approach tofinding, documenting, organizing and tracking thechangingrequirements.

definition requirements: capabilities & conditions that apply to system & project to which they must conform




  • Functional

  • Usability

  • Reliability

  • Performance

  • Supportability

  • + implementation, interface, operations, packaging, legal


  • functional (behavioral)

  • non-functional (rest)

recommended resources p 59

06. Use-case

Source URL:

H6 Use-case

text(not diagrams)

actor: something with behavior



scenario/use-case instance:


  • sequence of actions and interactions

  • one path through the use-case

  • successor failure

use-case: collection of related scenario's




  • brief (early req)

  • casual (early req)

  • fully dressed (after most use-cases are identified)

    • during req workshop (10%)


  • simple

  • accessible to users

SuD: System under Discussion



Actor Kinds:

  • primary: fulfills user-goals

    • uses services of SuD

    • why? find user goals

  • supporting: provides a service to the SuD

    • why? find external interfaces and protocols

  • offstage: has interest in behavior

    • why? find all necessary interests (identified & satisfied)

Book: Allistair Cockburn - Writing Effective Use Cases

"most popular book and approach to use case modelling"

format: single column/double column

CRUD: Create Retrieve Update Delete





G:Writing Style


  • essential: early requirements

    • no UI

    • intentions of user

    • responsiblities of system

    • NOT concrete actions

  • concrete: GUI design

    • concrete actions

    • UI embedded in text

G:Black Box Use-Cases


  • describe Responsibilities (not workings)

G:Perspective: Actor & Actor-Goal

"an observable result of value to a particular actor"

  • focus on actors (goals, typical situations)

  • focus valuable result for actor

G: Tests


  • Boss: "What have you done all day?"

  • EBP: Elementary Business Process

    • task

      • 1 person

      • 1 place

      • 1 time

    • response to event

    • adds value

    • leaves data in consistent state

  • Size: fully dressed is 3-10 pages

  • Exception: separate use case for less text duplication



actor-goal use-case table: a tool to start with

use-case driven development:

  • functional requirements use mainly use-cases

  • use cases are important part of iterative planning

  • use case realizations drive design

Book: recommended resources p99

07. Other Requirements

Source URL:

H7 Other Requirements


"fast, cheap, good: choose any two"




only a first approximation (not reliable specification)

  • supplementary specification

  • glossary

    • terms & definitions

    • data dictionary

  • vision

    • executive summary

    • > communicates the big ideas

  • buisiness rules/domain rules

Link:introduction to Wikis

Recommended resourcesp119

08. Iteration 1: Basics

Source URL:

H8 Iteration 1: Basics



each iteration a subset of a requirement/use-case is implemented (not necessarily all)

start production-quality programming before all requirement analysis is complete



Inception & Elaboration


artifacts: brief, incomplete



core+risky software architecture


  • programmed

  • tested

most requirements


  • discovered

  • stabilized

major risks


  • mitigated (less serious/gravity)

  • retired (solved)

architectural prototype


  • is a production subset of final system

  • not discardable experiment



  • domain model: visualization of domain concepts

  • design model: set of diagrams of logical design (class, interaction, package) diagrams

  • software architecture document: key architecture issues + resolution in design

  • data model: DB schema's, mapping objet <> non-object

  • use-case storyboards,UI prototypes: description UI, navigation paths, usability, ...

Planning next iteration

organize requirements and iterations

  • Risk: technical complexity, ...

  • Coverage: all major parts touched in early iterations, "wide & shallow"

  • Criticality: high business value

09. Domain Models (A)

Source URL:

H9 Domain Models


"It's all very well in practice, but it will never work in theory."

  • most important/used model in OOA

  • illustrates noteworthy concepts

  • inspiration >> design objects

  • input >> other artifacts

OOA/D knowledge > UML notation

Analysis Paralysis: trying to make a "correct" domain model






general definition:

Domain Model: visual representation of conceptual classes/real situation objects.

aka: conceptual model, domain model, analysis object model

UP Domain Model: representation ofreal-situationconceptual classes (not software objects)

  • not diagrams of software objects

  • not domain layer of software architecture

  • not software objects with responsibilities(=methods)

specialization ofBusinessObjectModel (BOM)



in UML: class diagrams without operations(=methods)

  1. domain objects or conceptual classes

  2. associations

  3. attributes

Domain Model is a "Visual Dictionary" of abstraction, vocabulary, information context (info could have been put in the UP Glossary)




  • software objects (Java, C#)

  • software artifacts (unless this is the domain eg. GUI)

  • responsibilities or methods

domain layer: layer of software objects below presentation or UI layer, composed of domain objects(+methods)



conceptual class: idea, thing, object

  • symbol: name eg. "Sale"

  • intension: definition eg. "event of purchase transaction"

  • extension: all examples eg. "all sale instances in the universe"

data model: persistent data


domain model: conceptual class can be without attributes or volatile






lower representational gap with OO Modelling

UP Domain Model inspires UP Design Model (names)






BOUNDED by current iteration requirements

  1. find conceptual classes

  2. draw them in UML class diagram

  3. add associations & attributes



G:Finding Conceptual Classes:

3 strategies:

  1. reuse/modify existing models

  2. category list

  3. noun phrase

1.Reusepublished, well crafted

  • domain models

  • data models (transformed to domain model)

Book: Analysis Patterns - Martin Fowler

Book: Data Model Patterns - David Hay

Book: Data Model Resource Book (vol 1,2) - Len Silverston



2.Category List: list of candidate conceptual classes through standard questions/categories



3.Noun Phrase Identification:

textual description of a domain (eg. use-cases)

noun, noun phrases=>candidate conceptual class/attribute


  • imprecision of natural language

  • some may refer to conceptual classes that are ignored in this iteration

G: sketch UML with bottom & right side of boxes open

G: Maintain model in a tool?

  • ONLY if there is a practical reason to maintain it

  • UML CASE tool

G: Report Objects (receipt)

  • :-( only duplication/derrived information

  • :-) special role? (handle return)

G: Mapmaker Strategy

cf "Use the Domain Vocabulary" strategy

  • use existing names of the territory

  • exclude irrelevant/out-of-scope features

  • don't add things that are not there

G: Attributes vs Classes

"if you do not think of it as a number or text in the real world, its probably a conceptual class, not an attribute"

G: Description Classes (aka specification)

aka "Item Descriptor" Pattern


  • duplication (space, errors)

  • if all instances are removed, info is not available


  • description of item/service is independent of current existence

  • deleting instance => loss of information that must be maintained

  • reduces redundant or duplicated information

09. Domain Models (B)

Source URL:

H9 Domain Models



association: relationship between classes (instances)

UML: "semantic relationship between classifiers that involve connections among their instances"

G: When?

  • knowledge of relationship needs to be preserved for some time

  • derived from 'Common Associations List

G: Avoid many associations

UML: Notation

  • line betweeen classes

  • Capitalized association name

  • bidirectional

G: Naming

  • 'Classname - VerbPhrase - Classname' format

  • meaningful

  • CamelCaps/hyphen-bound

UML: Roles (each end of association)

  • multiplicity:Store 1---* Item

  • name

  • navigability

UML: Multiple Associations possible




attribute: logical data value of object

only for information requirements of current scenario's

G: When?

  • requirements imply "need to remember information"

UML: Notation

visibility name : type multiplicity = default {property-string}

/derrived-attribute // calculated from other values

G: Attribute requirements >> UP Glossary (instead of as attribute)

G: Attribute Types

  • equality by value (not identity)

  • immutable?

eg: primitive data types, date/time, address/contact, enum, ...

G: Define new Data Types?

  • seperate sections?

  • operations associated (parse/validate)

  • quantity with unit (price, weight)

  • abstraction

G: No foreign key (association)

G: Quantities & Units (distinct classes, as type or association)





Process: Iterative & Evolutionary Domain Modelling

  • usually only inelaborationphase

  • incremental

  • limited to prior & current scenario's under considerdation

recommended resources p 170