Object-Oriented Software Development

Goals of the Course Working

in teams Introduction to object-oriented development

Object-Oriented Software Development

Iterative and incremental development processes Object-oriented techniques Work product orientation

Introduction

to real-life project issues Usage of industrial-strength tools

Jürgen Börstler [email protected] http://www.cs.umu.se/~jubo

This is NO programming course We do not teach any (OO) programming We assume you have sufficient programming skills

http://www.cs.umu.se/kurser/TDBC31

OOSD

Literature

Copyright by [email protected]

2

Project Issues Teamwork

(5-7 students) Complete life-cycle coverage “Real” (external) customers Subcontractors Fuzzy and/or volatile requirements Many deliverables Several project presentations Formal team meetings Formal reporting routines

® Lecture overheads ® Various documents and

resources linked to course web page

OOSD


3

OOSD


4

Project Examples

Team Roles and Organisation Each

team has an (external) customer and a supervisor Î Customer supervisor

Games Simulations Editors Project planning Trouble Reporting System Video Manipulation ...

Each

team contracts another team for implementing a well-defined part of its project Î Formal subcontract Î Pairwise subcontracting is not allowed Each

See

team evaluates another team’s prototype Î Feedback for development of final product Î Pairwise evaluation is not allowed

course home page for current proposals

Proposals

will be presented in next lecture

OOSD


5

OOSD


Teamwork

Specialist Roles

Team

Team

members take on specialist roles (e.g. team manager, requirements specialist, …) All team members must engage (at least) in OOA&D (in addition to role specific responsibilities) Individual diaries for project tracking Regular (formal) meetings to co-ordinate work

Manager Requirements Specialist User Interface Specialist Design Specialist Code Production Specialist

Team internal Team managers with supervisors

6

Quality

Assurance Specialist Documentation Specialist Tools Specialist Webmaster ...

Î Please feel free to add further roles as needed

Î Team decisions must be followed by all team members

Î We recommend to have at least two individuals for each

Î All team members are finally responsible for the overall

role

project outcome OOSD


7

OOSD


8

Specialist Responsibilities

Team Building

Research

your job Identify your tasks and specific responsibilities Estimate the time to complete your tasks Monitor the completion of your tasks Track your effort (Ö diary) Inform team members about the status of your work Keep yourself informed about project progress Maintain a list of problems / items to discuss

Students fill in Personal data Skills Preferences

Î Be pro-active not re-active Keep yourself informed on what is going on in the project Show up in team meetings

OOPS!

OOSD


a questionnaire

Î Match and mix student skills and preferences to build

equal teams You

need convincing arguments to change teams

Some students will arrive late Î Teams should maintain “job openings” 9

OOSD


Effective Teamwork

Project Documentation

Create clear goals Î Understand each other’s expectations

Up-to-date,

web-based project workbook Weekly reports Individual diaries Deliverables with firm deadlines

Go for small wins Î Set attainable and concrete short term goals Build mutual trust Î Listen to each other Î Show respect Î Be fair and objective

Ensure mutual accountability Î No finger pointing Help

each other Copyright by [email protected]

Team description Project management Requirements document (G)UI design Analysis/Design document

OOPS!

See web resources for more information. OOSD

10

11

OOSD

Subcontract Prototype user manual Prototype evaluation Final report

Some deadlines might be negotiated Copyright by [email protected]

12

Presentations

Grading

Team

Individual

grades (U, 3, 4, 5) Teams accumulate credits Team credits are distributed among team members

presentation, project plan, requirements, GUI mock-up, iteration plan Project progress, OOA&D, prototype demonstration, revised iteration plan Project summary, product presentation and demonstration, reflections, planned vs. actual work All

50% evenly 50% as proposed by team

Individual In

presentations should include actual project data

number of credits determines grade

case of marginal problems/failure:

Extra time for teams to complete projects Extra assignments for individuals

Î See course web pages for details OOSD


13

OOSD


The Credit System

Course Evaluation

Each

Very

team starts with 0 credits For each “performance” a team earns credits (quality x importance) Quality on scale 0..6 Importance on scale 1..15

each deadline missed a team looses credits

See http:///Grading.html for details.

OOSD


positive, in particular in recent years

Criticism from earlier evaluations (pre 2002) Workload too high Too little calendar time Unclear grading system Too much focus on deliverables Lectures not synchronised with deliverables

For

14

15

OOSD


16

Major Changes Since 2002

Latest Changes

15

50%-rule

