Ingegneria del Software. 1: Concetti di base. Rif.: Ghezzi et.al., Ingegneria del software, II Ed.,Prentice Hall - Capitoli

Transcription

1 Ingegneria del Software 1: Concetti di base Rif.: Ghezzi et.al., Ingegneria del software, II Ed.,Prentice Hall - Capitoli

2 Organizzazione del corso Docente Prof. A. Calvagna Esame Prove scritte in itinere e a fine corso Prova scritta+orale (tutti gli altri appelli) Comunicazioni Sito web: Date appelli, libri, slides, avvisi, ecc.

3 Argomenti del corso 1 concetti di base 2 ooad in UML 3 design architetturale 4 middleware prova in itinere 5 specifica dei requisiti 6 validazione e verifica 7 processi di sviluppo 8 qualita e gestione esame finale

4 What happens?

5 Warrantees? LIMITED WARRANTY. Microsoft warrants that (a) the SOFTWARE PRODUCT will perform substantially in accordance with the accompanying written materials for a period of ninety (90) days from the date of receipt, LIMITATION OF LIABILITY. TO THE MAXIMUM EXTENT PERMITTED BY APPLICABLE LAW, IN NO EVENT SHALL MICROSOFT OR ITS SUPPLIERS BE LIABLE FOR ANY SPECIAL, INCIDENTAL, INDIRECT, OR CONSEQUENTIAL DAMAGES WHATSOEVER (INCLUDING, ) ARISING OUT OF THE USE OF THE SOFTWARE PRODUCT MICROSOFT S ENTIRE LIABILITY SHALL BE LIMITED TO THE GREATER OF THE AMOUNT ACTUALLY PAID BY YOU FOR THE SOFTWARE PRODUCT OR U.S. $5.00; PROVIDED...

6 USS Yorktown After a crew member mistakenly entered a zero into the data field of an application, the computer system proceeded to divide another quantity by that zero. The operation caused a buffer overflow, in which data leaked from a temporary storage space in memory, and the error eventually brought down the ship's propulsion system. The result: the Yorktown was dead in the water for more than two hours.

7 Better, Faster, Cheaper In Sept. 99, NASA lost both the Mars Polar Lander and the Climate Orbiter. Later investigations determined software errors were to blame. Orbiter: Component reuse error. Lander: Precondition violation.

8 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. Substantial errors still exist. Astronauts are supplied with a book of known software problems "Program Notes and Waivers".

9 Arianne 5 40 seconds into its flight it veered off course and exploded. It was later found to be an error in reuse of a software component. On June 4, 1996, the Arianne 5 took off on its maiden flight. For the next two years, virtually every research presentation used this picture.

10 Automotive Analogy If the automobile had followed the same development as the computer, a Rolls-Royce would today cost $100, get a million miles per gallon, and...

11 Automotive Analogy If the automobile had followed the same development as the computer, a Rolls-Royce would today cost $100, get a million miles per gallon, and explode once a year killing everyone inside." - Robert Cringely

12 History The field of software engineering was born in 1968 in response to chronic failures of large software projects to meet schedule and budget constraints Recognition of "the software crisis" Term became popular after NATO Conference in Garmisch Partenkirchen (Germany), 1968

13 Software Engineering: Definition 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. 20

14 Software Engineering Introduction What is Software Engineering (SE)? The process of building a software product. Some questions to put SE in perspective: What are the sizes of some typical software products? How many people would it take to build these in 1 year? 2? What would you do if a bug could cost lives and $2 billion? What would you do if a delay could cost $100 s of millions?

15 Scientist vs Engineer Computer Scientist Proves theorems about algorithms, designs languages, defines knowledge representation schemes Has infinite time Engineer Develops a solution for an application-specific problem for a client Uses computers & languages, tools, techniques and methods Software Engineer Works in multiple application domains Has only 3 months... while changes occurs in requirements and available technology

