Elaborazione. Laboratorio di Ingegneria del Software. Andrea Bei

Transcript

1 Laboratorio di Ingegneria del Software Andrea Bei

2 - Obiettivo Obiettivi: Scoprire e stabilizzare la maggiorparte dei requisiti Realizzare (progettare, sviluppare e testare) la parte di architettura software più importante e rischiosa Attenuare i rischi maggiori Stimare il piano di lavoro e le risorse complessive La parte di architettura software da realizzare è quella che massimizza le seguenti caratteristiche Rischio: comprende i componenti più critici dal punto di vista della complessità tecnica, incertezza nella stima dell effort, usabilità Copertura: copre la maggiorparte degli aspetti significativi del sistema implementazione in ampiezza e poco profonda Criticità: implementa i casi d uso più importanti per il cliente 2

3 Elaborati principali Analisi del dominio (o del business) e dei requisiti Modello di dominio: E una visualizzazione dei concetti di dominio Modello dei casi d uso: Casi d uso e opzionalmente SSD e contratti delle operazioni Progettazione Modello di progetto: E l insieme dei diagrammi che descrivono la progettazione logica (diagrammi delle classi, diagrammi di interazione,...) Documento dell architettura del software: Riassume gli aspetti principali dell architettura. E un riepilogo delle idee di progettazione più significative e delle loro motivazioni Modello dei dati:comprende lo schema della base di dati e le strategie di mapping tra la rappresentazione a oggetti e la base di dati Storyboard dei casi d uso, Prototipi UI: Descrizione dell interfaccia utente, della navigazione, dei modelli di usabilità e così via 3

4 Modello di dominio Un modello di domino (o modello concettuale) è una rappresentazione visuale di classi concettuali o di oggetti reali di un dominio ( dizionario visuale ) E illustrato tramite:classi concettuali, associazioni e attributi concept or domain object quantity Sales LineItem 1..* 0..1 Records-sale-of 1 Item * association Contained-in Stocked-in 1 1 Sale Store attributes date time address name 1 Houses Paid-by 1..* 1 Payment Captured-on 1 Register amount 4

5 Modello di dominio e di progetto Un Payment nel modello di A Payment dominio the è un Domain concetto Model mentre is a concept, nel but modello a Payment di in progetto the Design Model è una is classe a software software. class. They are Non not sono the same la stessa thing, but cosa the former ma il inspired primo the naming and definition of the ispira il nome e la latter. definizione della seconda. Questo This reduces riduce the representational il salto rappresentazionale gap. E una delle idee fondamentali This is one of the della big ideas in progettazione object technology. OO Modello di dominio UP Domain Model Stakeholder's view of the noteworthy concepts in the domain. amount Payment Payment amount: Money 1 Pays-for 1 inspires objects and names in 1 1 Pays-for date time Sale Sale date: Date starttime: Time getbalance(): Money gettotal(): Money... UP Design Model Modello di progetto The object-oriented developer has taken inspiration from the real world domain Ci si ispira al dominio per creare i nomi delle classi software. in creating software classes. Il salto rappresentazionale tra i concetti del dominio e la loro Therefore, rappresentazione the representational software gap si between deve how mantere stakeholders il più conceive basso possibile the domain, and its representation in software, has been lowered. 5

6 Diagrammi di sequenza di sistema Un diagramma di sequenza di sistema (SSD System Sequence Diagram) illustra gli eventi di input ed output del sistema relativi ad uno scenario di un caso d uso Attore esterno external actor to system : Cashier system as black box the name could be "NextGenPOS" but "System" keeps it simple Il Sistema è visto a scatola nera the ":" and underline imply an instance, and are explained in a later chapter on sequence diagram notation in the UML Process Sale Scenario :System Un Loop UML con a UML una loop espressione interaction di guardia frame, with a guard booleana expression loop [ more items ] makenewsale enteritem(itemid, quantity) description, total Valore return ritornato value(s) associato al precedente associated with messaggio the previous message L astrazione ignora l interfaccia an abstraction grafica that ignores presentation and medium Il messaggio di ritorno è opzionale the return se line non is viene ritornato optional nulla if nothing is returned endsale total with taxes makepayment(amount) change due, receipt Un messaggio con a parametri message with parameters E una astrazione it rappresentante is an abstraction representing the l evento di sistema system event of entering associato the payment all inserimento data by di some dati relativi mechanism ad un pagamento 6

