Introduction 2010

Modern Methods in
Software Engineering
ID2207
Introduction
www.imit.kth.se/courses/2G1522
Course info
www.imit.kth.se/courses/2G1522
Coordinator and lecturer
Mihhail Matskin
misha@imit.kth.se
tel. 08-790 41 28
Assignments and project responsible
Nima Dokoohaki Shahab Mokarizadeh
nimad@kth.se shahab@kth.se
Lectures & Exercises:
Mondays 10.00-12.00
13.00-15.00
Fridays 10.00-12.00
Written examination ( 4.5 p.)
October 18 at 09:00-13:00
Registration at least 14 days before exam period
Homework and project assignments (3 p.)
Homework
Start Date Due Date Description
2010-09-13 2010-09-19 Homework 1
2010-09-20 2010-09-26 Homework 2
2010-09-27 2010-10-03 Homework 3
2010-10-04 2010-10-10 Homework 4
It is assumed that the Homework are done by groups of 2 student -
there will be no additional bonus for doing them alone
Project
Aims of the project
• To get practice in Agile Programming approach
Your task
Apply some elements of Extreme programming approach to

solving the problem of implementing Academic payroll
system
Provide an analysis and comparison of your experience to

develop a code with analysis-design-implementation cycle
and with XP approach
The project must be done by groups of 2 students

Bonuses
1.Delivering all Homeworks 1,2,3,4 in due time gives 5
bonus points to written exam (this assumes that all
Homeworks are approved)
2. In case of Late Submission of any Homework, No
bonus points will be awarded for the “in-time
submission of homeworks”.
3. Delivering project work before October 20 gives 5
bonus points to written exam (this assumes that the
project work is approved)
ALL Bonus points are only valid for the first exam on
October 18
Course literature
• Object-Oriented Software Engineering: Using
UML, Patterns and Java: International Edition, 3/E
Bernd Bruegge, Allen H. Dutoit,
ISBN-10: 0136061257, ISBN-13: 9780136061250
Publisher: Prentice Hall, Copyright: 2010, 800 pp
Published: 07/29/2009
(available in the Kista Electrum book store)
• Lecture notes
• Additional articles in the curriculum will be added
during the course
Very Tentative Lecture Plan
Date Lecture
1 06.09.2010
Introduction and Software Lifecycles
2 13.09.2010
UML Basics
3 17.09.2010
Requirements Elicitation
4 20.09.2010
Requirements Analysis
5 24.09.2010
System Design
6 27.09.2010
Object Design (reuse)
7 01.10.2010
Object Design (Interface Design)
8 04.10.2010
Move to code, Testing, Extreme Programming and other
Agile methods
9 08.10.2010
Homework/Extreme Programming and other Agile
methods
10 11.10.2010
Guest lecture from Microsoft
Objectives of the Course
• Learn about Software Engineering methods:
– how to build complex software systems when the
context frequently changes
• Learn methods for dealing with complexity and
changes in software construction
• Be able to evaluate and choose methods for
producing a high quality software system within
time
• Get technical knowledge and some managerial
knowledge for software construction
Introduction Content
• Introduction
• Software nature
• Definitions of Software Engineering
• Dealing with complexity
– Abstraction
– Decomposition
– Hierarchy
• Software development concepts and activities
• Software development lifecycle
Literature used
• Text book “Object-Oriented Software
Engineering: Using UML, Patterns and Java”
International Edition, 3/E Bernd Bruegge,
Allen H. Dutoit
Chapters 1, 15, 16
What is Software?
– computer programs
– associated documentation
– associated data that is needed to make the programs

operatable
Software’s Nature
• Software is
– intangible – it is difficult to understand development
efforts
– easily reproducible – cost is not in manufacturing but in
development
– labor-intensive – hard to automate
– easy to modify
– a logical rather than physical product – it doesn’t wear out
with use
– untrained people can hack something together
Adopted from Lethbridge and Laganière.

Some known software failures
• Item: In the summer of 1991, telephone outages occurred in local telephone
systems in California and along the Eastern seaboard. These breakdowns were
all the fault of an error in signaling software. Right before the outages, DSC
Communications (Plano, TX) introduced a bug when it changed three lines of
code in the several-million-line signaling program. After this tiny change,
nobody thought it necessary to retest the program.
• Item: In 1986, two cancer patients at the East Texas Cancer Center in Tyler
received fatal radiation overdoses from the Therac-25, a computer-controlled
radiation-therapy machine. There were several errors, among them the failure
of the programmer to detect a race condition (i.e., miscoordination between
concurrent tasks).
• Item: A New Jersey inmate escaped from computer-monitored house arrest in
the spring of 1992. He simply removed the rivets holding his electronic anklet
together and went off to commit a murder. A computer detected the tampering.
However, when it called a second computer to report the incident, the first
computer received a busy signal and never called back.
From http://www.byte.com/art/9512/sec6/art1.htm
Example: Space Shuttle Software
• Cost: $10 Billion, millions of dollars more than planned
• Time: 3 years late
• Quality: First launch of Columbia was cancelled because
of a synchronization problem with the Shuttle's 5 onboard
computers.
– Error was traced back to a change made 2 years earlier when a
programmer changed a delay factor in an interrupt handler from 50
to 80 milliseconds.
– The likelihood of the error was small enough, that the error caused
no harm during thousands of hours of testing.
• Substantial errors still exist.
– Astronauts are supplied with a book of known software problems
"Program Notes and Waivers".
Adopted from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
Do you know this product?
Software failures – some reasons
• Seldom occurring situations are not taken
into account
• Users can actively misusing systems
• Management failures
• Unnecessary complexity
• ...
Software project failures
• Terminated for non-performance of contract.
• Completed but the system is not deployed as users
cannot or will not use it.
• Completed but the system does not meet the
originally promised
• cost
• schedule.
• quality.
• capability.
• Completed but the system could not be evolved in
a cost-effective manner
Adopted from Charette 1989

