SE516029C2 - Förfarande system och datorprogram för integrering av en applikation i ett datorsystem - Google Patents

Description

25 30 35 516 029 ' IQ . "- y _ ,. 2 ibland kallas ärvda applikationer (legacy applications), har också varit svårt, tidsödande och dyrt.

Införandet av objektorienterade programmeringsspråk och metoder har lett till nàgot kortare utvecklingstider och gjort det nàgot lättare att införliva och integrera nya applikationer.

IEC-standarden DIS ISO/IEC 1346-l 1995, principles and reference designations, Structuring innehåller ett referensbeteckningssystem för otvetydig identifikation av delar av varje system i det generella tekniska samman- en anläggning hanget, såsom i ett tillverkande bolag, eller ett affärsdrivande bolag. I denna beskrivning används termerna objekt, aspekt och referensbeteckningar i synnerhet för att hänvisa till sådana delar av varje system i det generella tekniska sammanhanget enligt defi- nitionerna i DIS ISO/IEC 1346-1. Dessutom kommer vissa ytterligare typer av objekt och aspekter att ytterligare definieras under beskrivningens gång.

US 5 787 425 beskriver ett koncept för klient-server- förhållanden mellan objekt i ett objektorienterat dator- program. Objekt kommunicerar med varandra, t ex för att ett första objekt skall kunna få åtkomst till data som innehas av ett andra objekt. När det första objektet behöver åtkomst till någon data som kontrolleras av det andra objektet, betraktas det första objektet som klient till det andra objektet, vilket i sin tur betraktas som server. För att få åtkomst till data som kontrolleras av serverobjektet, det andra objektet i detta exempel, kommer en av operationerna hos det första objektet, klient- objektet, objektet. Den sålunda begärda operationen hos server- objektet utförs sedan för att få åtkomst till och/eller manipulera datan på klientobjektets vägnar. att anropa en av operationerna hos server- När klientobjektet och serverobjektet både existerar och körs i samma process (minnesutrymme) i samma dator, be- 10 15 20 25 30 35 516 029 _ såsom "in process". När klient- och serverobjekten körs i olika processer (minnesutrymmen) i samma dator, beskrivs serverobjektet såsom "local". När klient- och serverobjekten körs i olika datorer, beskrivs serverobjektet såsom "remote".

Standardoperationen hos en Object Request Broker (ORB) är att hantera önskemål mellan klient- och serverobjekt. ORBn gör hanteringen av önskemålen tydlig för klientobjektet antingen serverobjektet är ”in process", "local" eller "remote".

Ett känt exempel på en ORB är publicerat av Microsoft och kallas Component Object Model (COM). Den är standard för interoperabilitet mellan mjukvarukomponenter och introdu- cerades 1993. COM är oberoende av programmeringsspråk och stöds av många vitt använda datoroperativsystem såsom Windows, Mac OS och många typer av Unix. Den använder en enstaka model för mjukvarukomponenter för att kommunicera med varandra, både inuti samma beräkningsprocess och också tvärs över process- och nätverksgränser. COM är också förknippad med ActiveX (varumärke), ett system av mjuk- varukomponenter som använder sig av COM-teknologier. COM- standarden från 1995 beskrivs i The Component Object Model Specification som är tillgänglig i Microsofts MSDN online- bibliotek på den webbplats som upprätthålls av Microsoft.

Ytterligare information om COM finns bl a i en artikel i Dr Dobbs Journal, december 1994, med titeln The Component Object Model: Technical Overview.

Införandet av objektorienterad programmering och klient- servermetoden har lett fram till designverktyg som gör det lättare att designa datoriserade system med återanvänd- ningsbara moduler som samarbetar på ett standardiserat sätt för att utföra systemets kollektiva funktioner. Det är emellertid nödvändigt att integrera applikationer av olika ursprung, vilka är implementerade med hjälp av objekt- och icke-objektorienterade teknologier, inklusive nya applikationer, såväl som applikationer som man för- 10 15 20 30 35 516 029 I ' nu :H :". u utsåg men inte kände till i detalj vid tiden för plane- ringen av ett datoriserat system. Konventionell system- design kräver att ett objekt i ett datoriserat system har förhandsinformation om en applikation för att objektet t ex skall kunna få åtkomst till en metod som implemen- teras av applikationen. Ett nytt sätt att designa system krävs för att integrera applikationer så att olika appli- kationer kan vara både helt oberoende, baserat på olika teknologier och utan kunskap om varandras specifika egen- skaper, och samtidigt kunna samarbeta med varandra för att utföra den kollektiva funktionaliteten hos det datorise- rade systemet.

