60-322 Object-Oriented Analysis and Design Feb 4, 2009

1

60-322 Object-Oriented Analysis and Design

Feb 4, 2009

2

enterItem(itemID, quantity)

:System: Cashier

endSale

makePayment(amount)

a UML loop interaction frame, with a boolean guard expression

external actor to system

Process Sale Scenario

system as black box

the name could be "NextGenPOS" but "System" keeps it simple

the ":" and underline imply an instance, and are explained in a later chapter on sequence diagram notation in the UML

a message with parameters

it is an abstraction representing the system event of entering the payment data by some mechanism

description, total

return value(s) associated with the previous message

an abstraction that ignores presentation and medium

the return line is optional if nothing is returned

total with taxes

change due, receipt

makeNewSale

[ more items ]loop

3

An SSD shows system events for one scenario of a use case, therefore it is generated from inspection of a use case.

SSD vs. use cases

: Cashier :System

Simple cash-only Process Sale scenario:

1. Customer arrives at a POS checkout with goods and/or services 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 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....


endSale

makePayment(amount)

description, total

total with taxes

change due, receipt

makeNewSale

[ more items ]loop


4

Don't create SSDs for all scenarios. Rather, draw them only for the scenarios chosen for the next iteration.

And, they shouldn't take long to sketch - perhaps a few minutes or a half hour.

SSDs are also very useful when you want to understand the interface and collaborations of existing systems, or to document the architecture.

SSDs are part of the Use-Case Model - a visualization of the interactions implied in the scenarios of use cases.

SSDs are an example of the many possible skillful and widely used analysis and design artifacts or activities that the UP documents do not mention.

But the UP, being very flexible, encourages the inclusion of any and all artifacts and practices that add value.

Put SSD into Perspective

5

Inception

– SSDs are not usually motivated in inception, unless you are doing rough estimating (don't expect inception estimating to be reliable) involving a technique that is based on identifying system operations.

Elaboration

– Most SSDs are created during elaboration, when it is useful to identify the details of the system events to clarify what major operations the system must be designed to handle, write system operation contracts, and possibly to support estimation.

What is this opeation contract?

Put SSD into Perspective

6

Ch 11. Operation Contracts

This chapter is naturally related to SSD.

It first tells how to identifying system operations.

Then create Operation Contracts for the System Operations.

What? Why ? How ?

Stay tuned.

7


Use cases or system features are the main ways in the UP to describe system behavior, and are usually sufficient.

Sometimes a more detailed or precise description of system behavior has value.

Operation contracts use a pre- and post-condition form to describe detailed changes to objects in a domain model, as the result of a system operation.

A domain model is the most common OOA model, but operation contracts and state models (Ch 29) can also be useful OOA-related artifacts.

8


Operation: enterItem(…)

Post-conditions:- . . .

Operation Contracts

Sale

date. . .

SalesLineItem

quantity

1..*1 . . .

. . .

Domain Model

Use-Case Model

Design Model: Register


: ProductCatalog

spec = getProductSpec( itemID )

addLineItem( spec, quantity )

: Sale

Require-ments

Business Modeling

Design

Sample UP Artifact Relationships

: System

enterItem(id, quantity)

Use Case Text

System Sequence Diagrams

makeNewSale()

system events

Cashier

Process Sale

: Cashier

use case

names

system operations

Use Case Diagram

Vision

SupplementarySpecification

Glossary

starting events to design for, and more detailed requirements that must be satisfied by the software

Process Sale

1. Customer arrives ...2. ...3. Cashier enters item identifier.

the domain objects, attributes, and associations that undergo changes

requirements that must be satisfied by the software

ideas for the post-conditions

Operation contracts may be considered part of the UP Use-Case Model because they provide more analysis detail on the effect of the system operations implied in the use cases.

The prime inputs to the contracts are:a) the system operations identified in SSDs (such as enterItem),b) the domain model, and c) domain insight from experts.

The contracts can in turn serve as input to the object design, as they describe changes that are likely required in the software objects or database.

9

Example

10

Example

11

System Operation

Operation contracts may be defined for system operations - operations that the system as a black box component offers in its public interface.

System operations can be identified while sketching SSDs.

To be more precise, the SSDs show system events - events or I/O messages relative to the system.

Input system events imply the system has system operations to handle the events, just as an OO message (a kind of event or signal) is handled by an OO method (a kind of operation).

12

System Operation

The entire set of system operations, across all use cases, defines the public system interface, viewing the system as a single component or class.

In the UML, the system as a whole can be represented as one object of a class named (for example) System.

