Information Systems Analysis and Design Class Modeling

Information Systems Analysis and DesignClass Modeling INFO 620 Glenn Booker Lecture #4

Operation vs Method vs Message • Operation: A service that can be requested from an object to effect behavior. An operation has a signature, which may restrict the actual parameters that are possible. (all from UML 1.5 spec) • Method: The implementation of an operation. It specifies the algorithm or procedure associated with an operation. Lecture #4

Operation vs Method vs Message • Message: A specification of the conveyance of information from one instance to another, with the expectation that activity will ensue. A message may specify the raising of a signal or the call of an operation. • So ‘message’ is the most abstract interaction description; which may call an ‘operation,’ which is implemented with a ‘method’ Lecture #4

Domain Model • The Domain Model is the highest level (most vague) class diagram for a system • Also known as the Conceptual Class Diagram • Looks similar to an ERD, but isn’t the same • It shows the classes, their associations, and attributes Lecture #4

Domain Model • This is not the level where actual software classes with specific responsibilities (methods) will be defined • Conceptual classes do NOT explicitly include things like databases (as in CustomerDatabase) or interfaces, and do NOT include responsibilities (methods) Lecture #4

Conceptual Class Diagram Lecture #4

Class Naming Conventions • Class and attribute names are singular (Sale, not Sales), and words are spelled out • Capitalization conventions: • Class names use initial capital letters for each word; no spaces between them (SalesLineItem) • Attributes use all lower case (date) • Associations use initial capital letters for the first word and dashes between words (Contained-in) Lecture #4

Formal Class Definition • Each class has three ways of describing it • Symbol which represents the class • Intension; a definition of the intent of the class • Extension; the set of all members of the class (e.g. every sale) • We mostly care about the class’ symbol and intension Lecture #4

How find Classes? • Structured analysis used functional decomposition (break down what the system needs to be able to do) to find entities • OOAD looks instead for concepts involved in the problem • Classes can be abstract and transient Lecture #4

Iterative Development • Classes are best found by looking at use case scenarios, and deciding what ideas are cited there • Expect many more classes than you would have entities for the same system • Some conceptual classes may not have any attributes – that’s okay! Lecture #4

Identifying Classes • Already mentioned using the use case scenarios for finding conceptual classes – look for noun phrases, then evaluate them • Is it an important concept for this system? • Is it an attribute of something bigger, or is it a self-contained idea or thing? Lecture #4

Identifying Classes • Also can use the list on pp. 134-135 for ideas (Table 10.1) • Notice that classes can be actions, transactions, or events, like BookingASeat • There is not a single correct list of classes for a problem Lecture #4

Identifying Classes • Use terminology for class names which is native to the system’s environment • Don’t make the customer learn new words for old ideas • Omit things which aren’t relevant to meeting the system’s requirements • When in doubt, make it a separate class Lecture #4

Description Conceptual Classes • Often it is needed to have a place for information about a thing – such as a product description • We tend to keep a class for such descriptions, in case all those things disappear (e.g. are sold) • So many sales or manufacturing systems will have a ProductDescription class type or ProductSpecification Lecture #4

UML versus RUP • The Rational Unified Process defines the Domain Model concept – it isn’t part of the UML per se • UML recognizes the class diagram concept, and defines the visual representation of it • The same diagramming concepts can be used for conceptual, specification, or implementation perspectives Lecture #4

Conceptual to Design Class • Many of the conceptual classes will eventually become classes in the Design Class Diagram • Others will get broken down into more detailed classes • The fact that we started using native terminology helps understand how the classes relate to the problem’s environment Lecture #4

Domain Model and the RUP • The domain model, or conceptual class diagram, is usually started and finished in the Elaboration phase of the RUP • It forms the basis for the Design Class Model and later Implementation Class Model • The Domain Model is a variation on the Business Object Model (BOM) Lecture #4

Adding Associations • An association is shows that there is a meaningful connection between two classes • Formally, it is: The semantic relationship between two or more classifiers that specifies connections among their instances. • Associations imply a relationship which may be kept for a second, or forever Lecture #4

Adding Associations • Associations are often from a need-to-know basis – e.g. we ‘need to know’ what line items were associated with a given sale • For a conceptual model with ‘n’ classes, there can be n*(n-1) possible associations • Which are significant? • Associations are assumed bidirectional for now – information can go both directions Lecture #4

Labeling Associations • Each association has a label to describe the association, and may use an arrow to indicate which way the label should be read • In Visio, can use ‘<‘ or ‘>’ in the label for the arrow Lecture #4