REDoGöRELsE FÖR UPPFINNINGEN Ett ändamål med uppfinningen är att åstadkomma ett för- farande för att integrera en applikation i ett system för (a real world Ett datoriserad styrning av ett verkligt objekt object) samt ett system där förfarandet utnyttjas. annat ändamål med uppfinningen är ett förfarande för att integrera en applikation så att förhandsinformation om applikationen inte behöver specificeras. Ett annat ändamål med uppfinningen är att åstadkomma ett förfarande för att framställa verkliga objekt i ett datoriserat system på ett systematiskt sätt, där olika typer av information om det länkade till det verkliga objektet, behandlas, presenteras och åtgärdas, verkliga objektet kan erhållas, samt ett system som utnyttjar detsamma. Ett annat ändamål med upp- finningen är integrera ett stort urval applikationer inom systemet på ett modulärt sätt. Ett annat ändamål med upp- finningen är att åstadkomma ett förfarande för integration av senare och ytterligare applikationer i befintliga sys- tem. Ett annat ändamål med uppfinningen är att möjliggöra integration av olika applikationer som implementeras med användning av objekt- och icke-objektorienterade tekno- logier. Ett annat ändamål med uppfinningen är att åstad- komma ett system och ett förfarande där olika applika- tioner, som är oberoende och utan kunskap om varandras specifika egenskaper, kan samarbeta för att gemensamt 10 15 20 25 30 35 516 029 V ll r' j", u àstadkomma systemfunktionalitet som är förknippad med nämnda verklika objekt. Ett ytterligare ändamàl med uppfinningen är att àstadkomma ett förfarande och ett system där styrning av utrustningar kan àstadkommas pà vilken plats som helst inklusive ett hus eller en bostad.

Dessa och andra ändamàl ástadkoms enligt föreliggande uppfinning av ett förfarande som beskrivs i patentkrav 1 och ett system som beskrivs i patentkrav 14, samt en datorprogramprodukt som beskrivs i patentkrav 27. Före- liggande uppfinning kan sammanfattningsvis beskrivas som ett förfarande för design av ett datoriserat system, och ett system som utnyttjar nämnda förfarande, där ett eller flera verkliga objekt representeras av ett objekt som kallas sammansatt objekt (Composite Object). Det samman- satta objektet är en del av ett datorprogram som ingar i det datoriserade systemet. En eller flera sidor av det ett steg i en verkliga objektet, sàsom en fysisk plats, process, en styrfunktion, en operatörsinteraktion, en simuleringsmodell, dokumentation om objektet osv beskrivs sàsom en eller flera aspekter av det sammansatta objektet (Aspects of the Composite Object). Ett centralt särdrag i föreliggande uppfinning är att varje sammansatt objekt är en platshàllare för en eller flera aspekter av det verk- liga objektet, vilka representerar det verkliga objektet.

Ett viktigt nytt och användbart element i den föreliggande uppfinningen ligger i att olika applikationer kan användas för att implementera olika aspekter eller grupper av aspekter av ett sammansatt objekt. Varje applikation defi- nierar gränssnitt som är oberoende av implementeringen av själva applikationen. Dessa gränssnitt kan användas av andra applikationer, som implementerar andra aspekter eller grupper av aspekter av det sammansatta objektet, sà att applikationerna kan samarbeta för att åstadkomma en funktionalitet som är summan av alla aspekter, dvs funk- tionaliteten hos det sammansatta objektet. Gränssnitten specificeras som COM-gränssnitt, där COM-gränssnitt imple- menteras av COM-objekt sàsom beskrivits ovan. Gränssnitten 10 15 20 25 30 35 516 029 kan vara ”ip nrnrøcq” ”T nnal” varje applikation använda vilken som helst objekt- eller icke- orienterad teknologi, sàsom C++ eller Java, objektorienterad teknologi, sásom relationsdatabaser, sekventiella filer osv.

Mànga olika typer av applikationer kan användas för att implementera aspekter. Ett ordbehandlingsprogram kan t ex användas av en aspekt för att presentera en funktions- specifikation, och av en annan aspekt för att redigera operatörsanteckníngar. Likaledes kan ett CAD-program användas av en aspekt för att visa en ritning och användas av en annan aspekt för att visa ett elektriskt diagram eller av en tredje aspekt för att visa ett rörlednings- eller instrumenteringsdiagram. Applikationsprogrammen är inte begränsade pà nàgot sätt till de program som används i traditionella processtyrningsförfaranden. En produk- tionsstyrningsapplikation kan t ex användas av en aspekt för att visa en arbetsorder, av en annan aspekt för att köra ett utrustningsschema eller av en tredje aspekt för att Visa material i lager.

Den främsta fördelen med föreliggande uppfinning är att ett stort urval av applikationer kan integreras i ett datoriserat system pà ett modulärt och oberoende sätt.

Varje applikation är, med hjälp av sammansatta objekt och aspekter inneslutna av sammansatta objekt, ansvarig för sin egen data och sina egna operationer. Detta betyder att applikationer som är internt baserade pà olika objekt- eller icke-objektorienterade implementeringsmetoder kan integreras pà sàdant sätt att ingen skillnad är uppenbar mellan metoderna för att leverera tjänster som tillhanda- hàlls av de olika applikationerna. Detta innebär också att modifiering av en applikation eller tillägg av en appli- kation inte kräver nàgot ändring av andra applikationer i systemet. Detta är en särskilt användbar detalj i före- liggande uppfinning därför att den underlättar tillägg av nya sammansatta objekttyper som kan kräva tillägg av nya aspekter, inklusive nya applikationer för att hantera 10 15 20 25 30 35 516 029 7 dessa nya aspekter. En annan fördel med uppfinningen är att aspekter av ett sammansatt objekt erbjuder ett för- farande för att indikera arv vilket gör det möjligt för sammansatta objekt att ärva vissa aspekter automatiskt utan att nödvändigtvis definiera arvsförhallanden mellan specifika sammansatta objekt.

