60-322 object-oriented analysis and design jan 26, 2009

60-322 Object-Oriented Analysis and Design

Jan 26, 2009

Jan 26, 2009 2

Ch 7 Glossary

Jan 26, 2009 3

In its simplest form, the Glossary is a list of noteworthy terms and their definitions.

It is surprisingly common that a term, often technical or particular to the domain, will be used in slightly different ways by different stakeholders;

This needs to be resolved to reduce problems in communication and ambiguous requirements.

Guideline– Start the Glossary early. It will quickly become a useful

repository of detailed information related to fine-grained elements.

Ch 7 Glossary

Jan 26, 2009 4

In the UP, the Glossary also plays the role of a data dictionary, a document that records data about the data, that is, metadata.

During inception the glossary should be a simple document of terms and descriptions.

During elaboration, it may expand into a data dictionary.

Ch 7 Glossary

Jan 26, 2009 5

The Glossary is not only for atomic terms such as "product price."

It can and should include composite elements such as "sale" (which includes other elements, such as date and location) and nicknames used to describe a collection of data transmitted between actors in the use cases.

For example, in the Process Sale use case, consider the following statement:

– System sends payment authorization request to an external Payment Authorization Service, and requests payment approval.

"Payment authorization request" is a nickname for an aggregate of data, which needs to be explained in the Glossary.

Ch 7 Glossary

Jan 26, 2009 6

Ch 7 Business Rules (Domain Rules)

Jan 26, 2009 7

So what are domain rules?

Domain rules dictate how a domain or business may operate.

They are not requirements of any one application, although an application's requirements are often influenced by domain rules.

Company policies, physical laws (such as how oil flows underground), and government laws are common domain rules.


Jan 26, 2009 8

They are also called business rules, which is the most common type.

It's useful to identify and record domain rules in a separate application-independent artifact - what the UP calls the Business Rules artifact.

So that this analysis can be shared and reused across the organization and across projects, rather than buried within a project-specific document.


Jan 26, 2009 9

The rules can help clarify ambiguities in the use cases, which emphasize the flow of the story rather than the details.

– For example, in the NextGen POS, if someone asks if the Process Sale use case should be written with an alternative to allow credit payments without signature capture, there is a business rule (RULE1) that clarifies whether this will not be allowed by any credit authorization company.


Jan 26, 2009 10

Put all these other requirements into perspective

Ch 7 Other Requirements

Jan 26, 2009 11


During Inception– the Vision summarizes the project idea in a form to help decision

makers determine if it is worth continuing, and where to start.

Since most requirements analysis occurs during elaboration, the Supplementary Specification should be only lightly developed during inception, highlighting noteworthy quality attributes that expose major risks and challenges

– for example, the NextGen POS must have recoverability when external services fail.

Input into these artifacts could be generated during an inception phase requirements workshop.

Jan 26, 2009 12


During Elaboration

– Through the elaboration iterations, the "vision" and the Vision are refined, based upon feedback from incrementally building parts of the system, adapting, and multiple requirements workshops held over several development iterations.

Jan 26, 2009 13

Ch 7 Other Requirements During Elaboration

– By the end of elaboration, it is feasible to have use cases, a Supplementary Specification, and a Vision that reasonably reflects the stabilized major features and other requirements to be completed for delivery.

– Nevertheless, the Supplementary Specification and Vision are not something to freeze and "sign off" on as a fixed specification.

– Adaptation - not rigidity - is a core value of iterative development and the UP.

Jan 26, 2009 14


– As software professional, you understand the importance of iterative, evolutionary,…., they all means things are not fixed.

– From a business perspective, this is definitely not a good news for any business.

Jan 26, 2009 15


– It is perfectly sensible - at the end of elaboration - to form an agreement with stakeholders about what will be done in the remainder of the project, and to make commitments (perhaps contractual) regarding requirements and schedule.

– At some point (the end of elaboration, in the UP), we need a reliable idea of "what, how much, and when."

– In that sense, a formal agreement on the requirements is normal and expected.

– It is also necessary to have a change control process (one of the explicit best practices in the UP) for formally considered and approved requirements changes, rather than chaotic and

uncontrolled change.

Jan 26, 2009 16


– In iterative development and the UP it is understood that no matter how much due diligence is given to requirements specification, some change is inevitable, and should be acceptable.

– In iterative development, it is a core value to have continual engagement by the stakeholders to evaluate, provide feedback, and steer the project as they really want it.

– It does not benefit stakeholders to "wash their hands" of attentive engagement by signing off on a frozen set of requirements and waiting for the finished product, because they will seldom get what they really needed.

Jan 26, 2009 17

Ch 7 Other Requirements During Construction

