Objektorientētā koncepcija jeb objektorientētā konceptuālā pamatsistēma (object oriented approach)

Veidošanās pirmsākumi saistīti ar:1) jaunas programmēšanas pieejas realizēšanu valodā Simula1 (1960. g., Norvēģijas Skaitļošanas Centrs);2) pirmās objektorientētās programmēšanas valodas Smalltalk2 (1970. g., Alan Kay) izstrādi.

Objektorientētā koncepcija novirzīja uzmanību no koda uz datiem. Tā pasauli interpretē kā objektu (dati kopā ar metodēm) kopu un to mijiedarbību.

1 Kristen Nygaard, Ole-Johan Dahl. The Development of SIMULA Language. ACM SIGPLAN Notices, Vol. 13, No. 8, August 1978, p. 245 – 272.2 Kay, Allen. "The Early History of Smalltalk". gagne.homedns.org. Retrieved 22 Januar 2016.

1

Objektu – orientētās tehnoloģijas svarīgākie koncepti3

1. Klases, metaklases, parametrizētās klases (parameterized classes).

2. Abstrakcijas izmantošana – maznozīmīgākā ierobežošana, būtiskā

akcentēšana.

3. Objekts.

4. Iekapsulēšana – datu un metožu apvienošana.

5. Mantošana – objektu līdzības modelēšana.

6. Polimorfisms – vienādu metožu dažādas izpildes iespējas.

7. Melnās kastes un interfeisi.

8. Agregācija.

19. Metodes.

10. Objektu sakabe (coupling) un vienotība (cohesion).

3 http://www.ipipan.gda.pl/~marek/objects/TOA/oobasics/oobasics.html

2

Objektorientētās koncepcijas izmantošana

Tā tiek izmantota:1) objektorientētajā programmēšanā (object-oriented programming);2) objektu modelēšanas tehnikā (Object Modelling Techniques (OMT), 1991., James Rumbaugh) objektorientētās programmēšanas atbalstam4;3) objektorientētajā projektēšanā (object-oriented development 1980. g., Grady Booch5);4) objektorientētajā programmatūras tehnoloģijā (object-oriented software engineering (1992., Ivar Jacobson6);5) objektorientētajā analīzē7 (object-oriented analysis 1997.);6) objektorientētajās datu bāzēs8 (object-oriented databases 1985.);7) objektu-relāciju datu bāzēs9 10 (object-relational databases 1990.);8) objektorientētais lietotāju interfeiss (object - oriented user interface (OOUI)).

4 James Rumbaugh, Michael Blaha, William Premerlani, Frederick Eddy, William Lorensen (1990). Object-Oriented Modeling and Design. Prentice Hall. ISBN 0-13-629841-95 G. Booch, "Object Oriented Design," Ada Letters, Vol. I, No. 3, March- April 1982, pp. 64 - 76.6 Ivar Jacobson, Magnus Christerson, Patrik Jonsson, Gunnar Övergaard:Object-oriented software engineering - a use case driven approach. Addison-Wesley 1992, ISBN 978-0-201-54435-0, pp. I-XX, 1-5247 Martin Fowler. Analysis Patterns: Reusable Object Models. Addison-Wesley, 1997. [An introduction to object-oriented analysis with conceptual models]8 D. Maier, A. Otis, and A. Purdy, "Object-Oriented Database Development at Servio Logic," Database Engineering, vol. 18, no.4, December 1985.9 Stonebraker, M.; Rowe, L. A. (1986). "The design of POSTGRES". ACM SIGMOD Record 15 (2): 340.10 Stonebraker,. Michael with Moore, Dorothy. Object-Relational DBMSs: The Next Great Wave. Morgan Kaufmann Publishers, 1996. ISBN 1-55860-397-2.

3

Objektorientētās tehnoloģijas pamatterminiObjektorientētā tehnoloģija ir noteikts uztveres un domāšanas modelis (paradigma), kurā

1) dati un darbības tiek apvienoti kopējās struktūrās;2) datiem ir primāra loma.

Šo modeli reprezentē klases (DB objekta tipi) un objekti.

Klase ir objekta tipa apraksts, kas ietver sevī iekšējo mainīgo deklarēšanu un iekšējo metožu aprakstu.

Objekts ir datu un to apstrādes metožu kopums, kas izveidots saskaņā ar aprakstu, kuru definē klase. Objekts ir klases instance jeb eksemplārs.

Objekta tips ir iepriekš definēts salikts datu tips, kas ietver datu struktūru un metodes (kuras manipulē ar datiem) (firma Oracle).

Instance jeb eksemplārs ir objekta realizācija. Formāli "instance" ir "objekta" sinonīms.

Objektorientētā programmēšana:

klase (dati + metodes)

Datu bāze:

objekta tips (dati + metodes)

Objekts, instance, eksemplārs

4

Objekts

Termins objekts parasti apzīmē kaut ko vienotu un veselu, kas veidojas no atsevišķām sastāvdaļām. Datorzinātnē terminu “objekts” lieto lai norādītu:1) atsevišķo sastāvdaļu vienotību (att. a);

2) datu un to apstrādes programmu (metožu) vienotību (att. b).

a) objekts b) objekts Dati (objekta

stāvoklis)

Datu apstrādes metodes

1.sastāvdaļa

2.sastāvdaļa

3.sastāvdaļa

5

Objekta sastāvdaļas

Objektam ir:1) apraksts – objekta tipa definējums;2) objekta realizācijas – eksemplāri

(instances).

Katram objektam ir:1) unikāls identifikators (object identifier – OID), kas norāda, ka realitāte, kas tiek iekļauta DB ir viennozīmīgi identificējama;2) stāvoklis (state) – vērtību kopa, ko tas satur. Vērtības attēlo realitātes īpašības, iekļaujot faktus par saitēm ar citām realitātēm;3) uzvedība (behaviour) – darbību kopa, kas var tikt realizēta objektam. Tā

raksturo realitātes izmantošanas iespējas (pieļaujamās darbības vai metodes);

4) nosaukums, kurš ietver sevī zināmas asociācijas un atvieglo objektu lietotājam uz to atsaukties.

Objektus izmanto, lai ar to palīdzību attēlotu gan reālās pasaules realitātes (skolotāji, skolēni, …), kas eksistē ārpus DB, gan arī realitātes, kas eksistē tikai objektu DB (vērtības, notikumi, …). Ir objekti, kuru stāvokli (vērtības) var mainīt – mainīgie (mutable) objekti un objekti, kuru vērtības vienmēr paliks nemainīgas.

Objekta stāvokļa datu un to apstrādes metožu apvienojumu sauc par iekapsulēšanu (encapsulation). Dati tiek iekļauti datu bāzē, aprakstot gan to struktūru, gan pieejamās darbības ar tiem. Tas nosaka, ka lietojums ar datiem varēs izpildīt tikai tās darbības, kas ir definētas datu bāzē (metodes).

6

Objektu hierarhija

Set - nesakārtota elementu kolekcija, bez dublikātiem.

Bag – nesakārtota elementu kolekcija ar dublikātiem.

List – sakārtota elementu virkne.

7

Objekts kā maza DB sistēma

Objekta uzvedību nosaka definētās pieļaujamās darbības vai metodes. Tās ierobežo saskarni ar objektu. Ir divas darbību grupas:1) izmaiņu operācijas, kas maina objektu stāvokli (atribūtu vērtības);2) meklēšanas operācijas, kas meklē objektu ar noteiktām īpašībām vai vienkārši nosaka objekta pašreizējo stāvokli.Objekta stāvokli veido vērtības:1) kas attēlo faktus, kuri ir saistīti ar attiecīgo realitāti. Šīs vērtības sauc par

objekta atribūtiem.2) kas norāda saites ar citām realitātēm (viņu reprezentējošiem objektiem).

