Object-Oriented Software Development - CiteSeerX
-
Upload
khangminh22 -
Category
Documents
-
view
5 -
download
0
Transcript of Object-Oriented Software Development - CiteSeerX
Object-Oriented Software Development
Jürgen Bö[email protected]://www.cs.umu.se/~jubo
http://www.cs.umu.se/kurser/TDBC31
OOSD--fall'04 Copyright © by [email protected] 2
Goals of the Course
Working in teamsIntroduction to object-oriented development
Iterative and incremental development processesObject-oriented techniquesWork product orientation
Introduction to real-life project issuesUsage of industrial-strength tools
This is NO programming courseWe do not teach any (OO) programmingWe assume you have sufficient programming skills
OOSD--fall'04 Copyright © by [email protected] 3
Project Issues
Teamwork (5-7 students)Complete life-cycle coverage“Real” customersSubcontractorsFuzzy and/or volatile requirementsMany deliverablesSeveral project presentationsFormal team meetingsFormal reporting routines
OOSD--fall'04 Copyright © by [email protected] 4
Project Examples
GamesSimulationsEditorsProject planningTrouble Reporting SystemVideo Manipulation...
See course home page for current proposals
Proposals will be presented in next lecture
OOSD--fall'04 Copyright © by [email protected] 5
Team Roles and Organisation
Each team has an (external) customer and a supervisorCustomer ≠ supervisor
Each team acts as a customer for an externally produced part of the systemFormal subcontract
Each team evaluates another team’s prototypeFeedback for development of final product
OOSD--fall'04 Copyright © by [email protected] 6
Teamwork
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 trackingRegular (formal) meetings to co-ordinate work
Team internalTeam managers with supervisors
Team decisions must be followed by all team membersAll team members are finally responsible for the overall project outcome
OOSD--fall'04 Copyright © by [email protected] 7
Specialist Roles
Team ManagerRequirements SpecialistUser Interface SpecialistDesign SpecialistCode Production Specialist
Quality Assurance SpecialistDocumentation SpecialistTools SpecialistWebmaster...
Please feel free to add further roles as neededWe recommend to have at least two individuals for each role
OOSD--fall'04 Copyright © by [email protected] 8
Specialist ResponsibilitiesResearch your jobIdentify your tasks and specific responsibilitiesEstimate the time to complete your tasksMonitor the completion of your tasksTrack your effort ( diary)Inform team members about the status of your workKeep yourself informed about project progressMaintain a list of problems / items to discuss
Be pro-active not re-activeKeep yourself informed on what is going on in the projectShow up in team meetings
OOSD--fall'04 Copyright © by [email protected] 9
Team Building
Students fill in a questionnairePersonal dataSkillsPreferences
Match and mix student skills and preferences to build equal teams
You need convincing arguments to change teams
OOPS! Some students will arrive lateTeams should maintain “job openings”
OOSD--fall'04 Copyright © by [email protected] 10
Effective Teamwork
Create clear goalsUnderstand each other’s expectations
Go for small winsSet attainable and concrete short term goals
Build mutual trustListen to each otherShow respectBe fair and objective
Ensure mutual accountabilityNo finger pointing
Help each otherSee web resources for more information.
OOSD--fall'04 Copyright © by [email protected] 11
Up-to-date, web-based project workbookWeekly reportsIndividual diariesDeliverables with firm deadlines
OOPS! Some deadlines might be negotiated
Project Documentation
Team descriptionProject managementRequirements document(G)UI designAnalysis/Design document
SubcontractPrototype user manualPrototype evaluationFinal report
OOSD--fall'04 Copyright © by [email protected] 12
Presentations
Team presentation, project plan, requirements, GUI mock-up, iteration planProject progress, OOA&D, prototype demonstration, revised iteration planProject summary, product presentation and demonstration, reflections, planned vs. actual work
All presentations should include actual project data
See course web pages for details
OOSD--fall'04 Copyright © by [email protected] 13
Grading
Individual grades (U, 3, 4, 5)Credit system:
Each team starts with 0 creditsFor each “performance” a team earns credits (quality x importance)
Quality on scale 0..6Importance on scale 1..15
For each deadline missed a team looses creditsCredits earned (adjusted by #team members) can be “freely” distributed among the team membersGrade is determined by the final number of credits
In case of problems/failure:Extra time for teams to complete projectsExtra assignments for individuals
OOSD--fall'04 Copyright © by [email protected] 14
Course Evolution 1
Criticism from earlier evaluationsWorkload too highToo little calendar timeUnclear grading systemToo much focus on deliverablesLectures not synchronised with deliverables
Major revision done for ht0210 credits instead of 5Two project iterationsSubcontracts are implemented by PVK teamsInternet university course
OOSD--fall'04 Copyright © by [email protected] 15
Course Evolution 2
Changes/improvements for ht02/03Product quality is evaluated and graded (twice)Lectures better synchronised with deliverablesMore detailed grading “rules”Revised descriptions of presentation and deliverablesReorganised web pagesMore formal individual diariesMore formal handling of change requests
Only small changes in contents since ht01, since students were quite satisfied
OOSD--fall'04 Copyright © by [email protected] 16
Course Evolution 3
Changes/improvements for ht04Three types of “products” (GUI mock-up, proof-of-concept prototype, fully functional product)More formal weekly reporting
Team managers meet weekly with supervisorsMore detailed description of weekly reports
Revised descriptions of deliverables and grading “rules”Student to team allocation no longer completely voluntaryPeer evaluations to enable early team trouble-shootingIntroduced signature blocks on deliverables
OOSD--fall'04 Copyright © by [email protected] 17
Organisational Details
Not all team activities are scheduled
Teams have to take initiativeOrganise internal team meetingsContact customers to gather project informationKeep all stakeholders informed about the projectLearn about necessary methods/tools/environmentsMake appointments with supervisors…
Your customers (and supervisors) are busy peopleMake appointments in good time
OOSD--fall'04 Copyright © by [email protected] 18
Obligatory Attendance
Lectures: At least 2 team members per team
Presentations:Your own team presents: All team members of your team must attendAnother team presents: At least 3 team members of your team must attend
Weekly Management Meetings: At least one team member per team (typically the team managers)
Work Load: On average you are expected to work about 20h/week (about 15 person months per team)
OOSD--fall'04 Copyright © by [email protected] 19
Tools--General
The usage of an approved UML tool is obligatoryYou can use other tools/languages/builders environments etc. as you like, if they seem appropriate for your team and/or project
HOWEVERYou 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 yoursMake sure your projects do not depend on such tools/ environments
OOSD--fall'04 Copyright © by [email protected] 20
Tools--RecommendationsUML diagramming
Together Control CenterVP-UMLThere are free versions of both for download
Team collaborationShared workspaces for distributed teamsSwiki.netBSCW (Basic Support for Cooperative Work)
Project ManagementMS Project(MrProject)
Version controlCVS
MiscProject workbook templateDocumentation from old courses
OOSD--fall'04 Copyright © by [email protected] 21
Contents
IntroductionObject-Oriented Software DevelopmentProject ManagementRequirements Gathering(G)UI DesignObject-Oriented Analysis and DesignAdvanced Topics in OOA&DImplementation and TestingReferences
OOSD--fall'04 Copyright © by [email protected] 22
Object-Oriented Software Development
What is Object-Oriented DevelopmentObject-Oriented vs. Traditional DevelopmentAn Object-Oriented Development FrameworkPhases, Activities, and Work Products
OOSD--fall'04 Copyright © by [email protected] 23
What is Object-Oriented Development “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 very brief history 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 [UML V1.0 (Booch, Jacobson, Rumbaugh)]
1999: Unification of processes [RUP (Kruchten, Rational)]
2003: UML 2.0 [OMG]
OOSD--fall'04 Copyright © by [email protected] 24
func1(…)
Changing Views
Traditional viewOperations and data are separate entitiesData is globally visible
OO viewOperations + data = objects
func2(…)
func3(…)
...
A
B
C
...
A
func1(…) B
func2(…)
C
func2(…)
func3(…)
…
… …
…
…
…
……X
OOSD--fall'04 Copyright © by [email protected] 25
OO and the Semantic Gap
Hole
Ball
Club Border
Player Field
falls intohits
uses
rebounds
components
Semantic Gap
OOSD--fall'04 Copyright © by [email protected] 26
Important OO Concepts
ObjectEncapsulationMessage PassingClassesInheritancePolymorphism and Dynamic Binding(Multiple Inheritance)
See for example [Booch 94] or [Meyer 97] for details.
OOSD--fall'04 Copyright © by [email protected] 27
OO PhilosophyOO programs are systems of communicating objectsObjects have an internal state, behaviour, and identityClasses are templates for the creation of objects of the same typeSimilarities can be expressed by inheritanceBinding depends on the dynamic type of objects
ReadabilityExtensibilityMaintainability
OOSD--fall'04 Copyright © by [email protected] 28
The Context of (Object-Oriented) Development
Computing System
Problem Domain(“real world”)
Application Domain
User
Interaction
Solution( design model)
User perceptionof the real world
( analysis model)
OOSD--fall'04 Copyright © by [email protected] 29
Object-Oriented vs. Traditional Development☺Unified approach for analysis, design, and
implementation☺ Concepts in problem domain and solution are closer☺More “natural” concepts☺ Promotes encapsulation, extensibility, and reuse
Fuzzy borderline between analysis, design, and implementationMore difficult to manageMore complex component interrelationships
Transition problems
OOSD--fall'04 Copyright © by [email protected] 30
Object-Oriented Software Development
What is Object-Oriented DevelopmentObject-Oriented vs. Traditional DevelopmentAn Object-Oriented Development FrameworkPhases, Activities, and Work Products
OOSD--fall'04 Copyright © by [email protected] 31
An Object-Oriented Development Framework
Work product oriented and workbook centredFocus on the production of work productsHold and manage them in a central depository
Iterative and incrementalDivide the system into incrementsEvolve the system increment-wiseIteratively rework previous increments
Scenario-drivenModel externally visible system behaviour by scenarios/ use casesEnforce traceability through work products
OOSD--fall'04 Copyright © by [email protected] 32
The Project Workbook
A project workbook is a “logical document containing all the work products of a project.”
[OOTC 97, p 25]
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.”
Seehttp://<course homepage>/Workbook/wb_template.html
for a project workbook template, orexamples from former groups
for actual examples.
OOSD--fall'04 Copyright © by [email protected] 33
Iterative and Incremental Development 1
Waterfall modelStrongly based on phasesStable documentsNo feedback/ rework
ProblemsIncomplete requirementsRework is necessaryNo early prototypes
SolutionDevelop a solution for growing subsets of requirements (increments)Rework existing solutions ( iterations)
OOSD--fall'04 Copyright © by [email protected] 34
Pre-iteration phaseGather initial requirements, plan project, start analysis
IterationsPlanning, Analysis, Design, Coding, Testing, Assessment
Plan incrementExecute planAssess quality
Post-iteration phaseSystem test, package, and ship
Iterative and Incremental Development 2
[P | A | D | C | T | A][P | A | D | C | T | A][P | A | D | C | T | A]
OOSD--fall'04 Copyright © by [email protected] 35
Iterative and Incremental Development 3
Requirements
[P | A | D | C | T | A]
[P | A | D | C | T | A]
[P | A | D | C | T | A]
Time
Iterations/increments
Increment 1Increment 2Increment 3
OOSD--fall'04 Copyright © by [email protected] 36
Typical Increments
Increment Purpose Activities
1 Get project started
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.
2 Familiarise team with process and environment
Start with a few Use Cases and develop all planned work products for the Analysis, (G)UI, Design, and Implementation phases.
3..n-1 Complete project development
Taking a few Use Cases at a time, develop all work products for each phase through Implementation. As new work products are developed, old ones may need to be extended or amended.
n Package, test, and deliver the product
Implement the Physical Packing Plan and conduct the Installation, System, and Acceptance test plans.
OOSD--fall'04 Copyright © by [email protected] 37
Modelling and Software Development
Models make use ofAbstractionSeparation of concernsFamiliar and natural concepts
Models are tools toUnderstand a problem Cope with complexitySimplify problem solvingEnable traceability
OOSD--fall'04 Copyright © by [email protected] 38
Models Support Traceability
Real world Software system
Development
Model
X Y
X Y
☺ ☺
OOSD--fall'04 Copyright © by [email protected] 39
Examples of Models
In the real worldMapsFloor plansDiagrams…
In the computing sciences(Programming) Languages(Database) Conceptual modelsGraphs (for various purposes)…
Choose the right model for the right purpose
OOSD--fall'04 Copyright © by [email protected] 40
Models for (OO) Software Development
Use casesScenariosClass diagramsObject interaction diagramsState machinesFormal software specifications...
OOSD--fall'04 Copyright © by [email protected] 41
A Use Case for aCourse Registration System
Register for coursesDescription:This use case is initiated by the student. Itprovides the capability to create, review, modify,and delete a course schedule for a specializedsemester. All required billing information is sentto the Billing System.Actors:Student, Billing System.Notes:A student can register for at most 4 courses eachsemester....
OOSD--fall'04 Copyright © by [email protected] 42
A Use Case (cont.)
Register for coursesMain Flow of Events:1. The student enters the student ID number.2. The system verifies the ID number.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.
OOSD--fall'04 Copyright © by [email protected] 43
A Class Diagram
Person{abstract}
Studentcredits
Professor
namep_number
RegistrarregisterStudent()addCourse()
research_area
OOSD--fall'04 Copyright © by [email protected] 44
An Object Interaction Diagram
:RegistrarCourse Maintenance
Form tdbc18: Course
1: enter id2: verify id
3: create course
4: enter course info
5: submit6: create
7: save8: close form
time
add acourse
OOSD--fall'04 Copyright © by [email protected] 45
Coding
Test Case Development
ProblemStatement
Code Test Cases
ClassDescriptions
Requirements Gathering
Object-Oriented Analysis & Design
Implementation Testing
OO Development
???
OOSD--fall'04 Copyright © by [email protected] 46
Coding
Test Case Development
ProblemStatement
Code Test Cases
ClassDescriptions
Requirements Gathering
Object-Oriented Analysis & Design
Implementation Testing
Use Case Based OO Development
Use Case DevelopmentUse Case
Model
???
OOSD--fall'04 Copyright © by [email protected] 47
Coding
Elaboration
Assignmentof ResponsibilitiesOrganise
StateAbstraction
Consolidation
Test Case Development (white-box)
ProblemStatement
State Models
Code
Object Model
Test Cases
ClassDescriptions
Scenarios
Use CaseModel
ObjectInteraction Diagrams
Requirements Gathering
Object-Oriented Analysis & Design
Implementation Testing
Test CaseDevelopment
(black-box)
Scenario-Driven Development
Classifi
cation
Use Case Development
Traceability
OOSD--fall'04 Copyright © by [email protected] 48
Coding
Elaboration
Assignmentof ResponsibilitiesOrganise
StateAbstraction
Consolidation
Test Case Development (white-box)
LinguisticAnalysis
ProblemStatement
State Models
Code
Object Model
Test Cases
ClassDescriptions
Scenarios
Use CaseModel
ObjectInteraction Diagrams
Requirements Gathering
Object-Oriented Analysis & Design
Implementation Testing
Test CaseDevelopment
(black-box)
Work-Product Dependencies
Use Case Development
Classifi
cation
OOSD--fall'04 Copyright © by [email protected] 49
The Overall Development Process
Requirements Gathering
UI Design
ImplementationPro
ject
Man
agem
ent
OOA&D
(System) Testing
(Re-)Planning
Initial Planning
feedback
harvest
adapt
Rep
osit
ory
(Wor
kboo
k)
QA
iterative and incremental development