Creating Design Class Diagrams After the completion of interaction diagrams for use-case realizations, it is possible to identify the

e specification of the software classes and add the design details, such as methods. In practice, the creation of DCDs and creations of interaction diagrams are done in parallel. The usual procedure is to, first design classes are sketched out and after the creation of interaction diagrams, DCDs are updated. This procedure happens in se eral iterations. A Sample Design Class Diagrams
Register Captures enterItem() Sale date isComplete: Boolean time makeLineItem()

A typical DCD includes, classes, associations and attributes Interfaces !ethods Attribute type information "a igability Dependencies

The conceptual classes in the Domain !odel define the real world concepts. The design classes in the design model define the software classes. In the #nified $rocess, an specific artifact called %Design Class& is not defined. The #$ defines the Design !odel and it contains class diagrams . The term %design class diagram& is rather a short term for %class diagrams in the design model&.

Creating a NextGen POS DCD STEP 1: The first step in the creation of DCDs is to identify those classes that participate in the software solution. This can be done by scanning the interaction diagrams. 'or the "e(t)en $*+ system, they are,

,egister $roductCatalog +tore $ayment +ale $roduct+pecification +ales-ineItem

STEP 2: Then a class diagram is drawn for each of these classes, and include the attributes that were pre iously identified in the Domain !odel. "ote that some concepts in the domain model, such as Cashier, are not present in the design. Creating a NextGen POS DCD
Register ..... . Payment amount . SalesLineItem !uantity . Store address name . Sale date isComplete time . ProductCatalog !uantity .. ProductSpecification description price itemId .

STEP 3: Then the methods of each class are identified by analyzing the interaction diagram. 'or e(ample, if the message make-ineItem is sent to an instance of class +ale, +ale must define a make-ineItem method. In general, the set of all the messages sent to a class across all the interaction diagrams indicates the ma.ority of methods of the class. Creating a NextGen POS DCD
ProductCatalog !uantity getSpecification() ProductSpecification description price itemId . Payment amount . SalesLineItem !uantity getSu"total() Store address name addSale()

Sale date isComplete time "ecomeComplete() makeLineItem() makePayment() get#otal()

Register ..... endSale() enterItem() make$e%Sale() makePayment()

Method Name ss!es There are some special issues that should be considered when naming methods Interpretation of the create message Depiction of accessing message -anguage dependent synta( nterpretation o" the Create Message

The create message #!- language independent form to indicate instantiation. /hen translating the design to software language, it must be e(pressed in terms of its idioms for instantiation. 'or e(ample, in .a a, create implies new operator. Depi#tion o" A##essing Message Accessing methods retrie e 0accessor methods1 or set 0mutator methods1 the alue of an attribute. In some languages such as .a a, it is a common idiom to ha e an accessor and mutator for each attribute, and declare all attributes pri ate. Theses methods are not shown in the design class diagram. $ang!age Dependent S%ntax In #!- methods are named in the, method"ame01 format. 2ut in some programming languages the synta( for naming methods is different. 3(ample4 5a a4 camelCase $ascal4 $ascalCase C664 anything that starts with a lowercase letter $ang!age Dependent S%ntax It is recommended that the #!- format is used in design class diagrams, and transform into the language synta( in the coding process. Adding More T%pe n"ormation STEP &: The types of each attribute, method parameters and method return alues may all be optionally shown. /hether or not to include them depends on the following conte(t4

If it is being created in a CA+3 tool with automatic code generation, full and e(hasti e details are necessary. If it is being created for software de elopers to read, e(hausti e low-le el detail may be ad ersely affect the noise- alue ratio.

Sale date : *ate isComplete : Boolean time : #ime "ecomeComplete() makeLineItem(spec : Prodspecification' !ty : integer) makePayment(cas( #endered : )oney) get#otal : )oney

Adding Asso#iations and Na'iga(ilit% STEP ): Association is a relationship between types that indicates a meaningful connection. 3ach end of a association is called a role. "a igability is a property of the role that indicates that it is possible to na igate uni-directionally across the association. "a igability usually implies attribute isibility. Adding Asso#iations and Na'iga(ilit% Adding Dependen#% *elationships STEP +: A dependency is where one element has knowledge of another element. In DCDs it is indicated with a dashed arrow. Dependency relationships are useful to depict non-attribute isibility. Adding Dependen#% *elationships Mem(er Details STEP ,: The ne(t step is to add member details. 7ere the isibility markers and other details of the members are added. Notation "or Mem(er Details Attributes 6 public attribute & public attribute 8 protected attribute attribute/ith9isibility#nspecified attribute: 4 type Attribute; 4 type < initial alue = deri edAttribute finalConstantAttribute 4 type < alue >frozen? Notation "or Mem(er Details !ethods 6 @@constructorAA Class"ame01

6 public!ethod01 & pri ate!ethod01 8 protected!ethod01 method/ith9isibility#nspecified01 method,eturns+omething01 4 'oo abstractMethod() or abstract!ethod01 >abstract? -isi(ilit% De"a!lts in .M$ If no e(plicit isibility marker is gi en, what is the defaultB Answer is none. There is no default isibility in #!- . If none is shown it implies %not specified&. 7owe er there is a common con ention to assume that all attributes are pri ate and all methods are public unless otherwise noted. Adding Mem(er Details DCDs and CASE Tools CA+3 tools can re erse-engineer 0generate1 DCDs from source codes.