: Cashier


endSale()

makePayment(amount)

description, total

total with taxes

change due, receipt

makeNewSale()

these input system events invoke system operations

the system event enterItem invokes a system operation called enterItem and so forth

this is the same as in object-oriented programming when we say the message foo invokes the method (handling operation) foo

[ more items ]loop

:System


13

Postconditions

The postconditions describe changes in the state of objects in the domain model. Domain model state changes include

– instances created/deleted – associations formed or broken, and – attributes changed.

Postconditions are not actions to be performed during the operation; rather, they are observations about the domain model objects that are true when the operation has finished after the smoke has cleared.

To summarize, the postconditions fall into these categories:– Instance creation and deletion.– Attribute change of value.– Associations formed and broken.

14

Postconditions

These postconditions are expressed in the context of the Domain Model objects. We just finished domain model.

– What instances can be created?– those from the Domain Model.

– What associations can be formed?– those in the Domain Model; and so on.

15

Why Postconditions?

First, they aren't always necessary. Most often, the effect of a system operation is relatively clear to the developers by virtue of reading the use case, talking with experts, or their own knowledge.

But sometimes more detail and precision is useful. Contracts offer that.

It is also possible to express this level of detail in the use cases, but undesirable - they would be too verbose and low-level detailed.

A contract is an excellent tool of requirements analysis or OOA that describes in great detail the changes required by a system operation (in terms of the domain model objects) without having to describe how they are to be achieved.

16

Guideline: How to Write a Postcondition?

Express postconditions in the past tense to emphasize they are observations about state changes that arose from an operation, not an action to happen. That's why they are called postconditions!

For example:– (better) A SalesLineItem was created.

rather than– (worse) Create a SalesLineItem, or, A SalesLineItem is

created.

17

Guideline:How Complete Should Postconditions Be?

Generating a complete and detailed set of postconditions for all system operations is not likely or necessary.

In the spirit of Agile Modeling, treat their creation as an initial best guess, with the understanding they will not be complete and that "perfect" complete specifications are rarely possible or believable.

But understanding that light analysis is realistic and skillful doesn't mean to abandon a little investigation before programming that's the other extreme of misunderstanding.

18

Example: enterItem Postconditions

This example dissects the motivation for the postconditions of the enterItem system operation.

Register

id

ItemStore

nameaddress

Sale

dateTime/ total

CashPayment

amountTendered

SalesLineItem

quantity

Cashier

id

Customer

ProductCatalog

ProductDescription

itemIDdescriptionprice

Stocks

*

Houses

1..*

Used-by

*

Contains

1..*

Describes

*

Captured-on

Contained-in

1..*

Records-sale-of

0..1

Paid-by Is-for

Logs-completed

*

Works-on

1

1

1

1 1..*

1

1

1

1

1

1

1

0..1 1

1

Ledger

Records-accounts-

for

1

1

19


This example dissects the motivation for the postconditions of the enterItem system operation.

Instance Creation and Deletion– After the itemID and quantity of an item have been

entered, what new object should have been created? A SalesLineItem. Thus: A SalesLineItem instance sli was created (instance creation). Note the naming of the instance. This name will simplify

references to the new instance in other post-condition statements.

20


Attribute Modification– After the itemID and quantity of an item have

been entered by the cashier, what attributes of new or existing objects should have been modified?

The quantity of the SalesLineItem should have become equal to the quantity parameter. Thus:

sli.quantity became quantity (attribute modification).

21


Associations Formed and Broken– After the itemID and quantity of an item have been

entered by the cashier, what associations between new or existing objects should have been formed or broken?

– The new SalesLineItem should have been related to its Sale, and related to its ProductDescription. Thus:

sli was associated with the current Sale (association formed).

sli was associated with a ProductDescription, based on itemID match (association formed).

22

Updating Domain Model? It's common during the creation of the contracts to discover

the need to record new conceptual classes, attributes, or associations in the domain model.

Do not be limited to the prior definition of the domain model; enhance it as you make new discoveries while thinking through operation contracts.

In iterative and evolutionary methods (and reflecting the reality of software projects), all analysis and design artifacts are considered partial and imperfect, and evolve in response to new discoveries.

Yes, update your domain accordingly.

23

Guideline: When Are Contracts Useful?

In the UP, the use cases are the main repository of requirements for the project.

They may provide most or all of the detail necessary to know what to do in the design, in which case, contracts are not helpful.

However, there are situations where the details and complexity of required state changes are awkward or too detailed to capture in use cases.

24


