Reposted with permission from the original author
Ezequiel Cuellar of CrossLogic Corporation http://www.crosslogic.com

Section 4 - Static Modeling.

Domain Model.

• 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.
• The team that builds the domain model should be a small group (two to four people) that includes developers and domain experts. The smallest viable team would be one developer and one domain expert.
• A conceptual class may be considered in terms of its symbol, intension and extension.
  • Symbol: Words or images representing the conceptual class.
  • Intension: The definition of a conceptual class.
  • Extension: The set of examples to which the conceptual class applies. When creating a domain model it is usually the symbol and intensional view that are of most practical interest.
• The 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.
• Class identification can be done through the identification of nouns in the use case text or using a conceptual class category list.
• Some of the verbs in the requirements become methods of the nouns they reference.
• A report object of other information in a domain model is not useful since all its information is derived from other sources.

• Domain Modeling Guidelines.
  • List the candidate conceptual classes using the conceptual class category list and noun phrase identification.
  • Draw them in the domain model.
  • Add the associations.
  • Add the attributes.
• If we don't think of some conceptual class X as a number or text in the real world, X is probably a conceptual class, not an attribute.
• A Domain Model is not absolutely correct or wrong, but more or less useful.
• Specification Conceptual Classes 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.
• An 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 UML default but a common convention.
• The reading direction arrow has no meaning in terms of the model; 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.
• Generalization is the activity of identifying commonality among concepts and defining superclass (general concept) and subclass.
• Generalization-Specialization class hierarchy is known during Design Modeling as class hierarchy or inheritance.
• Generalization from the Conceptual perspective is valid to say that a type B is a subtype of a supertype A.
• Realization is also known as Interface Implementation and indicates that one class implements beheavior specified by another. Realization is deliberately similar to generalization. It indicates that one class implements some behavior specified by another.
• It is permissible for one implementation class to realize another, this means that the realizing class must conform to the interface but need not use inheritance. In a specification model there is no difference between realization and subtyping.
• Dependency relationship indicates that one element has knowledge of another element. In class diagrams the dependency relationship is useful to depict non-attribute visibility between classes, in other words, parameter, global, or locally declared visibility.
• From the specification perspective generalization means that the interface of the subtype must include all elements from the interface of the supertype. The subtype's is said to conform to the supertype's interface.
• Generalization at the implementation perspective is associated with inheritance in programming languages.
• Generalization is class inheritance, Realization is interface implementation.
• Is-a rule: All 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.
• 100% rule: 100% of the conceptual superclass' definition should be applicable to the subclass. The subclass must conform 100% of the superclass' attributes and associations.
• To find conceptual subclasses apply 100% rule (definition conformance) and the Is-a rule (set membership conformance).
• A conceptual class partition is a division of a conceptual class into disjoining subclasses.
• Strong motivations to partition a class into subclass:
  • The subclass has additional attributes of interest.
  • The subclass has additional associations of interest.
  • The subclass concept is operated on, handled, reacted to, or manipulated differently than the superclass or other subclasses in ways that are of interest.
  • The subclass concept represents an animate thing (for example, animal, robote) that behaves differently that the super class or other subclasses in ways that are of interest.
• Motivations to generalize and define a superclass:
  • The potential conceptual subclasses represent variations of similar concept.
  • The subclasses will conform to the 100% and Is-a rules.
  • All subclasses have the same attribute that can be factored out and expressed in the superclass.
  • All subclasses have the same association that can be factored out and related to the superclass.
• If every member of a class C MUST also be a member of a subclass, then class C is called an abstract conceptual class.
• When modeling changing states do not model the states of a concept X as sub of X. Rather, either:
  • Define a state hierarchy and associate the states with X, or
  • 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 C can simultaneously have many values for the same kind of attribute A, do not place attribute A in C. Place attribute A in another class that is associated with C. For example a Person can have many phone numbers. Place the phone number in another class.

Design Model.

• 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 Class Diagram doesn't show real world objects, rather it shows software classes.
• A 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.
• Looking in the Domain Model to name design classes reduces the representation gap between the Design Model and Domain Model.
• Setters and getters should not be included in the Design Model.
• Programming Language native libraries are not shown in the Design Model.
• Types of the attributes, method parameters and return values may optionally be shown.
• During elaboration the Design Model will accompany the use-case realization 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 visualizing the static structure of the system.
• Reference Attributes are shown as an association to another classes in the Design Model.
• Avoid making or updating any documentation or model unless there is a concrete justification for future use.

Class Diagram.

