SE 430 Object Oriented Modeling

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

2. 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. SE 430: Lecture 4

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 SE 430: Lecture 4

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 SE 430: Lecture 4

5. Visitor Information Subsystem Visitor Information Subsystem Handheld Device ArtifactTracking Subsystem Exhibit ProgramsTours Statistics SE 430: Lecture 4

6. 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 SE 430: Lecture 4

7. 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 SE 430: Lecture 4

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." SE 430: Lecture 4

9. 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 SE 430: Lecture 4

10. Big Picture Today SE 430: Lecture 4

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 SE 430: Lecture 4

12. Requirements Traceability SE 430: Lecture 4

13. 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." SE 430: Lecture 4

14. 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. SE 430: Lecture 4

15. 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 SE 430: Lecture 4

16. Object-Oriented Analysis and Design SE 430: Lecture 4

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 SE 430: Lecture 4

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 SE 430: Lecture 4

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 Semantics SE 430: Lecture 4

20. Object-Oriented Domain Modeling SE 430: Lecture 4

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 SE 430: Lecture 4

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 SE 430: Lecture 4

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 SE 430: Lecture 4

24. Object-Oriented Domain Model SE 430: Lecture 4

25. 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? SE 430: Lecture 4

26. 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 SE 430: Lecture 4

27. 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. SE 430: Lecture 4

28. 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. SE 430: Lecture 4

29. 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 SE 430: Lecture 4

30. 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 coherenceof each abstraction SE 430: Lecture 4

31. 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 SE 430: Lecture 4

32. 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. SE 430: Lecture 4

33. Domain modeling SE 430: Lecture 4

34. Domain Modeling Artifacts SE 430: Lecture 4

35. 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). SE 430: Lecture 4

36. 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! SE 430: Lecture 4

37. Basic domain model diagram notation SE 430: Lecture 4

38. Objects SE 430: Lecture 4

39. 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 SE 430: Lecture 4

40. 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 SE 430: Lecture 4

41. Object: flower on my desk Attributes: Name: Rose Smell: Sweet Color: Red Thorns: Yes 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 SE 430: Lecture 4

42. 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 SE 430: Lecture 4

43. 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” SE 430: Lecture 4

44. 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 SE 430: Lecture 4

45. Classes in the software So the main problem in designing object oriented software is: • How do we find the classes? SE 430: Lecture 4

46. Domain Model SE 430: Lecture 4

47. Building a domain model • Tasks: • 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. SE 430: Lecture 4

48. Conceptual Classes SE 430: Lecture 4

49. What are conceptual classes? P l a n e v i s u a l i z a t i o n o f d o m a i n c o n c e p t t a i l N u m b e r d o m a i n c o n c e p t p u b l i c c l a s s P l a n e { r e p r e s e n t a t i o n i n a n p r i v a t e S t r i n g t a i l N u m b e r ; o b j e c t - o r i e n t e d p r o g r a m m i n g l a n g u a g e p u b l i c L i s t g e t F l i g h t H i s t o r y ( ) { . . . } } SE 430: Lecture 4

50. 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. SE 430: Lecture 4