Software Development2D1385

Karl Meinke

NADA

KTH

karlm@nada.kth.se

1.1. Lab Exercises

• Labs 1,2 Java API, Graphics, event handling

• Lab 3 client-server with sockets• Lab 4 XML, syntax and parsing• Lab 5 interprocess communication with

CORBA• Lab 6 build a web browser using Java

Swing components

1.2. Course Book

“Software Design” by Eric Braude, 2004

Chpt: 0-2 Programming Concepts3: Unified Modeling Language UML4-5: Software Design Principles6-9: Design Patterns10-12: Software Components (Beans .NET)13-14: Software architecture

1.3. Goals of the Course

• Software Design Theory and Practice• Starts where programming and data structure

courses end• Understanding how to satisfy requirements

specifications (application is correct and adequate)

• Obtain robust, flexible reusable applications• Apply abstraction, encapsulation and

modularity

1.4. Good Program Modules

• A program module should be simple, clear and minimal

• It shouldn’t surprise the end-user

• Dependencies between modules should be few

• Modules should be usable, correct, robust, flexible and maintainable.

1.5. Checklist for Submitting Work

• Which engineering/management model has been used?

• Show your UML –diagram for the lab• Demonstrate using a program execution that

the functional and design requirements are satisfied

• Explain how robustness, and reusability are satisfied

1.5. Checklist (2)

• How have you achieved abstraction, encapsulation and modularity

• Which design patterns have been used?

• Which classes have you reused from earlier labs? (With refactoring?)

• Which new classes have you used, and why?

1.5. Checklist (3)

• How have you performed functional testing?

• How have you documented your program (comments, javadoc etc.)

• Point out the most critical pieces of code.

• In retrospect, what would you have done differently if the project had continued?

1.6. UML

The Unified Modeling Language (2.0)

• Class/Object diagrams (static)

• Sequence diagrams (dynamic)

• Activity diagrams (dynamic)

• Statecharts (dynamic)

Standard developed by OMG adopts earlier

ideas (Booch, Rumbaugh, Jacobson)

1.6.1. Models

Models express requirements, architecture &

detailed design. (Video Game examples)

Use Case Model: In this situation do the following …

e.g. how to engage a foreign character

Object / Class Model: with objects of these classes …

Object provides a set of services, e.g. engagement class.

State Model: by reacting to these events …

state/event reaction

e.g. if foreign character shoots while we are friendly … run away

Data Flow Model: in this way …

e.g. bullet objects flow from foreign character object to player object.

Target App

Use Cases Class Model

State ModelData Flow

2. O-O Analysis & Design

The basic OOA&D approach (iterative)

1. State the main use cases

2. Convert the use cases to sequence diagrams

3. Select the resulting domain classes

4. If not finished goto 1.

2.1. UML Use Case DiagramsUML gives us a graphical language toorganize all our use case scenarios into one overview:

Use Case DiagramsThese display:• actors• use cases• associations, i.e. which actors are involved in

which scenario

Activate

Check in

Check out

Add video

Clerk

Stocker

Precondition: app has been activated

1. Actor clicks “check out”

2. Actor swipes bar code ….

Postcondition: video is registered to customer

2.2. Use Case ModelingIn O-O based IT projects, we can begin the

requirements analysis phase with a

Use Case Analysis

A use case is a common or representative

situation where one or more external users

and/or systems interact with the system to

solve an instance of a common problem

Notice the underlined word “common”

Software seems to obey the statistical Pareto Law

90% of time is spent executing just 10% of the code

Therefore care in designing just this 10% of code is “cheap” and will give a good product 90% of the time (at least in theory!)

Note: we want to decouple

specific users (e.g. John Smith)

From their roles, e.g.

student, teacher, systems administrator, etc.

A role will be called an actor.

A specific proper noun (object)

e.g. Karl Meinke, may play several roles:

teacher, researcher, sysadmin ...

Use Case Modeling involves three steps

that may be repeated until we are satisfied.

Step 1. Identify, name and define each actor

in terms of:

(a) Goals, i.e. what the actor wants to do,

(b) Needs, i.e. what services from the system

the actor requires to meet each goal.

Step 2. For each system service

(identified in Step 1), informally describe the

• preconditions and

• results of the service, and its,

• interaction with the actors in: – a typical case (sunny day scenario). – exceptional and error cases (rainy day scenario)

Such a service description is called an informal description of a use case scenario.

Step 3. For each informal description which

is:– mission critical– unclear, or– ambiguous

formalise the interaction of the system and

the relevant actors using a sequence diagram

Step 4. [If necessary, repeat Steps 1-3]

