1. SE 430 Object Oriented Modeling Dennis Mumaugh, Instructor dmumaugh@cdm.depaul.edu Office: CDM, Room 432 Office Hours: Thursday, 4:00 – 5:30 October 1, 2015SE 430: Lecture 41 of 97

2. October 1, 2015SE 430: Lecture 4Administrivia  Comments and feedback  Team project  By now you should have connected and started planning and work  All members should be communicating and working  Members drop out »What to do? »Notify me ASAP! »Reassign work; reduce scope of work – less use cases »Make sure all work is covered  Watch your schedule. 2 of 97

3. Assignment 1 - Discussion  Please bring a copy of your assignment solution to class for our discussions. Possible problems with solution  Implementation oriented not user oriented.  Do not provide solutions (e.g. Android or NFC or RFID); describe what is required.  Missed major feature(s): display exhibit info or exhibit programmes.  Missed idea of content authoring and did not address the subject  Domain objects sound like processes.  Confusion between VIS and other sub-systems; just what is the VIS  Subsystem interfaces:  Missed sub-systems or had unneeded systems  Added or invented subsystems beyond those defined  Artifact Lending not needed as an interface October 1, 2015SE 430: Lecture 4 3 of 97

4. October 1, 2015SE 430: Lecture 4 Assignment 1 - Discussion  Areas that tend to have problems  Hardware: GPS?  System Context  Project scope: »Discussed features »Assigned responsibilities ATS is not the only source of information on artifacts and exhibits. It is just a catalog of artifacts. Something else needs to keep details such as history, provenance, relationship to other artifacts and people  Actors: sub types (members/non-members)  Weak in many areas. Hard to understand just what is required.  Proofread your documents before submission. Print them out and read them slowly.  Many have problems with expressing themselves in English 4 of 97

5. October 1, 2015SE 430: Lecture 4 Visitor Information Subsystem Handheld Device Exhibit Programs Tours Statistics Artifact Tracking Subsystem Visitor Information Subsystem 5 of 97

6. October 1, 2015SE 430: Lecture 4 Assignment 3  Due October 8, 2015  Visitor Information Subsystem: Domain Model  Domain model: Produce a domain model for the Visitor Information Subsystem.  Deliverables  Conceptual (Domain) model diagram with associations & attributes  System glossary 6 of 97

7. October 1, 2015SE 430: Lecture 4 SE 430 – Class 4  Topics: Domain Model  Requirements Traceability  Object-Oriented Domain Modeling »Introduction to Objects, Classes and their relationships  Domain Modeling Artifacts  Conceptual Classes »How to build »CRC Cards »Class Associations »Class Attributes  System Glossary  Reading:  Arlow & Neustadt: Ch’s 6-9  The Problem Domain The Problem Domain  Using CRC Cards Using CRC Cards  Reading list 7 of 97

8. Thought for the Day "It's always harder than you originally think. If there's one thing I've learned about developing software, it's that if it looks easy, that's a warning sign." October 1, 2015SE 430: Lecture 48 of 97

9. October 1, 2015SE 430: Lecture 4 Last Time Topics:  Use-Case Model  Concepts and Background  The Use-Case Model in the Unified Process  Use-Case Workflow  Use-Case Techniques and Artifacts »Scenarios »High-level (summary) »Expanded (full-dress) »Use case diagrams  Ranking use cases  System Sequence Diagrams 9 of 97

10. October 1, 2015SE 430: Lecture 4 Big Picture Today 10 of 97

11. Use Cases and Requirement Lists  Advice: Create in parallel.  Enhance each other.  Alternate ways to explore, think, talk.  Use cases are a simple, familiar communication vehicle for non- analysts.  Reduces barriers to communication—very important!  Use cases help us focus on  The business value of using a system  The priorities of development  If we only create requirement lists, it is easier to lose sight of the important elements and their priority in terms of business value.  Use cases are awkward to record non-functional requirements.  The Supplementary Specification is suitable October 1, 2015SE 430: Lecture 4 11 of 97

12. Requirements Traceability October 1, 2015SE 430: Lecture 412 of 97

13. October 1, 2015SE 430: Lecture 4 Requirements Traceability  "The requirements traceability is the ability to describe and follow the life of a requirement, in both a forward and backward direction, i.e. from its origins, through its development and specification, to its subsequent deployment and use, and through periods of ongoing refinement and iteration in any of these phases." 13 of 97

