Object Oriented Software Construction
Prof. Armin B. Cremers, Daniel Speicher, Tobias Rho
Tutors: Jan Nonnen, Paul Imhoff
Chapter 1: Introduction
Institut für Informatik III Object Oriented Software Construction 2011 2 / 49
The team ... for further questions
Course Director:
• Prof. Dr. Armin B. Cremers ([email protected])
Lecture Organization:
• Daniel Speicher ([email protected])
• Tobias Rho ([email protected])
Tutorials:
• Paul Imhoff ([email protected])
• Jan Nonnen ([email protected])
Institut für Informatik III Object Oriented Software Construction 2011 3 / 49
Main resource: OOSC 11 Wiki (read-only)
https://sewiki.iai.uni-bonn.de/teaching/lectures/oosc/2011/start
Institut für Informatik III Object Oriented Software Construction 2011 4 / 49
Objectives of the Class
Introduction to
Technical aspects of building complex software systems
Object-Oriented Modeling with the Unified Modeling Language
The Complete Software Lifecycle
Configuration & Rationale Management
Software Processes
Advanced Topics are covered in a follow-up lecture
“Advanced Topics of Software Construction”
Deepens Requirements Engineering, e.g. Requirements Writing
Software Architectures
Advanced Technologies
Aspect-oriented Software Development
Model-Driven Architecture
OOSC 2011
ATSC 2011/12
Institut für Informatik III Object Oriented Software Construction 2011 5 / 49
Acquire Technical Knowledge
Learn standard modeling language
UML 2.0 (Unified Modeling Language)
Learn standard modeling methods
Learn how to use tools
Eclipse Subversion UML modeling with Astah Testing with JUnit
Learn how to use proven solutions
Design Patterns Refactoring
Improve your knowledge in Java
Institut für Informatik III Object Oriented Software Construction 2011 6 / 49
Required Reading
Institut für Informatik III Object Oriented Software Construction 2011 7 / 49
Readings
Required:
Bernd Bruegge, Allen Dutoit: “Object-Oriented Software Engineering: Using UML, Patterns, and Java”, Prentice Hall, 2009, 3rd ed.
Recommended:
Dan Pilone, Neil Pitman: “UML 2.0 in a Nutshell”, O'Reilly Media, 2005, 2nd ed.
Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides: “Design Patterns”, Addison-Wesley, 1996.
Martin Fowler et al.: “Refactoring - Improving the Design of Existing Code”, Addison Wesley, 1999
Additional books may be recommended during individual lectures
Institut für Informatik III Object Oriented Software Construction 2011 8 / 49
Outline of Today's Lecture
Perspectives on Software Engineering
Modeling Complex Systems
Software Lifecycle
Overview of the Class, Organization
O O S C
Perspectives on Software Engineering
Institut für Informatik III Object Oriented Software Construction 2011 10 / 49
Ideas
How to start with a software project?
Information Conditions
Requirements
Institut für Informatik III Object Oriented Software Construction 2011 11 / 49
Requirements
Mapping requirements to Software Can it be so easy?
Software
Direct mapping
Institut für Informatik III Object Oriented Software Construction 2011 12 / 49
Perspectives on Software Engineering: Quality of Software
“Bad software engineering” leads to functional misbehavior
Updates are needed to fit the initial requirements
Increased costs
Delayed deployment
Unsatisfied customers
Some examples:
Toll Collect (Germany): Technical Problems caused a delayed deployment of more than 2 years
Hartz IV-Software “A2II”: Regular Updates needed, high costs; Computation of the unemployment benefit cannot be guaranteed (http://www.heise.de/newsticker/meldung/78233)
The average software product released on the market is not error free
Institut für Informatik III Object Oriented Software Construction 2011 13 / 49
Perspectives on Software Engineering: Working Definition
Software Engineering is a collection of techniques, methodologies and tools that help with the production of
A high quality software system developed with a given budget before a given deadline while change occurs.
Challenge: Dealing with complexity and change
Institut für Informatik III Object Oriented Software Construction 2011 14 / 49
Perspectives on Software Engineering: What makes a Software Engineer?
Computer Scientist (Researcher)
Proves theorems about algorithms, designs languages, defines knowledge representation schemes
Has infinite amount of time… (in general no project)
Programmer
Mainly involved in the technical realization of software
Software Engineer
Has to work in and understand multiple application domains
Must have technical and managerial background
Covers many (all) phases in software lifecycle in a project
Institut für Informatik III Object Oriented Software Construction 2011 15 / 49
Perspectives on Software Engineering: A Problem Solving Activity
General Procedure for Problem-Solving:
Formulate the problem
Analyze the problem and break it into pieces
Search for solutions
Decide on the most appropriate solutions
Specify and aggregate the solutions
Institut für Informatik III Object Oriented Software Construction 2011 16 / 49
Perspectives on Software Engineering: A Problem Solving Activity
Problem solving needs:
Notation
Graphical or textual set of rules for representing a model
Methods:
Repeatable technique that specifies the steps for solving a specific problem
Methodologies:
Collection of methods for solving a class of problems. Specifies how and when each method should be used
Tools:
Instrument or automated systems to accomplish a method
Knowledge Acquisition
Nonlinear process: addition of new knowledge may invalidate old knowledge
Rationale Management
Capturing the context in which decisions were made and the rationale behind these decisions
Institut für Informatik III Object Oriented Software Construction 2011 17 / 49
Influences of Object Orientation
Today’s mainstream development methodology in Software Engineering. Influences:
Object
Orientation
Object-Oriented Programming Languages (C++, Java, C#, Ruby, Smalltalk)
Object-Oriented Modeling Notations ( UML2 )
Object-Oriented Modeling Methods (Rational Unified Process, …)
[Object-Oriented] Databases, Platforms …
Major standardization Endeavors (OMG); Appreciation in industry
“Post Object-Orientation” (Components, Aspects, Services)
Model-Driven Architecture (EMF, OAW, AndroMDA,…)
Institut für Informatik III Object Oriented Software Construction 2011 18 / 49
The Object Management Group
O O S C Modeling Complex Systems
Institut für Informatik III Object Oriented Software Construction 2011 20 / 49
Factors affecting quality of software system
Complexity
Complex technologies (programming languages)
The development process is very difficult to manage
Domains are complex that no single person can understand it
Complex (unfeasible) requirements from clients
Fixing a bug causes another bug
Change
Requirements need to be updated when errors are discovered and when developers have a better understanding of the application
Project constellation changes (staff turn-around)
Technological changes (new standards, languages)
Institut für Informatik III Object Oriented Software Construction 2011 21 / 49
Dealing with Complexity Three Main methods
1. Modeling Abstract from complex systems and condition and build
models
improves understanding, reusability
2. Decomposition
Divide your solution into independent pieces
improves flexibility, effectiveness
3. Composition Organize the system (and knowledge) in meaningful
hierarchies
improves understanding
Institut für Informatik III Object Oriented Software Construction 2011 22 / 49
Modeling Models are used to provide abstractions
System Model:
Object Model: What is the structure of the system? What are the objects and how are they related?
Functional model: What are the functions of the system? How is data flowing through the system?
Dynamic model: How does the system react to external events? How is the event flow in the system ?
Task Model:
PERT Chart: What are the dependencies between the tasks?
GANTT Chart: How can this be done within the time limit?
Org Chart: What are the roles in the project or organization?
Issues Model:
What are the open and closed issues? What constraints were posed by the client? What resolutions were made?
Institut für Informatik III Object Oriented Software Construction 2011 23 / 49
Modeling The “Triangle” of Modeling
Task Models
PERT Chart Gantt Chart
Org Chart
Issue Model
Constraints
Issues
Proposals
Arguments
Pro Con
System Models Object Model
Functional Model
Dynamic Model
class... class... class...
Code
Institut für Informatik III Object Oriented Software Construction 2011 24 / 49
Which decomposition is the right one?
Decomposition Overview
A technique used to master complexity (“divide and conquer”)
Functional decomposition
The system is decomposed into modules
Each module is a major processing step (function) in the application domain
Modules can be decomposed into smaller modules
Object-oriented decomposition
The system is decomposed into classes (describing “objects”)
Each class is a major abstraction in the application domain
Classes can be decomposed into smaller classes
Institut für Informatik III Object Oriented Software Construction 2011 25 / 49
Decomposition Overview
Both views are important during software life-cycle
Functional decomposition emphasizes the ordering of operations
Very useful at requirements engineering stage and high level description of the system.
Functions are spread over the system Hard to maintain / change
Object-oriented decomposition emphasizes the objects that cause the operations.
Very useful after initial functional description Object Design
Encapsulates data and functions helps to deal with change
Institut für Informatik III Object Oriented Software Construction 2011 26 / 49
I/O Devices CPU Memory
Computer
Decomposition Object-Oriented Decomposition
Institut für Informatik III Object Oriented Software Construction 2011 27 / 49
Composition
We got modeling and decomposition
This leads us to chunks (classes, objects) which we view with object model
The next step to deal with complexity is to provide simple relationships between the chunks, (re-)composing the chunks to a whole.
One of the most important relationships is hierarchy
2 important hierarchies
"Part of" hierarchy
"Is-kind-of" hierarchy
Institut für Informatik III Object Oriented Software Construction 2011 28 / 49
Composition Part-of-Hierarchy
Computer
I/O Devices CPU Memory
Institut für Informatik III Object Oriented Software Construction 2011 29 / 49
Composition Is-Kind-of Hierarchy (Taxonomy)
Cell
Muscle Cell Blood Cell Nerve Cell
Institut für Informatik III Object Oriented Software Construction 2011 30 / 49
Handle Autoshape
Use Case Taxonomy Functional Decomposition
Draw Rectangle
Draw Oval
Draw Circle
Draw Change Mouse click
Change Rectangle
Change Oval
Change Circle
Institut für Informatik III Object Oriented Software Construction 2011 31 / 49
Class Hierarchy Object-oriented decomposition
draw() change() click()
Autoshape
draw()
Rectangle
draw()
Oval
draw()
Circle
Institut für Informatik III Object Oriented Software Construction 2011 32 / 49
Object-Oriented Modeling Our first modeling project!
Your mission: Please model “this”
Your (obvious) question: What is “this”?
Institut für Informatik III Object Oriented Software Construction 2011 33 / 49
Object-Oriented Modeling: Model of an Inuit
but is it the right model?
Shoe
size color type
wear()
lives in
Igloo
lighting
enter() leave()
Inuit
size
dress() smile() sleep()
Coat
size color type
wear()
Institut für Informatik III Object Oriented Software Construction 2011 34 / 49
Object-Oriented Modeling: Alternative Model: The Head of an Indian
Indian
hair
dress() smile() sleep()
Mouth
nrOfTeeth size
open() speak()
Ear
size
listen()
Face
nose
smile() closeEye()
2 1
Institut für Informatik III Object Oriented Software Construction 2011 35 / 49
Decomposition: Class Identification
Class identification is crucial to object-oriented modeling
What are the limitations? Depending on the purpose of the system different objects might be found
How can we identify the purpose of a system?
Principle Questions in Requirements Engineering
Solution:
Negotiate the purpose of a system with clients
Present various models
Interview, Observations …
… ok, but what to do if the client is unknowing?
Institut für Informatik III Object Oriented Software Construction 2011 36 / 49
Object-oriented Modeling: Behavior of an Inuit entering a igloo
:Inuit :Igloo
Enter()
Leave()
Issue No. 1 “Behavior of Shape” Status: solved Rationale: Client confirmed the shape as Inuit
tim
e
Institut für Informatik III Object Oriented Software Construction 2011 37 / 49
Object-oriented Modeling: Anticipate changes
lives in
Change Request: Inuit wants to live in a flat Goal: Find a design in which such a change can be realized Use already well-proven designs!
Flat
lighting
goIn()
Igloo
lighting
enter() leave()
Inuit
size
dress() smile() sleep()
Institut für Informatik III Object Oriented Software Construction 2011 38 / 49
Class Identification
Class identification is crucial to object-oriented modeling
Basic assumption:
1. We can find the classes for a new software system: We call this Greenfield Engineering
2. We can identify the classes in an existing system: We call this Reengineering
3. We can create a class-based interface to any system: We call this Interface Engineering
Why can we do this? Philosophy, science, experimental evidence
What are the limitations? Depending on the purpose of the system different objects might be found
How can we identify the purpose of a system?
Institut für Informatik III Object Oriented Software Construction 2011 39 / 49
So where are we right now?
Three ways to deal with complexity and changes
Modeling
Decomposition
Composition
Object-oriented modeling is a good methodology
Be aware of the purpose of the system, as the objects found depend on it
Anticipate changes in design
How can we do it right?
Our current approach: Start with a description of the functionality, then proceed to the object model
This leads us to the software lifecycle
O O S C Software Lifecycle
Institut für Informatik III Object Oriented Software Construction 2011 41 / 49
Software Lifecycle Activities … and their models
Sub- systems
class...
class...
class...
Source Code
Solution Domain Objects
System Design
Object Design
Implemen- tation
Testing
ApplicationDomain Objects
Test Cases
?
class.... ?
Requirements Elicitation
Use Case Model
Requirements Analysis
Expressed in Terms of
Structured by
Realized by
Implemented by
Verified by
Institut für Informatik III Object Oriented Software Construction 2011 42 / 49
Another visual presentation of the lifecycle
Requirements Elicitation
Requirements Analysis
System Design
Object Design
Implementation
Unit Testing
Integration Testing
System Testing
Acceptance Testing
The users world and language
The developers world and language
„V-Model“
Institut für Informatik III Object Oriented Software Construction 2011 43 / 49
Software Lifecycle Definition
Software lifecycle
Set of activities and their relationships to each other to support the development of a software system
Typical lifecycle questions
Which activities should I select for the software project?
What are the dependencies between activities?
How should I schedule the activities?
Dealing with change
Use a nonlinear software lifecycle to deal with changing requirements or changing technology (Iterations)
Provide configuration management to deal with changing entities
Institut für Informatik III Object Oriented Software Construction 2011 44 / 49
Summary
Software engineering is a problem solving activity
Developing quality software for a complex problem within a limited time while things are changing
Object-Oriented Software Construction provides standard methods
There are many ways to deal with complexity
Modeling, decomposition, composition (hierarchy)
Many ways to do deal with change
Management View: Use of an iterative software lifecycle
Technical View: Anticipate changes in your design ( use design patterns)
O O S C Overview of the Class, Organization
Institut für Informatik III Object Oriented Software Construction 2011 46 / 49
Overview on Lectures
Introduction Software Configuration
Management
Introduction to UML
Requirements Engineering Requirements Elicitation
Requirements Analysis
System Design Decomposition
Architecture Styles
Architecture Organization
Addressing Design Goals
Object Design Fundamentals
Design Pattern
Specifying Interfaces
Implementation and Testing Mapping Models to Code
Testing, Unit Testing
Refactoring
Testing, System Tests
Software Development Process Models
Invited Talk
Institut für Informatik III Object Oriented Software Construction 2011 47 / 49
Class Organization Requirements to be credited
SWS: V3/Ü1, number of ECTS Credits: 6
Requirements to get admittance to the written exam (21.07.11)
Join an exercise group of three students.
The submission is via SVN.
Regular attendance to the exercises by all group members.
You will meet with your tutor in the week following the deadline.
You are allowed to miss at most one exercise.
Points will be tracked individually.
The whole group has to attend the meeting with the tutor. If you are not there you get zero points.
Each group member has to be able to present the solution. You can only get points for tasks that you can explain.
50% of the total points from all the assignments are required to get admitted to the exam.
Institut für Informatik III Object Oriented Software Construction 2011 48 / 49
Your next step: Build groups of 3 and send us an email!
Template for
the email
Your data
(for all three)
Your time
preferences
Institut für Informatik III Object Oriented Software Construction 2011 49 / 49
The semester starts here!
Assignment 0 “Hello OOSC!” already published.
Assignment 1 “Java” will be published tomorrow.
Global exercise on the 13.04.11 after the lecture.
Bring your laptop.
In case of troubles with SVN or Eclipse, we will do our best to help you.
Regular exercise groups after the 18.04.11.
Good luck, have a successful semester
here in Bonn!
Photo: Thomas Wolf , http://de.wikipedia.org/w/index.php?title=Datei:Universit%C3%A4t_Bonn.jpg&filetimestamp=20081019131401