Presentation is loading. Please wait.

Presentation is loading. Please wait.

CS223 Introduction to Software Engineering

Similar presentations

Presentation on theme: "CS223 Introduction to Software Engineering"— Presentation transcript:

1 CS223 Introduction to Software Engineering
Doron Peled, Roger Packwood, Arshad Jhumka, Ananda Amatya, Mike Joy © The University of Warwick

2 Lecture 1 - Objectives To introduce the staff
To explain the structure of the module To describe what Software Engineering is about

3 Staff Doron Peled Roger Packwood Arshad Jhumka Ananda Amatya Mike Joy

4 Timetable Lectures Weekly, weeks 1-10 Twice weekly, weeks 11-15
“Surgeries” Weeks 6-19 Attend if you have any problems, or just questions you wish to ask

5 Assessment Exam (30%) Group Project (70%)
Handout Wednesday 27 October (week 5) deadline (part 1) Thursday 27 January (end week 14) deadline (part 2) Thursday 10 March (end week 20)

6 Themes General Software Engineering (Roger) UML (Ananda)
Design Patterns (Arshad) Project Management (Doron) Formal Methods (Doron) Coding Issues (Mike) Software Engineering in Industry (IBM)

7 Lectures - Term 1 1 DP/RAP/AJ/AA Introduction
2 RAP The Software Process 3 RAP Software Specification 4 AA UML: Overview 5 DP/RAP/AJ/AA The Project + Tools 6 AA Requirements (Use Case Modelling) 7 AA Analysis (Static & Dynamic Modelling) 8 AJ Analysis To Design + Case Study (part 1) 9 AJ Object Design + Case Study (part 2) 10 MSJ Coding Issues

8 Lectures - Term 2 (provisional)
11 RAP Software Cost Estimation 12 AJ Further Design + Case Study (part 3) 13 DAP Formal Methods (1): Introduction 14 DAP Formal Methods (2): Testing & Reliability 15 IBM Team Based Software Development 16 IBM Development Focus Areas & Practices 17 RAP Safety-Critical Systems 18 RAP Software Testing 19 RAP Software Reliability 20 AA Methodologies (XP)

9 Booklist See handout for ISBN, cost, etc. Recommended
Bruegge and Dutoit General Pressman and Ince Sommerville UML Bennett, Skelton and Lunn (Schaum) Booch, Jacobson and Rumbaugh Fowler and Scott Others

10 General Software Engineering
Over to Roger ...

11 The Software Process Why is there a Software Process ?
why not just write the program ? What the customer wants how it is implemented, or at least designed change, for the better, sometimes ... Why is software "engineering" hard ? what solutions does "engineering" offer ? The traditional software lifecycle other development models

12 Software Specification
"What" needs to be specified many people communicate via written documents A specification that the customer can agree to a specification for the programmer (one of many) Many aspects (views) of a software design Complete, Concise, Testable

13 Software Cost Estimation
Before we even start, do we want the job ? Need to estimate - how much effort how much time how much money Primarily based on how much last time model based Constructive Cost Model COCOMO Mythical Man Month - Brooks

14 Safety-Critical Systems
Developing software that should never compromise the overall safety of a system Reliability is with respect to specification safety is independent of specification Therac and Arianne examples Risk analysis intolerable As Low As Reasonably Practical (ALARP) acceptable The Myths of Software Safety

15 Software Testing A successful test finds a fault
testing does not prove the absence of faults White Box, Black Box testing Coverage testing, Exhaustive testing can you trust the test software? Test data values, Corner Cases, Fencepost errors mistyped variable names, operators, constructs Unit test, integration test, System, Alpha, Beta top-down, Bottom-up, Inside-out, Sandwich ??

16 Software Reliability Availability, Reliability, Safety, Integrity, etc. Defects, Density and Zero Fault Tolerance, N-Way, Recovery Blocks, Diversity Dangerous Programming

17 OOD & UML Over to Ananda ...

18 Warwick Bookshop: In stock
Bernd Bruegge, Adjunct, Carnegie Mellon University Allen H. Dutoit, Technical University of Munich ISBN: Publisher: Prentice Hall Copyright: Paperback 762 pages (November 30, 2003) Price: £35.99 Warwick Bookshop: In stock K2, 8611m, Karakoram range of Western Himalayas. 2nd highest peak, success rate < 40%

