You are on page 1of 22

Mapping design to code

-Programming and iterative,evolutionary development -creativity and change during implementation -Implementation in an object oriented language requires writing source code for Class and interface definitions,method definitions

Click to edit Master subtitle style

4/8/12

DCD-Design Class Diagram

4/8/12

4/8/12

4/8/12

Adding Reference Attributes

A reference attribute is an attribute that refers to another complex object, not to a primitive type such as a String, Number, and so on. The reference attributes of a class are suggested by the associations and navigability in a class diagram.
4/8/12

4/8/12

Creating Methods from Interaction Diagrams


An interaction diagram shows the messages that are sent in response to a method invocation. The sequence of these messages translates to a series of statements in the method definition. The enterltem interaction diagram in Figure 20.6 illustrates the Java definition of the enterltem method. In this example, the Register class will be used. A Java definition is shown in Figure 20.7.

4/8/12

4/8/12

4/8/12

4/8/12

Container/Collection Classes in Code


It is often necessary for an object to maintain visibility to a group of other objects; the need for this is usually evident from the multiplicity value in a classdiagram It may be greater than one. For example, a Sale must maintain visibility to a group of SalesLineltem instances.

In OO programming languages, these relationships are often implemented with the introduction of a intermediate container or collection.

The one-side class defines a reference attribute pointing to a For example, the Java libraries contain collection classes container/collection instance, which contains instances of the such as ArrayList and HashMap, which implement the List many-side class. and Map interfaces, respectively.

Using ArrayList, the Sale class can define an attribute that maintains an ordered list ofSalesLineltem instances.

4/8/12

4/8/12

Defining the Sale-makeLineltem Method

4/8/12

Order of Implementation
Classes need to be implemented (and ideally, fully unit tested) from least-coupled to mostcoupled .

For example, possible first classes to implement are either Payment or ProductSpecification; next are classes only dependent on the prior implementations ProductCatalog or SalesLineltem.

4/8/12

4/8/12

Test-First Development/Test Driven


In this practice, unit testing code is written before the code to be tested, and the developer writes unit testing code for all production code. actually get written The unit tests
Programmer satisfaction

Clarification of interface and behavior

Provable verification

The confidence to change things

4/8/12

Introduction to the Program SolutionNextGen POS

4/8/12

4/8/12

4/8/12

4/8/12

4/8/12

4/8/12

You might also like