Software projects
• The Standish Group delivered
“Chaos Report”
– 365 IT executives in US
companies in diverse industry
segments. Project completion
– 8,380 projects On time, on budget,
with all of the specified
features and functions
16%
• In 1994 only 16.2% of software 53%
projects were completed on-time and Cancelled before they
were completed
on-budget (for large and complex
systems it is 9%)
– average time overrun = 222%. delivered and
operational but over-
– average cost overrun = 189% 31% budget, over-schedule

or with fewer features
and functions than
– 61% of originally specified features
included
• In 2003 , it is 34% of projects

completed on-time and on-budget
Software’s nature
• Demand for software is high and rising
• In many cases software has poor design and
it getting worse
• “software crisis” in a permanent state
• We have to learn to engineer software
What is Software Engineering?
• Software Engineering is the establishment and use of sound
engineering principles in order to obtain economically
software that is reliable and works efficiently on real
machines [from Fritz Bauer in Pressman 1997, pA-1]
• sound engineering principles implies:
– a specification followed by an implementation
– a demonstration that the solution does what it is supposed to do
– the adoption of sound project management practices
– the availability of a range of tools and techniques
• obtain economically implies:
– productivity estimation measures
– cost estimation and measures
• reliability and efficiency imply:
– performance measures
– standards
– quality
The IEEE describes Software Engineering as
“the application of a systematic,
disciplined, quantifiable approach to the
development, operation and maintenance of
software”
• quantifiable implies measurement

• the discipline is not only concerned with
development but also maintenance and
operation
Software Engineering
• The amateur software engineer is always in
search of magic, some sensational method or
tool whose application promises to render
software development trivial. It is the mark of
the professional software engineer to know
that no such panacea exists.
– Grady Booch, in Object-Oriented Analysis and Design
• Brygge&Dutoit:
– Software Engineering is a collection of
techniques, methodologies and tools that help
with the production of
• a high quality software system
• with a given budget
• before a given deadline
• while change occurs.
• Software engineering is a modeling activity.
• Software engineering is a problem-solving
activity.
• Software engineering is a knowledge
acquisition activity.
• Software engineering is a rationale-driven
activity.
Scientist, Engineer and Software
Engineer
• (Computer) scientist
– concerns theories and methods that underlie computer and software
systems
– Has (almost) no time constraints
• Engineer
– works in application specific domain
– has time constraints
• Software engineer
– woks in multiple application domain
– has time constraints
– changes can occur in requirements and technology
Factors of Software Design
• Complexity
– The problem domain is difficult because of often we are
not experts in it
– The development process is very difficult to manage
– Software is extremely flexible – easy to modify
• Changes
– each change makes next change more expensive
– the cost of implementing changes grows in time
How to deal with complexity?
• Abstraction
-- Ignore non-essential details - modeling
• Decomposition
-- Break problem into sub-problems
• Hierarchy
-- Simple relationship between chunks
Abstraction/Modeling
• 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:
– What are the dependencies between the tasks?
– How can this be done within the time limit?
– 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?
Abstraction/Models
System Models Object Model
Forward
Engineering
Dynamic Model
class...
class... Code Reverse
Functional class... Engineering
Model
Constraints
Arguments Org Chart
Issues Pro Con
PERT Chart
Proposals
Issue Model Task Models

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
Building a House (Dependency Graph)
Install Install Install
Interior Interior Wallboard
The activity Plumbing Electrical
„Buy Material“ must

Paint
Precede the activity Interior
„Lay foundation“
Install
Interior
Install Doors
Flooring
Lay Build
START Survey Excava Buy FINISH
Founda Outside
ing tion Material
tion Wall Install
Roofing
Install
Exterior
Doors
Request
Paint
Exterior
Install Install Install

Exterior Exterior Exterior
Plumbing Electrical Siding
Gantt Chart
Activity 1
Activity 2
Activity 3
Activity 4
Activity 5
0 1 2 3 4 5 6 7
Time (in weeks after start)
Easy to read
Gantt Chart with milestones
Project Start
Activity 1
Activity 2
Activity 3
Design Review
Activity 4
Activity 5
Project Finish
0 1 2 3 4 5 6 7
Time (in weeks after start)
Good for reviews.
Types of Gantt Charts
Person-Centered View Activity-Centered View

To determine people‘s load To identify teams working
together on the same tasks
Joe A1 A2 A3
A1 Joe, Toby
Mary
A2 Joe
Toby A1 A3
A3 Clara, Toby, Joe

