Book: Applying UML and Patterns
December 9th, 2014
Table Of Contents
02. Iterative, Evolutionary and Agile
03.
01. OOA & OOD
paper: Dr Frederick Brooks - "No silver bullet"
book: Dr Frederick Brooks - "Myhtical Man Month"
UML vs CASE vs MDA
article: "Death by UML Fever"
"What UML is and Isn't"
class
-conceptual
-software
-implementation
Martin Fowler - "UML Distilled"
Rumbaugh - "TheUnified Modelling Language Reference Manual"
02. Iterative, Evolutionary and Agile
Source URL:https://mail.google.com/mail/u/0/#label/The+Great+Book+of+Learning/143d4f58f1741d7e
iterative/agile methods:
XP extreme programming
Scrum (30 day iteration, daily meeting with 3/4 specific questions per person)
UP Unified Process
EVO
UP
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"
iteration:
requirements
design
implementation
test
show/feedback
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)
agile:
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
inception feasable?
elaboration core architecture & high risk
costruction low risk & prepare deployment
transition beta, deployment
IID: Iterative Incremental Development
Book: Mythical Man Month - Dr F. Brooks
Book: recommended resources p40
04. Inception
Source URL:https://mail.google.com/mail/u/0/#label/The+Great+Book+of+Learning/143d9a2af8c50da1
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:https://mail.google.com/mail/u/0/#label/The+Great+Book+of+Learning/143d9a90e4af9c51
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
categorizedFURPS+model:
Functional
Usability
Reliability
Performance
Supportability
+ implementation, interface, operations, packaging, legal
categorizedgeneralmodel:
functional (behavioral)
non-functional (rest)
recommended resources p 59
06. Use-case
Source URL:https://mail.google.com/mail/u/0/#label/The+Great+Book+of+Learning/143e94835f44f791
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
formats:
brief (early req)
casual (early req)
fully dressed (after most use-cases are identified)
during req workshop (10%)
Why?
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
GUIDELINES
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:https://mail.google.com/mail/u/0/#label/The+Great+Book+of+Learning/143ee6494cddd7f7
H7 Other Requirements
"fast, cheap, good: choose any two"
Artifacts
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
Recommended resourcesp119
08. Iteration 1: Basics
Source URL:https://mail.google.com/mail/u/0/#label/The+Great+Book+of+Learning/1440dbe1ff0dacb2
H8 Iteration 1: Basics
Requirements
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
Inception
artifacts: brief, incomplete
Elaboration
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
artifacts:
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:https://mail.google.com/mail/u/0/#label/The+Great+Book+of+Learning/1441c8d8e6600670
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
What?
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)
domain objects or conceptual classes
associations
attributes
Domain Model is a "Visual Dictionary" of abstraction, vocabulary, information context (info could have been put in the UP Glossary)
NOT
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
vs
domain model: conceptual class can be without attributes or volatile
Why?
lower representational gap with OO Modelling
UP Domain Model inspires UP Design Model (names)
How?
BOUNDED by current iteration requirements
find conceptual classes
draw them in UML class diagram
add associations & attributes
G:Finding Conceptual Classes:
3 strategies:
reuse/modify existing models
category list
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
why:
duplication (space, errors)
if all instances are removed, info is not available
when:
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:https://mail.google.com/mail/u/0/#label/The+Great+Book+of+Learning/1441d3822d5e812c
H9 Domain Models
Associations
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
Attributes
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