Programmation Object & Genie Logiciel

Transcription

1 Licence Mention Informatique L2/S Programmation Object & Genie Logiciel Burkhart Wolff Département Informatique

2 Bibliographie et Weberies UML 2.0, Martin Fowler, Campus Press, 2004 Developing Applications with Java and UML, Paul R. Reed Jr., Addison Wesley, 2002 UML 2 et les Design Patterns, G. Larman, Campus Press, 2005 UML 2 en action, P. Roques, F. Vallée, Eyrolles 2004 Paul R. Reed Jr., Addison Wesley, 2002 The Unified Modeling Language User Guide, Grady Booch, James Rumbaugh, Ivar Jacobson, Addison-Wesley, 2005 Précis de Génie Logiciel, M.-C. Gaudel, B. Marre, F. Schlienger et G. Bernot, Masson, 1996 The Science of Programming, D. Gries, Springer Verlag, L2-GL - Intro 2

3 Part II.1 : Introduction to Software Engineering If the automobile had followed the same development cycle 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 X. Cringely

4 technological aspects society aspects Why Software Engineering? Why does ad-hoc software development not scale: Software becomes more and more complex and large Constraints to trustworthyness, safety, security, Growing mix of hardware and software (complexity!), Informatics is omnipresent et «diffuse» Presence of clients, with imprecise and changing requirements, with whom we must communicate Development in (very) large, longstanding teams nec. Software can have a long life-cycle, implying maintenance reference documents Bad image of a company, loss of market credibility obstacle for development Legal constraints (Common Criteria Certification, Antri-Trust-Laws,...) L2-GL - Intro 4

5 Software becomes more dangerous... Trust, safety and security of software : Transportation: railway, aircrafts, space, Control of industrial processes, nuclear, military, Tele-surgery, medical imaging and instruments Communication infrastructure, e-commerce,... Economics: costs and delay of development of reliable software, reflecting customer needs, accepted by stakeholders and the public Techniques and tools evolve : in 20 years: factor 100 (?) higher la density components local errors accumulate, so more large and complex systems require more quality in local components! Technological aspects, methodologies, management, as in other industrial activities L2-GL - Intro 5

6 Software becomes BIG... Windows 7: Team of 1200 programmers only 5 Bln development costs (estimation) Revenues : 20 Bln (estimation)! Legal Bindings: years! Problems: Legal Battle about Windows Server 98; led to a settlement with the EU costing 700 mio! Technological aspects, methodologies, management, as in other industrial activities... That is what Software Engineering is talking about! L2-GL - Intro 6

7 Famous Software Desasters Mariner 1 (Venus, 1962) : wrong transcription of a formula erratic corrections of the trajectory (crash during flight) 1981 : Delay of first start of spaceship «voyager» (problème de synchronisation des résultats de calculateurs redondants) : Overdosis in a radiotherapy system (Therac-25, 5 dead). Item : Crash of planning and tracking system of london ambulance calls 1996 : Crash of flight 501 of Ariane 5 («validation» problem of the systeme) Juillet 1997 : Blocking of names of the domaine.com Septembre 1999 : Loss of Mars Climate Orbiter after 9 months of flight. Costs : 120 M$ (confusion of unities between two different components) 2004 : defect of reservation system for SNCF tickets, 2004 : denial of access for the Bouygues Télécom and France Telecom networks 2008 : Toll-Collect Desaster (Allemagne) 2010 : NPfIT desaster in Great Britan (Loss: 12 Billion British Pound) L2-GL - Intro 7

8 Call-backs? (interrogations) Example of a call-back: Speed Control Renault Laguna (2005) Is it an informatics-bug or not? Is it a problem of interaction hardware/software/environment? Even if no «bug», no-one is completely convinced! need to justify/control the «proces of construction» (Common Criteria) need to guarantee quality of tests of final product Ubiquity of software! Peugeot 607 = 2 Mb of embedded software, 40 processors, 20 % total cost «Needs» (ABS, ESP, electronic pedals, sensors, ) Interaction of services difficult to control. Trafic/Interferences on busses Validation of the systeme with all combinations of variants/options? Future automatisation of métro lines (RATP ligne 1: 2010) What validation process? Responsabilities: RATP or industrial partners (SIEMENS) Who authorizes finally the service? With what prospected reliability? L2-GL - Intro 8

