Standard method att beskriva konfiguereringar
Standard method att beskriva konfiguereringar
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.
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.
Re: Standard method att beskriva konfiguereringar
Inom matematiken så har du linjära ekvationssystem. Kan även beskrivas som vektorer..
https://sv.m.wikipedia.org/wiki/Linjärt_ekvationssystem
https://sv.m.wikipedia.org/wiki/Linjärt_ekvationssystem
Re: Standard method att beskriva konfiguereringar
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.
3e alternativet är beskriva det som ett träd.
I bilfallet så hade träd fungerat tror jag.
- Jan Almqvist
- Inlägg: 1581
- Blev medlem: 1 oktober 2013, 20:48:26
- Ort: Orust
- lillahuset
- Gått bort
- Inlägg: 13969
- Blev medlem: 3 juli 2008, 08:13:14
- Ort: Norrköping
Re: Standard method att beskriva konfiguereringar
Ungefär så ja.
I Linuxsammanhang förekommer "requires" och "provides" i installationsscript. Lite i stil med vad Jan Almqvist skriver.
I Linuxsammanhang förekommer "requires" och "provides" i installationsscript. Lite i stil med vad Jan Almqvist skriver.
-
- Inlägg: 982
- Blev medlem: 2 juli 2010, 23:04:07
Re: Standard method att beskriva konfiguereringar
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.
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.
Ä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>
Re: Standard method att beskriva konfiguereringar
Jag tolkade det som det är valfri data, typ webtjänst...
Re: Standard method att beskriva konfiguereringar
Korrekt! Kan vara vilken data som helst med beroenden.Micke_s skrev:Jag tolkade det som det är valfri data, typ webtjänst...
I min applikation är det väldigt likt web exemplet.
Micke_s skrev: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.
Tack för tipsen, jag har funderat på något liknande. Träd eller listor.lillahuset skrev:Ungefär så ja.
I Linuxsammanhang förekommer "requires" och "provides" i installationsscript. Lite i stil med vad Jan Almqvist skriver.
Använda RPM saker passar inte så bra men teorin är samma.
- lillahuset
- Gått bort
- Inlägg: 13969
- Blev medlem: 3 juli 2008, 08:13:14
- Ort: Norrköping
Re: Standard method att beskriva konfiguereringar
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.
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.
-
- Inlägg: 982
- Blev medlem: 2 juli 2010, 23:04:07
Re: Standard method att beskriva konfiguereringar
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.
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.
Re: Standard method att beskriva konfiguereringar
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?)?
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?)?
Re: Standard method att beskriva konfiguereringar
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.
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.