14. October 1, 2015SE 430: Lecture 4 Requirements Traceability  Key idea  Everything has codes. FEA-1, UC1,...  Track how requirements trace to other artifacts, components, issues, change requests, tests,...  After developing the use cases, make a matrix of use cases vs. requirements and business rules  Each use case must satisfy at least one requirement  Each requirement must invoke at least one use case  Follow this into development and testing  Advice: Use a real requirements management (DOORS or Requisite Pro) and a change request tool (DDTS).  Alternative: Use a simple tool such as MS Access to create a database of elements and their relationships. 14 of 97

15. October 1, 2015SE 430: Lecture 4 Traceability Matrix  A matrix of Requirements and Use Cases  Number each Requirement and Each Use case  Show which requirement is satisfied by which use case REQ1REQ2REQ 3REQ4REQ5REQ6 UC1X UC2XX UC3X UC4XX UC5X 15 of 97

16. Object-Oriented Analysis and Design October 1, 2015SE 430: Lecture 416 of 97

17. Analysis  Analysis seeks to discover the vocabulary of the problem domain for the system under consideration:  Key abstractions of the domain  Key mechanisms of the domain  Analysis abstractions, their behavior, and their interactions define the conceptual model for the system’s problem domain  This is distinct from any conceptual model of the software solution—the software aspect is considered during design October 1, 2015SE 430: Lecture 4 17 of 97

18. Design  Design translates the conceptual model of analysis into a recipe for constructing the system  A recipe is descriptive—suitable for most systems—while a blueprint is prescriptive  Critical and outsourced systems likely require a blueprint approach  Design activities include:  Structuring the system within an architectural framework  Mapping analysis abstractions into software classes  Discovering and inventing software abstractions not present in the problem domain but needed for implementation  Assembling objects (class instances) into collaborations  Organizing classes into hierarchies October 1, 2015SE 430: Lecture 4 18 of 97

19. Basic modeling principle “ Models are not right or wrong, they are more or less useful.” – Martin Fowler “The map is not the territory.” – Alfred Korzybski, General SemanticsAlfred Korzybski October 1, 2015SE 430: Lecture 419 of 97

20. Object-Oriented Domain Modeling October 1, 2015SE 430: Lecture 420 of 97

21. Domain model definition  The domain model illustrates conceptual classes of the problem domain  A conceptual class is a concrete (e.g., an object) or non-concrete (e.g., a process) abstraction of an entity in the problem domain  Also (equivalently) referred to as a domain object  The domain model may include external software systems, if they are relevant and appropriate to the model  The domain model should not include software components within the system boundary of the existing or target systems October 1, 2015SE 430: Lecture 4 21 of 97

22. Domain model elements  A domain model is essentially a dictionary of the key abstractions in the problem domain  A domain model comprises two parts:  A visual dictionary  A textual dictionary  The visual dictionary component is called the domain model diagram  The textual dictionary component is called the glossary October 1, 2015SE 430: Lecture 4 22 of 97

23. Building a domain model  Tasks:  Identify the conceptual classes  Draw the conceptual classes in a domain model diagram  Define or describe the conceptual classes in the glossary  Identify associations among conceptual classes  If appropriate, identify attributes and behavior for conceptual classes  These tasks may be performed out of order in an opportunistic manner, in parallel, and/or incrementally and iteratively October 1, 2015SE 430: Lecture 4 23 of 97

24. Object-Oriented Domain Model October 1, 2015SE 430: Lecture 424 of 97

25. October 1, 2015SE 430: Lecture 4Introduction  The domain is the subject or problem area we are working with; it does not include technology (servers, devices, networks) or software (databases, etc.).  A Domain Model visualizes noteworthy concepts or objects in the domain.  It is a kind of “visual dictionary" of domain concepts.  Not a picture of software classes.  It helps us identify, relate and visualize important information.  It provides inspiration for later creation of software design classes, to reduce “representational gap.”  A classic object-oriented analysis activity.  What are the objects of interest in this domain?  their attributes?  their relationships? 25 of 97

26. October 1, 2015SE 430: Lecture 4Decomposition “All Gaul is divided into three parts”, Caesar's Commentaries on the War in Gaul, Julius Caesar  Analyzing a complex problem cannot be done by viewing the problem as a single piece  Decomposition breaks a system down into smaller, more manageable pieces  Identify the largest pieces first and how they interact  Look at the individual pieces and decompose them into smaller pieces and their interactions  Keep decomposing until you reach a point of diminishing returns 26 of 97

