M.

Sc Computing Science
Software Engineering– Lecture 1
Niki Trigoni
Department of Computer Science
and Information Systems
Birkbeck College, University of London

Email: niki@[Link]
Web Page: [Link]
The S/E course at a glance
Main objectives:
 Become adept at understanding and defining a problem
 Learn how to design a solid solution

Approach to achieving these objectives:

 Follow a specific methodology (e.g. the Unified Process)
 Build robust and maintainable systems by using object-
oriented analysis and design (OOA/D)
 Use UML to illustrate analysis and design models
 Apply design patterns to improve solution
Resources
Textbooks:
 “Applying UML and Patterns; An Introduction to Object-
Oriented Analysis and Design and the Unified Process”,
Craig Larman, 2nd edition, Prentice-Hall 2002
 “Design Patterns Explained; A New Perspective on
Object-Oriented Design”, Alan Shalloway and James R.
Trott, Addison Wesley 2002
Lecture Notes:
 [Link]
Coursework:
 Announced: 19 February
 Due: 26 March
Roadmap
Lecture 1: Overview of OOA/D and the UP (Unified Process)
Lecture 2: Use-Case model: write requirements
Lecture 3: Domain model: identify conceptual classes
Lecture 4: Design model: design objects and their interactions
Lecture 5: Design model (cont): the GRASP patterns
Lecture 6: Design examples and Implementation model
Roadmap (cont.)
Lecture 7: Demo of Borland Together
Lecture 8: More GRASP and GoF patterns
Lecture 9: Design examples using GRASP and GoF patterns
Lecture 10: Architectural analysis
Lecture 11: Revision Lecture
Overview of lecture 1
 Initial observations on software development
 Object-oriented analysis and design
 An intro to the Unified Process (UP)
What makes good software?
 Relevance
 Usability
 Robustness
 Fault-tolerance
 Maintainability
 Efficiency
 …
The emphasis on these metrics varies across projects.
Examples of software products
 Real time: air traffic control
 Embedded systems: digital camera, GPS
 Data processing: telephone billing, pensions
 Information systems: web sites, digital libraries
 Sensors: weather data
 System software: operating systems, compilers
 Communications: routers, mobile telephones
 Offices: word processing, video-conferences
 Scientific: simulations, weather forecasting
 Graphical: film making, design
 etc.
Putting software production in perspective
 Biggest program that you have written?
 Biggest program that you have worked on?
 Biggest project team that you have been part of?
 Longest project that you have worked on?
 Most people who have used your work?
 Longest that your project has been in production?

 The coursework for S/E will be about 0.01 person∙years.

 A big project may be 100 to 1,000+ person∙years.
 Software production requires team work.
 Large software projects are built on older ones.
 Software is expensive.
Approach to building large systems
 Analysis and design
 Object-oriented technology
 Follow a process that prescribes analysis and design in a well-
defined manner (e.g. the Unified Process)
 Clear documentation and sharing of information during
software development (e.g. using UML)
 Human factor: work in teams of people
 proficient in S/E and
 with good communication skills
Analysis and design
 Analysis: do the right thing
 investigation of a problem
 requirements
 e.g. requirements analysis or object analysis
 Design: do the thing right
 conceptual solution that fulfills the requirements
 can lead to implementation
 not the implementation
 e.g. object design or database design

 Object-oriented Analysis and Design (OOA/D)

 think (analyze and design) in objects
Object-oriented analysis
 OO analysis: create a description of the domain from the
perspective of classification by objects.
 identify main concepts (objects)
 add attributes
 associate objects with each other

Player Die
1 Rolls 2
name faceValue
1 2
Plays
1

DiceGame
1 Includes
Object-oriented design
 OO design: define software objects and their collaborations
 static view: design class diagrams
 dynamic view: interaction diagrams

DiceGame Die

die1 : Die 1 2 faceValue : int

die2 : Die
getFaceValue() : int
play() roll()
Object-oriented design
 OO design: define software objects and their collaborations
 static view: design class diagrams
 dynamic view: interaction diagrams

:DiceGame die1 : Die die2 : Die

play()
roll()

fv1 := getFaceValue()

roll()

fv2 := getFaceValue()
Software engineering is not just coding
 Knowing an OO language, like Java or C++, is necessary, but
not sufficient in order to create object software.
 In between a nice idea and a working software, there is much
more than programming.

Analysis Design Programming

