La breve risposta alla tua domanda è, sì, questa "notazione per la descrizione" sta affermando che i tuoi documenti descrittivi includono un linguaggio di progettazione e informazioni sufficienti affinché un lettore possa capire il linguaggio di progettazione. Un'analisi completa, basata su IEEE Standard 1016-2009 IEEE per Information Technology - Progettazione di sistemi - Descrizioni di progettazione software è riportata di seguito.
A partire dal 13 agosto 2015, lo standard corrente per le descrizioni di progettazione del software è IEEE Standard IEEE Std 1016-2009 per Information Technology - Systems Design - Descrizioni di progettazione software . Baserò il resto di questa risposta su quel documento e versione.
La definizione di una descrizione di progettazione software (SDD), presentata nel 1016-2009, è:
An SDD is a representation of a software design to be used for recording information and communicating that design information to key design stakeholders.
A differenza delle precedenti iterazioni di 1016, la versione del 2009 supporta molto più metodologie di sviluppo. Ad esempio, la formulazione della revisione del 1998 era molto incline a un approccio Big Design Up Front . Le idee del 2009 possono essere applicate più prontamente al design di grandi dimensioni in anticipo, iterativo e incrementale, e persino approcci di reverse engineering. Inoltre, non impone un formato: molti vecchi standard IEEE per l'ingegneria del software sono orientati verso documenti cartacei. Il contenuto di 1016-2009 può essere applicato a "documenti cartacei, database automatizzati, strumenti di sviluppo software o altri supporti".
Nel 1016-2009, un SDD contiene 1 o più viste di progetto. Ogni vista di progettazione è governata da un punto di vista del progetto, che è incorniciato da uno o più problemi di progettazione. Un punto di vista del progetto definisce anche uno o più elementi del progetto, che sono espressi in un determinato linguaggio di progettazione.
I seguenti sono gli esperimenti della Sezione 2 Definizioni che si applicano a questi termini:
3.2 design concern: An area of interest with respect to a software design.
3.4 design element: An item occurring in a design view that may be any of the following: design entity, design relationship, design attribute, or design constraint.
3.12 design view: A representation comprised of one or more design elements to address a set of design concerns from a specified design viewpoint.
3.13 design viewpoint: The specification of the elements and conventions available for constructing and using a design view.
Tutto ciò significa che inizi a organizzare la tua SDD in base alle persone che useranno le informazioni contenute nell'SDD. Diverse parti interessate avranno esigenze diverse: considerare gli amministratori di rete o di sistema che hanno bisogno di conoscere componenti distribuiti e protocolli di comunicazione, amministratori di database che devono conoscere le strutture dati per i database per ottimizzarle, personale addetto alla garanzia della qualità che testerà il software, ingegneri implementazione e manutenzione del software e così via. Ognuna di queste persone ha preoccupazioni diverse che devono essere catturate nell'SDD. Queste preoccupazioni verranno utilizzate per inquadrare vari punti di vista.
La Tabella 1 di 1016-2009 fornisce un certo numero di punti di vista di progettazione di esempio. Identifica 12 diversi punti di vista del design, ma non vi è alcuna indicazione che questo sia un elenco completo, né è necessario per tutti i progetti. Alcuni di questi punti di vista sono un punto di vista di contesto, un punto di vista di informazioni, un punto di vista di interazione, un punto di vista di dinamica di stato e un punto di vista dell'algoritmo. Per ogni punto di vista, la tabella fornisce anche preoccupazioni progettuali di esempio. Ad esempio, il punto di vista delle informazioni viene utilizzato per risolvere i problemi relativi alle informazioni persistenti mentre il punto di vista dell'algoritmo fornisce logica procedurale e il punto di vista logico cattura la struttura statica (classi, interfacce) e l'uso di tipi e implementazioni (classi, tipi primitivi).
Una volta identificati i punti di vista, si definiscono gli elementi di progettazione utilizzati per dimostrare tale punto di vista, utilizzando un linguaggio di progettazione. Gli elementi di progettazione appropriati dipendono dal punto di vista. Ad esempio, gli elementi di un progetto in un punto di vista della dinamica di stato sarebbero eventi, stati, transizioni, attività, trigger e così via. In un punto di vista dell'algoritmo, gli elementi di progettazione sarebbero attributi, dati e fasi di elaborazione. In un punto di vista informativo, gli elementi sarebbero tipi di dati e classi, formati e strutture di archiviazione dei dati e meccanismi di accesso.
Dopo aver definito i tuoi elementi di design, li rappresenti in un linguaggio di progettazione. 1016-2009 non richiede alcuna lingua o notazione specifica. Elenca diversi esempi: i tipi di diagrammi UML appropriati (se presenti) vengono spesso elencati come esempi per ciascun punto di vista. Tuttavia, lo standard menziona anche diagrammi di flusso e pseudocodice come esempi per i punti di vista dell'algoritmo oi diagrammi di relazione di entità per il punto di vista delle informazioni. In una nota nella Sezione 4.9 Lingue di progettazione, lo standard indica che i linguaggi di progettazione standardizzati (IDEF0, IDEF1X, UML, Vienna Definition Language) sono migliori delle lingue stabilite senza una definizione formale (macchine a stati, automi, tabelle decisionali, diagrammi di Warnier, Jackson Structured Design, modelli HIPO). Tuttavia, l'autore è libero di scegliere qualsiasi linguaggio di progettazione appropriato.