Groups

Paul Simmerlink Jigna J. Bhatt Don Miller

Stephen Herbert Casey J. Powell James Frye
Daniel Coming Brett Harrison David Brewer
Ogechi Ugwulebo Jonathan Ward Olja Mihic
James King Michael Vidal Casey Mees
Maggie Lu Howard C. Wu Jason Dodd
Reid Webber Shana Rheault Beifang Yi
Taisuke Nagayama RichardD.VanHorn Dorothy P. Cheung
Jeff Payne Rodel Mangoba William Nelson
Matasaka Sako Steve Luong Will Woolsey
Andrew Rodgers

James Cohen, Judy Rowley, Stan Sexton, Rajashekhar Yakkali,

Kazuhito Mori

Computer Science Software Engineering Slide 1

Project Management tools

See the projects web page


Concurrent Versions System (CVS)


Coding standards
• Java coding standard document

Computer Science Software Engineering Slide 2

What have we learned so far?

Murphy's Technology Laws
1. Logic is a systematic method of coming to the wrong
conclusion with confidence.
2. Whenever a system becomes completely defined, some
damn fool discovers something which either abolishes the
system or expands it beyond recognition.
3. Nothing ever gets built on schedule or within budget.
4. All's well that ends.
5. Any given program, when running, is obsolete.
6. To spot the expert, pick the one who predicts the job will
take the longest and cost the most.

Computer Science Software Engineering Slide 3

What have we learned so far?

The first step in software development is
understanding the system to be developed

This is requirements analysis

Requirements analysis starts with a description of
the system

The description is refined into a requirements
document

Computer Science Software Engineering Slide 4

Requirements document

Interaction between engineering, marketing and
clients (domain experts)

Iterative

Increase understanding of system
• Informal scenarios help understanding and appreciation of
system complexity
• Raise questions that need to be answered by domain experts
• Propose GUI/UI (more on GUI design later)

Requirements document (formatted formal
document)

Computer Science Software Engineering Slide 5

Do you understand system?

Validate your understanding

Use Case Centered Design (UCCD)
• Scenarios
• Comprehensive, explore all interaction with system
• UML class diagrams
• Initial design
• List of primary classes (nouns, properties of primary classes)
• UML use-case diagrams
• Compact representation of use of system

Computer Science Software Engineering Slide 6

Next?

Troutman's Laws of Computer Programming
1. Any running program is obsolete.
2. Any planned program costs more and takes longer.
3. Any useful program will have to be changed.
4. Any useless program will have to be documented.
5. The size of a program expands to fill all available memory.
6. The complexity of a program grows until it exceeds the capability of its
maintainers.
7. Any system that relies on computer reliability is unreliable.
8. Any system that relies on human reliability is unreliable.
9. Make it possible for programmers to write programs in English, and you
will find that programmers cannot write in English.
10. Profanity is the one language all programmers know best.

Computer Science Software Engineering Slide 7

Next

Persistence?

Inter-process communication?

HCI

Architecture
• Grouping primary classes
• Interfaces

Design

Implementation

Validation

Computer Science Software Engineering Slide 8

Persistence

LMS

Galaxy sleuth

GPA

Computer Science Software Engineering Slide 9

Object Persistence

Object persistence seeks to retain object
information on some persistent storage medium as
a file or through a DBMS

Object serialization works for situations where all
object information can reside in memory at once

Because most commercial DBMSs are relational
in contrast to object-oriented, some translation
between the object and relational representations
must be made

Computer Science Software Engineering Slide 10

Evaluating Object Persistence

Security
• Hacker proof
• Allows reconstruction in face of malicious use

Information growth
• Solution still works with increased data volume

Concurrency
• Concurrency solution allows for increased users

Computer Science Software Engineering Slide 11

LMS: Object Persistence

LMS may contain hundreds of thousands of book
entries as well as thousands of other library
resources

such a volume of data does not permit object
streaming

A DBMS is called for to provide
• Concurrent access by multiple users
• Security enforcement of different access levels for various user
categories
• Allow for increased data capacity

Computer Science Software Engineering Slide 12

What do we want to persist?

System state
• ?

Computer Science Software Engineering Slide 13

LMS Case Study: Relational
Representation of Data

Book Relational Tables

Resource List

Patron
Address
Patron

Computer Science Software Engineering Slide 14

Process Architecture

Software systems may consistent of processes
interacting over a network

Process architecture lays out the machines (nodes)
that will host the processes making up the system

Process architecture determines the behavior of
the distributed processes

Deployment diagrams are used to model
distributed processes

Computer Science Software Engineering Slide 15

Sample Deployment Diagram

Game Game
Client Internet Server

Game
Client
Game
Client

Computer Science Software Engineering Slide 16

Modeling Interprocess
Communication

Deployment diagrams show the distribution of
process over multiple nodes but do not indicate
how these processes communicate

State machines may be used to model
communication between processes

The idea behind using state machines for
modeling interprocess communication is that the
system enters a new state when messages are
exchanged between processes

Computer Science Software Engineering Slide 17

UML Notation for State
Machines
State with substates
Initial State
State Name
Final State

State Name Intermediate State

Trigger State transition

with event trigger

Computer Science Software Engineering Slide 18

 Sample State Machine Showing
Interprocess Communication

Player Joining Game { Server State}

Communicate
remaining tokens
player name
available
tokens selected
token
Get player Select token
name

{ Client States}

Computer Science Software Engineering Slide 19

Modeling Multiple Threads of
Control

Classes that consist of a separate thread of control
are modeled as active classes

Active classes are rendered with thick rectangles
as shown below

Regular class Active class

Computer Science Software Engineering Slide 20

Galaxy Sleuth

galaxySleuthServer

gameBoard

playerListener

Computer Science Software Engineering Slide 21

Design Summary

Create solution for object persistence

Develop user interface designs

Determine process architecture

Computer Science Software Engineering Slide 22

Possible Obstacles to Effective
Meetings

Poor agendas

Dysfunctional communication during the meeting
(silence or domination)

Not adhering to the agenda

Discussion may not sufficiently focus on meeting
objectives specified by the agenda

Team members are not listening to each other
during discussion

Computer Science Software Engineering Slide 23