ECTS instead of 7.5 Several iterations (currently 3) Very detailed grading “rules” More formal progress reporting

for credit distribution Subcontracting within same course Contents

is continuously updated to reflect latest developments Only minor changes in organisation of topics, since students were quite satisfied

Team managers meet weekly with supervisors Explicit requirements for weekly reports Individual diaries

Subcontracting

with teams from another course Questionnaire to support team formation Peer evaluations for early team trouble-shooting Signature blocks required on deliverables New textbook and UML tool (VP-UML) OOSD


17

OOSD


Teams Must Take Initiative

Obligatory Attendance

Teams

Lectures:

are responsible for organising their work

Schedule

and organise meetings (with team, customer and supervisor) Contact customers to gather project information Keep all stakeholders informed about the project Learn about necessary methods/tools/environments …

18

At least 3 team members per team

Presentations: Your own team presents: All team members of your team must attend Another team presents: At least 3 team members of your team must attend (all, if 3 teams) Weekly

Management Meetings: At least 2 team members per team (typically the team managers)

Your

customers (and supervisors) are busy people Î Make appointments in good time OOSD


Work

Load: On average you are expected to work about 20h/week (about 15 person months per team)

19

OOSD


20

Tools: General

Tools: Recommendations

The

UML

usage of an approved UML tool is obligatory You can use other tools/languages/builders environments etc. as you like, if they seem appropriate for your team and/or project

You

get support only for the tools and environments we provide on our lab machines Problems due to the usage of “non-standard” tools/ environments are solely yours Make sure your projects do not depend on such tools/ environments Copyright by [email protected]

Team

collaboration

VP-UML

HOWEVER

OOSD

diagramming

21

(local license Shared workspaces for server) distributed teams (e.g. a wiki) Many free, but restricted, versions of commercial tools Misc Project workbook Project Management template MS Project Documentation from old courses Planner (Open Source) Version

control

CVS

OOSD


Contents


Introduction

What

is Object-Oriented Development An Object-Oriented Development Framework Phases, Activities, and Work Products Importance of Modelling Putting Everything Together

Object-Oriented

Software Development Project Management Requirements Gathering (G)UI Design Object-Oriented Analysis and Design Advanced Topics in OOA&D Implementation and Testing References

OOSD


22

23

OOSD


24

What is Object-Oriented Development

Changing Views

“Object-oriented software construction is the software development method which bases the architecture of any software system on modules deduced from the types of objects it manipulates (rather than the function or functions that the system is intended to ensure).” [Meyer 97]

A

Traditional view Î Operations and data are separate entities Î Data is globally visible

... A

func1(…) func2(…)

B

func3(…)

very brief history

C

...

1966: Object-oriented programming [Simula (Dahl and Nygaard)] 1982: Object-oriented design [with Ada (Booch)] 1988: Object-oriented analysis [OORA (Coad), OOSA (Shlaer and Mellor)]

1997: Unification of notations

1999: Unification of processes 2003: UML 2.0 [OMG]

OO view Î Operations + data = objects

[UML V1.0 (Booch, Jacobson, Rumbaugh)] [(R)UP (Kruchten, Rational)]

func2(…) …

func1(…) …

A

…

…

X C

…

…

func2(…) …

B

…

func3(…)

OOSD


25

OO Small Semantic Gap

OOSD


26

Important OO Concepts Object Encapsulation Message

Passing

Classes Inheritance

Semantic Gap Player

Polymorphism

and Dynamic Binding (Multiple Inheritance)

Field components

uses

Club

Hole hits

See for example [Booch 94] or [Meyer 97] for details.

falls into

Ball

OOSD

Border

rebounds


27

OOSD


28

OO Philosophy 1

OO Philosophy 2

OO

programs are systems of communicating objects Objects have an internal state, behaviour, and identity Classes are templates for the creation of objects of the same type Similarities can be expressed by inheritance Binding depends on the dynamic type of objects

User perception of the real world (Ö analysis model)

Interaction

User

Î Readability

Computing System

Î Extensibility Î Maintainability

Solution (Ö design model)

Problem Domain (“real world”)

OOSD


29

OOSD

Application Domain


Object-Oriented vs. Traditional Development


- Unified approach for analysis, design, and implementation - Concepts in problem domain and solution are closer, i.e. more “natural” - Promotes encapsulation, extensibility, and reuse

What

30


/ Fuzzy borderline between analysis, design, and implementation / More difficult to manage / More complex component interrelationships / Transition problems OOSD


31

OOSD


32

An Object-Oriented Development Framework

The Project Workbook