– By construction, the major requirements- both functional and otherwise-should be stabilized- not finalized, but settled down to minor perturbation.

– Therefore, the Supplementary Specification and Vision are unlikely to experience much change in this phase.

Jan 26, 2009 18

We are at Ch. 8.

The Chapter title is “Iteration 1 – Basics”

What iteration and where is the iteration?

Note Ch 8 is the first chapter in Part III of the book.

Part III: Elaboration Iteration 1 – Basics

This is where we are.

What do we do in this part and this chapter?

Ch 8 Iteration 1- Basics

Jan 26, 2009 19

Ch. 8 will– Define the first iteration in the elaboration

phase.

– Motivate the following chapters in this section.

– Describe key inception and elaboration phase concepts.

– Summarize the iteration 1 requirements of the case studies.

Ch 8 Iteration 1- Basics

Jan 26, 2009 20

Iteration-1 of the elaboration phase emphasizes a range of fundamental and common OOA/D skills used in building object systems.

Many other skills and steps, such as database design, usability engineering, and UI design, are of course needed to build software,

But they are out of scope in this introduction focusing on OOA/D and applying the UML.

Ch 8 Iteration 1 Requirements and Emphasis: Core OOA/D Skills

Jan 26, 2009 21

Book Iterations vs. Real Project Iterations– Iteration-1 of the case studies in this book is driven

by learning goals rather than true project goals.

– Therefore, iteration-1 is not architecture-centric or risk-driven.

– On a UP project, one would tackle difficult, risky things first.

– But in the context of a book helping people learn fundamental OOA/D and UML, we want to start with easier topics.


Jan 26, 2009 22

The requirements for the first iteration of the NextGen POS application follow:– Implement a basic, key scenario of the Process Sale

use case: entering items and receiving a cash payment.

– Implement a Start Up use case as necessary to support the initialization needs of the iteration.

– Nothing fancy or complex is handled, just a simple happy path scenario, and the design and implementation to support it.

– There is no collaboration with external services, such as a tax calculator or product database.

– No complex pricing rules are applied.


Jan 26, 2009 23

The requirements for the first iteration of the Monopoly application follow:

– Implement a basic, key scenario of the Play Monopoly Game use case: players moving around the squares of the board.

– Implement a Start Up use case as necessary to support the initialization needs of the iteration.

– Two to eight players can play.

– A game is played as a series of rounds. During a round, each player takes one turn. In each turn, a player advances his piece clockwise around the board a number of squares equal to the sum of the number rolled on two six-sided dice.

– Play the game for only 20 rounds.


Jan 26, 2009 24

The requirements for the first iteration of the Monopoly application follow:

– After the dice are rolled, the name of the player and the roll are displayed. When the player moves and lands on a square, the name of the player and the name of the square that the player landed on are displayed.

– In iteration-1 there is no money, no winner or loser, no properties to buy or rent to pay, and no special squares of any kind.

– Each square has a name. Every player begins the game with their piece located on the square named "Go." The square names will be Go, Square 1, Square 2, … Square 39

– Run the game as a simulation requiring no user input, other than the number of players.

Subsequent iterations will grow on these foundations.


Jan 26, 2009 25

Use cases - Guidelines

Jan 26, 2009 26

That seems a lot of work to do in iteration 1.

But remember,

– In Iterative Development We Don't Implement All the Requirements at Once.

These requirements for iteration-1 are subsets of the complete requirements or use cases.

– For example, the NextGen POS iteration-1 requirements are a simplified version of the complete Process Sale use case; they describe one simple cash-only scenario.


Jan 26, 2009 27

This is a key understanding in iterative lifecycle methods .

We start production-quality programming and testing for a subset of the requirements, and

We start that development before all the requirements analysis is complete, in contrast to a waterfall process.

After all, this is UP, an Iterative, evolutionary approach.


Jan 26, 2009 28

Note also that we haven't done all the requirements analysis for the NextGen POS system.

We've only analyzed the Process Sale use case in detail; many others are not yet analyzed.

There will be lots of , lots of work to do,

Don’ t complain


Jan 26, 2009 29


It is common to work on varying scenarios of the same use case over several iterations and gradually extend the system to ultimately handle all the functionality required . On the other hand, short, simple use cases may be completed within one iteration.

Jan 26, 2009 30

In UP terms and our case studies, imagine we have finished the inception phase and are entering the elaboration phase.

Let’s take stock.

What happened in Inception?

From inception to Elaboration

Jan 26, 2009 31

Some likely activities and artifacts in inception include:– a short requirements workshop

– most actors, goals, and use cases named

– most use cases written in brief format; 10-20% of the use cases are written in fully dressed detail to improve understanding of the scope and complexity

– most influential and risky quality requirements identified

– version one of the Vision and Supplementary Specification written