For example, consider an airline reservation system and the system operation addNewReservation. The complexity is very high regarding all the domain objects that must be changed, created, and associated.

These fine-grained details can be written up in the use case, but it will make it extremely detailed (for example, noting each attribute in all the objects that must change).

Observe that the postcondition format offers and encourages a very precise, analytical language that supports detailed thoroughness.

25


If developers can comfortably understand what to do without them, then avoid writing contracts.

This case study shows more contracts than are necessary - for education.

In practice, most of the details they record are obviously inferable from the use case text. On the other hand, "obvious" is a slippery concept!

26

Guideline: How to Create and Write Contracts

Apply the following advice to create contracts:– Identify system operations from the SSDs.

– For system operations that are complex and perhaps subtle in their results, or which are not clear in the use case, construct a contract.

– To describe the postconditions, use the following categories:

instance creation and deletion attribute modification associations formed and broken

27


Writing Contracts– As mentioned, write the postconditions in a declarative, passive

past tense form (was …) to emphasize the observation of a change rather than a design of how it is going to be achieved. For example:

(better) A SalesLineItem was created. (worse) Create a SalesLineItem.

– Remember to establish an association between existing objects or those newly created.

For example, it is not enough that a new SalesLineItem instance is created when the enterItem operation occurs. After the operation is complete, it should also be true that the newly created instance was associated with Sale; thus:The SalesLineItem was associated with the Sale (association formed).

28


What's the Most Common Mistake?

– The most common problem is forgetting to include the forming of associations. Particularly when new instances are created, it is very likely that associations to several objects need be established. Don't forget!

29

Example: System Operations of the Process Sale Use Case

Note the vague description in the last postcondition. If understandable, it's fine. On a project, all these particular postconditions are so obvious from the use

case that the makeNewSale contract should probably not be written. Recall one of the guiding principles of healthy process and the UP: Keep it as

light as possible, and avoid all artifacts unless they really add value.


:System: Cashier

endSale

makePayment(amount)

a UML loop interaction frame, with a boolean guard expression

external actor to system


system as black box

the name could be "NextGenPOS" but "System" keeps it simple

the ":" and underline imply an instance, and are explained in a later chapter on sequence diagram notation in the UML

a message with parameters

it is an abstraction representing the system event of entering the payment data by some mechanism

description, total

return value(s) associated with the previous message

an abstraction that ignores presentation and medium

the return line is optional if nothing is returned

total with taxes

change due, receipt

makeNewSale

[ more items ]loop

30


31


32

Updating the POS Domain Model

There is at least one point suggested by these contracts that is not yet represented in the domain model: completion of item entry to the sale.

The endSale specification modifies it, and it is probably a good idea later during design work for the makePayment operation to test it, to disallow payments until a sale is complete (meaning, no more items to add).

One way to represent this information is with an isComplete attribute in the Sale:

33

Updating the POS Domain Model

34

Put the Contract into perspective

Inception – Contracts are not motivated during inception -

they are too detailed.Elaboration

– If used at all, most contracts will be written during elaboration, when most use cases are written. Only write contracts for the most complex and subtle system operations.

35

Recall that we are in the iterations of elaboration phase.

We’ve done:– Use cases (ch 6)– Other requirements (what are they?) (Ch 7)– Domain Model (Ch 9)– SSD (Ch 10)– Operation Contracts (Ch11)

What we’ve done are OOA.

We will now be transiting to OOD.

Ch.12 Requirements To Design - Iteratively

36

The case studies have emphasized analysis of the requirements.

If following the UP guidelines, perhaps 10% of the requirements were investigated in inception, and a slightly deeper investigation was started in this first iteration of elaboration.

The following chapters are a shift in emphasis toward designing a solution for this iteration in

terms of collaborating software objects.


37

The requirements and object-oriented analysis covered so far has focused on learning to do the right thing; that is, understanding some of the outstanding goals for the case studies, and related rules and constraints.

By contrast, the following design work will stress do the thing right; that is, skillfully designing a solution to satisfy the requirements for this iteration


38

In iterative development, a transition from primarily a requirements or analysis focus to primarily a design and implementation focus will occur in each iteration.

Early iterations will spend relatively more time on analysis activities.

In later iterations it is common that analysis lessens; there's more focus on just building the solution.


39

It is natural and healthy to discover and change some requirements during the design and implementation work, especially in the early iterations.

Iterative and evolutionary methods "embrace change“ although we try to provoke that inevitable change in early iterations,

so that we have a more stable goal (and estimate and schedule) for the later iterations.

