DOMAIN MODEL:ADDING ATTRIBUTES

Identify attributes in a domain model.

Distinguish between correct and incorrect attributes.

DOMAIN MODEL:ADDING ATTRIBUTES

An attribute is a logical data value of an object.

Include the following attributes in a domain model:

Those for which the requirements (for example, use cases) suggest or imply a need to remember information.

UML Attribute Notation

Valid Attribute Types

Keep Attributes Simple

Valid Attribute Types

Keep Attributes Simple

Valid Attribute Types

Keep Attributes Simple

Conceptual vs. Implementation Perspectives

What About Attributes in Code ?

Data Types

Attributes should generally be data types. This is a UML term that implies a set of values for which unique identity is not meaningful (in the context of our model or system) [RJB99].

If in doubt, define something as a separate conceptual class rather than as an attribute.

Non-primitive Data Type Classes

Represent what may initially be considered a primitive data type (such as a number or string) as a non-primitive class if:

• It is composed of separate sections.o phone number, name of person

• There are operations usually associated with it, such as parsing or validation.

o social security number

Non-primitive Data Type Classes

• It has other attributes.o promotional price could have a start (effective) date and end date

• It is a quantity with a unit.o payment amount has a unit of currency

• It is an abstraction of one or more types with some of these qualities.

o item identifier in the sales domain is a generalization of types such as Universal Product Code (UPC) or European Article Number (EAN)

Where to Illustrate Data Type Classes?

Where to Illustrate Data Type Classes?

Design Creep: No Attributes as Foreign Keys

Attributes should not be used to relate conceptual classes in the domain model. The most common violation of this principle is to add a kind of foreign key attribute.

Design Creep: No Attributes as Foreign Keys

Modeling Attribute Quantities and Units

Attributes in the NextGen Domain Model

Attributes in the NextGen Domain Model

Multiplicity From SalesLineItem to Item

Domain Model Conclusion

USE-CASE MODEL:ADDING DETAIL WITH OPERATION CONTRACTS

Objectives• Create contracts for system

operations.

USE-CASE MODEL:ADDING DETAIL WITH OPERATION CONTRACTSContracts Use cases are the primary mechanism in the

UP to describe system behavior, and are usually sufficient. However, sometimes a more detailed description of

system behavior has value. Contracts describe detailed system behavior in terms of state changes to objects in the Domain Model, after a system operation has executed.

System Operations and the System Interface

Example Contract: enterltem

Postconditions

Postconditions

If Contracts Are Used, How Complete Should Postconditions Be?

Writing Contracts Leads to Domain Model Updates

It is 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 the operation contracts.

When Are Contracts Useful? Contracts vs. Use Cases?

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.

There are situations where the details and complexity of required state changes are awkward to capture in use cases.

Guidelines: Contracts

To make contracts: 1. Identify system operations from the SSDs. 2. For system operations that are complex and

perhaps subtle in their results, or which are not clear in the use case,

construct a contract. 3. To describe the postconditions, use the following

categories: o instance creation and deletion o attribute modification o associations formed and broken

Guidelines: Contracts

To make contracts: 1. Identify system operations from the SSDs. 2. For system operations that are complex and

perhaps subtle in their results, or which are not clear in the use case, construct a contract.

3. To describe the postconditions, use the following categories:

o instance creation and deletion o attribute modification o associations formed and broken

Advice on Writing Contracts

State the postconditions in a declarative, passive past tense form (was ...) to emphasize the declaration of a state change rather than a design of how it is going to be achieved. For example:

# (better) A SalesLineltem was created. .) # (worse) Create a SalesLineltem.

Remember to establish a memory between existing objects or those newly created by defining the forming of an association. For example, it is not enough that a new SalesLineltem instance is created when the enterltem operation occurs. After the operation is complete, it should also be true that the newly created instance was associated with Sale; thus:

# The SalesLineltem was associated with the Sale (association formed).

The Most Common Mistake in Creating Contracts

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!

NextGen POS Example: Contracts

NextGen POS Example: Contracts

NextGen POS Example: Contracts

Changes to the Domain Model

Contracts, Operations, and the UML

The UML formally defines operations. To quote:

An operation is a specification of a transformation or query that an object may be called to execute [RJB99]

Contracts, Operations, and the UML

To summarize:The UML defines operation specifications,

which are specifiable in the pre- and post-condition contract style. Note that, as emphasized in this chapter, a UML operation specification may not show an algorithm or solution, but only the state changes or effects of the operation.

Operation Contracts Within the UP

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.

FROM REQUIREMENTS TO DESIGN IN THIS ITERATION

Iteratively Do the Right Thing, Do the Thing Right

The requirements and object-oriented analysis has focused on learning to do the right thing; that is, understanding some of the outstanding goals for the Next-Gen POS, 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.

Didn't That Take Weeks To Do? No, Not Exactly.

After many chapters of detailed discussion, it must surely seem like the prior modeling would take weeks of effort. Not so. 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 days.

On to Object Design No, Not Exactly.

During object design, a logical solution based on the object-oriented paradigm is developed. The heart of this solution is the creation of interaction diagrams, which illustrate how objects collaborate to fulfill the requirements. After or in parallel with drawing interaction diagrams, (design) class diagrams can be drawn. These summarize the definition of the software classes (and interfaces) that are to be implemented in software. In terms of the UP, these artifacts are part of the Design Model.

The Importance of Object Design Skill vs. UML Notation Skill