Advanced Class Diagrams and Intro to Interaction Modeling

Size: px

Start display at page:

Download "Advanced Class Diagrams and Intro to Interaction Modeling"

Jerome Allison
5 years ago
Views:

1 Advanced Class Diagrams and Intro to Interaction Modeling Or: Advance to Illinois Avenue. Do not pass Go. Jonathan Sprinkle 1 University of Arizona Department of Electrical and Computer Engineering PO Box , Tucson, AZ 85721, USA September 6, 2010 Jonathan Sprinkle Advanced Class Diagrams and Intro to Interaction Modeling 1

2 Abstract Abstract This lecture discusses advanced class diagram issues relevant to the course and project. We then continue with an introduction to interaction modeling. Jonathan Sprinkle Advanced Class Diagrams and Intro to Interaction Modeling 2

3 Previously, on ECE There are 5 things you should remember about OO languages... 2 Class modeling is the modeling of the structure of software 3 Encapsulation is a HAS-A relationship, that hides information 4 Object diagrams show actual objects (i.e., instances) Jonathan Sprinkle Advanced Class Diagrams and Intro to Interaction Modeling 3

4 Outline 1 Advanced Class Diagram Concepts Stereotypes Enumerations and Numbers Scoping and Visibility Abstract classes Ordering Bags and Sequences 2 Interaction Modeling Contextual Reminders Kinds of Interaction Models 3 Use Cases and Use Case Diagrams Introduction to Use Cases UML Actors Use Cases Use Case Diagrams Guidelines for Use Case Models Jonathan Sprinkle Advanced Class Diagrams and Intro to Interaction Modeling 4

5 Stereotypes A class may have a particular stereotype, which provides additional information about the class. Stereotypes are a special kind of inheritance, but on the language level (not the design level). The most useful kind of stereotype for you is the enumeration. Jonathan Sprinkle Advanced Class Diagrams and Intro to Interaction Modeling 5

6 Stereotypes Definition An enumeration is a (finite) set of values that make up a data type. Example enum ustimezones = ET, CT, MT, PT, AZ Jonathan Sprinkle Advanced Class Diagrams and Intro to Interaction Modeling 6

7 Stereotypes We refer to this enumeration as having cardinality 5, since ust imezones = 5 (i.e., the number of items in the enumeration is 5). An example of this representation in a class diagram can be seen in Figure 1. <<enumeration>> TimeZones ET CT MT PT AZ Figure: Enumeration as a stereotype. Jonathan Sprinkle Advanced Class Diagrams and Intro to Interaction Modeling 7

8 Scoping and Visibility Some features belong to the class, and not to an instantiated object. The concept of class features (rather than object features) is the most abstract of all scoping. Consequence: features in the class scope (denoted by the keyword static) do not require the class to be instantiated as an object before use. Example Using scoping at the class level. c l a s s C a l e n d a r { p u b l i c : s t a t i c short daysinweek ; i n t getnumevents ( ) ; } ; Jonathan Sprinkle Advanced Class Diagrams and Intro to Interaction Modeling 8

9 Scoping and Visibility Now, referring to Calendar::_daysInWeek should allow knowledge of the number of days in the week without having to query a Calendar object. Static scoping should only be applied to data members that are the same for all instances of a class. Changing this value for one instance would change for all instances. Example Checking how many instances there are of a class is knowledge at the class not object level. This usually requires that the constructor/destructor appropriately adds/subtracts a static variable each time they are called. Jonathan Sprinkle Advanced Class Diagrams and Intro to Interaction Modeling 9

10 Scoping and Visibility Syntax for Scoping Scoping is generally available through the :: operator in C++, allowing you to address objects in a namespace (std::cout), classes in a namespace (mynamespace::a) and various concatenations (mynamespace::a::staticmethodofa( )). Jonathan Sprinkle Advanced Class Diagrams and Intro to Interaction Modeling 10

11 Scoping and Visibility However, as a major point, there are two kinds of scope for design: class and object. We represent features with class scope as underlined in a class diagram. See the example in Figure 2 Calendar _daysinweek : short = 7 int getnumevents( ) Figure: Class scoping example. Jonathan Sprinkle Advanced Class Diagrams and Intro to Interaction Modeling 11

12 Scoping and Visibility Visibility refers to the access region of the features to other classes (including subclasses). We will cover visibility in more depth later, but you need to know the notation for regions. Example Using regions in class diagrams. c l a s s C a l e n d a r { p u b l i c : i n t getnumevents ( ) ; s t a t i c short getdaysinweek ( ) ; protected : s t d : : s t r i n g name ; p r i v a t e : s t a t i c short daysinweek ; } ; Jonathan Sprinkle Advanced Class Diagrams and Intro to Interaction Modeling 12

13 Scoping and Visibility We represent feature accessibility as shown in Figure 3, where + public access # protected access - private access Calendar -_daysinweek : short = 7 #_name : string +int getnumevents( ) +getdaysinweek( ) : short Figure: Jonathan Sprinkle Advanced Class Diagrams and Intro to Interaction Modeling 13

