2-The Object-Oriented Design Process

Published on June 2017 | Categories: Documents | Downloads: 40 | Comments: 0 | Views: 244
of 76
Download PDF   Embed   Report

Comments

Content

The Object-Oriented
Design Process

Introduction to UML

Unified Modeling Language


UML is a graphical language for visualizing, specifying,
constructing, and documenting the artifacts of a
softwareintensive system.



UML is established by the Object Management Group
(OMG) as the standard notation for distributed object
systems.



UML is just a notation. It is not, nor does it specify:





Processes



Tools



Programming languages

Using UML aids in communication among analysts,
designers, and programmers.
3

A brief history of UML


In the early to mid-1990s, three modeling languages were popular



Each was developed by a leader in the world of OO:







James Rumbaugh – object-modeling technique (OMT)



Grady Booch – Booch method



Ivar Jacobson – Object-oriented software engineering

All three joined Rational in 1994 and 1995


Became known as “The Three Amigos”



Combined their methodologies to creating the non-proprietary Unified
Modeling Language (UML) in 1996

UML is officially defined by the Object Management Group (OMG)


UML 1 – Submitted in 1996



UML 2 – Submitted to OMG in 2003

4

Some important UML artifacts


Use case diagrams and descriptions capture the
requirements of the system.



Class diagrams capture the classes, attributes,
methods for classes and the relationships between
classes.
 Object diagrams

are a variant of class diagrams that show
specific objects to give an example or snapshot of running
system.



Activity diagrams show flow of activities in a
process.
5

Some important UML artifacts


State machines show change of state and events
that cause change of state for specific objects.



Interaction diagrams show interactions between
objects.
 There

are several types of interaction diagrams.

 Sequence diagrams

show sequence of messages among
objects in an execution scenario.



UML also defines:


Component diagrams show physical structure of software components.



Deployment diagrams show the architecture of a system in terms of
physical nodes (hardware) and distribution of software components.
6

Use case diagram


How users interact with a system

7

Class diagram


Class diagrams show the classes involved in a
system and relationships between them.

8

Class and object diagrams


A class diagram is used to show classes, their attributes,
their methods and their relationship to other classes.



An object diagram is used to show specific instances
individual objects and the values of their attributes at one
point in time.

9

Activity diagram


Procedural and parallel behavior

10

State machine


How events change state of an object over its life

11

Sequence diagram


Interaction between objects; emphasis on sequence

12

Communications diagram


Interaction between objects; emphasis on links

13

Summary of UML symbols

14

Drawing UML diagrams


Products from Rational that create UML
 Rational Software

Modeler

 Rational Software

Architect

 Rational RequisitePro



 Rational Method

Composer

 Rational Unified

Process

Open source tools are also available, including
plug-ins for Eclipse
 http://www.eclipse.org

15

Using UML in the software development process


The main purpose of UML is to facilitate
communication among all people involved in the
development process



UML is a visual language that is made up of
diagrams
 Often

textual documents accompany the UML, especially
in larger scale projects that require a more formal process



UML should be modified as design decisions are
refined
16

Using UML in the software development process


UML is used on all stages of software development
 Requirements gathering


Use cases describe system functionality

 Analysis


Class and interaction diagrams model the business domain

 Design


of the business problem

of the code

Class and interaction diagrams help design the code

 Implementation


State, activity, and sequence show how scenarios unfold

 Testing


Should verify all scenarios describes by use cases

17

Topics















18

UML
From Problem to Code
The Object and Class Concepts
Identifying Classes
Identifying Responsibilities
Relationships Between Classes
Use Cases
CRC Cards
UML Class Diagrams
Sequence Diagrams
State Diagrams
Using javadoc for Design Documentation
Case Study: A Voice Mail System

From Problem to Code


Three Phases:
 Analysis

 Design
 Implementation

19

Analysis Phase


Establish the functions, services, and constraints
of the software to be developed.
 The developers

and the software users work together to
produce a requirements specification, which will be the
input to the design phase.



Functional Specification which is a part of
requirements specification, has the following
characteristics:
 Completely defines