Work product oriented and workbook centred Focus on the production of work products Hold and manage them in a central depository

products of a project.”

A project workbook is a “logical document containing all the work A work product is a “concrete result of a planned project-related activity such as analysis or project management. Work products include items delivered to the customer and items used purely internally within a project.”

Iterative and incremental Divide the system into increments Evolve the system increment-wise Iteratively rework previous increments

[OOTC 97, p 25]

Scenario-driven Model externally visible system behaviour by scenarios/ use cases Enforce traceability through work products

OOSD


See http:///Workbook/wb_template.html for a project workbook template, or examples from former groups for actual examples. 33

OOSD


Iterative and Incremental Development 1


Waterfall model Strongly based on phases Stable documents “Easy” to manage

Pre-iteration phase

34

Gather initial requirements, plan project, start analysis

Iterations Planning, Analysis, Design, Coding, Testing, Assessment

Problems Incomplete/ volatile requirements Testing late No early prototypes

Ö Plan increment Ö Execute plan Ö Assess quality

[P | A | D | C | T | A] [P | A | D | C | T | A] [P | A | D | C | T | A]

Post-iteration phase Solution Develop a solution for growing subsets of requirements (Ö increments) Rework existing solutions (Ö iterations) OOSD


System test, package, and ship

35

OOSD


36


RUP

Requirements Increment 1 Increment 2 Increment 3

Iterations/ increments

[P | A | D | C | T | A] [P | A | D | C | T | A] [P | A | D | C | T | A]

Time

OOSD


37

Typical Increments Increment Purpose

OOSD

A scenario is a sequence of events or actions in a particular context.

Activities

1

Get project started

2

Familiarise team Start with a few Use Cases and develop all planned with process and work products for the Analysis, (G)UI, Design, and Implementation phases. environment

Scenario perspective

Traditional view

Concrete descriptions

Abstract descriptions

3..n-1

Complete project Taking a few Use Cases at a time, develop all work products for each phase through Implementation. development

Goal-based

Feature-based

Particular instances/context

General

Informal

Formal, rigorous

Open-ended, explorative

Complete

Fragmentary

Exhaustive

n

Package, test, and deliver the product

Develop all planned work products for the Requirements Gathering and Project management phases. Review Analysis work products with customers. Concurrently, analysts, designers, and implementers develop guidelines for their phases. Designers can also start the System Architecture, Target Environment, and Subsystem Model work products.

User-system

interaction to achieve a certain goal Envisioned or predicted system behavior …

Implement the Physical Packing Plan and conduct the Installation, System, and Acceptance test plans.


38

Scenario-Driven Development

As new work products are developed, old ones may need to be extended or amended.

OOSD


39

OOSD


40


Phases, Activities, and Work Products

What

“A development phase is a state of product development that focuses on making progress on a particular aspect or facet.”


OOSD


A work product is a “concrete result of a planned project-related activity such as analysis or project management. Work products include items delivered to the customer and items used purely internally within a project.” [OOTC 97]

41

Project Management

OOSD

OOSD


42

Requirements Gathering

Phases

Activities

Work Products

Project Management

After initial project planning, define development activities and allocate resources to the activities. Allocate requirements to releases and manage project schedule and issues.

Project Workbook Outline

An organized list of work products that are expected to comprise the project workbook.

Resource Plan

Analysis of the resources required for the successful completion of the project.

Schedule

A task time line showing dates, milestones, critical path, etc.

Risk/Option Management Plan

Lists development options and describes the plan for minimizing project risks.

Test Plan

Outlines the project’s plan for testing the application.

Issues

A list of outstanding issues, questions, and concerns that are reviewed on a regular basis.

Metrics

The planned and actual measurements, and statistics.


Phases

Activities

Work Products

Requirements Group functional requirements (into use Gathering cases) and prioritize them.

43

OOSD

Problem Statement

Description of the problem to be solved in non-technical terms.

Use Cases (functional requirements)

An OO formalization of functional requirements describing the usage of the system by external agents.

Nonfunctional Requirements

Requirements that do not belong to user function, such as performance, platform, quality.

Prioritized Requirements

Defines the relative priorities of functional and nonfunctional system requirements.


44

UI Design

OOA&D

Phases

Activities

Work Products

UI Design

Document how users will interact with the application.

Guidelines

Describes the user interface guidelines and standards.

Screen Flows

Documents user navigation through the application’s user interface.

Screen Layouts

Documents details of all screens.

UI Prototype

A prototype built to show users the ”look and feel.”

