En tre-skikts arkitektur f r Begrepps-, Informations- och Data-modeller utg ende fr n en kombination av kasus av a

1. En tre-skikts arkitektur f�r Begrepps-, Informations- och Data-modeller utg�ende fr�n en kombination av kasus "av = ackusativ" resp "f�r = dativ".Hans Willars, Guide

2. Om vi till att b�rja med avgr�nsar till "av" och "f�r" f�r vi en m�jlighet att sortera upp i oredan runt Begreppsmodeller(eller motsvarande) Informationsmodeller(eller motsvarande) Datamodeller (eller motsvarande) Vi utg�r fr�n kasus-sammanhanget runt modellbegreppet och v�ljer h�r att s�rskilja modeller med en kombination av kasus "av = ackusativ" resp "f�r = dativ". D� kan f�ljande terminologi f�resl�s: Begreppsmodeller �r modeller...av verksamhetens begreppsv�rld (= tankev�rld)[1]f�r att kunna f�rst� och prata om den p� ett gemensamt s�tt i verksamheten, ochf�r att f�rankra begreppen och deras �satta termer i en gemensam social kontext. Informationsmodeller �r modeller...av ett urval av s�dana vht-begrepp som man vill se som hanteringsobjekt i verksamhetens konkreta bedrivandef�r att speca/visa vilka informationer man vill kunna "f�" om dem i verksamheten, ochf�r att f�rankra hanteringsobjekten definitionsm�ssigt i de mer ursprungliga begreppen. Datamodeller �r modeller...av data om verksamhetens hanteringsobjekt, enligt n�gon vald datautformningsprincipf�r att visa hur de kan hanteras i verksamhetens datahantering (dvs indatering, uppdatering, uts�kning, bearbetning...), och f�r att f�rankra data definitionsm�ssigt i de mer ursprungliga hanteringsobjekten. Obs att det f�rsta syftet som specats f�r varje modelltyp ovan �r ett "fram�triktat" syfte som g�r att vi kan komma vidare i ett utvecklingsarbete, medan det andra syftet �r "bak�triktat" f�r att s�kra sp�rbarhet (dvs svara p� fr�gan "Varf�r blev det just s� h�r?") Vi ser genast att de tv� �versta, begrepps- resp informationsmodeller, med detta val av terminologi och definition, �r modeller av likartade fenomen - verksamhetens begrepp. Dessa modeller "tillh�r" d�rmed verksamheten, eftersom vi som regel inte vill att IS/IT utan vidare ska kunna p�tvinga verksamheten hur den ska t�nka och tala om verksamhetsn�ra ting.[2] [1] Det vi h�r kallar begreppsmodeller b�r mer strikt ses som modeller av verkligheten sedd genom v�r naturgivet begr�nsade f�rm�ga till begreppsbildning. Se Bj�rn Nilssons "Om begreppsmodeller", ref BN1 i bil 8. [2] F�r s�vitt inte t ex f�retagsledningen har fattat ett medvetet beslut om detta, t ex genom att v�lja k�pa ett COTS, varvid det blir relevant att utf�rda p�budet "T�nk och tala enligt detta COTS!". L�tt att s�ga, sv�rare att f�lja.Vi utg�r fr�n kasus-sammanhanget runt modellbegreppet och v�ljer h�r att s�rskilja modeller med en kombination av kasus "av = ackusativ" resp "f�r = dativ". D� kan f�ljande terminologi f�resl�s: Begreppsmodeller �r modeller...av verksamhetens begreppsv�rld (= tankev�rld)[1]f�r att kunna f�rst� och prata om den p� ett gemensamt s�tt i verksamheten, ochf�r att f�rankra begreppen och deras �satta termer i en gemensam social kontext. Informationsmodeller �r modeller...av ett urval av s�dana vht-begrepp som man vill se som hanteringsobjekt i verksamhetens konkreta bedrivandef�r att speca/visa vilka informationer man vill kunna "f�" om dem i verksamheten, ochf�r att f�rankra hanteringsobjekten definitionsm�ssigt i de mer ursprungliga begreppen. Datamodeller �r modeller...av data om verksamhetens hanteringsobjekt, enligt n�gon vald datautformningsprincipf�r att visa hur de kan hanteras i verksamhetens datahantering (dvs indatering, uppdatering, uts�kning, bearbetning...), och f�r att f�rankra data definitionsm�ssigt i de mer ursprungliga hanteringsobjekten. Obs att det f�rsta syftet som specats f�r varje modelltyp ovan �r ett "fram�triktat" syfte som g�r att vi kan komma vidare i ett utvecklingsarbete, medan det andra syftet �r "bak�triktat" f�r att s�kra sp�rbarhet (dvs svara p� fr�gan "Varf�r blev det just s� h�r?") Vi ser genast att de tv� �versta, begrepps- resp informationsmodeller, med detta val av terminologi och definition, �r modeller av likartade fenomen - verksamhetens begrepp. Dessa modeller "tillh�r" d�rmed verksamheten, eftersom vi som regel inte vill att IS/IT utan vidare ska kunna p�tvinga verksamheten hur den ska t�nka och tala om verksamhetsn�ra ting.[2]