9 Some figures Size of software systems? Windows «90» : 10 M. LOC source, Win2000: 30 M. LOC Core RedHat 7.1 (2002) : ~2.4 M. LOC, XWindow ~1.8 M., Space shuttle (and its environment) : ~50 MLOC Colombus Station (abandoned) : 980 MLOC compiled?? Development costs? Proportion of «Coding» : % Coding is more and more automated (CASE-tools, MDA) Proportion of Validation and Verification? ~ 40% Proportion of Specification and Design? ~ 40% Estimation of «Necessary Manpower» (Boehm) Man-Month = 3,5 * C 1,2 («Complexity C» very approximative, but clearly Man-Months grow non-linear! see for an overview on cost estimation methods...) L2-GL - Intro 9

10 Des chiffres sur les «défauts logiciels» Algorithms Code 25% 15% 60% Specification and design Distribution of faults Algorithms Code 8% 9% Distribution of costs of faults 83% Source: F. Fichot, Cours de Conduite de Projets, IFIPS L2-GL - Intro 10

11 Particularities of software Complexity strongly depends on applications : Synchronisation, repartition of processes (concurrency, true parallelism) Nature or volume of data, existence of algorithmic problems, Interdependency of hardware and software, Performance or «real-time réponse» (in reactive systems) Apparently, software is easy to modify (versatility) but impacts/consequences of modifications are difficult to predict Difficult prediction on fault-rates and mesurement of «quality»: small changes may have the most dramatic consequences (in contrast to physics: small changes have usually small impacts) no way to predict the «probability» of impacts/consequences Weak visibility of development processes for clients, but also management! Importance of the phases (requirements) analysis, design, validation Need for an «industrial» development process, i.e. s.th. tracable Need for document-orientation of the development (at least in classic S.E.) L2-GL - Intro 11

12 Different aspects of Software Engineering Development Mgt. Risc Management MANAGEMENT PROCESS Configuration Management «PeopleWare» (Staff, Sub-contractors) FEASIBILITY STUDIES (BEFORE PROJET) SPECIFICATION & DESIGN Development QUALITY ASSURANCE Maintenance & Support PRODUCTION INTEGRATION & VALIDATION EXPLOITATION TECHNICAL PROCESS QUALITY CONTROL METRICS PROCESSUS QUALITE L2-GL - Intro 12

13 Organisational aspects: the conduct of projets Planning, organisation, problem detection, reaction! Estimation of costs and delays Planning (e.g. diagrams like PERT or GANTT charts) Follow-ups (Suivi): management of staff, des échéances et fournitures à remettre au client Risk Management (prevention or corrections) Configuration management (versioning of documents, sources, and tests as well as keeping track of their links and dependencies) Document management associted to different phases of software production (part of configuration management!) and all that respecting quality norms... (document types, circuits de validation, règles de nommage) L2-GL - Intro 13

14 Development Phases vs. Documents A Sequence of increasingly precise and executable documents, Informal Requirement Specification (Cahier des charges informel) -> model(s) of the analyse (captures / formalizes the requirements) -> model(s) of design (captures interfaces of the implementation) -> code (implementation) -> validation et vérification protocols, documentation Development in «phases» Each phase of the development process ends by producing (versions of) these documents verified and validated before transition to next phase. Each phase contributes to a number of «activities», which are pervasive Production of Documentation (user manuals(manuel utilisateur), reference manuals (manuel de référence), installation manual (manuel d installation), ): extended at different phases. Activity of Validation/Verification L2-GL - Intro 14

15 Activities and Phases (1) Phase Requirements Analysis (capture des besoins) Study of the environment and the system application context, analysis of requirements and constraints (performance, ergonomics, portability, ) Output: requirement specification (cahier des charges) Phase specification analysis (analyse et spécification) Description of what the system should do (and not how) Output: analysis models Phase architectural design (conception architecturale) Decomposition of the software into «components» Conception of an integration proceeding and order of the different components (increments); conception of related tests for integration Phase (detailed) design (conception détaillée) Choice of algorithms, data structures,definition of interfaces and classes to describe conception of tests which verify or validate the implementation Output: design documents, possibly code-interfaces, code fragments, pseudo-code, mock-ups, prototypes L2-GL - Intro 15