Föreliggande uppfinning erbjuder sàledes viktiga fördelar i flera avseenden innefattande: i) för systemutvecklaren, som kan integrera befintliga, nya och framtida eventuellt ännu inte förutsedda applikationer, utan att pà ett om- fattande sätt behöva skriva om varje applikation för att passa nagon speciell datamodell eller implementerings- metod; ii) för systemanvändaren, som kommer att uppfatta en sömlös integrering av väldigt olika applikationer som samverkar för att åstadkomma den fulla funktionalitet som (entities) är förknippad med de verkliga företeelser som han eller hon är sysselsatt med; och iii) för systemägaren vars investering skyddas därför att systemet kan utvecklas applikationer som inte tidigare med, eller utbyggas av, förutsetts.

Tillämpligheten i föreliggande uppfinning är inte be- gränsad till traditionella processstyrningsfunktioner och -användning utan kan också utsträckas till manga andra omráden. Detta inbegriper affärs- och kommersiell verk- samhet sásom produktionsledning, konstruktions- och under- hàllssystem samt affärssystem och finansiella system. Den innefattar också styrning av utrustning pà andra platser inklusive utrustningar eller processer i en bostad eller ett hus.

FIGURBESKRIVNING Föreliggande uppfinning skall närmare beskrivas i samband med bifogade ritningar.

Figur l visar schematiskt ett COM-objekt med gränssnitt enligt en känd standard, COM. 10 15 20 25 30 35 Figur 2 visar schematiskt ett sammansatt objekt och aspekter enligt en utföringsform av föreliggande uppfinning.

Figur 2b visar schematiskt en aspekttyp av en aspekt enligt en utföringsform av föreliggande uppfinning.

Figur 3 visar schematiskt hantering av en fràga av ett sammansatt objekt genom en aspekttyp enligt en utförings- form av föreliggande uppfinning.

Figur 4 visar schematiskt ett schema av arv för aspekter av ett sammansatt objekt enligt en annan utföringsform av föreliggande uppfinning.

Figur 5 visar schematiskt arv för aspekter av ett samman- satt objekt i samma struktur enligt en föredragen utfö- ringsform av föreliggande uppfinning.

BESKRIVNING AV FÖREDRAGNA UTFÖRINGSEXEMPEL Figur l visar ett COM-objekt 5 med tre kända gränssnitt l, 2, 3 och ett standardgränssnitt 4, vilket gränssnitt är känt inom COM-modellen sàsom IUnknown. COM är en befintlig standard.

För att underlätta förståelsen av uppfinningen är det nödvändigt att förklara nägra detaljer om COM. Utveck- lingen av datoriserade system med användning av COM siktar pà att utveckla ett eller flera COM~objekt. COM-objektet tillhandahåller sina tjänster via metoder som grupperas i ett eller flera gränssnitt. Varje gränssnitt, sàsom gränssnitt 1-3 i figur 1, innefattar i ett typiskt fall metoder som tillhandahåller ett särskild urval tjänster.

Genom dessa gränssnitt kan ett klientobjekt begära fram de metoder som definieras av COM-objektet. Den uppsättning gränssnitt som stöds av ett specifikt COM-objekt kan förändras allteftersom objektet genomgár revisioner och uppdateringar, men varje gränssnitt som en gang definie- rats förblir alltid detsamma. Pa så sätt minimeras problemen med versioner och bakàtkompatibilitet. Alla COM- objekt stöder ett gränssnitt som kallas IUnknown. Detta gränssnitt styr objektets livstid (genom referensräkning) 10 15 20 25 30 35 516 029 och gör det möjligt för klientobjekt att erhålla infor- mation om andra gränssnitt som stöds av objektet. Den traditionella användningen av IUnknown gör det således möjligt för COM-objekt att interagera utan att innan dess ha fått information om varje möjligt gränssnitt som kan stödjas av varje annat objekt. Figur l illustrerar ett COM-objekt 5 med åtskilliga gränssnitt, vilka gränssnitt alltid innefattar ett exempel på IUnknown. Ett klient- objekt kan fråga ett COM-objekt 5 av standardtyp om ett gränssnitt men för att kunna göra detta måste klient- objektet känna till identiteten på objektet (eller applikationen) för vilket det söker ett gränssnitt. Om objektet stöder gränssnittet returneras en hänvisning till gränssnittet såsom någon form av visare till det ställe där gränssnittet kan återfinnas.

COM är en publicerad standard och är som sådan en del av teknikens ståndpunkt.

Vid ett förfarande för integrering av en applikation i ett datoriserat system för styrning av ett verkligt objekt och ett system som använder nämnda förfarande enligt en ut- föringsform av föreliggande uppfinning, representerar ett sammansatt objekt varje verkligt objekt. Det verkliga A objektet kan vara ett verkligt objekt såsom en pump, en motor, en ventil osv, eller ett mer abstrakt objekt såsom en köporder, en produktionssats osv. Föreliggande upp- finning är inte begränsad till traditionella styrnings- eller processregleringsområden. Varje verkligt objekt kan innefattande representeras, såsom ett objekt i en process, en anordning eller process i t ex ett hus, eller en person som utför ett steg eller en roll i en process, eller icke påtagliga objekt såsom meddelanden, en plats, informa- tionsstatus osv.