16 Role of software engineer Programming skill not enough Software engineering involves "programmingin-the large" understand requirements and write specifications derive models and reason about them master software operate at various abstraction levels member of a team communication skills management skills

17 What is a software process? A set of activities whose goal is the development or evolution of software. Generic activities in all software processes are: Specification - what the system should do and its development constraints Development - production of the software system Validation - checking that the software is what the customer wants Evolution - changing the software in response to changing demands.

18 Software Lifecycle Definition Software lifecycle: Set of activities and their relationships to each other to support the development of a software system Typical Lifecycle questions: Which activities should I select for the software project? What are the dependencies between activities? How should I schedule the activities?

19 The software lifecycle (a preview) Requirements analysis and specification Design and specification waterfall model Code and module testing Integration and system testing Delivery and maintenance

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

21 Software Its Nature and Qualities

22 Software product Different from traditional types of products intangible difficult to describe and evaluate malleable human intensive involves only trivial manufacturing process

23 Some Software Characteristics Software is engineered or developed, not manufactured in the traditional sense. Software does not wear out in the same sense as hardware.

24 Some Software Characteristics In theory, software does not wear out at all. BUT, Hardware upgrades. Software upgrades.

25 In reality Thus, reality is more like this. Most software is custom built, and customer never really knows what she/he wants.

26 Software Myths Myth: It s in the software. So, we can easily change it. Reality: Requirements changes are a major cause of software degradation.

27 Software Myths Myth: We can solve schedule problems by adding more programmers. Reality: Maybe. It increases coordination efforts and may slow things down. Myth: While we don t have all requirements in writing yet, we know what we want and can start writing code. Reality: Incomplete up-front definition is the major cause of software project failures.

28 Software Myths Myth: Writing code is the major part of creating a software product. Reality: Coding may be as little as 10% of the effort, and 50-70% may occur after delivery.

29 Software Myths Myth: I can t tell you how well we are doing until I get parts of it running. Reality: Formal reviews of various types both can give good information and are critical to success in large projects. Myth: The only deliverable that matters is working code. Reality: Documentation, test history, and program configuration are critical parts of the delivery.

30 Software Myths Myth: I am a (super) programmer. Let me program it, and I will get it done. Reality: A sign of immaturity. A formula for failure. Software projects are done by teams, not individuals, and success requires much more than just coding.

31 Classification of sw qualities "ilities" Internal vs. external External visible to users Internal concern developers Product vs. process Our goal is to develop software products The process is how we do it Internal qualities affect external qualities Process quality affects product quality

32 Correctness Software is correct if it satisfies the functional requirements specifications assuming that specification exists! If specifications are formal, since programs are formal objects, correctness can be defined formally It can be proven as a theorem or disproved by counterexamples (testing)

33 The limits of correctness It is an absolute (yes/no) quality there is no concept of degree of correctness there is no concept of severity of deviation What if specifications are wrong? (e.g., they derive from incorrect requirements or errors in domain knowledge)

34 Reliability Reliability informally, user can rely on it can be defined mathematically as probability of absence of failures for a certain time period if specs are correct, all correct software is reliable, but not vice-versa (in practice, however, specs can be incorrect )

35 Idealized situation Requirements are correct Reliability Correctness

36 Robustness Robustness software behaves reasonably even in unforeseen circumstances (e.g., incorrect input, hardware failure)

37 Performance Efficient use of resources memory, processing time, communication Can be verified complexity analysis performance evaluation (on a model, via simulation) Performance can affect scalability a solution that works on a small local network may not work on a large intranet

38 Usability Expected users find the system easy to use Other term: user-friendliness Rather subjective, difficult to evaluate Affected mostly by user interface e.g., visual vs. textual

39 Verifiability How easy it is to verify properties mostly an internal quality can be external as well (e.g., security critical application)

40 Maintainability Maintainability: ease of maintenance Maintenance: changes after release Maintenance costs exceed 60% of total cost of software Three main categories of maintenance corrective: removing residual errors (20%) adaptive: adjusting to environment changes (20%) perfective: quality improvements (>50%)

