Groups

1
Groups
Paul Simmerlink Stephen Herbert Daniel Coming Ogechi Ugwulebo James King Jigna J. Bhatt Casey J. Powell Brett Harrison Jonathan Ward Michael Vidal Don Miller James Frye David Brewer Olja Mihic Casey Mees
Maggie Lu Reid Webber Taisuke Nagayama Jeff Payne Matasaka Sako Howard C. Wu Shana Rheault RichardD.VanHorn Rodel Mangoba Steve Luong Jason Dodd Beifang Yi Dorothy P. Cheung William Nelson Will Woolsey Andrew Rodgers
James Cohen, Judy Rowley, Stan Sexton, Rajashekhar Yakkali, Kazuhito Mori James Cohen, Judy Rowley, Stan Sexton, Rajashekhar Yakkali, Kazuhito Mori James Cohen, Judy Rowley, Stan Sexton, Rajashekhar Yakkali, Kazuhito Mori
2
Project Management tools

• See the projects web page
• Concurrent Versions System (CVS)
• Coding standards
• Java coding standard document

3
What have we learned so far?

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

4
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

5
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)

6
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

7
Next?

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

8
Next

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

9
Persistence

• LMS
• Galaxy sleuth
• GPA

10
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

11
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

12
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

13
What do we want to persist?

• System state
• ?

14
LMS Case Study Relational Representation of Data
Relational Tables
Book
Resource List
Patron Address
Patron
15
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

16
Sample Deployment Diagram
GameServer
GameClient
Internet
GameClient
GameClient
17
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

18
UML Notation for State Machines
State with substates
Initial State
State Name
Final State
State Name
Intermediate State
Trigger
State transition with event trigger
19
Sample State Machine Showing Interprocess
Communication
Server State
Player Joining Game
Communicate remaining tokens
player name
available tokens
selected token
Get player name
Select token
Client States
20
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

Active class
Regular class
21
Galaxy Sleuth

• galaxySleuthServer
• gameBoard
• playerListener

22
Design Summary

• Create solution for object persistence
• Develop user interface designs
• Determine process architecture

23
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