27. October 1, 2015SE 430: Lecture 4 Role of decomposition in O-O modeling  Algorithmic (or procedural) decomposition breaks a system down by procedures to be performed  Basic component corresponds to a step in a larger process.  Object-oriented decomposition breaks a system down into objects  Basic component is an ‘autonomous agent’ rather than a process step.  An agent is a more-or-less active entity in the system.  Agents have state and behavior.  Agents collaborate to produce higher-level behavior. 27 of 97

28. October 1, 2015SE 430: Lecture 4 Algorithmic vs. O-O decomposition  There is no ‘right’ way to decompose a system.  Algorithmic approach incorporates objects through things acted upon or passed in data flows.  O-O incorporates algorithmic elements through object behavior.  O-O decomposition seems to be an effective approach.  Objects are concrete while processes are abstract.  Active object behavior is often easier to ‘simulate’ in thought experiments than sequences of processing steps. 28 of 97

29. October 1, 2015SE 430: Lecture 4 Which decomposition approach is better?  From the perspective of completeness, algorithmic and object-oriented decompositions are roughly equivalent  Algorithmic decomposition uncovers ‘objects’ as the by- product of uncovering the processes: the things acted upon  Object-oriented decomposition uncovers the ‘processes’ as the by-product of object behavior and collaboration  Algorithmic decomposition works well for problems in which the model of computation has a nearly linear structure  Example: Most mathematical modeling problems  Object-oriented decomposition works well for problems in which the model of computation has a networked structure  Examples: Most simulations and enterprise applications 29 of 97

30. October 1, 2015SE 430: Lecture 4 When to stop decomposing?  Object-oriented decomposition can yield a large number of manageable pieces, but:  When is the point of ‘diminishing returns’ reached?  How can the effectiveness of the decomposition be judged?  The point of diminishing returns is reached:  When each piece is responsible for one specific aspect of the whole system  The piece cannot be logically decomposed further  The effectiveness of the decomposition can be judged by the coherence of each abstraction 30 of 97

31. October 1, 2015SE 430: Lecture 4 Responsibilities and coherence  Coherence is an abstraction metric that measures how well-focused are the properties of that abstraction  Properties include attributes, operations, and relationships  The responsibilities of an abstraction and its coherence go hand-in-hand  A coherent abstraction is responsible for one aspect of the system and all of its properties support this responsibility  Coherence can also be thought of as a ‘just right’ principle: a coherent abstraction has just the properties needed to fulfill its responsibilities, no more and no less 31 of 97

32. October 1, 2015SE 430: Lecture 4 Role of abstraction in O-O modeling  Abstraction helps us deal only with the most essential aspects of an entity.  Objects concentrate ‘usable’ information by representing tangible or intangible things in the real world.  These ‘real-world’ entities provide leverage in the form of analogous or metaphorical behavior. 32 of 97

33. October 1, 2015SE 430: Lecture 4 Domain modeling 33 of 97

34. Domain Modeling Artifacts October 1, 2015SE 430: Lecture 434 of 97

35. October 1, 2015SE 430: Lecture 4 What is a domain model?  A domain (or conceptual) model is a dictionary of key abstractions composed of two parts:  A visual component.  A textual component.  Visual dictionary consists of domain model diagram.  Textual dictionary consists of glossary.  Domain model illustrates meaningful conceptual classes or real-world objects of the problem domain.  Domain model includes the system that is being analyzed.  Domain model shows how system relates to actors, objects, and processes around it.  Note that this is at odds with Larman!  However, does not describe software classes or software objects (other software systems are OK). 35 of 97

36. October 1, 2015SE 430: Lecture 4 Domain model diagram components  Three main components:  Domain objects or conceptual classes. (High importance)  Associations among conceptual classes. (Medium importance)  Attributes of conceptual classes. (Low importance)  Uses the most basic standard UML class diagram notation  You should not incorporate more advanced or more detailed design-level class diagram notation in the domain model diagram! 36 of 97

37. October 1, 2015SE 430: Lecture 4 Basic domain model diagram notation 37 of 97

38. Objects October 1, 2015SE 430: Lecture 438 of 97

39. October 1, 2015SE 430: Lecture 4 What is an object?  Object are “things”  Concrete, real-world objects »The Mayor of Chicago ["da mare"] »The display projector in this room »The primary [telephone] trunk between St. Louis and Kansas City »My telephone bill for last month  More abstract, “internal to the system” objects »The financial project number for your current project »The “TCP connection” between my PC and mail server when I checked my email this morning 39 of 97

