Course information and deadline reminders Course web page: http://www.cs.bilkent.edu.tr/~calkan/teaching/cs319 Download the syllabus Course text book: Object-Oriented Software Engineering, Using UML, Patterns, and Java, 3rd Edition, by Bernd Bruegge and Allen H. Dutoit, Prentice-Hall, 2010, ISBN-10: 0136066836. Project Groups and Information http://www.cs.bilkent.edu.tr/~calkan/teaching/cs319/project.html We may need to readjust for add/drops, will be adjusted for drops tonight and for adds on Friday Nearest deadline: June 19, 2012: Submit information about project case.

Chapter 2, Modeling with UML

Overview: modeling with UML What is modeling? What is UML? Use case diagrams Class diagrams Sequence diagrams Activity diagrams

What is modeling? Modeling consists of building an abstraction of reality. Abstractions are simplifications because: They ignore irrelevant details and They only represent the relevant details. What is relevant or irrelevant depends on the purpose of the model.

Example: street map

Why model software? Why model software? Software is getting increasingly more complex Windows XP > 40 million lines of code A single programmer cannot manage this amount of code in its entirety. Code is not easily understandable by developers who did not write it We need simpler representations for complex systems Modeling is a means for dealing with complexity

Systems, Models and Views A model is an abstraction describing a subset of a system A view depicts selected aspects of a model A notation is a set of graphical or textual rules for depicting views Views and models of a single system may overlap each other Examples: System: Aircraft Models: Flight simulator, scale model Views: All blueprints, electrical wiring, fuel system

Systems, Models and Views Flightsimulator Blueprints Aircraft Electrical Wiring Scale Model

Models, Views and Systems (UML) * * System Model View Described by Depicted by Airplane: System Scale Model: Model Flight Simulator: Model Blueprints: View Fuel System: View Electrical Wiring: View

Concepts and Phenomena Phenomenon An object in the world of a domain as you perceive it Example: The lecture you are attending Example: My titanium watch Concept Describes the properties of phenomena that are common. Example: Lectures on software engineering Example: Titanium watches Concept is a 3-tuple: Name (To distinguish it from other concepts) Purpose (Properties that determine if a phenomenon is a member of a concept) Members (The set of phenomena which are part of the concept)

Concepts and phenomena Members Name Clock Purpose A device that measures time. Abstraction Classification of phenomena into concepts Modeling Development of abstractions to answer specific questions about a set of phenomena while ignoring irrelevant details.

Concepts in software: Type and Instance An abstraction in the context of programming languages Name: int, Purpose: integral number, Members: 0, -1, 1, 2, -2, . . . Instance: Member of a specific type The type of a variable represents all possible instances the variable can take The following relationships are similar: “type” <–> “instance” “concept” <–> “phenomenon”

Abstract Data Types & Classes Special type whose implementation is hidden from the rest of the system. Class: An abstraction in the context of object-oriented languages Like an abstract data type, a class encapsulates both state (variables) and behavior (methods) Class Vector Unlike abstract data types, classes can be defined in terms of other classes using inheritance

Application and Solution Domain Application Domain (Requirements Analysis): The environment in which the system is operating Solution Domain (System Design, Object Design): The available technologies to build the system

Object-oriented modeling Application Domain Solution Domain Application Domain Model UML Package System Model TrafficControl MapDisplay SummaryDisplay TrafficController FlightPlanDatabase Aircraft Airport TrafficControl FlightPlan

Standard notations We need a standard notation for accurate communication among participants of the project Analogous example: math notations are universally known and recognized Properties of the standard notation: Well-defined semantics “+”: addition, etc. Well-suited for representing aspects of a system Arithmetic operators represent all arithmetics Well-understood amont project participants Everyone knows what “+” sign means

