Diversi linguaggi di modellazione (Entity-Relation, Unified Modeling Language e altri) sono semplici notazioni per comunicare un progetto agli stakeholder. Comunicare un design è una comunicazione tecnica e uno dei principi della buona comunicazione tecnica è comunicare le informazioni in modo chiaro e conciso. La scelta di una notazione di modellazione che è compresa dal pubblico e in grado di comunicare chiaramente le informazioni desiderate è il primo passo per raggiungere questo principio.
Nel suo articolo Un confronto tra tecniche di modellazione dei dati , David Hay identifica un numero di notazioni di modellazione e fornisce lo stesso modello di esempio espresso in ciascuna notazione, inclusi diagrammi ER , Information Engineering , Notazione di Barker , IDEF1X , Object Role Modeling e UML . Hay discute la differenza tra gli analisti (che hanno bisogno di diagrammi chiari e di facile lettura su cui si possa ragionare) e i progettisti (che hanno bisogno di diagrammi completi, rigorosi ed espressivi da utilizzare per l'implementazione).
Scott Ambler ha anche alcuni principi della modellazione agile pertinenti per questo:
Travel Light. Every artifact that you create, and then decide to keep, will need to be maintained over time. If you decide to keep
seven models, then whenever a change occurs (a new/updated
requirement, a new approach is taken by your team, a new technology is
adopted, ...) you will need to consider the impact of that change on
all seven models and then act accordingly. If you decide to keep only
three models then you clearly have less work to perform to support the
same change, making you more agile because you are traveling lighter.
Similarly, the more complex/detailed your models are, the more likely
it is that any given change will be harder to accomplish (the
individual model is "heavier" and is therefore more of a burden to
maintain). Every time you decide to keep a model you trade-off agility
for the convenience of having that information available to your team
in an abstract manner (hence potentially enhancing communication
within your team as well as with project stakeholders). Never
underestimate the seriousness of this trade-off. Someone trekking
across the desert will benefit from a map, a hat, good boots, and a
canteen of water they likely won't make it if they burden themselves
with hundreds of gallons of water, a pack full of every piece of
survival gear imaginable, and a collection of books about the desert.
Similarly, a development team that decides to develop and maintain a
detailed requirements document, a detailed collection of analysis
models, a detailed collection of architectural models, and a detailed
collection of design models will quickly discover they are spending
the majority of their time updating documents instead of writing
source code.
Multiple Models. You potentially need to use multiple models to develop software because each model describes a single aspect of your
software. “What models are potentially required to build modern-day
business applications?” Considering the complexity of modern day
software, you need to have a wide range of techniques in your
intellectual modeling toolkit to be effective (see Modeling Artifacts
for AM for a start at a list and Agile Models Distilled for
detailed descriptions). An important point is that you don't need to
develop all of these models for any given system, but that depending
on the exact nature of the software you are developing you will
require at least a subset of the models. Different systems, different
subsets. Just like every fixit job at home doesn't require you to use
every tool available to you in your toolbox, over time the variety of
jobs you perform will require you to use each tool at some point. Just
like you use some tools more than others, you will use some types of
models more than others. For more details regarding the wide range of
modeling artifacts available to you, far more than those of the UML as
I show in the essay Be Realistic About the UML.
Content Is More Important Than Representation. Any given model could have several ways to represent it. For example, a UI specification
could be created using Post-It notes on a large sheet of paper (an
essential or low-fidelity prototype), as a sketch on paper or a
whiteboard, as a "traditional" prototype built using a prototyping
tool or programming language, or as a formal document including both a
visual representation as well as a textual description of the UI. An
interesting implication is that a model does not need to be a
document. Even a complex set of diagrams created using a CASE tool may
not become part of a document, instead they are used as inputs into
other artifacts, very likely source code, but never formalized as
official documentation. The point is that you take advantage of the
benefits of modeling without incurring the costs of creating and
maintaining documentation.
Ha anche alcune pratiche per la modellazione agile per aiutare a raggiungere questi principi:
Apply The Right Artifact(s). Each artifact has its own specific applications. For example, a UML activity diagram is useful for
describing a business process, whereas the static structure of your
database is better represented by a physical data or persistence
model. Very often a diagram is a better choice than source code -- If
a picture is worth a thousand words then a model is often worth 1024
lines of code when applied in the right circumstances (a term borrowed
from Karl Wieger's Software Requirements) because you can often
explore design alternatives more effectively by drawing a couple
diagrams on whiteboards with your peers than you can by sitting down
and developing code samples. The implication is that you need to know
the strengths and weaknesses of each type of artifact so you know when
and when not to use them. Note that this can be very difficult because
you have Multiple Models available to you, in fact the Agile Models
Distilled page lists over 35 types of models and it is by no means
definitive.
Iterate To Another Artifact. When you are working on a development
artifact -- such as a use case, CRC card, sequence diagram, or even
source code -- and find that you are stuck then you should consider
working on another artifact for the time being. Each artifact has its
strengths and weaknesses, each artifact is good for a certain type of
job. Whenever you find you are having difficulties working on one
artifact, perhaps you are working on a use case and find that you are
struggling to describe the business logic, then that's a sign that you
should iterate to another artifact. For example, if you are working on
an essential use case then you may want to consider changing focus to
start working on an essential UI prototype, a CRC model, a business
rule, a system use case, or a change case. By iterating to another
artifact you immediately become "unstuck" because you are making
progress working on that other artifact. Furthermore, by changing your
point of view you often discover that you address whatever it was that
causing you to be stuck in the first place. See the essay Iterate to
Another Artifact for more thoughts.
Single Source Information. Information should be stored in one place and one place only. In other words, not only should you apply the
right artifact you should also model a concept once and once only,
storing the information in the best place possible. When you are
modeling you should always be asking the questions "Do I need to
retain this information permanently?", "If so, where is the best place
to store this information?" and "Is this information already captured
elsewhere that I could simply reference?". Sometimes the best place to
store information is in an agile document, often it's in source code.
Read here for more details.
Innanzitutto occorre identificare con chi si sta comunicando e quali informazioni hanno bisogno. Dovresti scegliere la notazione e i modelli di modellazione appropriati per comunicare tali informazioni a loro. Una volta creati i modelli, dovresti usarli. Dovrebbero essere rivisti per coerenza, dovrebbero essere trasformati in altri modelli, dovrebbero essere inclusi nei documenti, o dovrebbero essere usati per guidare un'implementazione.
Se è necessario, valuta l'opportunità di investire nella formazione. Se stai lavorando con ingegneri di sistema che usano SysML, potresti prendere in considerazione l'addestramento di tutti a leggere i modelli SysML. Se il team del software rileva la notazione UML più facilmente, considera la possibilità di addestrare tutti in UML. Non deve essere un corso di formazione formale - potrebbe essere il passaggio di link a siti web utili, l'acquisto di alcune copie di un libro per una biblioteca aziendale, il pranzo e le sessioni di apprendimento, o la formazione esterna (sia fuori sede o un formatore portato in una sessione). Ciò potrebbe semplificare la riduzione della necessità di utilizzare più notazioni di modellazione.
Secondo, non aver paura di buttare via le modelle. Forse la prima iterazione di un modello potrebbe essere un diagramma ER. Questo potrebbe essere usato per capire i dati e creare il tuo database. Tuttavia, per aggiungere ulteriori dettagli, è possibile scegliere di evolverlo in un tipo di modello diverso, ad esempio un diagramma di classi. A seconda delle esigenze degli stakeholder, potrebbe essere necessario mantenere entrambi i modelli. Se non lo fai, butta via il primo modello in modo da non doverlo manutenere o rischiare che qualcuno lo trovi e lavori su un modello errato. I futuri aggiornamenti del database potrebbero essere guidati attraverso le modifiche al diagramma delle classi. Alla fine della giornata, però, non vuoi che le stesse informazioni vengano catturate in più punti.
Per rispondere in modo molto chiaro alla tua domanda: sì, ci sono dei motivi per usare un diagramma ER su un modello UML. Questo è il motivo per cui il diagramma ER è più utile per i tuoi stakeholder rispetto a un modello UML. Tuttavia, l'uso di un diagramma ER una volta non significa che lo manterrai per tutta la durata di un progetto o di un prodotto o che non creerai un altro modello in parallelo o dal tuo modello ER.
Consiglierei anche di consultare il sito Agile Data di Scott Ambler per ulteriori articoli e informazioni. È collegato al sito Agile Modeling e fa parte del processo completo Gestione agile disciplinata , ma ha alcune buone idee indipendentemente dalla metodologia stanno seguendo.