tasks to be solved
 Free from internal contradictions
 Readable both by domain experts and software developers
 Reviewable by diverse interested parties
 Testable against reality
20

Design Phase


Goals
 Identify classes

 Identify behavior

of classes

 Identify relationships among



Artifacts
 Textual description of

classes and key methods

 Diagrams

of class relationships

 Diagrams

of important usage scenarios

 State diagrams

21

classes

for objects with rich state

Implementation Phase


Implementation is the realization of the software
design in a specific programming language. Each
unit (a single class) is implemented separately.



Unit testing is done to ensure that each unit
functions properly with respect to its specification
before the units are integrated.



The individual units are integrated and tested as a
whole to ensure that the entire software system
works properly conforming to its specification.

22

Case Study: Voice Mail System


Use text for voice, phone keys, hangup



1 2 ... 0 # on a single line means key



H on a single line means "hang up"



All other inputs mean voice



In GUI program, will use buttons for keys

23

Identifying Classes


Rule of thumb: Look for nouns in problem
description
 Mailbox
 Message
 User
 Passcode
 Extension
 Menu



Focus on concepts, not implementation
 MessageQueue stores

24

 Don't

messages

worry yet how the queue is implemented

Categories of Classes


Tangible Things



Agents



Events and Transactions



Users and Roles



Systems



System interfaces and devices



Foundational Classes

25

Identifying Responsibilities


Rule of thumb: Look for verbs in problem
description



An example: Behavior of MessageQueue:
 Add

message to tail

 Remove

 Test



message from head

whether queue is empty

OO Principle: Every operation is the
responsibility of a single class
 Example:

Add message to mailbox
 Who is responsible: Message or Mailbox?
26

Class Relationships
The following relationships can exist among classes:


Dependency ("uses")



Association, including aggregation and
composition



Generalization, including inheritance and
implementation



Among them, inheritance ("is-a"), aggregation
("has"), and dependency ("use") are the most
basic relationships

27

Dependency Relationship


Class A depends on class B: method of A manipulates objects of B in
the parameters, local variables, or return types



Minimize dependency: reduce coupling


