Paradigma object-oriented

Transcript

1 Paradigma object-oriented Dati & Comportamento Implementazione trasparente dei servizi Facile mantenimento Omogeneità nella gerarchia dati-funzioni Procedural approach OO approach Data hierarchy Replaced by Hierarchy of functions Class hierarchy

2 Cosa sono gli oggetti? Il mondo può essere percepito Punto di vista filosofico Oggetto = astrazione di un entità reale Il mondo è fatto di oggetti Gli oggetti interni nascono e muoiono Gli oggetti esterni sono eterni Punto di vista di un modello Oggetto = Identificatore + Stato + Comportamento Stato attributi variabili Comportamento operazioni Punto di vista dell ingegneria del Software Oggetto = astrazione di un entità che contiene i dati e le operazioni Costruttore e distruttore Archiettura Object-oriented Organizzazione di un sistema software in termini di una collezione strutturata di oggetti Strutturata = include associazioni di Utilizzo Aggregazione ( parte di o contiene un ) Ereditarietà ( è un ) Collezione = Gli oggetti sono indipendenti dal sistema cui appartengono, perché Sono interessanti e utili individualmente Riutilizzabili per sistemi differenti

3 Classi e Oggetti Classe = descrizione di un dato astratto Offre Nome Definizione della sua struttura dati Servizi per accedere alla sua struttura dati Elemento statico Oggetto = istanza di una classe Offre Identità Stato, accessibile attraverso i servizi definiti dalla classe Elemento run time Classi e Oggetti (cont.) A run time Esistono solo oggetti Nel codice sorgente Esistono solo classi

4 Instanziazione Processo per la creazione di un oggetto Gli attributi sono inizializzati L istanza è assegnata ad una variabile Operatori per l instanziazione Costruttore Distruttore Dictionary language create_dictionary() insert_word() search_word() give_next_word() D1: Dictionary language = German Associazioni Relazioni tra classi e tra oggetti Cardinalità delle associazioni Numero degli oggetti partecipanti 1, 0..1, M..N, *, 0..*, 1..* Tipo di associazione Numero di classi che partecipano all associazione Binaria, ternaria, N-aria

5 Associazione asimmetrica Criteri che implicano l aggregazione Una classe rappresenta una parte di un altra classe Gli attributi di una classe sono propagati ad un altra classe Un azione di una classe implica un azione di un altra classe Le istanze di una classe sono subordinate alle istanze di un altra classe Aggregazione +owner co-owner Person Car 1..* 0..* aggregate class 1 1 Building Engine Ereditarietà Si realizza attraverso i meccanismi di Estensione delle classi Specializzazione delle classi Combinazione delle classi

6 Ereditarietà (cont.) superclass Object Point Polygon heir subclass Triangle Rectangle Un erede Offre i servizi dell antenato Del quale rappresenta un estensione Offrendo nuovi servizi E/O una specializzazione Sfruttando le potenzialità definite dai servizi degli antenati e ridefinendoli per il loro caso specifico (polimorfismo) Unified Modeling Language

7 Motivazione Perchè una notazione unificata? Potenza espressiva Completezza Consistenza Il valore dell UML È uno standard aperto Supporta l intero ciclo di sviluppo del software Supporta diverse aree di applicazione É basato sull esperienza e le necessità degli utenti È supportato da molte applicazioni

8 Motivazione (cont.) Perchè una notazione con diagrammi multipli? Obiettivo Coprire più aspetti di un sistema complesso Complessità Necessario per un analisi e un design dettagliato La visione del Software Architect End-user Functionality Logical View Process System integrators Performance View Scalability Throughput Conceptual Implementation View Programmers Use Case Software management View Deployment View System engineering System topology Delivery, installation Communication Physical P. Kruchten, Nov The 4+1 View Model of Architecture IEEE Software

9 Modelli, Viste e Diagrammi Static views Sequence Use Case Class Object Collaboration Models Component Statechart Dynamic views Activity Deployment Use Case Diagram

10 Analisi e Specifica dei Requisiti Attività per l analisi e la raccolta dei requisiti Studiare l ambito di un applicazione Identificare i confini e le interazioni tra l applicazione e il mondo esterno Identificazione e comprensione dei requisiti Attività per la specifica dei requisiti Specifica dei requisiti (basati su cosa e non su come) Validazione/Verifica dei requisiti specificati Analisi: Metodologie Nessun metodo scientifico Linee guida, principi generali e tecniche empiriche Troppi Fattori soggettivi, Fattori umani, e Problemi di comunicazione

