Modeling

• Describing a system at a high level of abstraction – A model of the system UML: Unified Modeling Language – Used for requirements and specification

• Many notations over time CS169 – State machines Lecture 5 – Entity-relationship diagrams – Dataflow diagrams – … see last lecture …

Prof. Brewer CS 169 Lecture 5 1 Prof. Brewer CS 169 Lecture 5 2

Recent History: 1980’s Recent History: 1990’s

• The rise of object-oriented programming • Three leading OO notations decide to combine – Grady Booch (BOOCH) • New class of OO modeling languages – Jim Rumbaugh (OML: Object Modeling Technique) – Ivar Jacobsen (OOSE: OO Soft. Eng) • By early ’90’s, over 50 OO modeling languages •Why? – Natural evolution towards each other – Effort to set an industry standard

Prof. Brewer CS 169 Lecture 5 3 Prof. Brewer CS 169 Lecture 5 4

UML UML (Cont.)

•UML stands for • Resulting design is huge Unified Modeling Language – Many features – Many loosely unrelated styles under one roof • Design by committee – Many interest groups participating • Could also be called – Everyone wants their favorite approach to be “in” Union of all Modeling Languages

Prof. Brewer CS 169 Lecture 5 5 Prof. Brewer CS 169 Lecture 5 6

1 This Lecture Running Example: Automatic Train

• We discuss • Consider an unmanned people-mover – Use Case Diagrams for functional models –as in many airports – Class Diagrams for structural models – Sequence Diagrams •Train – Activity Diagrams for dynamic models – Moves on a circular track – State Diagrams – Visits each of two stations (A and B) in turn – Each station has a “request” button • This is a subset of UML • To stop at this station – But probably the most used subset – Each train has two “request” buttons • To stop at a particular station

Prof. Brewer CS 169 Lecture 5 7 Prof. Brewer CS 169 Lecture 5 8

Picture Use-Cases

• Describe functionality from the user’s A perspective • One (or more) use-cases per kind of user – May be many kinds in a complex system

B • Use-cases capture requirements

Prof. Brewer CS 169 Lecture 5 9 Prof. Brewer CS 169 Lecture 5 10

An Example Use-Case in UML An Example Use-Case in UML

•Name •Event-flow –Normal Train Ride – Passenger presses request button •Actors – Train arrives and stops at platform – Doors open – Passenger – Passenger steps into train • Entry Condition – Doors close – Passenger at station – Passenger presses request button for final stop • Exit Condition –… – Passenger leaves station – Doors open at final stop – Passenger exits train • Non-functional requirements Prof. Brewer CS 169 Lecture 5 11 Prof. Brewer CS 169 Lecture 5 12

2 Use Case Diagram Exceptional Situations

•Graph showing • Use cases have relationships –Actors – Inclusion (E.g., push button included in ride) – Use cases –Variations – Edges actor-case if that Ride actor is involved in that case passenger • UML has a special notation – The “extends” relationship to express a exceptional •Actors Repair variation of a use case –Stick figures – Normally used to express errors • Use cases –Ovals technician

Prof. Brewer CS 169 Lecture 5 13 Prof. Brewer CS 169 Lecture 5 14

Extension Summary of Use Cases

• Use Case Diagram Dotted – Shows all actors, use cases, relationships Ride arrow pointing to • 5 parts to each use case “normal” passenger Derail case – Name, Actors, Entry/Exit Conditions, Event Flow – Actors are agents external to the system • E.g., users Repair – Event flows are sequence of steps • In English technician

Prof. Brewer CS 169 Lecture 5 15 Prof. Brewer CS 169 Lecture 5 16

Class Diagrams Class Diagrams: Relationships

• Describe classes Train • Many different kinds of – In the OO sense lastStop edges to show different nextStop relationships between • Each box is a class velocity classes –List fields doorsOpen? – List methods • Mention just a couple addStop(stop); • The more detail, the startTrain(velocity); more like a design it stopTrain(); becomes openDoors();

Prof. Brewer CS 169 Lecture 5 17 Prof. Brewer CS 169 Lecture 5 18

3 Associations Aggregation

• Capture n-m •Show “contains a” relationships Station Train relationships Station Train – Subsumes ER diagrams 1 1 1 1

1 2 • Station and Train 1 2 • Label endpoints of edge classes can contain their RequestButton RequestButton with cardinalities respective buttons – Use * for arbitrary • Denoted by open One request button • Typically realized with diamond on the embedded references per station; each train has two request “contains” side •Can be directional (use buttons arrows in that case) Prof. Brewer CS 169 Lecture 5 19 Prof. Brewer CS 169 Lecture 5 20