40. October 1, 2015SE 430: Lecture 4 Attributes and Behavior Attributes are the “data” part of an object:  the values of the attributes define the internal state of the object An insurance policy object has the following attributes:  name of insured  name of beneficiary or beneficiaries  policy value  list of covered events (accident, illness, fire, tornado, flood, etc.) Behavior is the “action” part of an object:  the behavior is a “list of services” that the object can do for others An insurance policy object has the following behaviors:  purchase  cancel  receive premium payment  accept claim  dispense claim payment 40 of 97

41. October 1, 2015SE 430: Lecture 4 Objects in the software  It is difficult to put a “real-world” object into a computer  But objects are still a useful concept for software development Object: flower on my desk Attributes: Name: Rose Smell: Sweet Color: Red Thorns: Yes 41 of 97

42. October 1, 2015SE 430: Lecture 4 Objects in the software  Some objects of interest are only “in the computer”  Many real-world objects can be (partially) simulated by software  Software objects usually contain a bunch of attributes  The attributes might be stored in a block of memory as a “struct” (or “record” or whatever your programming language uses to define chunks of memory with a mixture of data fields)  The “behavior” is implemented by functions that can read and/or modify the attributes Object: flower on my desk Attributes: Name: Rose Smell: Sweet Color: Red Thorns: Yes 42 of 97

43. October 1, 2015SE 430: Lecture 4 What is a Class?  Classes are descriptions of categories of objects  Examples: person, display device, trunk, telephone bill  In a software system, each class is described by listing its “data attributes” and “behaviors” 43 of 97

44. October 1, 2015SE 430: Lecture 4 Classes in the software We usually write software in terms of classes (rather than objects)  A single class declaration might describe thousands of objects (each object is an “instance” of the class)  The number of classes in our system is usually much smaller than the number of objects  The “data structure” (the list of attributes) for each object in a class is the same  The “responsibilities” (the list of behaviors in the “public interface” – the functions that are within the class that can be invoked by software outside of the class) for each object in a class are the same 44 of 97

45. October 1, 2015SE 430: Lecture 4 Classes in the software So the main problem in designing object oriented software is:  How do we find the classes? 45 of 97

46. Domain Model October 1, 2015SE 430: Lecture 446 of 97

47. October 1, 2015SE 430: Lecture 4 Building a domain model  Tasks: 1. Identify conceptual classes. 2. Draw the conceptual classes in a domain class diagram. 3. Define or describe the conceptual classes in the glossary. 4. Identify associations among conceptual classes. 5. If appropriate, identify attributes for conceptual classes.  As with other activities in the Unified Process, these tasks may be performed out of order, in parallel, incrementally, and iteratively. 47 of 97

48. October 1, 2015SE 430: Lecture 4 Conceptual Classes 48 of 97

49. October 1, 2015SE 430: Lecture 4 What are conceptual classes? Plane tailNumber public class Plane { private String tailNumber; public List getFlightHistory() {...} } domain concept visualization of domain concept representation in an object-oriented programming language 49 of 97

50. October 1, 2015SE 430: Lecture 4 What are conceptual classes?  Conceptual classes are the key abstractions of the problem domain.  Provide the vocabulary for describing the domain.  A conceptual class consists of:  Symbol. Representation of the conceptual class. For name, follow standard O-O class and instance naming and case conventions.  Intension. Definition of the conceptual class. »Note: This is a non-standard term, so use ‘definition’ instead. »Put this definition into the glossary  Extension. Represents all instances (examples) of the conceptual class. Examining more different instances usually leads to better abstraction. 50 of 97

51. October 1, 2015SE 430: Lecture 4 What are conceptual classes? 51 of 97

52. October 1, 2015SE 430: Lecture 4 Finding conceptual classes  You have discovered many conceptual classes in previous work: domain objects, processes, and actors from system context description.  Noun phrase identification is a technique that has some utility in identifying candidate conceptual classes.  Look for noun (phrases) in requirements documents and use cases  The conceptual category list (Larman pp. 140-141 ) provides a checklist of categories intended to cover most important types of conceptual categories.  Analysis pattern catalogs can provide another source of key abstractions in the form of reusable or analogous abstractions. 52 of 97

