CS288 Object-Oriented Software Engineering Motivation and Introduction

1
CS288Object-Oriented Software EngineeringMotiva
tion and Introduction

• Bill Mitchell

2
Overview

• Outline of course
• Introduction to business development process

3
Outline of Course

• UML modelling concepts
• Use Case Diagrams
• Class Diagrams
• Interfaces
• Collaboration
• Interaction diagrams
• Statechart diagrams
• Component
• Deployment

4
Outline of Course

• Java OO topics
• Classes and inheritance
• Class members and methods
• Creating and destroying objects
• Class inheritance and hierarchy
• Java GUI with Swing
• Java Event Model
• Refactoring (modifying the model)
• Threads of control (parallel programming)

5
Introduction to business design process

• Purpose
• Introduction to complexity of real world methods
• Understand some of the social aspects of real
  software engineering
• Realize the need for good methodology in global
  enterprise environments

6
Enterprise Development Process
Technical Marketing Requirements
System Requirements
Customers
Technical Marketing
Feature Teams
High Level Designs
Component Requirements
Box Teams
Functional Requirements
Architecture Requirements
Integration Teams
Detailed Designs
Testing Teams
Standards
7
Customers

• Enterprises often deal with other corporations
  more than end users (if at all).
• Corporate Customersfocused on
• end user requirements
• Return On Investment (ROI).
• During development life cycle these customer
  requirements are frequently changed.
• Corporate customer requirements are often
  technical but informal and have side effects for
  much of the existing system

8
Customers
Interfaces
9
Technical Marketing

• Technical marketing work with customers to fully
  capture the normative functionality of the
  customer interface to the final product.
• Technical marketing describe requirements at high
  level, without concern for internal system
  requirements.
• Technical marketing requirements will form the
  basis of the contract with the customer.
• Technical marketing are sometimes isolated from
  engineering groups who develop and test the
  actual products.
• Technical marketing main value to the enterprise
  is to win and keep customers.

10
Technical Marketing
11
Feature Teams

• Feature teams develop functional requirements
  from technical marketing requirements.
• Functional requirements define high level
  functionality of features with respect to logical
  entities within the system.
• Functional requirements refine marketing
  requirements to a level where they refer to the
  existing system components.
• Functional requirements must explain interactions
  that modify the system behaviour.
• Feature teams are temporary groups that are
  disbanded once functional requirements are good
  enough for further refinement by other groups
  (e.g software teams).

12
Refinement Process
13
Telecoms Example (of dynamic behaviour)

• Network provider deploying 3G.
• Placing order for handsets.
• One of the many features included will be access
  to network Java game repository.

14
Initial Customer Requirements
15
Technical Requirements
Usage Scenariosdetermine functional
elementswithin the interface.
060012
Jed Sneed
Ph. Bk
Menu
Hold
Power
Java
Ack
B1
B2
B3
B4
B5
B6
16
Technical Marketing Scenarios
Customer Scenariobroken down intosequence of
atomicevents, which changeinterface
functionality.
Default ScreenDisplay
Ph. Bk
Menu
Hold
Power
Java
Ack
B1
B2
B3
B4
B5
B6
17
Technical Marketing Scenarios 2
Phone negotiatesdata channel with air interface
and downloads file. Note requirements do not
specify how this will be done.
Progress 18897Kb
Cancel
Power
Java
Ack
File download
B1
B2
B3
B4
B5
B6
18
Technical Marketing Scenarios 3
Download Failure!Memory Full
Normative failure can be of various kinds. Here
phone memory full.
Progress 18897Kb
Cancel
Cancel
Power
Java
Ack
Power
Java
Ack
Internal mem full error
B1
B2
B3
B1
B2
B3
B4
B5
B6
B4
B5
B6
19
Technical Marketing Scenarios 4
Normative failure due to network failure. Note
does not specify which type of network error. Is
this broken connection to server, or entire
network down? Does not specify which internal
process should be alerted.
Download Failure!Connection Lost
Progress 18897Kb
Cancel
Cancel
Power
Java
Ack
Power
Java
Ack
B1
B2
B3
B1
B2
B3
Network error
B4
B5
B6
B4
B5
B6
20
Technical Marketing Scenarios 5
Normative failure due to corrupt file.
Download Failure!Corrupt File
Progress 18897Kb
Cancel
Cancel
Power
Java
Ack
Power
Java
Ack
B1
B2
B3
B1
B2
B3
Corrupt file error
B4
B5
B6
B4
B5
B6
21
Technical Marketing Scenarios 6
Normative success. File is downloaded uncorrupted.
Progress 18897Kb
Game Loaded
Download 68495Kb
Cancel
Play
Menu
Power
Java
Ack
Power
Java
Ack
B1
B2
B3
B1
B2
B3
File download complete
B4
B5
B6
B4
B5
B6
22
Technical Marketing Scenarios

• Normative scenarios are very focused on isolated
  behaviour of feature in these requirements
• What if voice call received during download?
• What if other data call received during download?
• Are there other applications that should be able
  to override the download?
• If the phone has multi-threading operating
  system, should it be able to offer the user other
  services while the download occurs?3G systems
  have high bandwidth so this should be possible.
• If memory is expandable (as with some PIM-phone
  hybrids) how should the mem-full error be handled
  if the user could add extra memory with, say, a
  USB flash memory stick?
• What if during the download the network service
  provider tries to update the phone configuration
  via the air interface for enhanced game play?

23
Technical Marketing Scenarios
UI
Marketing Requirements
Functional Requirements
These omissions arise because the role of
technical marketing is to focus on customer
requirements, rather than functional
requirements. Customers are focussed on
generating revenue from each feature, and rarely
worry about the system as a whole.
24
Functional Requirements
UI
Functional Requirements

• Functional requirements refine technical
  marketing requirements to logical entities
  defined in terms of their functionality.
• They are defined independently from any
  architecture requirements that will constrain
  implementations.

25
Functional Requirements Scenarios

• The purpose of functional requirements is to be
  precise enough for detailed specifications to be
  written for any particular architecture that can
  then be implemented.
• They do not define every single aspect of the
  features behaviour.
• They define comprehensive behaviour of the
  feature so that it performs well for any common
  eventuality, and can fail gracefully in
  exceptional circumstance.
• Made up of functional scenarios and partially
  defined state based models.

State Based Model
26
MSC Example
A single user action in marketing scenariois
decomposed into multiple events
betweenconcurrent system components.
27
Software Engineering Methodology

• Modular(Can split tasks into self contained
  units that canbe worked on by different groups)
• Reusable(So can be incorporated into future
  releases of new products)
• Flexible(When requirements are in constant flux
  it is easier to modify system)
• Reliable(Less likely to introduce errors and
  easier to find errors)

28
Summary

• Course outline and structure
• Introduction to global enterprise engineering
  methods
• Realization of complexity of system design

• Next time
• UML class diagrams and language constructs