Šīs vērtības sauc par saitēm.Viens vai vairāki atribūti var būt definēti kā objekta atslēga. Tā vērtībai (vai vērtību kombinācijai) ir jābūt unikālai. Katrai saitei ir divi aprakstošie nosaukumi pirmais ir ceļam no dotā objekta uz saistīto objektu, otrais – atpakaļceļam no saistītā objekta uz doto.

Objekta datuapstrādes procedūra

Objekta datuapstrādes procedūra

Objekta stāvoklis (atribūti un sasaistes)

Fiziskā glabātuve

8

Objektu tipi un realizācijasObjekta tipa definējums nosaka, kā attiecīgā tipa objekts (eksemplārs) ir lietojams, bet nepasaka, kā tas tiek realizēts (implemented). Tips norāda tikai saskarni (interfeisu) ar objektu. Tips var tikt realizēts daudzos veidos. Konkrētu realizāciju sauc par implementācijas klasi vai vienkārši klasi.

Objekta tipam ir:1) specifikācijas vai apraksta daļa (atribūtu definējumi, metožu interfeisu,

izsaukumu definējumi);2) ķermenis, kuru veido metožu programmu teksti.

Objekts Saskarne (interfeiss)

Realizācija

Stāvokļa vērtības

9

Klase un objekta eksemplārsThere are two broad categories of objects: classes and instances.

1. Klase ir veidne ar ko tiek izveidotas objekta realizācijas (reāli objekti). 2. Klase ir objektu realizācijas fabrika. Tā satur objektu veidni un objektu izveidošanas mehānismu. 3. Klase ir visu notektas veidnes objektu realizāciju kopa.

We should note that it is possible for an instance of a class to also be a class. A metaclass is a class whose instances themselves are classes. This means when we use the instance creation mechanism in a metaclass, the instance created will itself be a class. The instance creation mechanism of this class can, in turn, be used to create instances -- although these instances may or may not themselves be classes.

A concept very similar to the metaclass is the parameterized class. A parameterized class is a template for a class wherein specific items have been identified as being required to create non-parameterized classes based on the template. In effect, a parameterized class can be viewed as a "fill in the blanks" version of a class. One cannot directly use the instance creation mechanism of a parameterized class. First, we must supply the required parameters, resulting in the creation of a non-parameterized class. Once we have a non-parameterized class, we can use its creation mechanisms to create instances.

10

Objekti kā melnās kastes un to interfeisi Objects are "black boxes." Specifically, the underlying implementations of objects are hidden from those that use the object. In object-oriented systems, it is only the producer (creator, designer, or builder) of an object that knows the details about the internal construction of that object. The consumers (users) of an object are denied knowledge of the inner workings of the object, and must deal with an object via one of its three distinct interfaces:1) the "public" interface. This is the interface that is open (visible) to everybody.2) the "inheritance" interface. This is the interface that is accessible only by direct specializations of the object. In class-based object-oriented systems, only classes can provide an inheritance interface.3) the "parameter" interface. In the case of parameterized classes, the

parameter interface defines the parameters that must be supplied to create an instance of the parameterized class.

Another way of saying that an item is in the public interface of an object is to say that the object "exports" that item. Similarly, when an object requires information from outside of itself (e.g., as with the parameters in a parameterized class), we can say that the object needs to "import" that information.

11

Objekta realizācijas piemērs

SKOLNIEKS

SKOL_ID = 1VAR = “Rasma”UZV= “Egle”DZIM = “meitene”PERS_KODS = “010881-11265”ADRESE = “Ventspils, Brīvības-34/98”TELEFONS = 3687967KLASE = 10

uzvārda_maiņa (…)adreses_maiņa (…)telefona_maiņa (…)klases_maiņa (…)

Atribūti

Pieļaujamās darbības

12

Objektu – orientētās tehnoloģijas svarīgākie koncepti11

1. Objekts.

2. Klases, metaklases, parametrizētās klases (parameterized classes).

3. Melnās kastes un interfeisi.

4. Agregācija.

5. Specializācija un mantošana.

6. Abstrakta klase.

7. Metodes.

8. Konstantes.

9. Izņēmumi un to situācijas.

10. Objektu sakabe (coupling) un vienotība (cohesion).

11. Objektu sistēmas.

11 http://www.ipipan.gda.pl/~marek/objects/TOA/oobasics/oobasics.html

13

Asociācija12, atkarība, agregācija, kompozīcija

Asociācija norāda, ka eksistē semantiskas (strukturālas) saites starp noteiktu objektu tipu atsevišķiem objektiem.Viena objektu tipa eksemplārs (objekts) izmanto cita objektu tipa eksemplāru (objektu) vai abi izmanto viens otru. Objektu tipi ir neatkarīgi viens no otra, un nav nekādu īpašuma tiesību starp tiem. Asociācijas eksemplārs ir saite. Tā savieno sakārtotu objektu sarakstu, kur katrs objekts ir piederīgs attiecīgajam objekta tipam. Divus objektus savieno bināra saite. Var būt saite starp vienas klases objektiem un objektam var būt saite pašam ar sevi.Tiek lietotas gan vienvirziena (uni-derectional) asociācijas (Jacobson, Booch, Rumbaugh), gan divvirzienu asociācijas (Shlaer, Mellor, Booch, Rumbaugh).Rumbaugh un Odell ieviesa atvasinātās (derived, computed) asociācijas. Tās formulē, kā vienas asociācijas var tikt veidotas uz citu bāzes.Rumbaug un Shlaer/Mellor lieto asociāciju klases. Tās ļauj asociācijās izmantot atribūtus operācijas.Link (saite) – asociācijas eksemplārs.Katra asociācijas saite ar klasi tiek saukta par asociācijas polu. Poliem ir nosaukumi (lomu nosaukumi), redzamības (visibility) norāde (public, protected, private) un iespējamo saišu skaita diapazona norāde (multiplicity). Grafiski asociācija tiek attēlota kā nepērtraukta līnija starp klasēm. Asociācijai ir nosaukums. Ja asociācijai ir savi atribūti, tā ir objektu tips un tiek saukta par asociācija-objektu tips.

loma-apmāca loma-mācās

1 asociācija mācības 0..N

12 http://www.uml-diagrams.org/association.html?context=class-diagrams

fakultāte students

14

Atkarība (dependency) ir saites veids, kas nosaka, ka viena tipa objektu eksemplāriem ir nepieciešama saikne ar otra tipa objektu eksemplāriem, lai veiktu savas funkcijas. Atkarību veidi var būt ļoti dažādi: eksemplāra izveidošanas iespēja, dažādu semantisko līmeņu hierarhijas eksemplāru attiecība, konkretizācijas iespējas.

Agregācija ir „veselais - daļa” vai „daļa no” attiecība, kurā objektu eksemplāri, kuri ir kaut kā daļas, ir asociēti ar objektu eksemplāru, kas ir šo daļu konteiners.

Kompozīcija (composition) ir agregācijas speciāls gadījums, kas raksturojas ar to, ka agregāta sastāvdaļas, sauktas arī par komponentēm, ir neatņemamas šī agregāta daļas, kas “dzīvo un iet bojā” reizē ar pašu agregātu.

Terminu "asociācija" izmanto divējādi:

1) kā vispārīgu saites nosaukumu objektorientētajās datu bāzēs;

2) kā speciālu saites veidu objektorientētajās datu bāzēs.

tramvaja vadītājs

tramvajs

kurpe kurpes šņore

cilvēks galva

15

Problēma: agregācijas un kompozīcijas attiecības (???):1) agregācija kompozīcija;2) kompozīcija agregācija;3) agregācija vai kompozīcija.

16

Kompozīcija un agregācija

Kompozīcija un agregācija ir cieša savienojuma (tightly coupled) saites.

Kompozīcija (vārda plašā nozīmē)

Neatkarīgas eksistences (existence independent) (agregācija)

Atkarīgas eksistences (existence dependent) (kompozīcija)

Ekskluzīva (exclusive, non sharable)

Neekskluzīva (nonexclusive, sharable)

Veselais DaļaDaļa

?

17