14 Abstract classes If a class is abstract, it is shown in italics when the classname is displayed. We will discuss abstract class implementation syntax later. Fundamentally, abstract classes cannot be instantiated. If a (non-abstract) class derived from an abstract is instantiated, then the IS-A concepts are still valid. Abstract classes are useful to use as interfaces, or to use in function signatures. Example (Look familiar?) Coin toss( ) : bool BiasedCoin bias : double = 0.6 result : bool toss( ) : bool Figure: An abstract class, from hw01 Jonathan Sprinkle Advanced Class Diagrams and Intro to Interaction Modeling 14

15 Ordering Sometimes it is convenient to consider that the many association end multiplicities can be ordered explicitly. Definition An ordering is an ordered set of objects; no duplicates are allowed. Example Consider that a Person may have an ordered association with EmergencyContact objects. Person lastname : string phonenumber : string emergencycontact 0..* {ordered} Figure: Person and EmergencyContact class diagram. Jonathan Sprinkle Advanced Class Diagrams and Intro to Interaction Modeling 15

16 Bags and Sequences You may explicitly allow duplicates, or ensure that duplicates are not ordered, by using the bag and sequence modifiers on an association end. Definition A bag is a collection of elements with duplicates allowed. Definition A sequence is an ordered collection of elements with duplicates allowed.. Jonathan Sprinkle Advanced Class Diagrams and Intro to Interaction Modeling 16

17 Bags and Sequences Example Consider a FrequentFlier who has flown several hundred segments in the previous year to numerous Airports. Since ordering is not important (the flights have already been taken) the association with Airports may contain duplicates. Jonathan Sprinkle Advanced Class Diagrams and Intro to Interaction Modeling 17

18 Bags and Sequences Example Consider an Itinerary which will visit multiple Airports. The multiplicity for each end is, but the Airport is a {sequence}, since the same airport may be visited multiple times. Jonathan Sprinkle Advanced Class Diagrams and Intro to Interaction Modeling 18

19 Outline 1 Advanced Class Diagram Concepts Stereotypes Enumerations and Numbers Scoping and Visibility Abstract classes Ordering Bags and Sequences 2 Interaction Modeling Contextual Reminders Kinds of Interaction Models 3 Use Cases and Use Case Diagrams Introduction to Use Cases UML Actors Use Cases Use Case Diagrams Guidelines for Use Case Models Jonathan Sprinkle Advanced Class Diagrams and Intro to Interaction Modeling 19

20 Contextual Reminders Why do we model interactions? Remember that programs are a bunch of objects interacting with one another by passing messages. So, how do we know: What kinds of objects there will be? What kinds of messages they will pass? How we will know if things are going badly? These kinds of questions are made easier through analysis, which chiefly relies upon interaction modeling as its artifacts. Jonathan Sprinkle Advanced Class Diagrams and Intro to Interaction Modeling 20

21 Contextual Reminders Why do we model interactions? Remember that programs are a bunch of objects interacting with one another by passing messages. So, how do we know: What kinds of objects there will be? What kinds of messages they will pass? How we will know if things are going badly? These kinds of questions are made easier through analysis, which chiefly relies upon interaction modeling as its artifacts. Jonathan Sprinkle Advanced Class Diagrams and Intro to Interaction Modeling 21

22 Contextual Reminders Why do we model interactions? Remember that programs are a bunch of objects interacting with one another by passing messages. So, how do we know: What kinds of objects there will be? What kinds of messages they will pass? How we will know if things are going badly? These kinds of questions are made easier through analysis, which chiefly relies upon interaction modeling as its artifacts. Jonathan Sprinkle Advanced Class Diagrams and Intro to Interaction Modeling 22

23 Contextual Reminders Why do we model interactions? Remember that programs are a bunch of objects interacting with one another by passing messages. So, how do we know: What kinds of objects there will be? What kinds of messages they will pass? How we will know if things are going badly? These kinds of questions are made easier through analysis, which chiefly relies upon interaction modeling as its artifacts. Jonathan Sprinkle Advanced Class Diagrams and Intro to Interaction Modeling 23

24 Contextual Reminders Why do we model interactions? Remember that programs are a bunch of objects interacting with one another by passing messages. So, how do we know: What kinds of objects there will be? What kinds of messages they will pass? How we will know if things are going badly? These kinds of questions are made easier through analysis, which chiefly relies upon interaction modeling as its artifacts. Jonathan Sprinkle Advanced Class Diagrams and Intro to Interaction Modeling 24

25 Kinds of Interaction Models Major Categories There are different levels of abstraction for interaction models: Use case diagrams describe how the system interacts with external actors Sequence diagrams show messages exchanged among objects over a timeline Activity diagrams show control flow or data flow in a computation Jonathan Sprinkle Advanced Class Diagrams and Intro to Interaction Modeling 25