Jan 26, 2009 32

Some likely activities and artifacts in inception include:– risk list

– technical proof-of-concept prototypes and other investigations to explore the technical feasibility of special requirements ("Does Java Swing work properly on touch-screen displays?")

– user interface-oriented prototypes to clarify the vision of functional requirements


Jan 26, 2009 33

Some likely activities and artifacts in inception include:– recommendations on what components to

buy/build/reuse, to be refined in elaboration– For example, a recommendation to buy a tax calculation package.

– high-level candidate architecture and components proposed

– This is not a detailed architectural description, and it is not meant to be final or correct. Rather, it is brief speculation to use as a starting point of investigation in elaboration. For example, "A Java client-side application, no application server, Oracle for the database, …" In elaboration, it may be proven worthy, or discovered to be a poor idea and rejected.

– plan for the first iteration– candidate tools list


Jan 26, 2009 34

Elaboration is the initial series of iterations during which, on a normal project:

the core, risky software architecture is programmed and tested

the majority of requirements are discovered and stabilized

the major risks are mitigated or retired


Jan 26, 2009 35

Serious investigation, implementation, testing, etc happen in this phase, in contrast to inception phase.

Elaboration often consists of two or more iterations.

Each iteration is recommended to be between two and six weeks; prefer the shorter versions unless the team size is massive.

Each iteration is timeboxed.


Jan 26, 2009 36

CAUTION:– Elaboration is not a design phase (such as in

waterfall) or a phase when the models are fully developed in preparation for implementation in the construction step,

Do not superimpose waterfall ideas on iterative development and the UP.

The production quality programming and its output is not discardable, it is part of your final system to be delivered to customer.


Jan 26, 2009 37

Elaboration in one sentence:– Build the core architecture, resolve the high-risk elements,

define most requirements, and estimate the overall schedule and resources.

Some key ideas and best practices in elaboration: – do short timeboxed risk-driven iterations– start programming early– adaptively design, implement, and test the core and risky parts

of the architecture– test early, often, realistically– adapt based on feedback from tests, users, developers– write most of the use cases and other requirements in detail,

through a series of workshops, once per elaboration iteration


Jan 26, 2009 38

Artifacts produced in Elaboratoin

Our next topic in Ch. 9

Jan 26, 2009 39

What is domain model?

A domain model is the most important and classic model in OO analysis.

It illustrates noteworthy concepts in a domain.

It can act as a source of inspiration for designing some software objects and will be an input to several artifacts explored in the case studies.

Ch.9 Domain Model

Jan 26, 2009 40

In this chapter,

– Identify conceptual classes related to the current iteration.

– Create an initial domain model.

– Model appropriate attributes and associations.

– Useful modeling guidelines

Ch.9 Domain Model

Jan 26, 2009 41

Ch.9 Domain Model

The model can in turn

influence operation

contracts, a glossary, and

the Design Model,

Process Sale

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

Use Case Text

Operation : enterItem (…)

Post -conditions :- . . .

Operation Contracts

Sale

date. . .

SalesLineItem

quantity

1..*1 . . .

. . .

the domain objects , attributes , and associations that undergo state changes

Domain Model

Use -Case Model

Design Model

: Register

enterItem(itemID , quantity )

: ProductCatalog

spec = getProductSpec ( itemID )

addLineItem ( spec , quantity )

: Sale

. . .

conceptual classes in the domain inspire the names of some software classes in the design

conceptual classes –terms , concepts attributes , associations

Cashier : …Item ID : …...

Glossary

elaboration of some terms in the domain model

Require -ments

Business Modeling

Design

Sample UP Artifact Relationships

The related use case

concepts and insight of

experts will be input to

domain mode.

Jan 26, 2009 42

Ch.9 Domain Model (in UML notation)

Register

Item

Store

addressname

Sale

date time

Payment

amount

SalesLineItem

quantity

Stocked-in

*

Houses

1..*

Contained-in

1..*

Records-sale-of

0..1

Paid-by

1

1

1

1

1

1

0..1

1

Captured-on

conceptor domain object

association

attributes

a partial domain model drawn with UML class diagram notation. It illustrates that the conceptual classes of Payment and Sale are significant in this domain, that a Payment is related to a Sale in a way that is meaningful to note, and that a Sale has a date and time, information attributes we care about.

Jan 26, 2009 43

So where do you get information to draw that diagram?

What information?

Identifying a rich set of conceptual classes is at the heart of OO analysis.

If it is done with skill and short time investment (say, no more than a few hours in each early iteration), it usually pays off during design, when it supports better understanding and communication.

Ch.9 Domain Model

Jan 26, 2009 44

Guideline– Avoid a waterfall-mindset big-modeling effort to make a

