Zweck
Die Regel vor der Implementierung prüfbar machen.
Die Demonstration zeigt, wie eine Normalisierungsroutine spezifiziert und geprüft werden kann. Sie erklärt den Ansatz von CadSyntra und simuliert keine professionelle Lieferung.
Zurück zu den FallstudienEine ähnliche Routine beschreiben
Demonstrationsstudie
Layer-Namensstandardisierung
Eine kleine, vollständig prüfbare Transformation, die zeigt, wie Eingaben, Regeln, Entscheidungen und Grenzen vor der Entwicklung einer Automatisierung definiert werden können.
Nächster Schritt
Eine ähnliche Routine braucht Regeln und Grenzen aus ihrem realen Kontext.
Die Kontaktseite zeigt, welche Informationen den aktuellen Prozess beschreiben helfen, und bewahrt den Kontext dieser Demonstration im Formular.
Originale Demonstration
Originale Demonstration mit synthetischem Szenario, Namen und Daten. Sie stellt keinen Kunden, kein beauftragtes Projekt, keine bereitgestellte Software und kein kommerzielles Ergebnis dar.
- Ursprung
- Synthetisches Szenario und Daten
- Ausgabetyp
- Nach den angegebenen Regeln erwartet
- CAD-Ausführung
- Nicht durchgeführt
Synthetischer Kontext
Eine bewusst kleine und uneinheitliche Liste.
Fünf allgemeine Layernamen wurden mit äußeren Leerzeichen, Kleinschreibung, Unterstrichen, wiederholten Trennzeichen und einem Fachalias vorbereitet. Kein Name stammt aus einer Zeichnung oder einem Standard Dritter.
Dargestelltes Problem
Dieselbe Konvention erscheint in unterschiedlichen Formen.
Ohne eine explizite Normalisierungsfolge hängt die Prüfung von Interpretation ab und Ausnahmen sind schwer zu besprechen. Dieses Beispiel begrenzt das Problem auf den Text jedes Namens.
Beitrag von CadSyntra
Szenario, Regeln und Evidenz wurden für diese Demonstration erstellt.
Der Beitrag bestand darin, das Problem zu definieren, neutrale Daten zu erstellen, die Regeln zu ordnen, Entscheidungen zu dokumentieren und den Vergleich darzustellen. Er umfasste keinen Automatisierungscode, kein Plugin, keine CAD-Zeichnung und kein Deployment.
Definierte Grenzen
Was die Transformation entscheiden kann und was nicht.
- Nur mit den fünf veröffentlichten synthetischen Eingaben arbeiten.
- Regeln in der angegebenen Reihenfolge anwenden, ohne die richtige Fachdisziplin abzuleiten.
- Nur den im Beispiel erklärten Alias ELETRO → ELE verwenden.
- Die Ausgabe als prüfbare Erwartung behandeln, nicht als Ergebnis ausgeführter Software.
Ansatz
Deterministische Normalisierung in fünf Regeln.
Jede Eingabe folgt den folgenden Regeln in der angegebenen Reihenfolge. Jede Ausgabe muss durch die genannten Transformationen erklärbar sein.
- R1
Leerzeichen am Anfang und Ende des Namens entfernen.
- R2
Buchstaben in Großbuchstaben umwandeln.
- R3
Jeden Unterstrich durch einen Bindestrich ersetzen.
- R4
Bindestrichfolgen auf ein Trennzeichen reduzieren.
- R5
Nur das Präfix ELETRO durch den Alias ELE ersetzen.
Prüfbare Evidenz
Eingabe, angewandte Regeln und erwartete Ausgabe.
Die folgenden Ausgaben folgen den Beispielregeln und werden von einem deterministischen lokalen Textmodell geprüft. Die Prüfung ist weder ein Plugin noch eine AutoCAD-Ausführung.
- 01Synthetische Eingabe
arq_paredeAngewandte RegelnR1, R2 und R3Nach den Regeln erwartete AusgabeARQ-PAREDE - 02Synthetische Eingabe
ARQ__PORTAAngewandte RegelnR3 und R4Nach den Regeln erwartete AusgabeARQ-PORTA - 03Synthetische Eingabe
eletro-iluminacaoAngewandte RegelnR2 und R5Nach den Regeln erwartete AusgabeELE-ILUMINACAO - 04Synthetische Eingabe
hid-agua-friaAngewandte RegelnR2Nach den Regeln erwartete AusgabeHID-AGUA-FRIA - 05Synthetische Eingabe
ARQ-PAREDEAngewandte RegelnKeine Änderung erforderlichNach den Regeln erwartete AusgabeARQ-PAREDE
Technische Entscheidungen
Sichtbare und diskutierbare Entscheidungen.
Feste Reihenfolge
Die Reihenfolge verhindert, dass ein Alias oder Trennzeichen bei verschiedenen Eingaben unterschiedlich behandelt wird.
Begrenztes Vokabular
Nur ein bekannter Alias wird umgewandelt; nicht zugeordnete Begriffe bleiben zur Prüfung verfügbar.
Qualifizierte Ausgabe
Sie wird erwartete Ausgabe genannt, weil keine Routine ausgeführt wurde.
Beobachtbares Ergebnis
Der Vergleich entspricht den angegebenen Regeln.
In den fünf veröffentlichten Zeilen verwenden die erwarteten Ausgaben Großschreibung und ein einzelnes Trennzeichen; der Alias ELE erscheint nur bei der vorgesehenen Eingabe. Dies zeigt interne Konsistenz, nicht die Wirksamkeit einer Automatisierung in einer realen Umgebung.
Grenzen
Was dieses Material nicht demonstriert.
- Ausführung in AutoCAD oder Kompatibilität mit irgendeiner Version.
- Implementierung in .NET, C#, AutoLISP oder einer anderen CAD-Technologie.
- Lesen, Ändern oder Validieren einer Zeichnung.
- Umgang mit Konflikten, Duplikaten, Ausnahmen oder den echten Standards eines Teams.
- Deployment, Wartung, Stabilität, Leistung, Produktivität, Einsparungen oder Fehlerreduzierung.
Tatsächlich verwendete Technologien
Das veröffentlichte Material ist eine statische redaktionelle Demonstration.
- Versioniertes JSON für Daten und Texte.
- Deterministisches lokales Modell zur Prüfung der fünf synthetischen Ausgaben.
- React Server Component für statisches Rendering.
- Semantisches HTML und Tailwind CSS für eine responsive Darstellung.
In einem realen Projekt könnte die Bewertung AutoLISP oder .NET mit C# zur Ausführung der Regeln in AutoCAD nahelegen. Diese Technologien wurden in dieser Demonstration nicht verwendet.
Beziehung zum Angebot
Die Evidenz ist mit einer veröffentlichten Fähigkeit und einem Problem verknüpft.
Nächster Schritt
Eine ähnliche Routine braucht Regeln und Grenzen aus ihrem realen Kontext.
Die Kontaktseite zeigt, welche Informationen den aktuellen Prozess beschreiben helfen, und bewahrt den Kontext dieser Demonstration im Formular.