Section 4 - Static Modeling Reposted with permission from the original author Ezequiel Cuellar of CrossLogic Corporation http://www.crosslogic.

com Section 4 - Static odeling.

!omain odel. Is a representation of real world conceptual classes, not of software components. Domain Model is a tool of communication. Domain Modeling is driven by use cases as they become known. If a use case appears, the modeling team should look at them to assess whether they contain anything that could have a strong impact on the domain model. he team that builds the domain model should be a small group !two to four people" that includes developers and domain e#perts. he smallest viable team would be one developer and one domain e#pert. $ conceptual class may be considered in terms of its symbol, intension and e#tension. o Symbol% &ords or images representing the conceptual class. o Intension% he definition of a conceptual class. o '#tension% he set of e#amples to which the conceptual class applies. &hen creating a domain model it is usually the symbol and intensional view that are of most practical interest. he domain model is build over several iterations in the elaboration phase. It is better to over specify a domain model with lots of fine-grained conceptual classes than under specify it. It is common to miss conceptual classes during the initial identification step and to discover them later during the consideration of attributes or associations or during design work. It is valid to have attributeless conceptual classes or conceptual classes which have a purely behavioral role in the domain instead of an information role. (lass identification can be done through the identification of nouns in the use case te#t or using a conceptual class category list. Some of the verbs in the re)uirements become methods of the nouns they reference. $ report ob*ect of other information in a domain model is not useful since all its information is derived from other sources. Domain Modeling +uidelines. o ,ist the candidate conceptual classes using the conceptual class category list and noun phrase identification. o Draw them in the domain model. o $dd the associations. o $dd the attributes. If we don-t think of some conceptual class . as a number or te#t in the real world, . is probably a conceptual class, not an attribute.

,ast /evision% 0123424304

5age 0 of 04