26 Kinds of Interaction Models Major Categories There are different levels of abstraction for interaction models: Use case diagrams describe how the system interacts with external actors Sequence diagrams show messages exchanged among objects over a timeline Activity diagrams show control flow or data flow in a computation Jonathan Sprinkle Advanced Class Diagrams and Intro to Interaction Modeling 26

27 Kinds of Interaction Models Major Categories There are different levels of abstraction for interaction models: Use case diagrams describe how the system interacts with external actors Sequence diagrams show messages exchanged among objects over a timeline Activity diagrams show control flow or data flow in a computation Jonathan Sprinkle Advanced Class Diagrams and Intro to Interaction Modeling 27

28 Outline 1 Advanced Class Diagram Concepts Stereotypes Enumerations and Numbers Scoping and Visibility Abstract classes Ordering Bags and Sequences 2 Interaction Modeling Contextual Reminders Kinds of Interaction Models 3 Use Cases and Use Case Diagrams Introduction to Use Cases UML Actors Use Cases Use Case Diagrams Guidelines for Use Case Models Jonathan Sprinkle Advanced Class Diagrams and Intro to Interaction Modeling 28

29 Introduction to Use Cases What are Use Cases Use case models are on the highest level of modeling (e.g., the 30,000 perspective). They are very useful for requirements gathering and specification. Use cases are created by forming a summary, description, and diagram for each use case. Jonathan Sprinkle Advanced Class Diagrams and Intro to Interaction Modeling 29

30 UML Actors Definition An actor is a direct external user of the system. It is an object, person, or set of objects that communicates directly with the system, but is not part of it. Modeling actors helps a system to understand what external/boundary inputs it expects. An actor should have a single, well-defined purpose in its interaction with the system. Jonathan Sprinkle Advanced Class Diagrams and Intro to Interaction Modeling 30

31 Use Cases The various interactions of actors with the system are what makes up a use case. Definition A use case is a coherent piece of functionality that a system can provide by interacting with actors. Example A customer can buy a beverage. A repair technician can perform maintenance. In this example, the actors are customer, and repair technician. The functionality is buy a beverage and perform maintenance. Jonathan Sprinkle Advanced Class Diagrams and Intro to Interaction Modeling 31

32 Use Cases Use cases should have generic behaviors, with specialized behaviors available if needs be. Also, error conditions, improper use (to which the system should respond gracefully) etc., should be present in a use case. A use case brings together all of the behavior relevant to this particular slice of system functionality and behavior. Use cases should be use to partition the system behavior (information encapsulation!!). Jonathan Sprinkle Advanced Class Diagrams and Intro to Interaction Modeling 32

33 Use Cases Example This example use case comes from the text. Buy a beverage The vending machine delivers a beverage after the customer pays and selects. Perform scheduled maintenance The repair technician performs periodic service on the vending machine to keep it in good working condition Make repairs The repair technician performs unscheduled maintenance to repair a problem Load Items A stock clerk adds items into the vending machine to replenish its beverage stock Figure: Use Case summaries for a vending machine Jonathan Sprinkle Advanced Class Diagrams and Intro to Interaction Modeling 33

34 Use Cases Example This example shows use case descriptions Use Case Summary Actors Preconditions Description Exceptions Postconditions Buy a beverage The vending machine delivers a beverage after the customer pays and selects Customer The machine is waiting for money to be inserted A customer inserts coins... The following exceptions are expected: Canceled Out of stock Insufficient money No change Customer presses the cancel button prior to selection. The customer s money is returned, and the machine returns to the waiting state. Customer action...(consequences) Customer action...(consequences) Customer action...(consequences) The machine is waiting for money to be inserted Figure: Use case description for the Buy a beverage use case. Jonathan Sprinkle Advanced Class Diagrams and Intro to Interaction Modeling 34

35 Use Case Diagrams The graphical notation for indicating and summarizing use cases is called a Use Case Diagram. This diagram is supplemental to the use case summaries and descriptions. Example This example shows a use case diagram which is based on the previous examples. Vending Machine buy a beverage perform scheduled maintenance Customer make repairs Repair Technician load items Stock Clerk Jonathan Sprinkle Advanced Class Diagrams and Intro to Interaction Modeling 35

36 Guidelines for Use Case Models Use cases are a tool to help in requirements gathering, since their structure and creation help to disambiguate requirements. Though they are not perfect, they are an important part in ground-up designs. Some guidelines: Determine the system boundary. Ensure that actors are focused on their single, coherent, purpose Each use case should provide value to users Relate use cases and actors. If an actor does not have a use case, or a use case does not have an actor, something is wrong... Keep in mind the formality of use cases. Use cases are an informal (non-semantic) tool, and are useful in forming the design, not as a means of synthesis Use cases can be structured, helping to reduce complexity. Jonathan Sprinkle Advanced Class Diagrams and Intro to Interaction Modeling 36

Advanced UML Class Models

Advanced UML Class Models Or: Love s Labors Lost Jonathan Sprinkle 1 University of Arizona Department of Electrical and Computer Engineering PO Box 210104, Tucson, AZ 85721, USA August 27, 2012 Jonathan