Generalization Sequence Diagrams

• Inheritance between •A table classes Button – Columns are classes or actors – Rows are time steps • Denoted by open – Entries show control/data flow triangle • Method invocations • Important changes in state

RequestButton EmergencyButton

Prof. Brewer CS 169 Lecture 5 21 Prof. Brewer CS 169 Lecture 5 22

Example Sequence Diagram Example Sequence Diagram

Passenger Station Train Passenger Station Train pushButton() Classes & pushButton() Method addStop() Actors addStop() invocation Note: These are all openDoors() openDoors() synchronous pushButton(S) pushButton(S) method calls. closeDoors() closeDoors() There are other kinds of invocations.

Prof. Brewer CS 169 Lecture 5 23 Prof. Brewer CS 169 Lecture 5 24

4 Example Sequence Diagram Example Sequence Diagram

Passenger Station Train Passenger Station Train pushButton() Invocation pushButton() “Lifelines” fill addStop() lifetime spans addStop() in time lifetimes of all between nested invocations

openDoors() invocations openDoors() pushButton(S) pushButton(S) closeDoors() closeDoors()

Prof. Brewer CS 169 Lecture 5 25 Prof. Brewer CS 169 Lecture 5 26

Sequence Diagrams Notes Activity Diagrams

• Sequence diagrams • Reincarnation of flow charts – Refine use cases – Uses flowchart symbols – Gives view of dynamic behavior of classes • Class diagrams give the static class structure • Emphasis on control-flow • Not orthogonal to other diagrams – Overlapping functionality • Two useful flowchart extensions – True of all UML diagrams – Hierarchy • A node may be an activity diagram –Swim lanes

Prof. Brewer CS 169 Lecture 5 27 Prof. Brewer CS 169 Lecture 5 28

Example Activity Diagram Example Activity Diagram

Activities in Station Train Concurrency, Station Train rounded fork & join rectangles pushButton pushButton

May itself be a nested activity diagram lightButton addStop lightButton addStop

Prof. Brewer CS 169 Lecture 5 29 Prof. Brewer CS 169 Lecture 5 30

5 Example Activity Diagram Another Example Activity Diagram

Swim lanes Station Train Classic flow- show which chart if-then- StopRequested? classes/actors pushButton else are responsible for which part yes no of the diagram

stopTrain announceNoStop lightButton addStop

Prof. Brewer CS 169 Lecture 5 31 Prof. Brewer CS 169 Lecture 5 32

StateCharts Example Simple StateChart

• Hierarchical finite automata – Invented by David Harel, 1983 Button

• Specify automata with many states compactly off depart push • Complications in meaning of transitions on – What it means to enter/exit a compound state

Prof. Brewer CS 169 Lecture 5 33 Prof. Brewer CS 169 Lecture 5 34

StateChart for the Train StateChart for Buttons + Train

• A train can be Dotted lines ButtonA separate – At a station Train concurrent – Between stations off automata departA pushA atA, A • Pending requests are subset of {A,B} on departA

• 16 possible states ButtonB AtoB, none – Transitions: pushA, pushB, departA, departB, …

Prof. Brewer CS 169 Lecture 5 35 Prof. Brewer CS 169 Lecture 5 36 derail

6 StateChart for Buttons + Train Opinions about UML: What’s Good

• A common language ButtonA Train – Makes it easier to share requirements, specs, designs

off • Visual syntax is useful, to a point departA pushA – A picture is worth 1000 words atA, A – For the non-technical, easier to grasp simple diagrams than simple pseudo-code on departA Transition • To the extent UML is precise, forces clarity ButtonB causes control AtoB, none – Much better than natural language to leave any possible state • Commercial tool support of the – Something natural language could never have componentProf. Brewer CS 169 Lecture 5 37 Prof. Brewer CS 169 Lecture 5 38 derail automaton

Opinions On UML: What’s Bad UML is Happening

• Hodge-podge of ideas • UML is being widely adopted – Union of most popular modeling languages –By users – Sublanguages remain largely unintegrated – By tool vendors • Visual syntax does not scale well – By programmers – Many details are hard to depict visually • Ad hoc text attached to diagrams – No visualization advantage for large diagrams • A step forward • 1000 pictures are very hard to understand – Seems useful – First standard for high-levels of software process • Semantics is not completely clear – Some parts of UML underspecified, inconsistent – Expect further evolution, development of UML –Plans to fix

Prof. Brewer CS 169 Lecture 5 39 Prof. Brewer CS 169 Lecture 5 40

7