53. Conceptual class category list  Larman lists eighteen conceptual class categories*. [See lecture 2, slides 76-77]  Many are fairly obvious and straightforward: physical or tangible objects, places, organizations, etc.  Several are often overlooked but very useful:  Specifications. Provide a template for describing aspects of another conceptual class.  Rules and policies. Often capture the ‘intelligence’ in a domain process. »Example: Security access qualifications for Museum user.  Events. Significant occurrences, usually within a relatively short or fixed time window. »Example: Fire notification or alarm.  Transactions. Encapsulate related events. »Example: Transaction of loaning artifact to another museum. October 1, 2015SE 430: Lecture 4 53 of 97

54. October 1, 2015SE 430: Lecture 4 Sidebar: specification conceptual classes  Specification conceptual classes retain important information about another conceptual class, the ‘specified’ class.  Specifications act as ‘an abstraction of an abstraction’:  A specified conceptual class may have zero or more instances, but needs to have its important characteristics preserved separate from class instances.  Specification class retains important class characteristics, even if no instances of the specified class exist. Example: A climate requirements specification captures the essential climate parameters (temperature, humidity, lighting) for an artifact even if there are no actual artifacts. Answers the question “What makes up an artifact climate requirement?” 54 of 97

55. October 1, 2015SE 430: Lecture 4 Analysis pattern example: party Party pattern can be used to model the borrower of an artifact. Adapted from Analysis Patterns by Martin Fowler. 55 of 97

56. CRC cards October 1, 2015SE 430: Lecture 456 of 97

57. October 1, 2015SE 430: Lecture 4 Classes in the software  The main problem in designing object oriented software is:  how do we find the classes? 57 of 97

58. October 1, 2015SE 430: Lecture 4 CRC cards  Low-tech approach to identifying and capturing important elements of abstractions.  How to use:  Use notecards or Post-It Notes.  Identify abstractions (class).  Identify responsibilities– succinct, specific descriptions of the purpose of the abstraction.  Identify collaborators–other abstractions needed to fulfill responsibilities.  Excellent tool for use in design scenarios [Additional commentary is in the notes section.] 58 of 97

59. October 1, 2015SE 430: Lecture 4 CRC Cards CRC Cards characterize objects by  Class Name  Responsibilities (Tasks an object can do alone because of its local knowledge)  Collaborator names (Tasks done by other objects because of their knowledge) CRC Card Procedure  Create cards for each relevant object  external actors initiating a message to the system »the first object that receives the message »every object from the domain used in the solution of a use case. (Put unused cards off to the side)  Walk through the handling of a system event  Allocate responsibilities by deciding which class handles an event or delegates it to another object 59 of 97

60. October 1, 2015SE 430: Lecture 4 CRC Cards CRC Card Procedure (cont.)  Put the main responsibilities of each class on the card.  Put the collaborators of each class on the card  When assigning responsibilities, it may be necessary to  Add responsibilities to existing Classes  Create new Classes to handle new functions  Reallocate responsibilities when a Class becomes too complex 60 of 97

61. October 1, 2015SE 430: Lecture 4Responsibilities  A responsibility is a service that a class provides to the rest of the system  responsibilities are usually “verbs” or “verb phrases”  each class should have a small number of responsibilities »usually more than one »never more than can comfortably fit on the lines of one of your index cards  the implementation details of a responsibility aren’t important yet  A responsibility is not an operation that a class performs on an object of a different class  for example, in a “track meet” system, a Stopwatch class may have responsibilities like “start timing”, “stop timing”, “reset to zero”, and “report current time”, but not “post winning time on the scoreboard” 61 of 97

62. October 1, 2015SE 430: Lecture 4 Book Check out Check in Know due date Know borrower Librarian Check book out Check book in Search for book Book Borrower Allowed to check out Know list of books checked out BookCollaborators  An object may call upon the responsibilities of other objects during the execution of its responsibilities: these other objects are “collaborators”  Example:  In a library system, there are three important classes: Book, Librarian, and Borrower  The Librarian class needs to collaborate with Book and Borrower in order to check books in and out 62 of 97

63. October 1, 2015SE 430: Lecture 4 Starting a CRC card session  CRC sessions start as brainstorming  Identify some candidate classes by writing down a list of some “nouns” from the problem area  Pick some of the nouns that have some responsibilities: write them down on cards  Write a simple sentence on the back of each card - a short description of the class  Think of “scenarios”  could be based on some of the use cases  or there might be internal system scenarios  Act out the scenarios as a group  write down new responsibilities and collaborations that you discover 63 of 97

