Comparative Development Methodologies Lecture 8

1
Comparative Development MethodologiesLecture 8

• Niki Trigoni
• Department of Computer Science
• and Information Systems
• Birkbeck College, University of London
• Email niki_at_dcs.bbk.ac.uk
• Office Hours Wednesdays, 6 - 7 pm
• Web Page http//www.dcs.bbk.ac.uk/niki

2
Review of lecture 7

• We described three examples of blended
  methodologies
• SSADM
• Merise
• IE
• The three methodologies combine process-oriented
  and data-oriented aspects.
• SSADM takes a an information systems development
  life cycle approach used in many UK government
  systems.
• Merise defines three cycles decision, life and
  abstraction the abstraction cycle analyzes data
  and processes at a conceptual, logical and
  physical level.
• IE places more importance on data-oriented
  aspects and covers the entire life cycle of an
  information system

3
Overview of lecture 8

• The Unified Process (UP) an object-oriented
  methodology
• Object-oriented analysis and design
• Phases and iterations of the UP
• Disciplines and artifacts of the UP
• Workshop a quick walk through the phases,
  disciplines and artifacts of the UP, using a
  specific system development example

4
Object-oriented analysis and design

• Analysis do the right thing
• investigation of a problem
• requirements
• e.g. requirements analysis or object analysis
• Design do the thing right
• conceptual solution that fulfills the
  requirements
• can lead to implementation
• not the implementation
• e.g. object design or database design
• Object-oriented Analysis and Design (OOA/D)
• think (analyze and design) in objects

5
Object-oriented analysis

• OO analysis create a description of the domain
  from the perspective of classification by
  objects.
• identify main concepts (objects)
• add attributes
• associate objects with each other

6
Object-oriented design

• OO design define software objects and their
  collaborations
• static view design class diagrams
• dynamic view interaction diagrams

7
Object-oriented design

• OO design define software objects and their
  collaborations
• static view design class diagrams
• dynamic view interaction diagrams

8
OOA/D in the Unified Process (UP)

• In which context do we apply OOA/D ?
• We need a process
• with well defined steps
• that uses OOA/D
• in order to achieve a software development goal.
• The Unified Process is an example process
  particularly suited for building OO systems.

9
Central ideas in the UP

• Use of OO technologies
• Iterative lifecycle
• Continuous feedback and adaptation
• Managed complexity
• Early visible progress
• Time-boxed iterations
• Risk-driven development
• Early mitigation of high risks
• Cohesive and well-documented process
• Widely used process
• UML a well-defined modeling language for
  documenting and communicating ideas and designs

10
The UP iterative development

• Feedback from iteration N leads to refinement and
  adaptation of the requirements and design in
  iteration N1
• Iterations are fixed in length

Requirements
Requirements
Analysis Design
Analysis Design
Time
Implementation
Implementation
Testing Delivery
Testing Delivery
Iteration N
Iteration N1
11
UP phases

• Inception
• Feasibility phase and approximate vision
• Elaboration
• Core architecture implementation, high risk
  resolution
• Construction
• Implementation of remaining elements
• Transition
• Beta tests, deployment

12
UP artifacts and disciplines

• The UP describes work activities, which result in
  work products called artifacts. Examples of
  artifacts
• Code
• Web graphics
• Database schema
• Use cases (text documents explaining business
  scenarios)
• Diagrams, models and so on
• A discipline (or workflow) is a set of work
  activities. Examples
• Requirements
• Business modeling
• Design

13
UP disciplines and iterations

• An iteration includes work in most disciplines.

Sample UP Disciplines
Business modeling
Requirements
Design
Implementation
Test
Deployment
Configuration and Change Mngmnt
Project Mngmnt
Environment
14
An overview of the Unified Process
15
Requirements in the Unified Process
16
Inception

• Define the vision and business scope of the
  project
• Define high-level goals and constraints
• Investigate core requirements
• Study feasibility
• Identify critical (business, technical, schedule,
  ) risks
