Jan. 26, 2004 CS 509 - WPI 1

CS 509Design of Software Systems

Lecture #2Monday, Jan. 26, 2004

Jan. 26, 2004 CS 509 - WPI 2

Term Project AdministrationQuestionsQuiz #1Lecture #2: FS, UML & AnalysisIn Class Exercises:

UML Diagrams Analysis Objects Term Project Discussion

Class Format for Today

Jan. 26, 2004 CS 509 - WPI 3

CTS Project

Turn in Phase 1 (Requirements) documents and Journals

Several emails were sent out to the class mailing list about requirements. Did everyone receive the messages?

Hand out Phase 2 document – We will discuss after the quiz

Jan. 26, 2004 CS 509 - WPI 4

Questions?

From last week’s classFrom the readingAbout the CTS ProjectAnything else?

Jan. 26, 2004 CS 509 - WPI 5

Quiz #1

Chapters 1, 4 & 2You have 15 minutes.

Jan. 26, 2004 CS 509 - WPI 6

Phase 2

Functional Specifications

Jan. 26, 2004 CS 509 - WPI 7

Discussion

What is a Functional Specification?

What purpose does it serve?What goes into a FS document?

Jan. 26, 2004 CS 509 - WPI 8

Introduction

One of the most common documents used in commercial software industry

Developers might not have much input into requirements

Often your only chance to negotiate features

May need to be updated if requirements change

Jan. 26, 2004 CS 509 - WPI 9

Purpose

Further define goals and scope of the system by detailing functionality

Determine which features impact usability

Distinguish between necessary features and “wish list” features

Get client to sign-off Consider FS to be like a contract

Jan. 26, 2004 CS 509 - WPI 10

Contents

Introduction State purpose, scope and objectives

Detailed Functionality Explain how requirements will be

coveredGlossaryMock-up or Prototype

Show what features will look like Pictures often worth more than words

Jan. 26, 2004 CS 509 - WPI 11

Chapter 2 – UML

Unified Modeling Language

Jan. 26, 2004 CS 509 - WPI 12

What is UML?

Unified Modeling Language comes from a number of places (see 1st ¶ of Intro., p. 30)

Different notations combined into one standard

Now most commonly used standard in Software Engineering

Jan. 26, 2004 CS 509 - WPI 13

Why do we need notation?

Ability to articulate complex ideas succinctly & precisely

Conventions provide accuracy & clarity

Leaves less room for misinterpretation & ambiguity

Jan. 26, 2004 CS 509 - WPI 14

What does notation provide?

Well defined semanticsWell suited for representing a

given aspect of a system Easy to draw by hand

Well understood among project participants

Jan. 26, 2004 CS 509 - WPI 15

Overview of UML

Subset of UML diagrams covered in book: Use Case diagrams Class diagrams Interaction diagrams (AKA Sequence

diagrams) Statechart diagrams Activity diagrams

Jan. 26, 2004 CS 509 - WPI 16

Use Case Diagrams

WatchUser

ReadTime

SetTime

ChangeBattery

SimpleWatch

Figure 2-1 (page 25). A UML use case diagram describing the functionality of a simple watch.

WatchRepairPerson

Jan. 26, 2004 CS 509 - WPI 17

Class Diagrams

Batteryload()

1

2

Timenow()

PushButtonstatepush()release()

1

1

1

1

1

2

blinkIdxblinkSeconds()blinkMinutes()blinkHours()stopBlinking()referesh()

LCDDisplay

SimpleWatch

Figure 2-2 (page 26). An expanded UML class diagram describing the elements of a simple watch

Jan. 26, 2004 CS 509 - WPI 18

Interaction Diagrams

:SimpleWatch :Time:Display

pressButton1() blinkHours()

blinkMinutes()

pressButton2() incrementMinutes()

refresh()

pressButtons1And2()commitNewTime()

stopBlinking()

pressButton1()

:WatchUser

Figure 2-3 (page 27). A UML sequence diagram for a simple watch

Jan. 26, 2004 CS 509 - WPI 19

Statechart Diagrams

button1&2Pressed

button1Pressed

button2Pressed

button2Pressed

button2Pressed

button1Pressed

button1&2Pressed IncrementMinutes

IncrementHours

BlinkHours

BlinkSeconds

BlinkMinutes

IncrementSeconds

StopBlinking

Figure 2-4 (page 27). A UML statechart diagram for a simple watch.

Jan. 26, 2004 CS 509 - WPI 20

Activity Diagrams

OpenIncident

AllocateResources

CoordinateResources

DocumentIncident

ArchiveIncident

Figure 2-5 (page 28). An example of a UML activity diagram.

Jan. 26, 2004 CS 509 - WPI 21

Modeling Concepts

SystemsModelsViews

Jan. 26, 2004 CS 509 - WPI 22

Systems

Organized set of communicating parts designed for a specific purpose

Parts can be broken down into simpler subsystems

Decomposition is recursively applied to subsystems until we get to objects

Objects are small enough to be fully comprehended without further decomposition

Jan. 26, 2004 CS 509 - WPI 23