11 Analisi: Linee Guida L analisi dovrebbe identificare Una rappresentazione delle informazioni più significative Un modello del comportamento del software L analisi dovrebbe considerare come il sistema Sarà strutturato (dalla prospettiva utente) Fornirà le funzionalità I sistemi complessi devono essere suddivisi in modo gerarchico: L analisi è eseguita separatamente sulle differenti parti Specifica: livelli di formalismo Specifica Informale Basata sul linguaggio naturale (ambiguo) Specifica Formale Basata sul linguaggio matematico Specifica mista (Semi-formale) Composta da una parte formale e una informale

12 Specifica: tipi Specifica dei dati (vista statica) Specifica del comportamento (vista dinamica) Specifica: stili per il comportamento Operazionale Specifica le procedure Esempio: La lista B è ottenuta dalla lista A muovendo il più piccolo elemento di A nella prima posizione di B, il nuovo più piccolo elemento di A nella seconda posizione di B, e procedendo in questo modo finché la lista A è vuota. Descrittivo Specifica le proprietà Esempio: la lista B è una permutazione ordinata della lista A

13 Use Case Diagram Notazione semi-formale Specifica le interazioni tra il sistema e il mondo esterno Utile per Obbligare l analista ad esprimere dei confini ben definiti tra il sistema e il mondo esterno Organizzare le funzioni del sistema in elementi (use cases) sui quali focalizzare l attenzione Fornire una prima base per la specifica della struttura del sistema dal punto di vista dell utente Elementi di un Use Case Diagram Actor Qualcuno (utente) o qualcosa (sistema esterno, hardware) che Scambia informazioni con il sistema Fornisce input al sistema, o riceve output dal sistema Use Case Un unità funzionale (funzionalità) parte del sistema

14 Relazioni tra Use Cases Actor Actor Use Case Use Case Interaction. Determina: Quali attori participano in un use case Dove l esecuzione inizia Use Case A <<include>> Use Case B Usage. Modella il fatto che una funzionalità selezionata è usata nel contesto di un altra funzionalità (una è la fase dell altra) Use Case A Use Case B Generalization. Definisce una funzionalità come un estensione di un altra già esistente (special case) Esempio: Corsi on line All inzio del semestre la segreteria deve fornire agli studenti la lista dei corsi disponibili attraverso un sistema di registrazione on line. Ogni studente deve selezionare 4 corsi disponibili ed esprimere due possibili alternative. Ogni corso deve avere tra 3 e 20 studenti: corsi con meno di 3 studenti sono cancellati, e quelli con più di 20 sono suddivisi. All inzio i professori accedono al sistema per inserire i loro corsi nella lista, in seguito alle selezioni degli studenti loro accedono per controllare lo stato degli studenti. Dopo il periodo di selezione, il sistema crea le liste definitive, risolvendo tutte le anomalie e le manda all ufficio amministrativo che procede alla tassazione di ogni studente. Gli studenti accedono al sistema per vedere la lista dei loro corsi Tutte le interazioni utente sono autenticate

15 Esempio: Corsi on line Administrative Office Course Selection <<include>> Request Students List <<include>> Students User Authentication <<include>> <<include>> Professor Request Course List Insert Course Esempio: Sistema di prenotazione albergo L utente esegue la richiesta di prenotazione Il sistema di prenotazione controlla la disponibilità di posti Il sistema di prenotazione acquisisce i dati utente Il sistema di prenotazione garantisce la prenotazione con carta di credito

16 Esempio: Sistema di prenotazione <<include>> Hotel Booking Check availability <<include>> Customer Acquire Customer data <<include>> Acquire Credit Card data Hotel Booking guaranteed by Credit Card Esercizio Estendere il sistema di prenotazione in modo che: Sia prevista la conferma della prenotazione via Sia previsto un rifiuto della prenotazione se la carta di credito non è valida Siano possibili delle scelte alternative nel caso in cui il tipo di camera non è disponibile

17 Esercizio Modellare un sistema per la gestione di una biblioteca in modo: L utente può accedere solo se autenticato Gli utenti sconosciuti devono registrarsi Sia possibile cercare i libri secondo alcuni criteri (autore, argomento, titolo) Il bibliotecario può inserire nuovi libri, ma non può cancellarli Soltanto l amministratore può rimuovere dei libri dal catalogo L utente può richiedere l acquisto di alcuni libri non presenti compilando un modulo Il modulo di acquisto è inviato via al direttore della biblioteca.