• Obtain an order-of-magnitude estimate of the cost
• Determine who will do it (buy and/or build)
• Decide if it is worthwhile to invest in deeper
  exploration
• Plan the first iteration of elaboration
• Estimate the number of iterations needed for
  elaboration

17
Inception (cont.)

• Usually, it lasts one or a few weeks (e.g. one
  iteration).
• Artifacts that may be started during inception

18
Requirements

• Requirements are capabilities and conditions to
  which the system and more broadly, the project
  - must conform.
• The FURPS model Grady92
• Functional
• Usability
• Reliability
• Performance
• Supportability
• implementation, interface,
  operations,
  packaging, legal

quality requirements
non-functional requirements
19
The use-case model Jacobson92

• Use cases are stories of using a system to meet
  goals.
• The use-case model the set of all use cases -
  is an artifact within the requirements discipline
  of the Unified Process.
• Writing use cases is a good way of understanding
  and describing requirements (esp. functional
  ones).
• Use case example (in brief format)
• Process Sale A customer arrives at a checkout
  with items to purchase. The cashier uses the
  system to record each purchased item. The system
  presents a running total and line-item details.
  The customer enters payment information, which
  the system validates and records. The system
  updates inventory. The customer receives a
  receipt and leaves with items.

20
Use cases scenarios

• An actor is something with behavior, such as a
  person, computer system, or organization e.g. a
  cashier.
• A scenario also called use case instance - is a
  specific sequence of actions and interactions
  between actors and the system under discussion.
  It is one path through the use case.
• A use case is a collection of related success and
  failure scenarios that describe actors using a
  system to support a goal.
• Process Sale
• Main Success Scenario A customer arrives at a
  checkout with items to purchase
• Alternate Scenarios
• If the system rejects customers credit
  card
• If the customer has less cash than the
  required payment

21
Guidelines for writing use cases

• Try to answer the question How can using the
  system provide observable value to the users or
  fulfill their goals?
• Dont think of system requirements in terms of a
  check list of features or functions.
• Use cases emphasize the functional requirements
  (other requirement types are sometimes included,
  but have a secondary role).
• Use cases are text documents, not diagrams.
• Black-box use cases are highly recommended. We
  describe the responsibilities of a system, not
  the internal workings.
• Process Sale The system records the sale
• NOT The system generates an SQL INSERT stmt for
  the sale

22
Fully-dressed use case example
Use Case UC1 Process Sale

• Primary Actor Cashier
• Stakeholders and Interests
• -Cashier wants accurate fast entry, no payment
  errors
• Customer wants fast service and minimal purchase
  effort
• Company ?
• Government Tax Agencies ?
• Payment Authorization Service ?
• Preconditions Cashier is identified and
  authenticated
• Success Guarantee (Post-conditions)
• Sale is saved and tax is correctly calculated.
• Accounting and inventory updated.
• Receipt is generated.
• Payment authorization approvals are recorded.
• ???

23
Fully-dressed use case example (cont.)
Use Case UC1 Process Sale

• Main Success Scenario (or Basic Flow)
• Customer arrives at POS checkout with goods to
  purchase.
• Cashier starts a new sale.
• Cashier enters item identifier.
• System records sale line item and presents item
  description, price and running total.
• Cashier repeats steps 3-4 until indicates done.
• 5. System presents total with taxes calculated.
• 6. Cashier tells Customer the total, and asks for
  payment.
• 7. Customer pays and System handles payment.
• 8. System presents receipt.
• 9. Customer leaves with receipt and goods (if
  any).

24
Fully-dressed use case example (cont.)
Use Case UC1 Process Sale
Extensions (or Alternative Flows) a. At
any time, System fails Ensure all transaction
states are recoverable. 1. Cashier restarts the
system, logs in, and requests recovery of prior
state. 2. System reconstructs prior state. 3a.
Invalid identifier 1. System signals error and
rejects entry. 3b. There are multiple of same
item category and tracking unique item identity
not important. 1. Cashier enters item category
identifier and the quantity. 3-6a. Customer tells
Cashier to cancel sale 1. Cashier cancels sale
on System.
25
Fully-dressed use case example (cont.)
Use Case UC1 Process Sale