• A Class Diagram describes the types of objects in the system and the various kinds of static relationships that exist among them. There are two principal kinds of static relationships: associations and subtypes.
• Class Diagrams show the attributes and operations of a class and the constraints that apply to the way objects are connected.
• Class diagrams perspectives:
  • Conceptual perspective: The diagrams are interpreted as describing things in the real world.
  • Specification perspective: The diagrams are interpreted as describing software abstractions or components with specifications and interfaces but with no commitment to a particular implementation.
  • Implementation perspective: The 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. These concepts will naturally relate to the classes that implement them.
• The 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.
• A stereotype is a mechanism to categorize an element in some way.
• Stereotypes are the core extension mechanism for the UML. If you find that you need a modeling construct that isn't in the UML but is similar to something that is you treat your construct as a stereotype of the UML construct.
• A stereotype is showing in text between guillemets (<< text >>).
• A stereotype <<interface>> is used to indicate an interface.
• An interface is a collection of signatures that specify only the interface.
• A class contains both interface and implementation.
• Abstract classes and interfaces are similar but there is a difference. Both allow you to define an interface and defer its implementation, however the abstract class allows you to add implementation of some of the methods.
• An abstract class is shown with an italicized name.
• If every member of a class C must also be a member of a subclass, then class C is called abstract conceptual class.
• Generalization (Subclassing and inheritance) is shown with a solid line and a fat arrow pointing to the superclass. Either a separate target or shared target arrow style may be used.
• Realization is illustrated with a dashed line and a fat arrow.
• Dependency it is illustrated with a dashed arrow line.
• Another way to illustrate interfaces is by using small circles coming of the classes that implement them, often called lollipops.
• Exceptions thrown can be listed in another compartment labelled "exceptions".
• Exceptions caught are modeled as a kind of operation handling a signal.
• Class scope features are underlined on a class diagram. Class scope operations or attributes apply only to the class rather than an instance.
• Classification refers to the relationship between an object and its type.
• In single classification an object belongs to a single type which may inherit from supertypes.
• In multiple classification an object 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 object. Multiple classification allows multiple types for an object without defining a specific type for the purpose. For example …
• If you use multiple classification you need to be sure that you make it clear which combinations are legal. You do this by labelling a generalization line with a discriminator role which is an indication of the basis of the subtyping.
• A good convention is to have all subclasses that use one discriminator roll up to one triangle.
• A UML constraint is some semantically meaningfully information attached to a model element. UML constraints are enclosed in {} braces.
• A UML note is a comment that has no semantic impact. A note is always shown in a note box.
• Long constraints may be also placed within a note box. The text in the box is within braces to indicate that it is a constraint.
• A constraint can be written in any formal (ocl) or informal language.
• The constraint {complete} indicates that any instance of the superclass must be an instance of one of the subtypes of a group.
• Dynamic classification allows objects to change type within the subtyping structure, static classification does not.
• Visibility is + (public), #(protected) or - (private). Public is accessible anywhere in the program and may be called by any object within the system. A private member may be used only by the class that defines it. A protected member may be used only by (a) the class that defines or (b) a subclass of that class.

Associations.

• An association is a relationship between types that indicates some meaningful and interesting connection. They must imply knowledge of a relationship that needs to be preserved for some duration.
• Associations represent relationships between instances of classes.
• From a conceptual perspective associations represent conceptual relationships between classes.
• From the specification perspective associations represent responsibilities. These responsibilities do not imply data structure. The diagram indicates only the interface, nothing more
• From 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:
  • A is a physical or logical part of B.
  • A is physically or logically contained in/on B.
  • A is recorded in B.
• Name an association based on a TypeName-VerbPhrase-TypeName format where the verb phrase creates a sequence that is readable and meaningful in the model context.
• Two legal formats to compound association names are: Paid-by and PaidBy.
• Many associations can overwhelm the domain model. Focus 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.
• Association names should start with a capital letter.
• Two types may have multiple associations between them.
• During domain modeling an association is not a statement about data flows, instance variables, or object connections in software; it is a statement that a relationship is meaningful in a conceptual sense.
• Avoid showing redundant or derivable associations.
• Finding conceptual classes is more important than finding associations.
• Each end of an association is called a role.
• The role may be decorated with a navigability arrow.
• Navigability is a property of the role that indicates that is possible to navigate uni-directionally across the association from objects of the source to target class.
• Navigability implies visibility usually attribute visibility.
• If navigability exists only in one direction we call the association a unidirectional association.
• If the association doesn't have navigability arrows then is bi-directional.
• Bi-directional associations include an extra constraint which is that the two navigations are inverses of each other.
• Associations in Design Model is translated as the source class having an attribute that refers to an instance of the target class. Associations in Domain Model are used only to enhance the comprehension of the problem domain.
• Common situations suggesting a need to define an association with navigability adornment from A to B are: A sends a message to B, A creates an instance to B, A needs to maintain a connection to B.
• Visibility is the ability of an object to see or have a reference to another object. There are 4 common ways that visibility can be achieved from object A to object B.
  • Attribute visibility: B is an attribute of A.
  • Parameter visibility: B is a parameter of a method A.
  • Local visibility: B is a (non-parameter) local object in a method of A.
  • Global visibility: B is in some way globally visible.