Hänvisning till figur 2a, vilken visar ett sammansatt objekt 40 och några aspekter 41. Det sammansatta objektet 40 är en platshållare som innehåller olika aspekter l, 2, 19, 23 osv, relaterade till det verkliga objektet. En .-ø a 10 15 20 25 30 35 516 029 aspekt representerar en sida av det verkliga objektet och är ansvarig för alla operationer pá den sidan av det verkliga objektet och dess data. För t ex en pump skulle en aspekt sàlunda kunna representera en fysisk plats, en annan aspekt skulle kunna representera en planskiss över pumpen, en annan representerar en säkerhetsbeskrivning för pumpen, en annan aspekt representerar en styrning för drift av pumpen och ytterligare en annan aspekt represen- terar dokumentation om pumpen. Aspekten som representerar sidan i fråga har en anknytning till en funktion hos en applikation som, med hänvisning till exemplet ovan, kan visa planskissen eller styra driften av pumpen.

Sammansatta objekt och aspekter kommunicerar med varandra med användning av ett ”ramverk” baserat pà en Object Request Broker sàsom COM med tillägg definierade enligt föreliggande uppfinning. En uppsättning gränssnitt de- finieras för att göra det möjligt för aspekter att sam- verka med användning av standardtjänster. Varje enskild aspekt kan definiera ytterligare gränssnitt för att möjliggöra varje specifik interaktion som kan vara nöd- vändig inom en undergrupp av aspekter.

Vid en utföringsform av föreliggande uppfinning är vart och ett av de verkliga objekten som representeras i datorprogram som ett detta innehåller dator- att styra en dator att systemet representerat inom ett sammansatt objekt. För att göra programmet mjukvarukodmedel för utföra funktioner enligt en utföringsform av föreliggande uppfinning. Det sammansatta objektet innehàller en eller flera aspekter som representerar sidor av det verkliga objektet som det sammansatta objektet representerar. Dessa aspekter har också anknytningar till applikationer som àstadkommer funktionalitet som är förknippad med de res- pektive sidorna hos det verkliga objektet.

Alla aspekter skapas genom en aspektkategori (Aspect Category). Aspektkategorin innehåller information som delas av alla exempel av denna kategori. Varje aspekt- nuflfl" u anamn- 10 15 20 25 30 35 516 029 ll kategori hänvisar till en aspekttyp. Denna aspekttyp beskriver implementeringen av en aspekt.

En aspekt tillhör en aspekttyp (genom sin kategori) vilken innehåller en lista pà den uppsättning COM-objekt som implementerar aspektens funktionalitet. Denna imple- mentering tillhandahålls av ett objekt, kallat aspekt- (Aspect System Object, ASO), vilket är ett COM-anpassat objekt. Uttryckt på ett annorlunda sätt systemobjekt innehåller aspekttypen den bindande informationen mellan ett aspekt och den/de applikation(er) som implementerar dess funktionalitet.

Det sammansatta objektet kan få en fråga av en klient, genom en Object Request Broker såsom COM, att hitta en referens till ett gränssnitt hos den applikation som är förknippad med någon av dess aspekter.

En Object Request Broker såsom COM tillhandahåller en mekanism för att förmedla en referens till ett särskilt gränssnitt. Det av det sammansatta objektet och aspekterna tillhandahállna ”ramverket” åstadkommer medlen för att identifiera det särskilda gränssnitt som nämnda Object Request Broker därefter förmedlar.

Se figur 2b och 3. Figur 2b visar ett sammansatt objekt 6, en aspektkategori l9a som aspekt 6a tillhör, och en aspekttyp 8 för aspekten 6a enligt en utföringsform av uppfinningen. Aspekttypen 8 innehåller en förteckning över alla aspektsystemobjekt som används av denna aspekt, (CLSID) och en förteckning över alla gränssnittsidentifierare 7 (IID) såsom CLSID 9, identifierar en särskild applikation och uttryckt såsom klassidentifierare 9 för varje ASO för gränssnitt som stöds av varje ASO. En CLSID, associerar därmed en funktion av aspekten med den appli- kation som implementerar funktionen.

Figur 3 visar ett sammansatt objekt 10, vilket innefattar ett gränssnitt IUnknown 4a. Den visar även ett aspekt- 10 15 20 25"' 30 35 516 029 12 "-.-" systemobjekt 101, vilket innefattar ett annat gränssnitt IUnknown 4b. Figur 3 visar ocksa en fraga 13 om ett gräns- snitt och en referens 103 till ett gränssnitt 102. Av figur 3 framgar att när en klient frågar det sammansatta objektet 10 om ett gränssnitt kommer den referens 103 som returneras fràn aspektsystemobjektet 101. ASO:t 101 àter- finns genom att slà i en tabell med användning av aspekt- typen, sasom visas i figur 2b.

Resultatet av detta är att den klient som fràgar, t ex det sammansatta objektet 10, om en funktion förknippad med en av aspekterna av det sammansatta objektet 10 inte behöver känna till identiteten pà objektet (eller applikationen) för vilket (eller vilken) gränssnittet söks; klienten frågar helt enkelt det sammansatta objektet om den funktion som är förknippad med aspekten. Detta stàr i strid mot standardbruket av COM, vilket kräver att ett klientobjekt uttryckligen känner till identititeten pà objektet det söker ett gränssnitt. (eller applikationen) för vilket (eller vilken) Ett sammansatt objekt identifieras unikt genom dess objektidentifierare. En aspekt identifieras av objekt- identifieraren hos det sammansatta objekt som den är förknippad med, och en unik aspektidentifierare. Om ett objekt har en representation i olika system använder den samma objektidentifierare i alla system.

Att finna ett gränssnitt genom ett samansatt objekt enligt uppfinningen.