16 Activities and Phases (2) Phase coding Phase unit test Controled execution of tests of each procedure/method if they behave as defined Phase integration and intégration tests Execution of test scenarios conceived in the analysis (Emphasis on high-level system behaviour) Phase Acceptance Tests and System test (by the producer) Test global tests under real conditions (platforms, under stress, mesuring performance,...) Phase Deployment (Recette; par le client) Tests, inspection of delivered documents, possibly véerification of relevant quality norms L2-GL - Intro 16

17 Beyond phases Importance of documentations : stake-holders: users, admins, mainteners, providers, general public Distinction of two complementary activities : Validation: check that the right system is built (what is needed by the client; «external» coherence) Verification: check if the system has been built right (what has been specified? «internal» coherence) Importance of tracability! (extremely important in open-source devs!) Document and archive the choices beend done! (mailings, versions,...) Enforce the coherence between the models and the product (environments must be «forward/reverse engineered») Importance of archiving, version and configuration management (versioning documents, «building» particular configurations) Guarante of document coherence wrt. to different versions Guarante of reconstructibility of particular versions (can you re-build version and observe if bug XXX occurs in it?) L2-GL - Intro 17

18 And after deployment? Maintenance is painful and expensive! Correction maintenance: correction of critical bugs Adaptive maintenance: new OS version, new hardware, new performance problems, Y2K!!! Evolutionary maintenance: integrating new functionality Even worse: it may be nbecessary to maintain different versions/configurations of systems simultaneously! Maintenance costs: 2-4 times more than development? Need for regression tests from one version to another: Requires precise test goal descriptions (input, expected output and execution context + requirement trancing in tests) Need for test automation (execution, metrics, archiving) and, therefore, tool-chains L2-GL - Intro 18

19 Process development models Organisation of the phases associated documents Structuring of the process and improve its visibility, Development of Tool Support for a concrete process (RUP, V Model, Spiral, Méthodes Agiles, Xtreme programming,...) Produce templates for associated documents Minimise risc of procedural errors the software process Support for non-linear development (back-tracks) (modification of requirements, correction of design errors, modification of technical environment (platform), )? Are there methodologies adapted to the general tendancies? Distributed aspects in informatics, Global trends like virtualization, Need for interoperability (SOAP, WebServices, XML, ) Component-based approches (reuse, «COTS», libraries, frameworks) Separation of business logic (logique métier) / technical services (Norms like spécifications J2EE et.net, WebServices) L2-GL - Intro 19

20 The V-Model (Le Modèle en V) Requirements Engineering Installation, Systeme Tests Specification Acceptance Tests Architectural Design Detailed Design Integration & Integration Tests Unit Tests Coding Principle temporal dependencies Potential Back-flow Plans and Document Flow Historically best known, and pretty pedagogical! The descending flow produit les guides pour les phases montantes Pédagogique, mais pas toujours adapté (global, linéaire) L2-GL - Intro 20

21 The V-Model (Le Modèle en V) Analyse des besoins, Faisabilité Installation, Test Système Spécification Test d acceptation Conception Architecturale Intégration Conception Détaillée Codage Tests unitaires Flux temporel principal Retour en arrière éventuel Plans et Documents Historically best known, and pretty pedagogical! The descending flow produit les guides pour les phases montantes Pédagogique, mais pas toujours adapté (global, linéaire) L2-GL - Intro 21

22 Other process development models Iteration Model Spiral Model (Boehm) Révision Spécification Version 2 Version 1 Prototype Analyse de risques Incrément n Validation Intégration et deploiement Exigences Spécification Implémentation Conception Principes généraux: Diminuer les risques, meilleure visibilité, retours utilisateur rapides, Intégration et validation progressive des fonctionnalités L2-GL - Intro 22

23 Development process models en vogue Xtreme Programming (and other méthodes agiles such as SCRUM) Development driven by tests, «client»-centered Permanent restructuring of code, coding in «teams of two» Permanent presence of the client Rational Unified Process (RUP): iterative, using UML. Architecture MDA ( Approach based on the transformation of UML models L2-GL - Intro 23

24 Summary Programming in the small is not enough! When constructing systems with more than LOC's, the development process must be structured: into phases establishing a bureaucratic decumentation process tool-chains for code-generation, testing, verification, documentation generation. the work of 1000 of collaborators must be organized... and financed There is no silver-bullet, not ONE particular SE Development Process, rather: every process model can be found in industry, from V-Model (large projects with public/military clients) to Methodes Agiles and Xtreme Programming (google)... to MDA (e.g. SAP) L2-GL - Intro 24