• Special Requirements
• Touch screen UI. Text visible from 1 meter.
• Credit authorization response within 30 seconds.
• Pluggable business rules to be insertable at
  steps 3 and 7.
• Etc.
• Technology and Data Variations List
• 3a. Item id entered by bar code laser scanner or
  keyboard.
• 3b. Item id may be any UPC, EAN, JAN or SKU
  coding scheme.
• Etc.
• Frequency of Occurrence Could be nearly
  continuous.
• Open issues
• What are the tax law variations?
• Explore the remote service recovery issue.

26
Use case diagrams
system boundary
communication
NextGen
notation for human and computer actors
Process Sale
Payment Authorization Service
Cashier
Handle Returns
actor
actor Tax Calculator
Process Rental
actor Accounting System
Cash In
actor Sales Activity System
Analyze Activity
actor HR System
Manage Security
Manage Users
System Administrator
use case
. . .
27
Vision, SS and Glossary

• The Vision includes the big ideas regarding why
  the project was proposed, what the problems are,
  who the stakeholders are, what they need, and
  what the proposed solution looks like.
• The Supplementary Specification captures
  non-functional requirements, e.g. documentation,
  packaging, supportability, licensing etc.
• The Glossary is like a data dictionary it
  defines terms used in other artifacts (use cases,
  SS, vision etc.).
• Suggestion start the glossary early!

28
A (partial) Vision example

• Revision History (version, date, description,
  author)
• Introduction We envision a fault-tolerant
  point-of-sale appl. With the flexibility to
  support varying business rules and integration
  with multiple third-party supporting systems.
• Positioning
• Business Opportunity (what existing systems
  cant do)
• Problem Statement (problems caused by lack of
  features)
• Product Position Statement (who the system is
  for, outstanding features, how is it different
  from competition)
• Stakeholder Descriptions
• Stakeholder (non-user) summary Stakeholder
  goals
• User summary (and their goals) User-level
  goals
• Product Overview
• Product perspective Product benefits
• Cost and Pricing Licensing and Installation
• Summary of System Features
• Other Requirements and Constraints

29
A (partial) SS example

• Revision History (version, date, description,
  author)
• Introduction This document is the repository of
  all requirements not captured in the use cases.
• Functionality
• Logging and Error Handling Log all errors to
  pers. storage
• Pluggable Business Rules Customize
  functionality
• Security All usage requires user authentication
• Usability
• Reliability
• Performance
• Supportability (Adaptability and
  Configurability)
• Implementation Constraints Java technology
  solution
• Purchased Components Tax calculator.
• Interfaces (Hardware and Software)
• Domain (Business) Rules (id, rule,
  changeability, source)
• Legal Issues
• Information in Domains of Interest (pricing,
  sales tax, item ids)

30
Order of artifacts in Requirements discipline

• We dont have to be rigid. A synergy is
  preferred, in which working on one artifact helps
  clarify another.
• Suggested sequence
• Write a brief draft of Vision.
• Identify user goals and the supporting use cases.
• Write some use cases and start the Supplementary
  Specification.
• Refine the Vision, summarizing information from
  these.

31
Requirements in different UP phases

• Requirement in Iteration 1 of the inception phase
• Use-case model use-cases and diagrams
• Vision, supplementary specification (SS),
  glossary
• Requirements in Iteration 1 of the elaboration
  phase
• Use-case model
• system sequence diagrams
• contracts
• Use-case model write most of the use cases and
  other requirements in detail, through a series of
  workshops one per elaboration iteration.
• Refine the Vision, SS and glossary documents

32
System sequence diagrams (SSDs)

• Use cases describe how actors interact with the
  software system