En klient till ett sammansatt objekt frågar objektet om ett gränssnitt. Det sammansatta objektet använder de definitioner som innesluts av aspekttypen hos det sammansatta objektets aspekter för att identifiera aspektsystemobjektet som implementerar det begärda gränssnittet. Detta ASO skapas och inititieras sedan fràn den aspekt det representerar eller, om den redan körs, som áterfunnits genom en mekanism att lokalisera objekt som 10 15 20 »25 30 35 516 029 13 u o u o o av körs. En referens till ett gränssnitt hos detta ASO returneras sedan till klienten.

Närhelst en klient interagerar med ett sammansatt objekt exemplifieras ett COM-objekt som representerar det samman- satta objektet.

Se figur 2b. Mekanismen för att finna det aspektsystem- objekt som implementerar ett gränssnitt av en aspekt beskrivs sålunda. När en klient frågar ett sammansatt objekt 6 om ett gränssnitt, undersöker det sammansatta inklusive aspekt 6a, objektet sina aspekter, genom aspekt- kategorin l9a, för en aspekttyp 8 som visar en ASO- beskrivning 8a som innehåller en gränssnittsidentifierare 7 hos det begärda gränssnittet. Från samma ASO-beskrivning 8a erhålls klassidentifieraren 9a hos det aspektsystem- objekt som implementerar gränssnittet.

Se figur 3 som illustrerar en begäran till ett sammansatt objekt om ett gränssnitt. Figur 3 visar ett sammansatt objekt 10 som erhåller en fråga 13 från en klient.

Aspekttypen 8 genomsöks, såsom visas i figur 2b, för att finna klassidentifieraren 9 till aspektsystemobjektet. Om aspektsystemobjektet 101 inte redan körs så skapas det såsom visas av process 14, initiering, i figur 3. Det exemplifierade aspektsystemobjektet 101 tillfrågas sedan genom gränssnittet IUnknown 4b om en referens till gräns- snittet 102, vilken referens 103 returneras till klienten.

Aspektsystemobjekt kan definieras att vara delade eller exklusiva. Detta specificerar att om en klient begär ett gränssnitt flera gånger för samma aspekt, får den samma gränssnittsreferens till objektet flera gånger. Om aspekt- systemobjektet är delat så skapas bara en gränssnitts- referens med en särskild aspektidentifierare i varje sammanhang (typiskt sett per process). 10 15 20 25 30 35 516 029 ø u n . nu Att lägga till objekt och funktioner enligt uppfinningen Den ovan beskrivna mekanismen gör det möjligt att utvidga funktionaliteten hos styrsystemet genom att lägga till aspekter till sammansatta objekt, där varje aspekt för med sig en bit funktionalitet. Den gör det också möjligt att modulisera implementeringen av det datoriserade systemet därför att varje aspekt är oberoende av alla andra aspekter utom genom de gränssnitt den understöder och utnyttjar.

Vid ett system som implementeras baserat pà principerna i denna uppfinning tillför en utvecklare funktionalitet genom att tillföra aspektsystem. Ett aspektsystem är en applikation som implementerar en eller flera aspekter, vilket gör det möjligt att skapa aspektexempel och tillfoga dem till sammansatta objekt. Aspektsystemet definierar (bland annat) vilka COM-objekt som används för att implementera aspekterna.

Det är också möjligt att tillföra funktionalitet till ett befintligt aspektsystem genom att tillföra nya ASOn till aspekttypen.

Föredragen utföringsform Vid en föredragen utföringsform av föreliggande uppfinning innefattas ett förfarande för att organisera sammansatta objekt efter ett eller flera förhållanden till den verkli- ga världen, vilket förfarande kallas strukturer. Alla sammansatta objekt i ett system kan anordnas i en eller flera strukturer.

Ett antal sammansatta objekt som representerar delar av ett fysiskt system kan exempelvis lämpligen grupperas som en struktur. Sammansatta objekt som representerar en sensor fastsatt vid ett blad till en omröringsanordning, skaftet till omröringsanordningen, en temperatursensor i 10 15 20 25 30 35 516 029 omröringsanordningen och en styrenhet för omröraren osv kan alla dessutom identifieras sàsom tillhörande en speciell omrörarstruktur (Agitator Structure). Strukturen själv representeras som en företeelse som är skild fràn de ingående sammansatta objekten. Varje nod i strukturen representeras av en strukturaspekt hos det sammansatta objektet som ”placeras” i denna nod.

Användningen av strukturer innebär att förhållanden mellan sammansatta objekt representeras av aspekter av de samman- satta objekten. Detta gör att ett sammansatt objekt kan representeras i ett flertal strukturer och till och med i ett flertal positioner inom en särskild struktur. Struk- turer gör det möjligt för sammansatta objekt att organi- seras och gör det möjligt att pà ett naturligt sätt definiera funktioner sàsom arv, sortering och gruppering.

Ett första objekt kan ärva genom en känd generell arvs- mekanism genom att definieras som ett barn till ett andra objekt. Barnet (det första objektet) aspekter fràn sitt föräldraobjekt (det andra objektet) som ärver sedan de markeras sàsom skall-ärvas.

Föreliggande uppfinning definierar en ytterligare och ny metod att ärva. Aspekter hänvisar till aspektkategorier och genom kategorier till aspekttyper. Aspeksystem, aspekttyper och aspektkategorier framställs alla sàsom sammansatta objekt. Genom att placera ytterligare aspekter i en aspektkategori och markera dessa aspekter sàsom skall-ärvas, ärvs dessa aspekter till alla sammansatta objekt till vilka varje aspekt av denna speciella aspektkategori tillförs.