3. Modellarkitektur f�r Begrepp - Informationer - DataModeller i 3 skikt, av olika saker och i olika syften! Detta f�r tv� direkta konsekvenser: Verksamheten ges en stor frihet att identifiera och definiera de begrepp som man beh�ver i verksamheten f�r att i grunden kunna f�rst� vad denna �r och g�r ut p�. Som ovan visats medf�r principen om distribuerad inneb�rd att man f�r f�rst�elsen ibland m�ste ta med mer �n vad som sn�vt r�knas till sj�lva verksamheten. Men d� kan man ocks� dra avgr�nsningar tydligt f�r att visa och f�rst� vad som r�knas till verksamheten resp ligger utanf�r. De begrepp man v�ljer att se som hanteringsobjekt, dvs objekt man vill kunna informera sig om och bilda sig information om, kommer f�rst�ndsm�ssigt att vara samma som motsvarande begrepp i begreppsmodellen, men i ett avgr�nsat urval och f�r ett annat syfte. F�r det som �r samma som i begreppsmodellen kan man allts� anv�nda samma uttrycksformer/notationer, f�rutsatt att de duger f�r det nya syftet. Det �r d�rf�r inte ovanligt att begrepps- resp informationsmodeller ser v�ldigt lika ut, och att man f�r tydligheten allts� b�r dokumentera noga vad det �r man ser i modellen. F�lj r�den ovan om vad man ska kunna s�ga om en modell!Detta f�r tv� direkta konsekvenser: Verksamheten ges en stor frihet att identifiera och definiera de begrepp som man beh�ver i verksamheten f�r att i grunden kunna f�rst� vad denna �r och g�r ut p�. Som ovan visats medf�r principen om distribuerad inneb�rd att man f�r f�rst�elsen ibland m�ste ta med mer �n vad som sn�vt r�knas till sj�lva verksamheten. Men d� kan man ocks� dra avgr�nsningar tydligt f�r att visa och f�rst� vad som r�knas till verksamheten resp ligger utanf�r. De begrepp man v�ljer att se som hanteringsobjekt, dvs objekt man vill kunna informera sig om och bilda sig information om, kommer f�rst�ndsm�ssigt att vara samma som motsvarande begrepp i begreppsmodellen, men i ett avgr�nsat urval och f�r ett annat syfte. F�r det som �r samma som i begreppsmodellen kan man allts� anv�nda samma uttrycksformer/notationer, f�rutsatt att de duger f�r det nya syftet. Det �r d�rf�r inte ovanligt att begrepps- resp informationsmodeller ser v�ldigt lika ut, och att man f�r tydligheten allts� b�r dokumentera noga vad det �r man ser i modellen. F�lj r�den ovan om vad man ska kunna s�ga om en modell!