Early programming, tests, and demos help provoke the inevitable changes early on.

This sounds a simple idea, yes, it lies at the heart of why iterative development works.


40

Over the course of these early elaboration iterations, the requirements discovery should stabilize, so that by the end of elaboration, perhaps 80% of the requirements are reliably defined - defined and refined as a result of feedback, early programming and testing, rather than speculation, as occurs in a waterfall method.

When one is comfortable with the skills of use case writing, domain modeling, and so forth, the duration to do all the actual modeling that has been explored so far is realistically just a few hours or days.


41

I thought we are on the road to OOD.

Why suddenly to discuss logical architecture, and UML.

Suppose If you participated in this project of NextGen POS and are given all the artifacts of the case studies obtained so far,

Are you going to do programming right away?

Ch.13 Logical Architecture and UML Package Diagram

42

You could, but the experiences tell us that we need a big picture of the software that we are developing before you do the actual programming.

Logical architecture addressed this big pictures.

So let’s start with the large-scale big picture of the software under development.


43

At this level, the design of a typical OO system is based on several architectural layers, such as – a UI layer, – an application logic (or "domain") layer, and – so forth.

This chapter briefly explores a logical layered architecture and related UML notation.


44


: Register


: ProductCatalog

spec = getProductSpec( itemID )

Require-ments

Business Modeling

Design

Sample UP Artifact Relationships

Vision Glossary

The logical architecture is influenced by the constraints and non-functional requirements captured in the Supp. Spec.

Domain Model

**

SupplementarySpecification

Use-Case Model

Register

...

makeNewSale()enterItem(...)...

ProductCatalog

...

getProductSpec(...)...

1 1class diagrams(a static view)

interaction diagrams(a dynamic view)

UIpackage diagramsof the logical architecture(a static view) Domain

Tech Services

Design Model

45


Domain

UI

Swingnot the Java Swing libraries, but our GUI classes based on Swing

Web

Sales Payments Taxes

Technical Services

Persistence Logging RulesEngine

A partial layered, logical architecture drawn in UML package diagram

46

The logical architecture is the large-scale organization of the software classes into packages (or namespaces), subsystems, and layers.

It's called the logical architecture because there's no decision about how these elements are deployed across different operating system processes or across physical computers in a network (these latter decisions are part of the deployment architecture).

Ch.13 What is logical architecture?

47

A layer is a very coarse-grained grouping of classes, packages, or subsystems that has cohesive responsibility for a major aspect of the system.

Also, layers are organized such that "higher" layers (such as the UI layer) call upon services of "lower" layers, but not normally vice versa. Typically layers in an OO system include:

– User Interface.– Application Logic and Domain Objects

– software objects representing domain concepts (for example, a software class Sale) that fulfill application requirements, such as calculating a sale total.

– Technical Services – general purpose objects and subsystems that provide supporting technical

services, such as interfacing with a database or error logging. These services are usually application-independent and reusable across several systems.


48

In a strict layered architecture, a layer only calls upon the services of the layer directly below it.

This design is common in network protocol stacks.

But in information systems, it usually has a relaxed layered architecture, in which a higher layer calls upon several lower layers.

For example, the UI layer may call upon its directly subordinate application logic layer, and also upon elements of a lower technical service layer, for logging and so forth.

A logical architecture doesn't have to be organized in layers. But it's very common, and hence, introduced at this time.


49

Although OO technology can be applied at all levels, this introduction to OOA/D focuses on the core application logic (or "domain") layer, with some secondary discussion of the other layers.

Exploring design of the other layers (such as the UI layer) will focus on the design of their interface to the application logic layer.

The other layers tend to be very technology dependent (for

example, very specific to Java or .NET),

The OO design lessons learned in the context of the application logic (domain) layer are applicable to all other layers or components.

Ch.13 Our focus in the logical architecture

50

UML package diagrams are often used to illustrate the logical architecture of a system - the layers, subsystems, packages (in the Java sense), etc.

A layer can be modeled as a UML package; for example, the UI layer modeled as a package named UI.

Ch.13 UML Package Diagram

51


Domain

UI

Swingnot the Java Swing libraries, but our GUI classes based on Swing

Web

Sales Payments Taxes

Technical Services

Persistence Logging RulesEngine

A partial layered, logical architecture drawn in UML package diagram

52

A UML package diagram provides a way to group elements.

A UML package can group anything: classes, other packages, use cases, and so on.

Nesting packages is very common.

A UML package is a more general concept than simply a Java package or .NET namespace, though a UML package can represent those and more.