• UML notation for illustrating actor interactions.
• Given a scenario of a use case, an SSD shows
• the external actors that interact directly with
  the system,
• the system as a black box and
• the system events that the actors generate.
• The ordering of events should follow their order
  in the use case.
• SSDs are part of the use-case model.
• SSDs are visualizations of interactions implied
  in the use cases.

33
An SSD example
Cashier
System
makeNewSale()
enterItem(itemID, quantity)
description, total
more items
endSale()
total with taxes
makePayment(amount)
change due, receipt
34
From requirements to business modeling

• Domain model
• the most important artifact of business modeling
• a visual representation of conceptual classes or
  real-world objects in a domain of interest
• not a visualization of software components
• Class diagrams (UML notation) show
• conceptual classes
• attributes of conceptual classes
• associations between conceptual classes
• Why do business modeling?

35
A glimpse at a partial domain model
Sales LineItem quantity
Item
Records-sale-of
0..1
1
1..
Contained-in
1
Sale date time
Payment amount
Paid-by
1
1
36
How to generate a domain model

• List candidate conceptual classes
• Draw them in a domain model
• Add associations for which information must be
  maintained
• Add the attributes necessary to fulfill the
  information requirements

37
Conceptual classes

• Three ways of viewing a conceptual class
• Symbol
• Intension
• Extension
• In a domain model, we are interested in both the
  symbol and the intension of a conceptual class.

A sale represents the event of a purchase
transaction. It has a date and a time.
Sale date time
sale-1
sale-3
sale-2
sale-4
38
How to identify conceptual classes
Use a conceptual class category list. -
physical objects - specifications, descriptions
- places - transactions - transaction line
items - roles of people - containers or
contained item - event - catalog etc.
Identify noun phrases in the use cases. Process
Sale Main Success Scenario 1. Customer
arrives at a POS checkout with goods to
purchase. 2. Cashier starts a new sale. 3.
Cashier enters item identifier. 4. System
records sale line item and presents item
description, price and total.
39
Candidate Conceptual Classes
Product Catalog
Product Specification
Sales LineItem
Store
Item
Sale
Register
Manager
Payment
Customer
Cashier
40
How to identify associations

• An association is a relationship between object
  instances that indicates some meaningful and
  interesting connection
• worth remembering
• derived from the Common Associations List
• A is a physical (or logical) part of B
• A is physically (or logically) contained in
• A is a description of B
• A is known/captured/logged/recorded in B
• A uses or manages B
• A is related to a transaction B
• Etc.

41
Candidate associations

• Relationships that need to be remembered
• Register Records Sale (why?)
• Sale Paid-by Payment (why?)
• ProductCatalog Records ProductSpecification
  (why?)
• Relationships derived from the Common
  Associations List
• SalesLineItem Is-contained-in Sale
• Store Contains Item
• ProductSpecification Describes Item
• Cashier Is-member-of Store
• Cashier Uses/Manages Register
• Customer/Cashier Makes/Receives (Is-related-to)
  Payment
• Etc.

42
Multiplicity of associations
T

Attention! The multiplicity value of a
relationship indicates how many object instances
can be validly associated with another, at a
particular moment, rather than over a span of
time.
1..
T
1..2
T
5
T
1,2,5
T
43
Adding associations (names/multipl.)
1
ProductCatalog

Contains
ProductSpecification
SalesLineItem
1
1..
1
Used-by

Store
1..
Stocks
Item
Contained-in
1
0
1
Sale
Captured-on
Register
Manager
1
1
Started-by
1
1
1
1
1
Paid-by
Initiated-by
1
Records-sale-on
Cashier
Payment
Customer
1
1
44
How to identify attributes

• Attributes in a domain model should preferably be
  simple attributes or data types
• Common types boolean, date, number, string,
  text, time
• Other types address, color, geometrics, phone
  number, national insurance number, universal
  product code, postal codes
• Do not relate conceptual classes with an
  attribute!

