Archivi tag: ingegneria del software

Diagramma delle classi

Premessa: questo breve post non vuole essere una trattazione esauriente ed esaustiva circa l’argomento ma solo ed esclusivamente un appunto meritevole di approfondimenti, in quanto ci sono tonnellate di libri che trattano l’argomento in modo certamente migliore di quanto possa fare qualsiasi sito web.

Tali tipi di diagramma costituiscono uno dei diagrammi fondamentali nell’UML e consentono di descrivere tipi di entità con le loro caratteristiche e le eventuali relazioni.

L’unità di misura del diagramma è la Classe la quale rappresenta una categoria di entità (istanze) dette oggetti ed è corredata da un insieme di attributi (i quali descrivono le caratteristiche degli oggetti derivati dalla classe) e di operazioni caratteristiche che ne descrivono il comportamento.

Una tipica classe è formata come segue

+--------------------------------+
|        NOME DELLA CLASSE       |
|--------------------------------|
|        ATTRIBUTI               |
| + attributo                    |
| - attributo                    |
| # attributo                    |
|--------------------------------|
|        METODI/OPERAZIONI       |
| + metodo                       |
| - metodo                       |
| # metodo                       |
+--------------------------------+

Com’è possibile vedere dall’esempio di classe poco sopra, di fianco a metodi o attributi è presente un simbolo, tale simbolo ha un significato ben preciso e si riferisce alla visibilità dello stesso:

+ = public: è possibile accedere al metodo/attributo dall’esterno della classe

– = private: è possibile accedere al metodo/attributo solo all’interno della classe

# = protected: il metodo/attributo viene ereditato da tutte le classi derivate

Associazioni

Due classi possono essere legate da associazioni che ne rappresentano i legami; informazioni correlate circa la molteplicità possono essere esplicitate.

Dipendenze

Due classi possono essere legate da una relazione di indipendenza che indica sostanzialmente che la definizione di una delle due fa riferimento all’altra.

Generalizzazione

Due classi possono essere legate da una relazione di generalizzazione, la quale indica che una delle due classi è da considerarsi una generalizzazione dell’altra.

More info…

Software Engineering – Ian Sommerville

| + metodo                       |

Documentazione no problem!

Premessa: questa non vuole essere una trattazione esaustiva sull’argomento, ma semplicemente una serie di note, che ognuno poi può integrare o meno a suo piacimento.

Abstract: Un indice già pronto per stendere una documentazione omogenea ed esaustiva circa un progetto di un sistema software.

L’elenco che riporterò qui di seguito nasce dall’esigenza di avere sempre a disposizione un sommario di attività da fare, da utilizzare come linea guida, per poter creare un sistema software. Tale linea guida è frutto sia di diversi progetti in cui si ho raffinato man mano tale elenco sia di diverse letture dedicate all’ingegneria del software, non sono indicati gli schemi da utilizzare nel corso della stesura del documento risultante in quanto la necessità degli stessi dovrebbe sorgere automaticamente man mano che il documento prende forma. L’indice non è adatto agli studi di fattibilità per i quali invece penso di dedicare un ulteriore post.

1. Requisiti funzionali
Identificano quello che l’applicazione deve fare, quindi in questo capitolo dovremo descrivere le necessità dell’attività lavorativa con l’aiuto degli esperti di dominio; inoltre saremo chiamati ad effettuare l’analisi dei compiti proprio per vedere e toccare con mano quello che fanno gli utenti.

2. Specifica degli standard qualitativi
In questa attività è necessario prendere in considerazione i seguenti fattori
2.1 Facilità d’uso
2.2 Conformità alle convenzioni definite relativamente all’interfaccia utente
2.3 Facilità di manutenzione
2.4 Affidabilità
2.5 Prestazioni
2.6 Livello di difetti accettabile
2.7 Compatibilità con i sistemi correlati
2.8 Temi di risposta veloci
2.9 Prestazioni migliori

3. Definizione delle specifiche tecniche
3.1 Configurazione minima
3.2 Configurazione consigliata
3.3 Sistema operativo consigliato
3.4 Opzioni di rete
3.5 Linguaggi usati
3.6 Database usati
3.7 Portabilità
3.8 Possibilità di riutilizzo
3.9 Numero di utenti previsti
3.10 Volume dati previsto
3.11 Requisiti di sicurezza
3.12 Interfacce verso altri sistemi
3.13 Standard tecnici e convenzioni di codifica correnti
3.14 Requisiti previsti dal supporto tecnico
3.15 Internazionalizzazione

4. Trasformare le necessità in requisiti
In questa fase bisogna comprendere la spiegazione dell’utente riguardo la modalità di svolgimento di un compito e determinare perché il software è necessario

5. Determinare le priorità dei requisiti
6. Identificare le strategie per soddisfare i requisiti ed inizio della pianificazione