SE 430 Object Oriented Modeling Dennis Mumaugh,

SE 430 Object Oriented Modeling Dennis Mumaugh, Instructor [email protected] Office: CDM, Room 428 Office Hours: Thursday, 4:00 – 5:30 September 29, 2016 SE 430: Lecture 4 1 of 99

Administrivia 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. September 29, 2016 SE 430: Lecture 4 2 of 99

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 September 29, 2016 SE 430: Lecture 4 3 of 99

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 September 29, 2016 SE 430: Lecture 4 4 of 99

Visitor Information Subsystem Visitor Information Subsystem Handheld Device Artifact Tracking Subsystem Exhibit Programs Tours Statistics September 29, 2016 SE 430: Lecture 4 5 of 99

Assignment 3 Due October 6, 2016 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 September 29, 2016 SE 430: Lecture 4 6 of 99

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 Using CRC Cards Reading list September 29, 2016 SE 430: Lecture 4 7 of 99

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." September 29, 2016 SE 430: Lecture 4 8 of 99

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 September 29, 2016 SE 430: Lecture 4 9 of 99

Big Picture Today September 29, 2016 SE 430: Lecture 4 10 of 99

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 nonanalysts. 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 September 29, 2016 SE 430: Lecture 4 11 of 99

Requirements Traceability September 29, 2016 SE 430: Lecture 4 12 of 99

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." September 29, 2016 SE 430: Lecture 4 13 of 99

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. September 29, 2016 SE 430: Lecture 4 14 of 99

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 REQ1 UC1 REQ 3 REQ4 X UC3 REQ6 X X X X UC5 September 29, 2016 REQ5 X UC2 UC4 REQ2 X SE 430: Lecture 4 15 of 99

Object-Oriented Analysis and Design September 29, 2016 SE 430: Lecture 4 16 of 99

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 September 29, 2016 SE 430: Lecture 4 17 of 99

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 September 29, 2016 SE 430: Lecture 4 18 of 99

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 Semantics September 29, 2016 SE 430: Lecture 4 19 of 99

Object-Oriented Domain Modeling September 29, 2016 SE 430: Lecture 4 20 of 99

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 September 29, 2016 SE 430: Lecture 4 21 of 99

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 September 29, 2016 SE 430: Lecture 4 22 of 99

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 September 29, 2016 SE 430: Lecture 4 23 of 99

Object-Oriented Domain Model September 29, 2016 SE 430: Lecture 4 24 of 99

Introduction 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? September 29, 2016 SE 430: Lecture 4 25 of 99

Decomposition “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 September 29, 2016 SE 430: Lecture 4 26 of 99

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. September 29, 2016 SE 430: Lecture 4 27 of 99

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. September 29, 2016 SE 430: Lecture 4 28 of 99

Which decomposition approach is better? From the perspective of completeness, algorithmic and object-oriented decompositions are roughly equivalent Algorithmic decomposition uncovers ‘objects’ as the byproduct 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 September 29, 2016 SE 430: Lecture 4 29 of 99

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 September 29, 2016 SE 430: Lecture 4 30 of 99

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 September 29, 2016 SE 430: Lecture 4 31 of 99

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. September 29, 2016 SE 430: Lecture 4 32 of 99

Domain modeling ‘Analysis’ ‘Design’ Use-case realizations Domain knowledge Key abstractions Invented abstractions captured in Analysis patterns Design class diagram captured in Design Model Domain model diagram Glossary Domain Model September 29, 2016 SE 430: Lecture 4 33 of 99

Domain Modeling Artifacts September 29, 2016 SE 430: Lecture 4 34 of 99

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). September 29, 2016 SE 430: Lecture 4 35 of 99

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! September 29, 2016 SE 430: Lecture 4 36 of 99

Basic domain model diagram notation Class icon Exhibit Association name or label Contains Association ArtifactDescription Uses ExhibitDescription Artifacts September 29, 2016 SE 430: Lecture 4 37 of 99

Objects September 29, 2016 SE 430: Lecture 4 38 of 99

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 September 29, 2016 SE 430: Lecture 4 39 of 99

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.) September 29, 2016 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 SE 430: Lecture 4 40 of 99

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 September 29, 2016 SE 430: Lecture 4 41 of 99

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 September 29, 2016 SE 430: Lecture 4 Object: flower on my desk Attributes: Name: Rose Smell: Sweet Color: Red Thorns: Yes 42 of 99

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” September 29, 2016 SE 430: Lecture 4 43 of 99

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 September 29, 2016 SE 430: Lecture 4 44 of 99

Classes in the software So the main problem in designing object oriented software is: How do we find the classes? September 29, 2016 SE 430: Lecture 4 45 of 99