Agregācija (aggregation) un agregāta tipa objektsIt is possible for objects to be composed of other objects. Aggregation is either:1) the process of creating a new object from two or more other objects;2) or an object that is composed of two or more other objects.

A monolithic object is an object that has no externally-discernible structure. A monolithic object does not appear to have been constructed from two or more other objects. Specifically, a monolithic object can only be treated as a cohesive whole.

18

Kompozīcija (composite) un kompozīcijas tipa objektsComposite objects are objects that have an externally-discernible (ārēji atšķirama) structure, and the structure can be addressed via the public interface of the composite object. The objects that comprise a composite object are referred to as component objects. Composite objects meet one or both of the following criteria:1) the state of a composite object is directly affected by the presence or absence of one or more of its component objects, and/or2) the component objects can be directly referenced via the public interface of their corresponding composite object.

It is useful to divide composite objects into two subcategories: 1) a heterogeneous composite object is a composite object that is

conceptually composed of component objects that are not all conceptually the same.

2)a homogeneous composite object is a composite object that is conceptually composed of component objects that are all conceptually the same.

The rules for designing heterogeneous composite objects are different from the rules for designing homogeneous composite objects. The composition hierarchy may span an arbitrary number of levels. If one gets a composite or aggregated object design that has component objects that are themselves composite or aggregated objects, then one gets a two-level aggregation or composition hierarchy. This hierarchy could be repeated to several levels of composition or aggregation. Because of the arbitrary number of the part-of relationships between the objects, the objects involved in the composition are also known as complex objects.

19

Katalogs

Teksta fails Binārais fails

Ekskluzīva un neekskluzīva kompozīcija

Ekskluzīva (nonsharable) kompozīcija

1 1 1

Neekskluzīva (sharable) kompozīcija

1... 1... 1...

Dators

Centrālais procesors Cietais disks

20

Kompozīcijas tipi

1. Ekskluzīva (nonsharable, exclusive) un eksistences atkarīga (existence dependent) kompozīcija.

2. Neekskluzīva (sharable) un eksistences neatkarīga (existence independent) kompozīcija;

3. Nekskluzīva (sharable, nonexclusive) eksitences atkarīga (existence dependent) kompozīcija.

4. Ekskluzīva (nonsharable) un eksistences neatkarīga (existence independent) kompozīcija.

in UML: Composition = exclusive, dependent

21

Heterogēnas, homogēnas un daudzlīmeņu kompozīcijasA heterogeneous composition since one whole object may consist of several different types of part objects.

A homogeneous composition implies that one whole object consists of part objects of the same type.

The composition hierarchy may span an arbitrary number of levels. If one gets a composite or aggregated object design that has component objects that are themselves composite or aggregated objects, then one gets a two-level aggregation or composition hierarchy. This hierarchy could be repeated to several levels of composition or aggregation. Because of the arbitrary number of the part-of relationships between the objects, the objects involved in the composition are also known as complex objects.

22

Mantošana (lietojot terminu "klase")Mantošana (inheritance) ir objektorientētās tehnoloģijas mehānisms, kad klase pārņem (manto) elementus (laukus un metodes) no jau eksistējošas klases vai vairākām klasēm.

Klases, no kurām mantošanas rezultatā tiek iegūti elementi, sauc par bāzes klasēm (baseclass).

Klasi, kura tiek veidota, izmantojot mantošanu sauc par atvasināto (derived) klasi vai mantoto (inherited) klasi.

23

Mantošana (lietojot terminu "tips datu bāzē)Mantošana – ir saite (asociācija) starp virstipa objektu un vienu vai

vairākiem apakštipa (-u) objektiem. Mantošana var būt organizēta

divos virzienos:

1) vispārinājums - vispārinot kopīgos aspektus eksistējošajos

objektos un iekļaujot tos virsklases objektos (direction bottom-

top);

2) specializācija – izdalot objektu specifiskos aspektus un

iekļaujot tos vienā vai vairākos apakšklases objektos.

Cilvēks

Students Pasniedzējs

Cilvēks

Students Pasniedzējs

24

Specialization and generalization Aggregation is not the only way in which two objects can be related. One object can be a specialization of another object. Specialization is either:1) the process of defining a new object based on a (typically) more narrow definition of an existing object, or2) an object that is directly related to, and more narrowly defined than, another object.

Specialization is usually associated with classes. It is usually only in the so-called "classless" object-oriented systems that we think of specialization for objects other than classes.

It is common to say that everything that is true for a generalization is also true for its corresponding specialization. We can, for example, define "checking accounts" and "savings accounts" as specializations of "bank accounts." Another way of saying this is that a checking account is a kind of bank account, and a savings account is a kind of bank account. Still another way of expressing this idea is to say that everything that was true for the bank account is also true for the savings account and the checking account.

25

Inheritance (mantošana)

In an object-oriented context, we speak of specializations as "inheriting" characteristics from their corresponding generalizations. Inheritance can be defined as the process whereby one object acquires (gets, receives) characteristics from one or more other objects. Some object-oriented systems permit only single inheritance, a situation in which a specialization may only acquire characteristics from a single generalization.

Many object-oriented systems, however, allow for multiple inheritance, a situation in which a specialization may acquire characteristics from two or more corresponding generalizations.

26

Abstract Classes We usually think of classes as being complete definitions. However, there are situations where incomplete definitions are useful, and classes that represent these incomplete definitions are equally useful. For example, in everyday conversation, we might talk about such items as bank accounts, insurance policies, and houses. In object-oriented thinking, we often isolate useful, but incomplete, concepts such as these into their own special classes.

Abstract classes are classes that embody coherent and cohesive, but incomplete, concepts, and in turn, make these characteristics available to their specializations via inheritance. People sometimes use the terms "partial type" and "abstract superclass" as synonyms for abstract class. While we would never create instances of abstract classes, we most certainly would make their individual characteristics available to more specialized classes via inheritance.For example, consider the concept of an automobile. On one hand, most people know what an automobile is. On the other hand, "automobile" is not a complete definition for any vehicle. It would be quite accurate to describe "automobile" as the set of characteristics that make a thing an automobile, in other words, the "essence of automobile-ness."

27

Virsklase, bāzes klase

Virsklase, bāzes klase

Pakārtotā klase

Mantošanas pamattipi1. Vienkāršā (single) mantošana (viens virstips).

2. Saliktā, daudzkārtējā, atkārtotā (multiple, repeated) mantošana

(vairāki virstipi).

3. Daudzlīmeņu (multilevel) mantošana.

Virsklase

StarpklasePakārtotā klaseVirsklase

Pakārtotā klase

Pakārtotā klase, apakšklase, pakārtotais tips, apakštips

Virsklase, bāzes klase, virstips

28

4. Hierarhiskā (hierarhical) mantošana (virsklase vairākām apakšklasēm).

5. Saliktā ceļa (multipath) mantošana.

6. Hibrīda tipa (hybrid = single + multiple)) mantošana.

Virsklase, bāzes klase

Pakārtotā klase

Virsklase

Pakārtotā klase

Virsklase, bāzes klase

Virsklase

Pakārtotā klase

Virsklase

Pakārtotā klase

Virsklase

Pakārtotā klase

Virsklase

Pakārtotā klase

Pakārtotā klase

Pakārtotā klase

29

Bāzes klase

V

Apakšklase Apakšklase

Bāzes klase

S

Apakšklase Apakšklase

Mantošanas interpretējumi

Vispārinājums ("is a"). Apakšklase manto bāzes klases atribūtus un saites.

Specializācija ("is a"). Bāzes klasei pievienojasapakšklases atribūti un saites.

30

Absolūtā specializācija (total specialization) – katram bāzes klases eksemplāram ir vismaz viens apakšklases eksemplārs.

Daļējā specializācija (partial specialization) – ne katram bāzes klases eksemplāram ir atbilstošs pakārtototās klases eksemplārs.

Grāmata

AS

Dzejoļu grāmata

Romāns Cits tips

Grāmata

DS

Dzejoļu grāmata

Romāns