Clara A3
Time Time
Issue Model
Issue:
What is the Resolution (1615):
Resolution (1998): Center of the The church
The church declares Universe? decides proposal 1
proposal 1 was wrong is right
Proposal1: Proposal2:
The earth! The sun!
Pro: Pro:
Aristotle Con: Copernicus
says so. Jupiter’s moons rotate says so.
around Jupiter, not
around Earth.
Pro:
Change will disturb
the people.
Decomposition
• Functional decomposition - emphasizes the
ordering of operations
– The system is decomposed into functional modules
– Each module is a processing step (function) in the
application domain
– Modules can be decomposed into smaller modules
• Object-oriented decomposition - emphasizes the
agents that cause the operations
– The system is decomposed into classes (“objects”)
– Each class is a major abstraction in the application
domain
– Classes can be decomposed into smaller classes
Functional Decomposition
System
Function
Read Process Output Level 1 functions
Level 2 functions
Read Process Output
Load R5 Add R1, R5
Functional decomposition
Autoshape
Mouse Change Draw

click
Change Change Change

Rectangle Oval Circle
Draw Draw Draw

Rectangle Oval Circle
Object decomposition
Shape
Circle
Rectangle Oval
Draw
Draw Draw Change
Change Change
Object-Oriented Decomposition
Eskimo Indian
Size Hair
Dress() Dress()
Smile() Smile()
Sleep() Sleep()
*
Shoe Coat
Size Size Mouth
Color Color Face NrOfTeeths
Ear
Type
Wear()
Type
Wear()
Size * Nose
smile()
Size
open()
listen()
close_eye() speak()
Modeling Briefcase
Chair
BriefCase
Capacity: Integer
Weight: Integer
Open()
Close()
Carry()
SitOnIt()
Hierarchy
• Relationships between components obtained
from abstraction and decomposition
• Hierarchy is one of ways to provide simple
relationships
• Part-of-hierarchy
• Is-kind-of hierarchy
Part-of hierarchy
Computer
I/O Devices CPU Memory
Cache ALU Program

Counter
Is-a-kind-of hierarchy
Cell
Muscle Cell Blood Cell Nerve Cell
Striate Smooth Red White Cortical Pyramidal
Where we are now?
• Three ways to deal with complexity:
– Abstraction
– Decomposition
– Hierarchy
• Object-oriented decomposition is a good methodology
– Unfortunately, depending on the purpose of the system, different
objects can be found
• How can we do it right?
– Many different possibilities
– Our current approach: Start with a description of the functionality,
then proceed to the object model
– This leads us to the software lifecycle
Software Engineering Concepts
(resources)
• Resources include time, equipment and labor
• Participants – all actors involved in the project
• Roles – set of responsibilities in the project
– associated with a set of tasks and they are assigned to
participants
– participant can fill multiple roles
• Example of roles: client, user, manager, developer,
technical writer
• Example of participants: traveler, train company,
John, Alice, Zoe
• Example of role assignments: Alice – manager,
John – technical writer and analyst
• Other resources: Tariff Database
(Work Products)
• System – collection of interconnected parts
– TicketDistributor system
• Model - abstraction of a system
– Schematics of electrical wiring, object model
• Document
– description
• Work product can be
– internal - for project consumption
• test manual
• workplan
– deliverable – delivers to the client
• specification
• operation manual
(activities and tasks)
• Task – atomic unit of work to be managed
– consumes Resources
– produces Work Products
– depends on other tasks
– F/E develop “Out of Change” test case
• Activity – set of tasks performed for achieving the
project’s goals
– F/E requirements elicitation
• Work on the project is broken into tasks and
assigned to resources
Software Engineering Concepts’ Hierarchy
Project
*
Activity
is produced by * consumes
WorkProduct * Task * Resources
System Participant
Model Time
Document Equipment
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java - adopted from OMG
Possible SE activities - Simplified
view
Problem
Domain
Requirements Analysis What is the problem?
System Design What is the solution?
What is the solution in the context

Object Design of an existing hardware system?
Implementation How is the solution constructed?

Implementation
Domain
Software Engineering Development
Activities
• Analysis – concentrates on system requirements –
definitions of a system from users’ point of view
– Requirements elicitation – determining functionality user needs
and a way of its delivering
– Requirements analysis – formalizing determined requirements
and ensuring their completeness and consistency
• Design – constructing the system
– System design – defining a system architecture in terms of design
goals and a subsystem decomposition
– Object design – modeling and construction activities related to the
solution domain
• Implementation – translation of the solution domain model
into code
• Testing – the goal is to discover faults in the system to be
repaired before the system delivery
Activities and Models
Requirements System Object Implemen-
Analysis Testing
Elicitation Design Design tation
Implemented
By
Expressed in Structured By Realized By Verified
Terms Of
By
class...
class...
class... ?
class.... ?
Use Case Application Solution
Domain Subsystems Source Test
Model Domain
Objects Code Cases
Objects
Software Life-Cycle
• Which activities should be selected for the
software project?
• What are the dependencies between
activities?
– Does system design depend on analysis? Does
analysis depend on design?
• How should the activities be schedule?
– Should analysis precede design?
– Can analysis and design be done in parallel?
– Should they be done iteratively?
Software Life-cycle
• Life-cycle differs between projects
• Different experience and skills
• Different application domains
• Environment changes
• Project size
Software Life-Cycle
Conception Childhood
Childhood Adulthood Retirement
Pre- Post-
Development
Development
Development Development
IEEE 1074: Standard for Developing
Software Lifecycle Processes
• Describes a set of activities and processes