Domain Model September 29, 2016 SE 430: Lecture 4 46 of 99

Building a domain model Tasks: 1. 2. 3. 4. 5. Identify conceptual classes. Draw the conceptual classes in a domain class diagram. Define or describe the conceptual classes in the glossary. Identify associations among conceptual classes. 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. September 29, 2016 SE 430: Lecture 4 47 of 99

Conceptual Classes September 29, 2016 SE 430: Lecture 4 48 of 99

What are conceptual classes? Pla ne tailNumber domain concept representation in an object-oriented programming language September 29, 2016 SE 430: Lecture 4 visualization of domain concept public class Pla ne { priva te String tailNumber; public List getFlightHistory() {.} } 49 of 99

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. September 29, 2016 SE 430: Lecture 4 50 of 99

What are conceptual classes? September 29, 2016 SE 430: Lecture 4 51 of 99

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. September 29, 2016 SE 430: Lecture 4 52 of 99

Conceptual class category list Larman* lists eighteen conceptual class categories. [see next pages] 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. September 29, 2016 SE 430: Lecture 4 53 of 99

Conceptual class categories Conceptual class categories are a way of helping identify domain objects, processes, and actors These conceptual class categories are adapted from Craig Larman, Applying UML and Patterns: An Introduction to ObjectOriented Analysis and Design and Iterative Development, 3rd edition, Prentice Hall, 2004 September 29, 2016 Conceptual Class Category Example Physical or tangible objects TouchScreen, PDA, HostPC Specifications, designs, or descriptions Consultation-Protocol Places PatientBed Transactions DrugDosage-Change Transaction line items OriginalDose, NewDose Roles of people Patient, PrimaryCarePhysician Containers RadiologyLab, OperatingRoom Contained items PatientMonitor, MRIUnit SE 430: Lecture 4 54 of 99

Conceptual class categories Conceptual Class Category Example Other collaborating systems Originating hospital, primary care physician's records Abstract nouns concepts QualityOfLife Organizations AMA, InsuranceCompany Events PatientAdmitDate, PatientDischargeDate Processes MedicalHistoryReview, PatientAdmission Rules and policies DischargePolicy Catalogs AllowedProcedures Records of finance, work, contracts, legal matters Receipt, PreAuthorization Financial instruments and services PatientAccount, PatientCharge Manuals, schedules, documents, references PhysiciansDeskReference September 29, 2016 SE 430: Lecture 4 55 of 99

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?” September 29, 2016 SE 430: Lecture 4 56 of 99

Analysis pattern example: party Person subtype of [0, 1] Telephone Number [0, *] [0, *] Party Address [0, 1] [0, *] subtype of Organization [0, 1] E-mail Address Party pattern can be used to model the borrower of an artifact. Adapted from Analysis Patterns by Martin Fowler. September 29, 2016 SE 430: Lecture 4 57 of 99

CRC cards September 29, 2016 SE 430: Lecture 4 58 of 99

Classes in the software The main problem in designing object oriented software is: how do we find the classes? September 29, 2016 SE 430: Lecture 4 59 of 99

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.] September 29, 2016 Template Class name Responsibility Collaborators Sample SE 430: Lecture 4 Data Server Proxy Responsibility Collaborators Get data requests Model Retrieve requested data Broker Return requested data Proxy Controller 60 of 99

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 September 29, 2016 SE 430: Lecture 4 61 of 99

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 September 29, 2016 SE 430: Lecture 4 62 of 99

Responsibilities 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” September 29, 2016 SE 430: Lecture 4 63 of 99

Collaborators 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 Librarian Check book out Check book in Search for book September 29, 2016 Book Book Borrower Borrower Check out Check in Know due date Know borrower SE 430: Lecture 4 Allowed to check out Book Know list of books checked out 64 of 99

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 September 29, 2016 SE 430: Lecture 4 65 of 99

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] September 29, 2016 SE 430: Lecture 4 66 of 99

Some tips on the CRC process Three to six participants - most Create a “discard pile” for out- 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 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 September 29, 2016 SE 430: Lecture 4 67 of 99

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 September 29, 2016 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 SE 430: Lecture 4 68 of 99

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 September 29, 2016 SE 430: Lecture 4 69 of 99

Conclusion 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 See Arlow and Neustadt, 8.4.2 September 29, 2016 SE 430: Lecture 4 70 of 99

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. September 29, 2016 SE 430: Lecture 4 71 of 99

Example An ATM System September 29, 2016 SE 430: Lecture 4 72 of 99

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. September 29, 2016 SE 430: Lecture 4 73 of 99