64. October 1, 2015SE 430: Lecture 4 Choosing good class names  One of the hardest parts of the object oriented analysis/design process is choosing the names of the classes  choose clear and unambiguous names  keep the names simple; eliminate unnecessary words  use technical terms in the language of the appropriate domain  ensure that the names have the right level of abstraction  Examples of mediocre class names:  Transaction [too “generic”]  Customer server object [the word “object” is superfluous] 64 of 97

65. October 1, 2015SE 430: Lecture 4 Some tips on the CRC process  Three to six participants - most should have some knowledge of the problem area  Make the scenarios concrete and specific  Example: “Sam checks out the book C++ for dummies”  Each participant should play the role of one or more objects, and should pick up the card for the object’s class while acting out the scenarios  Create a “discard pile” for out- of-date cards (when eliminating, splitting, or rewriting classes)  Recording scenarios: use the sequence diagram notation to write down each scenario  Each arrow in the sequence diagram (covered later) should contain the name of a responsibility 65 of 97

66. October 1, 2015SE 430: Lecture 4 More practical CRC session ideas  Use a single pen for making all changes to the cards  this forces everyone to discuss the changes to the cards, and prevents multiple simultaneous changes  If you disagree with another team member, try to turn your objection into a scenario  Redistribute the cards among the team members periodically during the session  If most of the responsibilities on your cards are “has”, “get”, and “set” – you may be taking too much of a data-oriented view  Ask yourself why the object has another object in it – the answer to that “why” question may point out one or more responsibilities for the card 66 of 97

67. October 1, 2015SE 430: Lecture 4 Terminating a CRC card session  You know when you are done if you have covered all the use cases  You should evaluate the “cohesion” of each class and the amount of “coupling” between classes  At the end of the meeting, you should have a stack of cards plus a list of scenarios  the information on the cards can recorded in several ways »text document »a special CRC card tool »a “class diagram” (in UML notation, for example)  the detailed scenario documentation (in the form of sequence diagrams) can be done by individual team members outside of the meeting 67 of 97

68. October 1, 2015SE 430: Lecture 4Conclusion  CRC cards are another useful step that precedes creating design  CRC cards are a good method for brainstorming objects  good for getting an overall view of the architecture  the main emphasis is the “behavior” of the objects  planning the internal “data structure” part is suppressed  no CASE tools are needed  CRC cards only give a partial view of the classes  just a list of responsibilities and collaborations (plus some scenarios)  you need to add information about data  more detailed information about the behavior of the classes is also needed  Original paper by Beck and Cunningham at http://c2.com/doc/oopsla89/paper.html http://c2.com/doc/oopsla89/paper.html  See Arlow and Neustadt, 8.4.2 68 of 97

69. October 1, 2015SE 430: Lecture 4 Identifying classes  Identifying classes  From the nouns in the problem description and statements, and Domain objects  From the nouns in the Use Cases  From the CRC exercise  Eliminate the »Redundant »Irrelevant – those unrelated to the problem »Vague – ill-defined boundary, very broad in scope »Attributes – things that describe an object »Operations – things that manipulate objects »Implementation constructs – extraneous to real world must be eliminated from analysis model, needed during design, but not now. 69 of 97

70. Example An ATM System October 1, 2015SE 430: Lecture 470 of 97

71. October 1, 2015SE 430: Lecture 4 Example - Problem Statement for ATM Design the software to support a computerized banking network including both human cashiers and automated teller machines (ATMs) to be shared by a consortium of banks. Each bank provides its own computer to maintain its own accounts and process transactions against them. Cashier stations are owned by individual banks and communicate directly with their own bank computers. Human cashiers enter account and transaction data. ATM’s communicate with a central computer that clears transactions with the appropriate banks. An ATM accepts a cash card, interacts with the user, communicates with the central system to carry out the transaction, dispenses cash and prints receipts. The system requires appropriate record keeping and security provisions. The system must handle concurrent accesses to the same account correctly. The banks will provide their own software for their own computers; you are to design the software for the ATM's and the network. The cost of the shared system will be apportioned to the banks according to the number of customers with cash cards. 71 of 97

72. October 1, 2015SE 430: Lecture 4 ATM system - Potential Object List Identifying Classes  Software  Banking Network  Cashier  ATM  Consortium  Bank Computer  Account  Transaction  Cashier station  Account data  Transaction Data  Bank  Central Computer  Cash Card  User  Cash  Receipt  System  Recordkeeping provision  Security provision  Access  Cost  Customer 72 of 97

