( © 2004 benet devereux assertions ● attribute assertions – always hold of an attribute: for...

(

© 2004 Benet Devereux

Assertions

● Attribute assertions– Always hold of an attribute: for instance

Employee.age > 18– May reference other attributes

● Operation assertions– Pre- and post-conditions: must hold immediately

before (after) operation– Invariants: must hold during the operation

● Note difference from global assertions!

Based on Graham 1998

(


Discovering Relations

● Kinds of relations:– Inheritance (subclassing, A Kind Of)– Composition (aggregation)– Usage (object A uses an operation of object B)– Association (some other kind of relation: such as

Student enrolled-in Class)


(


Inheritance

● “Is-A” or “Is-A-Kind-Of” relationship● Questions to ask

– Does a proposed subclass/superclass matter for any tasks in the domain?

● An Employee is a kind of Mammal.. but who cares?– Does a proposed subclass have any different

behaviour?● If not, maybe an attribute is enough

– Does a proposed subclass override default behaviour of the superclass?

● A Bird class may have a fly() operation; but a Penguin does not have the ability to fly

● Still can be inheritance, but must be careful!


(


Aggregation

● Part/whole relationships● Questions to ask:

– Does the part have little or no independent existence outside the whole?

● e.g. A Line in a Document– Does the part move when the whole moves?– Do operations get propagated to the parts?


(


Usage

● Object A will use operations of object B to perform one of its responsibilities– Needs to know B's identity– Needs to know what operations B supports

● Either A is aware of B directly– Or can request B's identity from another object

● Law of Demeter: an object should never need to do further indirection


(


Other Associations

● Any relationship not covered by the previous three

● Uni-directional relationships– Have “endedness”– Knowing about the association is the source

object's responsibility● Bi-directional relationships

– Can be traversed in either direction– Either both objects must know about the

association– Or, associations are first-class citizens

themselves


(


Multiplicity of Relations

● Typical options: {one, zero or one, many} to {one, may}

● For example: one Patron may borrow many Books; but may have only one Account (nonspecific associations)

● A Course has zero or one Tutorials (aggregation)


(


Stereotypes

● An informal (usually) descriptor attached to an object

● Helps clarify the object's purpose quickly, without adding spurious superclasses to the model

● For instance: – domain objects (usually nouns from the problem

statement), like Product, Transaction– application objects usually encapsulate some

logic, such as TaxCalculator– Interface objects (not usually used in

requirements)

(


Attribute Constraints

● An attribute is of primitive type– Char, string, int, real, array

● Attributes may be:– Class or instance attributes– Optional: there may be no value

● Correct use means no get when no value– Write-restricted

● Only authorized objects may set– Read-restricted

● Only authorized objects may get– Of dependent type

● For instance, restricted in range● Represented by attribute invariants


(


Mode-Class Attributes

● An attribute is a mode-class if– It represents the current dynamic state of the

object– There is only one such attribute!

● Example: cruise-control– Attributes are set-point (integer), current-

speed(integer), and status ({off, above-set, below-set})


(


Operation Constraints

● Operations have a signature (assigning a type to each parameter and to the return value)

● Operation invariants must hold (of the object's visible attributes) continuously while the operation is taking place

● Operation pre- and post- conditions must hold before (after) the operation is invoked (returns)


(


Rulesets

● Unordered set of constraints for an object● In “if/then” form

– “if (attribute in some range) then (some operation must be called)”

– “if (some message received from object A) then (message must be sent to object B)”

● Must be consistent– Multiple inheritance may break this– Policies for resolving rules are needed


(


CRC Cards

● Class-Responsibility-Collaboration● Class

– Class name and brief description– Superclasses– Components

● Responsibility– What tasks is the class obliged to perform?

● Collaboration– What other classes use this one?– Which classes does this one use, and for what?

● Should fit on a single card– Otherwise the class does too much!


(


Goal Modeling

● Elements of goal models– Agents

● Have goals, perform tasks– Goals

● 'Hard' goals: operationalizable ('maintain condition')● Soft-goals: vaguer ('system should be secure')

– Tasks● Activities/processes, carried out by agents

– Resources● Used by agents to perform tasks

Based on Sutcliffe

(


Goal Decomposition

● Begin with high-level goals– Obtained from mission statement, discussions

● Hierarchically decompose into simpler goals– AND-decomposition: goal is met when each

subgoal is met– OR-decomposition: goal is met when any

subgoal is met (“alternatives”)● When to stop?

– When goals can clearly be assigned to subsystems as implementable tasks


(


A Warning..

● Goal analysis shouldn't become psychoanalysis

● Stick with the needs of the stakeholder as defined by their role– If they have “Increase revenue” as a goal..– Maybe a less materialistic life would make them

truly happier, but it's not an engineer's task to suggest (much less arrange!) that..

● Moral:– Don't get too worried about 'solving the real

problem'; solve the problem users bring

Based on Jackson 2001

(


Other Goal Relationships

● Depends-on– Agent depends-on goal (task); agent has that

goal– Goal (task) depends-on agent; agent has

responsibility to fulfill goal (do task)– Goal (task) depends-on resource; cannot be

completed without the resource● Contributes-to (+); detracts-from (-)● Strongly contributes-to (++); strongly

detracts-from (--)● Cuts across decomposition hierarchy

Based on Sutcliffe

(


A Simple Goal Model (Library)

PatronClerk

Borrow books

Enforce due

dates

Find books of

interest

Sign out

books

D

D

Catalogue

D

Collect fines

Stop patron

account

Accounting

system

D--

agentOR-decomposition

resource

task

AND-decomposition

softgoal

(


Points about Goal Models

● Don't absolutely need to build top-down– The example starts somewhere in the middle

● Decomposition goes by asking How?● Moving up in the goal hierarchy goes by

asking Why?● The notation used here (i*) does not

distinguish between 'How things are currently' and 'How we ought to be'; must be documented separately

(


Goal Model Semantics

● Are 'semi-formal' as presented here– AND/OR relationship is completely formal

● Can label leaf goals/tasks and propagate upwards– What about + and – type relations?

● No exact semantics!● If all activated edges are either + or -, we're OK● Otherwise need fuzzy semantics of some kind

(


Use-Cases

● Typical interaction between user and system– Captures some user-visible function– May be small or large– Achieves a discrete goal for the user

● Capturing use-cases– Sit down with end-users– Discuss things they might do with the system– For each discrete thing

● Give it a name● Write up a short description (a few paragraphs)

Based on Fowler 1997

(


Use-Case Diagrams

● Part of the UML● Elements are:

– Actors (indicated by stick figures, even if they are systems!)

– Use cases (indicated by ovals with brief description)

● Relations are:– Actor performs use-case– Use-case A <uses> use-case B– Use-case A <extends> use-case B

● To clarify...

Based on Fowler 1997

(


Use-Case Diagram

Patron

Search Catalogue

Place Hold

<<uses>>

Clerk

Pay Fines

Borrow Book

<<extends>>

(


Use-Case Text

● “Place Hold”:– Patron searches catalogue for book (uses)– Patron asks to place hold– Patron selects branch and method of notification– System confirms hold

● “Pay Fines”– Clerk scans patron card– System announces fines are above limit– Clerk enters payment into accounts– System releases patron account– Clerk signs out patron book

● Note there is no “call” to the “borrow book” case

(


Granularity of Use-Case Steps

● Each step should be an SVDPI sentence– Subject Verb Direct-object Preposition Indirect-

object(s)– Subject should be an agent

● All verbs and nouns should be part of the object model– Stop simplifying when it would introduce things

outside the domain model (such as 'pressing a key')


(


How Many Use-Cases?

● For a 10 person-year project– Jacobson: 20– Fowler: 100

● Supporting a single use-case can be a development step– So smaller, more specific ones make for more

frequent targets, allow faster feedback– Too many can be overwhelming!

(


Use-Cases and Goals

● A use-case describes a task or sequence of tasks that meets a goal

● Use-case diagram presents a complementary view to the goal model

● The link between use-cases and goals provides traceability– Use-cases are implementation targets

(


Use-Cases and Object Models

● Use-cases can help check consistency, completeness of the object model with walkthroughs– Use the CRC cards– Starting with the operations invoked by the

user,walk through the sequence of messages between objects

– Is everything consistent?– Are any operations or objects not used in any

use-case?● If not, why are they there?

– An executable walkthrough is a prototype


(


Prototyping

● Two basic kinds of prototypes– Rapid

● Functionality is partial● Efficiency and other non-functional requirements not

considered● Designed to be shown to customers and thrown away

– Evolutionary● Functionality is partial● Intended to mutate into a finished system

– Through iterative addition and refinement of functionality– Through optimization of operations

– Research● “For internal use only”● Helps manage implementation risk

(


Prototyping, continued

● Broad and shallow– Covers many features in outline

● Deep– Covers a few featues in great detail

● Where to prototype first?– Easiest problems, to gain confidence– The area solving 80% of business need– The area presenting greatest technical challenge

● Of course these are estimations!● Combination of second two is ideal

(


Input Forms

● Every step in a use-case where the user invokes an operation requires an input form

● The form is an application object that sends messages to domain objects– Possibly by way of input validator objects– Input validation seems like a design (or even

implementation) decision– But the choice of how incorrect user input is

handled is really a requirement– There is a tradeoff between the goals of usability

and simplicity of implementation (and possibly others)

(


Caveat on Input Forms

● Should not be considered 'user interface design' proper– Though will yield important lessons for that

design● We are simply documenting the places

where an agent communicates directly with a domain object– May even be an automated agent!

● Forms are for analysis, not for end use

(


Message Sequence Charts

● Animates the messages passed between objects during walkthrough

● Each object has a timeline (running from the top of the chart to the bottom)

● Messages are shown passing from one object's timeline to another

(


MSC Example: “Place Hold”

Catalogue search form BookDatabase CirculationCirculationRecords

searchBook()

[found=true]

placeHold()checkStatus()

[copy on shelf=false]

Holdnew()

bookOnShelf()

requestBook()

updateRecords()

Noteinformality!

(


Coming Up Next

● Giving models more predictive power– Formalizing constraints and rulesets– OCL: the Object Constraint Language– Organization models– Data-flow models

( © 2004 benet devereux assertions ● attribute assertions – always hold of an attribute: for...

Documents