Sommerville Chapter 7 Fowler Chapters 1, 3, 5, and 6. Conceptual Modeling and Class Diagrams

Size: px

Start display at page:

Download "Sommerville Chapter 7 Fowler Chapters 1, 3, 5, and 6. Conceptual Modeling and Class Diagrams"

Gavin Atkins
5 years ago
Views:

1 Sommerville Chapter 7 Fowler Chapters, 3, 5, and 6 Conceptual Modeling and Class Diagrams

2 ter> time> Announcements HW2 handout now available on the webpage. Interpration of throttle position and its relation to acceleration is different in HW2 Next tutorial in Week 4 on class diagrams and sequence diagrams

3 ter> time> Objective for Today To introduce conceptual modeling The goal of conceptual modeling To review the OO solution To introduce and discuss the object model (conceptual) Syntax and semantics

4 ter> time> Common Problems The requirements are wrong Incomplete, inconsistent, or ambiguous The developer and the customer did not interpret the requirements the same way Requirements drift The requirements tend to change throughout the project Late design changes Continual change The functionality of the system continually changes Many changes come late in the project Many changes during maintenance Breakdown of system structure The system finally becomes unusable

5 ter> time> Solutions Rigorous requirements and planning stage Make sure all stakeholders understand and agree on the requirements Structure the system design to accommodate change Isolate parts that are likely to change Modularize so changes are contained Attempt to not compromise system structure during change

6 ter> time> The OO Solution The problem domain is relatively constant Auto pilot Get a plane from point A to point B using the available control surfaces

7 ter> time> The OO Solution The problem domain is relatively constant Auto pilot Get a plane from point A to point B using the available control surfaces The functionality and data representation is what is likely to change Auto pilot The hardware interfaces are different between different models The operational modes vary between models and evolve over time

8 ter> time> The OO Solution The problem domain is relatively constant Auto pilot Get a plane from point A to point B using the available control surfaces The functionality and data representation is what is likely to change Auto pilot The hardware interfaces are different between different models The operational modes vary between models and evolve over time Structure the system based on the structure of the problem domain, NOT based on the structure of the solution

9 ter> time> What is OO A way of thinking about a problem (software) based on abstractions of concepts that exist in the real world OO is not constrained by implementation language (C, Pascal, FORTRAN, etc. will work)

10 ter> 0time> What is not OO Using an object oriented language (C++, Eiffel, Smalltalk) You can easily misuse the OO support in these languages Using an OO notation for design Misuse the notation for a non-oo design Calling what you do OO Management and customers like OO, therefore, that is what we are doing OO is not the answer to all your problems

11 ter> time> Several Complementary Models Structural Models Describes the structure of the objects in a system Structure of individual objects (attributes and operations) Relationships between the objects (inheritance, sharing, and associations) Clustering of objects in logical packages and on the actual hardware Dynamic models (behavioral models) The aspects related to sequencing of operations Changes to attributes and sequences of changes The control aspects of the system

12 2 l i A Short Discussion i Conceptual Modeling l

13 ter> 3time> Conceptual Modeling Early modeling to understand the problem Conducted in cooperation with the customer Domain experts Domain engineers No real problem analysis if the customer is not involved Power of OO It is simple and people can quickly participate effectively Or so they say

14 ter> 4time> The OO Solution The OO model closely resembles the problem domain Base your model on the objects in the problem domain Iteratively refine the high-level model until you have an implementation Attempt to avoid big conceptual jumps during the development process

15 ter> 5time> The OO Solution (Cont.) Organize the model as a collection of objects Concrete concepts in the physical world A drivers license, a credit card, an aircraft, etc. Logical concepts A scheduling policy in an OS, ATC conflict resolution rules, etc. Encapsulate all information within the objects Data representation Characteristics of the object - the object attributes Functionality (behavior) What the object can do - what operations can the object perform

16 Fall CSci Dr. Mats Heimdahl Objects Drivers License Ajitha Rajan A Ajitha Rajan