45
From domain model to requirements

• The use-case model is the primary mechanism in
  the UP to describe requirements
• Contracts is another artifact of the Requirements
  discipline used when a more detailed description
  of system behavior is needed.
• Contracts reflect state changes of objects in the
  Domain Model, after a system operation has
  executed.
• Contracts are initiated during Elaboration
• The goal is to capture important details of the
  system functionality, and to move easily to the
  next step, i.e. the design model.

46
Contract Format
Contract ltcontractNogt ltcontractNamegt
Operation ltoperationNamegt (ltoperationParametersgt)
Cross References Use Cases use case names
where operation can occur Preconditions
noteworthy assumptions about the state of the
system Postconditions state of objects in the
Domain Model after completion of the operation
47
Contract Example
Remember SSDs?
48
Contract Example
Remember SSDs?
49
From requirements and analysis to design
Process Sale
UP Use-case Model
Payment date time
Sale amount
Paid-by
UP Domain Model
1
1
Sale amount getBalance()Money
Payment date Time getTotal()Money
Paid-by
UP Design Model
1
1
50
The Design Model

• Comparing the Design Model to the Domain Model
• they both use the object-oriented paradigm
• the Domain Model describes the problem at hand
  (does the right thing), whereas the Design Model
  designs a good solution for the problem (does
  the thing right)
• the Domain Model provides a static view of
  conceptual classes, whereas the Design Model
  provides both a static and a dynamic view of
  software objects and classes.

The Design Model
51
Main design consideration

• The most important task in the Design Model is to
  assign responsibilities to objects.
• The use cases describe different tasks that must
  be performed in their context. Who is responsible
  for performing these tasks? Are they going to be
  performed by one element (object) or delegated to
  (shared amongst) many elements?
• Responsibilities are obligations of an object in
  terms of its behavior. There are two kinds
• knowing
• doing

52
Object responsibilities

• Doing responsibilities of an object include
• creating an object, doing a calculation,
  initiating action in other objects, coordinating
  activities in other objects
• Knowing responsibilities of an object include
• knowing about private data, about related
  objects, about things it can derive and calculate
• Examples
• A Sale is responsible for creating
  SalesLineItem
• A Sale is responsible for knowing its total

53
Responsibilities and methods

• In general, responsibilities are implemented
  using methods.
• Methods either act alone or collaborate with
  other object methods.
• Depending on its granularity, a responsibility
  may correspond to a single method in a class, or
  it may involve many methods across many classes
  packaged in a subsystem.

54
Design Patterns

• Patterns guide object-oriented developers in the
  creation of software.
• They codify existing tried-and-true knowledge and
  principles the more widely they are used, the
  better.
• Patterns are very simple to use.
• They are applicable in many contexts in fact,
  the notion of a new pattern could be considered
  an oxymoron.
• Patterns provide a formal framework for
  generating good designs gt avoid hand-waving.

55
Examples of design patterns

• The first five GRASP patterns
• The Information Expert pattern suggests that
  responsibilities should be assigned to objects
  that contain relevant information.
• The Creator pattern suggests that the creator of
  an object is usually an object that contains, or
  aggregates it.
• The Low Coupling pattern suggests that
  interdependency between classes should remain
  low.
• The High Cohesion pattern suggests that
  responsibilities of a certain class must be
  highly related.
• The Controller pattern indicates which class will
  handle external system events.

56
Interaction diagrams

• Interaction diagrams are the heart of the Design
  Model
• They illustrate how objects interact via messages
  and collaborate to fulfill the requirements
• They provide a dynamic view to the system
• Many design decisions are taken in the process of
  generating interaction diagrams
• gt their creation requires strong design skills

57
Interaction diagrams

• Two kinds of Interaction diagrams
• Collaboration diagrams
• Sequence diagrams
• Collaboration diagrams illustrate object
  interactions in a graph or network format, where
  objects can be placed anywhere in the diagram.
