Ingegneria dei sistemi software. AN - Univwersity of Bologna

Transcript

1 Ingegneria dei sistemi software AN - Univwersity of Bologna

2 Informatico: cosa è? Un tecnico (che pilota tecnologie)? Un analista (che valuta problemi)? Un manager (che gestisce processi di produzione)? Un progettista (di prodotti e tecnologie)? Uno scienziato (che studia e crea le fondazioni)? Un venditore (che analizza le esigenze del mercato)? L informatica: una commodity o qualcosa da costruire? AN - Univwersity of Bologna

3 Informatico e titoli di studio Istituto tecnico Laurea triennale Laurea magistrale Dottorato di ricerca AN - Univwersity of Bologna

4 Scienza o ingegneria? Scienza Attività speculativa intesa ad analizzare, definire e interpretare la realtà sulla base di criteri rigorosi e coerenti Ingegneria Disciplina che studia l'applicabilità delle conoscenze scientifiche alle necessità della vita civile e del suo sviluppo socio-economico AN - Univwersity of Bologna

5 Computer science & software engineering Computer Science is concerned with the theories and methods which underlie computers and software systems. Software Engineering is concerned with the practical problem of producing software. In the belief that software could be engineered on the same footing as traditional engineering disciplines, a NATO study group coined the term Software Engineering in AN Unibo

6 Requisiti Per seguire il corso e per svolgere le attività di laboratorio è necessario conoscere gli elementi fondamentali di UML e dei design pattern classici (pattern GOF). E anche richiesta una buona conoscenza del linguaggio Java, dei linguaggi e modelli computazionali e della programmazione concorrente. AN - Univwersity of Bologna

7 Software Engineering Software creation process: application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software IEEE Software Engineering is an engineering discipline which is concerned with all aspects of software production from the early stages of system requirements through to maintaining the system after is has gone into use. AN Unibo

8 Engineering discipline Engineers make things work. They apply theories, methods and tools that are appropriate but use them selectively and always try to discover solutions to problems even when there are not applicable theories and methods to support them. Engineers have to work to organizational and financial constraints AN Unibo

9 Crisi del software Nasce dalla rapida crescita della potenza degli elaboratori e dalla crescita della complessità dei problemi che gli elaboratori permettono di affrontare e risolvere I committenti domandano un crescente numero di funzionalità, cercando di minimizzare i costi e i tempi dello sviluppo I requisiti si rivelano spesso ambigui ed anche in conflitto tra loro La crisi del software è legata alla incomprensione di cosa si deve fare e alla inadeguatezza dei processi di produzione del software A Collection of Well-Known Software Failures 9 Latest Software Failures in Enterprise Applications AN Unibo

10 Ingegneria dei Sistemi Software Lo scopo del corso di Ingegneria dei Sistemi software (ISS) è approfondire principi, metodologie e tecnologie utili a migliorare l'efficienza e l'efficacia del processo di costruzione di software di qualità, rapportando in modo sistematico questo corpo di conoscenze agli strumenti (linguaggi, IDE, tecnologie, piattaforme, etc) che abilitano e sostengono la produzione di software. AN - Univwersity of Bologna

11 Ingegneria dei Sistemi Software L'obiettivo del corso è capire sia cosa sia opportuno fare durante un processo di produzione per ottenere software di qualità, sia come farlo, con l'aiuto di strumenti di produzione e di piattaforme di esecuzione di tipo general puropse e/o custom (domain specific). Al centro dell'attenzione viene posto il concetto di sistema software inteso come un insieme di parti eterogenee tra loro interagenti ed organizzate in modo da costruire un tutto le cui proprietà non sono interamente riconducibili alla somma delle parti. Particolare attenzione viene dedicata ai sistemi distribuiti organizzati a livelli (verticali e orizzontali) e al rapporto tra i processi di analisi / progettazione e le moderne piattaforme operative di supporto. AN - Univwersity of Bologna

12 Ingegneria dei Sistemi Software Il corso intende fare riferimento (si veda book pg ) sia a metodologie agili sia a metodologie di sviluppo basate sull'uso dei modelli (espressi in UML2.0 o in linguaggi custom basati su MOF) enucleando da entrambi gli approcci elementi utili per la definizione di processi organizzativi ritagliati per diversi macro-contesti di produzione, quali piccole aziende costituite da poche unità di lavoro, aziende di medie dimensioni con ruoli già diversificati (analista, progettista, etc.) e aziende di grandi dimensioni, sensibili anche forme di innovazione sia di prodotto sia di processo. AN - Univwersity of Bologna