17 ter> 7time> Characteristics of Objects Identity Discrete and distinguishable entities Classification Abstract entities with the same structure (attributes) and behaviour (operations) into classes Polymorphism The same operation may behave different on different classes Inheritance Sharing of attributes and operations based on a hierarchical relationship

18 8 l i i The Class Diagrams l

19 ter> 9time> Objects Something that makes sense in the application context (application domain) Ajitha Rajan Joe s Homework Assignment Ajitha s drivers license All objects have identity and are distinguishable NOT objects Person Drivers license

20 0ter> time> Classes Describes a group of objects with similar properties (attributes), common behavior (operations), common relationships to other classes, and common semantics Person Ajitha Rajan Joe Smith Allan Clark Card Credit card Drivers license Teller card

21 Fall CSci Dr. Mats Heimdahl Attributes and Operations Person objects Card objects Drivers License Ajitha Rajan A abstracts to Ajitha Rajan Person class Attributes name age height weight Operations move change-job Card class Attributes height width id-number Operations issue change

22 Class Diagrams Class diagram Person name: String age: integer Class with attributes Person person ID: integer name: String age: integer Person Lisa Heimdahl 32 Instance diagram Person Mats Heimdahl 33 Objects with values Objects have an identity Do not explicitly list object identifiers SSN OK!

23 ter> 3time> Class Diagrams Class diagram Instance diagram Person name: String age: integer Person- : Person -name = Lisa Heimdahl -age = 32 Person-2 : Person -name = Mats Heimdahl -age = 33 Class with attributes Person person ID: integer name: String age: integer Objects with values Objects have an identity

24 ter> 4time> Operations and Methods Transformation that can be applied to or performed by an object Card height: integer width: integer thickness: integer id-number: integer issue() revoke() Shape height: integer width: integer rotate(angle: integer) move(x: integer, y: integer) May have arguments

25 ter> 5time> Object Notation - Summary Class name attribute- : data-type- = default-value- attribute-2 : data-type-2 = default-value-2 attribute-3 : data-type-3 = default-value-3 operation-(argument-list-) : result-type- operation-2(argument-list-2) : result-type-2 operation-3(argument-list-3) : result-type-3

26 ter> 6time> Associations Conceptual connection between classes A credit card is issued-by a bank A person works-for a company Credit Card Issued-by Bank Person Works-for Company Class diagrams Person-2 : Person -name = Mats Heimdahl -age = 33 Works-for U of M : Company Instance diagram

27 ter> 7time> Associations are Bidirectional There is no direction implied in an association Country name Has-capital City name Person name Is-issued Drivers-license lic.-number: integer

28 ter> 8time> Associations Have Direction Unified adds a direction indicator Country name Has-capital City name Person name Is-issued Drivers-license lic.-number: integer

29 9ter> time> Multiplicity One person holds one credit card Person name: String Holds Credit-card card-number: integer One object can be related to many objects through the same association One person can hold zero or more credit cards (* stands for many) Person name: String Holds 0..* Credit-card card-number: integer

30 ter> 0time> Multiplicity One person holds one credit card Person name: String Holds Credit-card card-number: integer One object can be related to many objects through the same association One person can hold zero or more credit cards (* stands for many) Person name: String Holds 0..* Credit-card card-number: integer

31 ter> time> Multiplicity (Cont.) One person can hold zero or more credit cards (0..*) Each card has zero or one holder (0..) Person name: String 0.. Holds 0..* Credit-card card-number: integer Credit-Card Person Holds Credit-Card Person Mats Heimdahl 33 Holds Credit-Card Lisa Heimdahl

32 ter> 2time> Multiplicity (Cont.) One person can hold zero or more credit cards (0..*) Each card has zero or one holder (0..) Person name: String 0.. Holds 0..* Credit-card card-number: integer Credit-Card Person Holds Credit-Card Person Mats Heimdahl 33 Holds Credit-Card Lisa Heimdahl