• Sequence diagrams illustrate object interactions
  in a fence format, in which each new object is
  successively added to the right.

58
Interaction diagrams
Collaboration diagram Sequence
diagram
msg1()
ClassAInstance
ClassAInstance
ClassBInstance
1.msg2()
msg1()
2.msg3()
msg2()
ClassBInstance
msg3()
59
Responsibilities and interaction diagrams

• How do we assign responsibilities (implemented as
  methods) to objects? Interaction diagrams show
  choices in assigning responsibilities.

Sale
makePayment(cashRcvd)
create(cashRcvd)
Payment
It implies Sale objects have a responsibility to
create Payments. This responsibility is invoked
with a makePayment message and handled with a
corresponding makePayment method.
60
From use cases to interaction diagrams

• A use-case realization describes how a particular
  use case scenario is realized within the design
  model, in terms of collaborating objects in
  interaction diagrams.
• Use-case realizations within the UP
• Inception design decisions are premature in this
  phase
• Elaboration Use-case realizations are created
  for the most architecturally significant and
  risky scenarios of the design.
• Construction Use-case realizations are created
  for remaining design.

61
Use-case realizations example 1
Contract C01 makeNewSale Operation
makeNewSale () Cross References Use Cases
Process Sale Preconditions none Postconditions
- A Sale instance s was created - s was
associated with the Register - Attributes of
s were initialized
Register
makeNewSale()
create()
Sale
create()
Sales LineItem
62
Use-case realizations example 2
Contract C02 enterItem Operation enterItem
(itemIDItemID, quantityinteger) Cross
References Use Cases Process
Sale Preconditions There is a sale
underway Postconditions - A SalesLineItem
instance sli was created - sli was
associated with the current Sale -
sli.quantity became quantity - sli was
associated with a ProductSpec
2makeLineItem(spec,qty)
enterItem(it,qty)
Register
Sale
1specgetSpec(id)
2.1create(spec,qty)
2.2add(sl)
1.1specfind(id)
Product Catalog
slSalesLineItem
ProductSpec
SalesLineItem
63
Use-case realizations example 3
Contract C03 endSale Operation endSale
() Cross References Use Cases Process
Sale Preconditions There is a sale
underway Postconditions - Sale.isComplete
became true
endSale()
1.becomeComplete()
Register
Sale
64
Use-case realizations example 4
Contract C04 makePayment Operation
makePayment (amountMoney) Cross References
Use Cases Process Sale Preconditions There
is a sale underway Postconditions - A payment
instance p was created - p.amountTendered
became amount - p was associated with the
current Sale - The current Sale was
associated with the Store (to add it to
historical log of sales)
makePayment(cash)
1.makePayment(cash)
Register
sSale
1.1create(cash)
2.addSale(s)
2.1add(s)
Payment
Store
completedSSale
65
Design Class Diagrams (DCDs)

• DCDs, Design Class Diagrams, provide a static
  view of the Design Model
• DCDs are created in parallel with Interaction
  diagrams
• Example DCD

Sale date time isCompleteBoolean makeLineItem()
Register enterItem()
Captures
1
1
66
Design Class Diagrams (DCDs)

• DCDs illustrate
• Classes and interfaces
• Associations (and navigability)
• Attributes and often their types
• Methods, their parameters, and often parameter
  and method result types
• How are DCDs different from class diagrams of the
  Domain Model?
• How are DCDs different from interaction diagrams?

67
How to generate DCDs

• Identify software classes by looking at the
  Interaction diagrams or the Domain Model class
  diagrams. Some of the classes in the Domain Model
  may be omitted.
• Add attributes based on the attributes of the
  classes in the Domain Model (or the attributes of
  objects in the Interaction diagrams). In the
  Design Model, additional attributes may be added
  (that are not defined in the Domain Model). Types
  of attributes may also be added.
• Add methods by analyzing the Interaction
  diagrams. If a message is sent to an instance of
  a class A, then class A in a DCD must define a
  method with the same name.
