Table Of Contents

01. OOA & OOD 02. Iterative, Evolutionary and Agile 03. 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: The Mythical Man-Month - Frederick Brooks 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

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

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:

  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) 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

  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

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

H5 Evolutionary Requirement

manage requirements: systematic approach to_finding, documenting, organizing and tracking thechanging_requirements. definition requirements: capabilities & conditions that apply to system & project to which they must conform

categorized**FURPS+**model_:_

  • Functional

  • Usability

  • Reliability

  • Performance

  • Supportability

  • + implementation, interface, operations, packaging, legal

categorizedgeneralmodel_:_

  • functional (behavioral)

  • non-functional (rest)

recommended resources p 59

06. Use-case

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

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

Link:introduction to Wikis

Recommended resourcesp119

08. Iteration 1: Basics

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)

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)

  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)

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

  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 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)

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