31

Dzīvnieks

SA

Lauva Zirgs Suns

1

Darbinieks

StrādnieksVadītājs

Sadalījuma specializācija (disjoint inheritance) – katram bāzes klases eksemplāram var būt ne vairāk kā viens atbilstošais elements no apakšklasēm.

Savstarpēji izslēdzošā (mutual – exclusion) mantošanā:1) apakšklašu objekti nevar vienlaicīgi piederēt vairākiem bāzes klases

objektiem;2) galvenās klases objekts var nepiederēt nevienai no apakšklasēm.

32

Pārklāšanās tipa mantošana (overlapping inheritance) – katram bāzes klases eksemplāram var atbilst vairāku apakšklašu eksemplāri.

Sadalīšanas (partition) mantošanā apakšklašu grupas veido savstarpēji izslēdzošas grupas.

Upe

P

Liela Maza Strauja

N

Gadījuma strādnieks

Darbinieks

VadītājsStrādnieks

33

Apvienojošā (union) mantošanā:1) katrs galvenās klases objekts obligāti pieder kādai no

apakšklasēm;2) galvenās klases objekts var piederēt vairākām apakšklasēm

vienlaicīgi. Attēlā ir parādīts apvienojošās mantošanas piemērs, kurā katrs augu kaitēklis pieder vismaz pie vienas no apakšklasēm – pie bumbieru kaitēkļiem vai ķiršu kaitēkļiem, turklāt kaitēklis var vienlaicīgi būt bumbieru kaitēklis un ķiršu kaitēklis.

Vairākkārtējā mantošana (multiple inheritance) – apakšklases eksemplāri ir saistīti ar vairākām bāzes klasēm.

Dzīvnieks Cilvēks

Nāra

Bāzes klases

Apakšklase

DM

34

Persona

PasniedzējsStudents

Apvienojošās (union) mantošanas divi varianti

Bāzes tipa objektu apvienojošā mantošana:1) apakštipa objekts ir saistīts ar vairākiem bāzes tipa objektiem;2) apakštipa objekts vienlaikus manto atribūtus un metodes tikai no viena

bāzes tipa objekta.

Pakārtoto objektu apvienojošā (union) mantošanā:1) katrs bāzes tipa objekts ir obligāti saistīts ar kāda apakštipa objektu;2) galvenā tipa objekts var būt saistīts ar vairākiem apakštipu objektiem (apakštipa objekts var būt arī cita apakštipa objekts (students var būt arī pasniedzējs)).

Pirkums

AP

Produkts Pakalpojums

Apakštipa objekts

Bāzes tipa objekts

XOR

35

Persona

PasniedzējsStudents

Relāciju – objektu datu bāzes (RODB) datu glabāšanas struktūru mantošanas saites

Apvienojošā mantošanaApvienojošā (union) mantošanā:1) katrs galvenās klases objekts ir obligāti saistīts ar kādas apakšklases objektu;2) galvenās klases objekts var būt saistīts ar vairākiem apakšklases objektiem (apakšklases objekts var būt arī citas apakšklases objekts (students var būt arī pasniedzējs)).

If we use the Oracle version, which supports inheritance using the “under” keyword, we can create Student and Staff subclasses under the superclass Person. Note that for union inheritance, we need to create one table each for the superclass and all the subclasses.Using the “under” keyword, normally we do not need to create separate tables for the subclasses because the table created for the superclass can also be used to store the instances of the subclasses. However, in this union type of inheritance, we need to allow a particular person to be both a student as well as a staff. If we are to store all instances into one superclass table, we will not be able to store the two records together as they will violate the primary-key constraints (i.e., two records with the same ID). Therefore, we need to create a separate table for each of the subclasses to allow the same person’s record to appear in both the Student as well as Staff tables. We also need to create a table for Person to store persons who are neither staff members nor students.

CREATE OR REPLACE TYPE Person_T AS OBJECT (id VARCHAR2(10),name VARCHAR2(20),address VARCHAR2(35)) NOT FINAL; CREATE TABLE Person OF Person_T (id NOT NULL, PRIMARY KEY (id)); CREATE OR REPLACE TYPE Student_T UNDER Person_T (course VARCHAR2(10), year VARCHAR2(4));

CREATE TABLE Student OF Student_T (id NOT NULL, PRIMARY KEY (id));

CREATE OR REPLACE TYPE Staff_T UNDER Person_T (department VARCHAR2(10), room_no VARCHAR2(4));

CREATE TABLE Staff OF Staff_T (id NOT NULL, PRIMARY KEY (id));

36

Darbinieks

StrādnieksVadītājs

Savstarpēji izslēdzošā mantošanaSavstarpēji izslēdzošā (mutual – exclusion) mantošanā:1) apakšklašu objekti nav saistīti (darbinieks ir tikai vai nu vadītājs vai strādnieks, ne abi divi).2) galvenās klases objekts var būt nesaistīts ar kādu apakšklases objektu.

Using the newer Oracle version, we can create Manager and Worker subclasses under the superclass Employee. Notice that in this type of inheritance, we create only one table for the superclass. We do not need subclass tables because an object can be a member of only one subclass. These subclasses are instantiations of the superclass. Also notice that although the table is created from the superclass table, Oracle maintains the integrity constraint between the subclass and the superclass table. We cannot delete the subclass while the superclass table still exists. In this case, an employee can only be a manager, a worker, or neither. If an employee is neither a manager nor a worker, he or she is only an object of the superclass, Employee. If an employee is a manager, for example, he or she will be an object of the subclass Manager. Thus, the employee will have all of the attributes of the Manager type and all other attributes that are inherited from the Employee type. However, all of the subclass tables can be kept in the superclass table.CREATE OR REPLACE TYPE Employee_T AS OBJECT (id VARCHAR2(10), name VARCHAR2(20), address VARCHAR2(35), emp_type VARCHAR2(8)) NOT FINAL;

CREATE TABLE Employee OF Employee_T (id NOT NULL,emp_type CHECK (emp_type in (‘Manager’, ‘Worker’, ‘NULL’)), PRIMARY KEY (id));

CREATE OR REPLACE TYPE Manager_T UNDER Employee_T (annual_salary NUMBER);

CREATE OR REPLACE TYPE Worker_T UNDER Employee_T (weekly_wage NUMBER);

37

Gadījuma strādnieks

Darbinieks

StrādnieksVadītājs

Nodalīšanas mantošanaNodalīšanas (partition) mantošana ir apvienojošās un savstarpēji izslēdzošās mantošanas apvienojums:1) apakšklašu grupas veido savstarpēji izslēdzošas grupas;2)

We use the example of an employee again, but here a new class, Casual, is added, and it is assumed that each member of the Employee class must belong to one and only one of the classes Manager, Worker, and Casual. For example, an employee cannot be both a manager and a casual. Similar to the other types of inheritance, the best way to map the partition type of inheritance into tables is to have one table for each superclass and one for each subclass. Like the mutual-exclusion type, a new attribute emp_type is added to the superclass table. The difference is that this new attribute has a constraint, which is “not null.” This will ensure that each superclass object belongs to a particular subclass type. It also ensures that no superclass object belongs to more than one subclass. Notice that the attribute emp_type is also needed in the Employee table with the “not null” constraint. The newer Oracle version can also accommodate this inheritance type. It is very similar to the implementation in the mutual-exclusion type. The only difference is the constraint of emp_type in the Employee table.

CREATE OR REPLACE TYPE Employee_T AS OBJECT (id VARCHAR2(10), name VARCHAR2(20), address VARCHAR2(35), emp_type VARCHAR2(8)) NOT FINAL; CREATE TABLE Employee OF Employee_T (id NOT NULL, emp_type NOT NULL CHECK (emp_type in (‘Manager’, ‘Worker’, ‘Casual’)), PRIMARY KEY (id));

CREATE TYPE Manager_T same as in mutual exclusive inheritance

CREATE TYPE Worker_T same as in mutual exclusive inheritance