19 Objectives (with lecture & suggested reading plan)
Understand System Modelling Learn UML (Unified Modelling Language) (Lecture 4: BD ch. 2) Learn different modelling methods: Use Case modelling (Requirements Elicitation) (Lecture 6: BD ch. 4) Static & Dynamic modelling (Domain Analysis) (Lecture 7: BD ch. 5) Learn how to use Tools: CASE (Computer Aided Software Engineering) Tool: IBM Rational Rose (Lecture 5: with Project Lecture) Learn Software Development Methodologies: (Lecture 20: BD ch. 16) Rational Unified Process Agile Process (XP) The term Software Engineering was coined in 1968: developing quality software on time and within budget Setting concrete objectives Estimating resources necessary to attain the objectives Meeting customer expectations Software Engineering is a modelling activity: overcoming complexity by focussing on what is relevant Software Engineering is a problem solving activity: acceptable solutions with resource constraints (budget, deadline) Software Engineering is a knowledge acquisition activity: collect data, organize it into information, and formalize it into knowledge, iteratively Software Engineering is a rationale driven activity: decision making context and rationale

20 Factors affecting the quality of a software system
Complexity: System too complex for a single programmer to comprehend; Fixing one bug introduces another bug. Change: Entropy of a software system increases with each change: Change in a system alters its structure Change in structure makes the next change more difficult. Cost of subsequent changes increase rapidly: Whatever the system’s application domain or technological base. Software systems are complex, need to evolve due to changing environment and requirements

21 Dealing with Complexity
Abstraction Decomposition Hierarchy Hierarchy (Booch 17): Object model is called object structure by Booch

22 Abstraction Inherent human limitation to deal with complexity
The phenomena Chunking: Group collection of objects Ignore unessential details: Models Modelling: abstract representation of a system to answer questions about a system The system itself may be too large, too small, too complicated, too expensive, no longer exists, hypothetical Model: visualize, understand To build a system, one needs to know the operating environment of the system Build a model of the application domain relevant to the system To build a system, one needs to know the possible solutions Build a model of the solution domain OO method regards solution domain models as transformations of the applicaion domain models.

23 Models are used to provide abstractions
System Model: Object Model: system structure; object interaction Functional model: system functions; data flow through the system Dynamic model: system reaction to external events; event flow Task Model: PERT Chart: dependencies between the tasks Schedule: time limit Org Chart: roles in the project or organization Issues Model: Open and closed issues; constraints posed by the client; resolutions made. Rationale: context of design decisions (why certain decisions are made)

24 Decomposition Which decomposition is the right one?
A technique used to master complexity (divide and conquer) Functional decomposition system decomposed into modules Module: a major processing step (function) in the application domain Modules can be decomposed into smaller modules Object-oriented decomposition The system is decomposed into classes (objects) Each class is a major abstraction in the application domain Classes can be decomposed into smaller classes Which decomposition is the right one? If you think you are politically correct, you probably want to answer: Object-oriented. But that is actually wrong. Both views are important Functional decomposition emphasises the ordering of operations, very useful at requirements engineering stage and high level description of the system. Object-oriented decomposition emphasizes the agents that cause the operations. Very useful after initial functional description. Helps to deal with change (usually object don’t change often, but the functions attached to them do). Which decomposition is the right one?

25 Class Identification Object-oriented modelling requires Class identification: Finding classes for a new software system (Greenfield Engineering) Identifying classes in an existing system (Reengineering) Creating class-based interface to a system (Interface Engineering) Class identification uses: Philosophy Science Experimental evidence Difficulty in identifying classes: Determining the purpose of a system

26 Hierarchy Abstraction & Decomposition:
Leads to classes & objects (object model) Relationships between classes & objects Structure (static models), interactions (dynamic models) Hierarchical relationships between classes 2 important hierarchies "Part of" hierarchy "Is-kind-of" hierarchy

27 Part of Hierarchy Computer CPU Memory I/O Devices Cache Program
Counter ALU

28 Is-Kind-of Hierarchy (Taxonomy)
Cell Muscle Cell Blood Cell Nerve Cell Striate Smooth Red White Cortical Pyramidal