Ch.13 UML Package Diagram- Some comments

53

It is common to want to show dependency (a coupling) between packages so that developers can see the large-scale coupling in the system.

The UML dependency line is used for this, a dashed arrowed line with the arrow pointing towards the depended-on package.

A UML package represents a namespace so that, for example, a Date class may be defined in two packages.

– If you need to provide fully-qualified names, the UML notation is, for example, java::util::Date in the case that there was an outer package named "java" with a nested package named "util" with a Date class.

Ch.13 UML Package Diagram- Some comments

54

The UML provides alternate notations to illustrate outer and inner nested packages. Sometimes it is awkward to draw an outer package box around inner packages. Alternatives are:

Ch.13 UML Package Diagram -Some comments

Domain::Sales

UI::WebUI::Swing

Sales

WebSwing

UI

Domain

DomainUI

Swing SalesWeb

Alternate UML approaches to show package nesting, using embedded packages, UML fully-qualified names, and the circle-cross symbol.

55


56

The purpose and number of layers varies across applications and application domains (information systems, operating systems, and so forth).

Applied to information systems, typical layers are illustrated and explained in the following Figure.

Ch.13 Design With Layers

57

UI(AKA Presentation, View)

Application(AKA Workflow, Process,Mediation, App Controller)

Domain(AKA Business,

Application Logic, Model)

Technical Services(AKA Technical Infrastructure, High-level Technical Services)

Foundation(AKA Core Services, Base Services,

Low-level Technical Services/Infrastructure)

width implies range of applicability

· GUI windows· reports· speech interface· HTML, XML, XSLT, JSP, Javascript, ...

· handles presentation layer requests· workflow· session state· window/page transitions· consolidation/transformation of disparate

data for presentation

· handles application layer requests· implementation of domain rules· domain services (POS, Inventory)

- services may be used by just one application, but there is also the possibility of multi-application services

· (relatively) high-level technical services and frameworks

· Persistence, Security

· low-level technical services, utilities, and frameworks

· data structures, threads, math, file, DB, and network I/O

moreapp

specific

dependency

Business Infrastructure(AKA Low-level Business Services)

· very general low-level business services used in many business domains

· CurrencyConverter

58

In general, there is a separation of concerns, a separation of high from low-level services, and of application-specific from general services.

– This reduces coupling and dependencies, improves cohesion, increases reuse potential, and increases clarity.

Related complexity is encapsulated and decomposable. Some layers can be replaced with new implementations.

– This is generally not possible for lower-level Technical Service or Foundation layers (e.g., java.util), but may be possible for UI, Application, and Domain layers.

Lower layers contain reusable functions.

Some layers (primarily the Domain and Technical Services) can be distributed.

Development by teams is aided because of the logical segmentation.

Ch.13 Benefits of Using Layers

59

Guideline:The responsibilities of the objects in a layer should be strongly related to each other and should not be mixed with responsibilities of other layers.

For example, objects in the UI layer should focus on UI work, such as creating windows and widgets, capturing mouse and keyboard events, and so forth.

Objects in the application logic or "domain" layer should focus on application logic, such as calculating a sales total or taxes, or moving a piece on a game board.

UI objects should not do application logic. For example, a Java Swing JFrame (window) object should NOT

contain logic to calculate taxes or move a game piece. Application logic classes should not trap UI mouse or keyboard

events. – That would violate a clear separation of concerns and

maintaining high cohesion - basic architectural principles.

Cohesive Responsibilities; Maintain a Separation of Concerns

60

A typical software system has UI logic and application logic, such as GUI widget creation and tax calculations. Now, here's a key question:– How do we design the application logic with

objects?

We could create one class called XYZ and put all the methods, for all the required logic, in that one class. It could technically work (though be a nightmare to understand and maintain), but it isn't the recommended approach in the spirit of OO thinking.

Definition: Domain Layer vs. Application Logic Layer; Domain Objects – confusing terms?!

61

So, what is the recommended approach?

Answer:

To create software objects with names and information similar to the real-world domain, and assign application logic responsibilities to them.


62

For example, in the real world of POS, there are sales and payments. So, in software, we create a Sale and Payment class, and give them application logic responsibilities.

This kind of software object is called a domain object.

It represents a thing in the problem domain space, and has related application or business logic, for example, a Sale object being able to calculate its total.

Designing objects this way leads to the application logic layer being more accurately called the domain layer of the architecture - the layer that contains domain objects to handle application logic work.


Documents

60-322 Object-Oriented Analysis and Design Feb 4, 2009