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 [email protected] tel. 08-790 41 28
Assignments and project responsible • Siskos Filotas (Course assistant)
E-mail [email protected] • Nikolaos Stanogias (Course assistant)
E-mail [email protected] Lectures & Exercises:
see schedule Written examination ( 4.5 p.)
October 29 at 09:00-13:00 Registration at least 21 days before exam period
Homework and project assignments (3 p.)
Homework
Start Date Due Date Description 2014-09-08 2014-09-15 Homework 1 2014-09-15 2014-09-23 Homework 2 2014-09-23 2014-09-30 Homework 3 2014-09-30 2014-10-07 Homework 4
It is assumed that the Homework are done by groups of 2 students
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 a system for insurance claim processing
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 Homework 1,2,3,4 in due time gives 5
bonus points to written exam (this assumes that all Homework are approved)
2. In case of Late Submission of any Homework, No bonus points will be awarded for the “in-time submission of homework”.
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 29
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 Forum book store)
• Lecture notes • Additional articles in the curriculum will be added
during the course
Very Tentative Lecture Plan Date Lecture
1 01.09.2014 Introduction and Software Lifecycles 2 02.09.2014 UML Basics
3 05.09.2014 Requirements Elicitation 4 09.09.2014 Requirements Analysis
5 12.09.2014 System Design 6 16.09.2014 Object Design (reuse) 7 19.09.2014 Object Design (Interface Design) 8 25.09.2014 Move to code, Testing 9 26.09.2014 Extreme Programming and other Agile methods 10 01.10.2014 Guest lecture
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 lifecycles
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 – untrained people can hack something together – 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
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 common reasons
• Seldom occurring situations are not taken into account
• Users can actively misusing systems • 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.
– 8,380 projects
• In 1994 only 16.2% of software projects were completed on-time and on-budget (for large and complex systems it is 9%)
– average time overrun = 222%. – average cost overrun = 189% – 61% of originally specified features
included
• In 2003 , it is 34% of projects completed on-time and on-budget
Project completion
16%
31%
53%
On time, on budget,with all of the specifiedfeatures and functions
Cancelled before theywere completed
delivered andoperational but over-budget, over-scheduleor with fewer featuresand functions thanspecified
Software nature (summarizing)
• 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
What is Software Engineering?
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
What is Software Engineering?
• 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.
What is Software Engineering?
• 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 general 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
Adopted from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
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 implemented change erodes the structure of the
system which makes next change more expensive – the cost of implementing changes grows in time
Adopted from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
How to deal with complexity?
• Abstraction -- Ignore non-essential details - modeling
• Decomposition -- Break problem into sub-problems
• Hierarchy -- Simple relationship between chunks
Adopted from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
Abstraction/Modeling • System Model:
– Functional model: What are the functions of the system? How is data flowing through the system?
– Object Model: What is the structure of the system? What are the objects and how are they related?
– 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? Adopted from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
Abstraction/Models System Models
Issue Model Task Models
PERT Chart
Org Chart Constraints
Issues Proposals
Arguments
Object Model
Functional Model
Dynamic Model class...!class...!class...!
Code
Pro Con
Forward Engineering Reverse Engineering
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
Building a House (Dependency Graph)
START!
Request !
Survey!ing!!
Excava!tion!
Buy !Material! Founda!
tion!!
Build !Outside !
Wall!
Install !Exterior !Plumbing!
Install !Interior !Plumbing!
Install !Exterior !Electrical!
Install !Interior !
Electrical!
Install !Exterior !
Siding!
Install !Wallboard!
Paint !Exterior!
Install !Roofing!
Install!!Flooring!
Paint !Interior!!
Install !Interior !
Doors!
Install !Exterior !
Doors!
FINISH!
The activity!„Buy Material“ must !Precede the activity!„Lay foundation“!
Lay !
Adopted from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
Gantt Chart
Time (in weeks after start)!
Activity 1!
Activity 2!
1! 2! 3! 4! 5! 6! 7!0!
Activity 3!
Activity 4!
Activity 5!
Easy to read Adopted from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
Gantt Chart with milestones
Time (in weeks after start)!
Activity 1!
Activity 2!
1! 2! 3! 4! 5! 6! 7!0!
Activity 3!
Activity 4!
Activity 5!
Project Start!
Project Finish!
Good for reviews.
Design Review!
Adopted from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
Types of Gantt Charts
Person-Centered View To determine people‘s load
Activity-Centered View To identify teams working
together on the same tasks
Time! Time!
Joe!
Mary!
Toby!
Clara!
A1! A3!Joe, Toby!
A1! A3!
A1!
A2!
A3!
Joe!
A2!
Clara, Toby, Joe!A3!
Adopted from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
Issue Model Issue:
What is the Center of the
Universe?
Proposal1: The earth!
Proposal2: The sun!
Pro: Copernicus
says so. Pro:
Aristotle says so.
Pro: Change will disturb
the people.
Con: Jupiter’s moons rotate
around Jupiter, not around Earth.
Resolution (1615): The church
decides proposal 1 is right
Resolution (1998): The church declares
proposal 1 was wrong
Adopted from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
Pro: New scientific
knowledge.
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
Adopted from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
Functional Decomposition
Level 1 functions
Level 2 functions
System Function
Load R5 Add R1, R5
Read Process Output
Process Output Read
Adopted from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
Functional decomposition Autoshape
Draw Rectangle
Draw Oval
Draw Circle
Draw Change Mouse click
Change Rectangle
Change Oval
Change Circle
Adopted from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
Object decomposition
Rectangle
Draw Change
Shape
Oval
Draw Change
Circle
Draw Change
Object-Oriented Decomposition
Eskimo Size
Dress() Smile() Sleep()
Shoe Size
Color Type
Wear()
*!Coat Size
Color Type
Wear()
Indian Hair
Dress() Smile() Sleep()
Mouth NrOfTeeths Size open() speak()
*!Ear Size listen()
Face Nose smile() close_eye()
Adopted from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
Modeling Briefcase
Capacity: Integer Weight: Integer
Open() Close() Carry() SitOnIt()
Adopted from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
BriefCase Chair
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
Adopted from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
Part-of hierarchy Computer!
I/O Devices! CPU! Memory!
Cache! ALU! Program! Counter!
Adopted from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
Is-a-kind-of hierarchy Cell!
Muscle Cell! Blood Cell! Nerve Cell!
Striate! Smooth! Red! White! Cortical! Pyramidal!
Adopted from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
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
Adopted from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
Software Engineering Concepts (resources)
• Resources include time, equipment and participants • 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
Software Engineering Concepts (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
Software Engineering Concepts (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
consumes
Activity
WorkProduct Resources Task
Equipment
Time
Participant
Document
Model
System
is produced by *
*
* *
Project
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java - adopted from OMG
Possible SE activities - Simplified view
Problem Domain
Implementation Domain
Requirements Analysis What is the problem?
System Design What is the solution?
Object Design What is the solution in the context of an existing hardware system?
Implementation How is the solution constructed?
Adopted from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
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
Adopted from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
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 scheduled?
– Should analysis precede design? – Can analysis and design be done in parallel? – Should they be done iteratively?
Adopted from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
Software Life-cycle
• Life-cycle differs between projects • Different experience and skills • Different application domains • Environment changes • Project size
Software Life-Cycle
Development Post- Development
Pre- Development
Conception Childhood Adulthood Retirement
Adopted from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
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
Adopted from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
IEEE 1074: Standard for Developing Software Lifecycle Processes
• 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 – ....
Adopted from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
IEEE 1074: Standard for Developing Software Lifecycle Processes
• Process Group: Consists of Set of Processes • Process: Consists of Activities • Activity: Consists of sub activities and tasks
Process Group
Process
Activity
Development
Design
Task
Design Database
Make a Purchase
Recommendation Adopted from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
IEEE 1074: Standard for Developing Software Lifecycle Processes
Adopted Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
IEEE 1074
Project Management
Pre- Development
Develop- ment
Post- Development
Cross- Development
(Integral Processes)
> Project Initiation >Project Monitoring &Control > Software Quality Management
> Concept Exploration > System Allocation
> Requirements Analysis > Design > Implemen- tation
> Installation > Operation & Support > Maintenance > Retirement
> V & V > Configuration Management > Documen- tation > Training
Process Group
Processes
Life Cycle Modeling
> Selection of Life Cycle model
Project Management Process Group
Project Management
Project Monitoring & Control
Software Quality
Management
Ø Map Activities to Software Life Cycle Model Ø Allocate Project Resources Ø Establish Project Environment Ø Plan Project Management
Ø Analyze Risks Ø Perform Contingency Planning Ø Manage the Project Ø Retain Records Ø Implement Problem Reporting Model
Project Initiation
Ø Plan Software Quality Mesurement Ø Define Metrics Ø Manage Software Quality Ø Identify Quality Improvement Needs
Adopted from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
IEEE 1074 standard.
Verification & Validation
Process
Configuration Management Process
Documentation Development
Process
Training Process
Project Monitoring
&Ctrl Process
S/W Quality Management Process
Project Initiation Process
Operation & Support Process
Maintenance Process
Design Process
Concept Exploration
Process
System Allocation Process
Requirements Process
Implementation Process
Installation Process
Retirement Process
Development processes Management processes Integral processes
Adopted from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
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 Adopted from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
What do we want? Requirements!
Software!
Implementation
Design
Testing
Adopted from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
Waterfall Model
Requirements Process
System Allocation Process
Concept Exploration Process
Design Process
Implementation Process
Installation Process
Operation & Support Process
Verification & Validation
Process
Adopted from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
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
Adopted from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
Waterfall model with prototyping
System Design
Requirements Analysis
Requirements Engineering
Object Design
Implementation Process
Installation Process
Operation & Support Process
Verification & Validation
Process
Prototyping
V- model !
System Design
Requirements Analysis
Requirements Engineering
Object Design
Integration Testing
System Testing
Unit Testing
Implemen- tation
System Testing
Unit Testing
Integration Testing
Acceptance
Copyright 2002 Bernd Brügge Software Engineering II, Lecture 3: Scheduling SS 2002
V-Model precedes
Is validated by
Copyright 2002 Bernd Brügge Software Engineering II, Lecture 3: Scheduling SS 2002
System Design
Requirements Analysis
Requirements Engineering
Object Design
Implemen- tation
System Testing
Unit Testing
Integration Testing
Acceptance
Incremental model
analysis design implementation deployment
Feat
ures
and
func
tiona
lity
Time
analysis design implementation deployment
analysis design implementation deployment
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
Adopted from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
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 Adopted from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
Spiral model Rounds/cycles • Concept of Operation, • Software Requirements, • Software Product Design, • Detailed Design, • Code, • Unit Test, • Integration and Test, • Acceptance
• For each cycle go through these activities – Quadrant IV: Define objectives,
alternatives, constraints – Quadrant I: Evaluate alternative,
identify and resolve risks – Quadrant II: Develop, verify
prototype – Quadrant III: Plan next “cycle”
IV Determine objectives IV Specify constraints IV Generate alternatives I Identify risks I Resolve risks II Develop and verify prototype III Plan
Adopted from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
Spiral model
Project progress
Define Objectives Risk analysis
Customer evaluation and next round planning
Prototyping
“continue, not-continue” decision
Project cost
Spiral Model Determine objectives,alternatives, & constraints
Evaluate alternatives,identify & resolve risks
Develop & ver ifynext level productPlan next phase
Requirements
Development
Integration
pla n
pla n
pla n
Requirements
Design
validation
validation
Software SystemProduct
Riskanalysis
Riskanalysis
Prototype1Prototype2
Prototype3
Riskanalysis
Concept ofopera tion
RequirementsDesign
Code
Unit Test
Integration & TestAcceptance
DetailedDesign
P1
P2
Test
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java Adopted from Boem
Start Project Risk Analysis
activity
Development system product Activity
Requirements and Life cycle Planning
Start New Round
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”)
Adopted from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
Unified Software Development Process (UP)
• Repeats over a series of cycles
• Each cycle consists of four phases which are subdivided into iterations
Birth Death
Cycles conducted with a release
Inception Elaboration Construction Transition Iteration
No1 Iteration
No2 Iteration No n-1
Iteration 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
Unified Software Development Process (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
Unified Software Development Process
Implementation Workflow
Management Workflow
Requirements Workflow
Design Workflow
Deployment Workflow
Inception Elaboration Construction Transition
Assessment Workflow
Environment Workflow
Time
Iter .#1 Iter .#2 Iter .#... Iter .#... Iter .#... Iter .#... Iter .#... Iter .#n-1 Iter .#n
From Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java adopted from Jacobson
An iteration in the elaboration phase
UP vs. Waterfall
Iter .#1 Iter .#2 Iter .#... Iter .#... Iter .#... Iter .#... Iter .#... Iter .#n-1 Iter .#n time
Risk seriousness
Inception
Elaboration
Construction
Transition
Waterfall
Waterfall integration and test period
Formal software development models • inductive methods,
where a program is built on the basis of input-output pairs or examples of computations
• 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 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 →select1 INVERTER.IN, INVERTER →select2 INVERTER.OUT
Example. Modeling logical circuits • Class and
and:(in1, in2, out:bool; fand:in1, in2 → out (fand))
Corresponding set of formulae AND.IN1 & AND.IN2 →fand AND.OUT, AND.IN1 & AND.IN2 & AND.OUT →constr3 AND, AND →select1 AND.IN1, AND →select2 AND.IN2, AND →select3 AND.OUT
Example. Modeling logical circuits • Class nand
nand: (in1,in2,out: bool; a: and in1 = in1, in2 = in2; i: inverter in = a.out, out=out; fnand: in1,in2 → out);
Corresponding set of formulae 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
Example. Modeling logical circuits (inference)
IN1 IN2 A.IN1 A.IN2 A.OUT I.IN I.OUT i.inv OUT
Extracted program fnand: out=eq7(i.finv(eq6(a.fand(eq1(in1), eq3(in2)))) or fnand: λin1 in2. (i.finv(a.fand(in1, in2)))
eq1 eq3
a.fand
eq6
eq7
i.inv
Example - Logical circuits (new) Class SCHEMA var X1, X2, X3, X4: any;
i1: Inverter in = X1; i2: Inverter in = X2; 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.Q1; rel problem: X1, X2, X3, X4 -> Y {spec};
1
&
&
&
¬
¬ ¬
X1
X2 X3
X4
Problem Solving in the SSP Systems (Geometry)
Figure var s1:SQUARE; s2:SQUARE side = s1.diagonal;
SQUARE
var side, square, diagonal:numeric; rel area= side^2; diagonal^2 = 2*side^2;
Set of solvable problems:
s1.side → s1, s2; s2.side → s1, s2; s1.diagonal → s1, s2; s1.area→ s1, s2; s2.diagonal→ s1, s2; . . .
s1
s2
Transformational model
Formal Specification
System Requirements (maybe informal and incomplete)
Transform 1 Code
System
Formal Development Process
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.
Correctness of transformations 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.
Correctness of transformations
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]).
Correctness of transformations
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)
Platform Independent Model (PIM)
Platform Specific Model (PSM)
Transformations/ Mappings
PIM Transformation Techniques
PSM Transformation Techniques
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
Analysis
Design
Coding
Mostly text
Platform Independent Model (PIM)
Platform Specific
Model (PSM)
Code
Platform Specific
Model (PSM)
Code
PSM bridge
Code bridge
Customer requirements
Testing
Deployment
How much Planning?
• Two styles of navigation [Gladwin 1964] – European navigation – “Polynesian navigation”
Adopted from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
“European Navigation”
Event: Course deviation.
Auckland (Desired Location)
Lima (Current Location)
Planned Route
Actual Route
Action: Course correction
Adopted from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
Polynesian Navigation
Event: “Birds seen”
Lima (Current location)
“We need a new place for living.
Let’s go to Auckland”
Tahiti (Empty island, great
place for Living)
Action: “Follow the birds”
Adopted from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
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.
Adopted from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
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 [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
Situated action
Adopted from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
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
Refactoring
Continuous integration
User stories
Acceptance tests
Test-driven development
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.