Example: Removes dependence on System and Message
Replace
public class Message{
void print() { System.out.println(text); }

with
public class Message{
String getText() { // can print anywhere }


28

An example and UML notation for dependency

Association


Association represents general binary relationships
between classes



Association can have roles



Implemented through instance fields



An example and UML notation for association
relationship

29

Aggregation


A special form of association









30

Represents the has-a or part-whole relationship.
Simply a structural relationship that distinguishes the whole, that is, the
aggregate class, from the parts, that is, the component class.
Implemented through instance fields
e.g. MessageQueue aggregates Messages
e.g. Mailbox aggregates MessageQueue

An example and UML notation for aggregation

Composition




31

A stronger form of aggregation


The aggregate class exclusively owns the component class.



The lifetime of the components is entirely included in the lifetime of
the aggregate.



Contained objects don't exist outside container

An example and UML notation for composition: message
queues permanently contained in mail box

Association Direction




Some associations are bidirectional
 Can

navigate from either class to the other

 e.g.

Course has set of students, student has set of courses

Some associations are directed
 Navigation is
 e.g.

it

32

unidirectional

Message doesn't know about message queue containing

Multiplicities


any number (0 or more): *



one or more: 1..*



zero or one: 0..1



exactly one: 1



Implementation:


1, 0..1 relationship:
public class Mailbox{
...
private MessageQueue queue;
}



1:n relationship:
public class MessageQueue{
...
private ArrayList<Message> elements;
}

33

Generalization - Inheritance relationship


Inheritance relationship is formed when a class (or an
interface) extends another class (or interface).



UML notation for generalization

34

Generalization - implementation relation


The implementation relation between a class and an
interface



Interface type describes a set of methods. No
implementation, no state



Class implements interface if it implements its methods



UML notation for implementation relation

35

Use Cases


Analysis technique



Each use case focuses on a specific scenario



Use case = sequence of actions



Action = interaction between actor and computer
system



Each action yields a result



Each result has a value to one of the actors



Use variations for exceptional situations

36

Sample Use Case
Leave a Message
1.

Caller dials main number of voice mail system

2.

System speaks prompt
Enter mailbox number followed by #

3.

User types extension number

4.

System speaks
You have reached mailbox xxxx. Please leave a
message now

5.

Caller speaks message

6.

Caller hangs up

7.

System places message in mailbox

37

Sample Use Case -- Variations


Variation #1
1.1. In step 3, user enters invalid extension number

1.2. Voice mail system speaks
You have typed an invalid mailbox number.

1.3. Continue with step 2.



Variation #2
2.1. After step 4, caller hangs up instead of speaking message

2.3. Voice mail system discards empty message

38

CRC Cards


CRC = Classes, Responsibilities, Collaborators
a

very effective design tool in identifying classes, their
responsibilities, and relationships to other classes



Developed by Beck and Cunningham



Use an index card for each class



Class name on top of card



Responsibilities on left



Collaborators on right

39

CRC Cards

40

CRC Cards


Responsibilities should be high level without
concerning implementation details



Between 1 - 3 responsibilities per card is ideal



Collaborators are for the class, not for each
responsibility

41

How do you create CRC models
A CRC model is created iteratively performing the
following steps:


Find classes



One card per class



Walk through scenario of use cases, to find
responsibilities, define collaborators to fill in cards

42

Walkthroughs


Use case: "Leave a message"
 Caller connects

 Caller dials

to voice mail system

extension number



"Someone" must locate mailbox



Neither Mailbox nor Message can do this



New class: MailSystem



Responsibility: manage mailboxes

43

Walkthroughs

44

Other UML Diagrams


Many UML diagram types



We'll use three types:
 Class

Diagrams

 Sequence

Diagrams

 State Diagrams

45

Sequence Diagrams


Each diagram shows dynamics of scenario



Object diagram: class name underlined

46

Sequence Diagrams
Self call

47

Object Construction

State Diagram


48

Use for classes whose objects have interesting states

Design Documentation


Recommendation: Use Javadoc comments



Leave methods blank
/**
Adds a message to the end of the new
messages.
@param aMessage a message
*/
public void addMessage(Message aMessage)
{
}



Don't compile file, just run Javadoc



Makes a good starting point for code later

49

Case Study: Voice Mail System


Use text for voice, phone keys, hangup



1 2 ... 0 # on a single line means key



H on a single line means "hang up"



All other inputs mean voice



In GUI program, will use buttons for keys

50

Use Case: Reach an Extension
1.

User dials main number of system

2.

System speaks prompt
Enter mailbox number followed by #

3.

User types extension number

4.

System speaks
You have reached mailbox xxxx. Please
leave a message now

51

Use Case: Leave a Message
1.

Caller carries out Reach an Extension

2.

Caller speaks message

3.

Caller hangs up

4.

System places message in mailbox

52

Use Case: Log in
1.

Mailbox owner carries out Reach an Extension

2.

Mailbox owner types password and #
Default password = mailbox number. To change,
see Change the Passcode

3.

System plays mailbox menu:
Enter 1 to retrieve your messages.
Enter 2 to change your passcode.
Enter 3 to change your greeting.

53

Use Case: Retrieve Messages
1.

Mailbox owner carries out Log in

2.

Mailbox owner selects "retrieve messages" menu option

3.

System plays message menu:
Press
Press
Press
Press

1
2
3
4

to
to
to
to

listen to the current message
delete the current message
save the current message
return to the mailbox menu

4.

Mailbox owner selects "listen to current message"

5.

System plays current new message, or, if no more new messages,
current old message.
Note: Message is played, not removed from queue

6.

System plays message menu

7.

User selects "delete current message". Message is removed.

8.

Continue with step 3.

54

Use Case: Retrieve Messages
Variation #1
1.1. Start at Step 6
1.2. User selects "save current message".


Message is removed from new queue and appended to
old queue

1.3. Continue with step 3.

55

Use Case: Change the Greeting
1.

Mailbox owner carries out Log in

2.

Mailbox owner selects "change greeting" menu option

3.

Mailbox owner speaks new greeting

4.

Mailbox owner presses #

5.

System sets new greeting

Variation #1: Hang up before confirmation
1.1. Start at step 3.
1.2. Mailbox owner hangs up.

1.3. System keeps old greeting.

56

Use Case: Change the Passcode
1.

Mailbox owner carries out Log in

2.

Mailbox owner selects "change passcode" menu option

3.

Mailbox owner dials new passcode

4.

Mailbox owner presses #

5.

System sets new passcode

Variation #1: Hang up before confirmation
1.1. Start at step 3.
1.2. Mailbox owner hangs up.

1.3. System keeps old passcode.

57

CRC Cards for Voice Mail System
Some obvious classes


Mailbox



Message



MailSystem

58

Initial CRC Cards

59

Telephone


Who interacts with user?



Telephone takes button presses, voice input



Telephone speaks output to user

60

Connection


With whom does Telephone communicate


With MailSystem?



What if there are multiple telephones?



Each connection can be in different state (dialing,
recording, retrieving messages,...)



Should mail system keep track of all connection states?



Better to give this responsibility to a new class

61

Analyze Use Case: Leave a message
1.

User dials extension. Telephone sends number to Connection


Add collaborator Connection to Telephone

2.

Connection asks MailSystem to find matching Mailbox

3.

Connection asks Mailbox for greeting


Add responsibility "manage greeting" to Mailbox, add collaborator
Mailbox to Connection

4.

Connection asks Telephone to play greeting

5.

User speaks message. Telephone asks Connection to record it.


Add responsibility "record voice input" to Connection)

6.

User hangs up. Telephone notifies Connection.

7.

Connection constructs Message


8.
62

Add card for Message class, add collaborator Message to Connection

Connection adds Message to Mailbox

Result of Use Case Analysis

63

Result of Use Case Analysis

64

Analyse Use Case: Retrieve messages
1.

User types in passcode. Telephone notifies Connection

2.

Connection asks Mailbox to check passcode.


Add responsibility "manage passcode" to Mailbox

3.

Connection sets current mailbox and asks Telephone to speak menu

4.

User selects "retrieve messages". Telephone passes key to Connection

5.

Connection asks Telephone to speak menu

6.

User selects "listen to current message". Telephone passes key to Connection

7.

Connection gets first message from current mailbox.



Add "retrieve messages" to responsibility of Mailbox.
Connection asks Telephone to speak message

8.

Connection asks Telephone to speak menu

9.

User selects "save current message". Telephone passes key to Connection

10.

Connection tells Mailbox to save message


11.

65

Modify responsibility of Mailbox to "retrieve, save, delete messages"

Connection asks Telephone to speak menu

Result of Use Case Analysis

66

CRC Summary


One card per class



Responsibilities at high level



Use scenario walkthroughs to fill in cards



Usually, the first design isn't perfect.
(You just saw the author's third design of the mail
system)

67

UML Class Diagram for Mail System


CRC collaborators yield dependencies



Mailbox depends on MessageQueue



Message doesn't depends on Mailbox



Connection depends on Telephone,
MailSystem, Message, Mailbox



Telephone depends on Connection

68

Dependency Relationships

69

Aggregation Relationships


A mail system has mailboxes



A mailbox has two message queues



A message queue has some number of messages



A connection has a current mailbox.



A connection has references to a mailsystem and a
telephone

70

UML Class Diagram for Voice Mail System

71

Sequence Diagram for Use Case: Leave a message

72

Interpreting a Sequence Diagram


Each key press results in separate call to dial, but only one
is shown



Connection wants to get greeting to play



Each mailbox knows its greeting



Connection must find mailbox object:
Call findMailbox on MailSystem object



Parameters are not displayed (e.g. mailbox number)



Return values are not displayed (e.g. found mailbox)



Note that connection holds on to that mailbox over
multiple call

73

Sequence Diagram for Use Case: Retrieve messages

74

Connection State Diagram

75

Final Class Diagram for Voice Mail System

76

Sponsor Documents

Or use your account on DocShare.tips

Hide

Forgot your password?

Or register your new account on DocShare.tips

Hide

Lost your password? Please enter your email address. You will receive a link to create a new password.

Back to log-in

Close