Week III Recap from Last Week Review Classes

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 1 2003. 09. 29

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: q Conceptual - how users think and talk about the world • • q the software, rather than the business Implementation - class - software component implementation • • ? semantics Specification - type - software component interface • q the terms & facts of the problem space -- the i. e. , the system glossary or domain model typically, business-focused 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. q Attributes – the “value facts” the system records the “variables” q Relationships between classes – 3 types: • • • q q 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.

Association Role properties ~ multiplicity

Associations in perspective q 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. ” q 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. ” q Implementation (e. g. , Java) • association = pointer specifications ("navigability") example: <refer to OOP lecture & also Fowler, p. 54 -56>

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

Domain Model Relationships: Generalization / Specialization

Domain Model relationships: Generalization / Specialization (cont) 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, q Employee • q Relationship Manager and Branch Manager • ? a supertype two, more-specialized types of Employee Subtypes "inherit" responsibilities from the supertype.

Generalization in perspective q Conceptual • generalization = a way of expressing "fact" hierarchies. e. g. , everything we say about an Employee is also true for a Relationship Manager. q 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. q Implementation (e. g. , Java) • generalization = inheritance features in a programming language

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

Domain Model Diagram Elements: rule elements

Class responsibilities: Rules definition A rule is a constraint or condition that limits or guides what an object can "know" or "do. " q Many (structure) rules are expressible using the graphical language. • q 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 (cont) ? It is good practice to summarize the Domain Model rules and provide to the stakeholders in a form they can readily review. q Standard rules • • • q initial value rules mandatory value rules unique value rules frozen value rules at-most-one rules [associations] Custom rules that are custom-written to support domain integrity requirements

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.