that are mandatory for development and
maintenance of software
• Establishes a common framework for
developing lifecycle models
• Process Group - consists of Set of Processes
– Design process is a part of Development group
• Process - consists of Activities. Design process may
consist of:
– Perform Architectural Design
– Design Database (If Applicable)
– Design Interfaces
– Select or Develop Algorithms (If Applicable)
– Perform Detailed Design (= Object Design)
• Activity - consists of subactivities and tasks. Design
Database activity may consist of:
– Review Relational Databases
– Review Object-Oriented Databases
– Make a Purchase recommendation
– ....
• Process Group: Consists of Set of Processes
• Process: Consists of Activities
• Activity: Consists of sub activities and tasks
Process
Process Development
Development
Group
Group
Process
Process Design
Design
Activity Design
Design
Activity Database
Database
Make
Makeaa
Task
Task Purchase
Purchase
Recommendation
Recommendation
Life
LifeCycle
Cycle
Modeling
Modeling Process Group
IEEE
IEEE1074
1074
> Selection of Life Cycle model
Pre- Develop- Post- Cross-

Cross-
Project
Project Pre- Develop- Post-
Development ment Development Development
Development
Management
Management Development ment Development (Integral
(IntegralProcesses)
Processes)
> Project Initiation > Concept > Requirements > Installation >V&V
>Project Monitoring Exploration Analysis > Operation & > Configuration
&Control > System > Design Support Management
> Software Quality Allocation > Implemen- > Maintenance > Documen-
Management tation > Retirement tation
> Training
Processes
Adopted Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
Project Management Process Group
Project
Project
Management
Management
Project
Project Software
Software
Project
Project Monitoring
Monitoring Quality
Quality
Initiation
Initiation &&Control
Control Management
Management
Map Activities to Analyze Risks Plan Software
Software Life Cycle Perform Contingency Quality Mesurement
Model Planning Define Metrics
Allocate Project Manage the Project Manage Software
Resources Retain Records Quality
Establish Project Implement Problem Identify Quality
Environment Reporting Model Improvement Needs
Plan Project
Management
IEEE 1074 standard.
Development processes Management processes Integral processes
Concept
Exploration
Process
System
Allocation
Process
Project Configuration
Requirements Initiation Management
Process Process Process
Design
Process
Implementation Project Documentation

Process Monitoring Development
&Ctrl Process Process
Installation
Process
Operation S/W Quality

& Support Training
Management Process
Process Process
Maintenance
Process Verification
& Validation
Process
Retirement
Process
Capability Maturity Model (CMM)
• Level 1: Initial
– Ad hoc activities applied
– Success depends on skills of key individuals
– System is black box for users
– No interaction with user during the project
• Level 2: Repeatable
– Each project has well-defined software life cycle
– Models differ from project to project
– Previous experience in similar projects allows predictability success
– Interaction with user in defined points
• Level 3: Defined
– Documented software life cycle model is used for all activities
– Customized version of the model is produced for each project
– User knows standard model and the model selected for the project
• Level 4: Managed
– Metrics for activities and deliverables defined
– Collecting data during project duration
– The software life cycle model can be analyzed
– User informed about the risks before the project and knows the measures
• Level 5: Optimized
– The measurement data are used as a feedback to improve the software life cycle over
lifetime of the organization
– The user, mangers and developers communicate and work together during the whole
project
What do we want?
Requirements
Design
Implementation
Testing
Software
Waterfall Model
Concept
Exploration
Process
System
Allocation
Process
Requirements
Process
Design
Process
Implementation
Process
Verification
& Validation
Process
Installation
Process
Operation &
Support Process
Waterfall model
• Managers like waterfall models:
– Clear milestones
– No need to look back (linear system), one activity at a time
– Easy to check progress : 90% coded, 20% tested
• In practice, software development is not sequential
– The development stages overlap
• Different stakeholders need different abstractions
• System development is a nonlinear activity
Waterfall model with prototyping
Requirements
Engineering
Requirements
Analysis
System
Design
Object
Design
Implementation
Prototyping Process
Verification
& Validation
Process
Installation
Process
Operation &
Support Process
V- model
Acceptance
Requirements
Engineering
System
Requirements
Testing
Analysis
Integration
System Design Testing
Unit
Object Design Testing
Implemen-
tation
Unit
Testing
Integration
Testing
System
Copyright 2002 Bernd Brügge Software Engineering II, Lecture 3: Scheduling SS 2002 Testing
V-Model
System Is validated by
Requirements Operation
Analysis
precedes
Software
Requirements Client
Elicitation Acceptance
System
Requirements Integration
Analysis & Test
Component
Preliminary Integration
Design & Test
Detailed Unit
Design Test
Implementation
Copyright 2002 Bernd Brügge Software Engineering II, Lecture 3: Scheduling SS 2002
Incremental model
Features and functionality
analysis design implementation deployment
Time
Iterative models
• Software development is iterative
– During design problems with requirements are
identified
– During coding, design and requirement
problems are found
– During testing, coding, design & requirement
errors are found
=> Spiral Model
Spiral model
• The spiral model proposed by Boehm is an
iterative model with the following activities
– Determine objectives and constraints
– Evaluate Alternatives
– Identify risks
– Resolve risks by assigning priorities to risks
– Develop a series of prototypes for the identified risks
starting with the highest risk.
– Use a waterfall model for each prototype development
(“cycle”)
– If a risk has successfully been resolved, evaluate the
results of the “cycle” and plan the next round
– If a certain risk cannot be resolved, terminate the
project immediately
Spiral model
Rounds/cycles • For each cycle go through these activities
– Quadrant IV: Define objectives,
• Concept of Operation, alternatives, constraints
• Software Requirements, – Quadrant I: Evaluate alternative,
• Software Product Design, identify and resolve risks
• Detailed Design, – Quadrant II: Develop, verify
prototype
• Code, – Quadrant III: Plan next “cycle”
• Unit Test, IV Determine objectives
• Integration and Test, IV Specify constraints
• Acceptance IV Generate alternatives
I Identify risks
I Resolve risks
II Develop and verify prototype
III Plan
Spiral model
Project
cost
Risk analysis
Define Objectives
“continue,
not-continue”
decision
Project
progress
Customer
evaluation Prototyping
and next round planning
Spiral Model
Determine objectives, Evaluate alter natives,
alternatives, & constraints identify & resolve risks
Risk
analysis
Risk
analysis
Risk Analysis
Start Project activity
Risk
analysis
Start New Round P1
Prototype3
Prototype2
Prototype1
Requirements Concept of
plan operation Software
System
Requirements Product Detailed
Design Design
Development Requirements
plan validation
P2
Code
Integration Design Unit Test