Makes an iterative requirements analysis

1. Actors

2. Use cases

3. SequenceDiagrams

2.3. Example

Let us analyse requirements on a

Warehouse management system

Step 1. We begin by identifying actors

(perhaps by looking at a particular warehouse

and identifying job titles). This might give

the following:

• Foreman: responsible for one warehouse.

• Warehouse Worker: works in a warehouse loading and unloading goods.

• Truck Driver: drives a truck between different warehouses

• Forklift Operator: drives a forklift in a warehouse

• Office Staff?, Customers? Security Staff?? …

Table 2.3.1

These actor definitions are short, but enough

to get started on Step 2. By iterating again

later we can add more details.

Step 2 asks to focus on the services which the

system (warehouse management software)

must provide.

We build a list of informal use case scenarios.

Notice how in Table 2.3.1 we underlined:

• Nouns: e.g. foreman, warehouse, …

• Verbs: e.g. loading, unloading …

• Relational Phrases: e.g. responsible for, works in, … (prepositions?)

(Notice the possible overlap between verbs

and relational phrases.)

This identification work is the heart of O-O

analysis and design, since …

2.3.2. Central O-O Dogma

• Common Nouns e.g. warehouse, truck, correspond to classes and attributes

• Proper Nouns e.g. Karl, Fido, KTH, correspond to objects

• Verbs e.g. unload, correspond to methods

• Relational Phrases e.g. responsible for, works with correspond with system and/or software “structure”

Not every noun will be an actor …

(does a forklift truck have any goals ???)

… but every actor will be a noun, so:

Actors Nouns

Step 2 requires us to look at each actor in turn

(in our case there are 4 actors) and ask:

• What does this actor want to do (all verbs)?

• What does the actor need from the system

to accomplish each activity (each verb)?

Let’s look at the 1st actor “foreman” and try

to analyse the verb “responsible”.

(a) A foreman has to be able to move items between warehouses with or without a customer order. This use case scenario is called “manual redistribution between warehouses”

(b) A foreman also wants to check how far a customer order has been processed. We call this use case scenario “check status of acustomer order”.

Let’s try to informally define the 1st use case

scenario: “manual redistribution between

Warehouses”.

This could be broken down into 4 steps

(1) Initialisation: when a foreman gives a

request to do a redistribution.

(2) Planning: when the system plans how to

co-ordinate the various transports, and issues transport requests

(3) Loading: when a truck fetches the items

from a source warehouse.

(4) Unloading: when a truck delivers items

to a destination warehouse.

Is there anything wrong with this use case?

(1) It is very short!- but we can add detail later!

(2) It doesn’t say what happens if things go

wrong.

- We need to add exception/error cases.

- The more of these we add, the more

robust our system will be.

2.4. UML Sequence Diagrams

A use case scenario describes a

sequence of interactions

or

messages

between a

collection of actors and the system

in order to carry out some task

Often we would like to formally model

a use case scenario, to study:

• timing aspects (relative or absolute)

• communication patterns

• system states

• exception behavior

• alternative paths or behaviors

2.4.1. Elementary Concepts

A basic sequence diagram depicts a set of objects or

processes each of which has its own timeline.

Conventionally, objects go across the diagram

horizontally, while time goes down the diagram

vertically. Down the timelines, between

objects, we show messages.

C : Computer P : Print_server D : Device

>lprfile

print(file, device)print(file,size)

donedone

>done(time)

Here is our earlier sequence diagram drawn as an SD/MSC:

object/processtimeline message

time

SD Print

Notice that:• This basic SD has 3 objects and 6 messages• 1 message comes from the environment:

>lpr file (from the keyboard??)

• 1 message goes to the environment>done(time) (to the screen??)

• The environment is an implicit actor

• Each timeline has a terminating block at thebottom, which does not mean that the objectdissappears/ gets deleted, life goes on!!

2.4.2. The Time Concept

An SD/MSC must show

dynamic behavior over time

Down each timeline we see a set of events .

Each event may either be:

• sending of a message (arrow tail)

• receiving of a message (arrow head)

Each timeline shows the local relative orderbetween events, but not the absolute timeinterval between events.

Thus the basic model of time is relative (instead of absolute).

Also, for every message m:

send(m) occurs before receive(m)

This means that, e.g.

receive(>lpr file) occurs before

send( print(file, device) )

which occurs before

receive(done)

which occurs before

send(>done(time) )

and e.g. send(done)

occurs before receive(done)

We don’t know the absolute time between sending

and receiving a message, i.e. message delay.

e.g these two diagrams express the same scenario.

BA A B“a”

“b”

“a”

“b”

SD 1 SD 2