Denna form av arv illustreras kortfattat i figur 4. Ett sammansatt objekt 18 är en platshàllare för en del aspekter, inklusive aspektl. Aspektl hänför sig till en aspektkategori 19. I aspektkategorin 19 markeras aspekt2 och aspekt4 sàsom skall-ärvas. Därför att det sammansatta objektet 18 innehåller minst en aspekt fràn aspektkate- ° " ' 222'- - ' ' 22"- 5 . o. .nu . v v' 15 "'"nz: ::=1' - 2 °"9 . u u .n n . u u o H 10 15 20 25 30 35 516 029 l 6 §f§§ïj . . . . n gorin 19, vilken i detta exempel är aspektl, kommer det sammansatta objektet 18 att ärva alla aspekter i kategori 19 som markeras skall-ärvas. Det sammansatta objektet 18 ärver således aspekt2 och aspekt4 automatiskt genom skall- ärva-indikatorn pà dessa aspekter i aspektkategorin 19.

Den ovan beskrivna mekanismen fungerar rekursivt.

Föreliggande uppfinning definierar också en annan ny metod att ärva, schematiskt visad i figur 5. En struktur 20 innefattar ett första sammansatt objekt 25 och tvä andra sammansatta objekt 26, 27 som är organiserade i samma struktur. De sammansatta objekten 26, 27 ärver automatiskt aspekt32 fràn det sammansatta objektet 25 därför att aspekt32 markeras skall-ärvas av sammansatta objekt när de organiseras underordnade i samma struktur. Denna organisa- tionsmetod inom strukturen kan baseras pà vilket förhàll- ande som helst, typiskt sett ett som àterspeglar en verklig funktion, och är inte begränsad till beskrivningar sàsom en klass i en hierarki. Markören för ”skall-ärvas- inom-samma-struktur” placeras i respektive aspekters aspektkategori.

Ett system som utnyttjar ett förfarande enligt före- liggande uppfinning kan också ta formen av ett distri- buerat system eftersom det är designat med användning av förfaranden som underlättar kommunikation mellan, och utförande av, applikationer som körs pà datorer i ett fördelat system. Ett fördelat system innebär här ett system som är spritt över ett flertal datorer, dator- system, datornätverk, intelligenta och icke-intelligenta anordningar som är anordnade med kommunikationsanordningar sà att varje del av systemet kan kommunicera med varje annan del.

Det ligger inom ramen för patentkraven i föreliggande uppfinning att inbegripa datoriserade system som inne- fattar alla kommunikationsmedel eller kombinationer därav, inklusive men inte begränsat till direkt fast kopplade 516 (129 17 länkar, nätverk, intranät, Internet, allmänna eller privata telefonlinjer, radiolänkar, infraröda länkar eller länkar som använder optiska fibrer.

Claims (42)

10 15 20 25 30 35 516 029 18 PATENTKRAV

1. Förfarande för integrering av en applikation i ett datoriserat system för styrning av ett verkligt objekt, vilket system innefattar ett mjukvarumedel (5) vilket framställer det verkliga objektet, en första referens till ett gränssnitt (1) förknippad med mjukvarumedlet, och en Object Request Broker som ger àtkomst till nämnda applikation genom ett gränssnitt (102), kännetecknat av att förfarandet innefattar följande steg: - att konfigurera nämnda mjukvarumedel som ett sammansatt objekt (40, 10, 6, 18, 25-27) Vilket innehåller en aspekt (41, 6a, l8a, 25a-27a) - att framställa en funktion av nämnda verkliga objekt som en aspekt (41, 6a, l8a, 25a-27a) av det sammansatta objektet (40, 10, 6, 18, 25-27) - att förknippa nämnda applikation med aspekten (41, 6a, l8a, 25a-27b) med hjälp av en andra referens (9) - att möjliggöra en fràga (13) med hjälp av den första (40, 10, 6, 18, 25-27) om funktionen förknippad med aspekten (41, 6a, l8a, 25a-27a) av det sammansatta objektet (40, 10, 6, 18, 25- 27). - att genom det sammansatta objektet (40, 10, 6, 18, 25- 27) (lO3) (102) hos nämnda applikation som implementerar funktionen. referensen till det sammansatta objektet fà en tredje referens till gränssnittet

2. Förfarande enligt patentkrav 1, kännetecknat av att det sammansatta objektet (40, 10, 6, 18, 25-27) tillhandahåller information om aspekten (41, 6a, l8a, 25a- 27a) som är förknippad med det sammansatta objektet (40, 10, 6, 18, 25-27).

3. Förfarande enligt patentkrav 1, kännetecknat av att det gränssnitt som blir åtkomligt genom nämnda Object Request Broker implementeras av ett aspektsystemobjekt (101).

4. Förfarande enligt patentkrav 1, kännetecknat av att aspekten (41, 6a, l8a, 25a-27a) tillhör en aspektkategori 10 15 20 25 30 35 É°:É'°',É:' :"::": 'É 19 E" FÉ Ü ÄÉ="=' ' l9a) som innehåller en referens till en aspekttyp i 8), vilken aspekttyp (8) innehåller en första referens 9) till ett aspektsystemobjekt (101).