33 ter> 3time> Multiplicity (Cont.) One person can hold zero or more credit cards (0..*) Each card has one holder (no indication or ) Each card has one or more authorized users (..*) One person can be authorized to use zero or more cards Person name: String Holds 0..* Autorized..* 0..* Credit-card card-number: integer Credit-Card Autoriz ed Person Holds Mats Heimdahl 33 Holds Autoriz ed Credit-Card Explicit enumeration is also possible (2, 3, 2..5, etc.) Person Autoriz ed Lisa Heimdahl 32 Autoriz ed Holds Credit-Card

34 ter> 4time> Link Attributes Associations can have properties the same way objects have properties Person name: String age: integer SSN: integer address: String 0..* Works-for Company name: String address: String How represent salary and job title? Person name: String age: integer SSN: integer address: String 0..* Works-for Company name: String address: String Use a link attribute! salary: integer job-title: String

35 ter> 5time> Folding Link Attributes into Class Person name: String age: integer SSN: integer address: String salary: integer job-title: String 0..* Works-for Company name: String address: String Why not this? Salary and job title are properties of the job not the person Person name: String age: integer SSN: integer address: String 0..* Works-for 0..* Company name: String address: String In this case, a link attribute is the only solution salary: integer job-title: String

36 Ordering The objects on the many side of an association does not have order. Imply ordering with the ordered attribute Screen Visible 0..* Window Screen Visible 0..* {ordered} Window

37 ter> 7time> General Constraints Express constraints in plain English Draw a dotted line if feasible Do not clutter the diagram with constraint arrows!

38 ter> 8time> Attribute Constraints Constraints on the attributes Card number must be a 2 digit number Worker s salary is always less than the salary of the boss Credit-card card-number: integer {card-number is 2 digits} Manages boss 0.. worker 0..* Employee name salary address {worker.salary < boss.salary}

39 9 Navigability Indicates you can get information about objects in only one direction Pointer from one object to the next Object defined as a member in the implementation

40 ter> 0 l Role Names Attach names to the ends of an association to clarify its meaning Manages boss 0.. Person name: String age: integer SSN: integer address: String 0..* worker 0..* Works-for 0..* employee salary: integer job-title: String employer Company name: String address: String

41 ter> l Higher order associations Ternary association Project, language, person Language..*..* Project..* Person Language C++ Project Compiler Person Mats Heimdahl 33 Language LISP Project TicTacToe

42 2 Aggregation A special association, the is-part-of association A sentence is part of a paragraph (a paragraph consists of sentences) A paragraph is part of a document (a document consists of paragraphs) 0..* 0..* Document Paragraph Sentence Aggregation symbol

43 3 Aggregation (Cont.) Often used in parts explosion Car 4 Wheel Body Gearbox Engine..*..* 0..* Door Hood Trunk Piston Valve Crankshaft

44 ter> 4 l Generalization and Inheritance The is-a association Cards have many properties in common Generalize the common properties to a separate class, the base-card Let all cards inherit from this class, all cards is-a base-card (plus possibly something more) Drivers License Card height: integer width: integer thickness: integer id-number: integer issue() revoke() ID Card Credit Card class: vehicle issued: date expires: date expire() issued: date expires: date expire() credit-limit: integer issued: date validate()

45 5 Example Owns City name Based-In 0..* Airline name Works-for 0..* Pilot name license Located-In Offers..* Certified-On 0..* Pilots 0..* Airport name heat() clean() Departs 0..* 0..* Flight Arrives date Used-For flight # 0..* cancel() delay() 0..* Plane model serial # hours flown heat() refuel() clean() 30..* Passenger 0..* Seat location name Confirmed-for reserve()

46 ter> 6time> Aggregation Versus Association Can you use the phrase is-part-of or is-made-of Are operations automatically applied to the parts (for example, move) - aggregation Not clear what it should be Company 0..* 0..* Division Department Works-for 0..* Person

47 ter> 7time> Aggregation Versus Inheritance Do not confuse the is-a relation (inheritance) with the is-part-of relation (aggregation) Use inheritance for special cases of a general concept Use aggregation for parts explosion Station Wagon Car Compact 4 by 4 4 Wheel Body Gearbox Engine Transfer Case