Finding Associations • Other than need-to-know basis, can find associations from the list on pp. 155-157 • The first four types shown may be aggregations, which we’ll discuss later • The known/logged type includes any form of recording data • “Organizational subunit” could be any kind of department • May not need to keep “uses or keeps” relations Lecture #4

Finding Associations • Most common association types are the physical or logical types (e.g. Register is physically located in Store), or when information is stored, recorded or captured (Register reports Sale) • Classes are more critical to identify than associations • Avoid too many associations Lecture #4

Roles • Each association describes a role (allowable behavior between the classes) • Roles may have names and multiplicity (we’ll add navigability later) • Multiplicity is like cardinality for an ERD • Here, more flexible • Multiplicity can give allowable ranges, specific values, or the classic 0/1/many Lecture #4

Multiplicity • Here ‘*’ means many, but by itself it means ‘0, 1, or many’ • ‘1..*’ means one or many • ‘1..40’ means a range from 1 to 40 • ‘n’ means only the value of ‘n’ • ‘a, b, c’ means only a, b, and c are allowable values Lecture #4

Multiplicity • To determine multiplicity, think of what values may be true at any one moment • Consider what multiplicity is meaningful from your system’s point of view • If your system will never handle the case of 0 multiplicity, don’t need 0 to show in the domain model Lecture #4

More on Naming Associations • General rule of thumb: If the association is oriented top to bottom, or left to right, don’t need to show an arrow • The name of an association is the class name, space, association label, space, then the other class name; e.g. from slide 20: • “Register Records-current Sale” is the association name Lecture #4

Multiple Associations • It is possible to show two associations between two classes, if the associations are handled very differently by the system • E.g. Flight Flies-to Airport andFlight Flies-from Airport Lecture #4

Cleaning up Associations • In general, we may define associations conceptually that don’t get implemented, or may later find associations we missed here • Whether an association is needed depends heavily on the system’s requirements • “Sale Initiated-by Customer” may be trivial for a gas station, but important for a grocery store which analyzes its regular customers Lecture #4

Cleaning up Associations • OTOH, might want to keep associations which reveal key information about the problem, even though we may never implement them • “Sale Initiated-by Customer” could be kept as a reminder of who starts the purchasing process Lecture #4

Adding Attributes • Attributes are data values which describe a class • Following the need-to-know concept, we want all attributes which we need to remember for our system • Attributes may be described by their type of data (particularly for non-primitive data types) Lecture #4

Attribute Types The primitive data types are in bold; others are non-primitive Lecture #4

Adding Attributes • Key to finding good attributes is to make sure each one is • A simple characteristic, • Which is uniquely defined by the class to which it belongs • Don’t worry about “keys” for defining associations to other classes; focus only on the characteristics of each class Lecture #4

Adding Attributes • If a potential attribute starts appearing complex, make it a separate class instead, and associate the two classes • Remember, this is an iterative process for finding attributes, so don’t be afraid to put down your best guess for now, and refine it later • When in doubt, make it a separate class Lecture #4

Avoid Implementation • Don’t worry how the attributes will be implemented in source code • The focus is still on describing the problem domain Lecture #4

Primitive vs Non-Primitive • Primitive data types are the most basic ways to represent data in a computer • Boolean, Date, Number, String, Time • Most complex data types are considered non-primitive Lecture #4

Non-Primitive Data Types • Use non-primitive if any of the following guidelines apply (p. 171): • Data has separate sections (phone) • There are operations associated with it (SSN) • It needs other characteristics (start/end date) • It has units (height) • Or any other complex concept (UPC) Lecture #4

Non-Primitive Data Types • So a credit card number could be a non-primitive data type, since it has • Type of card (Visa/MC/Discover) • Fixed length depending on type • Validation rules based on first digit • Non-primitive data can be shown as separate conceptual classes, or just flagged as specific data types Lecture #4

Format: Non-Primitive Data Types The Class is called ProductSpecification. One attribute is called ‘id’, which is of the non-primitive data type ‘ItemID’. Can show the same thing this way: Lecture #4

Attributes with Units • Things with units ($, ft., lb., etc.) need to be modeled with non-primitive data types • This helps support internationalization and conversion to other measurement systems (e.g. dollars to Euros, or English to SI units) Lecture #4

Derived Attributes • Some attributes may be derived from other information from that class or classes with which it’s associated • Denote derived attributes with a slash in front of the attribute name Lecture #4

Information Systems Analysis and Design Class Modeling