CREATE OR REPLACE TYPE Casual_T UNDER Employee_T (hourly_rate NUMBER);

38

Privātskolotājs

Persona

PasniedzējsStudents

Daudzkārtējā (multiple) mantošanaDaudzkārtējā (multiple) matošana:1) vienas apakšklases objektus manto vairākas galvenās klases.

A Tutor class can be said to be inheriting from overlapping classes because basically a tutor can be a student who is also a staff member. The best way to handle this inheritance from overlapping classes is to use one table for each superclass and one table for the subclass. Figure gives an example of a multiple inheritance implementation. A Tutor class can be said to be inheriting from overlapping classes Student and Staff.At the time of this writing, the newer Oracle does not support multiple inheritance using the “under” keyword. This keyword is applicable only to the single inheritance type. However, this multiple inheritance concept is often simulated using other existing techniques. For example, we can use the “under” keyword to implement one inherited parent, and use an association type to link to the other parent. The drawback of using this technique is that only the parent type implemented using “under” can be inherited, and therefore we have to be careful when choosing which parent to inherit and which one to associate.

CREATE TABLE Person (id VARCHAR2(10) NOT NULL, name VARCHAR2(20), address VARCHAR2(35), PRIMARY KEY (id));

CREATE TABLE Student (id VARCHAR2(10) NOT NULL, course VARCHAR2(10), year VARCHAR2(4), PRIMARY KEY (id), FOREIGN KEY (id) REFERENCES Person (id) ON DELETE CASCADE); CREATE TABLE Staff (id VARCHAR2(10) NOT NULL, department VARCHAR2(10), room_no VARCHAR2(4), PRIMARY KEY (id), FOREIGN KEY (id) REFERENCES Person (id) ON DELETE CASCADE);

CREATE TABLE Tutor (id VARCHAR2(10) NOT NULL, no_hours NUMBER, rate NUMBER, PRIMARY KEY (id), FOREIGN KEY (id) REFERENCES Person (id) ON DELETE CASCADE);

39

Relāciju – objektu datu bāzes (RODB) datu glabāšanas struktūru agregācijas un kompozīcijas saites1. Agregācijas saiteAgregācijas saite norāda, ka objekts ir salikts (complex object). Tātad eksistē veselais un daļas. Agregācijas saite norāda sekojošu attiecību starp vesalo objektu un daļu objektiem:1) daļas objekts pieder tikai vienam veselajam objektam (exclusive) vai vairākiem (nonexclusive);2) ja tiek likvidēts veselais objekts, daļas objekti paliek (neatkarīgā esamība (existence independent)).

EER diagramma

RORB datu glabāšanas struktūra (exclusive variants)

objektu saite

1 : 1

RORB datu glabāšanas struktūra (nonexclusive variants)

objektu saite

N : 1

FakultāteAtr1Atr2Atr3

PasniedzējsAtr4Atr5Atr6

Tabula ar rindas tipa objektiem ar atsaucēm (Ref) Objekts (OID, Atr4, Atr5, Atr6, Ref)

Tabula ar rindas tipa objektiemObjekts (OID, Atr1, Atr2, Atr3)

Tabula ar kolekciju. Kolekcijas veido atsauces Ref. Kolonas: Atr4, Atr5, Atr6, AtsaucesKolonu Atsauces veido objektu kolekcijas ar atsaucēm.

Tabula ar rindas tipa objektiemObjekts (OID, Atr1, Atr2, Atr3)

40

2. Kompozīcija (salikti objekti (complex objects))Kompozīcijas saite norāda sekojošu attiecību starp vesalo objektu (saliktu objektu) un daļu objektiem:1) daļas objekts pieder tikai vienam veselajam objektam vai vairākiem (exclusive, nonexclusive);2) ja tiek likvidēts veselais objekts, tiek likvidēti arī daļas objekti (atkarīgā esamība (existence dependent)).

EER diagramma

RORB datu glabāšanas struktūra (exclusive variants)

RORB datu glabāšanas struktūra (nonexclusive variants)

objektu saite

N : 1

A heterogeneous composition since one whole object may consist of several different types of part objects.

A homogeneous composition implies that one whole object consists of part objects of the same type.

DzīviklisAtr1Atr2Atr3

IstabaAtr4Atr5Atr6

Tabula ar objektu kolekcijuKolonas: Atr1, Atr2, Atr3, ISTABAKolona ISTABA satur objekta (Atr4, Atr5, Atr6) objekta kolekcijas

Tabula ar rindas tipa objektiemObjekts (OID, Atr1, Atr2, Atr3).Trigeris daļveida objektu dzēšanai, ja tiek dzēsts veselais objekts.

Tabula ar kolekciju. Kolekcijas veido atsauces Ref. Kolonas: Atr4, Atr5, Atr6, AtsaucesKolonu Atsauces veido objektu kolekcijas ar atsaucēm.

41

Ģeometriskā objekta

pamatdati

Punkta koordinātes Triplets (grafiskā

primitīva apraksts)

Salikta grafiskā objekta apraksts

Salikta grafiskā objekta

koordinātes

Grafiskā primitīva objekta

koordinātes

Grafiskās datu bāzes datu glabāšanas struktūra izmantojot SDO_GEOMETRY objekta tipuĢeometrijas objektu glabāšanas RODB tabula (tabula ar objektu kolonu)

Objekta tipa SDO_GEOMETRY datu EER diagramma

42

SDO_GEMETRYETRY

SDO_GEMETRYETRY

SDO_GTYPE

SDO_SRID

SDO_POINT

SDO_ELEM_INFO--------------------------------------SDO_STARTING_OFFSET

SDO_ETYPESDO_INTERPRETATION

SDO_ORDINATES----------------------X1,Y1,X2,Y2, ...

Atr Atr AtrAtr

Atr

Atr

Atr Atr AtrAtr Atr Atr

Atr Atr Atr

Objektu tipa SDO_GEOMERTY struktūra

AtrAtr

43

Operations

The public interface of an object typically contains three different categories of items:1) operations (sometimes referred to as "method selectors," "method interfaces," "messages," or "methods");2) constants;3) exceptions.

An operation in the public interface of an object advertises a functional capability of that object. For example, "deposit" would be an operation in the public interface of a bank account object, "what is current temperature" would be an operation in the public interface of a temperature sensor object, and "increment" would be an operation in the public interface of a counter object.The actual algorithm for accomplishing an operation is referred to as a method. Unlike operations, methods are not in the public interface for an object. Rather, methods are hidden on the inside of an object. So, while users of bank account objects would know that they could make a deposit into a bank account, they would be unaware of the details as to how that deposit actually got credited to the bank account.We refer to the operations in the public interface of an object as "suffered operations."

44

Suffered operationsSuffered operations are operations that meet two criteria: 1) they are things that happen to an object;2) they are in the public interface of that object. For example, we can say that a bank account "suffers" the operation of having a deposit made into it. The bank account can also "suffer" the operation of being queried as to its current balance. Some people also refer to suffered operations as "exported operations."There are three broad categories of suffered operations, i.e.:1) a selector is an operation that tells us something about the state of an object, but cannot, by definition, change the state of the object. An operation that tells us the current balance of a bank account is an example of a selector operation.2) a constructor is an operation that has the ability to change the state of an object. For example, an operation in the public interface to a mailbox object that added a message to the mailbox would be a constructor operation. (Please note that some people restrict the definition of the term "constructor" to those operations that cause instances of a class to come into existence.)3) in the context of a homogeneous composite object, an iterator is an operation that allows its users to visit (access) each of the component objects that make up the homogeneous composite object. If we have a list of addresses, for example, and we wish to print the entire list, an iterator would allow us to visit each address object within the list and then, in turn, to print each address. Iterators can be further divided into two broad categories: 1) active (open) iterators. Active iterators are objects in their own right. Passive iterators are implemented as operations in the interface of the object over which they allow iteration.2) passive (closed) iterators. Passive iterators are further broken down into selective iterators and constructive iterators. Passive selective iterators do not allow their users to change the object over which the iteration takes place. Passive constructive iterators do allow users to change the object over which iteration takes place.