What is UML? UML (Unified Modeling Language) OMT (Rumbaugh et al.) Nonproprietary standard for modeling software systems, Object Management Group (OMG) Convergence of notations used in object-oriented methods OMT (Rumbaugh et al.) Booch (Grady Booch) OOSE (Jacobson et al.) Current Version: UML 2.4.1 Information at the OMG portal http://www.uml.org/ Commercial tools: Rational (IBM),Together (Borland), Visual Architect (business processes, BCD) Open Source tools: ArgoUML, StarUML, Umbrello Commercial and Opensource: PoseidonUML (Gentleware)

UML: First Pass You can model 80% of most problems by using about 20% UML We teach you those 20% 80-20 rule: Pareto principle http://www.ephorie.de/hindle_pareto-prinzip.htm “For many events, roughly 80% of the effects come from 20% of the causes” Microsoft noted that by fixing the top 20% of the most reported bugs, 80% of the errors and crashes would be eliminated.

UML First Pass Use case diagrams Class diagrams Sequence diagrams Describe the functional behavior of the system as seen by the user Used during requirements elicitation Class diagrams Describe the static structure of the system: Objects, attributes, associations Sequence diagrams Describe the dynamic behavior between objects of the system State diagrams Describe the dynamic behavior of an individual object Statechart diagrams Describe the dynamic behavior of an individual object (essentially a finite state automaton) Activity Diagrams Model the dynamic behavior of a system, in particular the workflow (essentially a flowchart)

UML Core Conventions All UML Diagrams are composed of graphs of nodes and edges Nodes are entities and drawn as rectangles or ovals Rectangles denote classes or instances Ovals denote functions Names of Classes are not underlined SimpleWatch Firefighter Names of Instances are underlined myWatch:SimpleWatch Joe:Firefighter An edge between two nodes denotes a relationship between the corresponding entities

UML first pass: Use case diagrams Classifier Use Case Actor. System boundary Use case diagrams represent the functionality of the system from user’s point of view

Historical Remark: UML 1 used packages Use case Package Watch WatchUser Actor ReadTime SetTime ChangeBattery WatchRepairPerson Use case diagrams represent the functionality of the system from user’s point of view

UML first pass: Class diagrams Association Class Multiplicity SimpleWatch 1 2 1 2 PushButton Display Battery Time Class diagrams represent the structure of the system

UML first pass: Class diagrams Class diagrams represent the structure of the system Association Class Multiplicity Watch 1 blinkIdx blinkSeconds() blinkMinutes() blinkHours() stopBlinking() referesh() LCDDisplay 1 Battery Load 1 2 Time Now 1 1 2 PushButton state push() release() Operations Attribute

UML first pass: Sequence diagram :Watch :WatchUser Actor Message Object Lifeline :LCDDisplay :Time pressButton1() blinkHours() pressButton1() blinkMinutes() pressButton2() incrementMinutes() refresh() pressButton1and2() commitNewTime() stopBlinking() Activation Sequence diagrams represent the behavior of a system as messages (“interactions”) between different objects

UML first pass: Statechart diagrams Initial state Event button1&2Pressed button1Pressed button2Pressed Increment Minutes Hours Blink Seconds Stop Blinking Transition State Represent behavior of single objects with interesting dynamic behavior in terms of states and transitions The behavior of the single object Watch, for example, has several different interesting states, BlinkHours, BlinkMinutes, BlinkSeconds, Because in each state pressing a button or two yields a different result. Final state Represent behavior of a single object with interesting dynamic behavior.

Other UML Notations UML provides many other notations, for example Deployment diagrams for modeling configurations Useful for testing and for release management We introduce these and other notations as we go along in the lectures Object Constraint Language (OCL): A language for constraining UML models Lecture on Object Design In particular, in the lecture on System Design we introduced Deployment Diagrams, in the lecture on Testing we introduce Profiles. There is also a language to constrain the systems that can be instantiated from models. The language that has been designed to constain UML models is called OCL (Object constraint language) Introduced in lecture on Object Design

