1 / 40

Information Systems Analysis and Design Class Modeling

Information Systems Analysis and Design Class Modeling. INFO 620 Glenn Booker. Operation vs Method vs Message.

hasad-mckee
Download Presentation

Information Systems Analysis and Design Class Modeling

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


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

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

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

  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

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

  6. Conceptual Class Diagram Lecture #4

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

More Related