Informatica Industriale

A chi stai rispondendo?

Cmq, RUP prevede un milione di artifacts, ma (viva dìo) non vanno prodotti tutti: dipende dall'istanza del processo.

Viste le dimensioni del nostro progetto, ne vanno prodotti una piccola parte.

Sarebbe carino avere una lista di artifacts da produrre per la fine del progetto.

C'è da qualche parte?

Non rispondevo a nessuno in particolare, era un'informazione rivolta a tutti.

Nash ha scritto:

A chi stai rispondendo?

Cmq, RUP prevede un milione di artifacts, ma (viva dìo) non vanno prodotti tutti: dipende dall'istanza del processo.

Viste le dimensioni del nostro progetto, ne vanno prodotti una piccola parte.

Sarebbe carino avere una lista di artifacts da produrre per la fine del progetto.

C'è da qualche parte?

il buon calavaro ci aveva promesso di fornirci una lista del genere, ma finora non si è vista!
ciao

Noi stiamo procedendo così:

fatti i casi d'uso
analizziamo i casi d'uso e troviamo le classi boundary, control, entity
facciamo il relativo diagramma sequence
alla fine ci ritroviamo un bel vopc

Cose non chiare:
che cosa bisogna fisicamente produrre per "l'architettura del sistema"???
i subsystem dove vanno messi in un documento particolare???

Ragazzi, come avete strutturato il modello di analisi in RSA?Mi spiego avete creato un package Realizzazioni dove all'interno ci sono altri package, uno per ogni realizzazione? E poi? Come avete modellato, in concreto, l'architettura? Cioè, quale pattern avete utilizzato (MVC o l'approccio che utilizza i layer)? Avete creato, per esempio, un package per ogni layer sia nel modello di analisi che in quello di progetto?

Scusate ma sono abbastanza confuso su come modellare sta "benedetta" architettura....

Qualcuno ha delle idee in proposito...?
THANKS

COM_KUNENA_LIB_BBCODE_QUOTE_NON_EXISTANT_USER ha scritto:

Come avete modellato, in concreto, l'architettura? Cioè, quale pattern avete utilizzato (MVC o l'approccio che utilizza i layer)?

Una cosa non esclude l'altra: in particolare i Layer sono un pattern architetturale [1], MVC è un pattern di design [2].

Sei a due livelli differenti: MVC serve a diminuire il coupling e le mutue dipendenze fra entity, logica di controllo, e presentazione; se ci fai caso c'è un mapping 1:1 con boundary, entity e control, quindi sei nella realizzazione dei casi d'uso, e di architettura non c'è molto.

I layer servono ad allocare i componenti (e le varie responsabilità) a livelli diversi, in modo tale che i servizi forniti da un componente (o sottosistema) di livello i dipendano solo e soltanto dai servizi forniti dal livello i-1; questo per migliorare la modularità e rendere l'architettura in grado di sopportare meglio i cambiamenti.

[1] An Architectural Pattern expresses a fundamental structural organization or schema for software systems. It provides a set of predefined subsystems, specifies their responsibilities, and includes rules and guidelines for organizing the relationships between them.

[2] A Design Pattern provides a scheme for refining the subsystems or components of a software system, or the relationships between them. It describes commonly recurring structure of communicating components that solves a general design problem within a particular context.