plan validation Develop & ver ify
Plan next phase next level product
Requirements and Integration & Test
Life cycle Planning

Acceptance Development system product
Test
Activity
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java Adopted from Boem
Limitations of Waterfall and Spiral
Models
• Neither of these model deals well with frequent
change
– The Waterfall model assume that once you are done
with a phase, all issues covered in that phase are closed
and cannot be reopened
– The Spiral model can deal with change between phases,
but once inside a phase, no change is allowed
• What do you do if change is happening more
frequently? (“The only constant is the change”)
Unified Software Development Process
(UP)
• Repeats over a series of cycles
Birth Death
Cycles conducted with a release
• Each cycle consists of four phases which are

subdivided into iterations
Inception Elaboration Construction Transition

Iteration Iteration ... ... ... ... ... ... ... Iteration Iteration
No1 No2 No n-1 No n
Unified process
• Inception – establishes a business case for the
system
• Elaboration – most of the product cases are
specified in details, architecture is designed
• Construction – the product is built. The
architectural baseline becomes a full-pledged
system
• Transition – period when product moves to beta
release
(UP)
• UP organizes projects in two-dimensional terms
• The horizontal dimension represents the
successive phases of each project iteration:
– inception,
– elaboration,
– construction, and
– transition.
• The vertical dimension represents software
development disciplines and supporting activities
of configuration and change management, project
management, and environment.
Workflows
• Cross-functional
– Management – planning aspects
– Environment – automation of the process itself
– Assessment – assesses processes and products needed for
reviews
– Deployment – transition of the system
• Engineering
– Requirements
– Design
– Implementation
– Testing
An iteration in the elaboration phase
Inception Elaboration Construction Transition

Iter.#1 Iter.#2 Iter.#... Iter.#... Iter.#... Iter.#... Iter.#... Iter.#n-1 Iter.#n
Management Workflow
Environment Workflow
Requirements Workflow
Design Workflow
Implementation Workflow
Assessment Workflow
Deployment Workflow
Time
From Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java adopted from Jacobson
UP vs. Waterfall
Waterfall
Risk
seriousness
Inception
Waterfall integration and
test period
Elaboration
Construction
Transition time
Iter.#1 Iter.#2 Iter.#... Iter.#... Iter.#... Iter.#... Iter.#... Iter.#n-1 Iter.#n
Formal software development
models
• deductive methods,
which uses automatic deduction of a proof of
solvability of a problem and derives a program
from the proof
• transformational methods,
where a program is derived stepwise from a
specification by means of transformations
• inductive methods,
where a program is built on the basis of input-
output pairs or examples of computations
Inductive synthesis - Basic
notions (Program specification)
• The expression "programming by examples" is
taken to mean the act of specifying a program by
means of examples of the program behavior
• Examples consisting of expressions representing
an input and output
– (A B C) → C
– (A B) → B,
(A B C) → B,
(A B C D) → B
Program specification
• A single example indicates a specific
transformation or computation that must be
duplicated by any program defined by the
examples
• For any finite set of examples there are an infinite
number of programs that behave like the
examples.
• Program satisfies or is defined by a set of
examples if it produces the examples output when
applied to the examples input for all examples in
the specifying set.
General methods (search)
• A fundamental method of inductive
inference is to search in some systematic
way through the space of possible programs
(rules)
• Possible program should be agree with all
examples
General methods (search)
• Basic advantage of search is that it is a
general method and does not depend much
on domain-specific knowledge
• Basic disadvantage of search is that in a