13 Piattaforme Le piattaforme operative di riferimento sono prevalentemente di tipo opensource ed utilizzano Java come linguaggio di base, ma non si limitano all'uso del paradigma ad oggetti così come realizzato in Java. Particolare attenzione viene data al settore dei dispositivi mobili e piccoli computer, tra cui Raspberry Pi ed Android AN - Univwersity of Bologna

14 Contesto applicativo AN Unibo

15 AN - Univwersity of Bologna Internet of things

16 Ingegneria dei Sistemi Software Le piattaforme operative di riferimento sono prevalentemente di tipo opensource ed utilizzano Java come linguaggio di base, ma non si limitano all'uso del paradigma ad oggetti così come realizzato in Java. Particolare attenzione viene data al tema Internet of things, al settore dei dispositivi mobili basati su Android, su Linux AN - Univwersity of Bologna

17 Ingegneria dei Sistemi Software Filo conduttore del discorso è il concetto di Architettura Software e l'uso di Software Factories cutsom basate su Model Driven Software Development (MDSD). La tecnologia di riferimento in questo settore sarà XText. Particolare attenzione viene dedicato allo sviluppo sistematico di architetture di analisi e di progetto a partire dai requisiti funzionali (nell'ambito di specifici domini applicativi) e da requisiti non funzionali legati alla eterogeneità, distribuzione e (possibilmente) sicurezza. AN - Univwersity of Bologna

18 Ingegneria dei Sistemi Software Partcolare attnezione saraà dedicata al rapporto tra metodologie model-based e metododologie agili TDD SCRUM FDD AN - Univwersity of Bologna

19 Macchine e problemi Overcoming the abs. gap Problem (Requirements) (Misky) machine (ABSTRACTION) GAP TOP DOWN: from the problem to the machine BOTTOM UP: from the machine to the problem AN - Univwersity of Bologna

20 La macchina di Minsky CLR (r): CLeaR register r. (Set r to zero.) INC (r): INCrement the contents of register r. DEC (r): DECrement the contents of register r. JZ (r, z): IF register r contains Zero THEN Jump to instruction z ELSE continue in sequence. AN - Univwersity of Bologna

21 Livelli UML2 (book pg. 34) Insieme ridotto di concetti Ingegneria del software AN Università di Bologna

22 Design Pattern GOF Interfaces Construction Adapter Facade AbstractFactory Buidler Composite Bridge FactoryMethod Prototype Memento Responsibility Operation Singleton Mediator Observer Proxy TemplateMethod State Command Extension Interpreter ChainOfResponsibility Decorator Iterator Visitor Flyweight AN Unibo Ingegneria del software

23 Pattern POSA4 Franck Bushmann, Kevin Henney, Douglas C. Schmidt: Pattern- Oriented Software Architecture: Volume 4 A Pattern Language for Distributed computing, John Wiley & Sons, 2007 Franck Bushmann, Kevin Henney, Douglas C. Schmidt: Pattern-Oriented Software Architecture: Volume 4 A Pattern Language for Distributed computing, John Wiley & Sons, 2007 AN - Univwersity of Bologna

24 Capability Maturity Model The CMM (a registered service mark of Carnegie Mellon University, CMU) is a development model created after study of data collected from organizations that contracted with the U.S. Department of Defense, who funded the research. This model became the foundation from which Carnegie Mellon created the Software Engineering Institute (SEI). The term "maturity" relates to the degree of formality and optimization of processes, from ad hoc practices, to formally defined steps, to managed result metrics, to active optimization of the processes. AN - Univwersity of Bologna

25 CMM levels Initial (chaotic, ad hoc, individual heroics) - the starting point for use of a new or undocumented repeat process. It is characteristic of processes at this level that they are (typically) undocumented and in a state of dynamic change, tending to be driven in an ad hoc, uncontrolled and reactive manner by users or events. This provides a chaotic or unstable environment for the processes. Repeatable - the process is at least documented sufficiently such that repeating the same steps may be attempted. some processes are repeatable, possibly with consistent results. Process discipline is unlikely to be rigorous, but where it exists it may help to ensure that existing processes are maintained during times of stress. Defined - the process is defined/confirmed as a standard business process, and decomposed to levels 0, 1 and 2 (the last being Work Instructions). there are sets of defined and documented standard processes established and subject to some degree of improvement over time. These standard processes are in place and used to establish consistency of process performance across the organization AN - Univwersity of Bologna

26 CMM levels Managed - the process is quantitatively managed in accordance with agreed-upon metrics. using process metrics, management can effectively control the AS-IS process (e.g., for software development ). In particular, management can identify ways to adjust and adapt the process to particular projects without measurable losses of quality or deviations from specifications. Process Capability is established from this level. Optimizing - process management includes deliberate process optimization/improvement. the focus is on continually improving process performance through both incremental and innovative technological changes/improvements. Note: process maturity according to the CMM is not necessarily mandatory for successful software development AN - Univwersity of Bologna