41 Types of Software Maintenance Corrective maintenance Fixing defects ( bugs ) I.e. correcting design flaws Perfective maintenance Improving the product ( enhancements ) Because of new requirements Or misunderstood requirement Because of new technological opportunities E.g. increased distribution of a centralized IS onto client-server architecture Adaptive maintenance Reflecting changes in the environment Changes to tax laws, changes to ways of working, etc. Or unanticipated changes

42 Cost of SE phases

43 Reusability 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

44 Reusability Existing product (or components) used (with minor modifications) to build another product (Similar to evolvability) Also applies to process Reuse of standard parts measure of maturity of the field

45 Portability Software can run on different hw platforms or sw environments Remains relevant as new platforms and environments are introduced (e.g. digital assistants) Relevant when downloading software in a heterogeneous network environment

46 Understandability Ease of understanding software Program modification requires program understanding

47 Interoperability Ability of a system to coexist and cooperate with other systems e.g., word processor and spreadsheet

48 Typical process qualities Productivity denotes its efficiency and performance Timeliness ability to deliver a product on time Visibility all of its steps and current status are documented clearly

49 Timeliness: issues Often the development process does not follow the evolution of user requirements A mismatch occurs between user requirements and status of the product

50 Timeliness: a visual description of the mismatch Function User needs Actual system capabilities t t t t t Time

51 Application-specific qualities E.g., information systems Data integrity Security Data availability Transaction performance.

52 Quality measurement Many qualities are subjective No standard metrics defined for most qualities

53 Factors affecting the quality of a software system Complexity: The system is so complex that no single programmer can understand it anymore The introduction of one bug fix causes another bug Change: The Entropy of a software system increases with each change: Each implemented change erodes the structure of the system which makes the next change even more expensive ( Second Law of Software Dynamics ). As time goes on, the cost to implement a change will be too high, and the system will then be unable to support its intended task. This is true of all systems, independent of their application domain or technological base.

54 Quality of today s software. The average software product released on the market is not error free.

55 has major impact on Users

56 Software Engineering Principles

57 Outline Principles form the basis of methods, techniques, methodologies and tools Seven important principles that may be used in all phases of software development Modularity is the cornerstone principle supporting software design Case studies

58 Application of principles Principles apply to process and product Principles become practice through methods and techniques often methods and techniques are packaged in a methodology methodologies can be enforced by tools

59 A visual representation Tools Methodologies Methodologies Methods and techniques Principles

60 Key principles Rigor and formality Separation of concerns Modularity Abstraction Anticipation of change Generality Incrementality

61 Rigor and formality Software engineering is a creative design activity, BUT It must be practiced systematically Rigor is a necessary complement to creativity that increases our confidence in our developments Formality is rigor at the highest degree software process driven and evaluated by mathematical laws

62 Examples: product Mathematical (formal) analysis of program correctness Systematic (rigorous) test data derivation

63 Example: process Rigorous documentation of development steps helps project management and assessment of timeliness

64 Separation of concerns To dominate complexity, separate the issues to concentrate on one at a time "Divide & conquer" (divide et impera) Supports parallelization of efforts and separation of responsibilities

65 Example: process Go through phases one after the other (as in waterfall) Does separation of concerns by separating activities with respect to time

66 Example: product Keep product requirements separate functionality performance user interface and usability

67 Modularity A complex system may be divided into simpler pieces called modules A system that is composed of modules is called modular Supports application of separation of concerns when dealing with a module we can ignore details of other modules

68 Cohesion and coupling Each module should be highly cohesive module understandable as a meaningful unit Components of a module are closely related to one another Modules should exhibit low coupling modules have low interactions with others understandable separately

69 A visual representation (a) high coupling (b) low coupling