45

Suffered operations are:1) primitive operation is an operation that cannot be accomplished simply, efficiently, and reliably without direct knowledge of the underlying (hidden) implementation of the object. As an example, we could argue that an operation that added an item to a list object, or an operation that deleted an item from a list object were primitive operations with respect to the list object.2) a composite operation is any operation that is composed, or can be composed, of two or more primitive operations. Suppose that we wanted to create a "swap operation," an operation that would swap in a new item in a list, while at the same time swapping out an old item in the same list. This is not a primitive operation since we can accomplish this with a simple combination of the delete operation (deleting the old item) followed by the add operation (adding the new item). The swap operation is an example of a composite operation. Sometimes objects need help in maintaining their characteristics. Suppose, for example, that we wanted to create a "generic ordered list" object. An ordered list is a list that must order its contents from the smallest to the largest. Specifically, every time we add an item to our ordered list, that item would have to be placed in its proper position with respect to all the other items already in the list. By "generic," we mean a template that can be instantiated with the category (class) of items we wish to place in the ordered list.It would not be unreasonable to implement this object as a parameterized class. Obviously, one of the parameters would be the category of items (e.g., class) that we desired to place in the list. For example, could instantiate (make an instance) the generic ordered list with a "name class" resulting in the creation of an "ordered list of names class."There is a problem, however. Given that we could instantiate the generic ordered list with just about any category of items, how can we be sure that the ordered lists will know how to properly maintain order -- no matter what we use to instantiate the generic ordered list? Suppose, for example, that we wanted an ordered list of "fazoomas." How could the generic list class tell if one fazooma was greater than or less than another fazooma?A solution would be for the generic ordered list to require a second parameter, a parameter over and above the category of items (class) that we

46

desired to place in the list. This second parameter would be a "<" (less than) operation that worked with the category of items to be placed in the list. In the case of our ordered list of fazoomas, this second parameter would be a "<" that works with fazoomas.The "<" that worked with fazoomas is an example of a required operation. A required operation is an operation that an object needs to maintain its outwardly observable characteristics, but which the object cannot supply itself. Some people refer to required operations as "imported operations."

47

Constants In addition to suffered operations, the public interface of an object can also contain constants. Constants are objects of constant state. Imagine that we want to create a "bounded list of addresses class." A bounded list is a list that has a fixed maximum number of elements. A bounded list can be empty, and it can contain fewer than the maximum number of elements. It can even contain the maximum number of elements, but it can never contain more than the defined maximum number of elements.Assume that we place a constant in the public interface of our bounded list of addresses. This constant represents the maximum number of elements that can be placed in the bounded list. Assume also that there is a suffered operation that will tell us how many elements (addresses, in our example) are currently in the bounded list. We can now determine how much room is available in the bounded list by inquiring how many addresses are already in the list, and then subtracting this from the previously-defined constant.In some cases, as with the bounded list example above, constants are provided more for convenience than necessity. In other cases, such as in the case of encryption algorithms needing a "seed value," constants are an absolute requirement.

48

Exceptions A third category of items that can be found in the public interface of objects is exceptions. Exceptions have two different definitions:1) an event that causes suspension of normal application execution;2) a set of information directly relating to the event that caused suspension of normal application execution. Exceptions can be contrasted with an older, less reliable technology: "error codes." The idea behind error codes was fairly simple. You would request that an application, or part of an application, accomplish some work. One of the pieces of information that would be returned to the requester would be an error code. If all had gone well, the error code would typically have a value of zero. If any problems had occurred, the error code would have a non-zero value. It was also quite common to associate different non-zero values of an error code with specific errors.Error codes suffered from two major problems: No one was forced to actually check the value of returned error codes. Changes (additions, deletions, and modifications) in the meanings of the special values assigned to error codes were not automatically passed on to interested parties. Tracking the effects of a changed error code value often consumed a significant amount of resources. To understand how exceptions directly address both of these issues, we first need to understand how exceptions typically work: Exceptions may be defined by the environment or by the user. When an exceptional (but not unforeseen) condition occurs, an appropriate exception is activated. (People use different terms to express the activation of an exception. The most common is "raise." Less commonly, people use the terms "throw" or "activate.") This activation may be automatic (controlled by the environment) or may be expressly requested by the designer of the object or application. Examples of exceptional conditions include trying to remove something from an empty container, directing an elevator on the top floor to "go up," and attempting to cause a date to take on an invalid value like "February 31, 1993." Once the exception is activated, normal application execution stops and control is transferred to a locally defined exception handler, if one is present.

49

If no locally defined exception handler is present or if the exception handler is not equipped to handle the exception, the exception is propagated to the next higher level of the application. Exceptions cannot be ignored. An exception will continue to be sent to higher levels of the application until it is either turned off or the application ceases to function. An exception handler checks to see what type of exception has been activated. If the exception is one that the handler recognizes, a specific set of actions is taken. Executing a set of actions in response to an exception is known as "handling the exception." Handling an exception deactivates the exception; the exception will not be propagated any further. Unlike error codes, exceptions cannot be ignored. Once an exception has been activated, it demands attention. In object-oriented systems, exceptions are placed in the public interfaces of objects. Changes in the public interfaces of objects very often require an automatic rechecking of all other objects that invoke operations in the changed objects. Thus, changes in exceptions result in at least a partially automated propagation of change information.

50

Object coupling Engineers have known for centuries that the less any one part of a system knows about any other part of that same system, the better the overall system. Systems whose components are highly independent of each other are easier to fix and enhance than systems where there are strong interdependencies among some or all of the components. Highly independent system components are possible when there is minimal coupling among the components, and each component is highly cohesive.Coupling (saistība) is a measure of the strength of the connection between any two system components. The more any one component knows about another component, the tighter (worse) the coupling is between those two components. Cohesion is a measure of how logically related the parts of an individual component are to each other, and to the overall component. The more logically related the parts of a component are to each other the higher (better) the cohesion of that component.

The objects that make up an object-oriented system exhibit object coupling and object cohesion. Object coupling describes the degree of interrelationships among the objects that make up a system. The more any one object knows about any other object in the system, the tighter (worse) the coupling is between those two objects.To construct systems from objects, we must couple (to some degree) the objects that comprise the system. This is necessary object coupling. However, if in the design of an individual object, we give that object direct knowledge of other specific objects, we are unnecessarily coupling the objects. Unnecessary object coupling reduces both the reusability of individual objects, and the reliability of the systems that contain unnecessarily coupled objects.

51

Object cohesionObject cohesion (vienotība), on the other hand, is a measure of how logically related the components of the external view of an object are to each other. For example, if we are told that a date object is comprised of a month object, a day object, a year object, and the color blue, we should recognize that the color blue is not appropriate, and lowers the cohesion of the date object. We want our objects to be as cohesive as possible for two reasons. First, objects with low cohesion are more likely to be changed, and are more likely to have undesirable side effects when they are changed. Second, objects with low cohesion are seldom easily reusable.

52

Systems of objects In constructing object-oriented models and object-oriented applications, one quickly finds that single classes and single instances are not enough. You need some way of creating and dealing with large objects. A system of objects is defined as two or more interacting or interrelated, non-nested objects. (We exclude simple aggregations of composite objects from our definition of systems of objects.)Systems of objects fall into two general categories:1) kits (komplekts), which are collections of items (classes, metaclasses, parameterized classes, non-class instances, other kits, and/or systems of interacting objects) all of which support a single, large, coherent, object-oriented concept, such as computer graphics windows or insurance policies. There may indeed be some physical connection among some of the members of a given kit. However, kits are "granular." While all the components of a kit are logically related, there are very few physical connections that bind them together.2) systems of interacting objects, which are collections of items (classes, metaclasses, parameterized classes, non-class instances, kits, and/or other systems of interacting objects) all of which support a single, large, coherent, object-oriented concept, and in which there must be a direct or indirect physical connection between any two arbitrary objects within the collection. Further, systems of interacting objects have at least one internal, independently executing thread of control. Lastly, systems of interacting objects may exhibit multiple, completely disjoint public interfaces. Kits resemble libraries. Say, for example, that we had to create a computer application with a graphical user interface. Graphical user interfaces normally contain several different types of windows. It would be very useful if we had a library of windows and window components from which we could construct any window we desired. Windows are objects, and the components of windows (buttons and check boxes) are themselves objects. A collection of windows and window components can be viewed as a kit.Systems of interacting objects, on the other hand, resemble applications. For example, suppose that we wanted to construct an object-oriented application that controlled the elevators in a particular building. We would assemble elevators, buttons, lamps, panels, and other objects into a working application

