Real-time Perspective definisce un insieme di processi e tecniche richieste per un efficace sviluppo dei sistemi real-time. L'intento di UML Real-time è di fornire un insieme minimo, ma sufficiente, di estensioni a UML standard per supportare tutte le tecniche identificate in Real-time Perspective e di favorire e promuovere la standardizzazione nell'industria delle estensione proposte. Perché le tecniche Object-oriented si adattano bene allo sviluppo dei sistemi Real-time? UML Real-time (RT) è la notazione di modellazione che sta alla base di Real-time Perspective. Questa sezione discute di quanto l'object orientation e UML RT si adattino allo sviluppo di sistemi real-time.

Per progettare sistemi real-time sono state usate a lungo tecniche strutturate (ad esempioYourdon) e con grande successo. L'Object orientation si basa su queste tecniche ampliandole ulteriormente per offrire nuovi benefici ai progettisti real-time.

Molte delle tecniche di progetto che avevano reso le tecniche di sviluppo strutturato così utili sono state incorporate e migliorate in quelle object-oriented.

Gli Use Case, una delle tecniche object-oriented più di successo, permette di descrivere il modo in cui operatori umani o dispositivi esterni interaggiscono con il sistema. Gli Object Sequence Diagram descrivono, per un dato Use Case, gli eventi che causano l'interazione e la risposta dettagliata del sistema, incluso il timing. Questa tecnica, sebbene forse con un formalismo diverso, è stata usata in molti progetti real-time negli anni passati per catturare scenari d'uso e identificare probabili problemi di timing.

La Modularità è sempre stata un obiettivo del progetto. La tecnica di partizionamento di un sistema in diversi moduli, sia per definire le interfacce tra gruppi e per separare l'interfaccia dall'implementazione, è stata campionata da Parnas. Uno dei principi fondamentali dell'Object Orientation, l'incapsulazione, ha una base concettuale molto simile alla modularizzazione. Un buon progetto modulare ha sempre consentito un Test di qualità, perchè il modulo si può testare come "scatola nera" e la sua qualità certificata separatamente dagli altri moduli del sistema, piuttosto che testare l'intero sistema in blocco. Questa è anche una proprietà dell'incapsulamento dell'Oggetto (definita qui sotto).

L'Object Orientation può essere visto come un insieme di miglioramenti e formalizzazioni di tecniche esistenti. Le due tecniche basilari che fanno da fondamento all'Object Orientation sono l'incapsulamento e l'ereditarietà.

L'incapsulamento è un meccanismo in cui i dati interni e l'implementazione di un oggetto (modulo) sono nascosti dietro un'interfaccia di metodi invocabili (funzioni). Una tecnica meno tangibile,simile all'incapsulamento, chiamata astrazione, suggerisce che il gruppo di metodi che formano l'interfaccia a uno oggetto, presi come un tutt'uno, rappresentino qualcosa di significativo per un utente di quella interfaccia, ad esempio una coda, un sensore, una traccia radar, piuttosto che essere una collezione arbitraria di funzioni.

L'ereditarietà è un meccanismo per riusare interfacce esistenti di oggetti e forse anche le implementazioni. Un progettista può dire che un oggetto eredita le interfacce di un altro oggetto e quindi aggiungere nuove interfacce specifiche e implementazioni specializzate delle interfacce esistenti (o mantenere le implementazioni esistenti). Questo può fare risparmiare parecchio lavoro ed è un modo di beneficiare del riuso. Presenta una opportunità specifica di estendere un sistema "specializzando" oggetti esistenti per incorporare funzionalità estese.

Si noti che il riuso di codice esistente può anche essere ottenuto tramite delega quando i metodi di un oggetto (modulo) chiamano i metodi di un altro, magari con dei calcoli addizionali. Questa tecnica non è nuova per l'object orientation ed è sempre più preferita all'ereditarietà in certe circostanze.

Un meccanismo meno tangibile simile all'ereditarietà è la classificazione, dove gli oggetti di un sistema sono classificati in "una specie di" gerarchia. Ad esempio un Towed Sonar Array è "una specie di" Sonar, che è "una specie di" Sensore. La classificazione e l'astrazione sono modi naturali di pensare per gli esseri umani e possono aiutare a organizzare e definire oggetti.

Gli oggetti possono essere raggruppati in Classi, dove tutti gli oggetti con la(e) stessa(e) interfaccia(e) sono descritti da una Classe. Questa definizione di Classe può essere usata (in ambienti object-oriented) per creare un nuovo oggetto (talvolta chiamati Istanza) con la(e) stessa(e) interfaccia(e). Questo è da paragonare con un modulo, che è un "oggetto" singolare e, se ne volete un altro simile, dovete copiare il codice o adattare l'interfaccia in qualche modo (e cambiare significativamente l'implementazione).

Pagina Precedente Pagina Successiva