70 Abstraction Identify the important aspects of a phenomenon and ignore its details Special case of separation of concerns The type of abstraction to apply depends on purpose Example : the user interface of a watch (its buttons) abstracts from the watch's internals for the purpose of setting time; other abstractions needed to support repair

71 What is this?

72 Abstraction ignores details Example: equations describing complex circuit (e.g., amplifier) allows designer to reason about signal amplification Equations may approximate description, ignoring details that yield negligible effects (e.g., connectors assumed to be ideal)

73 Abstraction yields models For example, when requirements are analyzed we produce a model of the proposed application The model can be a formal or semiformal description It is then possible to reason about the system by reasoning about the model

74 An example Programming language semantics described through an abstract machine that ignores details of the real machines used for implementation abstraction ignores details such as precision of number representation or addressing mechanisms

75 Abstraction in process When we do cost estimation we only take some key factors into account We apply similarity with previous systems, ignoring detail differences

76 Anticipation of change Ability to support software evolution requires anticipating potential future changes It is the basis for software evolvability Example: set up a configuration management environment for the project (as we will discuss)

77 Generality While solving a problem, try to discover if it is an instance of a more general problem whose solution can be reused in other cases Carefully balance generality against performance and cost

78 Incrementality Process proceeds in a stepwise fashion (increments) Examples (process) deliver subsets of a system early to get early feedback from expected users, then add new features incrementally deal first with functionality, then turn to performance deliver a first prototype and then incrementally add effort to turn prototype into product

79 Case study: compiler Compiler construction is an area where systematic (formal) design methods have been developed e.g., BNF for formal description of language syntax

80 Separation of concerns example When designing optimal register allocation algorithms (runtime efficiency) no need to worry about runtime diagnostic messages (user friendliness)

81 Modularity Compilation process decomposed into phases Lexical analysis Syntax analysis (parsing) Code generation Phases can be associated with modules

82 Representation of modular structure Lexical diagnostic s Symbol table Source code Lexical analysis Parsing Code generation Object code Parse tree Tokenized code boxes represent modules directed lines represent interfaces Syntax diagnostics

83 Module decomposition may be iterated further modularization of code-generation module Symbol table Code genration Intermediate code Object code Parse tree Intermediate code generation Machine code generation

84 Abstraction Applied in many cases abstract syntax to neglect syntactic details such as begin end vs. { } to bracket statement sequences intermediate machine code (e.g., Java Bytecode) for code portability

85 Anticipation of change Consider possible changes of source language (due to standardization committees) target processor I/O devices

86 Generality Parameterize with respect to target machine (by defining intermediate code) Develop compiler generating tools (compiler compilers) instead of just one compiler

87 Incrementality Incremental development deliver first a kernel version for a subset of the source language, then increasingly larger subsets deliver compiler with little or no diagnostics/optimizations, then add diagnostics/optimizations

88 Case study (system engineering): elevator system In many cases, the "software engineering" phase starts after understanding and analyzing the "systems engineering issues The elevator case study illustrates the point

89 Rigor&formality (1) Quite relevant: it is a safety critical system Define requirements must be able to carry up to 400 Kg. (safety alarm and no operation if overloaded) emergency brakes must be able to stop elevator within 1 m. and 2 sec. in case of cable failures Later, verify their fulfillment

90 Separation of concerns Try to separate safety performance usability (e.g, button illumination) cost although some are strongly related cost reduction by using cheap material can make solution unsafe

91 A modular structure Control apparatus buttons at floor i Elevator B3 B2 B1

92 Module decomposition may be iterated Control apparatus Elevator Engine Brakes Cabin Internal Buttons

93 Abstraction The modular view we provided does not specify the behavior of the mechanical and electrical components they are abstracted away

94 Anticipation of change, generality Make the project parametric wrt the number of elevators (and floor buttons) Control apparatus Elevators Floor buttons

95 Summary Need for engineered software Software product has a lifecycle Software product nature and -ilities Software systems are complex and subject to continuous changes Apply key SE principles to improve quality