53

that would control the elevators. Such an application would not be viewed as a library, but as a highly cohesive whole. The elevator controller application is a system of interacting objects.

54

Objektu orientētās tehnoloģijas iezīmes1. Lietotāja definēti tipi.2. Iekļauti objekti.3. Konteineri: kolekcijas (sets), saraksti (lists), multi-kolekcijas (bags) ... 4. Metodes.5. Likumi.6. Stingra tipu saglabāšana interfeisos (strong typing across interface).

Relational databases don’t normally let you define your own data types (although some authors, most notably [date95], argue that this is a deficiency of current implementations and not a prescription of the relational model).

Object databases, instead, let you define arbitrarily complex, data types like their programming language counterparts, possibly nested in is-a and/or has-a hierarchies.

Sets, lists, bags (i.e. multisets) and other containers are used, among other things, to represent the result of a query which returns several objects.

A method is a piece of code associated with an object that has privileged access to the object’s state. Checking whether an object has or doesn’t have a property which is “derived” from its state may sometimes be done more efficiently by invoking a specially written method than by running a query on the attributes.

Stored procedures (stored in the database, that is) which can be executed on the server side were for certain aspects a precursor of this idea.

“Rules” is a generic name for code that is automatically activated when certain events occur. A form of constraint programming.

Finally, one of the most important features of object databases is that the commonality between the application’s and the database’s type systems preserves the strong typing in the communication between the two.

55

Objektu orientētās tehnoloģijas priekšrocības

1) rich type system;2) better at modelling complex objects;3) better performance on certain data structures;4) no impedance mismatch.

Objektu orientētās tehnoloģijas trūkumi

1)procedural navigation;2) querying breaks encapsulation (or is limited);3) what about closure?4) no mathematical foundation.

Object systems introduce pointers linking objects to each other. This in turn promotes a procedural style of navigation among the data items that can be seen as a step backwards from the higher-level declarative approach introduced by relational systems.

While encapsulation (the idea that an object’s internal state is only accessible through its designated methods) is a valuable modular technique, it presents problems with queries. Even if the Employee class has an extensive set of methods for hire_employee, change_salary, fire_employee etc., I might still not be able to answer a simple question like “who is the manager of this employee?” unless an appropriate method has been written. There is a tradeoff between giving up encapsulation (by exposing all of the object’s state through methods or by allowing queries to violate encapsulation under certain circumstances) and severely restricting the class of possible queries.

Closure of the relational algebra (the property that operators take relations as their arguments and give out relations as their results, thus allowing nested queries) is an important property that is normally lost in object systems.

Finally, but perhaps most importantly, object databases do not rest on a formal mathematical base like their relational predecessors. A powerful instrument of analysis, deduction and insight is lost.

56

An object oriented conceptual model An Object Oriented Conceptual Model (OOCM) encapsulates such aspects of objects:

1) static. The static aspects consist of the classes and objects, and the relationships between them, namely, inheritance, association, and aggregation. Each of these relationships is associated with a set of constraints.

2) dynamic. The dynamic aspect is divided into two types of methods: generic and user defined. Dynamic aspects can be called implementation or behavioural aspects. The specified routines are the only operations that can be carried out on the attributes in the object. Routines form the interface between the state of an object and the user.

- generic methods are used to access attributes of an object. The concept behind the need for generic methods is encapsulation, in which attributes associated with an object can be accessed directly only by the methods of the object itself.- user - defined methods are nongeneric methods that are defined by users in order to perform certain database functionality.

The object-oriented method promised to improve software quality and efficiency. One of the most enticing promises is that of real reusability: reusability of codes, program portions, designs, formal specifications, and also commercial packages. The main idea of the object-oriented method is that it provides a more natural way to model many real-world situations. The model obtained by the object oriented method will be a more direct representation of the situations, providing a better framework for understanding and manipulating the complex relationships that may exist.

57

In the object-oriented method, we also recognize the concept of encapsulation. An object is simply an encapsulation of data and their operations.

Objects are the basic run-time entities in an object-oriented system. An object can be created only during run time.

A class has three aspects: 1) the type as attributes and applicable routines;2) a container of objects of the same type;3) an instantiation mechanism, such as to create.

Association refers to a connection between object instances. Association is basically a reference from one object to another that provides access paths among objects in a system.

58

Operations

The public interface of an object typically contains three different categories of items:1) operations (sometimes referred to as "method selectors," "method interfaces," "messages," or "methods");2) constants;3) exceptions.

An operation in the public interface of an object advertises a functional capability of that object. For example, "deposit" would be an operation in the public interface of a bank account object, "what is current temperature" would be an operation in the public interface of a temperature sensor object, and "increment" would be an operation in the public interface of a counter object.The actual algorithm for accomplishing an operation is referred to as a method. Unlike operations, methods are not in the public interface for an object. Rather, methods are hidden on the inside of an object. So, while users of bank account objects would know that they could make a deposit into a bank account, they would be unaware of the details as to how that deposit actually got credited to the bank account.We refer to the operations in the public interface of an object as "suffered operations."

59

Suffered operationsSuffered operations are operations that meet two criteria: 1) they are things that happen to an object;2) they are in the public interface of that object. For example, we can say that a bank account "suffers" the operation of having a deposit made into it. The bank account can also "suffer" the operation of being queried as to its current balance. Some people also refer to suffered operations as "exported operations."There are three broad categories of suffered operations, i.e.:1) a selector is an operation that tells us something about the state of an object, but cannot, by definition, change the state of the object. An operation that tells us the current balance of a bank account is an example of a selector operation.2) a constructor is an operation that has the ability to change the state of an object. For example, an operation in the public interface to a mailbox object that added a message to the mailbox would be a constructor operation. (Please note that some people restrict the definition of the term "constructor" to those operations that cause instances of a class to come into existence.)3) in the context of a homogeneous composite object, an iterator is an operation that allows its users to visit (access) each of the component objects that make up the homogeneous composite object. If we have a list of addresses, for example, and we wish to print the entire list, an iterator would allow us to visit each address object within the list and then, in turn, to print each address. Iterators can be further divided into two broad categories: 1) active (open) iterators. Active iterators are objects in their own right. Passive iterators are implemented as operations in the interface of the object over which they allow iteration.2) passive (closed) iterators. Passive iterators are further broken down into selective iterators and constructive iterators. Passive selective iterators do not allow their users to change the object over which the iteration takes place. Passive constructive iterators do allow users to change the object over which iteration takes place.

60