thorough or "correct" domain model - it won't ever be either, and such over-modeling efforts lead to analysis paralysis, with little or no return on the investment.

We were discussing domain model most of the time so far. I thought we should now do object oriented analysis and design (later).

OO analysis vs. domain model?

Ch.9 Domain Model

Jan 26, 2009 45

The quintessential object-oriented analysis is

– the decomposition of a domain into noteworthy concepts or objects.

This definition seems having nothing to do with domain model.

Ch.9 Domain Model

Jan 26, 2009 46

A domain model is a visual representation of conceptual classes or real-situation objects in a domain.

Domain models have also been called – conceptual models – domain object models, and – analysis object models.

OO analysis vs. domain model !

Ch.9 Domain Model

Jan 26, 2009 47

In the UP, the term "Domain Model" means a representation of real-situation conceptual classes, not of software objects.

The term does not mean a set of diagrams describing software classes, the domain layer of a software architecture, or software objects with responsibilities.

In other words, it has nothing to do with programming.

Ch.9 Domain Model

Jan 26, 2009 48

Applying UML notation, a domain model is illustrated with a set of class diagrams in which no operations (method signatures) are defined.

It provides a conceptual perspective of the domain. It may show:

– domain objects or conceptual classes

– associations between conceptual classes

– attributes of conceptual classes

Ch.9 Domain Model

Jan 26, 2009 49

We want to emphasize again that:– Domain Model is a visualization of things in a real-

situation domain of interest, not of software objects such as Java or C# classes, or software objects with responsibilities .

Therefore, the following elements are not suitable in a domain model:– Software artifacts, such as a window or a database,

unless the domain being modeled is of software concepts, such as a model of graphical user interfaces.

– Responsibilities or methods.

Ch.9 Domain Model

Jan 26, 2009 50

Ch.9 Domain Model

Jan 26, 2009 51

Be aware that the term “Domain Model “ means also something else before.

In the UP and thus this chapter, "Domain Model" is a conceptual perspective of objects in a real situation of the world, not a software perspective.

It also has been used to mean "the domain layer of software objects."

Ch.9 Domain Model

Jan 26, 2009 52

Ok, we know that domain model describes conceptual classes in a domain. So what is a conceptual class?

Informally, a conceptual class is an idea, thing, or object.

More formally, a conceptual class may be considered in terms of its symbol, intension, and extension

Ch.9 Domain Model

Jan 26, 2009 53

– Symbol: words or images representing a conceptual class.

– Intension: the definition of a conceptual class.

– Extension: the set of examples to which the conceptual class applies.

– See the figure.

Ch.9 Domain Model

Jan 26, 2009 54

Ch.9 Domain Model

Sale

datetime

concept's symbol

"A sale represents the event of a purchase transaction. It has a date and time."

concept's intension

sale-1

sale-3sale-2

sale-4

concept's extension

words or images representing a conceptual class.

the definition of a conceptual class.

the set of examples to which the conceptual class applies.

Jan 26, 2009 55

Shall we begin to discuss constructing domain model?

We studied what domain model is, some related terms such as conceptual class, etc. We are told to constructed by the UP to construct domain model when we enter elaboration phase?

But why create a domain model? We want to know why before we study how?

Domain model To help coding? Domain model To help understanding?

Ch.9 Domain Model

Jan 26, 2009 56

Domain model To help understanding and more…

– To understand the key concepts and vocabulary in a domain

– To support a lower gap between the software representation and our mental model of the domain.

Lower representation Gap with OO modellingA key idea in OO.

Ch.9 Domain Model

Jan 26, 2009 57

Ch.9 Domain Model

Payment

amount

Sale

datetime

Pays-for

Payment

amount: Money

getBalance(): Money

Sale

date: DatestartTime: Time

getTotal(): Money. . .

Pays-for

UP Domain ModelStakeholder's view of the noteworthy concepts in the domain.

UP Design ModelThe object-oriented developer has taken inspiration from the real world domain in creating software classes.

Therefore, the representational gap between how stakeholders conceive the domain, and its representation in software, has been lowered.

1 1

1 1

A Payment in the Domain Model is a concept, but a Payment in the Design Model is a software class. They are not the same thing, but the former inspired the naming and definition of the latter.

This reduces the representational gap.

This is one of the big ideas in object technology.

inspires objects

and names in

supports a low representational gap between our mental and software models.

here's a source-code payroll program written in 1953:1000010101000111101010101010001010101010101111010101 …

Jan 26, 2009 58

How to create a domain model?

Bounded by the current iteration requirements under design:

– Find the conceptual classes

– Draw them as classes in a UML class diagram.

– Add associations and attributes.

Ch.9 Domain Model

60-322 object-oriented analysis and design jan 26, 2009

Documents