48 8 l Object Modeling Summary Classes Name Attributes Operations Associations Roles Link attributes Aggregation Inheritance

49 9 l In Class Examples Draw a class diagram for a book chapter with the following structure. A chapter comprises several sections, each of which comprises several paragraphs and/or figures. A paragraph comprises several sentences, each of which comprises several words. Note : You may ignore punctuation and you need not pursue the structure of a figure any further. Note 2: Several in the text above refers to one or more. Draw a class diagram (using inheritance) that captures two categories of a company s customers: external customers, which are other companies buying goods from this company, and internal customer, which are all the divisions of this company.

50 0 l Suggested Solution Chapter Section Section Component..*..* Word..* Sentence..* Paragraph Picture

51 l Another Suggested Solution Corporate Division Customer Internal Customer External Customers

52 2 l i Sommerville Chapter 7 Fowler Chapters, 3, 5, and 6 i Object Modeling Approach l

53 ter> 3time> Objective To introduce one way of getting a model started Introduce a way of starting to find responsibilities, collaborators, and relationships

54 4 l Object Modeling Approach Start with a problem statement High-level requirements Define object model Identify objects and classes Prepare data dictionary Identify associations and aggregations Identify attributes of objects and links Organize and simplify using inheritance Iterate and refine the model Group classes into modules

55 Fall CSci Dr. Mats Heimdahl The Home Heating System Water Pump Water Valve Hot Water Burner Controller Home Fuel Valve Off Fuel On Control Panel Temp Sensor

56 ter> 6time> Home Heating Requirements The purpose of the software for the Home Heating System is to control the heating system that heats the rooms of a house. The software shall maintain the temperature of each room within a specified range by controlling the heat flow to individual rooms. The software shall control the heat in each room The room shall be heated when the temperature is 2F below desired temp The room shall no longer be heated when the temperature is 2F above desired temp The flow of heat to each room shall be individually controlled by opening and closing its water valve The valve shall be open when the room needs heat and closed otherwise The user shall set the desired temperature on the thermostat The operator shall be able to turn the heating system on and off The furnace must not run when the system is off When the furnace is not running and a room needs heat, the software shall turn the furnace on To turn the furnace on the software shall follow these steps open the fuel valve turn the burner on The software shall turn the furnace off when heat is no longer needed in any room To turn the furnace off the software shall follow these steps close fuel valve turn burner off

57 7 Identify Object Classes Requirements Statements Extract Nouns Tentative Object Classes Eliminate Spurious Classes Object Classes Candidate Classes Water Pump Controller Hot Water operator Home Heating System house furnace thermostat Burner room Water Valve heating system Fuel Valve temperature heat software desired temp Home Fuel Temp Sensor on-off switch Control Panel range

58 8 Eliminate Bad Classes Redundant classes Classes that represent the same thing with different words Irrelevant classes Classes we simply do not care about Vague classes Classes with ill defined boundaries Attributes Things that describe individual objects Operations Sequences of actions are often mistaken for classes Roles The name of a class should reflect what it is, not the role it plays Implementation details Save that for implementation

59 Eliminate Classes Redundant Irrelevant Vague Attributes heating system Fuel software heat house desired temp user Hot Water heat flow home temperature range Operations Roles Implementation None None None Fuel Valve Burner Water Pump thermostat on-off switch furnace operator room Controller Home Heating System Temp Sensor Water Valve Control Panel

60 0 Classes After Elimination Fuel Valve Burner Water Pump Room Home Heating System Thermostat Furnace Temp Sensor Water Valve Operator on-off switch Control Panel Controller

61 Prepare Data Dictionary Water Tank The storage tank containing the water that circulates in the system. Pump- The pump pumping water from the Water Tank to the radiators in the rooms Etc. Etc.