• Attribute visibility form A to B exists when B is an attribute of A. It is a relatively permanent visibility because it persists as long as A and B exist.
• Parameter visibility from A to B exists when B is passed as a parameter to a method of A. It is relatively temporary visibility because it persists only within the scope of the method.
• Local visibility from A to B exists when B is declared as local object within a method of A. It is relatively temporary visibility because it persists only within the scope of the method.
• Global Visibility from A to B exists when B is global to A. It is relatively permanent visibility because it persists as long as A and B exist.
• Visibility can be illustrated using stereotypes in interaction diagrams. The stereotype <<association>> denotes attribute visibility.
• An Association Class is that whose attributes are related to the association and its life time is dependent on the association.
• Association class allows you to add attributes, operations and other features to associations.
• Clues that an association class might be useful in a domain model:
  • An attribute is related to an association.
  • Instances of the association class have a life-time dependency on the association.
  • There is a many-to-many association between two concepts and information associated with the association itself.
  • There is a many-to-many association between two concepts and one or more attributes of a concept has multiple values.
• Composition is a kind of association used to model the whole-part relationships between things. If the multiplicity at the composite object is one that means that the part may not exist separate from the composite.
• Composition in the Design Model indicates that the composite software objects create the part software objects.
• With composition the part object may belong to only one whole usually the parts are expected to live and die with the whole. Usually any deletion of the whole is considered to cascade to the parts.
• Another way to illustrate composition is to put the component inside the whole. The component class name is not bold and you write it in the form: rolename:Class name. In addition you put the multiplicity in the top right corner.
• Aggregation is the part-of relationship. It is like saying that a car has an engine and wheels as its parts.
• Aggregation 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. For example a package may be considered to aggregate its elements but an element may be referenced in more than one package.
• Aggregation and Composition are properties of an association role.
• Composition and Aggregation are also known as Composite Aggregation and Shared Aggregation.
• The association name is often excluded in aggregation and composition relationships since it is typically thought of as Has-part.
• If in doubt about Aggregation or Composition associations, leave them out.
• Consider showing aggregation or composition when:
  • The lifetime of the part is bound within the lifetime of the composite; there is a create-delete dependency of the part on the whole.
  • There is an obvious whole-part physical or logical assembly.
  • Some properties of the composite propagate to the parts such as the location.
  • Operations applied to the composite propagate to the parts such as destruction, movement, and recording.
• Discover and show aggregation because it has he following benefits:
  • It clarifies the domain constraints regarding the eligible existence of the part independent of the whole.
  • It assists in the identification of the creator using the GRASP Creator Pattern.
  • Operations such as copy and delete applied to the whole often propagate to the parts.
• Each end of an association is called role. They may optionally have name, multiplicity expression or navigability. If the role name is not present assume that the default role name is equal to the related class name through starting with a lower case letter. Note that the role name and the association name are two different subjects. Both can be present.
• In a domain model a real world role may be modeled in a number of ways like:
  • Roles in Associations are appealing because they are a relatively accurate way to express the notion that the same instance of a person takes on multiple roles in various associations.
  • Roles as concepts provide ease and flexibility in adding unique attributes, associations and additional semantics.
• A qualifier may be used in an association; it distinguishes the set of objects at the far end of the association based on the qualifier value. An association with a qualifier is a qualified association. A qualifier communicates how in the domain things of one class are distinguished in a relation to another. Qualification reduces the multiplicity at the far end form the qualifier usually down from many to one.
• A concept may have an association to itself this is known as a reflexive association.
• An association is represented as a line between classes with an association name.
• The association is inherently bi-directional.
• Each association has two association ends, each end is attached to one of the classes in the association.
• An association end has a multiplicity which is an indication of how many objects may participate in the given relationship.
• Multiplicity indicates lower and upper bounds for the participating objects. The * represents infinity.
• The ends of an association may contain multiplicity expression indicating the numerical relationship between instances of the classes.
• Multiplicity defines how many instances of a class A can be associated with one instance of a class B.

