1

The Object-oriented Paradigmand

The Unified Modeling Language (UML)

2

"problems" of software development (review):

**conceptual integrity

**incremental build, progressive refinement

**large projects "differ" from small ones

programming paradigms (1950’s-present): attempts to deal effectively with these problems, make software easier to develop and to maintain

Problems of software development

3

Computer Language / Design Methodology: brief history:

1950's:unstructured, no information hiding--”spaghetti” code, GOTO, flowcharts--machine code--assembly lang. --FORTRAN, LISP(Algol; COBOL)

1980’s: structured, top-down design (“3 basic control structures, no GOTO”), modularity--Pascal--(C)--Ada

1990’s: encapsulation, information-hiding, reuse, hardware/software codesign (from simulation languages developed much earlier, e.g., Modula, simula)

--C++--Java

2000’s: info hiding; web languages; environments encapsulating multiple languages, styles--.NET, C#--Python--MATLAB, Mathematica, Labview, …

Languages and design methodology

4

1950's:unstructured, no information hiding--”spaghetti” code, GOTO, flowcharts--machine code--assembly lang. --FORTRAN, LISP (Algol; COBOL)

1970s,1980s: structured, top-down design (“3 basic control structures, no GOTO”), modularity--Pascal, C, PL/I, Ada

1990’s: encapsulation, information-hiding, reuse, hardware/software codesign (from simulation languages developed much earlier, e.g., Modula, simula)--C++, Java

2000’s: info hiding; web languages; environments encapsulating multiple languages, styles--.NET, C#, Python, Perl, MATLAB, Mathematica, Labview, …

A Brief History: Computer Hardware, Computer Languages, Design Techniques

Early machines—large, central (Eniac)

Supercomputers, “Minicomputers”, PCs, multiuser machines, PICs

Beowulf clusters, Spread of the Internet

“Ubiquitous computing”, laptops,.Personal communication devices, multicore processors, GPUs

wpclipart.com

chilton-computing.org.uk

techxav.com

http://en.wikipedia.org/wiki/PIC_microcontroller#History

cse.mtu.edu

visual.merriam-webster.com

5

Important basic OO concepts:

class: encapsulates data structure (object) and associated methods (functions) these may be declared public / private / protected

appropriate uses:

public: pass info to object or request info about object(use "messages") (can be used by anyone)

private: modify object (can be used in class or by “friends”)

protected: for descendants (in class or by derived class and “friends”)

OO class

6

traditional: record (struct): functions to use or modify this record can be anywhere in the program

OO: class concept supports encapsulation, information hiding

Record/class

DATA

DATA

DATA

DATA

DATA

DATA

DATA

Procedural Prog.

OO Prog.

7

Useful OO techniques:

Inheritance:ex: in a program modeling an ecosystem, we might have the relationships:

wolf is carnivore; sheep is herbivore; grass is plant carnivore is animal; herbivore is animalanimal is organism; plant is organism

here the base class “organism” holds data fields which apply to all organisms, e.g., amount of water needed to survive two derived classes, plant and animal, hold information specific to each of these types of organisms, e.g., kind of soil preferred by plantthe animal class also has two derived classes, wolf and sheep

Inheritance allows the collection of common attributes and methods in "base" class and inclusion of more specific attributes and methods in derived classes

Inheritance

A. B.Ex: Object data

structures:

A. Base class

B. Derived class

X

Y

Z

X

Y

Z

W

8

Polymorphism:

base class can define a “virtual” function; appropriate versions of this function can be instantiated in each derived class (e.g., "draw" in the base class of graphical objects can have its own specific meaning for rectangles, lines, ellipses)

Overloading:

ex: cin >> num1;>> is overloaded "shift”

ex: “+” can be overloaded to allow the addition of two vectors

ex: a function name can be overloaded to apply to more than one situation; e.g., a constructor can be defined one way if initial values are given and a different way if initial values are not given

Polymorphism and overloading

9

Templates:

example:

template <class T> T method1 (T x) …..

can be specialized: int method1 (int x)

float method1 (float y)

usertype method1 (usertype a)

templates promote reuse

Templates

10

Separate compilation:

Typically, an object-oriented program can be broken into three sets of components:

definitions and prototypes (text files, “header files”)

implementations (compiled--source code need not be available to user)

application program--uses the classes defined in header files and supported by the implementation files

This strategy promotes reuse and information hiding

Separate compilation

11

Note: no paradigm is misuse-proof

Misuse of object-oriented paradigm

12

Developing an OO project: we will use UML (subset)

determine specifications:use cases[scenario: instance of use case; concrete informal

description of 1 feature; enhances understanding of use case]

determine classes and connections (static behavior): ER or class diagramsCRC cards

model dynamic behavior:interaction (object message) diagramsactivity diagramsstate diagramssequence diagrams

Using OO & UML in quarter project

13

UML: a language for specifying and designing an OO project

UML: stands for "unified modeling language”

unifies methods of Booch, Rumbaugh (OMT or Object Modeling Technique), and Jacobson (OOSE or Object-Oriented Software Engineering)

mainly a modeling language, not a complete development method

Early versions -- second half of the 90's

Not all methods we will use are officially part of the UML description (e.g., CRC cards)

There exist many versions of UML—syntax may have slight differences among versions—be aware of this as you read and work on homework and projects

14

USE CASES: a part of the ”Unified Modeling Language" (UML) which we will use for requirements analysis and specification

each identifies a way the system will be used and the "actors" (people or devices) that will use it (an interaction between the user and the system)

each use case should capture some user-visible function and achieve some discrete goal for the user

an actual user can have many actor roles in these use cases

an instance of a use case is usually called a "scenario”

Use case will typically have graphical & verbal forms

Use cases

15