OOSD


45

Implementation & Testing Phases

Activities

Work Products

Implementation

Systematically code the classes as specified in the class descriptions so that they can be built and installed on the target platforms.

Coding Guidelines

A description of the coding guidelines and standards.

Source Code

The actual implementation of the product.

User Support Materials

Documentation, delivered in various forms, which support the customer’s use of the product.

Prototypes

Intermediate products.

Test Cases

The testing and quality assurance work products.

Testing

OOSD

Insure that the application meets the requirements set forth in the problem statement and requirements gathering work products.


Phases

Activities

Work Products

ObjectOriented Analysis & Design

Analysis: Identify objects, their attributes, behaviors, and interrelationships. Develop solutions to system usage scenarios in terms of active objects that group related tasks and communicate with other objects in order to complete them.

Guidelines

Records the details of the analysis and design approach being followed.

System Architecture

Description of the high-level components/ structures of the system and the design principles guiding the implementation.

Object Model

A consolidated model describing the classes of a system together with their responsibilities and static interrelationships.

Scenarios

Descriptions of required systems behaviour. Scenarios refine use cases and are formalized in OIDs.

Design: Plan a solution to the problem examined during analysis in terms of interacting objects, within the constraints specified by the nonfunctional requirements.

OIDs (Object Interaction Diagrams)

A working out of a scenario, showing the interactions between objects to accomplish (the implementation of) a task.

State Models

Show the life cycle of an object, i.e. its possible states and state transitions.

Classes

Detailed descriptions of all classes.

File Structure

The files and their structure as required by the system.

Traceability Matrix

A cross-reference table that relates design elements to requirements.

OOSD


46

Miscellaneous Work Products Phases

Activities

Work Products

Miscellaneous Document miscellaneous activities in appendices and add them to the project workbook.

47

OOSD

Glossary

Definitions and terminology.

Back-level work products. Historical Work Products

Meeting Minutes

The minutes of all project meetings.

Time Logs

The time logs of the people allocated to the project.

...

...


48

Course Related Work Products

Work Product Definition

Phases

Activities

Work Products

Course organization

Document course specific aspects and support course organization.

Team Description

A presentation of your team and the members of the team.

Subcontract

A contract with an external team to deliver a specified piece of software.

Prototype Evaluation

An evaluation of another team’s prototype.

Weekly Reports

Progress reports with up-to-date project information and (summaries of) the individual diaries.

Presentations

Materials from the team presentations.

Final Report

A complete document set.

OOSD


Defined in detail Description Purpose Participants Timing Techniques Strengths Weaknesses

in [OOTC]:

Notation Traceability Advice & Guidance Verification Examples References Importance

See http:///Deliverables.html for a detailed description of the course’s deliverables and http://forc.darkeye.net for an example from a previous course. 49

OOSD



Modelling and Software Development

What

Models make use of Abstraction Separation of concerns Familiar and natural concepts


OOSD


50

Models are tools to Understand a problem Cope with complexity Simplify problem solving Enable traceability

51

OOSD


52

Examples of Models In

Models Support Traceability

the real world Real world

Maps Physical models Darwin’s origin of species …

In

X

-

Programming languages Turing machines Graphs (for various purposes) …

Y

Development

the computing sciences

Software system

/

Model X

-

Y

Î Choose the right model for the right purpose OOSD


53

Models in (OO) Software Development

OOSD


54

Use Cases and Scenarios

Use

cases Scenarios Class diagrams Object interaction diagrams State machines Formal software specifications ...

OOSD


Register for courses Student

Use case X: Register for courses Description: This use case is initiated by the student. It provides the capability to create, review, modify, and delete a course schedule for a specialized semester. All required billing information is sent to the Billing System. Actors: Student, Billing System. Notes: A student can register for at most 4 courses each semester. 55

OOSD

Main success scenario: 1. The student identifies himself/ herself. 2. The system verifies student identity. 3. The student selects a valid semester. 4. The student creates, reviews, or changes a schedule. 5. The systems prints a notification. 6. The system sends billing information to the Billing System.


56

An Object Interaction Diagram

A Class Diagram Registrar registerStudent() addCourse()

Student credits

add a course

Professor

Course Maintenance Form

:Registrar

research_area

tdbc18: Course

1: enter id 2: verify id

time

3: create course 4: enter course info 5: submit 6: create

Person

{abstract}

7: save 8: close form

name p_number

OOSD


57


OOSD

58


Putting Everything Together

What



Problem Statement

??? Class Descriptions