What should be done first? Coding or Modeling? It all depends…. Forward Engineering Creation of code from a model Start with modeling Greenfield projects Reverse Engineering Creation of a model from existing code Interface or reengineering projects Roundtrip Engineering Move constantly between forward and reverse engineering Reengineering projects Useful when requirements, technology and schedule are changing frequently.

UML Second Pass Use case diagrams Class diagrams Sequence diagrams Describe the functional behavior of the system as seen by the user Class diagrams Describe the static structure of the system: Objects, attributes, associations Sequence diagrams Describe the dynamic behavior between objects of the system State diagrams Describe the dynamic behavior of an individual object Activity diagrams Describe the dynamic behavior of a system, in particular the workflow. Statechart diagrams Describe the dynamic behavior of an individual object (essentially a finite state automaton) Activity Diagrams Model the dynamic behavior of a system, in particular the workflow (essentially a flowchart)

UML Use Case Diagrams Used during requirements elicitation and analysis to represent external behavior (“visible from the outside of the system”) Passenger An Actor represents a role, that is, a type of user of the system A use case represents a class of functionality provided by the system PurchaseTicket Use case model: The set of all use cases that completely describe the functionality of the system.

Actors An actor is a model for an external entity which interacts (communicates) with the system: User External system (Another system) Physical environment (e.g. Weather) An actor has a unique name and an optional description Examples: Passenger: A person in the train GPS satellite: An external system that provides the system with GPS coordinates. Passenger Optional Description ATM actors: client, bank, operator Name

ATM System Actor 1 Actor 2 Actor 3

ATM System

Use Case • A use case represents a class of functionality provided by the system • Use cases can be described textually, with a focus on the event flow between actor and system • The textual use case description consists of 6 parts: Unique name Participating actors Entry conditions Exit conditions Flow of events Special requirements. PurchaseTicket

Textual Use Case Description Example Passenger Textual Use Case Description Example PurchaseTicket 1. Name: Purchase ticket 2. Participating actor: Passenger 3. Entry condition: Passenger stands in front of ticket distributor Passenger has sufficient money to purchase ticket 4. Exit condition: Passenger has ticket 5. Flow of events: 1. Passenger selects the number of zones to be traveled 2. Ticket Distributor displays the amount due 3. Passenger inserts money, at least the amount due 4. Ticket Distributor returns change 5. Ticket Distributor issues ticket 6. Special requirements: None. Question: Anything missing? Answer: Exceptional cases! Use cases represent functionality of the system All use cases need to be described for the model to be useful Use case diagrams are useful as an index into the use cases The Textual Use case descriptions provide meat of model, not the use case diagrams.

ATM System

ATM System

Uses Cases can be related Extends Relationship To represent seldom invoked use cases or exceptional functionality Includes Relationship To represent functional behavior common to more than one use case.

The <<extends>> Relationship <<extends>> relationships model exceptional or seldom invoked cases The exceptional event flows are factored out of the main event flow for clarity The direction of an <<extends>> relationship is to the extended use case Use cases representing exceptional flows can extend more than one use case. Passenger PurchaseTicket <<extends>> <<extends>> <<extends>> <<extends>> OutOfOrder TimeOut Cancel NoChange

The <<includes>> Relationship <<includes>> relationship represents common functionality needed in more than one use case <<includes>> behavior is factored out for reuse, not because it is an exception The direction of a <<includes>> relationship is to the using use case (unlike the direction of the <<extends>> relationship). Passenger PurchaseMultiCard PurchaseSingleTicket <<includes>> <<includes>> CollectMoney NoChange <<extends>> Cancel

ATM System ? ?

ATM System Is kind of… Hierarchy type?

Use Case Diagrams: Summary Use case diagrams represent external behavior Use case diagrams are useful as an index into the use cases Use case descriptions provide meat of model, not the use case diagrams. All use cases need to be described for the model to be useful.

To do… Read chapters 1 and 2 Introduce yourselves to your project groups, let me know if anyone dropped/added the course Work on the Use Case report for your project.