73. October 1, 2015SE 430: Lecture 4 KEEP: Account, ATM, Bank, Bank Computer, Cash Cards, Cashier, Cashier Station, Central Computer, Consortium, Customer, Transaction Keeping the right classes 73 of 97

74. October 1, 2015SE 430: Lecture 4 Class Associations 74 of 97

75. October 1, 2015SE 430: Lecture 4 What are class associations?  A class association is a relationship between two classes.  Represents some symbolic relational (‘semantic’) dependency.  Associations are not essential in the domain model diagram, but they can be very helpful  Include associations to capture a significant relationship between two or more conceptual classes.  Don't struggle to include associations if they are not significant or otherwise readily discovered 75 of 97

76. October 1, 2015SE 430: Lecture 4 Finding class associations  As with conceptual classes, you have encountered class associations in previous work:  Subsystem Project Statement.  Within use cases.  Like the conceptual class category list, the common associations list (Larman* pp. 155-156) provides a checklist of association categories.  Analysis pattern catalogs are another source of associations among conceptual classes. * Craig Larman, Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development, 3rd edition, Prentice Hall, 2004 76 of 97

77. October 1, 2015SE 430: Lecture 4 Common associations list  Larman lists sixteen common association categories.  The obvious associations include: physical part of, physically contained in, and uses or manages.  Some of the more subtle ones are:  Logical part and containment. Relate ‘business objects’ which are logical rather than physical. Example: A reservation is a logical part of an artifact calendar.  Captured in/by. Often acts as an adjunct to other associations. Example: An alarm is captured in the event log.  Event or Event generated by. Provides a means of documenting events. Example: A fire notification is an event generated by a smoke detector. 77 of 97

78. October 1, 2015SE 430: Lecture 4 Association notation  Association names can be drawn from the domain or from the common associations list.  Cardinality (multiplicity) defines the number of instances that may reside on association. Most common: one-to-one, one-to-many, many-to-many  Roles define a direction on an association and add clarification. An Exhibit contains zero or more Artifact instances and an Artifact instance is contained in exactly one Exhibit. 78 of 97

79. Class Attributes October 1, 2015SE 430: Lecture 479 of 97

80. October 1, 2015SE 430: Lecture 4 What are class attributes?  An attribute represents a characteristic of a conceptual class  In conceptual classes, an attribute should be represented by a simple or fundamental type  Examples: String, int, etc.  Non-fundamental attributes can be converted to associations and vice versa  Consider attributes as a specialized form of association that captures an intrinsic characteristic of a conceptual class  Example: A Cost attribute has both a value (e.g. 129.95) and a currency unit (e.g. US$, £, €)  Important! For clarity during analysis, identify all non-fundamental attributes of a domain class by an association with another domain class [use a class for non-fundamental types] ( see next slides)  Limit attributes to fundamental data types; classes are not attributes (E.g. Lists) 80 of 97

81. October 1, 2015SE 430: Lecture 4 Attribute notation  Display essential or defining attributes of the class.  Don't struggle to include attributes if they are not essential or otherwise readily discovered!  Attribute names should be unambiguous–it should be clear what they are representing.  Omitting attribute compartment makes no statement about presence/absence of attributes; empty compartment does. Attribute compartment format: attribute name:attribute type Non-primitive attribute 81 of 97

82. October 1, 2015SE 430: Lecture 4 Attribute notation 82 of 97

83. October 1, 2015SE 430: Lecture 4 Class Diagrams  Class diagrams contain information about the data and operations of each class  Class diagrams also contain relationships  ordinary associations are labeled with the “purpose” for which the two classes are connected  aggregations (a special kind of association) are used to describe a containment hierarchy (or a “whole-part” relationship)  ordinary associations and aggregation can have cardinality labels  generalization-specialization relationships describe the relationship between superclasses and subclasses [usually we defer to the design diagram, on domain models it is generally too early to do this] 83 of 97

84. October 1, 2015SE 430: Lecture 4 Domain Modeling - Main Features 84 of 97