general case it can be very inefficient
Deductive Synthesis
It is based on the observation that constructive
proofs are equivalent to programs because
each step of a constructive proof can be
interpreted as a step of computation.
The way from a problem to
program
Problem in source form
Problem represented in a formal theory
Proof of solvability of the problem
Program
Deductive synthesis problem
• suppose that program to be derived takes an
input x and produces an output y
• suppose that specification of the program
states that a precondition P(x) should be
true of the input and that a post-condition
Q(x,y) should be true of the output
• then the theorem to be proven is
∀x ∃ y[P(x) →Q(x,y)]
Structural synthesis of programs
The idea of Structural Synthesis of Programs
(SSP) is that a proof of solvability of a
problem can be built and that the overall
structure of a problem can be derived from
the proof, knowing very little about
properties of the functions used in the
program
Logical language of SSP (LL-language)
• Propositional variables (begin with capital letters):
A, B, C, D, Ai, Ai ....
• Unconditional computability statements:
A1 & ... & Ak → B
we also use A as an abbreviation for A1 & ... & Ak
• Conditional computability statements
(A1 → B1 ) & ... & (An → Bn ) →(C → D)
we also use ( A → B) as an abbreviation for
( A1 → B1 ) & ... & (An → Bn ).
Informal meaning
A1& ... &Ak → B has two meanings
• Logical meaning "A1,..., Ak implies B",
where A1,..., Ak, B - propositional variables
• Computational meaning ”B is computable
from A1,..., Ak"
A1,..., Ak, B - computational objects
Computational meaning of the LL formulae
• Propositional variables of LL correspond to object
variables from the source problem description
language (specification language).
• An unconditional computability statement A → B
expresses a computability of the value of the
object variable b corresponding to B from values
of a1... ak corresponding to A.
• A conditional computability statement, e.g.
(A → B) → (C → D) expresses computability of
the object variable d from c depending on other
computations, here depending on the computation
of the object variable b from a.
Structural synthesis rules (SSR)
• Σ |– A → V Γ |– A
(→ -)
Σ , Γ |– V
where Γ |– A is a set of sequents for all A in A
• Γ, A |– B
(→ +)
Γ |– A → B
• Σ |– (A → B) → (C→ V); Γ, A |– B; ∆ |– C
(→ --)
Σ , Γ , ∆ |– V
where Γ, A |– B is a set of sequents for all A → B in
(A → B), and ∆ |– C is a set of sequents for all C in
C.
SSR1 inference rules
Σ |– A →f V ; Γ |– A(a)
(→ -)
Σ, Γ |– V(f(a))
Γ, A |– B(b)
(→ +)
Γ |– A →λ a.b B
Σ|–(A→g B)→(C →F V); Γ, A|–B(b); ∆|–C(c)

(→ - -)
Σ, Γ ,∆ |– V(F(λ a.b, c))
Example. Modeling logical circuits
Class inverter
inverter: (in,out: bool;
finv: in → out (finv))
Corresponding set of formulae
INVERTER.IN →finv INVERTER.OUT,
INVERTER.IN & INVERTER.OUT →constr( )
2
INVERTER,
INVERTER →select INVERTER.IN,
1
INVERTER →select2 INVERTER.OUT

• Class and
and:(in1, in2, out:bool;
fand:in1, in2 → out (fand))
AND.IN1 & AND.IN2 →fand AND.OUT,
AND.IN1 & AND.IN2 & AND.OUT →constr AND,
3
AND →select AND.IN1, AND →select AND.IN2,

1 2
AND →select AND.OUT