7 Diagrammi di sequenza di sistema Gli obiettivi degli SSD sono: approfondire l indagine del comportamento ( a scatola nera ) del sistema a partire dai casi d uso stabilire con precisione quali sono gli eventi di input (operazioni di input e parametri) e di output (dati di ritorno) rappresentare un punto di partenza per la progettazione degli oggetti e della collaborazioni tra essi l analisi dei contratti delle operazioni supportare metodologie di stima basate sull identificazione delle operazioni di sistema (Function Point + COCOMO) Gli SSD sono creati durante la fase di elaborazione Gli SSD fanno parte del modello dei casi d uso 7

8 Dai casi d uso agli SSD Un SSD mostra gli eventi per un solo scenario di caso d uso Gli elementi (nome operazioni, parametri, dati di ritorno) sono descritti nel Glossario. Es: i dettagli della ricevuta (receipt) Scenario : pagamento in contanti di Process Sale Process Sale Scenario : Cashier :System 1. Il Cliente arriva alla cassa POS con Simple gli articoli cash-only e/o Process i servizi Sale da scenario: acquistare Customer Il Cassiere arrives inizia at una a POS nuova checkout vendita 3. with Il goods Cassiere and/or inserisce services il to codice purchase. 2. Cashier identificativo starts a dell articolo new sale Cashier Il Sistema enters registra item identifier. la riga di vendita 4. System per l articolo records e sale presenta line item la and presents item description, price, and descrizione dell articolo, il prezzo running total. e il totale parziale. Si ripetono i Cashier repeats steps 3-4 until indicates passi 3-4 fino a che l operazione done. 5. System non termina presents total with taxes 5. calculated. Il sistema mostra il totale con le 6. Cashier imposte tells calcolate Customer the total, and 6. asks Il Cassiere for payment. riferisce il totale al 7. Customer Cliente, e pays richiede and System il pagamento handles 7. payment. Il Cliente paga e il sistema gestisce... il pagamento loop [ more items ] makenewsale enteritem(itemid, quantity) description, total endsale total with taxes makepayment(amount) change due, receipt 8

9 Relazione tra SSD e gli altri elaborati Sample UP Artifact Relationships Domain Model Business Modeling date... Sale 1 1..* Sales... LineItem... quantity Use-Case Model Vision Process Sale Requirements Cashier Process Sale Use Case Diagram use case names 1. Customer arrives Cashier makes new sale Use Case Text system events parameters and return value details Glossary : System Operation: enteritem( ) Post-conditions: -... system operations : Cashier make NewSale() enteritem (id, quantity) Supplementary Specification Operation Contracts System Sequence Diagrams starting events to design for : Register Design Model : ProductCatalog : Sale Design enteritem (itemid, quantity) spec = getproductspec( itemid ) addlineitem( spec, quantity ) 9

10 Architettura Logica L architettura logica è l organizzazione su larga scala delle classi software in package, sottosistemi e strati Uno strato è un gruppo a grana grossa di classi, package e sottosistemi con responsabilità coese rispetto ad un aspetto importante del sistema Strati ricorrono a servizi di strati più bassi User Interface (Interfaccia Utente) UI Swing not the Java Swing libraries, but our GUI classes based on Swing Web Application Logic e Domain Objects Oggetti software che rappresentano oggetti di dominio e che collaborano per soddisfare i requisiti (es: Sale) Domain Sales Payments Taxes Technical Services Servizi tecnici indipendenti dal dominio come l interfacciamento con il Database, Logging, M Technical Services Persistence Logging RulesEngine 10

11 Architettura Logica e relazione con altri Sample UP Artifact Relationships elaborati Modello di L architettura logica può essere descritta con un diagramma dei package UML E descritta nel modello di progetto Il principale input è rappresentato dai requisiti non funzionali presenti nelle specifiche supplementari Business Modeling Requirements Design Modello dei casi d uso Use-Case Model Visione Vision The logical architecture is influenced by the constraints and non-functional requirements captured in the Supp. Spec. interaction Diagramma diagrams (a interazione dynamic view) (vista dinamica) Domain dominio Model package Diagramma diagrams dei UI of package the logical architecture dell architettura (a static view) Domain logica * enteritem (itemid, quantity) * : Register Specifiche Supplementary Supplementari Specification Design Modello di Progetto Tech Services spec = getproductspec( itemid ) Glossario Glossary : ProductCatalog Diagramma class delle diagrams classi (a(vista static view) statica)... Register makenewsale() enteritem(...) ProductCatalog getproductspec(...)... 11

