2 Lecture 1 - Objectives To introduce the staff To explain the structure of the moduleTo describe what Software Engineering is about
3 StaffDoron PeledRoger PackwoodArshad JhumkaAnanda AmatyaMike Joy
4 Timetable Lectures Weekly, weeks 1-10 Twice weekly, weeks 11-15 “Surgeries”Weeks 6-19Attend 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 Process3 RAP Software Specification4 AA UML: Overview5 DP/RAP/AJ/AA The Project + Tools6 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 Estimation12 AJ Further Design + Case Study (part 3)13 DAP Formal Methods (1): Introduction14 DAP Formal Methods (2): Testing & Reliability15 IBM Team Based Software Development16 IBM Development Focus Areas & Practices17 RAP Safety-Critical Systems18 RAP Software Testing19 RAP Software Reliability20 AA Methodologies (XP)
9 Booklist See handout for ISBN, cost, etc. Recommended Bruegge and DutoitGeneralPressman and InceSommervilleUMLBennett, Skelton and Lunn (Schaum)Booch, Jacobson and RumbaughFowler and ScottOthers
11 The Software Process Why is there a Software Process ? why not just write the program ?What the customer wantshow it is implemented, or at least designedchange, for the better, sometimes ...Why is software "engineering" hard ?what solutions does "engineering" offer ?The traditional software lifecycleother development models
12 Software Specification "What" needs to be specifiedmany people communicate via written documentsA specification that the customer can agree toa specification for the programmer (one of many)Many aspects (views) of a software designComplete, Concise, Testable
13 Software Cost Estimation Before we even start, do we want the job ?Need to estimate -how much efforthow much timehow much moneyPrimarily based on how much last timemodel basedConstructive Cost Model COCOMOMythical Man Month - Brooks
14 Safety-Critical Systems Developing software that should never compromise the overall safety of a systemReliability is with respect to specificationsafety is independent of specificationTherac and Arianne examplesRisk analysisintolerableAs Low As Reasonably Practical (ALARP)acceptableThe Myths of Software Safety
15 Software Testing A successful test finds a fault testing does not prove the absence of faultsWhite Box, Black Box testingCoverage testing, Exhaustive testingcan you trust the test software?Test data values, Corner Cases, Fencepost errorsmistyped variable names, operators, constructsUnit test, integration test, System, Alpha, Betatop-down, Bottom-up, Inside-out, Sandwich ??
16 Software ReliabilityAvailability, Reliability, Safety, Integrity, etc.Defects, Density and ZeroFault Tolerance, N-Way, Recovery Blocks, DiversityDangerous Programming
18 Warwick Bookshop: In stock Bernd Bruegge, Adjunct, Carnegie Mellon University Allen H. Dutoit, Technical University of MunichISBN:Publisher: Prentice Hall Copyright: Paperback 762 pages (November 30, 2003)Amazon.co.uk Price: £35.99Warwick Bookshop: In stockK2, 8611m, Karakoram range of Western Himalayas.2nd highest peak, success rate < 40%
19 Objectives (with lecture & suggested reading plan) Understand System ModellingLearn 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 ProcessAgile Process (XP)The term Software Engineering was coined in 1968: developing quality software on time and within budgetSetting concrete objectivesEstimating resources necessary to attain the objectivesMeeting customer expectationsSoftware Engineering is a modelling activity: overcoming complexity by focussing on what is relevantSoftware 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, iterativelySoftware 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 structureChange 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 AbstractionDecompositionHierarchyHierarchy (Booch 17):Object model is called object structure by Booch
22 Abstraction Inherent human limitation to deal with complexity The phenomenaChunking:Group collection of objectsIgnore unessential details:ModelsModelling: abstract representation of a system to answer questions about a systemThe system itself may be too large, too small, too complicated, too expensive, no longer exists, hypotheticalModel: visualize, understandTo build a system, one needs to know the operating environment of the systemBuild a model of the application domain relevant to the systemTo build a system, one needs to know the possible solutionsBuild a model of the solution domainOO 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 interactionFunctional model: system functions; data flow through the systemDynamic model: system reaction to external events; event flowTask Model:PERT Chart: dependencies between the tasksSchedule: time limitOrg Chart: roles in the project or organizationIssues 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 decompositionsystem decomposed into modulesModule: a major processing step (function) in the application domainModules can be decomposed into smaller modulesObject-oriented decompositionThe system is decomposed into classes (objects)Each class is a major abstraction in the application domainClasses can be decomposed into smaller classesWhich 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 importantFunctional 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 IdentificationObject-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:PhilosophyScienceExperimental evidenceDifficulty in identifying classes:Determining the purpose of a system
26 Hierarchy Abstraction & Decomposition: Leads to classes & objects (object model)Relationships between classes & objectsStructure (static models), interactions (dynamic models)Hierarchical relationships between classes2 important hierarchies"Part of" hierarchy"Is-kind-of" hierarchy
27 Part of Hierarchy Computer CPU Memory I/O Devices Cache Program CounterALU
29 So where are we right now? Three ways to deal with complexity:AbstractionDecompositionHierarchyObject-oriented decomposition is a good methodologyDifficulty in determining the purpose of a systemDepending on the purpose, different objects are foundHow can we do it right?Many different possibilitiesUse Case Modelling (currently popular) approach:Start with a description of the functionalityThen proceed to the object modelThis leads us to the software lifecycleThe identification of objects and the definition of the system boundary are heavily intertwined with each other.
30 Software Lifecycle Activities ...and their modelsSystemDesignObjectImplemen-tationTestingRequirementsElicitationAnalysisUse CaseModelSolution DomainObjectsRealized ByApplicationDomainExpressed in Terms OfTestCases?VerifiedByclass....SubsystemsStructured Byclass...SourceCodeImplemented
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 principlesThey reuse solutions that have worked for them in the pastGoal for the software engineer:Design the software to be reusable across application domains and designsHow?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 problemReusable 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 BuilderProvide architectural guidance during the design phaseProvide a foundation for software components industry
34 Patterns are used by many people Chess Master:OpeningsMiddle gamesEnd gamesWriterTragically Flawed Hero (Macbeth, Hamlet)Romantic NovelUser ManualArchitectOffice BuildingCommercial BuildingPrivate HomeSoftware EngineerComposite Pattern: A collection of objects needs to be treated like a single objectAdapter Pattern (Wrapper): Interface to an existing systemBridge Pattern: Interface to an existing system, but allow it to be extensibleNow 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:packagesinheritancesubclassinginterfacemodifiersexception handlingaccessor methodsabstract classesJava Beans
38 Goal: software reliability Use software engineering methodologies to develop the code.Use formal methods during code development2
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 FMDeductive 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 approachLearn 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 EmphasisThe process: Selecting the tools, Modeling, Verification, Locating errors.Use of tools: Hands on. PVS, SPINVisual 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 arrangementsMentioned the topics we will cover in detailPlease ...Consult Web Site for informationDoron.Peled/course/cs223/index.htmlSubscribe to newsgroupuwarwick.dcs.course.cs223