1. 2003.09.291 Week III  Recap from Last Week Review Classes Review Domain Model for EU-Bid & EU-Lease Aggregation Example (Reservation) Attribute Properties / Standard rule categories (see rules for EU-Bid for examples)  New Material Use Cases, Part I Understanding the Business Dynamics

2. Class models & the development process -- A Class Model defines the static structure of concepts, types, and classes. 3 perspectives we can take when defining a class model:  Conceptual - how users think and talk about the world the terms & facts of the problem space -- the semantics i.e., the system glossary or domain model typically, business-focused  Specification - type - software component interface the software, rather than the business  Implementation - class - software component 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.

3. 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.

4. Association Role properties ~ multiplicity

5. 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:

6. 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.

7. Domain Model Relationships: Generalization / Specialization

8. 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)

9.  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

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

11. Domain Model Diagram Elements: rule elements

12. 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

13.  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)

14. 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.