• Add associations by drawing inspiration from the
  Domain Model and considering visibility between
  objects

68
Associations in DCDs

• Associations in DCDs are formed based on
  attribute visibility
• Navigability arrows indicate attribute visibility
  from the source to the destination class.
  Attributes pointing to visible objects are
  usually omitted.

Sale date time isCompleteBoolean makeLineItem()
Register currentSaleSale enterItem()
Captures
(Can be omitted)
1
1
69
Mapping design to code

• Implementation model
• Creating class definitions from DCDs
• Container/Collection classes in code
• Order of implementation
• Test-first programming

70
Implementation model

• Interaction diagrams and DCDs input to code
  generation
• The Implementation Model includes
• source code for classes
• database schema
• XML/HTML pages
• etc.
• Writing code in an OO programming language (like
  Java) is not considered part of OOA/D
• Most of the creative work took place during
  OOA/D. Transition to implementation is mostly
  mechanical
• Expect deviations from the design during
  programming

71
Code changes and the iterative model
Iterative Cycles of Development
Requirements Analysis
Requirements Analysis
Design
Design
Implementation
Implementation
Time
72
Creating class definitions from DCDs

• Straightforward mapping of attribute definitions
  and method signatures. Dont forget to add
  constructors.

ProductSpec descriptionText priceMoney itemIDIt
emID
SalesLineItem quantityInteger getSubtotal()Mon
ey
Described-by
1

public class SalesLineItem private int
quantity public SalesLineItem(ProductSpec
spec, int qty) public Money getSubtotal()

73
Reference attributes

• A reference attribute is an attribute that refers
  to another object, not to a primitive type such
  as String, Number and so on.

ProductSpec descriptionText priceMoney itemIDIt
emID
SalesLineItem quantityInteger getSubtotal()Mon
ey
Described-by
1

productSpec
public class SalesLineItem private int
quantity private ProductSpec productSpec publi
c SalesLineItem(ProductSpec spec, int qty)
public Money getSubtotal()
74
Creating methods from interaction dgrms

• An interaction diagram shows messages sent in
  response to a method invocation. These are
  translated to code in this method.

enterItem(id,qty)
2makeLineItem(spec,qty)
Register
Sale
1specgetSpecification(id)
Product Catalog
public void enterItem (ItemID id, int
qty) ProductSpec spec catalog.getSpecificatio
n(id) sale.makeLineItem (spec, qty)
75
Collection attributes

• Visibility to a group of objects in DCDs is often
  translated to a collection attribute in the
  Implementation Model.

Sale
SalesLineItem
Contains
1..
1
public class Sale private List lineItems
new ArrayList()
76
Order of class implementation

• The order of implementing classes depends on
  their dependencies. One possible order for the
  example below is

Sale
Register
SalesLineItem
Captures
Contains
5
4
3
1
1
1..
1
1

Looks-in
Described-by
1
1
ProductCatalog
ProductSpec
Contains
1
2
1..
1
77
Test-first programming

• Unit testing code is written before the code to
  be tested.
• Example

public class SaleTest extends TestCase
// public void testTotal() // set up the
test Money total new Money ( 7.5 ) Money
price new Money ( 2.5 ) ItemID id new
ItemID ( 1 ) ProductSpec spec new
ProductSpec ( id, price, prod 1 ) Sale sale
new Sale () // add the items sale.makeLineI
tem ( spec, 1 ) sale.makeLineItem ( spec, 2
) // verify the total is 7.5 assertEquals (
sale.getTotal(), total )
78
Refine requir., analysis, design and implem.
79
Summary of lecture 8

• The Unified Process has 4 phases.
• In most phases we work on all disciplines, e.g.
  requirements, domain model, design model and
  implementation.
• The emphasis placed on each discipline depends on
  the phase inception favors requirements
  analysis, etc.
• The object-oriented paradigm is used in the
  disciplines of domain analysis and design, and
  potentially at the implementation level