12 Architettura Software (o Applicativa) Un architettura software è L insieme delle decisioni significative sull organizzazione di un sistema software Gli elementi strutturali di cui e composto Le interfacce di tali elementi Il comportamento di tali elementi specificato dalle collaborazioni tramite le loro interfacce La composizione di questi elementi in sottosistemi via via più ampi Lo stile architetturale che guida questa organizzazione 12

13 Progettazione a strati L idea della progettazione a strati è codificata nel pattern Layers Linee guida Progettare strati con una separazione netta e coesa degli interessi (delle responsabilità) Progettare strati inferiori per servizi generali e strati superiori per servizi specifici dell applicazione Collaborazioni e accoppiamenti dagli strati alti ai bassi (non il viceversa) Vantaggi dell uso degli strati Riduzione di accoppiamento e dipendenze, e conseguente aumento di riusabilità e comprensibilità La complessità è incapsulata Manutenibilità: Gli strati sono facilmente sostituibili (es: UI) Riusabilità: Gli strati più bassi sono molto riusabili Lo sviluppo in team è favorito 13

14 dependency Progettazione a strati:una architettura di riferimento Interfacce grafiche GUI windows Reports reports Interfacce vocali speech interface HTML, XML, XSLT,JSP,Javascript HTML, XML, XSLT, JSP, Javascript,... Gestione richieste strato UI handles presentation layer requests Workflow workflow Gestione stato della sessione session state Transizione tra finestre/pagine window/page transitions Consolidamento/trasformazione consolidation/transformation per la presentazione of disparate data for presentation UI (AKA Presentation, View) Application (AKA Workflow, Process, Mediation, App Controller) more app specific Gestione richieste strato Application handles application layer requests Implementazione regole di implementation dominio of domain rules Servizi di dominio (POS, Inventory) domain services (eventualmente (POS, Inventory) servizi multiapplicazione - services may be used by just one application, but there is also the possibility of multi-application services Domain (AKA Business, Application Logic, Model) Servizi aziendali molto generali very general e di basso low-level livello business utilizzati services in numerosi domini aziendali used in many business domains CurrencyConverter CurrencyConverter Business Infrastructure (AKA Low-level Business Services) Servizi tecnici di livello (relativamente) alto Persistence, Security (relatively) high-level technical services and frameworks Persistence, Security Technical Services (AKA Technical Infrastructure, High-level Technical Services) Servizi tecnici di basso livello low-level technical services, utilities, Strutture dati, Thread, matematica, file, DB, e I/O di rete and frameworks data structures, threads, math, file, DB, and network I/O Foundation (AKA Core Services, Base Services, Low-level Technical Services/Infrastructure) width implies range of applicability 14

15 Strati e partizioni Strati: sezioni verticali Partizioni: sottosistemi di uno stesso strato (divisione orizzontale) Domain Vertical Layers POS Inventory Tax Technical Services Persistence Security Logging Horizontal Partitions 15

16 Separazione modello-vista Modello è un sinonimo di strato degli oggetti del dominio, Vista è un sinonimo di strato UI Il Principio di separazione Modello-Vista dice: Gli oggetti non UI non devono essere accoppiati direttamente ad oggetti UI. Es: un oggetto Sale (non UI) non deve avere nessun riferimento alla finestra Sale (UI) Gli oggetti UI non devono contenere logica applicativa (es: il calcolo delle imposte) ma solo la logica di gestione degli eventi di iterazione con l utente (click di un bottone) delega dell elaborazione delle richieste agli oggetti di dominio contenenti la logica applicativa. 16

17 SSD, operazioni di sistema e strati Il pattern layers suggerisce UI come strato più alto I messaggi dei SSD inviati al sistema sono quindi catturati dallo strato UI e inoltrati allo strato di dominio I messaggi inviati dallo strato UI allo strato del dominio sono quindi quelli descritti negli SSD UI :System : Cashier makenewsale() enteritem(id, quantity) description, total Domain Swing... ProcessSale Frame makenewsale() enteritem() endsale() makenewsale() enteritem() endsale() : Cashier endsale()... Register makenewsale() enteritem()... the system operations handled by the system in an SSD represent the operation calls on the Application or Domain layer from the UI layer 17