Section 4 - Static Modeling $ Domain Model is not absolutely correct or wrong, but more or less useful. Specification (onceptual (lasses are used to avoid duplicated data for every instance of a given class. Instead of having certain attributes that will store always the same values we can put them in a separate class and avoid accidental loss of information that needs to be maintained. Domain model offers a conceptual perspective. It may show conceptual classes, associations, multiplicity and attributes. $n optional reading arrow indicates the direction to read the association name it does not indicate direction of visibility or navigation. If not present it is conventional to read the association from left to right or top to bottom, this is not a 6M, default but a common convention. he reading direction arrow has no meaning in terms of the model7 it is only an aid to the reader of the diagram. If a new class is discovered during design modeling then that class should be added to the Domain Model only if it adds communication value to it. +enerali8ation is the activity of identifying commonality among concepts and defining superclass !general concept" and subclass. +enerali8ation-Speciali8ation class hierarchy is known during Design Modeling as class hierarchy or inheritance. +enerali8ation from the (onceptual perspective is valid to say that a type 9 is a subtype of a supertype $. /eali8ation is also known as Interface Implementation and indicates that one class implements beheavior specified by another. /eali8ation is deliberately similar to generali8ation. It indicates that one class implements some behavior specified by another. It is permissible for one implementation class to reali8e another, this means that the reali8ing class must conform to the interface but need not use inheritance. In a specification model there is no difference between reali8ation and subtyping. Dependency relationship indicates that one element has knowledge of another element. In class diagrams the dependency relationship is useful to depict nonattribute visibility between classes, in other words, parameter, global, or locally declared visibility. :rom the specification perspective generali8ation means that the interface of the subtype must include all elements from the interface of the supertype. he subtype-s is said to conform to the supertype-s interface. +enerali8ation at the implementation perspective is associated with inheritance in programming languages. +enerali8ation is class inheritance, /eali8ation is interface implementation. Is-a rule% $ll the members of a conceptual subclass set are members of their superclass set, thus a subclass is a member of the superclass- set. Subclass ;is a; Superclass. 033< rule% 033< of the conceptual superclass- definition should be applicable to the subclass. he subclass must conform 033< of the superclass- attributes and associations.

,ast /evision% 0123424304

5age 4 of 04

Section 4 - Static Modeling o find conceptual subclasses apply 033< rule !definition conformance" and the Is-a rule !set membership conformance". $ conceptual class partition is a division of a conceptual class into dis*oining subclasses. Strong motivations to partition a class into subclass% o he subclass has additional attributes of interest. o he subclass has additional associations of interest. o he subclass concept is operated on, handled, reacted to, or manipulated differently than the superclass or other subclasses in ways that are of interest. o he subclass concept represents an animate thing !for e#ample, animal, robote" that behaves differently that the super class or other subclasses in ways that are of interest. Motivations to generali8e and define a superclass% o he potential conceptual subclasses represent variations of similar concept. o he subclasses will conform to the 033< and Is-a rules. o $ll subclasses have the same attribute that can be factored out and e#pressed in the superclass. o $ll subclasses have the same association that can be factored out and related to the superclass. If every member of a class ( M6S also be a member of a subclass, then class ( is called an abstract conceptual class. &hen modeling changing states do not model the states of a concept . as sub of .. /ather, either% o Define a state hierarchy and associate the states with ., or o ignore showing the states of a concept in the domain model and show the states in an state diagram instead. In a Domain Model if a class ( can simultaneously have many values for the same kind of attribute $, do not place attribute $ in (. 5lace attribute $ in another class that is associated with (. :or e#ample a 5erson can have many phone numbers. 5lace the phone number in another class.

!esign odel. Design model offers a specification or implementation perspective. It may show conceptual classes, associations, operations, multiplicity and navigability. In contrast to the Domain Model a (lass Diagram doesn-t show real world ob*ects, rather it shows software classes. $ Design Model illustrates the specifications for software classes and interfaces, typical information includes% classes, associations, attributes, interfaces with their operations and constants methods, attribute type information, navigability and dependencies. ,ooking in the Domain Model to name design classes reduces the representation gap between the Design Model and Domain Model.

,ast /evision% 0123424304

5age = of 04

Section 4 - Static Modeling Setters and getters should not be included in the Design Model. 5rogramming ,anguage native libraries are not shown in the Design Model. ypes of the attributes, method parameters and return values may optionally be shown. During elaboration the Design Model will accompany the use-case reali8ation interaction diagrams, they may be created for the most architecturally significant classes of the design. During construction Design Model will continue to be generated from the source code as an aid in visuali8ing the static structure of the system. /eference $ttributes are shown as an association to another classes in the Design Model. $void making or updating any documentation or model unless there is a concrete *ustification for future use.

Class !iagram. $ (lass Diagram describes the types of ob*ects in the system and the various kinds of static relationships that e#ist among them. here are two principal kinds of static relationships% associations and subtypes. (lass Diagrams show the attributes and operations of a class and the constraints that apply to the way ob*ects are connected. (lass diagrams perspectives% o (onceptual perspective% he diagrams are interpreted as describing things in the real world. o Specification perspective% he diagrams are interpreted as describing software abstractions or components with specifications and interfaces but with no commitment to a particular implementation. o Implementation perspective% he diagrams are interpreted as describing software implementations in a particular technology and language. If you take the conceptual perspective you draw a diagram that represents the concepts in the domain under study. hese concepts will naturally relate to the classes that implement them. he conceptual perspective is considered language-independent. If you take the specification perspective we are looking at the interfaces of the software not the implementation. If you take the implementation perspective we are looking at the software implementation. $ stereotype is a mechanism to categori8e an element in some way. Stereotypes are the core e#tension mechanism for the 6M,. If you find that you need a modeling construct that isn-t in the 6M, but is similar to something that is you treat your construct as a stereotype of the 6M, construct. $ stereotype is showing in te#t between guillemets !>> te#t ??". $ stereotype >>interface?? is used to indicate an interface. $n interface is a collection of signatures that specify only the interface. $ class contains both interface and implementation. ,ast /evision% 0123424304 5age 4 of 04

Section 4 - Static Modeling $bstract classes and interfaces are similar but there is a difference. 9oth allow you to define an interface and defer its implementation, however the abstract class allows you to add implementation of some of the methods. $n abstract class is shown with an italici8ed name. If every member of a class ( must also be a member of a subclass, then class ( is called abstract conceptual class. +enerali8ation !Subclassing and inheritance" is shown with a solid line and a fat arrow pointing to the superclass. 'ither a separate target or shared target arrow style may be used. /eali8ation is illustrated with a dashed line and a fat arrow. Dependency it is illustrated with a dashed arrow line. $nother way to illustrate interfaces is by using small circles coming of the classes that implement them, often called lollipops. '#ceptions thrown can be listed in another compartment labelled ;e#ceptions;. '#ceptions caught are modeled as a kind of operation handling a signal. (lass scope features are underlined on a class diagram. (lass scope operations or attributes apply only to the class rather than an instance. (lassification refers to the relationship between an ob*ect and its type. In single classification an ob*ect belongs to a single type which may inherit from supertypes. In multiple classification an ob*ect may be described by several types that are not necessarily connected by inheritance. Multiple classification is different from multiple inheritance. Multiple inheritance says that a type may have many supertypes but a single type must be defined for each ob*ect. Multiple classification allows multiple types for an ob*ect without defining a specific type for the purpose. :or e#ample @ If you use multiple classification you need to be sure that you make it clear which combinations are legal. Aou do this by labelling a generali8ation line with a discriminator role which is an indication of the basis of the subtyping. $ good convention is to have all subclasses that use one discriminator roll up to one triangle. $ 6M, constraint is some semantically meaningfully information attached to a model element. 6M, constraints are enclosed in BC braces. $ 6M, note is a comment that has no semantic impact. $ note is always shown in a note bo#. ,ong constraints may be also placed within a note bo#. he te#t in the bo# is within braces to indicate that it is a constraint. $ constraint can be written in any formal !ocl" or informal language. he constraint BcompleteC indicates that any instance of the superclass must be an instance of one of the subtypes of a group. Dynamic classification allows ob*ects to change type within the subtyping structure, static classification does not.

,ast /evision% 0123424304

5age D of 04

Section 4 - Static Modeling Eisibility is F !public", G!protected" or - !private". 5ublic is accessible anywhere in the program and may be called by any ob*ect within the system. $ private member may be used only by the class that defines it. $ protected member may be used only by !a" the class that defines or !b" a subclass of that class.

"ssociations. $n association is a relationship between types that indicates some meaningful and interesting connection. hey must imply knowledge of a relationship that needs to be preserved for some duration. $ssociations represent relationships between instances of classes. :rom a conceptual perspective associations represent conceptual relationships between classes. :rom the specification perspective associations represent responsibilities. hese responsibilities do not imply data structure. he diagram indicates only the interface, nothing more :rom the implementation perspective associations represent references between the related classes. Some high-priority association categories that are invariably useful to include in a domain model are% o $ is a physical or logical part of 9. o $ is physically or logically contained in2on 9. o $ is recorded in 9. Hame an association based on a ypeHame-Eerb5hrase- ypeHame format where the verb phrase creates a se)uence that is readable and meaningful in the model conte#t. wo legal formats to compound association names are% 5aid-by and 5aid9y. Many associations can overwhelm the domain model. :ocus on those associations for which knowledge of the relationship needs to be preserved for some duration !;need-to-know; associations", and add choice comprehension-only associations to enrich critical understanding of the domain. $ssociation names should start with a capital letter. wo types may have multiple associations between them. During domain modeling an association is not a statement about data flows, instance variables, or ob*ect connections in software7 it is a statement that a relationship is meaningful in a conceptual sense. $void showing redundant or derivable associations. :inding conceptual classes is more important than finding associations. 'ach end of an association is called a role. he role may be decorated with a navigability arrow. Havigability is a property of the role that indicates that is possible to navigate unidirectionally across the association from ob*ects of the source to target class. Havigability implies visibility usually attribute visibility.

,ast /evision% 0123424304

5age I of 04

Section 4 - Static Modeling If navigability e#ists only in one direction we call the association a unidirectional association. If the association doesn-t have navigability arrows then is bi-directional. 9i-directional associations include an e#tra constraint which is that the two navigations are inverses of each other. $ssociations in Design Model is translated as the source class having an attribute that refers to an instance of the target class. $ssociations in Domain Model are used only to enhance the comprehension of the problem domain. (ommon situations suggesting a need to define an association with navigability adornment from $ to 9 are% $ sends a message to 9, $ creates an instance to 9, $ needs to maintain a connection to 9. Eisibility is the ability of an ob*ect to see or have a reference to another ob*ect. here are 4 common ways that visibility can be achieved from ob*ect $ to ob*ect 9. o $ttribute visibility% 9 is an attribute of $. o 5arameter visibility% 9 is a parameter of a method $. o ,ocal visibility% 9 is a !non-parameter" local ob*ect in a method of $. o +lobal visibility% 9 is in some way globally visible. $ttribute visibility form $ to 9 e#ists when 9 is an attribute of $. It is a relatively permanent visibility because it persists as long as $ and 9 e#ist. 5arameter visibility from $ to 9 e#ists when 9 is passed as a parameter to a method of $. It is relatively temporary visibility because it persists only within the scope of the method. ,ocal visibility from $ to 9 e#ists when 9 is declared as local ob*ect within a method of $. It is relatively temporary visibility because it persists only within the scope of the method. +lobal Eisibility from $ to 9 e#ists when 9 is global to $. It is relatively permanent visibility because it persists as long as $ and 9 e#ist. Eisibility can be illustrated using stereotypes in interaction diagrams. he stereotype >>association?? denotes attribute visibility. $n $ssociation (lass is that whose attributes are related to the association and its life time is dependent on the association. $ssociation class allows you to add attributes, operations and other features to associations. (lues that an association class might be useful in a domain model% o $n attribute is related to an association. o Instances of the association class have a life-time dependency on the association. o here is a many-to-many association between two concepts and information associated with the association itself. o here is a many-to-many association between two concepts and one or more attributes of a concept has multiple values. (omposition is a kind of association used to model the whole-part relationships between things. If the multiplicity at the composite ob*ect is one that means that the part may not e#ist separate from the composite. 5age 1 of 04

,ast /evision% 0123424304

Section 4 - Static Modeling (omposition in the Design Model indicates that the composite software ob*ects create the part software ob*ects. &ith composition the part ob*ect may belong to only one whole usually the parts are e#pected to live and die with the whole. 6sually any deletion of the whole is considered to cascade to the parts. $nother way to illustrate composition is to put the component inside the whole. he component class name is not bold and you write it in the form% rolename%(lass name. In addition you put the multiplicity in the top right corner. $ggregation is the part-of relationship. It is like saying that a car has an engine and wheels as its parts. $ggregation means that the multiplicity at the composite end may be more than one. It implies that the part may be simultaneously in many composite instances. :or e#ample a package may be considered to aggregate its elements but an element may be referenced in more than one package. $ggregation and (omposition are properties of an association role. (omposition and $ggregation are also known as (omposite $ggregation and Shared $ggregation. he association name is often e#cluded in aggregation and composition relationships since it is typically thought of as Jas-part. If in doubt about $ggregation or (omposition associations, leave them out. (onsider showing aggregation or composition when% o he lifetime of the part is bound within the lifetime of the composite7 there is a create-delete dependency of the part on the whole. o here is an obvious whole-part physical or logical assembly. o Some properties of the composite propagate to the parts such as the location. o Kperations applied to the composite propagate to the parts such as destruction, movement, and recording. Discover and show aggregation because it has he following benefits% o It clarifies the domain constraints regarding the eligible e#istence of the part independent of the whole. o It assists in the identification of the creator using the +/$S5 (reator 5attern. o Kperations such as copy and delete applied to the whole often propagate to the parts. 'ach end of an association is called role. hey may optionally have name, multiplicity e#pression or navigability. If the role name is not present assume that the default role name is e)ual to the related class name through starting with a lower case letter. Hote that the role name and the association name are two different sub*ects. 9oth can be present. In a domain model a real world role may be modeled in a number of ways like% o /oles in $ssociations are appealing because they are a relatively accurate way to e#press the notion that the same instance of a person takes on multiple roles in various associations.

,ast /evision% 0123424304

5age L of 04

Section 4 - Static Modeling o /oles as concepts provide ease and fle#ibility in adding uni)ue attributes, associations and additional semantics. $ )ualifier may be used in an association7 it distinguishes the set of ob*ects at the far end of the association based on the )ualifier value. $n association with a )ualifier is a )ualified association. $ )ualifier communicates how in the domain things of one class are distinguished in a relation to another. Mualification reduces the multiplicity at the far end form the )ualifier usually down from many to one. $ concept may have an association to itself this is known as a refle#ive association. $n association is represented as a line between classes with an association name. he association is inherently bi-directional. 'ach association has two association ends, each end is attached to one of the classes in the association. $n association end has a multiplicity which is an indication of how many ob*ects may participate in the given relationship. Multiplicity indicates lower and upper bounds for the participating ob*ects. he N represents infinity. he ends of an association may contain multiplicity e#pression indicating the numerical relationship between instances of the classes. Multiplicity defines how many instances of a class $ can be associated with one instance of a class 9. N 8ero or more7 ;many;. 0..N one or more. 0..43 one to 43. D e#actly D. =,D,L e#actly =,D, or L. Krdered elements are shown by placing the BorderedC constraint. he BbagC constraint is used to indicate that ob*ects in a collection may appear more than once. he Bhierarchy" constraint is used to indicate that the ob*ects in a collection form a hierachy. he BdagC constraint is used to indicate a directed a cyclic graph. :ro8en on an attribute or association end indicate that the value of that attribute or association end may not change during the lifetime of the source ob*ect. he value must be set at ob*ect creation and may never change after that. he initial value may be null. &hen applied to a class fro8en indicates that all association ends and attributes associated with that class are fro8en. :ro8en is not the same as read-only.

"ttri#utes. $n attribute is a logical data value of an ob*ect. Include the following attributes in a domain model% hose for which the re)uirements suggest or imply a need to remember information. $ttributes in a domain model should be data types or simple attributes. Data types as 5hone Humber are known as value ob*ects. ,ast /evision% 0123424304 5age O of 04

Section 4 - Static Modeling If in doubt, define something as a separate conceptual class rather than as an attribute. /elate conceptual classes with an association, not with an attribute. If an attribute is composed of separate sections, has other attributes, is a )uantity with a unit, is an abstraction of one or more types or there are operations usually associated with it, then the attribute must be represented as a non-primitive. /epresent it in a distinct conceptual class. $ttributes should not be used as foreign keys to relate conceptual classes. Humeric )uantities should not be represented as plain numbers. (onsider price or velocity, these are )uantities with associated units and it is common to re)uire knowing the unit and to support conversions. he solution is to represent the )uantity as a distinct conceptual class. Since )uantities are considered data types is valid to put their illustration into the attributes section of the class bo#. $ Derived association and a derived attribute can be calculated from other associations and attributes respectively on a class diagram. o illustrate either a derived attribute or an association simply put a ;2; before the name% 2balance%Money or 2entries. :rom the specification perspective a derived attribute indicate a constraint between values and not a statement of what is calculated and what is stored. $ Derived $ttribute is one that its value may be derived from other information. $void showing derived elements in a diagram since they add comple#ity without new information Jowever add a derived element when it is prominent in the terminology and e#cluding it impairs comprehension. /eference $ttribute is an attribute that refers to another comple# ob*ect not to a primitive type. hey are suggested by the associations and navigability in a class diagram. $t the conceptual level attributes indicates that the concept has properties, at the specification level attributes indicates that the ob*ect-s interface has a way to give you the value of them and it has a way to set its values, at the specification level indicates the class- field or data member. :rom the conceptual perspective there is no difference between an attribute and an association. he attribute notation is% visibility name % type P default value. here isn-t a default visibility marker when an attribute or a method is shown without it. It implies ;not specified;.

$perations. Kperations are the processes that a class knows to carry out. $t the specification level operations correspond to public methods on a type. Kperations that simply manipulate attributes must not be shown in a class diagram !getters and setters". &ith conceptual models operations shouldn-t be used to specify the interface of a class. ,ast /evision% 0123424304 5age 03 of 04

Section 4 - Static Modeling $ )uery is an operation that gets a value form a class without changing the system state. Such operation can be marked with the constraint B)ueryC. Modifiers are operations that do change the state of a class or system. $ getting method returns a value from a field. $ setting method puts value into a field. $n operation is something that is invoked on an ob*ect !the procedure call", whereas a method is the body of the procedure. $ feature is either an attribute or an operation. he synta# for operations is% o Eisibility name !parameter-list" % return-type-e#pression Bproperty-stringC where% o Eisibility is F !public", G!protected" or - !private". o Hame is a string. o 5arameter-list contains a comma-separated parameters whose synta# is similar to that for attributes% direction name % type P default value. o /eturn-type-e#pression is a comma-separated list of return types. o 5roperty-string indicates property values that apply to the given operation. $ method body implementation may be shown in a 6M, note bo#. It should be placed within braces. he synta# may be pseudo-code or any language. It is common to e#clude the method signature but it is legal to include it. /eturn or parameter types that represent a collection can be specified in any synta#. $bstract methods are shown with italics. he methods of each class can be identified by analy8ing the interaction diagrams. %ol&morphism. Is a fundamental principle in designing how a system is organi8ed to handle similar variations. 'usiness Rules. $lso called Domain /ules they dictate how the domain or business may operate. (ompany policies, physical laws and government laws are common business rules. 9usiness rules are not application re)uirements. Do not record system features as rules. hey describe the constraints and behaviours of how the domain works, not the application. CRC Cards. (/( (ards stands for (lass /esponsibility (ollaboration cards. (/( cards are used to represent the responsibilities and the collaboration of a class with another classes. he sections of a (/( card are% class name, responsibility and collaboration. 'ach responsibility collaborates with one or more classes. ,ast /evision% 0123424304 5age 00 of 04

Section 4 - Static Modeling (/( cards help to e#plore an interaction between classes.

$#(ect !iagram. $n ob*ect diagram shows instances instead of classes, it is often called instance diagram. 'ach name of an instance takes the form% instance name % class name. 9oth parts of the name are optional. Contri#utors: Ezequiel Cuellar - prime cfw

,ast /evision% 0123424304

5age 04 of 04