Presentation is loading. Please wait.

Presentation is loading. Please wait.

CG152 Introduction: slide 1 CS223 Introduction: slide 1 CS223 Introduction to Software Engineering Doron Peled, Roger Packwood, Arshad Jhumka, Ananda Amatya,

Similar presentations


Presentation on theme: "CG152 Introduction: slide 1 CS223 Introduction: slide 1 CS223 Introduction to Software Engineering Doron Peled, Roger Packwood, Arshad Jhumka, Ananda Amatya,"— Presentation transcript:

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

2 CG152 Introduction: slide 1 CS223 Introduction: slide 1 Lecture 1 - Objectives To introduce the staff To explain the structure of the module To describe what Software Engineering is about

3 CG152 Introduction: slide 1 CS223 Introduction: slide 1 Staff Doron Peled Roger Packwood Arshad Jhumka Ananda Amatya Mike Joy

4 CG152 Introduction: slide 1 CS223 Introduction: slide 1 Timetable Lectures –Weekly, weeks 1-10 –Twice weekly, weeks Surgeries –Weeks 6-19 –Attend if you have any problems, or just questions you wish to ask

5 CG152 Introduction: slide 1 CS223 Introduction: slide 1 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 CG152 Introduction: slide 1 CS223 Introduction: slide 1 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 CG152 Introduction: slide 1 CS223 Introduction: slide 1 Lectures - Term 1 1DP/RAP/AJ/AAIntroduction 2RAP The Software Process 3RAP Software Specification 4AAUML: Overview 5DP/RAP/AJ/AAThe Project + Tools 6AARequirements (Use Case Modelling) 7AAAnalysis (Static & Dynamic Modelling) 8AJAnalysis To Design + Case Study (part 1) 9AJObject Design + Case Study (part 2) 10MSJ Coding Issues

8 CG152 Introduction: slide 1 CS223 Introduction: slide 1 Lectures - Term 2 (provisional) 11RAPSoftware Cost Estimation 12AJFurther Design + Case Study (part 3) 13DAPFormal Methods (1): Introduction 14DAPFormal Methods (2): Testing & Reliability 15IBMTeam Based Software Development 16IBMDevelopment Focus Areas & Practices 17RAP Safety-Critical Systems 18RAP Software Testing 19RAP Software Reliability 20AA Methodologies (XP)

9 CG152 Introduction: slide 1 CS223 Introduction: slide 1 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 CG152 Introduction: slide 1 CS223 Introduction: slide 1 General Software Engineering Over to Roger...

11 CG152 Introduction: slide 1 CS223 Introduction: slide 1 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 CG152 Introduction: slide 1 CS223 Introduction: slide 1 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 CG152 Introduction: slide 1 CS223 Introduction: slide 1 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 CG152 Introduction: slide 1 CS223 Introduction: slide 1 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 CG152 Introduction: slide 1 CS223 Introduction: slide 1 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 CG152 Introduction: slide 1 CS223 Introduction: slide 1 Software Reliability Availability, Reliability, Safety, Integrity, etc. Defects, Density and Zero Fault Tolerance, N-Way, Recovery Blocks, Diversity Dangerous Programming

17 CG152 Introduction: slide 1 CS223 Introduction: slide 1 OOD & UML Over to Ananda...

18 CG152 Introduction: slide 1 CS223 Introduction: slide 1 Bernd Bruegge, Adjunct, Carnegie Mellon University Allen H. Dutoit, Technical University of Munich ISBN: Publisher: Prentice Hall Copyright: 2004 Paperback 762 pages (November 30, 2003) Amazon.co.uk Price: £35.99 Warwick Bookshop: In stock

19 CG152 Introduction: slide 1 CS223 Introduction: slide 1 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)

20 CG152 Introduction: slide 1 CS223 Introduction: slide 1 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 systems application domain or technological base.

21 CG152 Introduction: slide 1 CS223 Introduction: slide 1 Dealing with Complexity Abstraction Decomposition Hierarchy

22 CG152 Introduction: slide 1 CS223 Introduction: slide 1 Abstraction Inherent human limitation to deal with complexity –The phenomena Chunking: –Group collection of objects Ignore unessential details: –Models

23 CG152 Introduction: slide 1 CS223 Introduction: slide 1 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.

24 CG152 Introduction: slide 1 CS223 Introduction: slide 1 Which decomposition is the right one? Decomposition 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

25 CG152 Introduction: slide 1 CS223 Introduction: slide 1 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 CG152 Introduction: slide 1 CS223 Introduction: slide 1 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 CG152 Introduction: slide 1 CS223 Introduction: slide 1 Part of Hierarchy Computer Cache ALU Program Counter I/O Devices CPUMemory

28 CG152 Introduction: slide 1 CS223 Introduction: slide 1 Is-Kind-of Hierarchy (Taxonomy) Cell Muscle Cell Blood Cell Nerve Cell Striate SmoothRedWhite Cortical Pyramidal

29 CG152 Introduction: slide 1 CS223 Introduction: slide 1 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

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

31 CG152 Introduction: slide 1 CS223 Introduction: slide 1 OOD & UML Over to Arshad...

32 CG152 Introduction: slide 1 CS223 Introduction: slide 1 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 CG152 Introduction: slide 1 CS223 Introduction: slide 1 Design Patterns and Frameworks Design Pattern: –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 CG152 Introduction: slide 1 CS223 Introduction: slide 1 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 CG152 Introduction: slide 1 CS223 Introduction: slide 1 Chapter 1: Introduction

36 CG152 Introduction: slide 1 CS223 Introduction: slide 1 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 CG152 Introduction: slide 1 CS223 Introduction: slide 1 Finally Back to Doron...

38 CG152 Introduction: slide 1 CS223 Introduction: slide 1 Goal: software reliability Use software engineering methodologies to develop the code. Use formal methods during code development

39 CG152 Introduction: slide 1 CS223 Introduction: slide 1 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 CG152 Introduction: slide 1 CS223 Introduction: slide 1 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 CG152 Introduction: slide 1 CS223 Introduction: slide 1 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 CG152 Introduction: slide 1 CS223 Introduction: slide 1 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 CG152 Introduction: slide 1 CS223 Introduction: slide 1 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 CG152 Introduction: slide 1 CS223 Introduction: slide 1 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 CG152 Introduction: slide 1 CS223 Introduction: slide 1 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 CG152 Introduction: slide 1 CS223 Introduction: slide 1 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 CG152 Introduction: slide 1 CS223 Introduction: slide 1 Emphasis The process: Selecting the tools, Modeling, Verification, Locating errors. Use of tools: Hands on. PVS, SPIN Visual notation: Statecharts, MSCs, UML.

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

49 CG152 Introduction: slide 1 CS223 Introduction: slide 1 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 CG152 Introduction: slide 1 CS223 Introduction: slide 1 End


Download ppt "CG152 Introduction: slide 1 CS223 Introduction: slide 1 CS223 Introduction to Software Engineering Doron Peled, Roger Packwood, Arshad Jhumka, Ananda Amatya,"

Similar presentations


Ads by Google