Diagramma UML per un'implementazione esistente

2

Ho del codice, che voglio presentare in UML, ma a un certo punto mi sono bloccato. Lascia che ti dica qualcosa sulla funzionalità del codice.

Ho uno spazio di lavoro in cui posso posizionare alcuni Component s, selezionarli, eliminare, aggiungere nuovi, spostare ecc. Posso anche collegarli secondo alcune regole (ci sono diversi tipi di Component s disponibili) . Per determinare se un gruppo di Component s può essere collegato o meno, ho implementato alcuni semplici meccanismi. In questo meccanismo compaiono le seguenti parti:

[ EDIT : nota che "PlausibilityRule" in UML e "ConnectionRule" sono le stesse cose: è la mia supervisione]

ConnectionRule : ottieni il tipo di connessione e controlla se una raccolta di Component s data come parametro può essere collegata in base a questo ConnectionRule .

ConnectionRulesSet - contiene molte regole all'interno. Il cliente chiede un set con regole come questa: "in base a quali regole definite in un set, i componenti dati come parametro, possono essere collegati"? ConnectionRulesSet fornisce una lista di ConnectionRules come risposta. Un insieme di regole di connessione concrete è esposto solo all'interfaccia throug: il client non può creare un'istanza di un RulesSet concreto.

RulesSetFactory - a seconda di molte circostanze, l'applicazione può utilizzare% diverso% di escluso. Ecco perché ho creato una factory che fornisce una corretta implementazione dell'interfaccia ConnectionRulesSet a seconda delle circostanze specificate.

Ora diamo un'occhiata al codice cliente:

// list of components which should be verified in terms of connection plausibility:
List<Component> selectedComponents = ... ;
// Get set of rules for normal conditions:
ConnectionRulesSet setOfRules = RulesSetFactory.getRulesSet(NORMAL_SET);
List<ConnectionRule> fulfilledRules = setOfRules.getFulfilledRules(final selectedComponents);
// Do something with fulfilled rules:
for(PlausibilityRule rule : fulfilledRules){
   addToAvailableRulesList(rule.getConnectionType().getName()); // display names of connetion types...
} 

Il mio problema è che non sono sicuro di come creare un diagramma di classe UML per tale soluzione dal punto di vista del Cliente ... Come esporre le relazioni tra la soluzione presentata e un Cliente. Il client utilizza in realtà tutti: ConnectionRule, RulesSet, RulesSetFactory ...

C'è una delle mie idee qui sotto ... Cosa ne pensi? Hai una soluzione migliore?

    
posta guitar_freak 13.01.2014 - 21:03
fonte

1 risposta

1

Va bene, darò una risposta a questa risposta - spero di aver capito tutto correttamente!

Il diagramma

In primo luogo, mi permetta di scusarmi in anticipo per il layout ( yUML è bello e veloce, ma talvolta espone estesi diagrammi di grandi dimensioni).

Comepuoivedere,noncisonomolticambiamenti.Macenesonoalcuni,valeadire:

  • Aggiuntaun'aggregazione(inparticolare,una" composizione ") da ConnectionRuleSet a ConnectionRule .

    Questo è più chiaro, credo, della relazione restituisce la lista di nel diagramma originale (come ConnectionRuleSet è un insieme di ConnectionRule 's ). La relazione del contenitore riflette la responsabilità di aggregazione di ConnectionRuleSet , ma potrebbe non esplicitare esplicitamente la responsabilità comportamentale del metodo getFulfilledRules .

  • Rimosso il utilizza tra Client e ConnectionRuleSet .

    Considerata la relazione usi già posizionata tra Client e ConnectionRule direttamente, aggiungendo un altro usi tra Client e ConnectionRuleSet Mi sento superflua inutilmente le cose. È chiaro che un ConnectionRuleSet contiene ConnectionRule (grazie alla composizione).

  • Aggiunta una classe Component al diagramma.

    Non sono sicuro al 100% esattamente che cosa sia Component nel tuo dominio, tuttavia penso che potrebbe valerne la pena per includerlo nel diagramma. Dopo tutto, è menzionato nei metodi in ConnectionRule e ConnectionRuleSet . Non è del tutto chiaro dalla tua domanda quale dovrebbe essere la relazione tra Client e Component , ho usato l'aggregazione come sembra un Client contiene molti Component 's.

Altre note del diagramma

  1. Esempi di lezioni concrete : penso che le classi concrete di esempio, come ConcreteConnectionRuleSet , ConcreteRule1 e ConcreteRule2 , ecc. aggiungano molto poco a il diagramma. Li ho inclusi come erano nell'originale, ma penso che il diagramma sarebbe molto più semplice senza di essi.

  2. Vector < Componente > : di nuovo, incluso come era nell'originale, ma vorrei STRONGLY consigliarti di non legare design a particolari implementazioni della struttura dati (questo vale anche per List < Component > too!). Qualcosa come Collection<Component> , o almeno un IList<Component> sarebbe molto meglio qui.

Sentiti libero di vai su yUML e modifica lo schema ... Di seguito è riportato il codice yUML codice che ho usato per farlo:

[«interface»;RuleSetFactory|+ getRuleSet(rulseSetType : enum)]-.-                 «instantiates»-.->[«interface»;ConnectionRuleSet|getFulfilledRules(comps : List≤Component≥)]
[«interface»;ConnectionRuleSet]++-[«interface»;ConnectionRule|+ getConnectionType();+ isFulfilledForComponents(comps : Vector≤Component≥)]
[«interface»;ConnectionRule]<-.-   uses-.-[Client]
[Client]<>-?-[Component]
[Client]-.-requests       RuleSet from-.->[«interface»;RuleSetFactory]
[«interface»;ConnectionRuleSet]^.=[ConcreteConnectionRuleSet]
[«interface»;ConnectionRule]^-.=[ConcreteRule1]
[«interface»;ConnectionRule]^-.=[ConcreteRule2]
    
risposta data 04.03.2016 - 01:03
fonte

Leggi altre domande sui tag