Object-Oriented Analysis & Design

Coding

Code

Test Case Development

Implementation OOSD


59

OOSD

Test Cases

Testing Copyright by [email protected]

60

Putting Everything Together Requirements Gathering

Problem Statement

Putting Everything Together

Use Case Development


Problem Statement

Use Case Model

Use Case Model


Elaboration

State Models

???

Object Model

State Abstraction se ani Org n tio ic a s if s a Cl

Object Interaction Diagrams

Traceability

Test Case Development (black-box)

Consolidation

Class Descriptions

Class Descriptions



Coding

Coding

Code

Test Case Development

Implementation OOSD

Test Cases

Code

Testing

Implementation 61


Work-Product Dependencies Requirements Gathering

Problem Statement

OOSD

Test Case Development (white-box)

Test Cases

Testing 62


OO Development Processes More or less all modern processes are incremental, iterative, and scenario-based

Use Case Model


Linguistic Analysis

Elaboration

State Models Object Model

State Abstraction se ani Org n tio ca ifi s as Cl

Object Interaction Diagrams

Scenarios

light-weight flexible

Assignment of Responsibilities

heavy-weight plan based

Test Case Development (black-box)

Consolidation

Class Descriptions

Scenarios Assignment of Responsibilities


Coding

Code

Implementation OOSD

Test Case Development (white-box)


Test Cases

Testing 63

OOSD


64

The Agile Manifesto

Agile vs. Traditional

Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan

Agile

Traditional

High

Requirements volatility

Low

Low/medium

Criticality of application

Medium/high

High

Project risk level

Low

High

Volatility of context/environment

Low

High

Overall team expertise

Low

Low

Staff turnover

High

Low

Process overhead

High

That is, while there is value in the items on the right, we value the items on the left more.

See http://www.agilealliance.com/

for more details (e.g., principles). OOSD


65

References [Abbot 83] [BiSp 03] [Booch 94] [BrDu 04] [BRJ 99] [CMRR 94] [Gold 04] [Jacob 97] [Meyer 97] [OOTC 97] [SHE 89] [Wiegers 03] OOSD

R.J. Abbot, Program Design by Informal English Descriptions, Communications of the ACM 26 (11), Nov 1983, 882-894. K. Bittner, I. Spence, Use Case Modeling, Addison-Wesley, 2003. G. Booch, Object-Oriented Analysis and Design, Benjamin/ Cummings, 1994. B. Bruegge, A.H. Dutoit, Object-Oriented Software Engineering, Using UML, Patterns, and Java, Prentice Hall, 2004. G. Booch, J. Rumbaugh, I. Jacobson, The Unified Modeling Language User Guide, Addison-Wesley, 1999. J.M. Carrol, R.L. Mack, P. Robertson, M.B. Rosson, Binding Objects to Scenarios of Use, Journal of Human-Computer Studies 41, 1994, 243-276. R.F. Goldsmith, Discovering REAL Business Requirements for Software Project Success, Artech House, 2004. I. Jacobson, The Object Advantage, Addison-Wesley, 1997. B. Meyer, Object-Oriented Software Construction, Prentice Hall, 1997. D. Livesey, T. Guinane (IBM’s OOTC), Developing Object-Oriented Software, Prentice Hall, 1997. M. Saeki, H. Horai, H. Enomoto, Software Development Process from Natural Language Specification, Proceedings ICSE-11, Pittsburgh, PE, USA, Mar 1989, 64-73. K.E. Wiegers, Software Requirements, 2nd Ed., Microsoft Press 2003. Copyright by [email protected]

67

OOSD


66

Object-Oriented Software Development

Object-Oriented Software Development

Suggest Documents

Testing ObjectOriented Software

[PDF] Download ObjectOriented Software Full Books.pdf - Google Drive

Postmodern Software Development - CiteSeerX

Agile Software Development - SNIP

development of software

SOFTWARE TEST PROCESS DEVELOPMENT

Model Driven Software Development

3 Agile Software Development

Multicore Software Development Kit

UNDERSTANDING SOFTWARE DEVELOPMENT TEAM ...

Software Development by Refinement

ACS software tool development

Software Development Fundamentals

DEVELOPMENT OF SOFTWARE

DEVELOPMENT OF SOFTWARE

Collaborative Software Development

Agile Software Development

Rugged Software Development

Collaborative Software Development - CiteSeerX

Secure Software Development

ARM Software Development Toolkit

Crowdsourcing Software Development: Task

Software Development Roles - CORE

Software development - CiteSeerX