29 So where are we right now?
Three ways to deal with complexity: Abstraction Decomposition Hierarchy Object-oriented decomposition is a good methodology Difficulty in determining the purpose of a system Depending on the purpose, different objects are found How can we do it right? Many different possibilities Use Case Modelling (currently popular) approach: Start with a description of the functionality Then proceed to the object model This leads us to the software lifecycle The identification of objects and the definition of the system boundary are heavily intertwined with each other.

30 Software Lifecycle Activities
...and their models System Design Object Implemen- tation Testing Requirements Elicitation Analysis Use Case Model Solution Domain Objects Realized By Application Domain Expressed in Terms Of Test Cases ? Verified By class.... Subsystems Structured By class... Source Code Implemented

31 OOD & UML Over to Arshad ...

32 Reusability … living with change
A good software design solves a specific problem but is general enough to address future problems (for example, changing requirements) Experts do not solve every problem from first principles They reuse solutions that have worked for them in the past Goal for the software engineer: Design the software to be reusable across application domains and designs How? Use design patterns and frameworks whenever possible

33 Design Patterns and Frameworks
A small set of classes that provide a template solution to a recurring design problem Reusable design knowledge on a higher level than datastructures (link lists, binary trees, etc) Framework: A moderately large set of classes that collaborate to carry out a set of responsibilities in an application domain. Examples: User Interface Builder Provide architectural guidance during the design phase Provide a foundation for software components industry

34 Patterns are used by many people
Chess Master: Openings Middle games End games Writer Tragically Flawed Hero (Macbeth, Hamlet) Romantic Novel User Manual Architect Office Building Commercial Building Private Home Software Engineer Composite Pattern: A collection of objects needs to be treated like a single object Adapter Pattern (Wrapper): Interface to an existing system Bridge Pattern: Interface to an existing system, but allow it to be extensible Now Read Chapter 1 of BD book

35 Chapter 1: Introduction
Mt. Robson with Kain Face, West Rib of Denali

36 Coding Issues Mike will talk about how to write good Java code?
His lecture will include topics such as: packages inheritance subclassing interface modifiers exception handling accessor methods abstract classes Java Beans

37 Finally Back to Doron ...

38 Goal: software reliability
Use software engineering methodologies to develop the code. Use formal methods during code development 2

39 What are formal methods?
Techniques for analyzing systems, based on some mathematics. This does not mean that the user must be a mathematician. Some of the work is done in an informal way, due to complexity.

40 Examples for FM Deductive verification: Using some logical formalism, prove formally that the software satisfies its specification. Model checking: Use some software to automatically check that the software satisfies its specification. Testing: Check executions of the software according to some coverage scheme.

41 Typical situation: Boss: Mark, I want that the new internet marketing software will be flawless. OK? Mark: Hmmm. Well, ..., Aham, Oh! Ah??? Where do I start? Bob: I have just the solution for you. It would solve everything.

42 Some concerns Which technique? Which tool? Which experts?
What limitations? What methodology? At which points? How expensive? How many people? Needed expertise. Kind of training. Size limitations. Exhaustiveness. Reliability. Expressiveness. Support.

43 Common critics Formal methods can only be used by mathematicians.
The verification process is itself prone to errors, so why bother? Using formal methods will slow down the project.

44 Some questions and answers...
Formal methods can only be used by mathematicians. Wrong. They are based on some math but the user should not care. The verification process is itself prone to errors, so why bother? We opt to reduce the errors, not eliminate them. Using formal methods will slow down the project. Maybe it will speed it up, once errors are found earlier.

45 Some exaggerations Automatic verification can always find errors.
Deductive verification can show that the software is completely safe. Testing is the only industrial practical method.

46 Our approach Learn several methods (deductive verification, model checking, testing process algebra). Learn advantages and limitations, in order to choose the right methods and tools. Learn how to combine existing methods.

47 Emphasis The process: Selecting the tools, Modeling, Verification, Locating errors. Use of tools: Hands on. PVS, SPIN Visual notation: Statecharts, MSCs, UML.

48 Some emphasis The process of selecting and using formal methods.
The appropriate notation. In particular, visual notation. Hands-on experience with tools.

49 Summary In this lecture, we have:
Discussed the administrative arrangements Mentioned the topics we will cover in detail Please ... Consult Web Site for information Doron.Peled/course/cs223/index.html Subscribe to newsgroup uwarwick.dcs.course.cs223

50 End

Download ppt "CS223 Introduction to Software Engineering"

Similar presentations

Ads by Google