4. Sammanfattning av utvecklingskedjan Begrepp - Informationer - Data3 "v�rldar" � 3 syften � 3 drivande fr�gor � 3 olika former av svar! En utvecklingsprocess som samspelar med arkitekturen Enligt ovan f�ljer ur arkitekturen en naturlig utvecklingsprocess som med bibeh�llen konsekvens (dvs r�tt v�gval fram�t resp f�rankring bak�t) och i avgr�nsade steg leder fr�n verksamhetens/"aff�rens" definition och inriktning till definitioner av de dataunderlag/databaser som st�der aff�rsid�n i det dagliga arbetet. Denna utvecklingsprocess har tv� �vergripande syften: Syftet f�r IS/IT �r att man ska kunna utforma verksamhetens databaser s� att de blir ensade, rationella, effektiva och "normaliserade". Databaserna kan d�rigenom bli merutnyttjade, inte bara genom att vara allm�nt tillg�ngliga utan �ven genom att kunna tolkas och f�rst�s r�tt vad avser inneh�ll och kvalitet. Syftet f�r �k�rnverksamheten� �r att kunna kommunicera data s�v�l inom verksamheten som mellan verksamheten och omv�rlden utan att de blir misstolkade, f�rvanskade eller oavsiktligt beskurna. En utvecklingsprocess som samspelar med arkitekturen Enligt ovan f�ljer ur arkitekturen en naturlig utvecklingsprocess som med bibeh�llen konsekvens (dvs r�tt v�gval fram�t resp f�rankring bak�t) och i avgr�nsade steg leder fr�n verksamhetens/"aff�rens" definition och inriktning till definitioner av de dataunderlag/databaser som st�der aff�rsid�n i det dagliga arbetet. Denna utvecklingsprocess har tv� �vergripande syften: Syftet f�r IS/IT �r att man ska kunna utforma verksamhetens databaser s� att de blir ensade, rationella, effektiva och "normaliserade". Databaserna kan d�rigenom bli merutnyttjade, inte bara genom att vara allm�nt tillg�ngliga utan �ven genom att kunna tolkas och f�rst�s r�tt vad avser inneh�ll och kvalitet. Syftet f�r �k�rnverksamheten� �r att kunna kommunicera data s�v�l inom verksamheten som mellan verksamheten och omv�rlden utan att de blir misstolkade, f�rvanskade eller oavsiktligt beskurna.

