Standard method att beskriva konfiguereringar

[arte]

Hej,

Finns det någon standard method att beskriva konfigureringar och olika parametrars förhållande till varandra?

T.ex När man köper en bil så är det mängder med options med förhållande till varandra:
- 19" hjul finns bara med turbo motorn.
- 19" går inte om man har fyrhjulsdrift
- Off-road paketet finns bara med AWD

Det blir ganska snabbt komplext med mycket förhållande och parametrar med begränsningar.

Någon som vet ifall det finns någon standard eller väl vedertaget format för detta?

Ett sätt är att beskriva det med ett script och en jäkla massa if satser.

[Micke_s]

Inom matematiken så har du linjära ekvationssystem. Kan även beskrivas som vektorer..

https://sv.m.wikipedia.org/wiki/Linjärt_ekvationssystem

[Micke_s]

Alternativ så får man köra listor med tillåtna kombinationer, ev också otillåtna.

3e alternativet är beskriva det som ett träd.

I bilfallet så hade träd fungerat tror jag.

[Jan Almqvist]

Sanningstabell. Många bitar in. En bit ut.

[lillahuset]

Ungefär så ja.
I Linuxsammanhang förekommer "requires" och "provides" i installationsscript. Lite i stil med vad Jan Almqvist skriver.

[Findecanor]

Jag förstår inte riktigt vad som menas ...

Är det kommandoradsparametrar det handlar om?
Under Unix/Linux finns en konvention för hjälptexter att först visas en eller flera alternativa syntax för parametrarna.
Sedan listas parametrarna. T.ex.

Kod: Markera allt

Usage: prog [options] -a <apelsin> -b <banan> <file>
       prog [options] -c <citron> [  <file> ]
       prog [options] -d <druva> [ -e <äpple> ] <file> ...

Arguments:
  -a  <apelsin>     : Mer om apelsin
  -b <banan>        : Mer om banan
  -c <citron>       : Mer om Citroner

Generic options:
  -v                : Verbose output
  -o <file>         : Write output to <file>

För att skriva API:er i många objektorienterade språk kan man göra samma sak med överlagrade funktioner. Då överlagrar man en funktion med samma namn men olika parameterlistor liksom ovan.

[Micke_s]

Jag tolkade det som det är valfri data, typ webtjänst...

[arte]

Jag tolkade det som det är valfri data, typ webtjänst...

Korrekt! Kan vara vilken data som helst med beroenden.
I min applikation är det väldigt likt web exemplet.

Alternativ så får man köra listor med tillåtna kombinationer, ev också otillåtna.

3e alternativet är beskriva det som ett träd.

I bilfallet så hade träd fungerat tror jag.

Ungefär så ja.
I Linuxsammanhang förekommer "requires" och "provides" i installationsscript. Lite i stil med vad Jan Almqvist skriver.

Tack för tipsen, jag har funderat på något liknande. Träd eller listor.
Använda RPM saker passar inte så bra men teorin är samma.

[lillahuset]

Grundidén kan kanske vara något.

[sodjan]

Det är ju svårt att ange generella metoder som fungerar till lite av varje.
Ofta har man specifika metoder/syntaxer för vissa speciella behov.

En sådan sak som syntax för kommandon är ju ett sådan fall där man
med fördel har ett standardiserat sätt att hantera det så att inte varje
enskild applikation behöver ha kod för att t.ex. ge fel för två switchar
som är i konflikt med varandra. När själva programmet kör så vet den
redan att parametrarna och switcharna är OK.

En "Usage:" utskrift är mer som en rudimentär hjälptext och har inget
med faktisk kontroll av konflikter mellan parametrar/switchar att göra.

[Findecanor]

Usage-utskriften i mitt exempel är ändå ett exempel på en modell för representation av konfigurationer. Man skulle kunna använda den modellen direkt i en syntax-parser. Då skulle den inte vara "rudamentär" -- utan den faktiska modellen som används för både syntax-parsning och utskrift av syntaxen till användaren.

Representationen har tre nivåer:
1. En vektor of "konfigurationer"
2. Varje konfiguration är en vektor av fält
3. Varje fält kan vara valfritt eller obligatoriskt i denna konfiguration.

Alternativet vore att representera lagliga konfigurationer med ett enda uttryck i någon slags representation av Backus-Naur Form, men det skulle kunna bli svårare att förstå för den användare som måste stoppa in, ta bort och ändra i konfigurationerna. Istället har man en ordnar vektor of enklare typer av uttryck och man matchar mot första bästa som uppfyller indata.

[Nerre]

Det finns nog ingen generell metod utan man får kombinera olika metoder.

Träd är ju ett sett, matriser ett annat (de kan ju ha flera dimensioner).

Annars måste det nog bli en massa länkade villkorssatser på nåt sätt.

Jag vet inte om man skulle kunna använda lexisk analys (heter det så? lexikal kanske?)?

[arte]

Har labbat lite med att beskriva konfigureringen som en funktion (ett python script). Kanske passar ganska bra.

En aspekt är också att det skall vara hyfsat enkelt för en ingengör att skapa en konfiguration.
Där är matrisen bra, ett problem med matris kan vara att den växer väldigt snabbt för många inputs. Trädet har inte den egenskapen.

(Som någon skrev så löser en sannings tabell (många in, en ut) problemet).

Tack för tipsen.