3
• Class nand
nand: (in1,in2,out: bool;
a: and in1 = in1, in2 = in2;
i: inverter in = a.out, out=out;
fnand: in1,in2 → out);
IN1 →eq1 A.IN1, A.IN1 →eq2 IN1, IN2 →eq3 A.IN2,
A.IN2 →eq4 IN2, I.IN →eq5 A.OUT, A.OUT →eq6 I.IN,
I.OUT →eq7 OUT, OUT →eq8 I.OUT,
A.IN1 & A.IN2 →a.fand A.OUT, I.IN →i.finv I.OUT,
A → select1 A.IN1, A → select2 A.IN2, A → select3 A.OUT,
IN1 & IN2 & OUT → constr3 A, I.IN & I.OUT →constr2 I,
I → select1 I.IN, I → select2 I.OUT, IN1 & IN2 → OUT
(inference)
IN1 IN2
eq1 eq3
A.IN1 A.IN2
a.fand
A.OUT
eq6
I.IN
i.inv
I.OUT i.inv
eq7
OUT
Extracted program
fand:out=eq7(i.finv(eq6(a.fand(eq1(in1), eq3(in2))))
or fand: λin1 in2. (i.finv(a.fand(in1, in2)))
Example - Logical circuits (new)
&
X1 ¬ 1
Class SCHEMA
var X1, X2, X3, X4: any; X3 ¬ & X2 ¬
i1: Inverter in = X1;
i2: Inverter in = X2; X4 &
i3: Inverter in = X3;
a1: NAND in1 = t1.Q1, in2 = i1.out;
a2: NAND in1 = i3.out, in2 = a3.out;
a3: AND in1 = X4, in2 = t1.Q2;
t1: D_latch S=1,D=i2.out, C=a2.out,R=a1.out;
alias Y = t1.result;
rel problem: X1, X2, X3, X4 -> Y {spec};
Problem Solving in the SSP Systems
(Geometry)
s2
Figure
var area:numeric;
s1:SQUARE; s1
s2:SQUARE side = s1.diagonal;
Set of solvable problems:

s1.side → s1, s2; s2.side → s1, s2;
s1.diagonal s2; s1.side area; s2.side → area;
...
Transformational model
Formal Development Process
Formal
Specification Transform 1 Code
System Requirements System

(maybe informal and incomplete)
Adopted fromPfleger&Atlee
Deductive and Transformational
Synthesis
• Both of them are based on deduction, however,
they use different deduction methods.
• Synthesis is usually based on inference, whereas
transformation is usually based on replacement.
• Inference means the axioms and rules supplied to
the program derivation system are expressed as
implications, and the logical operations of the
system derive either necessary conclusions or
premises of sufficient antecedents of goals.
• Replacement means that the axioms supplied to
the system are expressed as equations or rewrite
rules, and the logical operations replace
expressions by other equivalent expressions.
Correctness of transformations
• Let SP0 be a specification of the requirements which
the software system is expected to fulfill, expressed
in some formal specification language SL.
• The ultimate objective is a program P written in
some programming language PL which satisfies the
requirements in SP0.
• The main idea is to develop P from SP0 via series of
small refinement steps
SP0 → SP1 →... → P
• If each individual refinement step (SP0 → SP1, SP1
→ SP2,...) can be proved to be correct then the
resulting program P is guaranteed to be correct.
The notions of the "correctness of transformations" have to
be based on suitable relations between programs. Given
such a relation ϕ , the transition from a program P to
another program P' then is said to be correct iff P ϕ P'
holds.
• Some relations which are reasonable in connection with
program transformations:
– P and P' have to be "equivalent"
– Weakening condition for “equivalence”: the
equivalence of P and P' is only required if P is defined
– For nondeterministic programs, it may suffice that P'
is included in P, - that the possible results of P' form a
subset of possible results of P.
Relation ϕ has to fulfill the following requirements:
• it has to be reflexive, since the identity should be a
valid transformation;
• it has to be transitive in order to allow the
successive application of several transformations
• if there is the local application of transformation to
a (small) part Q of a program P, then the validity
of Q ϕ Q' only implies the validity of P ϕ P', if the
relation is monotonic for the constructs of the
language (where P' = P[Q'/Q]).
The formalization of relations has to refer to the actual
semantic definition of the programming language under
consideration (for example):
• In denotational semantics the meaning of program is
specified with help of a function M mapping programs to
semantic object.
Two programs P1 and P2 then can be defined to be
equivalent iff M(P1) = M(P2).
• In operational semantics two programs may be regarded
equivalent iff they lead to the same sequences of
"elementary" actions.
Model-driven architecture
(MDA)
• a software design approach for the development
of software systems.
• provides a set of guidelines for the structuring
of specifications, which are expressed as
models.
• a kind of domain engineering, and supports
model-driven engineering of software systems.
• launched by the Object Management Group
(OMG) in 2001 Adopted from Alan Brown
The principles of MDA (from
OMG)
• Models expressed in a well-defined notation are a cornerstone to
understanding systems for enterprise-scale solutions.
• The building of systems can be organized around a set of models by
imposing a series of transformations between models, organized into
an architectural framework of layers and transformations.
• A formal underpinning for describing models in a set of metamodels
facilitates meaningful integration and transformation among models,
and is the basis for automation through tools.
• Acceptance and broad adoption of this model-based approach requires
industry standards to provide openness to consumers, and foster
competition among vendors.
Model-Driven Architecture (MDA)
PIM Transformation
Platform Independent Techniques
Model (PIM)
Transformations/
Mappings
PSM Transformation
Platform Specific
Techniques
Model (PSM)
Metamodel tranformation
From MDA Guide Version 1.0.1

Model tranformation
From MDA Guide Version 1.0.1

Model Driven Development
• Developer develops model(s)
based on certain
metamodel(s).
• Using code generation
templates, the model is
transformed to executable
code.
• Optionally, the generated
code is merged with
manually written code.
• One or more model-to-model
transformation steps may
precede code generation.
Adopted from Alan Brown

Model Driven Architecture
Customer requirements Mostly text
Analysis Platform
Independent
Model (PIM)
Design
Platform PSM Platform
Specific bridge Specific
Model (PSM) Model (PSM)
Coding
Code
Code bridge Code
Testing
Deployment
How much Planning?
• Two styles of navigation [Gladwin 1964]
– European navigation
– “Polynesian navigation”
“European Navigation”
Planned Route
Lima
(Current Location)
Auckland
(Desired Location)
Actual Route
Event: Course deviation.

Action: Course correction
Polynesian Navigation
“We need a new place