Suffered operations are:1) primitive operation is an operation that cannot be accomplished simply, efficiently, and reliably without direct knowledge of the underlying (hidden) implementation of the object. As an example, we could argue that an operation that added an item to a list object, or an operation that deleted an item from a list object were primitive operations with respect to the list object.2) a composite operation is any operation that is composed, or can be composed, of two or more primitive operations. Suppose that we wanted to create a "swap operation," an operation that would swap in a new item in a list, while at the same time swapping out an old item in the same list. This is not a primitive operation since we can accomplish this with a simple combination of the delete operation (deleting the old item) followed by the add operation (adding the new item). The swap operation is an example of a composite operation. Sometimes objects need help in maintaining their characteristics. Suppose, for example, that we wanted to create a "generic ordered list" object. An ordered list is a list that must order its contents from the smallest to the largest. Specifically, every time we add an item to our ordered list, that item would have to be placed in its proper position with respect to all the other items already in the list. By "generic," we mean a template that can be instantiated with the category (class) of items we wish to place in the ordered list.It would not be unreasonable to implement this object as a parameterized class. Obviously, one of the parameters would be the category of items (e.g., class) that we desired to place in the list. For example, could instantiate (make an instance) the generic ordered list with a "name class" resulting in the creation of an "ordered list of names class."There is a problem, however. Given that we could instantiate the generic ordered list with just about any category of items, how can we be sure that the ordered lists will know how to properly maintain order -- no matter what we use to instantiate the generic ordered list? Suppose, for example, that we wanted an ordered list of "fazoomas." How could the generic list class tell if one fazooma was greater than or less than another fazooma?A solution would be for the generic ordered list to require a second parameter, a parameter over and above the category of items (class) that we

61

desired to place in the list. This second parameter would be a "<" (less than) operation that worked with the category of items to be placed in the list. In the case of our ordered list of fazoomas, this second parameter would be a "<" that works with fazoomas.The "<" that worked with fazoomas is an example of a required operation. A required operation is an operation that an object needs to maintain its outwardly observable characteristics, but which the object cannot supply itself. Some people refer to required operations as "imported operations."

62

Constants In addition to suffered operations, the public interface of an object can also contain constants. Constants are objects of constant state. Imagine that we want to create a "bounded list of addresses class." A bounded list is a list that has a fixed maximum number of elements. A bounded list can be empty, and it can contain fewer than the maximum number of elements. It can even contain the maximum number of elements, but it can never contain more than the defined maximum number of elements.Assume that we place a constant in the public interface of our bounded list of addresses. This constant represents the maximum number of elements that can be placed in the bounded list. Assume also that there is a suffered operation that will tell us how many elements (addresses, in our example) are currently in the bounded list. We can now determine how much room is available in the bounded list by inquiring how many addresses are already in the list, and then subtracting this from the previously-defined constant.In some cases, as with the bounded list example above, constants are provided more for convenience than necessity. In other cases, such as in the case of encryption algorithms needing a "seed value," constants are an absolute requirement.

63

Exceptions A third category of items that can be found in the public interface of objects is exceptions. Exceptions have two different definitions:1) an event that causes suspension of normal application execution;2) a set of information directly relating to the event that caused suspension of normal application execution. Exceptions can be contrasted with an older, less reliable technology: "error codes." The idea behind error codes was fairly simple. You would request that an application, or part of an application, accomplish some work. One of the pieces of information that would be returned to the requester would be an error code. If all had gone well, the error code would typically have a value of zero. If any problems had occurred, the error code would have a non-zero value. It was also quite common to associate different non-zero values of an error code with specific errors.Error codes suffered from two major problems: No one was forced to actually check the value of returned error codes. Changes (additions, deletions, and modifications) in the meanings of the special values assigned to error codes were not automatically passed on to interested parties. Tracking the effects of a changed error code value often consumed a significant amount of resources. To understand how exceptions directly address both of these issues, we first need to understand how exceptions typically work: Exceptions may be defined by the environment or by the user. When an exceptional (but not unforeseen) condition occurs, an appropriate exception is activated. (People use different terms to express the activation of an exception. The most common is "raise." Less commonly, people use the terms "throw" or "activate.") This activation may be automatic (controlled by the environment) or may be expressly requested by the designer of the object or application. Examples of exceptional conditions include trying to remove something from an empty container, directing an elevator on the top floor to "go up," and attempting to cause a date to take on an invalid value like "February 31, 1993." Once the exception is activated, normal application execution stops and control is transferred to a locally defined exception handler, if one is present.

64

If no locally defined exception handler is present or if the exception handler is not equipped to handle the exception, the exception is propagated to the next higher level of the application. Exceptions cannot be ignored. An exception will continue to be sent to higher levels of the application until it is either turned off or the application ceases to function. An exception handler checks to see what type of exception has been activated. If the exception is one that the handler recognizes, a specific set of actions is taken. Executing a set of actions in response to an exception is known as "handling the exception." Handling an exception deactivates the exception; the exception will not be propagated any further. Unlike error codes, exceptions cannot be ignored. Once an exception has been activated, it demands attention. In object-oriented systems, exceptions are placed in the public interfaces of objects. Changes in the public interfaces of objects very often require an automatic rechecking of all other objects that invoke operations in the changed objects. Thus, changes in exceptions result in at least a partially automated propagation of change information.

65

Object coupling Engineers have known for centuries that the less any one part of a system knows about any other part of that same system, the better the overall system. Systems whose components are highly independent of each other are easier to fix and enhance than systems where there are strong interdependencies among some or all of the components. Highly independent system components are possible when there is minimal coupling among the components, and each component is highly cohesive.Coupling (saistība) is a measure of the strength of the connection between any two system components. The more any one component knows about another component, the tighter (worse) the coupling is between those two components. Cohesion is a measure of how logically related the parts of an individual component are to each other, and to the overall component. The more logically related the parts of a component are to each other the higher (better) the cohesion of that component.

The objects that make up an object-oriented system exhibit object coupling and object cohesion. Object coupling describes the degree of interrelationships among the objects that make up a system. The more any one object knows about any other object in the system, the tighter (worse) the coupling is between those two objects.To construct systems from objects, we must couple (to some degree) the objects that comprise the system. This is necessary object coupling. However, if in the design of an individual object, we give that object direct knowledge of other specific objects, we are unnecessarily coupling the objects. Unnecessary object coupling reduces both the reusability of individual objects, and the reliability of the systems that contain unnecessarily coupled objects.

66

Object cohesionObject cohesion (vienotība), on the other hand, is a measure of how logically related the components of the external view of an object are to each other. For example, if we are told that a date object is comprised of a month object, a day object, a year object, and the color blue, we should recognize that the color blue is not appropriate, and lowers the cohesion of the date object. We want our objects to be as cohesive as possible for two reasons. First, objects with low cohesion are more likely to be changed, and are more likely to have undesirable side effects when they are changed. Second, objects with low cohesion are seldom easily reusable.

67

Systems of objects In constructing object-oriented models and object-oriented applications, one quickly finds that single classes and single instances are not enough. You need some way of creating and dealing with large objects. A system of objects is defined as two or more interacting or interrelated, non-nested objects. (We exclude simple aggregations of composite objects from our definition of systems of objects.)Systems of objects fall into two general categories:1) kits (komplekts), which are collections of items (classes, metaclasses, parameterized classes, non-class instances, other kits, and/or systems of interacting objects) all of which support a single, large, coherent, object-oriented concept, such as computer graphics windows or insurance policies. There may indeed be some physical connection among some of the members of a given kit. However, kits are "granular." While all the components of a kit are logically related, there are very few physical connections that bind them together.2) systems of interacting objects, which are collections of items (classes, metaclasses, parameterized classes, non-class instances, kits, and/or other systems of interacting objects) all of which support a single, large, coherent, object-oriented concept, and in which there must be a direct or indirect physical connection between any two arbitrary objects within the collection. Further, systems of interacting objects have at least one internal, independently executing thread of control. Lastly, systems of interacting objects may exhibit multiple, completely disjoint public interfaces. Kits resemble libraries. Say, for example, that we had to create a computer application with a graphical user interface. Graphical user interfaces normally contain several different types of windows. It would be very useful if we had a library of windows and window components from which we could construct any window we desired. Windows are objects, and the components of windows (buttons and check boxes) are themselves objects. A collection of windows and window components can be viewed as a kit.Systems of interacting objects, on the other hand, resemble applications. For example, suppose that we wanted to construct an object-oriented application that controlled the elevators in a particular building. We would assemble elevators, buttons, lamps, panels, and other objects into a working application

68

that would control the elevators. Such an application would not be viewed as a library, but as a highly cohesive whole. The elevator controller application is a system of interacting objects.

69