Modeling (Slide 1)

Abstraction for dealing with complexityComplex systems described by >1 modelEach model focuses on a different aspectWhat’s interesting, what’s irrelevant?

Depends on what you’re trying to modelRule of thumb: each entity should contain

at most 7 2 parts (Why?)

Jan. 26, 2004 CS 509 - WPI 24

Modeling (Slide 2)Abstractions that can answer specific

questions about phenomenaMay exist prior to the phenomena it

represents UML model of system not yet implemented Theory derived from model prior to discovery

(black hole, top quark, dark matter, etc.)Used to communicate about the system

Notation describes model Views show aspects of model for specific need

Jan. 26, 2004 CS 509 - WPI 25

Modeling Example

Airplane models: (see Figure 2-6, p. 36) Scale model of exterior surface allows

investigation of aerodynamics Flight simulator models layout &

behavior of flight instrumentsBoth models are less complex than

the real life concept (airplane) they represent

Jan. 26, 2004 CS 509 - WPI 26

Views

Decomposition of a model into smaller partsFocus on a subset of a model to make it

more understandableViews may overlapDifferent notations can be used to represent

the same view

View Model System**

describesdepicts

1 1

Figure from 1st Edition of text book. A System can be described by many different Models, each of which can be depicted by many different Views

Jan. 26, 2004 CS 509 - WPI 27

More Modeling Concepts

Data TypesAbstract Data Types (ADTs)Instances, Classes and InheritanceAbstract ClassesObjectsEvents & MessagesFalsification & Prototyping

Jan. 26, 2004 CS 509 - WPI 28

Data Types

Abstraction in context of a programming lang.

Describes an extent - a set of objects that share common characteristics: Unique name distinguishes it from other types Denotes a set of values valid for members of

type Defines structure of data Defines operations valid for members of type

Examples of Data Types? How are they defined?

Jan. 26, 2004 CS 509 - WPI 29

Abstract Data Types

Defined by an implementation-independent specification Reason about type without worrying about

impl. Changes to implementation do not effect

useDefine operations & behavior, but not

internal structure - expose API onlyExample ADTs?

How are they defined?

Jan. 26, 2004 CS 509 - WPI 30

Instances

Specific object of a particular type or class Contains value in range defined by type Has structure defined by type Can be manipulated with operations defined

by typeIn Java, an instance variable is a reference

to an object – what does this mean?Difference between Type and Instance?

Examples of instances

Jan. 26, 2004 CS 509 - WPI 31

Classes

Abstraction in the context of an object-oriented programming language

Like ADT, encapsulates structure & behavior

Unlike ADT, defined in terms of other classes in an inheritance hierarchy: Base, Super or Parent class is a

generalization Sub or Child class is a more specific

refinement

Jan. 26, 2004 CS 509 - WPI 32

Inheritance

Classes define operations and attributes that can be applied to instances

Operations/attributes defined in base class are inherited by subclass

Operations/attributes which are defined only in subclass are not accessible in base class

Jan. 26, 2004 CS 509 - WPI 33

Abstract Classes

Generalization Purpose is to model shared attributes &

behaviorUsed to reduce complexity, promote

reuseRepresents generalized conceptNever instantiated

Does not correspond to any existing concept Reference may be used in polymorphism

Examples?

Jan. 26, 2004 CS 509 - WPI 34

Objects

Instance of a class Unique identity, stores attribute values (state) Each object belongs to exactly one class

Instance names are underlined in UML Distinguish from type/class that defines them

Attributes may not be visible to entire system Type modifiers specify visibility Examples?

Jan. 26, 2004 CS 509 - WPI 35

Events and Messages

Event Class: an abstraction for a kind of event

Event: instance of an Event Class Can be a Message sent from one object to

another Other examples?

Message: Usually a request or notification Name and some arguments Corresponds to some operation

Jan. 26, 2004 CS 509 - WPI 36

Object-oriented Modeling

Used in both analysis and designAnalysis focuses on application domain

Represents aspects of the user’s environment

Helps developers understand the problem(s)Design focuses on solution domain

Richer space of all possible solutions Changes with technology

(Figure 2-12, page 42)

Jan. 26, 2004 CS 509 - WPI 37

Application Domain Solution DomainApplication Domain Model System Model

AircraftTrafficController

FlightPlan Airport

MapDisplay

FlightPlanDatabase

SummaryDisplay

TrafficControl

TrafficControl

Figure 2-12. The application domain model represents entities of the environment which are relevant to an air traffic control system (e.g., aircraft, traffic controllers). The system model represents entities that are part of the system (e.g., map display, flight plan database). In object-oriented analysis and design, the application domain model is also part of the system model. An example in this figure is the TrafficControl package that appears in both models.

Jan. 26, 2004 CS 509 - WPI 38

Falsification and Prototyping

Falsification: Process of identifying defects in the model

• Details missing or incorrectly represented• Model doesn’t correspond to reality

Prototype: Simulate some aspect of solution (often UI) Users may falsify prototype

Easier to demonstrate that a model is incorrect than to prove it is correct – why?

