Nel linguaggio C++ le classi possono ereditare le caratteristiche di altre classi ed aggiungerne di proprie. Questa particolare capacità del  linguaggio rende il C++ particolarmente efficace per modellare le entità della vità reale.

In particolare in C++, grazie al meccanismo dell' ereditarietà, è possibile creare una nuova classe, detta classe figlia o derivata, trasferendo in essa tutti i membri di una classe esistente, detta classe padre o base. Ad esempio:

class B : public A
{
......
};

Questo frammento di codice significa che la nuova classe B possiede, oltre ai membri elencati nella propria definizione, anche quelli ereditati dalla classe A.

A questa regola esiste un'eccezione: una classe derivata non eredita i costruttori, il distruttore e l'operatore di assegnazione della sua classe base; ogni classe, quindi, deve fornire i propri costruttori e distruttori, oppure utilizzare le implementazioni di default. Inoltre, nel caso di costruttori con parametri, la classe derivata deve provvedere ad attivare il costruttore della propria diretta genitrice (non preoccupandosi invece delle eventuali altre classi gerarchicamente superiori).

La rappresentazione dei casi d'uso sotto forma di diagramma è molto utile per avere una visione "dall'alto" delle funzionalità che dovranno essere implementate nel software che si intende realizzare, ma non fornisce sufficienti dettagli per consentire al progettista del sistema di capire in che modo saranno realizzate. Dal diagramma dei casi d'uso non vi è alcun modo di capire quale sia l'attore più importante, o quali azioni dovranno essere compiute per implementare un determinato caso d'uso.

La rappresentazione migliore per rappresentare queste importanti informazioni è la forma testuale e ciascun caso d'uso dovrebbe essere accompagnato da una descrizione.

In realtà lo standard UML non definisce in modo preciso quali informazioni debbano essere incluse nella descrizione di un caso d'uso, ma un buon punto di partenza potrebbe essere la tabella seguente.

La tabella precedente è solo un esempio, ma è bene ricordare che non rappresenta un inutile documento supplementare al diagramma, al contrario completa il caso d'uso associato: in realtà senza la descrizione un caso d'uso risulta di scarsa utilità.

UTC (Universal Time Coordinated), in italiano Tempo Coordinato Universale, è l'ora di riferimento internazionale. Esso è derivato (e coincide a meno di approssimazioni infinitesimali) dal tempo medio di Greenwich (in inglese Greenwich Mean Time, GMT), e perciò talvolta è ancora chiamato GMT.

Quando è l'ora 0 UTC, è mezzanotte a Greenwich (Inghilterra), sul meridiano di longitudine zero. In Italia, nel periodo estivo (ora "legale"), l'orario è 2 ore avanti rispetto alla UTC; in inverno (ora "solare") l'orario è avanti di un'ora sulla UTC.

L'ora UTC è calcolata dal Bureau International des Poids et Mesures (BIPM) dai dati di vari orologi atomici, distribuiti in quasi cinquanta laboratori nazionali.

Il Time Service Department, U.S. Naval Observatory, (USA), da' l'ora UTC in tempo reale.

La realizzazione di un'applicazione software secondo la metodologia OOP consiste di un insieme di oggetti che comunicano tra loro ed il più delle volte l'analisi dell'architettura rivela una fitta maglia di interdipendenze tra le classi anche tra quelle poste a livelli di astrazione differente. In realta questa situazione è l'effetto di una cattiva progettazione e comporta una serie di vincoli e di svantaggi di difficile soluzione.

Le numerose dipendenze impediscono il riuso di parti del codice in altri contesti, poiché diventa quasi impossibile isolare le classi di interesse dal resto dell'applicazione; anche le modifiche risultano complesse poiché i cambiamenti ad una classe possono comportare ulteriori cambiamenti ad un numero imprecisato di altre classi o generare malfunzionamenti su altre parti del codice.

Il principio di inversione della dipendenza è una regola che aiuta a ridurre le dipendenze tra le classi.

Prosegue...

Quando si inizia larealizzazione di un nuovo progetto software, spesso è necessarioaffrontare il dilemma se sia più conveniente aggiungere nuovefunzionalità a del codice già esistente e ben testato, oppureriscrivere l'applicazione da zero.

Generalmente si tende ariscrivere da zero gran parte del codice esistente, anche se questocomporta una grande mole di lavoro e la necessità di testarenuovamente la correttezza dei programmi generati.