27 Software process development Model-driven engineering (MDE) focuses on creating and exploiting domain models (that is, abstract representations of the knowledge and activities that govern a particular application domain), rather than on general purpose computing (or algorithmic) concepts. Agile software development a group of software development methods based on iterative and incremental development, where requirements and solutions evolve through collaboration between self-organizing, crossfunctional teams. It promotes adaptive planning, evolutionary development and delivery, a time-boxed iterative approach, and encourages rapid and flexible response to change. Example: SCRUM ) AN - Univwersity of Bologna

28 Process Snapshot (pg. 102) 1 Introduction 2 Vision 3 Goals 4 Requirements 5 Requirement analysis 5.1 Use cases 5.2 Scenarios 5.3 (Domain)model 5.4 Test plan 6 Problem analysis 6.1 Logic architecture 6.2 Abstraction gap 6.3 Risk analysis 7 Work plan 8 Project 8.1 Structure 8.2 Interaction 8.3 Behavior 9 Implementation 10 Testing 11 Deployment 12 Maintenance Ingegneria del software AN Università di Bologna

29 Rendere esplicite le conoscenze Nel processo di produzione del software il lavoro dei diversi attori (analisti, progettisti, sviluppatori, etc.) si basa su un insieme di conoscenze e decisioni che spesso rimangono implicite all'interno del processo di produzione. Uno degli scopi dei processi model based è rendere esplicite queste conoscenze attraverso la costruzione di diagrammi espressi con notazioni formali cioè attraverso l'uso di un linguaggio con una ben precisa sintassi e semantica. AN - University of Bologna

30 Domande (su un sistema) Cosa deve fare committente Cosa deve essere analista Quale struttura-interazione-comportamento sono necessari tenendo conto dei vincoli che sorgono dai requisiti e dal problema in sè Cosa è opportuno che sia analista Tenendo conto delle tecnologie, dell andamento del mercato, delle risorse umane, economiche, temporali, etc. Come è fatto progettista Quale struttura-interazione-comportamento ha il sistema finale tenendo conto dei vincoli dall analisi e dei criteri (pattern) usati per risolvere le forze (anche contrastanti) in gioco AN - Univwersity of Bologna

31 Workflow Sviluppiamo l analisi dei requisiti e l analisi del problema Esprimendo fatti rilevanti attraverso modelli essenziali Discutiamo in modo sistematico avvalendoci di modelli basati su meta-modelli custom Usiamo i modelli come se fossero il nuovo codice sorgente costruendo generatori di codice usando Xtext (pg. 206) Realizziamo in modo automatico la schematic part avvelendoci dei design pattern per sistemi distribuiti Impostiamo piani di collaudo ancor prima di avere iniziato la fase di progettazione Realizziamo un primo prototipo di prodotto e interagiamo con il committente Ingegneria del software AN Università di Bologna

32 Valutazione del lavoro svolto Il laboratorio costituisce una parte essenziale del corso. Gli studenti sono tenuti a consegnare gli elaborati richiesti, che verranno valutati dal docente, in modo da acquisire una retroazione immediata sul lavoro svolto, che potrà essere utilizzata per modificare/migliorare quanto sviluppato. La valutazione finale consiste nelle presentazione e discussione degli artefatti prodotti in relazione alla costruzione di un sistema software (dello stesso tipo di quello discusso nei CaseStudy proposti durante il corso) che rispetti i requisiti pubblicati l'ultima settimana di lezione. Questi artefatti possono essere prodotti in modo individuale oppure, preferibilmente, attraverso un lavoro cooperativo svolto in gruppi di 2/3/4 studenti. AN - Univwersity of Bologna

33 Un primo case-study Produrre un telecomando per un robot AN - Univwersity of Bologna

34 Motto Non c è codice senza progetto, non c è progetto senza analisi del problema, non c è problema senza requisiti. AN Unibo

35 Non c è senza analisi NON iniziamo la fase di progetto prima di avere assestato la fase di analisi dei requisiti e l analisi del problema, con relativa peer-review, al fine di Individuare i principali sottosistemi Capire quali tecnologie sono necessarie Valutare i punti critici, i rischi e i costi Pianificare l uso delle risorse e i tempi Distribuire il lavoro tra le persone AN - University of Bologna

36 Architettura: le dimensioni base Struttura Interna Class diagrams Object diagrams Del prodotto Component diagrams Deployment diagrams Comportamento Sequence diagrams Collaboration diagrams Statechart diagrams Activity diagrams Interazione AN Unibo Ingegneria del software