Example: cellular network place and receive calls use case (based on Booch, Rumbaugh, and Jacobson, The Unified Modeling Language User Guide)

Place call

Receive call

Use scheduler

Receive additional

call

Place conference

call

Cellular network

User

Use Case (Example) Key: Use Case Actor “Extends” “Uses”

Validate user

Example use case

System boundary

Text description --Use case name (cellular network place and receive calls)--Participating actors (cellular network and human user)--Flow of events (network or user accesses network to use its functionality)--Entry condition(s) (user accesses network using device or password) --Exit condition(s) (call completed lost or network busy)--Quality requirements (speed, service quality)--Open issues (for future versions, e.g.)

Text description—gives important details

Use case diagram—summarizes, provides system overview

16

use case

Text description:

Use case name

Participating actors

Flow of events

Entry condition(s)

Exit condition(s)

Quality requirements

17

Use case—detailed example (Pressman)

Example: “SAFEHOME” system (Pressman)Use case: InitiateMonitoring(Pressman text categories:

•Primary actor (1) •Goal in context (2) •Preconditions (3) •Trigger (4)•Scenario (5)•Exceptions (6)•Priority (system development) (7)•When available (8)•Frequency of use (9)•Channel to actor (10)•Secondary actors (11)•Channels to secondary actors (12)•Open issues (13) )

Arms/disarms system

Accesses system via internet

Responds to alarm event

Encounters an error condition

Reconfigures sensors

and related system features

Homeowner

System administrator

Sensors

Pressman, p. 163, Figure 7.3

18

Use case—detailed example (Pressman)

Example: “SAFEHOME” system (Pressman)

Use case name: InitiateMonitoring

Participating actors: homeowner, technicians, sensors

Flow of events (homeowner):--Homeowner wants to set the system when the homeowner leaves house or remains in house--Homeowner observes control panel--Homeowner enters password--Homeowner selects “stay” or “away”--Homeowner observes that read alarm light has come on, indicating the system is armed

19

Use detailed example (Pressman)--continued

Entry condition(s)

Homeowner decides to set control panel

Exit condition(s)

Control panel is not ready; homeowner must check all sensors and reset them if necessary

Control panel indicates incorrect password (one beep)—homeowner enters correct password

Password not recognized—must contact monitoring and response subsystem to reprogram password

Stay selected: control panel beeps twice and lights stay light; perimeter sensors are activated

Away selected: control panel beeps three times and lights away light; all sensors are activated

20

Use case—detailed example (Pressman)

Quality requirements:

Control panel may display additional text messages

time the homeowner has to enter the password from the time the first key is pressed

Ability to activate the system without the use of a password or with an abbreviated password

Ability to deactivate the system before it actually activates

21

Use case additions—simplifications of use case descriptions

A. Include: one use case includes another in its flow of events (cases A and B both include case C)

Example: report a fire: both “open incident” and “send fire trucks” include the use case “view city map”

B. Extend: extend one use case to include additional behavior (cases D and E are extensions of case F)

Example: ConnectionDown between two emergency responders is a “special case” of Reportemergency but it can use the basic functionality of ReportEmergency

A

B

C<<include>>

<<include>>

FE

D

<<extend>>

<<extend>>

22

Use case additions

C. Inheritance: one use case specializes the more general behavior of another G and H specialize behavior of J)

Note: use case inheritance is BEHAVIORAL or FUNCTIONAL inheritance

Standard OO inheritance is STRUCTURAL inheritance

H

Jauthenticate

Authenticate with card

Authenticate with password

G

23

Use case continued

Examples: what would be a use case for: vending machine user university student management system

(e.g., student changes registration)

Use case nameParticipating actorsFlow of eventsEntry conditionExit conditionQuality requirements

24

TESTING at the system level:

Use cases can form a basis for system acceptance tests

For each use case:• Develop one or more system tests to confirm that the use case requirements will be satisfied• Add explicit test values as soon as possible during design phase• These tests are now specifically tied to the use case and will be used as the top level acceptance tests

Do not forget use cases / tests for performance and usability requirements (these may be qualitative as well as quantitative)

System Tests

25

Requirements Specifications …..

Use cases, tests classes, …

Requirements must be:--complete--consistent--unambiguous--correct

26

Another way to organize requirements (text)--FURPS:

Functional requirements:*F—functionality

Nonfunctional requirements:“Quality”:*U—Usability

*R—Reliability (Dependability—reliability, robustness, safety)

*P—Performance

*S—Supportability

“Constraints”:*implementation requirements

Operations requirements, packaging requirements, legal requirements

* = important this quarter

27

Steps to turn requirements into specifications:

--identify actors

--identify scenarios (specific examples of use cases)

--identify use cases

--refine use cases as appropriate (extends / includes)—don’t overdo this

--identify relationships among actors and use cases

--can now begin to identify objects needed ( design)

--also need to identify nonfunctional requirements

28

Use case writing guide (p. 137 of text):

--each use case should be traceable to requirements--name should be a verb phrase to indicate user goal--actor names should be noun phrases--system boundary needs to be clearly defined--use active voice in describing flow of events, to make clear who does what--make sure the flow of events describes a complete user transaction---if there is a dependence among steps, this needs to be made clear--describe exceptions separately--DO NOT describe the user interface to the system, only functions--DO NOT make the use case too long—use extends, includes instead --as you develop use cases, develop associated tests

29

Example—bank simulation (Horstmann)

Teller 1

Teller 2

Teller 3

Teller 4

Customer 1Customer 3 Customer 2

Horstmann, Mastering Object-Oriented Design in C++, Wiley, 1995

30

Use Cases--Bank

Goal: Develop a tool to simulate the bank to decide on optimal values for number of tellers, number of customer queues, etc.

Use cases?