Jan. 26, 2004 CS 509 - WPI 39

UML Exercise – Diagrams

Vending Machine ProblemDiscussion: define problem

How would you model a vending machine?

What is the process of making a purchase?

Create Diagrams Which type of diagram Model some piece of problem Present to class

Jan. 26, 2004 CS 509 - WPI 40

Short Break

Review Functional SpecificationAssignment

Jan. 26, 2004 CS 509 - WPI 41

Questions?

Lecture on Chapter 2About FS AssignmentAnything else?

Jan. 26, 2004 CS 509 - WPI 42

Analysis

Chapter 5

Jan. 26, 2004 CS 509 - WPI 43

Purpose of Analysis

To better understand requirementsIdentify objects & types in the problem

domain May or may not be same objects in design of

solutionIdentify attributes & associationsModel interactions between objectsModel Nontrivial BehaviorModel Generalization Relationships

Jan. 26, 2004 CS 509 - WPI 44

Terminology & Activities

Entity, Boundary and Control ObjectsMapping Use Cases to ObjectsModeling Interactions among ObjectsAssociations, Aggregates & AttributesModeling State-Dependent BehaviorModeling Inheritance Relationships

Jan. 26, 2004 CS 509 - WPI 45

Identifying Object Types

Entity Object: Persistent information tracked by system E.g. Month, Day, Year

Boundary Object: Interactions between actors & system E.g. Button, Display

Control Object: Tasks performed by User, supported by

System E.g. ChangeDate

Jan. 26, 2004 CS 509 - WPI 46

Heuristics for Object Types

Entity objects: Box on page 181

Boundary objects: Box on page 183

Control objects: Box on page 184

Jan. 26, 2004 CS 509 - WPI 47

Mapping Use Cases to Objects

Sequence diagrams tie use cases to objects

Show how behavior in use case is distributed among participating objects

Model the sequence of interactions among objects to realize use case

Sequence diagrams are not appropriate for a non-technical audience (Why not?)

See example diagrams on pages 186-187

Jan. 26, 2004 CS 509 - WPI 48

Interactions Among Objects

CRC cards can also be used to model interactions among objects Class, Responsibilities, Collaborators,

Beck & Cunningham, 1989Each class is represented with an

index card Name of class, Responsibilities, Names of

other classes (dependencies)See examples on page 190

Jan. 26, 2004 CS 509 - WPI 49

Identifying Associations

Class diagrams describe interdependencies among classes

Associations depict relationships between 2 or more classes

Heuristics box on page 191Association examples on pages

190, 192

Jan. 26, 2004 CS 509 - WPI 50

Associations & MultiplicityTypes of associations:

one-to-one one-to-many many-to-many

Symbols used to represent multiplicity: 1 - may be assumed by default, 2 … n * - zero or more + - one or more ? - zero or one

Jan. 26, 2004 CS 509 - WPI 51

Identifying Aggregates

An Aggregate is a type of association: Whole-part relationship, denotes

containmentComposition Aggregation

Existence of parts depends on the wholeShared Aggregation

Whole and parts can exist independentlySee examples, bottom of page 192

Jan. 26, 2004 CS 509 - WPI 52

Identifying Attributes

Properties of individual objectsEach attribute should have:

name identifying it within an object description to remember what it’s for type defining legal values it can take

onHeuristics for identifying

attributes, p. 194

Jan. 26, 2004 CS 509 - WPI 53

State-Dependent Behavior

Statechart diagrams can be used to model behavior of a single object

Gives a different perspective when compared to Sequence diagrams

By focusing on states, can identify new behavior

Which objects require statecharts?

Jan. 26, 2004 CS 509 - WPI 54

Inheritance Relationships

Generalization relationships can be modeled using UML Class diagrams See Figure 5-18, page 196

Use when two or more classes share attributes and/or behavior

Organize concepts into hierarchies from most general to most specific

Eliminate redundancy

Jan. 26, 2004 CS 509 - WPI 55

Analysis Model

Is this a useful activity? Identifying object types – terminology,

concepts Constructing sequence & state-chart

diagrams Associations and generalizations

At what point does analysis apply to a software development project?

Is it required for this course?

Jan. 26, 2004 CS 509 - WPI 56

Analysis Exercise

Identifying Objects& Object Types

Jan. 26, 2004 CS 509 - WPI 57

File System Analysis

(From textbook, exercises #1-5, page 219)

File system with GUI – e.g., File Explorer

Activity: copy file from floppy to hard disk How is this accomplished?

Tasks: Identify objects & object types Identify associations, attributes,

generalizations

Jan. 26, 2004 CS 509 - WPI 58

Term Project Discussion

Use of tools: Rational Rose, ClearCase, etc.

Send soft copy of phase 1 by email If there’s time, I will consolidate

requirementsContinue with phase 2 for same tool(s)

as phase 1 Research technology – include feasibility

analysis Anyone want to change tool(s) at this point?

Can choose different piece for phase 3

Jan. 26, 2004 CS 509 - WPI 59

For Next Time

Read Chapter 3Project Communication