Identifying Classes ATM system - Potential Object List Software Banking Network Cashier ATM Consortium Bank Computer Account Transaction Cashier station Account data Transaction Data Bank September 29, 2016 Central Computer Cash Card User Cash Receipt System Recordkeeping provision Security provision Access Cost Customer SE 430: Lecture 4 74 of 99

Keeping the right classes Object Access Account Account data ATM Bank Computer Banking Network Cash Cash Card Cashier Cashier station Central Computer Consortium Cost Customer Receipt Recordkeeping provision Security Provision Software System Transaction Transaction Data User September 29, 2016 Elimination Reason Implementation * Attribute * * Vague Attribute * * * * * Irrelevant * Attribute Vague Vague Implementation Vague * Vague Redundant SE 430: Lecture 4 KEEP: Account, ATM, Bank, Bank Computer, Cash Cards, Cashier, Cashier Station, Central Computer, Consortium, Customer, Transaction 75 of 99

Class Associations September 29, 2016 SE 430: Lecture 4 76 of 99

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 September 29, 2016 SE 430: Lecture 4 77 of 99

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 September 29, 2016 SE 430: Lecture 4 78 of 99

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. September 29, 2016 SE 430: Lecture 4 79 of 99

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. Exhibit 1 Container Contains * Collection Artifact An Exhibit contains zero or more Artifact instances and an Artifact instance is contained in exactly one Exhibit. September 29, 2016 SE 430: Lecture 4 80 of 99

Class Attributes September 29, 2016 SE 430: Lecture 4 81 of 99

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) September 29, 2016 SE 430: Lecture 4 82 of 99

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. September 29, 2016 ArtifactDescription Non-primitive attribute Overview version Dimension ArtifactDescription height:Float width:Float depth:Float units: String uniqueID:String artist:String size: Dimension Detail version Attribute compartment format: attribute name:attribute type SE 430: Lecture 4 83 of 99

Attribute notation Address ItemID OK BAD Product Description 1 1 Store id manufacturerCode countryCode Product Description itemId : ItemID September 29, 2016 1 1 street1 street2 cityName . Store address : Address SE 430: Lecture 4 84 of 99

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] September 29, 2016 SE 430: Lecture 4 85 of 99

Domain Modeling - Main Features Class Association Aggregation Library Item User Borrows 0.* Address Member# Name Subscribe Unsubscribe External Reader Ext. Library Name No. Copies ShelfNo Status Title Issue Return Shelve Recorded Media Borrower Items Borrowed Maximum Loans Book Author ISBN Pub. Date Publisher September 29, 2016 Generalization SE 430: Lecture 4 CAL Package Distributor Course Text 86 of 99

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 September 29, 2016 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 SE 430: Lecture 4 87 of 99

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 September 29, 2016 SE 430: Lecture 4 88 of 99

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 accounts or from implicit verb phrases consortium consists of banks bank holds account or from knowledge of the problem domain cash card accesses accounts bank employs cashiers September 29, 2016 SE 430: Lecture 4 etc. etc. 89 of 99

Example: Initial Class Diagram 0.* Consists of Consortium Bank Owns Owns Central Computer 0.* Bank Computer Communicates with Employs 0.* Cashier Concerns Concerns Entered 0.* 0.* Has Cashier transaction Cashier Station Entered On 0.* Entered On Customer Accesses Communicates 0.* with 0.* 0.* September 29, 2016 Account Owns 0.* Communicates with ATM Holds 0.* Has Remote transaction SE 430: Lecture 4 0.* 0.* Cash Card 0.* Authorized by 90 of 99

Domain vs. Design Class Diagram September 29, 2016 SE 430: Lecture 4 91 of 99

Domain vs. Design Class Diagram September 29, 2016 SE 430: Lecture 4 92 of 99

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 September 29, 2016 SE 430: Lecture 4 93 of 99

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 Stein September 29, 2016 SE 430: Lecture 4 94 of 99

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 - . September 29, 2016 SE 430: Lecture 4 95 of 99

Glossary System glossary contains Words from conceptual model Classes Associations Attributes Use cases Names Actors Terminology from Requirements Problem statements Acronyms and terminology September 29, 2016 SE 430: Lecture 4 96 of 99

Glossary Example Glossary Term Category Comments or Definition: Buy Items Use case Description of the process of a customer buying items in a store Sale Type (Class) A sales transaction. SalesLineItem Type (Class) A line item for a particular item bought within a Sale SalesLineItem.quantity:Integ Attribute er September 29, 2016 SE 430: Lecture 4 The quantity of one kind of item bought. 97 of 99

Summary 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. September 29, 2016 SE 430: Lecture 4 98 of 99

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 Successful Robustness Analysis Function-Class Decomposition Assignments: Assignment 3 due October 6, 2016 September 29, 2016 SE 430: Lecture 4 99 of 99