85. October 1, 2015SE 430: Lecture 4 Tips for good Class diagrams Data attributes  stick to the “essential data”: detailed definition of the data structures is supposed to be a design-level task Operations  some operations are obvious, so put them into the model  others will be filled in later (after you start doing state modeling and/or more detailed scenarios)  the operations define the set of services that the class will provide Associations  ordinary associations are drawn between “peer” classes – classes at the same semantic level  verify (using scenarios) that each association is necessary; also check if each operation can get to the objects it needs (and add associations if needed)  check the cardinalities: if an association is “conditional”, the cardinality label might need to be 0..1 or 0..* rather than 1 or 1..*  use the “is-a” test to check subclasses 85 of 97

86. October 1, 2015SE 430: Lecture 4 Tips for good Class diagrams  Operations  Get and put are useful but should not be used much  Use things like »Enter information into a form, one method with several arguments rather than several puts »Print form rather than several gets and something else doing the work  Classes own their data; they need to operate on it including presentation and update 86 of 97

87. October 1, 2015SE 430: Lecture 4 Identify Associations  Associations correspond to verbs in the problem statement  Association = any dependency between two classes  form verb phrases involving identified classes  consortium shares ATMs  bank provides bank computer  bank computer maintains accountsetc...  or from implicit verb phrases  consortium consists of banks  bank holds accountetc...  or from knowledge of the problem domain  cash card accesses accounts  bank employs cashiers 87 of 97

88. October 1, 2015SE 430: Lecture 4 Example: Initial Class Diagram ConsortiumBank Account Customer Cash Card Central ComputerBank ComputerCashier Cashier Station Cashier transaction Remote transaction ATM Consists of Holds Communicates with Has Owns Entered On Concerns Authorized by Has Accesses Entered On Communicates with Owns Communicates with Owns Employs Entered 0..* 88 of 97

89. October 1, 2015SE 430: Lecture 4 Domain vs. Design Class Diagram 89 of 97

90. October 1, 2015SE 430: Lecture 4 Domain vs. Design Class Diagram 90 of 97

91. October 1, 2015SE 430: Lecture 4 Developing Static Models - Summary  Identify the main use cases and write down descriptions of these  Identify the main elements of information that must be stored.  Identify the main actors with which the system must interact.  Identify objects and classes  Identify associations between classes  Creating object model segments for each Use-case.  Identify attributes for classes  Merge the object model segments to create an overall object model for the system  Organize and simplify classes using inheritance  Test the model and it's relationships by performing walk-through using, for example, use cases  Iterate and refine the models 91 of 97

92. Glossary “ What's in a name? That which we call a rose by any other name would smell as sweet;” – William Shakespeare “A rose is a rose is a rose!” – Gertrude St ein October 1, 2015SE 430: Lecture 492 of 97

93. October 1, 2015SE 430: Lecture 4 Object Modeling - Data Dictionary Prepare a Data Dictionary/Description of each class  Account - a single account in a bank against which transactions can be applied. Accounts may be of various types, at least checking or saving. A customer can hold more than one account.  ATM - a station that allows customers to enter their own transactions using cash cards as identification. The ATM interacts with the customer to gather transaction information, sends the transaction information to the central computer for validation and processing, and dispenses cash to the user.  Bank - …………. 93 of 97

94. October 1, 2015SE 430: Lecture 4Glossary System glossary contains  Words from conceptual model  Classes  Associations  Attributes  Use cases  Names  Actors  Terminology from  Requirements  Problem statements  Acronyms and terminology 94 of 97

95. October 1, 2015SE 430: Lecture 4Glossary Example Glossary TermCategoryComments or Definition: Buy ItemsUse caseDescription of the process of a customer buying items in a store SaleType (Class)A sales transaction. SalesLineItemType (Class)A line item for a particular item bought within a Sale SalesLineItem.quantity:Inte ger AttributeThe quantity of one kind of item bought. 95 of 97

96. October 1, 2015SE 430: Lecture 4Summary  The domain (or conceptual) model contains the static information about the problem area under analysis.  It has two elements  The domain (class) diagram  The glossary  These provide the basis for the (eventual) design class diagram. 96 of 97

97. October 1, 2015SE 430: Lecture 4 Next Class Topic: Transition to Design: System architecture; Design scenarios; The Human Computer Interface: Tiered Architecture – Robustness Analysis; Function-Class Decomposition Reading:  Arlow & Neustadt, Ch’s. 8.4.3, 16, 19  Responsibility-based Modeling Responsibility-based Modeling  Successful Robustness Analysis Successful Robustness Analysis  Function-Class Decomposition Function-Class Decomposition Assignments:  Assignment 3 due October 8, 2015 97 of 97