Investigation of
Logical solution Code
the problem
OOA/D in the Unified Process (UP)
 In which context do we apply OOA/D ?
 We need a process
 with well defined steps
 that uses OOA/D
 in order to achieve a software development goal.
 The Unified Process is an example process particularly suited
for building OO systems.
 Why use the Unified Process to develop software?
Central ideas in the UP
 Use of OO technologies
 Iterative lifecycle
 Continuous feedback and adaptation
 Managed complexity
 Early visible progress
 Time-boxed iterations
 Risk-driven development
 Early mitigation of high risks
 Cohesive and well-documented process
 Widely used process
 UML: a well-defined modeling language for documenting
and communicating ideas and designs
The UP iterative development
 Feedback from iteration N leads to refinement and
adaptation of the requirements and design in iteration N+1
 Iterations are fixed in length

Requirements Requirements

Analysis & Design Time Analysis & Design

Implementation Implementation

Testing & Delivery Testing & Delivery

Iteration N Iteration N+1

UP phases
 Inception
 Feasibility phase and approximate vision
 Elaboration
 Core architecture implementation, high risk resolution
 Construction
 Implementation of remaining elements
 Transition
 Beta tests, deployment
development cycle

iteration phase

inc. elaboration construction transition

UP artifacts and disciplines
 The UP describes work activities, which result in work products
called artifacts. Examples of artifacts:
 Code
 Web graphics
 Database schema
 Use cases (text documents explaining business scenarios)
 Diagrams, models and so on

 A discipline (or workflow) is a set of work activities. Examples:

 Requirements
 Business modeling
 Design
 UP disciplines and iterations
A four-week iteration (for example).
A mini-project that includes work in most Note that
 An iteration includes work in most disciplines.
disciplines, ending in a stable executable. although an
iteration includes
Sample work in most
Sample
UP
UP Disciplines Disciplines disciplines, the
relative effort and
Business
Business Modeling
modeling emphasis change
over time.
Focus Requirements
of this Requirements This example is
book Design suggestive, not
Design literal.
Implementation
Implementation
Test
Test
Deployment
Deployment
Configuration and
Configuration & Change
Change Mngmnt
Management
Project
Project ManagementMngmnt
Environment
Environment

Iterations
An overview of the Unified Process
Discipline Artifact Inc. Elab. Con. Tran.

Bus. Modeling Domain Model s

Requirements Use-case Model s r

Vision, SS, Glossary s r

Design Design Model s r

Data Model s r

Architecture Docum. s

Implementation Implement. Model s r r

Project Mngmt SW Developm. Plan s r r r

Testing Test Model s r

Environment Development Case s r

The waterfall model
Feasibility study

Requirements

System design

Program design

Coding

Testing
Acceptance testing
Operation & maintenance
 How does it differ from the UP?
Case study: Banking application
 Inception: envision the product scope, vision and business case.
 What is the vision for this project?
 Is it feasible?
 Who will do it?
 In-house development
 Buy external packages and customize them
 Sub-contract the project to a software company
 How much will it cost ?
 This depends on who will do the work.
 Will it require training of the personnel of the bank, or hiring
new people?
 Think of the main risks and constraints involved.
 Define the most important functional requirements (opening
an account, deposit, withdrawal)?
 Is it worth investigating in serious investigation?
Case study: Banking application
 Elaboration: build the core architecture and resolve the high risk
elements, define most requirements and estimate the overall
schedule and resources.
 Work in short time-boxed risk-driven iterations
 How do we describe the functional requirements of the
banking application?
 Which are the main domain concepts involved in the business
of a bank (account, customer, transaction)?
 How do domain concepts translate to design objects?
 Design the database schema used to represent data
 Build the User Interface
 Which are the key architectural issues?
 How will we test the system? What will be tested?
 Implement a good part of the system
Questionnaire
 Inception=Requirements, Elaboration=Design,
Construction=Implementation (true? or false?)
 Requirements must be fully defined before starting analysis and
design (true? or false?)
 A system must be perfectly designed before being implemented
(true? or false?)
 A suitable iteration is four week long, as opposed to four month
long (true? or false?)
 An accurate estimate of the project development cycle is possible
at the end of the Inception Phase (true? or false?)
 The most critical functional requirements are not defined during
the Inception Phase (true? or false?)
 The code written during the first iterations of Elaboration is a
throw-away prototype (true? or false?)