for living.
Let’s go to Auckland”
Lima
(Current location)
Event: “Birds seen”
Action: “Follow the birds”
Tahiti
(Empty island, great
place for Living)
Auckland Project Plan (European Navigation)
• Project Goal: Auckland
• Desired Outcome: Auckland is found
• Team: Captain and 50 sailors
• Organization: Flat hierarchy
• Tools: Compass, speed meter, map
• Methods: Determine planned course, write planned course
before departure. Example: Start Lima. Sail West, keep the
compass constantly at 97 degrees, stay at latitude 20 degrees
• Work breakdown structure
• Task T1 (Check direction): Determine current direction of ship
• Task T2 (Compute deviation): Determine deviation from desired course
• Task T3 (Course Correction): Bring ship back on course
• Process:
– T1 and T2 are executed hourly. If there is a deviation, T3 is executed to
bring the ship back on the planned course.
• Schedule: With good wind 50 days, if doldrums are
encountered, 85 days.
Auckland Project Plan (Polynesian Navigation)
• Project Goal: Auckland
• Desired Outcome: A new place for living is found
• Team: Captain and 50 sailors
• Organization: Flat hierarchy
• Tools: Use stars for navigation, measure water temperature with hand
• Methods: Set up a set of event-action rules. When an event occurs,
determine the action to be executed in the given context.
• Work breakdown structure
– Task T1 (Determine direction): Set direction of ship to a certain course
– Task T2 (Check Clouds): Look for non-moving clouds in the distance
– Task T3 (Check Birds): Look for birds and determine their direction
– Task T4 (Compute course): Determine new course for ship
– Task T5 (Change course): Change direction to follow new course
• Process:
– Start with T1. Tasks T2 and T3 are executed regularly. The result (cloud
detected, birds detected, nothing happened) is interpreted in the current
context. If the interpretation makes a new course more promising, execute task
T4 and T5.
• Schedule: None Adopted from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
Situated action
• Situated action [Suchman 1990]
– Selection of action depends on the type of event, the situation and the
skill of the developer. Also called context-dependent action.
• Examples of navigation events: “Course deviation”, “Birds
seen”, “Clouds seen”.
• European Navigation is context independent:
– Event: “Course deviation in the morning”
• Action: “Course correction towards planned route”
– Event: “Course deviation in the evening”
• Action: “Course correction towards planned route”
• Polynesian Navigation is context dependent:
– Event: “Birds seen”, Context: Morning
• Action: “Sail opposite to the direction the birds are flying”
– Event: “Birds seen”, Context: Evening
• Action: “Sail in the direction the birds are flying
Agile software development
Key points of agility in software production:
• Individuals and interactions over processes
and tools
• Working software over comprehensive
documentation
• Customer collaboration over contract
negotiation
• Responding to change over following a plan
Adopted from: http://agilemanifesto.org/

Agile Development
Test-driven
Refactoring
development
Acceptance Continuous
tests integration
User
stories
Adopted from XPExplored, by Wake

Summary
• Software engineering is a modeling, problem-solving activity, knowledge
acquisition activity and rationale-driven activity.
• Dealing with complexity:
• Abstraction
• Decomposition
• Hierarchy
• Software Engineering activities
– Analysis
• Requirements elicitation
• Requirements analysis
– Design
• System design –
• Object design
– Implementation
– Testing
• Software Development Life Cycle
– Waterfall
– Incremental
– Spiral/UP
– Formal methods
– Agile methods
Next lecture
• UML
Chapter 2 in the text-book.

Introduction 2010

Caricato da

Informazioni sul documento

Descrizione originale:

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Introduction 2010

Caricato da

Copyright:

Formati disponibili

Modern Methods in

• To get practice in Agile Programming approach

Apply some elements of Extreme programming approach to

Provide an analysis and comparison of your experience to

The project must be done by groups of 2 students

– associated data that is needed to make the programs

Adopted from Lethbridge and Laganière.

Adopted from Charette 1989

– average cost overrun = 189% 31% budget, over-schedule

• In 2003 , it is 34% of projects

• quantifiable implies measurement

Issue Model Task Models

„Buy Material“ must

Install Install Install

Person-Centered View Activity-Centered View

A3 Clara, Toby, Joe

Read Process Output Level 1 functions

Load R5 Add R1, R5

Mouse Change Draw

Change Change Change

Draw Draw Draw

I/O Devices CPU Memory

Cache ALU Program

Muscle Cell Blood Cell Nerve Cell

Striate Smooth Red White Cortical Pyramidal

WorkProduct * Task * Resources

System Design What is the solution?

What is the solution in the context

Implementation How is the solution constructed?

• Describes a set of activities and processes

Pre- Develop- Post- Cross-

Implementation Project Documentation

Operation S/W Quality

analysis design implementation deployment

analysis design implementation deployment

analysis design implementation deployment

Integration Design Unit Test

Life cycle Planning

Cycles conducted with a release

• Each cycle consists of four phases which are

Inception Elaboration Construction Transition

Inception Elaboration Construction Transition

• Basic disadvantage of search is that in a

Problem represented in a formal theory

Proof of solvability of the problem

Σ|–(A→g B)→(C →F V); Γ, A|–B(b); ∆|–C(c)

INVERTER →select2 INVERTER.OUT

AND →select AND.IN1, AND →select AND.IN2,

AND →select AND.OUT

Set of solvable problems:

System Requirements System

From MDA Guide Version 1.0.1

From MDA Guide Version 1.0.1

Adopted from Alan Brown

Event: Course deviation.

“We need a new place

Adopted from: http://agilemanifesto.org/

Adopted from XPExplored, by Wake

Chapter 2 in the text-book.

Potrebbero piacerti anche