62 ter> 2time> Possible Associations A room consists of a thermometer and a radiator A radiator consists of a valve and a radiator element The home heating system consists of a furnace, rooms, a water pump, a control panel, and a controller The furnace consists of a fuel pump and a burner The control panel consists of an on-off switch and a thermostat The controller controls the fuel pump The controller controls the burner The controller controls the water pump The controller monitors the temperature in each room The controller opens and closes the valves in the rooms The operator sets the desired temperature The operator turns the system on and off The controller gets notified of the new desired temperature

63 ter> 3 l Class Diagram Home Heating System Control Panel Furnace Water Pump Runs On-Off Switch Thermostat Burner Fuel Valve Pushes Adjusts..* Room Notifies Operator Water Valve Temp Sensor Opens/Closes Ignites Monitor Actuates Controller

64 ter> 4 l Class Diagram (Better?) Control Panel Furnace Water Pump Runs On-Off Switch Thermostat Burner Fuel Valve Pushes Adjusts Room Notifies Operator Water Valve Temp Sensor Opens/Closes Ignites Actuates Monitor Controller

65 5 Class Diagram - Modified Home Heating System Control Panel Furnace Water Pump Runs On-Off Switch Thermostat Burner Fuel Valve Pushes Adjusts..* Room..* Ignites Opens/Closes Notifies Operator..* Heats Monitor Water Valve Temp Sensor Controller

66 ter> 6time> Class Diagram Alternate Notify * Room * Request Heat Water Valve Temp Sensor Start Water Pump Control Panel Furnace Power Switch Thermostat Fuel Valve Burner Push Operator Adjust

67 7 Attributes Thermostat desired-temp On-Off switch setting Temp Sensor temperature

68 8 Final Class Diagram Home Heating System Control Panel Furnace Water Pump Runs On-Off Switch Thermostat Burner Fuel Valve setting desired-temp Pushes Adjusts..* Room..* Ignites Opens/Closes Notifies Operator..* Heats Monitor Water Valve Temp Sensor temperature Controller

69 ter> 9time> Final Alternative Notify * Room * Request Heat Water Valve Temp Sensor -Temperature Start Water Pump Control Panel Furnace Power Switch -setting Thermostat -Desired Temp Fuel Valve Burner Push Operator Adjust

70 Iterate the Model Keep on doing this until you, your customer, and your engineers are happy with the model Iterate

71 ter> time> Different Types of Interaction Diagrams An Interaction Diagram typically captures a use-case A sequence of user interactions Sequence diagrams Highlight the sequencing of of the interactions between objects Collaboration diagrams Highlight the structure of the components (objects) involved in the interaction

72 ter> 2time> Home Heating Use-Case Use case: Power Up Actors: Home Owner (initiator) Type: Primary and essential Description: The Home Owner turns the power on. Each room is temperature checked. If a room is below the the desired temperature the valve for the room is opened, the water pump started, the fuel valve opened, and the burner ignited. If the temperature in all rooms is above the desired temperature, no actions are taken. Cross Ref.: Requirements XX, YY, and ZZ Use-Cases: None

73 ter> 3 l Class Diagram v Control Panel Furnace Water Pump Runs On-Off Switch Thermostat Burner Fuel Valve setting Pushes desired-temp Adjusts Room..* Opens/Closes Ignites Notifies Operator Water Valve..* Temp Sensor Heats Monitor temperature Controller

74 ter> 4time> Sequence Diagrams (for cd v)

75 ter> 5time> Sequence Diagrams (old) (for cd v)

76 ter> time> 6 We Have Learned An object is an entity in the problem domain A class is an abstraction of a collection of objects Objects (classes) have attributes and operations Objects (classes) are related to each other trough associations Regular association Aggregation Inheritance Associations have multiplicity May have link attributes Role names may be used to clarify the model

77 Fall CSci Dr. Mats Heimdahl We Have Learned How to approach an OO modeling effort Identify objects (nouns) Identify associations (typically verbs) Identify attributes and operations The model will need a lot of iteration In conjunction with other models we have not yet talked about We will the next few lectures

The OO Solution. Objects

The OO Solution. Objects C870: Cheng The OO Solution The OO model closely resembles the problem domain Base your model on the objects in the problem domain Iteratively refine the high-level model until you have an implementation