5. Förfarande enligt patentkrav 1, kännatecknat av att den andra referensen (9) till aspektsystemobjektet (101) är en klassidentifierare.

6. Förfarande enligt patentkrav 3, kännetecknat av att aspektsystemobjektet (101) är anordnat att åstadkomma nämnda gränssnitt (102) vilket via nämnda Object Request Broker är ”in process", eller ”local” eller "remote".

7. Förfarande enligt patentkrav 1, kännetecknat av att nämnda Object Request Broker är anpassad till COM.

8. Förfarande enligt patentkrav 4, kännetecknat av att arv av aspekter beskrivs i aspektkategorin (19, l9a) till (41,6a, l8a, 25a-27a) hör. vilken aspekten

9. Förfarande enligt patentkrav 1, kännetecknat av att det 10, 6, 18, 25-27) är organiserat sammansatta objektet (40, i en struktur (20).

10. Förfarande enligt patentkrav 9, kännetecknat av att (40, 10, 6, 18, 25-27) är organiserat genom att placeras i mer än en position i det sammansatta objektet strukturen (20).

11. Förfarande enligt patentkrav 9, kännetecknat av att (40, 10, 6, 18, 25-27) är organiserat genom att placeras i mer än en struktur det sammansatta objektet (20).

12. Förfarande enligt patentkrav 9, kännetecknat av att aspekten (25a) av ett första sammansatt objekt (25) i en struktur (20), markerad sàsom ”skall-ärvas-inom-samma- struktur", ärvs av minst ett andra sammansatt objekt (26, 27) som organiseras underordnat i samma struktur (20). 10 15 20 25 30 35 516 029 2 0

13. Förfarande enligt patentkrav 1, kännetecknat av att minst en ytterligare funktion läggs till genom följande ytterligare steg: - att definiera ett ytterligare aspektsystem som inne- håller ett aspektsystemobjekt (101) - att beskriva en aspekttyp (8) som implementeras i det ytterligare aspektsystemet - att i aspekttypen (8) lista det aspektsystemobjekt (101) som blir åtkomligt genom nämnda Object Request Broker.

14. System för datoriserad styrning av ett verkligt objekt, vilket system inbegriper en applikation, ett mjukvarumedel (5) vilket framställer det verkliga objektet, förknippad med mjukvarumedlet, (1), och innefattar en Object en första referens till ett gränssnitt Request Broker som ger åtkomst till nämnda applikation genom ett gränssnitt (102), kännetecknat av att nämnda system innefattar ett med hjälp av mjukvarumedlet konfigurerat sammansatt objekt (40, 10, 6, 18, 25-27) som representerar nämnda verkliga objekt, en aspekt (41, 6a, 18a, 25a-27a) av det sammansatta objektet (40, 10, 6, 18, 25-27), som representerar en funktion av nämnda verkliga objekt och är förbunden med nämnda applikation med hjälp av en andra referens (9), där det sammansatta objektet (40, 10, 6, 18, (41, 18a, 25a-27a) och är anordnat att tillhandahålla en tredje referens (103) (102) 25-27) är en platshàllare för aspekten 6a, till nämnda gränssnitt hos nämnda applikation.

15. System enligt patentkrav 14, kännetecknat av att det sammansatta objektet (40, 10, 6, 18, 25-27) ger informa- tion om den aspekt (41, 6a, 18a, 25a-27a) som är förbunden med det sammansatta objektet (40, 10, 6, 18, 25-27).

16. System enligt patentkrav 14 eller 15, kännetecknat av att nämnda gränssnitt (102) som blir åtkomligt genom nämnda Object Request Broker implementeras av ett aspekt- systemobjekt (101). 10 15 20 25 30 35 516 029 21

17. System enligt patentkrav 14, kännetecknat av att den andra referensen (9) till aspektsystemobjektet (101) är en klassidentifierare.

18. System enligt patentkrav 14, kännetecknat av att (41, 6a, l8a, 25a-27a) l9a) som innehåller en referens till en aspekttyp aspekten tillhör en aspektkategori (19, (8), aspektsystemobjekt (101). vilken aspekttyp (8) innehåller en referens till ett

19. System enligt patentkrav 16, kännetecknat av att (101) är anordnat att tillhandahålla (102) vilket via nämnda Object Request aspektsystemobjektet nämnda gränssnitt Broker är ”in process” eller ”local” eller "remote".

20. System enligt patentkrav 14, kännetecknat av att nämnda Object Request Broker är anpassad till COM.

21. System enligt patentkrav 14, kännetecknat av att arv av aspekter beskrivs i en aspektkategori (19, l9a) till vilken aspekten (41,6a, l8a, 25a-27a) hör.

22. System enligt patentkrav 14, kännetecknat av att det sammansatta objektet (40, 10, 6, 18, 25-27) är organiserat i en struktur (20).

23. System enligt patentkrav 22, kännetecknat av att det (40, 10, 6, 18, 25-27) genom att placeras i mer än en position i strukturen (20). sammansatta objektet är organiserat

24. System enligt patentkrav 22, kännetecknat av att det sammansatta objektet (40, 10, 6, 18, 25-27) genom att placeras i mer än en struktur (20). är organiserat

25. System enligt patentkrav 22, kännetecknat av att (25a) (25) (20), markerad såsom ”skall-ärvas-inom-samma- struktur", ärvs av minst ett andra sammansatt objekt (26, aspekten av ett första sammansatt objekt i en struktur 27) som organiseras underordnat i samma struktur (20). o u o o o nu 10 15 20 25 30 35 516 029 ÉHÛH:Üf:* 22 ?.U.. ašaj.

26. System enligt patentkrav 14, kännetecknat av att minst en ytterligare funktion kan läggas till innefattande - ett ytterligare aspektsystem som innehåller ett eller (101) - en eller flera aspekttyper som implementeras i det flera aspektsystemobjekt ytterligare aspektsystemet - en förteckning i varje aspekttyp (8) av ett eller flera (101) nämnda Object Request Broker. aspektsystemobjekt som kan bli åtkomligt genom

27. En datorprogramprodukt innehållande mjukvarukodmedel som kan laddas in i internminnet hos en dator i ett datoriserat system, kännetecknad av att nämnda dator- programprodukt har medel för att få nämnda dator att: tillhandahålla ett sammansatt objekt (40, 10, 6, 18, 27) sagda sammansatta objekt är kapabel att framställa en första (1), 25- som kan representera ett verkligt objekt, referens till ett gränssnitt vilket sammansatt objekt (40, 10, 6, 18, 25-27) är en platshållare för en aspekt (41, 6a, 18a, 25a-27a), (41, 18a, 25a-27a) är kapabel att representera en funktion av det verkliga objektet, där aspekten (41, 18a, 25a-27a) är förbunden med en applikation med hjälp av en andra åstadkomma att aspekten 6a, 6a, referens (9), samt att på begäran återlämna en tredje referens (103) applikationen, vilket gränssnitt (102) blir åtkomligt till ett gränssnitt (102) hos genom en Object Request Broker.

28. En datorprogramprodukt enligt patentkrav 27, kännetecknad av att det sammansatta objektet (40, 10, 6, 18, 25-27) tillhandahåller information om aspekten (41, 6a, 18a, 25a-27a) som är förknippad med det sammansatta objektet (40, 10, 6, 18, 25-27).

29. En datorprogramprodukt enligt patentkrav 27, kännetecknad av att det gränssnitt (102) ligt genom nämnda Object Request Broker implementeras av (101). som blir åtkom- ett aspektsystemobjekt 10 15 20 25 30 35 516 029 2 ggsw-.s :wa -a oo o o oc: o o oooo ooo o ooo oo o oo oo o o oo oo I o o o oo o oo o o o o oo n o o o o o oo oo o o o o oo v oo

30. En datorprogramprodukt enligt patentkrav 27, kännetecknad av att varje aspekt (41, 6a, 18a, 25a-27a) tillhör en aspektkategori (19, l9a) som innehåller en referens till en aspekttyp (8), vilken aspekttyp (8) innehåller en första referens (9) till ett aspektsystem- objekt (101).

31. En datorprogramprodukt enligt patentkrav 27, kännetecknad av att den andra referensen (9) till aspektsystemobjektet (101) är en klassidentifierare.

32. En datorprogramprodukt enligt patentkrav 29, kännetecknad av att aspektsystemobjektet (101) är anordnat att åstadkomma nämnda gränssnitt (102) vilket via nämnda Object Request Broker är ”in process", eller "local" eller "remote".

33. En datorprogramprodukt enligt patentkrav 27, kännetecknad av att nämnda Object Request Broker är anpassad till COM.

34. En datorprogramprodukt enligt patentkrav 30, kännetecknad av att arv av aspekter beskrivs i en aspektkategori (19, 19a).

35. En datorprogramprodukt enligt patentkrav 27, kännetecknad av att det sammansatta objektet (40, 10, 6, 18, 25-27) är organiserat i en struktur (20).

36. En datorprogramprodukt enligt patentkrav 35, kännetecknad av att det sammansatta objektet (40, 10, 6, 18, 25-27) är organiserat genom att placeras i mer än en position i en struktur (20).

37. En datorprogramprodukt enligt patentkrav 35, kännetecknad av att det sammansatta objektet (40, 10, 6, 18, 25-27) är organiserat genom att placeras i mer än en struktur (20). 10 15 20 25 30 35 516 Û29 ïï?%5{¶¶_§' 24 - n.2: .u

38. En datorprogramprodukt enligt patentkrav 35, (25a) sammansatt objekt (25) i en struktur (20), markerad såsom kännetacknad av att aspekten av ett första ”skall-ärvas-inom-samma-struktur", ärvs av minst ett andra sammansatt objekt (26, 27) som organiseras underordnat i samma struktur (20).

39. En datorprogramprodukt enligt patentkrav 27, kännetecknad av att den har medel för att: - tillhandahålla minst ett ytterligare aspektsystem innehållande ett eller flera aspektsystemobjekt (101) - tillhandahålla en eller flera aspekttyper (8) som implementeras i det ytterligare aspektsystemet - tillhandahålla en förteckning i varje aspekttyp (8) över ett eller flera aspektsystemobjekt (101) vilka kan fås tillgång till genom nämnda Object Request Broker.

40. En datorprogramprodukt enligt patentkrav 27 innehållet på ett datorläsbart medium.

41. Användning av ett system enligt patentkrav 14 för att styra ett Verkligt objekt lokaliserat på en industriell eller kommersiell plats, en bostad eller ett hus.

42. Användning av en datorprogramprodukt enligt patentkrav 27 för att styra ett verkligt objekt lokaliserat på en industriell eller kommersiell plats, en bostad eller ett hus. u macro: