Today in OOAD  The Domain Model Artifact UML Classes  EU-Bid Domain Model Exercise  EU-Lease Domain Model Assignment Guest Speaker  Kate Cunningham, Flexcar

Entity Class terminology  name from the glossary entry  attributes 'nominal' at first  operations later  not shown graphically  definition recorded in the Glossary  rules constraints (aka "business rules)

 the data contained in an object of the class A student ‘knows’ its name A course ‘knows’ how many students it can hold A person ‘knows’ his or her date of birth What are some attributes for EU-Bid and EU-Lease classes? What about class variables? The Domain Model ~ Attributes

The following things can be specified about an attribute:  name – noun or noun phrase (documented in the Glossary)  multiplicity o typically only 1 (“mandatory”) or 0..1 (“optional”)  initial value – is there a system-supplied value at birth?  changeability – is the value: changeable, frozen, or addOnly?  visibility – (same as for operations) encapsulation Implementation perspective: Attribute values are considered hidden; an attribute’s value must be requested. Specification perspective: We will treat all attributes as visible (“public” with an assumed accessor operation).  type – datatype (we will define this later) Attribute properties

The Domain Model ~ Associations  Next, show where one entity has to know about another entity….  Relationship Association Generalization Aggregation rents Are we taking a static or dynamic view? Does an attribute of Customer contain a Vehicle object (or collection of Vehicle objects)? What about navigability? What are the advantages and disadvantages of deciding about navigability at this stage?

informal definition: An association is the shared knowledge that classes have about their long-lasting connections. example: A customer “knows” its accounts. An course “knows” its enrolled-students. An order “knows” its order-lines. UML definitions: An association is the representation of a set of links between objects (instances of classes). A link is an instance of an association. The Domain Model ~ Associations

 Each association has 2 * participating classes. These are the classes at each end of an association line.  Each participating class is said to "play a role" in the association. Each role represents one "direction" in the association.  Multiplicities – How many objects may participate in the given relationship. An exact number, e.g., 27 A range of numbers 0..1, or 1, or …. An arbitrary, unspecified number * * Associations that: involve more than 2 classes, have their own properties, or are promoted to full class status (“reified”) are “advanced concepts” and not covered here. The Domain Model ~ Association Roles

The Domain Model ~ Associations & Association Role properties

Consider the problem of keeping track of courses and specific offerings at a BrandX university. Professors must be assigned to teach courses, students must register for courses, and professors receive rosters for each course they teach.  Working with the person next to you, draw a simple class model for this system. Note: the entities of interest in this system some relationships between entities some attributes for each entity some interesting behavior for each entity Example Domain Model – A university registration system

The following things can be specified about each role in an association:  role name  verb phrase  multiplicity  navigability  changeability The Domain Model ~ Association Role properties

 Each role can be given an explicit name (a "rolename"). example: An employee plays the role of “sales rep” to a customer.  The default rolename is the class name. example: An order is placed by a customer. o Here, “customer” is both the class name and the rolename. Association Role properties ~ rolename

 An explicit rolename is usually optional – used only when it adds clarity to a class’ participation in an association. as in the examples just given  BUT...  Sometimes a rolename is required. example: A flight segment involves two cities – a departure city and an arrival city. Here, at least one association end requires a rolename. Association Role properties ~ rolename

 various labeling schemes: verb-phrase (natural language sentence style) gerund (applying to the association as a whole)  useful as an aid in communication between analysts and with users.  optional in the UML Association Role properties ~ verb phrase

Each association role also has multiplicity.  Multiplicity specifies "how many?" objects of a class may participate in a given link. It indicates both a lower and an upper bound for the number of participating objects.  notation – an annotation next to the class at the far end of the association line. default is the range 0..infinity o or shorthand representation as simply * 0..* other commonly-used multiplicity values: o exactly one: 1 o at least one: 1.. * o at most one: 0..1 o explicit range (e.g., between 2 and 4, inclusive):2..4 Association Role properties ~ multiplicity

for now, in the Domain Model we will assume each association is "navigable in both directions“ Association Role properties ~ navigability & changeability

Class model A Class Model defines the static structure of concepts, types, and classes.  concept – how users think and talk about the world ~ the semantics  type – software component interface ~ the interface  class – software component implementation ~ the realization note: in many 00 languages, the notion of ‘class’ combines both ‘interface’ & ‘implementation.’ but the distinction is important!  "Program to a class's interface (type)rather than to its implementation."

Class models & the development process 3 perspectives we can take when defining a class model:  Conceptual the terms & facts of the problem space i.e., the system glossary or domain model typically, business-focused  Specification the software, rather than the business only the software "type" (the interface)  Implementation language-specific realization the implementation – "the classes that implement the type" (or, “implement the interface”) ~ one type (interface) specification can have multiple implementations.  This course deals with the “conceptual” and “specification” perspective class models; the Java course deals with the "implementation" perspective.

Class model diagram elements Class – a description of a set of objects that share the same responsibilities (attributes, relationships, operations, rules) and semantics.  Attributes – the “value facts” the system records the “variables”  Relationships between classes – 3 types: association generalization (supertype/subtype) aggregation (“advanced”)  Operations – the behavior the "methods"  Rules – the constraints that govern both structure (relationships & attributes) and behavior (operations). Many of these elements can be shown visually as a Class Model Diagram.

Class behavior – Operations informal definition: An operation specifies what an object can “do.” – i.e., the processes a class knows how to carry out, when requested. example: An ATM machine knows how to “accept a deposit.” A reservation knows how to “close a reservation.” UML definition: An operation is the specification of a transformation or query that an object may be called on to execute.

Associations in perspective  Conceptual association = "facts" in the users' problem space facts relate concepts, applying terms to form sentences. example: “Customers place orders.” “Orders may have several order lines.”  Specification association = responsibilities an object is "responsible to know" the other objects it is associated with. example: “A customer knows the orders it has placed.” “An order knows the customer who placed the order.”  Implementation (e.g., Java) association = pointer specifications ("navigability") example:

Association properties – navigability different treatment for each perspective:  Conceptual – typically left undefined/unannotated interpretation is “not applicable”/"undecided"  Specification – directional knowledge knowledge in both directions (bi-directional) is assumed typically drawn without navigation arrowheads  Implementation – navigation arrowhead means implementation pointer  Note: bi-directional navigation implies an additional constraint  The two navigations must be inverses of each other.  This is true for all three perspectives.

Domain Model Relationships: Generalization / Specialization

Generalization / Specialization is a feature of OO languages that permits an object's class to be specified as a hierarchy (or network) of classes, ranging from more general classes to very specific classes. typically referred to as simply "generalization" also referred to as "supertype / subtype" relationships For example,  Employee a supertype  Relationship Manager and Branch Manager two, more-specialized types of Employee  Subtypes "inherit" responsibilities from the supertype. Domain Model relationships: Generalization / Specialization (cont)

 Conceptual generalization = a way of expressing "fact" hierarchies. e.g., everything we say about an Employee is also true for a Relationship Manager.  Specification generalization = the interface of a subtype must include all elements from the interface of the supertype.  the subtype's interface conforms to the supertype's interface.  the principle of ‘substitutability’ applies.  Implementation (e.g., Java) generalization = inheritance features in a programming language Generalization in perspective

Domain Model relationships: Aggregation Terminology Aggregation Examples order + order item --> product reservation + reservation detail -> reservable item Terminology Aggregation

Domain Model Diagram Elements: rule elements

definition A rule is a constraint or condition that limits or guides what an object can "know" or "do."  Many (structure) rules are expressible using the graphical language. e.g., limiting a relationship to "at most one" or an attribute value to being “mandatory.”  When you need to express a rule that the graphics don't support, state the rule in a “note” or use braces { } surrounding the rule statement. write in informal natural language, or use a formal rule language, e.g., UML's Object Constraint Language (OCL). Class responsibilities: Rules

 It is good practice to summarize the Domain Model rules and provide to the stakeholders in a form they can readily review.  Standard rules initial value rules mandatory value rules unique value rules frozen value rules at-most-one rules [associations]  Custom rules rules that are custom-written to support domain integrity requirements Class responsibilities: Rules (cont)