* zero or more; "many".

1..* one or more.

1..40 one to 40.

5 exactly 5.

3,5,8 exactly 3,5, or 8.

• Ordered elements are shown by placing the {ordered} constraint.
• The {bag} constraint is used to indicate that objects in a collection may appear more than once.
• The {hierarchy) constraint is used to indicate that the objects in a collection form a hierachy.
• The {dag} constraint is used to indicate a directed a cyclic graph.
• Frozen 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 object. The value must be set at object creation and may never change after that. The initial value may be null. When applied to a class frozen indicates that all association ends and attributes associated with that class are frozen. Frozen is not the same as read-only.

Attributes.

• An attribute is a logical data value of an object.
• Include the following attributes in a domain model: Those for which the requirements suggest or imply a need to remember information.
• Attributes in a domain model should be data types or simple attributes.
• Data types as Phone Number are known as value objects.
• If in doubt, define something as a separate conceptual class rather than as an attribute.
• Relate conceptual classes with an association, not with an attribute.
• If an attribute is composed of separate sections, has other attributes, is a quantity 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. Represent it in a distinct conceptual class.
• Attributes should not be used as foreign keys to relate conceptual classes.
• Numeric quantities should not be represented as plain numbers. Consider price or velocity, these are quantities with associated units and it is common to require knowing the unit and to support conversions. The solution is to represent the quantity as a distinct conceptual class. Since quantities are considered data types is valid to put their illustration into the attributes section of the class box.
• A Derived association and a derived attribute can be calculated from other associations and attributes respectively on a class diagram.
• To illustrate either a derived attribute or an association simply put a "/" before the name: /balance:Money or /entries.
• From the specification perspective a derived attribute indicate a constraint between values and not a statement of what is calculated and what is stored.
• A Derived Attribute is one that its value may be derived from other information.
• Avoid showing derived elements in a diagram since they add complexity without new information However add a derived element when it is prominent in the terminology and excluding it impairs comprehension.
• Reference Attribute is an attribute that refers to another complex object not to a primitive type. They are suggested by the associations and navigability in a class diagram.
• At the conceptual level attributes indicates that the concept has properties, at the specification level attributes indicates that the object'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.
• From the conceptual perspective there is no difference between an attribute and an association.
• The attribute notation is: visibility name : type = default value.
• There isn't a default visibility marker when an attribute or a method is shown without it. It implies "not specified".

Operations.

• Operations are the processes that a class knows to carry out.
• At the specification level operations correspond to public methods on a type.
• Operations that simply manipulate attributes must not be shown in a class diagram (getters and setters).
• With conceptual models operations shouldn't be used to specify the interface of a class.
• A query is an operation that gets a value form a class without changing the system state. Such operation can be marked with the constraint {query}.
• Modifiers are operations that do change the state of a class or system.
• A getting method returns a value from a field.
• A setting method puts value into a field.
• An operation is something that is invoked on an object (the procedure call), whereas a method is the body of the procedure.
• A feature is either an attribute or an operation.
• The syntax for operations is:
  • Visibility name (parameter-list) : return-type-expression {property-string}

where:

• • Name is a string.
  • Parameter-list contains a comma-separated parameters whose syntax is similar to that for attributes: direction name : type = default value.
  • Return-type-expression is a comma-separated list of return types.
  • Property-string indicates property values that apply to the given operation.
• A method body implementation may be shown in a UML note box. It should be placed within braces. The syntax may be pseudo-code or any language. It is common to exclude the method signature but it is legal to include it.
• Return or parameter types that represent a collection can be specified in any syntax.
• Abstract methods are shown with italics.
• The methods of each class can be identified by analyzing the interaction diagrams.

Polymorphism.

• Is a fundamental principle in designing how a system is organized to handle similar variations.

Business Rules.

• Also called Domain Rules they dictate how the domain or business may operate. Company policies, physical laws and government laws are common business rules. Business rules are not application requirements. Do not record system features as rules. They describe the constraints and behaviours of how the domain works, not the application.

CRC Cards.

• CRC Cards stands for Class Responsibility Collaboration cards.
• CRC cards are used to represent the responsibilities and the collaboration of a class with another classes.
• The sections of a CRC card are: class name, responsibility and collaboration. Each responsibility collaborates with one or more classes.
• CRC cards help to explore an interaction between classes.

Object Diagram.

• An object diagram shows instances instead of classes, it is often called instance diagram.
• Each name of an instance takes the form: instance name : class name. Both parts of the name are optional.

Contributors:

• Ezequiel Cuellar - prime
• cfw
• SZ