37 Architecture: basic concepts Structure Atomic Composed Active Passive OPEARATIONS Property Modifier Provider Mapper Primitive NON-primitive Interaction Polling Procedure call Event driven Message passing Behavior AN Unibo Ingegneria del software

38 Modello: cosa si intende? (pg. 32) Per modello si intende genericamente una rappresentazione di un oggetto o di un fenomeno reale. La rappresentazione riproduce caratteristiche o comportamenti ritenuti fondamentali per il tipo di ricerca che si sta svolgendo In fisica si parla di modelli che descrivono i fenomeni reali. Tali modelli, spesso basati su ipotesi concettuali, si adattano a descriverne campi più o meno vasti del mondo fisico Gli ingegneri tradizionali intendono per modello un sistema matematico o fisico che ubbidisce a specifici vincoli e che può essere utilizzato per descrivere e comprendere un sistema attraverso relazioni di analogia AN - University of Bologna

39 Modello nella ingegneria del software Nei processi di costruzione del software, il termine modello va inteso come un insieme di concetti e proprietà volti a catturare aspetti essenziali di un sistema, collocandosi in un preciso spazio concettuale. Per l'ingegnere del software quindi un modello costituisce una visione semplificata di un sistema che rende il sistema stesso più accessibile alla comprensione e alla valutazione e facilita il trasferimento di informazione e la collaborazione tra persone. L'insieme dei modelli che descrivono un sistema dovrebbe formare una descrizione completa, coerente, consistente e non (troppo) ridondante. AN - University of Bologna

40 Un buon modello Corenza coerènza s. f. [dal lat. cohaerentia, der. di cohaerere; v. coerente]. L esser coerente, nel sign. proprio e fig., e nelle accezioni specifiche (per le quali, v. coerente): la c. delle parti nel tutto; c. d idee; c. fra pensiero e azione Per coerenza intendiamo che alle parole debba seguire una corrispondente azione, o anche l idea di pensare, sentire ed agire nella stessa direzione. Esempi: a) ogni unità di codice deve essere associata a un piano di test b)il colore rosso denota azioni, il colore blu denota entità. Consistenza consistènte agg. [dal lat. consistens -entis, der. di consistĕre nel sign. di «star saldo»: v. consistere]. 1. Solido, resistente, saldo: roba, stoffa molto c.; colla c.; anche fig.: un organizzazione poco c.; uno scritto c., che ha corpo, ricco di concetti. 2. a. In matematica, detto di un sistema non contraddittorio di postulati. Per consistenza intendiamo non contraddittorietà, sia sul piano sintattico, sia sul piano semantico Sinteticità Evitare elementi inutilmente sovrabbondanti, eccessivi o non necessari AN - University of Bologna

41 Modelli e linguaggi Quattro diverse rappresentazioni Insieme numeri Naturali 3 espresse in quattro differenti linguaggi Idea di un certo numero naturale III tre dello stesso modello AN Unibo

42 Forze in gioco Requisiti Sistema software Piattaforma operativa Domian forces

43 Il framework Xtext B I B L I O G R A F I A : X T E X T U S E R G U I D E AN University of Bologna

44 Xtext is part of openarchitectureware / Eclipse Modeling is Based on an EBNF grammar. It generates ANTLR3 based parser EMF based metamodel Eclipse editor with syntax highlighting code completion customizable outline code folding real time constraint checking AN University of Bologna

45 Specifica della grammatica grammar it.unibo.xtext.entities with org.eclipse.xtext.common.terminals generate entities " Model : (imports+=import)* (types+=type)* ; Frasi espresse in notazione EBNF Import : Type: SimpleType: 'import' importuri = STRING; SimpleType Entity; 'type' name = ID; The grammar is a collection of Rules. Rules start with their name followed by : and ending with ; Entity : 'entity' name=id ('extends' extends= [ Entity ] )? '{' properties+=property* '}'; Property: 'property' name=id ':' type= [ Type ] ( many?= '[]')?; AN University of Bologna The editor provides code completion and constraint checking for the grammars themselves

46 Target Language Editor ( generato ) AN University of Bologna

47 Modello-utente (Engines.entity) Frase nel nostro linguaggio type String entity Engine { } property name: String entity WebCrawler extends Engine { } entity Mechanism extends Engine { } property subengine: Engine[] Frase come rappresentazione Un parser (generato in modo automatico dalla grammatica) trasforma questa frase in un AST L AST è la rappresentazione interna della frase espressa nel nostro linguaggio Il nostro linguaggio è un metamodello => l AST è un modello. I tipi dei nodi dell AST sono il metamodello Il modello può essere trasformato in codice (o altro) mediante regole che hanno come riferimento il metamodello AN University of Bologna