5. Verksamhetsbaserad datautformningArbetsg�ng/process i 4 principiella och v�rdeh�jande steg. Ovanst�ende bild visar 4 "normalskeden" f�r att ta sig "fr�n allm�n verksamhetsutveckling till k�rbara datastrukturer". H�r fokuseras s�rskilt den statiska verksamhetsaspekten (faktakunskaper om verksamhets- och informationsresurser, objekt, etc), men utan att f�r den skull gl�mma bort att detta bara �r en av flera aspekter som m�ste analyseras i ett konsekvent sammanhang. Som vi ser utg�r man som regel fr�n en generellt inriktad begreppsanalys f�r att etablera den gemensamma f�rst�elsen som plattform f�r breda samverkande satsningar p� kompetens, organisation, IS/IT, mm. Med detta breda syfte �r det l�mpligt att uttrycka framtagna modeller med ett spr�k som fr�mst �r aff�rsdefinierande och f�rst�elseskapande och d�rf�r n�ra ansluter till verksamhetens eget naturliga spr�kbruk. D�refter avgr�nsas och preciseras (delar av) dessa modeller och fylls p� med verksamhetsdetaljer som �r viktiga f�r fortsatt datautformning, h�r kallade Informationssysteminriktade objektmodeller (alt informationsmodeller, hanteringsobjektmodeller). Det �r fortfarande verksamhetens f�reteelser som modelleras, i ett urval som har gjorts utifr�n informationsbehov, men syftet �r inte l�ngre lika brett utan har sn�vat in mot IS-utveckling. D�rf�r kan det vara l�mpligt att �verg� till ett spr�k som �r allm�nt, formaliserat och ev standardiserat f�r just detta, t ex UML. Huvudsaken �r att allt som verksamhetens anv�ndare vill kunna se och g�ra f�rs vidare till n�sta steg. �verg�ngen mellan verksamhetsv�rlden och IT-v�rlden leder till en nominell/ideal datastruktur ("datamodell") med syfte ett vara maximalt kongruent med verksamheten (normalisering). Den nominella datastrukturen uttrycks enligt n�gon i f�rv�g ansatt strukturprincip (flata filer, relationstabeller, objektorienterade databaser, etc). Inga anpassningar �nnu till prestandakrav eller aktuella datahanteringsprodukter. Slutligen g�rs en driftm�ssig anpassning med h�nsyn till teknikens f�rm�ga att klara s�kerhet, prestandakrav mm. H�r kan man beh�va g�ra avsteg fr�n den ideala kongruensen, t ex genom denormalisering. Vi f�r d� en driftm�ssig datastruktur : de datastrukturer och dataelement som �r deklarerade enligt vald datahanteringsprodukt och som anv�ndarna k�r sina dataarbeten mot. Ovanst�ende bild visar 4 "normalskeden" f�r att ta sig "fr�n allm�n verksamhetsutveckling till k�rbara datastrukturer". H�r fokuseras s�rskilt den statiska verksamhetsaspekten (faktakunskaper om verksamhets- och informationsresurser, objekt, etc), men utan att f�r den skull gl�mma bort att detta bara �r en av flera aspekter som m�ste analyseras i ett konsekvent sammanhang. Som vi ser utg�r man som regel fr�n en generellt inriktad begreppsanalys f�r att etablera den gemensamma f�rst�elsen som plattform f�r breda samverkande satsningar p� kompetens, organisation, IS/IT, mm. Med detta breda syfte �r det l�mpligt att uttrycka framtagna modeller med ett spr�k som fr�mst �r aff�rsdefinierande och f�rst�elseskapande och d�rf�r n�ra ansluter till verksamhetens eget naturliga spr�kbruk. D�refter avgr�nsas och preciseras (delar av) dessa modeller och fylls p� med verksamhetsdetaljer som �r viktiga f�r fortsatt datautformning, h�r kallade Informationssysteminriktade objektmodeller (alt informationsmodeller, hanteringsobjektmodeller). Det �r fortfarande verksamhetens f�reteelser som modelleras, i ett urval som har gjorts utifr�n informationsbehov, men syftet �r inte l�ngre lika brett utan har sn�vat in mot IS-utveckling. D�rf�r kan det vara l�mpligt att �verg� till ett spr�k som �r allm�nt, formaliserat och ev standardiserat f�r just detta, t ex UML. Huvudsaken �r att allt som verksamhetens anv�ndare vill kunna se och g�ra f�rs vidare till n�sta steg. �verg�ngen mellan verksamhetsv�rlden och IT-v�rlden leder till en nominell/ideal datastruktur ("datamodell") med syfte ett vara maximalt kongruent med verksamheten (normalisering). Den nominella datastrukturen uttrycks enligt n�gon i f�rv�g ansatt strukturprincip (flata filer, relationstabeller, objektorienterade databaser, etc). Inga anpassningar �nnu till prestandakrav eller aktuella datahanteringsprodukter. Slutligen g�rs en driftm�ssig anpassning med h�nsyn till teknikens f�rm�ga att klara s�kerhet, prestandakrav mm. H�r kan man beh�va g�ra avsteg fr�n den ideala kongruensen, t ex genom denormalisering. Vi f�r d� en driftm�ssig datastruktur : de datastrukturer och dataelement som �r deklarerade enligt vald datahanteringsprodukt och som anv�ndarna k�r sina dataarbeten mot.

6. Nybild TxtTxt

7. Nybild TxtTxt

8. Begrepps-modellDrivande fr�ga: Vad �r inneb�rd i, & mening med, X? B�ttre exempel med f�rklarande text p� g...B�ttre exempel med f�rklarande text p� g...

9. Informations-modellDrivande fr�ga: Vad vill vi veta om X, i sitt sammanhang? B�ttre exempel med f�rklarande text p� g...B�ttre exempel med f�rklarande text p� g...

10. Data(bas)-modellDrivande fr�ga: Hur vill vi se data om X lagrade & s�kbara? B�ttre exempel med f�rklarande text p� g... B�ttre exempel med f�rklarande text p� g...