Wondershare EdrawMind
Galería de mapas mentales Analisi del sistema informativo e progettazione di mappe mentali
- 11
Analisi del sistema informativo e progettazione di mappe mentali
Questa è una mappa mentale sull'analisi e la progettazione del sistema informativo, inclusa l'analisi del sistema e la panoramica della progettazione, il sondaggio sui requisiti di sistema, i casi d'uso, il modello di dominio, ecc.
Editado a las 2023-11-14 10:01:51,
Analisi del sistema informativo e progettazione di mappe mentali
- Recomendados
- Resumen
Sistema informativo del sistema di conoscenza del project manager (Capitolo 12 Gestione degli appalti di progetto)
- 7
Sistema informativo del sistema di conoscenza del project manager (Capitolo 3 Gestione dell'ambito del progetto)
- 10
Sistema informativo del sistema di conoscenza del project manager (Capitolo 10 Gestione della comunicazione di progetto e gestione degli stakeholder)
- 8
Sistema di conoscenza del project manager del sistema informativo (Capitolo 9 Gestione delle risorse umane del progetto)
- 6
Sistema informativo del sistema di conoscenza del project manager (Capitolo 11 Project Risk Management)
- 7
Analisi e progettazione di sistemi informativi
cap01 Analisi del sistema e panoramica della progettazione
introduzione
Si tratta di un insieme di specifiche e linee guida per aiutare a sviluppare sistemi informativi
1.1 Sviluppo software e analisi e progettazione del sistema
applicazione per computer
Un programma software per computer che esegue un insieme specifico di funzioni su un dispositivo informatico
Campo di applicazione medio
Chiamata anche "applicazione" (app)
Sistema informativo
Un insieme di componenti correlati che raccolgono, elaborano, archiviano e forniscono le informazioni necessarie per completare le attività aziendali
Ambito più ampio di "applicazione"
Include software, database e relativi processi manuali
analisi del sistema
Quelle attività che consentono alle persone di comprendere e specificare cosa dovrebbe realizzare un sistema informativo
sistema di design
Quelle attività che consentono di definire e descrivere in dettaglio il sistema che risolve i requisiti
L’analisi del sistema equivale a disegnare un progetto, mentre la progettazione del sistema è un piano dettagliato
1.2 Ciclo di vita dello sviluppo del sistema
progetto
Un compito pianificato che ha un inizio e una fine e produce un determinato risultato
per lo sviluppo dei sistemi informativi
Richiede la conoscenza degli strumenti e delle tecniche di analisi e progettazione del sistema
SDLC (ciclo di vita dello sviluppo del sistema), ovvero il ciclo di vita dello sviluppo del sistema
Il ciclo di vita dello sviluppo dei sistemi identifica l'intero processo che include tutte le attività necessarie per costruire, avviare e mantenere i sistemi informativi
Tutte le attività comprendono: analisi del sistema, progettazione del sistema, programmazione, test, manutenzione del sistema
sei processi fondamentali
Identificare problemi o esigenze e ottenere l'approvazione
Pianificare e monitorare i progetti
Scoprire e comprendere i dettagli di un problema o di una necessità
Progettare componenti del sistema che risolvono un problema o soddisfano un'esigenza
Costruisci, testa e integra componenti di sistema
Completa il test del sistema e quindi distribuisci la soluzione
processo di sviluppo del sistema informativo
Un approccio pratico allo sviluppo di un sistema informativo specifico (noto anche come metodologia) completando il test del sistema e quindi distribuendo la soluzione
Per esempio
Processo Unificato (UP)
Programmazione estrema (XP)
Processo iterativo incrementale di sviluppo software Scrum
La maggior parte dei processi/metodi utilizza ora uno sviluppo agile e iterativo
Sviluppo agileSviluppo agile
Un processo di sviluppo dei sistemi informativi che enfatizza la flessibilità nell'anticipare nuovi requisiti durante lo sviluppo
Veloce nei piedi; reattivo al cambiamento
Né gli utenti né i membri del team comprendono appieno i problemi e le complessità del nuovo sistema, quindi la pianificazione e l’esecuzione del progetto devono tenere conto dei problemi imprevisti.
Sviluppo iterativoSviluppo iterativo
Un approccio allo sviluppo di sistemi in cui il sistema "cresce" gradualmente attraverso molteplici iterazioni
Completa una piccola parte del sistema (mini-progetto), quindi ripeti il processo per perfezionare e aggiungere altro, quindi ripetere il perfezionamento e aggiungere altro fino al completamento
Vantaggio
1. Parti del sistema possono essere implementate rapidamente
2. Elimina prima una piccola parte da sviluppare, in modo da poter individuare i problemi difficili nel progetto il prima possibile
Sei processi fondamentali per l'iterazione di un progetto
L'area del cerchio rappresenta il carico di lavoro dell'iterazione corrispondente in questo processo.
Ogni iterazione eseguirà più processi con focus diversi.
1.5 Prendere come esempio il sistema di scambio RMO per introdurre il processo di sviluppo
1.5.1 Preparazione
Identificare il problema e documentare gli obiettivi del sistema (processo principale 1)
Investigazioni preliminari
Tradurre i risultati in un documento di visione del sistema (SVD)
Ottenere l'approvazione per avviare il progetto (processo principale 1)
Incontrare le principali parti interessate, inclusa la direzione esecutiva
Incontrare le principali parti interessate, inclusa la direzione esecutiva, per prendere decisioni e approvare piani e budget
SVD (documento di visione del sistema)
Un documento di visione del sistema viene utilizzato per identificare le caratteristiche che andranno a vantaggio dell'azienda e quelle che saranno incluse nel sistema
Fallo in due passaggi
Sviluppare una dichiarazione iniziale dei benefici
Aggiungi stime dettagliate di entrate e costi
Si compone generalmente di tre parti
Descrizione del problema
Capacità del sistema
vantaggi aziendali
1.5.2 Attività del primo giorno
Processo principale 2: pianificazione del progetto
Identificare i componenti principali (aree funzionali) richieste
Dividere il sistema in sottosistemi o componenti
Un sottosistema è una parte del sistema complessivo
Definire le iterazioni e assegnare ciascuna area funzionale alle iterazioni
Pianificare una singola iterazione
Determinare le attività richieste per l'iterazione
Le attività identificate vengono compilate e organizzate in un elenco chiamato struttura di ripartizione del lavoro (WBS)
Esempio
Contenuti della WBS (struttura della pausa lavorativa)
Base di scomposizione (nome)
La base per la decomposizione dipende dai seguenti quattro processi principali
tempo richiesto
Ordine di esecuzione
Misurare il tempo richiesto e la sequenza di esecuzione può aiutare nella costruzione della successiva rete di lavoro e nel calcolo del percorso critico (PERT).
Il percorso critico è il percorso più lungo dell'intera rete. I processi che attraversa devono essere eseguiti rigorosamente. I processi su altri percorsi hanno un certo grado di flessibilità.
Organizzare e mantenere queste attività organizzate per data
Converti la WBS in una pianificazione
Il vantaggio di pianificare iterazioni individuali è che la pianificazione è informale e può essere modificata per soddisfare circostanze impreviste.
Sviluppare una bozza di sequenza di lavoro
Vantaggi della bozza di ordine di lavoro
1. Aiuta a organizzare il lavoro di squadra
2. Fornisce una misura se l'iterazione sta andando come previsto
3. Se il progetto richiederà del tempo secondo questo programma, il leader del progetto può vedere che la programmazione potrebbe richiedere più tempo e risorse e può organizzare le risorse in anticipo per aiutare con questa parte del progetto
Identificare le risorse necessarie (persone) e organizzare il personale per eseguire i compiti corrispondenti
Identificare i membri del team e le responsabilità
1.5.3 Attività del secondo giorno
Svolgere attività preliminari di accertamento dei fatti per comprendere i requisiti. (Processo principale 3)
Il capitolo 2 spiegherà in dettaglio
Sviluppare un elenco preliminare di casi d'uso e un diagramma dei casi d'uso. (Processo principale 3)
Caso d'uso
Un caso d'uso registra un evento aziendale attivato da un singolo utente e la risposta del sistema a tale evento.
Un caso d'uso si riferisce a un esempio o situazione di utilizzo del sistema
Ad esempio: gli agenti di acquisto "utilizzano" questo sistema per "interrogare i fornitori"
I casi d'uso sono generalmente verbi, corrispondenti a requisiti/funzioni
Utilizzare l'esempio dell'elenco dei casi
Esempio di diagramma dei casi d'uso
Sviluppare un elenco preliminare delle classi e un diagramma delle classi. (Processo principale 3)
Classe dell'oggetto
I sistemi di identificazione delle classi di oggetti devono comprendere e tracciare queste cose nel mondo reale.
Le classi di oggetti devono salvare le informazioni nel sistema
Esempio di elenco di classi
Esempio di diagramma di classi
Questo è un diagramma di classi preliminare, quindi sono presenti solo proprietà (caratteristiche statiche)
Il diagramma delle classi di progettazione avrà tipi di dati di attributi e metodi di classe, ecc.
Il diagramma sopra è sviluppato utilizzando l'Unified Modeling Language UML
1.5.4 Attività del terzo giorno
Condurre indagini approfondite per conoscere i dettagli. (Processo principale 3)
Comprendere e documentare il flusso di lavoro dettagliato per ciascun caso d'uso. (Processo principale 3)
Sviluppare descrizioni di casi d'uso e diagrammi di flusso di lavoro
Ecco due modi per documentare i dettagli del caso d'uso
Lo sviluppo di diagrammi di flusso di lavoro richiede l'uso di diagrammi di attività, che sono diagrammi in UML
Esempio di diagramma del flusso di lavoro
Gli ovali nella figura rappresentano i compiti, i diamanti rappresentano i punti decisionali, le frecce rappresentano il flusso della sequenza e le frecce che attraversano la linea centrale rappresentano l'interazione tra l'utente e il sistema.
Definisci l'esperienza dell'utente con schermate e report. (Processi principali 3 e 4)
Definire il layout dello schermo
1.5.5 Attività del quarto giorno
Progettare la struttura del database (schema). (Processo principale 4)
progettazione del tavolo
Parole chiave e identificatori di indice
Tipo di proprietà
integrità referenziale
Esempio di schema di database
Progettare la struttura di alto livello del sistema. (Processo principale 4)
Progetto architettonico complessivo
Definire il diagramma delle classi di progettazione preliminare
Esempio di diagramma di classe di progettazione preliminare
Le classi di progettazione includono le variabili a livello di classe richieste dalla classe, che mostrano anche i nomi dei metodi importanti in ciascuna classe. Gli ultimi elementi in un diagramma delle classi di progettazione sono le frecce, che mostrano quali classi hanno accesso ai metodi di quali altre classi.
Progettazione dell'architettura del sottosistema
1.5.6 Attività del quinto giorno
Proseguire con la progettazione dettagliata (CP4)
Eseguire la programmazione e i test individuali (CP5)
Progettare e programmare non significa progettare il tutto e poi programmare, ma progettare una parte, programmare, quindi progettare una parte e quindi programmare di nuovo.
1.5.7 Attività del sesto giorno
Test completo del sistema (CP6)
Test funzionale complessivo del sistema
Test di accettazione da parte dell'utente
Possibile implementazione di sistemi parziali (CP6)
1.5.8 Revisione della prima iterazione
1.6 Introduzione al contenuto successivo
1.6.1 Prima parte Introduzione allo sviluppo del sistema
Capitolo primo
1.6.2 Parte 2 Attività di Analisi del Sistema
Capitoli 2, 3, 4 e 5
1.6.3 Parte 3 Attività di progettazione del sistema
Capitolo sei e sette
1.6.4 Parte 4 Progetti e gestione dei progetti
Capitolo 8 e 9
1.6.5 Parte 5 Concetti avanzati e concetti di distribuzione
Capitolo 10, 11, 12
cap02 Sondaggio sui requisiti di sistema
2.1 Introduzione
In questo capitolo inizieremo ad espandere l'ambito e i dettagli del processo SDLC per coprire una gamma più ampia di concetti, strumenti e tecniche. Mentre questo capitolo si concentra sulle attività di analisi dei sistemi (il terzo processo principale elencato), i capitoli seguenti discuteranno in dettaglio i modelli sviluppati durante queste attività di analisi dei sistemi. I capitoli successivi ampliano la discussione di altri processi SDLC fondamentali.
2.2CSMS (Sistema completo di vendita e marketing) per RMO
2.2.1 Sistema informativo e architettura esistenti di RMO
L'architettura è divisa in due tipologie
architettura tecnologica architettura tecnologica
L'architettura tecnologica descrive l'insieme di hardware informatico, hardware e topologia di rete e software di sistema utilizzati da un'organizzazione (come sistemi operativi e sistemi di gestione di database).
architettura dell'applicazione architettura dell'applicazione
L'architettura dell'applicazione descrive il modo in cui le risorse software sono organizzate e strutturate per implementare i sistemi informativi di un'organizzazione. Descrive l'organizzazione del software in moduli e sottosistemi, comprese le tecnologie di supporto (come linguaggi di programmazione e ambienti di sviluppo), approcci architetturali (come l'architettura orientata ai servizi) e tecnologie di interfaccia utente (come display di mobile computing, touch screen tecnologia e riconoscimento vocale).
2.1.2 Nuovo CSMS
Il nuovo sistema integrato di vendita e marketing avrà quattro sottosistemi
Sottosistema di vendita
Sottosistema di implementazione dell'ordine
Sottosistema conto cliente
Sottosistema di marketing
2.3 Attività di analisi del sistema
Ci sono cinque parti principali
2.3.1 Raccogliere informazioni dettagliate
Interviste, questionari, documentazione, osservazione dei processi aziendali, ricerca di fornitori, opinioni e suggerimenti
2.3.2 Definire i requisiti
Modellazione dei requisiti funzionali e non funzionali
2.3.3 Priorità dei requisiti
2.3.4 Sviluppare finestre di dialogo dell'interfaccia utente
Il processo di interazione tra utenti e sistema
2.3.5 Valutare i bisogni con gli utenti
Coinvolgimento degli utenti, feedback, adattamento ai cambiamenti
2.4 Cos'è la domanda
I requisiti di sistema sono tutte le attività che il nuovo sistema deve eseguire o supportare e i vincoli che il nuovo sistema deve soddisfare.
I requisiti di sistema sono suddivisi in
richieste funzionali
I requisiti funzionali sono le attività che il sistema deve svolgere (ad esempio, l'azienda a cui verrà applicato il sistema).
Richiede l'esecuzione da parte dell'utente
requisiti non funzionali
I requisiti non funzionali sono caratteristiche che vanno oltre le attività che il sistema deve eseguire o supportare.
Come indicatori di prestazione, vincoli (strumenti di sviluppo, formati di dati, ecc.)
È possibile utilizzare FURPS per dividere semplicemente i requisiti
funzionalità funzionale
disponibilità di usabilità
Affidabilità
Prestazione
Sicurezza
Altri, come condizioni restrittive
requisiti non funzionali
2.5 Modelli e Modellazione
Modello
Un modello è una rappresentazione di alcuni aspetti del sistema in costruzione.
Tipo di modello
modello testuale
relazioni, documenti
modello grafico
Diagramma schematico
modello matematico
formula
linguaggio di modellazione
Lo sviluppo di molti modelli grafici è implementato tramite UML (Unfine Modeling Language)
UML è un insieme di costrutti e simboli di modelli standard definiti dall'Object Management Group, un'organizzazione senza scopo di lucro
2.6 Soggetti interessati
Le parti interessate sono tutti coloro che hanno interesse al successo dell’implementazione del sistema.
Classificazione delle parti interessate
stakeholder interni
Gli stakeholder interni sono persone all’interno dell’organizzazione che interagiscono con il sistema o hanno un interesse significativo nel suo funzionamento o successo.
stakeholder esterni
Gli stakeholder esterni sono coloro che sono al di fuori del controllo e dell’influenza dell’organizzazione,
stakeholder operativi
Gli stakeholder operativi sono persone che interagiscono frequentemente con il sistema nel loro lavoro o nella loro vita.
Esempi: contabili che interagiscono con sistemi di contabilità o fatturazione, operai che interagiscono con sistemi di pianificazione della produzione, clienti che interagiscono con negozi Internet e pazienti che interagiscono con siti Web sanitari, pagine Facebook o feed di notizie di Twitter.
Gestire le parti interessate
Gli stakeholder del management sono coloro che non interagiscono direttamente con il sistema ma utilizzano le informazioni prodotte dal sistema o hanno un significativo interesse finanziario o di altro tipo nel suo funzionamento e successo.
Ad esempio: il senior management e il consiglio di amministrazione di un'organizzazione, le autorità di regolamentazione e le autorità fiscali.
Due tipi di stakeholder importanti
Cliente: la persona che fornisce supporto finanziario
Personale di supporto tecnico del sistema
2.7 Tecnologia di raccolta delle informazioni
Le tecnologie di raccolta delle informazioni includono
2.7.1 Condurre interviste con utenti e altre parti interessate
Servono analisti di sistema
Preparare domande dettagliate
oggetto della domanda
Quale dovrebbe essere il processo aziendale?
Come funzionano i processi aziendali
Quali informazioni sono necessarie
Tipo di domanda
domande aperte
domande chiuse
Oggetto della domanda: vecchio sistema o nuovo sistema
Incontra singoli utenti o gruppi di utenti
Ottieni e discuti le risposte alle domande
registrare la risposta
Segui le informazioni da utilizzare nelle interviste future
2.7.2 Distribuire e raccogliere questionari
Tre tipi di domande
domande chiuse
Guarda i problemi di formato
domande aperte
2.7.3 Controllare input, output e processo
Esistono due fonti di input, output e processi
Documenti aziendali e descrizioni dei processi all'interno dell'organizzazione
Dall'esterno dell'organizzazione: organizzazioni professionali e altre aziende del settore
Controllare la documentazione di elaborazione esistente
2.7.4 Osservare e registrare i processi aziendali
Questo ti aiuterà a capire la funzione dell'azienda
2.7.5 Ricercare soluzioni dei fornitori
Tre vantaggi e un pericolo
1. Lo studio di queste soluzioni può aiutare gli utenti a pensare meglio a come gestire meglio le funzioni aziendali
2. Alcune soluzioni sono già di prim'ordine ed è difficile tenere il passo con la tendenza senza condurre ricerche.
3. Acquistare una soluzione è meno rischioso ed economico che ricercarne una
Pericolo: affrettarsi ad acquistare una soluzione senza indagare tutte le esigenze del sistema
2.7.6 Raccogliere i commenti degli utenti attivi
2.8 Utilizzare il diagramma di attività per registrare il flusso di lavoro
Flusso di lavoro
Un flusso di lavoro è una serie di passaggi di elaborazione che gestiscono completamente una transazione commerciale o una richiesta del cliente.
diagramma di attività
Un diagramma di attività descrive le varie attività dell'utente (o del sistema), le persone che eseguono ciascuna attività e il flusso sequenziale di tali attività.
Simboli e spiegazioni
I puntini di sospensione rappresentano varie attività nel flusso di lavoro. Le frecce di collegamento indicano la sequenza tra le attività. I cerchi neri rappresentano l'inizio e la fine del flusso di lavoro. Il diamante è un punto decisionale in cui il processo seguirà un percorso o un altro. La linea continua spessa è una barra di sincronizzazione che può dividere un percorso in più percorsi simultanei o ricombinare percorsi simultanei. Il titolo della corsia di nuoto rappresenta l'agente che esegue l'attività. Poiché in genere in un flusso di lavoro sono presenti diversi agenti (ovvero persone) che eseguono diverse fasi del processo del flusso di lavoro, i simboli delle corsie di nuoto dividono le attività del flusso di lavoro in gruppi, mostrando quale agente esegue quale attività.
caso d'uso del capitolo 03
3.1 Introduzione
Come i capitoli 4 e 5, questo capitolo introduce le tecniche per documentare i requisiti funzionali creando vari modelli.
Un caso d'uso è un'attività eseguita da un sistema, solitamente in risposta alla richiesta di un utente.
I casi d'uso definiscono i requisiti funzionali
Gli analisti scompongono il sistema in un insieme di casi d'uso (scomposizione funzionale)
I casi d'uso prendono solitamente il nome da verbi o gerundi
3.2 Casi d'uso e obiettivi degli utenti
Una tecnica per definire i casi d'uso è la tecnica degli obiettivi utente, che chiede agli utenti di descrivere i loro obiettivi per l'utilizzo di un sistema nuovo o aggiornato.
Diviso in otto passi
Identificare tutti i potenziali utenti del nuovo sistema
Classificare i potenziali utenti in base ai ruoli funzionali (ad esempio, trasporti, marketing, vendite)
Classificare ulteriormente i potenziali utenti in base al livello organizzativo (ad esempio, operazioni, gestione, esecutivo)
Per ogni tipologia di utente, visitali e trova un elenco di obiettivi specifici che avranno quando utilizzeranno il nuovo sistema (obiettivi attuali e funzionalità innovative che aggiungono valore)
Crea un elenco preliminare di casi d'uso organizzati per tipologia di utente
Trova copie con nomi di casi d'uso simili e risolvi le incoerenze
Determina dove diversi tipi di utenti richiedono gli stessi casi d'uso
Esamina l'elenco completato con ciascun tipo di utente e parti interessate
Generalmente vengono considerati solo gli eventi con requisiti funzionali
Le tecniche di targeting degli utenti sono semplici ma comunemente utilizzate
3.3 Caso d'uso e scomposizione degli eventi
La tecnologia di scomposizione degli eventi è la tecnologia più completa per identificare i casi d'uso
La tecnica di scomposizione degli eventi determina innanzitutto tutti gli eventi aziendali che causeranno la risposta del sistema informativo e ciascun evento porterà a un caso d'uso. Iniziare con gli eventi aziendali aiuta gli analisti a definire ogni caso d'uso al giusto livello di dettaglio
Utilizzato per determinare il livello di dettaglio appropriato per un caso d'uso è l'Essential Business Process (EBP)
L'EBP è un'attività eseguita da una persona in un unico posto per rispondere a eventi aziendali, aggiungere valore aziendale misurabile e portare il sistema e i relativi dati in uno stato stabile e coerente.
Ogni EBP risponde a un evento aziendale nel momento in cui si verifica
3.3.1 Tecnologia di decomposizione degli eventi
evento
Gli eventi si verificano in un momento e in un luogo specifici, possono essere descritti e dovrebbero essere ricordati dal sistema
3.3.2 Tipi di eventi
eventi esterni
Gli eventi esterni sono eventi che si verificano all'esterno del sistema, solitamente avviati da agenti o attori esterni.
Gli agenti esterni (o attori) sono individui o unità organizzative che forniscono o ricevono dati al sistema.
Per esempio
Vari processi aziendali, come l'effettuazione di ordini da parte dell'utente, ecc.
Gli eventi esterni vengono generalmente utilizzati per rispondere alle richieste dell'utente (attore) e si verificano in ambienti di interazione uomo-computer.
Evento temporizzato/tempo temporaneo
Un evento che si verifica in seguito al raggiungimento di un certo punto nel tempo.
Per esempio
Inviare regolarmente rapporti statistici, ecc.
All'interno del sistema si verificano eventi temporanei
evento di stato
Gli eventi di stato si verificano quando si verifica un evento all'interno del sistema che attiva un requisito di elaborazione.
Causato quando lo stato cambia
Generalmente si tratta di requisiti non funzionali e spesso non vengono presi in considerazione.
3.3.3 Definire eventi
Evento/Precondizione/Risposta
Gli analisti devono considerare una sequenza di eventi e quindi identificare gli eventi che effettivamente influenzano il sistema
sequenza di eventi
È utile tenere traccia di una serie di eventi accaduti a una specifica entità o attore esterno
Eventi di dipendenza tecnologica e controllo del sistema
A volte gli analisti si preoccupano di eventi importanti per il sistema ma non direttamente correlati agli utenti o alle transazioni. Questi eventi in genere coinvolgono scelte di progettazione o controlli di sistema. Gli analisti dovrebbero ignorare temporaneamente questi eventi durante l'analisi.
I controlli di sistema sono controlli o procedure di sicurezza progettati per proteggere l'integrità di un sistema
Backup dei dati, login, ecc.
Durante la fase di analisi utilizzeremo ipotesi tecniche ideali
L'ipotesi della tecnologia perfetta afferma che gli eventi si verificano solo quando il sistema deve rispondere in condizioni perfette (ad esempio, il dispositivo non si guasta mai, la potenza di elaborazione e archiviazione è illimitata e le persone che gestiscono il sistema sono completamente oneste e non commettono mai errori). inclusi nel processo di analisi.
3.3.4 Utilizzare la tecnologia di scomposizione degli eventi
1. Considerare gli eventi esterni nell'ambiente del sistema che richiedono una risposta del sistema
2. Per ogni evento esterno, identificare e nominare il caso d'uso richiesto dal sistema.
3. Utilizzare una lista di controllo per considerare gli eventi temporali che richiedono una risposta del sistema.
4. Per ogni evento temporale, identificare e denominare i casi d'uso richiesti dal sistema, quindi stabilire il punto temporale che attiva il caso d'uso.
5. Considerare gli eventi di stato a cui il sistema può rispondere, soprattutto se si tratta di un sistema in tempo reale in cui le modifiche del dispositivo o dello stato interno attivano casi d'uso.
6. Per ciascun evento di stato, identificare e denominare il caso d'uso richiesto dal sistema, quindi definire la modifica dello stato.
7. Dopo aver definito eventi e casi d'uso, verificare se richiedono presupposti tecnici perfetti. Non includere eventi che coinvolgono controlli di sistema come accesso, disconnessione, modifica password e backup o ripristino del database, poiché questi vengono inseriti come controlli di sistema.
3.4 Casi d'uso e CRUD
Un’altra tecnologia importante per convalidare e perfezionare i casi d’uso è la tecnologia CRUD.
CRUD significa
Creare
Leggi leggi
Aggiorna, aggiorna
Cancella, cancella
Si tratta di operazioni legate alla gestione del database
Le tecniche CRUD sono molto utili se utilizzate insieme alle tecniche di targeting degli utenti come controllo incrociato. Invece di utilizzarlo direttamente come metodo per identificare i casi d'uso, potrebbe far sì che i casi d'uso non tengano traccia molto bene del processo aziendale.
Può verificare se sono presenti tipi di casi d'uso mancanti
Passi della tecnologia CRUD
1. Identificare tutte le entità dati o classi di dominio coinvolte nel nuovo sistema.
2. Per ciascun tipo di dati (entità dati o classe di dominio), verificare di aver identificato i casi d'uso per la creazione di nuove istanze, l'aggiornamento delle istanze esistenti, la lettura o il reporting dei valori delle istanze e l'eliminazione (archiviazione) delle istanze.
3. Se un caso d'uso richiesto viene ignorato, aggiungere un nuovo caso d'uso e identificare le parti interessate.
4. Per le applicazioni integrate, assicurarsi che sia chiaro quale applicazione è responsabile dell'aggiunta e della gestione dei dati e quale sistema utilizza solo i dati.
3.6 Diagramma dei casi d'uso
I diagrammi dei casi d'uso sono modelli UML utilizzati per visualizzare graficamente i casi d'uso e la loro relazione con gli utenti.
3.6.1 Casi d'uso, attori e simboli
Nella maggior parte dei casi d’uso sono implicite le persone che utilizzano il sistema, che finora abbiamo definito utenti. In UML questa persona è chiamata attore. Gli attori sono spesso al di fuori dei confini dell'automazione
Nel diagramma dei casi d'uso, il simbolo umano rappresenta l'attore, l'ovale rappresenta il caso d'uso, il bordo rettangolare rappresenta il confine dell'automazione e la connessione tra il caso d'uso e l'attore rappresenta quale attore partecipa a quale caso d'uso.
Esempio
Non solo esistono relazioni tra casi d’uso e attori, ma possono esserci anche relazioni tra casi d’uso.
Questa è una dipendenza tra i casi d'uso e si presenta in due forme Utilizzare le frecce tratteggiate e << >> per indicare
<<includere>>
Può essere intesa come una relazione d'uso, che si riferisce all'utilizzo di un caso d'uso in un altro caso d'uso. Il caso d'uso indicato dalla freccia è il caso d'uso utilizzato (dipendente). Questa relazione richiede che un caso d'uso debba essere utilizzato in un altro caso d'uso
<<esteso>>
Questa relazione indica che un caso d'uso può utilizzare un altro caso d'uso. In questa relazione ci sarà qualcosa chiamato punto di estensione. Ad esempio, in un sistema di gestione di una biblioteca, il caso d'uso della restituzione dei libri può comportare sanzioni (timeout, ecc.).
La connessione tra i due è che sono entrambe relazioni tra casi d'uso ed entrambe significano l'utilizzo di un altro caso d'uso in un caso d'uso. La differenza tra i due è che include significa che verrà sicuramente utilizzato un altro UC, mentre esteso richiede di giudicare l'estensione punto prima di decidere se utilizzarlo o meno
cap04 modello di dominio
4.1 Introduzione
Concetti fondamentali: Cose nel dominio dei problemi dell'utente del sistema
4.2 Cose nel dominio del problema
Il dominio problematico si riferisce all'area specifica dell'attività degli utenti inclusa nel nuovo sistema.
Le classi o entità di dominio sono ciò con cui gli utenti finali devono lavorare in studio. Queste vengono spesso definite "cose" nel dominio dei problemi di sistema.
Per esempio
prodotti, ordini, clienti
4.2.1 Metodo 1 per definire le cose nell'ambito del problema - metodo del brainstorming
1. Identificare un utente e una serie di casi d'uso.
2. Brainstorming con gli utenti per identificare gli elementi coinvolti nell'esecuzione del caso d'uso, ovvero gli elementi su cui il sistema dovrebbe acquisire informazioni.
3. Utilizza i tipi di cose (categorie) per porre sistematicamente domande su cose potenziali, ad esempio: memorizzi informazioni su cose tangibili? Ci sono luoghi coinvolti? Quali ruoli devi ricordare?
4. Continuare a lavorare con una varietà di utenti e parti interessate per espandere l'elenco di brainstorming.
5. Combina i risultati, elimina eventuali duplicati e compila un elenco iniziale.
4.2.2 Metodo 2 per definire le cose nell'ambito del problema: tecnologia nominale
Elenca tutti i nomi menzionati dagli utenti I nomi usati per descrivere eventi, casi d'uso o attori sono cose potenziali.
fare un passo
1. Identificare tutti i nomi utilizzando casi d'uso, attori e altre informazioni sul sistema (inclusi input e output).
2. Utilizzando i sistemi esistenti, le procedure attuali e altre informazioni provenienti da rapporti o moduli attuali, aggiungere elementi o categorie di informazioni richieste. Alcuni di questi elementi potrebbero essere elementi aggiuntivi, mentre altri potrebbero essere informazioni più specifiche (chiamate attributi) su elementi già identificati. Affina l'elenco e poi registra le ipotesi o le domande che desideri esplorare.
3. Man mano che viene creato questo elenco di nomi, dovrai perfezionarlo.
Poni le seguenti domande per ciascun sostantivo per aiutarti a decidere se deve essere incluso:
È qualcosa di unico che il sistema deve sapere?
Rientra nell'ambito del sistema che sto sviluppando?
Il sistema deve ricordare più di uno degli elementi sopra indicati?
Rivolgi le seguenti domande su ciascun nome per decidere se deve essere escluso:
È davvero un sinonimo di qualcos'altro che ho identificato?
È davvero solo l'output del sistema basato su altre informazioni che ho identificato?
È davvero solo un input che porta a registrare altre informazioni che ho identificato?
Poni le seguenti domande su ciascun nome per decidere se dovrebbe essere studiato:
È possibile che si tratti di informazioni specifiche (proprietà) su altre cose che ho identificato?
Se le ipotesi cambiano, potrei averne bisogno?
4. Crea un elenco principale di tutti i nomi identificati e poi indica se ciascun nome deve essere incluso, escluso o studiato ulteriormente.
5. Esamina l'elenco con utenti, stakeholder e membri del team, quindi perfeziona l'elenco delle cose nell'ambito del problema.
Esempio
4.2.3 Proprietà delle cose
La maggior parte dei sistemi memorizza alcune informazioni specifiche sulle transazioni chiamate attributi
Un attributo che identifica qualcosa in modo univoco è chiamato identificatore o parola chiave (chiave/codice)
Gli attributi compositi sono composti da più attributi correlati, come indirizzo, nome completo, ecc.
4.2.4 Relazioni tra le cose
L'associazione si riferisce alla relazione naturale tra certe cose.
In UML esistono circa quattro tipi di relazioni tra le cose
associazione
generalizzazione generazionale
dipendenzadipendenza
strumento
dettagli associati
ha un nome
C'è una direzione, e la cosa puntata dalla freccia non può vedere l'altra (cioè, l'altro dipende dalla cosa puntata dalla freccia, e la cosa puntata cambia nell'altra, ma viceversa non ha alcun effetto)
Ad esempio, A->B è detto A dipendente da B.
L'associazione è molteplicità, cioè il rapporto quantitativo tra una cosa e un'altra cosa
esempio
Esistono restrizioni sulla cardinalità tra le associazioni
elemento associato
Un'associazione consiste di diversi tipi di cose, e il numero di queste cose è l'arietà dell'associazione
Cliente e ordine, relazione binaria
Associazione tra cose simili, un elemento
Tre o più tipi diversi di cose sono correlati, molteplici
4.3 Diagramma Entità-Contatto
Questo è un modello per la modellazione di database
I rettangoli rappresentano le entità e le linee che collegano i rettangoli rappresentano le connessioni tra le entità.
rappresentazione simbolica
Solo le linee verticali vengono troncate per rappresentare che ce n'è solo una
Le linee verticali vengono tagliate e cerchiate per rappresentare 0 o 1
Un cerchio con una linea trasversale indica 0 o più
Le linee verticali tagliate e le linee biforcate rappresentano uno o più
La direzione corrispondente al numero va da senza segno a con segno
Negli attributi dell'entità, il codice primario (identificatore) viene inserito nella prima riga e PK viene contrassegnato per indicare che si tratta del codice primario.
Esempio
Un cliente corrisponde a 0 ordini multipli; un ordine corrisponde ad uno ed un solo cliente
4.4 Diagramma delle classi del modello di dominio
La classe di cose in questione è chiamata classe di dominio
In UML, il diagramma delle classi viene utilizzato per visualizzare le classi di oggetti del sistema
Diagramma delle classi del modello di dominio
Utilizzato per visualizzare elementi nel dominio problematico dell'utente
Diagramma delle classi di progettazione
per la progettazione
rappresentazione simbolica
In un diagramma delle classi, i rettangoli rappresentano le classi e le linee rette che collegano i rettangoli rappresentano le relazioni tra le classi.
Il rettangolo è composto da due parti (diagramma delle classi del modello di dominio, diagramma delle classi di progettazione composto da tre parti: nome della classe, attributi, metodi), la parte superiore è il nome della classe e la parte inferiore sono gli attributi della classe
I nomi delle classi e degli attributi utilizzano la denominazione cammello. La prima lettera del nome della classe è in maiuscolo e la prima lettera del nome dell'attributo è in minuscolo.
4.4.1 Notazione del diagramma classi del modello di dominio
simbolo della molteplicità
Rappresenta il numero di relazioni tra istanze di classe, simile alla molteplicità dei diagrammi delle relazioni tra entità
Esempio
La molteplicità qui è simile alla cardinalità di mappatura del diagramma delle relazioni tra entità.
Applicazione del diagramma delle classi di dominio specifico
Questo è un diagramma di classe del modello di dominio per la selezione del corso degli studenti. Un corso può avere da 0 a più sezioni, ma una sezione può appartenere e deve appartenere a un solo corso e le sezioni hanno una relazione molti-a-molti ed entrambe possono esserlo zero; Esiste una classe di associazione tra studenti e corsi, contrassegnata da una linea tratteggiata, con un attributo di voto
4.4.2 Questioni più complesse riguardanti le classi di oggetti
Esistono tre tipi di relazioni nelle classi di dominio
associazione
Generazione di generalizzazione/specializzazione
La base della relazione generalizzazione/specializzazione è che le persone classificano le cose in base a somiglianze e differenze.
La relazione generalizzazione/specializzazione viene utilizzata per strutturare o ordinare queste cose dal più generale al più specifico.
Ogni classe nella gerarchia può avere sopra di sé una classe più generale, chiamata superclasse.
Una classe può avere una classe più specializzata al di sotto di essa, chiamata sottoclasse.
L'ereditarietà consente alle sottoclassi di condividere le caratteristiche della loro superclasse.
Usa una freccia triangolare per indicare la super classe
Esempio
Utilizzare il corsivo per etichettare le classi astratte
Le classi astratte non possono essere istanziate e possono solo essere ereditate
Esiste anche una classe concreta, che è una classe che può avere oggetti istanza.
Le superclassi sono talvolta concrete o astratte
Parte intera
La relazione globale/parte viene utilizzata per esprimere la relazione tra una classe e le altre classi contenute in questa classe.
polimerizzazione
In una relazione di aggregazione, i componenti possono esistere in modo indipendente
Usa diamanti cavi per rappresentare
combinazione
In una relazione combinata, ciascuna parte non può esistere indipendentemente una volta collegata.
Usa un diamante solido per rappresentare
Capitolo05 Estensione del modello dei requisiti
5.2 Descrizione del caso d'uso
Le descrizioni dei casi d'uso descrivono i dettagli di ciascun caso d'uso.
Descrizione semplice del caso d'uso
Adatto a scenari singoli e meno eccezioni
Esempio
Descrizione del caso d'uso completamente sviluppata
Per alcuni casi d'uso più complessi, è richiesta una descrizione del caso d'uso completamente estesa.
Modello standard
Usa il nome del caso
Scenari di casi d'uso
evento scatenante
Breve descrizione
partecipanti
Altri casi d'uso ad esso associati e come è associato
Parti interessate
Prerequisiti
I prerequisiti determinano lo stato del sistema quando inizia un caso d’uso, inclusi gli oggetti che devono già esistere, le informazioni che devono essere disponibili e persino le condizioni per gli attori prima dell’inizio del caso d’uso.
Condizioni successive
Le postcondizioni determinano cosa deve essere vero una volta completato il caso d'uso. Ancora più importante, indicano quali nuovi oggetti il caso d'uso crea o aggiorna e come gli oggetti devono essere correlati.
flusso di attività
Flusso di attività inclusi partecipanti (utenti) e sistema
situazione anomala
Il flusso di attività per ciascun caso d'uso può essere molto diverso, a seconda dell'attore che invoca il caso d'uso. I diversi flussi di attività sono chiamati scenari, noti anche come istanze dei casi d'uso;
5.3 Diagramma delle attività dei casi d'uso
Un modo per registrare i casi d'uso è utilizzare i diagrammi di attività. Abbiamo imparato a utilizzare i diagrammi di attività per creare flussi di lavoro nel Capitolo 2. Utilizzeremo i diagrammi di attività qui per registrare il flusso di attività dei casi d'uso.
Esempio
Questo diagramma di attività mostra il flusso di attività della registrazione del caso d'uso della registrazione del cliente.
5.4 Diagramma sequenza sistema SSD
Il diagramma di sequenza del sistema viene utilizzato per descrivere il flusso di informazioni in entrata e in uscita da un sistema di automazione
Utilizza simboli umani per rappresentare gli attori dei casi d'uso e bordi rettangolari per rappresentare i confini dell'automazione
Il rettangolo è contrassegnato: sistema (con due punti), che indica l'impianto automatizzato
C'è una linea tratteggiata sotto i partecipanti e il sistema, chiamata ancora di salvezza, che rappresenta il ciclo di vita dei partecipanti e del sistema, e il tempo scorre in una direzione dall'alto verso il basso.
C'è l'invio e la ricezione di messaggi tra i partecipanti e l'ancora di salvezza del sistema
L'invio dei messaggi è rappresentato da una linea continua, con la direzione dal partecipante al sistema
I messaggi ricevuti sono rappresentati da linee tratteggiate con direzione dal sistema al partecipante
Rappresentazione simbolica completa del messaggio
(*)[Condizione Vero/Falso] Valore restituito:=Nome del messaggio (lista parametri)
* indica il ciclo
[] rappresenta le condizioni vero e falso. Se l'interno è vero, il messaggio verrà inviato, altrimenti non verrà inviato.
Il nome del messaggio è una descrizione del messaggio inviato
L'elenco dei parametri rappresenta le informazioni da passare
Inoltre, ci sono alcuni quadri alternativi
alterazione del ciclo
Se più messaggi vengono inviati e ricevuti in un ciclo, potrebbe essere preferibile utilizzare un framework alternativo.
La cornice alternativa consiste nell'utilizzare una cornice rettangolare per selezionare la parte da mettere in loop ed esprimere il loop per tutti gli elementi nell'angolo in alto a sinistra
seleziona altera
Il frame alternativo di select viene utilizzato insieme ad else. Utilizza un frame rettangolare per selezionare l'area di selezione. Utilizza le linee tratteggiate per distinguere i messaggi inviati in circostanze diverse e contrassegnali separatamente nella parte finale dell'invio del messaggio.
5.4.2 Sviluppare SSD
1. Confermare il messaggio immesso
2. Utilizzare i simboli dei messaggi per descrivere le informazioni trasmesse al sistema dall'esterno
3. Aggiungere condizioni specifiche al messaggio di input, inclusi cicli e condizioni vero/falso
4. Conferma e aggiungi il messaggio di reso
5.5 Diagramma della macchina a stati Diagramma della macchina a stati
Lo stato di un oggetto è una condizione che si verifica durante la sua vita quando vengono soddisfatte determinate condizioni, vengono eseguite determinate azioni o è atteso qualche evento.
La transizione di stato è l'attività di un oggetto che si sposta da uno stato all'altro.
funzione di transizione di stato
Nome della conversione (parametro,...) [condizione di giudizio]/descrizione del comportamento
Un'espressione di azione rappresenta un processo che deve verificarsi prima che la transizione sia completa e l'oggetto raggiunga lo stato di destinazione.
Una condizione è un qualificatore o un test per una transizione, è semplicemente una condizione vero/falso che deve essere soddisfatta prima che la transizione possa essere attivata.
5.5.1 Stato composito e stato simultaneo
Essere in più stati contemporaneamente è chiamato concorrenza o stati concorrenti.
Rappresentato utilizzando percorsi simultanei simili ai diagrammi di attività, un percorso è un insieme ordinato di transizioni di stato interconnesse.
Stati annidati all'interno di altri stati di livello superiore. Questi stati di livello superiore sono chiamati stati compositi.
Gli stati compositi sono rappresentati da stati di alto livello annidati in stati di basso livello
Esempio
Quando la stampante è accesa (stato composito), ha due percorsi simultanei, ovvero la parte del vassoio carta e la parte di stampa. Le due parti sono indipendenti; quando si preme il pulsante di accensione si accende e quando si preme il pulsante di spegnimento premuto si spegne. Non ci sono restrizioni.
5.5.2 Regole per lo sviluppo dei diagrammi delle macchine a stati
Visualizza il diagramma delle classi e seleziona le classi che potrebbero richiedere lo stato
Per ciascuna classe selezionata nel gruppo, elenca tutte le condizioni di stato che puoi determinare
Inizia a costruire un frammento del diagramma della macchina a stati identificando le transizioni che fanno sì che un oggetto lasci lo stato identificato
Disporre queste combinazioni di transizioni di stato nell'ordine corretto
Controlla questi percorsi e cerca percorsi simultanei indipendenti
Trova altre conversioni
Espandi ogni transizione con eventi di messaggio, condizioni di guardia ed espressioni di azione appropriati
Controllare e testare ogni diagramma della macchina a stati
5.6 Integrazione dei modelli di domanda
La relazione tra i diversi modelli di domanda
diagramma dei casi d'uso
Descrizione del caso d'uso
diagramma di attività
SSD
Diagramma delle classi del modello di dominio
Diagramma della macchina a stati
La relazione è descritta dalla figura seguente
La freccia punta nella direzione dall'elemento dipendente all'elemento dipendente
Le linee continue rappresentano le dipendenze primarie, le linee tratteggiate rappresentano le dipendenze secondarie e alcune frecce sono bidirezionali, indicando un'influenza reciproca.
cap06 Punti fondamentali della progettazione e attività di progettazione
6.1 Introduzione
Nella fase di analisi discuteremo principalmente di cosa fa il sistema (come i requisiti), mentre nella fase di progettazione discuteremo principalmente di come il sistema soddisfa questi requisiti;
L'input e l'output della progettazione del sistema non sono l'input e l'output del sistema: l'input della progettazione del sistema è il risultato dell'analisi del sistema, cioè i requisiti e i relativi modelli, mentre l'output della progettazione del sistema è una soluzione più dettagliata
6.2 Elementi di progettazione
6.2.1 Cos’è la progettazione del sistema?
La progettazione del sistema è un processo di collegamento tra l'analisi e l'implementazione del sistema con lo scopo di definire, organizzare e costruire i componenti della soluzione finale come un progetto per la costruzione
6.2.2 Componenti principali e livelli di progettazione
Componenti principali
progettazione ambientale
Descrive le reti, l'hardware, ecc. che collegano insieme il sistema
progettazione dell'applicazione
Programma per computer
Progettazione dell'interfaccia utente
Schermate, report e controlli definiti per input e output
Progettazione di banche dati
Struttura della base di dati
Progettazione dell'interfaccia di sistema
Descrive la comunicazione con altri sistemi
Progettazione della sicurezza e del controllo
due livelli
Progetto di architettura
Chiarire l'intera struttura e la forma della soluzione, ovvero la progettazione ampia della struttura complessiva del sistema
Chiamato anche progettazione complessiva o progettazione concettuale
progettazione dei dettagli
Include dettagli di programmazione specifici
Esempio
Progettazione per caso d'uso
Progettazione di banche dati
Progettazione dell'interfaccia utente e dell'interfaccia di sistema
Progettazione della sicurezza e del controllo
6.3 Input e output della progettazione del sistema
Convertire informazioni come modelli di analisi e documenti ottenuti dall'analisi del sistema in un modello che rappresenta il sistema della soluzione
Modello analitico
Diagramma delle classi
Diagramma dei casi d'uso UCD
Diagramma di sequenza del sistema SSD
Descrizione del caso d'uso
Diagramma della macchina a stati
diagramma di attività
modello di progettazione
Mappa dei pacchetti
Nodo e grafico della posizione
Diagramma delle classi di progettazione
Diagramma di flusso
Schema della banca dati
Interfaccia utente e sistema
Controllo della sicurezza del sistema
Diagramma di collaborazione
6.4 Attività di progettazione
Le attività di progettazione sono la progettazione dei sei componenti di cui sopra. Ciascuna attività di progettazione ha problemi chiave corrispondenti.
progettazione ambientale
Abbiamo dettagliato l'ambiente in cui verrà eseguito il software e tutte le varie opzioni?
Architettura dell'applicazione e progettazione del software
Abbiamo dettagliato tutti gli elementi del software e come viene eseguito ogni caso d'uso?
progettazione dell'interfaccia utente
Abbiamo dettagliato come questo sistema comunicherà con tutti gli altri sistemi all'interno e all'esterno dell'organizzazione?
Progettazione dell'interfaccia del sistema
Abbiamo dettagliato il modo in cui gli utenti interagiranno con il sistema per eseguire tutte le loro attività [casi d'uso]?
Progettazione di banche dati
Abbiamo specificato tutti i requisiti di archiviazione delle informazioni, inclusi tutti gli elementi dello schema?
Progettazione della sicurezza e del controllo
Abbiamo dettagliato tutti gli elementi necessari per garantire che i sistemi e i dati siano sicuri e protetti?
6.4.1 Ambiente di progettazione
L'ambiente è tutta la tecnologia necessaria per supportare un'applicazione software
Server, computer desktop
dispositivi mobili, sistemi operativi
Abilità comunicativa, capacità di input e output
L’abbiamo chiamata architettura tecnica nel capitolo 2
6.4.2 Progettare l'architettura e il software dell'applicazione
Dividere il sistema in sottosistemi
Definire l'architettura del software (progettazione architettonica)
Architettura a tre livelli MVC, ecc.
Progettazione dettagliata di ciascun caso d'uso
Diagramma delle classi di progettazione
Diagramma di flusso
Diagramma della macchina a stati
6.4.3 Progettare l'interfaccia utente
La progettazione del dialogo inizia con i requisiti
Il design aggiunge layout dello schermo, aspetto grafico, navigazione ed esperienza utente
Progetta interfacce diverse per dispositivi diversi
6.4.4 Progettare l'interfaccia del sistema
I sistemi informativi interagiscono con molti altri sistemi interni ed esterni
Le interfacce di sistema si collegano ad altri sistemi in molti modi diversi
6.4.5 Banca dati di progettazione
Inizia con un diagramma di classi del modello di dominio (o ERD)
Seleziona la struttura del database
Architettura del design (distribuito, ecc.)
Progettare lo schema del database
Tabella, colonna degli attributi
Vincoli di integrità dei riferimenti di progettazione
6.4.6 Progettare la sicurezza e i controlli del sistema
Lo scopo è proteggere le risorse di un'organizzazione, fondamentali nel mondo Internet e wireless
Controlli dell'interfaccia utente
controllo dell'applicazione
Controllo della banca dati
controllo della rete
6.5 Come progettare l'ambiente
Progetta in locale
Esistono due tipi di sistemi software locali
Sistema software autonomo
Esegui da un dispositivo senza rete
Sistema interno basato sul web
Distribuzione hardware: LAN
architettura client-server
Sistema applicativo desktop (client-server)
Sistema applicativo basato su browser (browser-server)
Utilizza Hypertext Markup Language come pagina
Utilizzare il protocollo TCP/IP come protocollo di trasporto
Architettura client/server a tre livelli
Un modo efficace per progettare il software è separare l'interfaccia utente e i livelli della logica aziendale e separare il livello della logica aziendale e il livello di accesso ai dati. Questo metodo di progettazione dei programmi è chiamato architettura a tre livelli. L'idea di base è dividere il software in tre livelli
Livello vista: responsabile della ricezione dell'input dell'utente e dell'elaborazione in output formattato
Livello logico/Livello del dominio Livello del dominio: responsabile delle regole e delle procedure che implementano i processi aziendali o di elaborazione
Livello dati: responsabile della gestione dei dati archiviati, che solitamente esistono in uno o più database
È possibile eseguire più livelli su un singolo computer oppure ciascun livello può essere gestito da un computer separato. I livelli complessi possono essere distribuiti su due o tre livelli distribuendo la funzionalità del livello o implementando il bilanciamento del carico su computer ridondanti
Un'altra idea progettuale è MVC, ovvero Model-View-Controller
Progettare la distribuzione esterna
Le domande importanti includono
Configurazione per la distribuzione su Internet
La protezione dei dati avviene tramite Hypertext Transfer Protocol Security (HTTPS). Le pagine web servite dal protocollo HTTPS vengono trasmesse in forma crittografata, che è più sicura dell'HTTP.
Utilizza strutture server multilivello, bilanciamento del carico e reti di distribuzione dei contenuti (CDN) per aumentare le prestazioni
La struttura del server multilivello include il server delle applicazioni e il server del database
Le richieste vengono inviate a diversi server del data center tramite computer di bilanciamento del carico
Quando accedi ad alcune immagini o video statici, puoi utilizzare un CDN indipendente per inviarli
Opzioni di hosting per distribuzioni Internet
affitto del locale
Fornire ai clienti un data center sicuro in cui posizionare i computer server Il vantaggio è che non ci sono costi fisici, sicuri e complessi per il data center.
Servizi gestiti
Fornisce servizi aggiuntivi tra cui la gestione di sistemi operativi, server di rete, server di database, ecc. Il vantaggio è che non è necessario assumere dipendenti per gestire i sistemi server e il software di sistema.
server virtuale
I clienti possono noleggiare server virtuali, di dimensioni fisse
cloud computing
I clienti devono acquistare solo la capacità di calcolo di cui hanno bisogno e che utilizzano e, quando la capacità di calcolo aumenta, il cloud fornirà automaticamente più capacità. Questa soluzione può far risparmiare sui costi perché non è necessario acquistare capacità non necessaria
Per tutte le alternative esiste un Service Level Agreement (Service Level Agreement), che fa parte del contratto tra l'impresa e la società di hosting per garantire uno specifico livello di disponibilità del sistema.
Diversità dei dispositivi dei clienti distribuiti per Internet
computer
Dispositivo tablet di medie dimensioni
piccolo dispositivo mobile
Progettazione per ambienti remoti e distribuiti
Distribuzione remota tramite rete privata virtuale (VPN)
Una VPN è una rete costruita su una rete pubblica come Internet. Fornisce una rete sicura e collegabile per gruppi privati
cap07 Progettare l'interfaccia utente e l'interfaccia di sistema
7.2 Interfaccia utente e interfaccia di sistema
L'interfaccia utente contiene input e output che richiedono l'intervento diretto dell'utente.
L'interfaccia del sistema richiede input e output manuali minimi
7.3 Comprendere l'interfaccia utente
L'interfaccia utente ha tre componenti
Significato fisico: scrivanie e sedie da ufficio, lampade, tastiere, mouse, touch screen
Significato percepito: colori, forme, trame, caratteri, finestre, menu, pulsanti
Significato concettuale: cliente, partecipante, ordine, trasporto, feedback
La prospettiva progettuale dell'interfaccia utente è centrata sull'utente, enfatizzando l'interazione tra uomo e computer (interazione uomo-computer)
L'interazione uomo-computer è un campo che studia l'efficienza e l'efficacia dell'interazione dell'utente con i sistemi informatici, le tecniche di input e output orientate all'uomo e gli aspetti psicologici delle interfacce utente
Tre principi base del design centrato sull'utente
Concentrati fin dall'inizio sugli utenti e sul loro lavoro
Valutare il sistema per garantirne l'usabilità
Utilizzare lo sviluppo iterativo
Metafore per l'interazione uomo-computer
Le metafore sono analogie tra le funzionalità dell'interfaccia utente e le entità fisiche familiari agli utenti
Le metafore sono ampiamente utilizzate nella progettazione dell'interfaccia utente nelle seguenti situazioni:
manipolazione diretta
Manipola oggetti fisici direttamente sul display o oggetti che li rappresentano
Esempio: l'utente trascina una cartella nel Cestino
metafora del desktop
Organizza la visualizzazione in diverse aree, con un ampio spazio di lavoro vuoto al centro circondato da una serie di icone degli strumenti
Esempio: desktop di Windows
metafora del documento
Visualizza i dati come una pagina o una tabella
Esempio: documento di istruzioni per l'utente, ecc.
metafora conversazionale
Gli utenti e i computer completano le attività impegnandosi in comunicazioni o dialoghi utilizzando testo, voce o altri strumenti
Esempio: finestra cmd
I primi tre enfatizzano gli oggetti che interagiscono con l'utente, mentre la metafora conversazionale enfatizza la comunicazione che avviene tra l'utente e il computer.
7.4 Concetti di progettazione dell'interfaccia utente
7.4.1 Tempestività e visibilità
Indicativo si riferisce all'aspetto di un controllo che ne riflette le prestazioni
Visibilità significa che il controllo è visibile
7.4.2 Coerenza
7.4.3 Scorciatoie
7.4.4 Feedback
7.4.5 Dialogo completo
7.4.6 Gestione degli errori
7.4.7 Annulla azione
7.4.8 Ridurre il carico sulla memoria a breve termine
7.5 Dall'analisi alla progettazione dell'interfaccia utente
7.5.1 Casi d'uso e gerarchia dei menu
I menu sono un modo per organizzare un gran numero di casi d'uso o conversazioni correlati in un'interfaccia utente
Il progettista dovrebbe stimare la gerarchia dei menu in base al numero di casi d'uso
Un livello di menu contiene solitamente 5-10 opzioni
7.5.2 Dialogo e storyboard
È necessario registrare le conversazioni di cui gli utenti hanno bisogno
Storyboard: visualizza questa serie di schizzi dello schermo nella conversazione
7.6 Progettazione dell'interfaccia utente
7.6.1 Linee guida per la progettazione di moduli e tabelle
Layout e formattazione dell'interfaccia
Coerenza, etichette e titoli, distribuzione e ordine, caratteri e colori
inserimento dati
Casella di testo, casella di riepilogo, casella combinata, pulsante di opzione, casella di controllo
Orientamento e controllo di supporto
Minimizza, massimizza, chiudi, barre di scorrimento, ridimensiona
7.6.2 Linee guida aggiuntive per le interfacce del browser
consistenza
Cascading Style Sheets (CSS) - Uno standard di codifica delle pagine Web che consente ai progettisti di siti Web di specificare parti di una pagina che hanno sempre lo stesso aspetto e parti che variano a seconda dell'attività o del pubblico.
Considerazioni sulle prestazioni
Sensibile alle connessioni di rete, alla quantità di informazioni trasferite, al tipo di informazioni trasferite
Immagini, video e suoni
Ci saranno problemi di compatibilità
Utenti speciali (disabilità)
Tecnologia assistiva: software che adatta le interfacce utente alle esigenze speciali delle persone con disabilità (come gli strumenti di sintesi vocale e di riconoscimento vocale)
7.6.3 Linee guida aggiuntive per le interfacce dei dispositivi mobili
Sfide nella progettazione dell'interfaccia utente per i dispositivi mobili
Schermi piccoli, tastiere e touch screen, capacità di rete limitata, linee guida e kit di strumenti per la progettazione delle applicazioni
7.7 Determinare l'interfaccia del sistema
Le interfacce di sistema sono generalmente definite come input e output che non richiedono alcun intervento o un intervento minimo da parte dell'utente.
Diviso nelle seguenti categorie
Ingresso e uscita da altri sistemi
XML (Extensible Markup Language) può essere utilizzato per lo scambio elettronico di dati e la comunicazione tra sistemi
XML implementa l'incorporamento di strutture dati personalizzate rispetto a HTML
Input e output altamente automatizzati
Input e output da database esterni
7.8 Input del sistema di progettazione
7.8.1 Dispositivi di input automatizzati
Lo scopo principale di qualsiasi immissione di dati è fornire o aggiornare dati privi di errori nel sistema. La cosa più importante è evitare errori il più possibile. Ecco diversi modi per evitare errori in modo efficace.
Utilizzare dispositivi di input automatizzati
Evitare il più possibile l’intervento umano
Se le informazioni di input possono essere ottenute da un foglio di calcolo, utilizzare il foglio di calcolo senza reinserire i dati
Verificare e correggere i dati
7.8.2 Definire i dettagli di input del sistema
7.9 Progettare gli output del sistema
Progettare report, estratti conto e documenti di restituzione
Tipo di rapporto
Report dettagliato: contiene informazioni dettagliate sul processo aziendale
Rapporto di riepilogo: questo tipo di rapporto viene utilizzato per riassumere le attività per fasi.
Rapporto anomalo: generato quando i risultati della transazione o dell'operazione sono anomali.
Reporting esecutivo: valutare la salute e le operazioni generali
L'output interno viene generato per uso interno dell'organizzazione o unità. I report discussi in precedenza appartengono all'output interno; l'output esterno viene generato per l'utilizzo da parte di membri esterni dell'organizzazione, come informazioni sulla conferma dell'ordine, estratti conto mensili, ecc. Perché è un documento commerciale ufficiale generato per estranei e richiede una qualità superiore
Esiste un tipo di output esterno chiamato documento di reso. L'output fornito all'utente è costituito da una porzione che può essere strappata e utilizzata successivamente come input nel sistema, ad esempio una fattura contenente una ricevuta di pagamento che verrà restituita insieme al documento. controllo.
dichiarazioni elettroniche
Presentazione grafica e multimediale
cap08 metodo di sviluppo del sistema
8.2 Ciclo di vita dello sviluppo del sistema
8.2.1 Metodi tradizionali di previsione del ciclo di vita dello sviluppo del sistema
Il metodo di previsione è un metodo in grado di pianificare in anticipo progetti di sviluppo organizzativo e di sviluppare nuovi sistemi informativi secondo il piano.
Requisiti: si presuppone che il progetto possa essere pianificato in anticipo, che il sistema informativo possa essere sviluppato secondo il piano, che i requisiti siano ben compresi e che il rischio tecnico sia basso
modello a cascata
In un progetto, le sei fasi del ciclo di vita progrediscono da una fase a quella successiva e le fasi sono sequenziali.
Nel tradizionale modello a cascata non vi è alcuna sovrapposizione o iterazione tra le varie fasi dell'SDLC
Il modello sul lato relativamente destro della scala è il modello a cascata migliorato
Il modello a cascata migliorato mantiene ancora la sequenza prevista delle fasi di sviluppo, ma queste fasi si sovrappongono, si influenzano e dipendono l'una dall'altra.
Maggiore flessibilità, ma presuppone ancora una pianificazione predittiva e fasi sequenziali
8.2.2 Approccio adattivo al ciclo di vita dello sviluppo del sistema
I modelli di adattamento possono essere utilizzati per lo sviluppo quando i requisiti (requisiti) non sono chiari e spesso comportano diverse iterazioni.
I progetti devono essere più flessibili e adattarsi alle mutevoli esigenze durante il processo di sviluppo; la domanda è incerta e i rischi tecnici sono elevati;
modello a spirale
Relativamente lontano dall'estremità destra della scala
Utilizza una spirale per descrivere l'SDLC, partendo dal centro ed espandendosi verso l'esterno più e più volte fino al completamento del progetto.
Più di una volta per fase
modello iterativo
Similmente al metodo di sviluppo del Capitolo 1, le righe della tabella sono attività di sviluppo e le colonne sono iterazioni.
Ogni iterazione contiene diverse fasi e ciascuna fase non verrà completata in una sola volta, ma verrà continuamente migliorata nelle iterazioni successive.
Concetti aggiuntivi sugli approcci adattivi
sviluppo incrementale
Il concetto di base è che i sistemi vengono costruiti in piccoli incrementi, crescendo in modo organico
Durante il progetto, il sistema viene implementato in fasi e parzialmente implementato
Il vantaggio è che gli utenti possono ottenere rapidamente una parte del sistema in modo che l'attività possa essere avviata il più rapidamente possibile.
scheletro ambulante
Un approccio iniziale alla costruzione di una struttura di sistema completa che fornisce solo le funzioni di base
Innanzitutto, fornire uno "scheletro" del processo completo di implementazione del nuovo sistema, dall'inizio alla fine, quindi utilizzare le iterazioni successive per completare lo scheletro.
Nei progetti spesso non è una scelta estrema
8.3 Fase di supporto
L'approccio predittivo SDLC prevede tale fase di supporto
L'approccio adattivo tratta la fase di supporto come un progetto completo e autonomo
Durante la fase di supporto si verificano tre attività principali
Sistema di manutenzione
Rafforzare il sistema
Supporta gli utenti
8.4 Metodi, modelli, strumenti e tecniche
metodi di sviluppo del sistema
L'ambito del metodo è il più ampio
Una metodologia include una serie di tecniche per completare attività e compiti, inclusa la modellazione di ogni aspetto di un progetto
Modello
Un modello è una rappresentazione astratta di alcuni aspetti specifici del mondo reale che consente di comprendere un concetto complesso concentrandosi solo sulle parti rilevanti
Ogni modello enfatizza informazioni diverse
Siamo già entrati in contatto con alcuni di questi modelli: diagramma ER, diagramma dei casi d'uso, diagramma delle classi, diagramma di sequenza
attrezzo
supporto software
tecnologia
acquisite attraverso l’apprendimento
8.5 Due metodi di costruzione e modellazione del software
8.5.1 Approccio strutturato
Il metodo strutturato si concentra sul processo ed è centrato sul flusso di dati. Presuppone che il sistema sia un insieme di processi che interagiscono con il flusso di dati.
Il metodo strutturato è lo stesso metodo tradizionale del metodo di previsione SDLC.
Analisi strutturata
Modellazione utilizzando il diagramma del flusso di dati
Verranno utilizzati anche i diagrammi ER
progettazione strutturata
Progettare programmi utilizzando diagrammi di struttura
Richiede basso accoppiamento e alta coesione
Basso accoppiamento significa che i diversi moduli sono il più indipendenti possibile dagli altri moduli, in modo che la modifica di un modulo non influisca sul funzionamento degli altri moduli.
Un'elevata coesione significa che ogni modulo implementa un compito chiaro
programmazione strutturata
Comprende un inizio, una fine e tre strutture: sequenza, selezione, ciclo
Programmazione top-down/progettazione modulare
8.5.2 Approccio orientato agli oggetti
L'approccio orientato agli oggetti vede un sistema come una raccolta di oggetti che lavorano insieme per realizzare una determinata interazione.
Gli oggetti sono cose nel sistema che rispondono ai messaggi
analisi orientata agli oggetti
Il processo di identificazione e definizione di casi d'uso e insiemi di oggetti (classi) in un nuovo sistema
progettazione orientata agli oggetti
Definisci tutti i tipi di oggetti necessari per comunicare con persone e dispositivi e mostra come interagiscono per completare le attività
Utilizzare modelli come diagrammi di classi e diagrammi di casi d'uso
Programmazione orientata agli oggetti
Scrivi istruzioni per definire la classe effettiva e il ruolo di ciascun oggetto della classe
Utilizzare modelli come diagrammi di sequenza e diagrammi di classi di progettazione
8.6 Sviluppo agile
Attività di sviluppo condotte in un ambiente sconosciuto e in rapida evoluzione
8.6.1 Teoria e valore dello sviluppo agile
teoria fondamentale
Concentrati sulla risposta al cambiamento piuttosto che seguire un piano
Valorizzare gli individui e le interazioni piuttosto che i processi e gli strumenti
Preferisci il software funzionante alla documentazione completa
Concentrarsi sulla collaborazione con il cliente piuttosto che sulle trattative contrattuali
Descrivi il concetto di progetti agili: caos
Questo è caos e ordine: le prime due teorie fondamentali – il predominio dei valori individuali sui valori del gruppo – sono la causa del caos, e questo caos può essere gestito con crescente flessibilità. Il caos è inevitabile durante l'imprevedibile processo di sviluppo. Gli sviluppatori devono accettarlo, ma a volte è necessario utilizzare altri metodi e tecniche utili per aggiungere ordine e struttura al progetto.
Per dirla semplicemente, significa permettere che si verifichi un po’ di caos garantendo allo stesso tempo l’ordine generale.
cap09 Pianificazione e gestione dei progetti
Queste sono le prime due delle sei sezioni principali: identificare il problema e ottenere l'approvazione, pianificare e monitorare il progetto
9.2 Principi di gestione del progetto
9.2.1 Requisiti per la gestione del progetto
Secondo le statistiche, meno di un terzo dei progetti di successo
Motivi per cui alcuni progetti falliscono
Motivo principale: mancanza di coinvolgimento del senior management e di capacità gestionali
Mancanza di partecipazione al gruppo di utenti
9.2.2 Il ruolo del project manager
La gestione del progetto è il processo di organizzazione e direzione degli altri per raggiungere i risultati pianificati secondo un programma e un budget precedentemente determinati. Può anche essere definito come il processo di pianificazione di un progetto e quindi di monitoraggio e controllo.
Responsabilità interne del Project Manager
Sviluppare il programma del progetto
Reclutare e formare i membri del team
Coordinare il lavoro tra i membri del team
Valutare i rischi del progetto
Monitorare e controllare le tappe fondamentali del progetto
Gestire persone e risorse
Responsabilità esterne del project manager
Segnala lo stato e i progressi del progetto
Lavorare direttamente con i clienti e le altre parti interessate
Determinare le esigenze di risorse e ottenere risorse
Coordinare le pubbliche relazioni
I project manager lavorano con diversi gruppi di persone
Cliente: la persona che finanzia il sistema
Comitato di supervisione: composto dal cliente e da altri dirigenti senior per supervisionare il progetto
Utente: una persona che utilizza direttamente il sistema per completare le attività
I project manager hanno una doppia funzione interna ed esterna
9.2.3 Gestione del progetto e cerimonia (cerimonia)
Anche il grado di formalità di un progetto, o rituale, ha un impatto sulla gestione del progetto
I progetti più piccoli spesso eseguono rituali di fascia bassa
Progetti più grandi e complessi spesso eseguono cerimonie di alta qualità
I rituali del progetto differiscono quando si utilizzano metodi predittivi tradizionali rispetto a metodi adattivi
I progetti adattivi possono spesso essere più formali o informali nei loro metodi di gestione: UP (Unified Process) è piuttosto formale e ha rituali rigorosi, mentre i metodi iterativi sono più informali
9.2.4 Sistema di conoscenza della gestione del progetto
PMBOK, è composto da nove moduli
Gestione della scala del progetto
Gestione del tempo di progetto
gestione dei costi di progetto
Gestione della qualità del progetto
Gestione delle risorse umane del progetto
Gestione della comunicazione del progetto
gestione del rischio di progetto
Gestione degli appalti di progetto
Gestione dell'integrazione del progetto
9.2.5 Gestione agile del progetto
Gestione agile del progetto
L’ambito non è ben compreso ma deve essere controllato
Utilizzare diverse linee guida per determinare le priorità aziendali
Gestione agile del tempo
L’orario deve essere flessibile per accogliere i cambiamenti
Gestione agile dei costi
I costi sono più difficili da stimare, quindi il controllo dei costi non è così importante come lo è in un approccio predittivo
Gestione agile del rischio
Gli aspetti ad alto rischio del progetto vengono completati per primi
Gestione agile della qualità
Condurre una valutazione della qualità dopo ogni iterazione
9.3 Processo principale 1: identificare il problema e ottenere l'approvazione
9.3.1 Identificare il problema
Tre scopi principali per lo sviluppo di nuovi sistemi
Rispondere a nuove opportunità di sviluppo
occupare quote di mercato
Risolvere i problemi aziendali esistenti
Rispondere ai comandi esterni
Legale, fiscale ecc.
Un modo efficace per definire il problema è creare un System Vision Document (SVD)
Include tre parti
Descrizione del problema
Quali sono i problemi e le soluzioni?
Capacità del sistema
Quali caratteristiche avrà il nuovo sistema?
vantaggi aziendali
Benefici per l’organizzazione (tangibili o immateriali)
9.3.2 Quantificare i fattori di approvazione del progetto
Bisogna essere chiari
Tempo di completamento stimato
Costi di sviluppo stimati
Costi di gestione stimati
Pre-guadagni
analisi costi benefici
alcuni concetti
VAN (Valore attuale netto) valore attuale netto
Il valore attuale dei benefici e dei costi di un particolare investimento
Calcolato sottraendo i costi utilizzando i "guadagni attuali" (utilizzando un fattore di sconto)
punto di recupero costi
Durante questo periodo, i guadagni in dollari hanno compensato i costi in dollari
benefici tangibili
La parte del beneficio che può essere misurata in termini di denaro
benefici immateriali
Benefici per l’organizzazione ma non possono essere misurati quantitativamente o stimati con precisione
Miglioramenti nei livelli di servizio (in modi che non possono essere misurati in dollari)
Miglioramento della soddisfazione del cliente (non misurabile in dollari)
Sopravvivenza: è necessario competere in questo modo
Necessità di sviluppare competenze interne (ad esempio progetti pilota per nuove tecnologie)
metodo di analisi costi/benefici
Utilizzare il valore attuale come valore stimato
Calcolare la vita del sistema
Calcolare il periodo di ammortamento e le entrate finali accumulando il valore attuale netto ogni anno
Esempio
Il periodo di rimborso utilizza i punti di svolta positivi e negativi del valore attuale netto accumulato come parte intera e la parte decimale viene calcolata utilizzando (ultimo valore negativo/differenza totale)
9.3.3 Valutazione del rischio e analisi di fattibilità
Determinare il rischio e la fattibilità dell’organizzazione
Valutare i rischi tecnici e la fattibilità
Valutare il rischio e la fattibilità delle risorse
Determinare i rischi e la fattibilità del programma
9.3.4 Collaborare con i clienti in fase di approvazione
Revisione e approvazione del Comitato Esecutivo
I consigli di amministrazione devono rivedere e approvare progetti molto grandi
Le parti interessate coinvolte devono capire cosa ci si aspetta da loro
I dipartimenti IS devono sapere cosa fare in termini di personale e supporto
L’intera organizzazione dovrebbe essere consapevole di questo progetto e della sua importanza
9.4 Processo principale 2: Pianificare e monitorare i progetti
9.4.1 Stabilire l'ambiente del progetto
Diversamente dalla progettazione ambientale menzionata prima, l'ambiente di progetto qui si riferisce all'ambiente di lavoro e alla comunicazione all'interno e all'esterno del team, piuttosto che alla tecnologia richiesta dal sistema, ecc.
Documenti e comunicazioni - Interni/Esterni
Ambiente di lavoro – Supporto/Attrezzature/Strumenti
PC o postazione di lavoro
Software e strumenti per lo sviluppo personale
Server con libreria di risorse, strumenti di comunicazione
Uffici, sale conferenze, stampanti e altre attrezzature
Supportare i dipendenti (fuori dal team)
Processi e Procedure
Rapporti e documentazione
programmazione
test
Prodotti finali
Controllo del codice e della versione
9.4.2 Organizzare l'avanzamento del lavoro
Utilizza la pianificazione delle iterazioni del progetto per assegnare i casi d'uso alle iterazioni
Pianificare un programma dettagliato delle attività e del lavoro che deve essere completato in ogni iterazione: utilizzare un programma di lavoro dettagliato
Tre passaggi per creare un programma di lavoro dettagliato iterativo
Creare una struttura di ripartizione del lavoro WBS
Stima dell'impegno e identificazione delle dipendenze
Crea una pianificazione utilizzando un diagramma Gatt
La struttura di suddivisione del lavoro contiene
Base di decomposizione
tempo richiesto
Ordine di esecuzione
Valutare il tempo in base alle informazioni rilevanti della WBS e scoprire le dipendenze, possibilmente utilizzando il percorso critico
Un diagramma di Gantt è un grafico a barre con attività espresse in barre e visualizzate su una sequenza temporale orizzontale
Ad eccezione della prima attività, ogni attività ha un'attività predecessore.
La parte di colore chiaro è il percorso critico, che influisce sull'intero progresso e deve essere monitorato attentamente.
9.4.3 Assegnazione del personale e delle risorse
cinque compiti
Creare un piano delle risorse nel progetto
Identificare e richiedere dipendenti tecnici specifici
Identificare e richiedere dipendenti utente specifici
Organizzare i team in gruppi di lavoro
Stabilire esercizi di formazione iniziale ed esercizi di team building
9.4.4 Processo di lavoro di valutazione
mostra retrospettiva
9.4.5 Processo di monitoraggio e correzione
Assegnare il lavoro a individui o team
stato della raccolta
Il compito è stato completato e l’obiettivo raggiunto?
Analizzare le anomalie
Le eccezioni contano?
intraprendere l'azione giusta
cap10 Progettazione orientata agli oggetti: principi di progettazione
10.2 Progettazione orientata agli oggetti: il ponte tra analisi e implementazione
10.3 Progettazione dell'architettura orientata agli oggetti (progettazione di alto livello)
I sistemi software sono generalmente divisi in due tipologie
Sistema a utente singolo: eseguito sul desktop dell'utente o su un server senza condivisione delle risorse
Sistemi di livello aziendale: i componenti possono essere condivisi tra più persone o organizzazioni
Sistema server/cliente
Sistema Internet (browser/server)
Tre differenze fondamentali che influenzano la progettazione dell'architettura del sistema
stato
Client/server è un sistema basato sullo stato e le connessioni client/server sono di lunga durata
I sistemi Internet sono sistemi stateless e le connessioni non sono a lungo termine
Distribuzione del cliente
Visualizzazione diretta di schermate e tabelle
Le schermate e le tabelle vengono visualizzate tramite il browser
Distribuzione del server
L'applicazione o il client si connette direttamente al server
Il client si connette indirettamente al server delle applicazioni tramite il browser
Diagramma dei componenti e progettazione dell'architettura
Un tipo di diagramma di progettazione che mostra l'architettura complessiva del sistema e i componenti logici al suo interno, illustrando come verrà implementato il sistema
Il diagramma dei componenti identifica i componenti del sistema per logica, riutilizzabilità e portabilità
Gli elementi di base di un diagramma dei componenti sono elementi dei componenti con API.
Le API sono metodi pubblici a cui è possibile accedere dal mondo esterno
Esistono due tipi di API nei diagrammi dei componenti
Presa di ingresso (Presa)
Porta di uscita (Porta)
Esempio
Caso: progettazione dell'architettura di Internet a due livelli (in realtà può anche essere a tre livelli)
Livello dell'interfaccia utente (livello di visualizzazione)
Livello di dominio (livello logico)
Livello di accesso al database (livello dati)
Rappresentare utilizzando i diagrammi dei componenti
10.4 Principi base della progettazione esecutiva orientata agli oggetti
Fasi di progettazione dettagliata orientata agli oggetti
Sviluppare diagrammi preliminari delle classi di progettazione
Utilizza le carte CRC per determinare le responsabilità della classe e la cooperazione per i casi d'uso
Sviluppa diagrammi di sequenza dettagliati per ciascun caso d'uso: sviluppa prima i diagrammi di sequenza preliminari, quindi i diagrammi di sequenza a più livelli
Aggiungi caratteristiche del metodo e informazioni di navigazione
Suddividere la soluzione in pacchetti (schema dei pacchetti)
10.5 Classe di progetto e diagramma delle classi di progetto
10.5.1 Simboli di progettazione
Un prototipo è un modo di classificare gli elementi in base alle loro caratteristiche, rappresentate da <<>>
Esistono quattro tipi di prototipi di design
Classe di entità
L'identificatore di progettazione della classe del dominio problematico, solitamente persistente, rappresentato da <<entità>>
Le classi persistenti si riferiscono a classi che contengono ancora dati dopo l'arresto del sistema. Quando si implementano i metodi, i relativi dati vengono scritti nel database o nel file.
Esempio
Studenti e insegnanti nel sistema di gestione educativa
Classe di controllo
È una classe che svolge un ruolo di coordinamento tra le classi di visualizzazione e le classi di entità, simile a router o switch, rappresentata da <<controller>>
Visualizza la lezione
Le classi di visualizzazione, o classi di confine, si trovano al confine di automazione del sistema, simili a caselle di input o pagine Web, di fronte agli utenti e sono rappresentate da <<boundary>>
Classe di accesso al database
È una classe che ottiene i dati dal database e li restituisce, rappresentati da <<dataAccess>>
Ogni classe prototipo ha un simbolo diverso
10.5.2 Rappresentazione delle classi di progetto
Definire il formato degli attributi in una classe di progettazione
visibilità
Indica (o -) se è possibile accedere direttamente alla proprietà da un altro oggetto. Di solito private(-) invece di public()
Nome della proprietà
cassa cammello minuscola
tipo espressione
classe, stringa, intero, doppio, data
valore iniziale
proprietà
Tra parentesi graffe, come {key}
Definire il formato del metodo (caratteristiche del metodo)
visibilità del metodo
nome del metodo
Tipo di valore restituito dal metodo
elenco dei parametri
Esempio
Tra il nome e il tipo della proprietà sono presenti i due punti, così come tra l'elenco dei parametri e il tipo del valore restituito dal metodo è presente un segno uguale prima del valore iniziale;
Utilizzare nomi di classi in corsivo per indicare classi astratte
Le classi che consentono solo l'ereditarietà ma non l'istanziazione generalmente rappresentano concetti astratti di livello superiore
10.5.3 Sviluppare diagrammi preliminari delle classi di progettazione
Perfezionamento degli attributi
I progettisti determinano i tipi di attributi in base all'esperienza. Nella maggior parte dei casi, gli attributi sono invisibili (privati).
Visibilità della navigazione
La visibilità di navigazione si riferisce al fatto che una classe sia visibile o invisibile a un'altra classe, indicando la capacità di un oggetto di vedere e interagire con un altro oggetto
Utilizzare una freccia per indicare che la direzione indicata è il lato visibile
In questo esempio, il cliente fa riferimento alla classe vendita, quindi la vendita è visibile al cliente, ma il cliente non è visibile alla vendita.
Tipo di visibilità della navigazione
Rappresenta una relazione uno-a-molti tra superiori e subordinati, di solito puntando dai superiori ai subordinati
Associazione forzata, in cui un oggetto in una classe non può esistere senza un oggetto in un'altra classe, in genere passando da una classe più indipendente a una classe dipendente
Ad esempio, nel caso cliente e vendita di cui sopra, la vendita non ha senso quando non ci sono clienti.
Quando un oggetto richiede informazioni da un altro oggetto, potrebbe essere necessaria una freccia di navigazione
La visibilità della navigazione può essere bidirezionale
Passaggi per sviluppare diagrammi preliminari dei casi d'uso
Caso d'uso dopo caso d'uso, aggiunto al diagramma
Seleziona le classi di dominio coinvolte nel caso d'uso (vedi l'idea di prerequisiti e postcondizioni)
Le precondizioni e le postcondizioni dovrebbero essere nella descrizione del caso d'uso nel Capitolo 5
Aggiungi una classe controller per gestire il caso d'uso
Utilizzare le linee guida per determinare le esigenze di visibilità della navigazione iniziale e aggiungerle al diagramma
Descrivi le proprietà di ciascuna classe in dettaglio con visibilità e tipo
Si noti che le associazioni e la molteplicità vengono spesso rimosse dai diagrammi delle classi di progettazione, proprio come la navigazione viene enfatizzata nel testo, ma spesso vengono mantenute
Dal diagramma delle classi del dominio al diagramma delle classi del progetto preliminare
10.6 Utilizzo delle schede CRC per la progettazione dettagliata
La carta CRC significa Classe, Responsabilità, Collaborazione
La progettazione orientata agli oggetti riguarda l'assegnazione di responsabilità alle classi e il modo in cui lavorano insieme per completare un caso d'uso
La scheda CRC è divisa in tre aree: nome della classe, nome della responsabilità e classe di cooperazione
Passaggi per utilizzare la carta CRC
Inizia con un set di carte CRC inutilizzate e procedi attraverso un caso d'uso dopo l'altro
Seleziona un caso d'uso e seleziona una carta come controller
Determinare la classe di dominio principalmente responsabile di questo caso d'uso. Gli oggetti di questa classe riceveranno i messaggi dal controller; determineranno le responsabilità e le scriveranno sul lato sinistro della scheda.
Identificare altre classi che cooperano con la classe dell'oggetto principale per completare il caso d'uso e scriverle sul lato destro della scheda CRC
Dopo aver determinato le categorie di cooperazione, eseguire le operazioni di cui sopra per ciascuna categoria di cooperazione (determinare le responsabilità/trovare le categorie di cooperazione)
Le classi dell'interfaccia utente e le classi di accesso al database possono essere aggiunte in modo appropriato
Utilizzare i risultati della scheda CRC per aggiornare il diagramma delle classi di progettazione preliminare
Aggiorna il metodo: la responsabilità nella scheda CRC diventa un metodo (ma non c'è visibilità ed espressione del tipo di ritorno, cioè non vengono aggiunte caratteristiche del metodo)
Aggiorna la visibilità della navigazione
Esempio
Diagramma delle classi di progettazione preliminare
Diagramma delle classi di progettazione aggiornato
10.7 Alcuni principi di progettazione esecutiva
accoppiamento basso
Alta coesione
Protezione variabile
indiretto
Responsabilità dell'oggetto
cap11 Progettazione orientata agli oggetti: implementazione del progetto
11.2 Progettazione di dettaglio di sistemi multistrato
Modelli di progettazione
Modelli di progettazione: tecniche e modelli di progettazione standard ampiamente riconosciuti come buone pratiche
Per problemi comuni di progettazione/codifica, i modelli di progettazione suggeriscono il modo migliore per gestire il problema.
elementi dei design pattern
Nome dello schema
Problemi che richiedono soluzioni
modello di risoluzione dei problemi
Custodia modello
Vantaggi e conseguenze dei modelli
Il primo esempio di pattern di progettazione di programmazione è il pattern Controller.
I controller dei casi d'uso vengono creati artificialmente per passare i messaggi dal livello di visualizzazione al livello di dominio per ridurre l'accoppiamento.
Vantaggi e conseguenze
Riduce l'accoppiamento tra il livello del dominio e il livello della vista
fornisce uno strato di indiretto
I controller e le classi di dominio sono strettamente accoppiati
Se non stai attento, il controller conterrà molta logica irrilevante, in particolare logica aziendale.
11.3 Implementazione dei casi d'uso e diagramma di sequenza SSD
Implementazione dei casi d'uso: il processo di progettazione dettagliata dei casi d'uso utilizzando i diagrammi di interazione
Esistono due tipi di diagrammi di interazione
Diagramma di flusso
I diagrammi di sequenza vengono mostrati estendendo il diagramma di sequenza del sistema
visualizzare l'oggetto del livello
Oggetti del livello di dominio (solitamente eseguiti per primi)
oggetto del livello di accesso ai dati
Diagramma di collaborazione
11.3.1 Comprensione dei diagrammi di sequenza
La differenza tra diagramma di sequenza del sistema e diagramma di sequenza
Il diagramma di sequenza del sistema ha un solo oggetto, che rappresenta il sistema: sistema mentre il diagramma di sequenza estende l'oggetto all'interno del sistema.
Il diagramma di sequenza del sistema ha solo due linee di vita, che rappresentano gli attori e il sistema; gli attori e ogni oggetto nel diagramma di sequenza hanno una linea di vita, sebbene la lunghezza possa essere diversa (la tempistica inizia quando l'oggetto viene creato)
Nello stesso caso d'uso, la parte di confine dell'automazione del diagramma di sequenza del sistema e del diagramma di sequenza è la stessa (il tutto rimane invariato), vale a dire, l'input al sistema e l'output del sistema verso l'esterno sono Stesso.
I diagrammi di sequenza hanno una sezione speciale della linea di vita chiamata linea di vita dell'attività
La linea di vita dell'attività rappresenta il tempo in cui un oggetto si trova nello stato di esecuzione attivo. Lo stato attivo dura fino al salvataggio di tutti i dati o alla chiamata di altri metodi.
In questo diagramma di sequenza della creazione di un caso d'uso utente: Customform e CustomHandler sono stati creati e l'oggetto Custom viene creato dopo il metodo createCustom, quindi l'ora di inizio della linea di vita è diversa e la barra rettangolare è la linea di vita attiva;
11.3.2 Processo di progettazione dell'implementazione del caso d'uso
fasi di progettazione
Sviluppare un diagramma delle classi di progettazione preliminare che mostri la visibilità della navigazione
Utilizza le schede CRC per assegnare funzioni alle classi nei casi d'uso
Sviluppare diagrammi di sequenza dettagliati per ciascun caso d'uso
Diagramma di sequenza preliminare
Diagramma di sequenza multilivello
Utilizza le schede CRC e i diagrammi di sequenza dettagliati per aggiornare i diagrammi delle classi di progettazione e aggiungere funzionalità al metodo
Diagrammi delle classi di progettazione del pacchetto
11.3.3 Caso: diagramma delle classi di progettazione preliminare per la creazione di un account utente
Sviluppare un diagramma di sequenza preliminare basato sul diagramma preliminare delle classi di progettazione sviluppato in precedenza
Espandi il diagramma di sequenza del sistema e contrassegna gli oggetti della classe che devono essere utilizzati nell'originale: system, e davanti ad esso sono ancora presenti i due punti.
Determina i messaggi interni tra gli oggetti, aggiungi messaggi e attivazioni per completare la collaborazione
Il formato del messaggio è coerente con il diagramma di sequenza del sistema: *[codizione] valore_ritorno:=nome_funzione(elenco_parametri) Puoi anche utilizzare una freccia inversa tratteggiata come valore restituito
sottoargomento
11.3.5 Linee guida e ipotesi per lo sviluppo di diagrammi di sequenza preliminari
guida
Accettare ogni messaggio e identificare altri messaggi interni risultanti da questo messaggio di input
Durante l'elaborazione di ciascun messaggio, specificare l'insieme di classi interessate
Arricchisci la struttura del messaggio, aggiungi condizioni vere e false, cicli, valori restituiti, trasferimento di parametri, ecc.
ipotesi
Ipotesi di perfezione tecnica
Ipotesi di perfezione della memoria
nessuna ipotesi di anomalia
11.3.6 Sviluppo di diagrammi di sequenza multistrato
Quanto sopra è solo un diagramma di sequenza preliminare per il livello di dominio (livello logico). Per descrivere i casi d'uso in modo più dettagliato, è necessario sviluppare diagrammi di sequenza per il livello di accesso ai dati e il livello di visualizzazione.
11.4 Utilizzare il diagramma di comunicazione del diagramma di collaborazione
11.5 Aggiornamento e diagramma delle classi di progettazione del pacchetto
Aggiorna il diagramma delle classi di progettazione
In base alle informazioni del diagramma di sequenza, aggiungere funzionalità del metodo per aggiornare il DCD
Tre tipi di metodi
Metodo del costruttore: crea una nuova istanza dell'oggetto
Metodi di lettura e scrittura dei dati: ottenere o aggiornare i valori degli attributi
Metodi specifici del caso d'uso: inclusi nel diagramma delle classi di progettazione
Mappa dei pacchetti
Un diagramma di pacchetto è un diagramma di alto livello che associa gruppi di classi correlati
Utilizza icone simili a cartelle per rappresentare i pacchetti e le classi vengono posizionate nei pacchetti corrispondenti in base ai livelli a cui appartengono.
Utilizza le frecce tratteggiate per indicare le dipendenze, comprese le dipendenze tra classi e le dipendenze tra pacchetti.
Esempio
Diagramma del pacchetto parziale con un solo caso d'uso
Diagramma del pacchetto del sottosistema
11.6 Altri modelli di progettazione comuni
adattatore
Quando è necessario collegare due sistemi ma le interfacce tra loro non corrispondono, è necessario un adattatore.
Connetti interfacce non corrispondenti riscrivendo i dati
Ad esempio: quando si hanno a che fare con fornitori diversi (tasse, spese di spedizione), è sufficiente riscrivere l'adattatore
fabbrica
Le classi factory vengono utilizzate per creare molti tipi diversi di istanze di classi di utilità
Generalmente, una classe strumento necessita di una sola istanza e la factory deve garantire che ci sia solo una istanza.
Singleton
Un singleton ha una variabile statica che punta a un'istanza di se stesso. Controlla questa variabile attraverso qualche metodo. Se è vuoto, puoi creare un'istanza e assegnarla alla variabile; se non è vuoto, puoi restituire direttamente l'istanza della variabile;
Connessione alla classe{ conn statico privato=null; getConnection statico pubblico sincronizzato(){ se conn==null{ conn=nuova connessione(); } collegamento di ritorno; } }
Fabbrica e singleton
La logica di base delle factory e dei singleton è la stessa: entrambi devono garantire che ci sia una sola istanza dell'oggetto e risparmiare sovraccarico di memoria.
Ma la factory deve essere responsabile di più classi; il singleton controlla solo le variabili di istanza statiche all'interno della classe.