��������� ���� �

��������������

��������������������������

��������� ���� �

���������������������������� ������� Nos anos 80 proliferam os SGBD relacionais na micro-informática.� O modelo relacional aplica-se muito bem a aplicações de informatização

tradicionais…

…mas…

� As aplicações tornam-se cada vez mais complexas.� Surgem novos ‘tipos’ de informação que urge tratar: vídeo, audio, hipertexto,

imagem, etc.

…neste contexto…

� Surge o paradigma object-oriented como forma de resolver estas questões.� O C++ consegue implantar-se com grande sucesso (entre outras linguagens de

programação object-oriented).� Surgem várias propostas para modelação object-oriented.� Surgem os SGBDOO.

��������� ���� �

���������������������������� ������� A evolução dos SGBD neste contexto segue basicamente 2 direcções

1. Acrescentar às linguagens de programação object-oriented características de persistência.� Basicamente o que acontece é que se acrescenta persistência aos objectos criados

em linguagens de programação object-oriented. � Além da persistência muitos sistemas hoje em dia já implementam alguns dos

aspectos comuns em SGBD: linguagens de interrogação, noção de esquema de BD, multi-utilizador e gestão de concorrência, noção de transacção, etc.

� Uma das grandes vantagens desta abordagem é o facto de apenas existir um sistema para programação e base de dados.

2. Acrescentar ao modelo relacional características object-oriented.� A segunda abordagem consiste em acrescentar ao modelo relacional uma camada

superior object-oriented.� Isto permite uma mais fácil transição das bases de dados relacionais para as novas

bases de dados mas permanece normalmente a separação entre os dois mundos: o programador da lógica da aplicação (numa linguagem tradicional qualquer - linguagem host) e o desenhador da base de dados…

� Existem algumas tentativas de tornar este aspecto invisível para o programador através de extensões às linguagens de programação que façam a ‘tradução’ entre o modelo de dados da aplicação e o modelo semi-relacional.

��������� ���� �

���������������������������� ������

� Áreas em desenvolvimento dos SGBDOO� Linguagens de consulta e acesso por navegação

� Uso de inquéritos para aceder a um conjunto de objectos que obedeçam a um determinado critério, e depois navegar pelas estruturas que compõem os objectos encontrados

� Optimização de respostas a consultas� Obtenção da informação no menor tempo possível

� Objectos complexos� Representação de objectos que são constituídos à custa de outros, e/ou têm

referências para outros objectos� Abertura das linguagens de programação

� Muitas BDOO estão ligadas a linguagens de programação específicas (C++, Smalltalk, Lisp, etc) o que implica que o SGBD não seja um repositório de dados independente…

� Métodos armazenados nas BD� Algumas BDOO apenas armazenam a estrutura dos objectos (atributos ou dados)� Os métodos não são tratados pelo SGBD, sendo armazenados em ficheiros

‘normais’ externamente à base de dados. � Assim os métodos têm que ser ligados de forma ‘convencional’ ao programa� Num sistema que suporte o armazenamento de métodos é suficiente que o

utilizador apenas abra a base de dados, tendo disponível na altura os dados e os respectivos métodos.

��������� ���� �

���������������������������� ������

� Áreas em desenvolvimento dos SGBDOO� Acesso à meta base de dados

� Como meta base de dados entende-se a definição de classes, atributos e métodos� Grande parte das BDOO não trata a meta base de dados como objectos comuns� Isso impede que se consiga especificar consultas com o intuito de obter

informação sobre a estrutura das classes…� Definição dinâmica de classes

� Este problema é muito semelhante ao do acesso à meta base de dados e tem a ver com a possibilidade dinâmica de definição e alteração de classes

� Regras de integridade� Normalmente os mecanismos de consistência das BDOO limitam-se aos

implementados nos próprios métodos � Outros tipos de controlo de consistência como ‘triggers’, constrangimentos ao nível

dos valores de atributos, etc, não estão disponíveis nas BDOO� Mecanismo de vistas

� É pouco comum o suporte para vistas em BDOO� Existe uma opinião generalizada que o encapsulamento e a herança tornam a

definição de vista desnecessária.

��������� ����

���������������������������� ������

� Áreas em desenvolvimento dos SGBDOO� Integração com sistemas OOP

� Apesar da maior parte das BDOO supostamente integrarem bastante bem com linguagens de programação OO, essa integração ainda pode ser melhorada permitindo, por exemplo, referências entre objectos persistentes e temporários

� Ligação com SGBD não OO� No futuro próximo aumentará o uso de vários tipos de SGBD entre os quais as

BDOO� Para que se faça uso de todas as vantagens das BDOO é desejável que estas

interliguem com outros tipos de BD, em particular as BD relacionais� Para isso terão que existir desenvolvimentos ao nível de:

� Suporte de interface SQL.� Execução de transacções distribuídas entre BDOO e BDR.� Etc.

� Controlo de acessos� Este aspecto tem sido minimizado desde o inicio do desenvolvimento das BDOO� É necessário que se possam definir direitos ao nível dos objectos e das classes.

Só desta forma poderão as BDOO vir a ocupar lugar no desenvolvimento de aplicações tradicionais de informatização de negócios

��������� ���� �

� !�" ������ ���#!��$��$�

� OQL pretende definir uma extensão à linguagem C++ para inquéritos a objectos, com os seguintes objectivos:� Modelo de dados (de objectos) = Sistema de tipos da linguagem� Verificação de tipos� Inquéritos� Separação entre tipos e extensões de tipos � As extensões de tipos (ex: Set, Bag, Array, List, etc.) podem ser colecções

explícitas de objectos de um tipo ou colecções criadas e mantidas pelo programador

� Possibilidade de combinar instruções de inquérito e de programação� Abstracção de dados� Sintaxe e semântica uniforme entre linguagem de inquérito e instruções da

linguagem

_______________________________________________________________Nota:O OQL é baseado em investigação da ARPA (Advanced Research Projects Agency)U.S. Army Reseach LaboratoryReferência: Modern Database Systems, Won Lim, Addison-Wesley

��������� ���� %

� !�" ������ ���#!��$��$�

� O modelo de dados (C++) � Uma classe é um tipo de dado definido pelo utilizador que

determina a estrutura e comportamento das instâncias (objectos) dessa classe

� Um tipo de dados abstracto é simulado por uma classe que tem um conjunto de funções (métodos) públicos e não tem atributos públicos

� Sintaxe de um inquérito em OQL<resultado> =SELECT <objectos>FROM <variável de intervalo> IN <colecção>WHERE <predicado> ;

��������� ���� &

� !�" ������ ���#!��$��$�class Person{public:Person(Name&, Address&, Birthdate&);int age();String sex();Name name();Address home_address();virtual home_address();void set_name( Name& );void set_address( Address& );

…};

class Physician : public Person{public:String speciality();Address office_address();String phone();virtual void print();

…};

class Medical_Record{public: int patient_no();Date date();String diagnosis();List< Lab_Test > lab_tests();List< X_Ray > x_ray_tests();

…};

class Patient : public Person{public:int indent();Physician family_doctor();Set< Medical_Record > records;virtual void print();

…};

��������� ���� �

� !�" ������ ���#!��$��$�

� Devolver todos os doentes que são tratados pelo Dr. J. Smith

Set <Patient> result;result =

SELECT pFROM Patient p IN PatientsWHERE p.family_doctor().name() == "J. Smith";

ouresult =

SELECT pFROM Patient *p IN PatientsWHERE p->family_doctor().name() == "J. Smith";

��������� ���� ��

� !�" ������ ���#!��$��$�

� Devolver os doentes masculinos que foram diagnosticados com gripe antes de 5 de Junho de 1998� Neste exemplo é possível observar a utilização de

colecções como membros de um objecto

Set <Patient> result;result =

SELECT *FROM Patient p IN Patients

WHERE p.sex() == “male”&& EXISTS(SELECT r

FROM Medical_Record r IN p.records()WHERE r.date() < Date(05,06,1998)

&& r.diagnosis() == "flu");

��������� ���� ��

� !�" ������ ���#!��$��$�

� Os tipos de resultados dos inquéritos em OQL podem ser

1. O mesmo que o tipo de objectos da colecção que se estáa pesquisar (exemplos nos slides anteriores)

2. O tipo de uma classe pai do tipo de objecto da classe a inquirir

3. Um novo tipo

2. Exemplo da obtenção de um tipo (através de cast)Set <Person> result;result =

SELECT (Person) pFROM Patient p IN Patients

WHERE p.family_doctor().name() == "J. Smith";

��������� ���� ��

� !�" ������ ���#!��$��$�

3. Exemplo da obtenção de tipos sem relação directa com a colecção

� Projecçãoclass New_Object{ public:New_Object( Name&, int& );

…};

Set <New_Object> result;result =

SELECT New_Object( p.name(), p.age() )FROM Patient p IN Patients

WHERE p.age() < 10;

��������� ���� ��

� !�" ������ ���#!��$��$�

3. Exemplo da obtenção de tipos sem relação directa com a colecção

� Joinclass Dr_Patient{ public:Dr_Patient( Physician&, Patient& );

…};

Set <Dr_Patient> result;result =

SELECT Dr_Patient( d, p )FROM Physician d IN Physicians, Patient p IN Patients

WHERE d.office_address().street == p.home_address().street()&& d.office_address().city() == p.home_address().city();

��������� ���� ��

� !�" ������ ���#!��$��$�

3. Exemplo da obtenção de tipos sem relação directa com a colecção

� User-defined functions

Set <Patient> result;result =

SELECT pFROM Patient p IN Patients

WHEREEXISTS(SELECT *

FROM Medical_Record r IN p.records()WHERE EXISTS(SELECT *

FROM X_Ray x IN r.x_ray_tests()WHERE x_ray_match(x.picture(), pattern)));

��������� ���� �

� !�" ������ ���#!��$��$�� Suporte para alteração de dados no OQL (UPDATE, INSERT e DELETE)

� Alterar o número de telefone de todos os médicos cujo consultório se situa em 453 First St., Dallas, Texas para (214) 444-9999UPDATE SET p.set_phone("214-444-9999")

FROM Physician p IN PhysiciansWHERE p.address().street() == "453 First St.“

&& p.address().city() == "Dallas" && p.address().state() == "Texas";

� Apagar todos os pacientes do Dr. Smith da colecção de pacientes.DELETE FROM Patient p IN Patients WHERE p.family_doctor().name() == "J. Smith";

� Transferir todos os pacientes do Dr. Smith na colecção de pacientes que sofram de tuberculose para uma nova colecção designada Tuberculosis_PatientsSet<Patient> Tuberculosis_Patients;INSERT INTO Tuberculosis_PatientsSELECT * FROM Patient p IN PatientsWHERE p.family_doctor().name() == "J. Smith“

&& EXISTS( SELECT r FROM Medical_Record r IN p.records()WHERE r.diagnosis() == "Tuberculosis" );

��������� ���� ��

���������������������

� Exemplo da construção de um modelo OO� Considere-se uma empresa que aluga casas de

férias, de dois tipos: Campo e Praia. A base é o arrendamento semanal.

� Há quatro visões que ilustram o problema:1. arrendatários – grupos de pessoas que procuram casa

para alugar2. acordo de arrendamento3. casa de campo4. casa de praia

��������� ���� �%

���������������������

� Exemplo da construção de um modelo OO� Considere-se uma empresa que aluga casas de férias, de dois tipos:

Campo e Praia. A base é o arrendamento semanal.� Há quatro visões que ilustram o problema:

1. arrendatários – grupos de pessoas que procuram casa para alugar2. acordo de arrendamento3. casa de campo4. casa de praia 300,00�212121212Rua YYYJoão

200,00�222333444Rua XXXAsdrubal

Max AluguerTelefoneMoradaNome

4567-654

2340-222

Cod_Postal

Não250,00�3CB

Sim300,00�3CA

Prática de SkiAluguerNº QuartosMorada

3300-100

2200-000

Cod_Postal

500 m 400,00�4PB

2 Km500,00�3PA

Distância à PraiaAluguerNº QuartosMorada

134

��������� ���� �&

���������������������

NomeMoradaTelefoneAluguer-Max

Arrendatário

Mostrar aluguer

Data_InícioData_FimAluguer

Acordoarrendamento

Computar totaldo aluguer

MoradaCod_PostalNº_QuartosAluguer

Prática_SkiDist_Praia

CASAS

PRAIA CAMPO

Aluguer casa

��������� ���� �

���������������������

� AGREGAÇÃOé o relacionamento “parte-todo” ou “uma parte de”, na qual os objectos que representam os componentes de alguma coisa são associados a um objecto que representa a estrutura inteira.

Nº_EncomendaDataData_Entrega

ENCOMENDA

CLIENTE ARTIGO

símbolo deagregação

��������� ���� ��

���������������������

� MÉTODOS� Os métodos só podem processar dados dentro da classe de objectos na qual

estão definidos.� Podem receber pedidos de métodos de outra classe, mas não podem processar

dados noutra classe de objectos.

� Tipos de métodos� Métodos de manutenção

� Permitem a manutenção das ocorrências de cada objecto e de cada estrutura de classificação (generalização ou agregação): adicionar, alterar, remover, seleccionar.

� Estão incluídos em todos os objectos e têm funções como: controlo da integridade, ligação de ocorrências, gestão de respostas.

� Métodos de cálculo� Permitem cálculos sobre valores encapsulados no mesmo objecto.

� Métodos de monitorização� Por exemplo, num sistema de stock o alerta de ter atingido o stock mínimo

��������� ���� ��

���������������������

� MENSAGENS

Existe um método que é activado quando uma mensagem é enviada de uma classe de objectos (endereçador) para outra classe de objectos (receptor)

A ligação de mensagens é um caminho de comunicação entre o endereçador e o receptor.

1. um endereçador (classe de objectos) envia a mensagem2. um receptor (classe de objectos) recebe a mensagem, e realiza um ou mais métodos3. o receptor retorna a resposta ao endereçador.

��������� ���� ��

���������������������

Completemos, agora, o nosso modelo

CLIENTE – mostrar informação

CLIENTE – adicionar ocorrência

ENCOMENDA – adicionarencomenda

UTILIZADOR

CLIENTE ENCOMENDA ARTIGO

1 2

5 4

3

4

5

1

2

3

ARTIGO - expedir

CLIENTE –calcular total (crédito excedido)

��������� ���� ��

�'�������������������������

� Object/Relational mapping é o processo de conversão entre objectos e o modelo relacional. Basicamente, para aproveitar as vantagens desenvolvimento orientado a objectos, e guardar a informação persistente nas bases dados relacionais, pois ainda são as mais eficientes e fiáveis para grandes volumes de dados.

� Os objectos de negócio isolam totalmente as regras de negócio, os problemas de guardar os dados e os problemas de concorrência, são todos encapsulados. Como os clientes só interagem com os objectos de negócio, as alterações podem ser feitas na BD sem alterar código no Cliente.

� Os objectos de negócio podem ser implementados de várias modos, desde uma configuração Cliente/Servidor a N-Tier.

� As aplicações construídas com objectos têm uma manutenção mais fácil. A arquitectura separa a responsabilidade em diferentes camadas (ex. interface, objectos de negócio, e camada de dados)

� Os objectos podem ser facilmente reutilizados.� As bases dados relacionais continuam a ser as melhores para

tratamento de grandes quantidades de dados.

��������� ���� ��

�'�������������������������

� Conversão de uma classe simples� Uma classe simples, é fácil de converter para

uma base de dados relacional, pois basta criar uma tabela que tenha todos os atributos persistentes dessa classe.

CClienteCodigo : intNome : CStringMorada : CStringTelefone : CStringEMail : CString

��������� ���� �

�'�������������������������

� Conversão da herança e herança múltipla� As três técnicas mais comuns para converter herança

múltipla em RDMBS são a conversão vertical, horizontal e a filtrada. Para mostrar estas técnicas foi seguido o seguinte exemplo de herança representado em UML

Pessoa

Nome : CString Morada : CString

CProfessor Vencimento : float

CAluno AnoMatricula : int

��������� ���� ��

�'�������������������������

� Conversão vertical� Na conversão vertical cada classe é convertida

numa tabela, e as classes descendentes terão que referenciar de alguma maneira a classe ascendente (ex. através de uma chave). Sempre que seja necessário informação , é preciso efectuar uma operação de JOIN para aceder aos dados.

��������� ���� �%

�'�������������������������

� Conversão horizontal� Na conversão horizontal, cada classe do nível

mais baixo da herança é convertida numa tabela. Nessa tabela são também incluídos todos os campos herdados do(s) pai(s).

��������� ���� �&

�'�������������������������

� Conversão filtrada� Na conversão filtrada todas as classes são

convertidas numa única tabela, portanto a tabela terá que ter todos os atributos de todas as classes, e será acrescentado um campo que permitirá distinguir as subclasses.

��������� ���� �

�'�������������������������

� Conversão de relações� O seguinte diagrama de classes representa três

classes simplificadas e as relações entre elas :

CLinhasPreco : floatQuant : float

CEncomendaData : CStringVendedor : CString

CClienteNome : CString

As classes podem ser convertidas para uma base dados relacional, dando origem a seguinte estrutura:

��������� ���� ��

(��������)��������������������

� SGBDOO (OODBMS)Os SGBDOO são o resultado da integração da tecnologia de base de dados com o paradigma object-orientedDesde finais da década de 80 que surgiram SGBDOO, tendo em poucos anos sido desenvolvidas 3 gerações destes produtos.A primeira geração data de 1986 com a introdução no mercado do G-Base, da empresa francesa Graphael, seguido do GemStone da Servio Corporation em 1987 e do VBase da Ontologic em 1988. O objectivo destes SGBDOO eram dar persistência aos objectos das LPOO. Eram utilizados nos departamentos de investigação de grandes empresas.A segunda geração começa em 1989 com o produto ONTOS da Ontologic, seguido de outros como o ObbjectStore, o Objectivity/DB, etc. Estes produtos têm já usavam a arquitectura cliente/servidor e tinham uma plataforma comum: C++, XWindows e Unix.O Itasca foi o primeiro produto da terceira geração e surgiu em 1990.Era uma versão comercial do Orion que foi um projecto de investigação do MCC (Microelectronics andComputer Corporation). Outros produtos desta geração são o O2 e o Zeitgest.

��������� ���� ��

(��������)��������������������

Os produtos da terceira geração tinham características mais avançadas e tinham linguagens de definição e manipulação de dados que eram orientadas para objectos e computacionalmente completas.

Os SGBDOO mais importantes do mercado podem ser assim ordenados:� ORION/Itasca (nome da versão comercial a partir de 1990) da MCC� O2 (1986-1991) do Consorcio Altair� GemStone (1987) é o produto comercial mais antigo ainda hoje existente, em duas versões

GemStone/s (versão smalltalk) e GemStone/J (versão Java)� IRIS/OpenDB (1989) protótipo de investigação da HP� VBase/ONTOS (1988) de linguagem proprietária passou a C++.É totalmente distribuído.� ObjectStore (1989) tem suporte para documentos XML� POET (1999) – C++ e Java, suporta documentos XML e SGML.� Jasmine da CA

��������� ���� ��

(��������)��������������������

� OMG: consorcio Object Management Group� Sun Microsystems, Borland, AT&T/NCR, HP, Hitachi, Computer Associates, Unisys e Oracle� Criação de standards de facto, promoção de técnicas OO, …� ODMG, 2001 (Object Data Management Group)

� ODMG -Object Database Management Group é um consórcio industrial que pretende definir standards para bases de dados orientadas para objectos� Standards de linguagens de programação persistentes

� Inclui standards para C++, Smalltalk e Java� ODMG-93� ODMG-2.0 (1997) e 3.0 (2000 - extensão do 2.0 para Java)

� O standard ODMG C++ não altera a linguagem C++� Fornece funcionalidade para persistência via template classes e class libraries

��������� ���� ��

(��������)��������������������

� ODMG definiu uma arquitectura de standards, com os seguintes componentes:

- modelo de objectos (ODM – Object Data Model) - uma linguagem de definição de objectos (ODL –Object Definition Language) que permite definir o modelo de objectos. Permite a definição de objectos complexos, de relações entre esses objectos e dos métodos associados.- uma linguagem de consulta (OQL – Object Query Language) que permite consultar os objectos de estruturas complexas, de enviar mensagens a objectos, efectuar junções e outras operações de tipo associativo. A sua sintaxe é do tipo SQL.

- ligações com LP OO via C++, Java e Smalltalk. A norma ODMG não definiu uma linguagem de manipulação de objectos (OML – Object Manipulation Language), antes propôs mapeamentos para as linguagens de programção OO mais divulgadas.

��������� ���� ��

(��������)��������������������

� ODM define a base da norma ODMG em termos de, quais as características dos objectos que podem ser armazenados numa BDOO, como é que eles se relacionam , como podem ser manipulados, etc.

O modelo de dados é o do C++Uma classe é um tipo de dado definido pelo utilizador que determina a estrutura e comportamento das instâncias (objectos) dessa classeUm tipo de dados abstracto é simulado por uma classe que tem um conjunto de funções (métodos) públicos e não tem atributos pub

� ODL é uma linguagem de especificação utilizada para definir interfaces para tipos de objectos que aderem ao modelo de objectos da ODMG.

O principal objectivo da ODL é facilitar a portabilidade de esquemas de bases de dados entre SGBDOO que adiram à ODL. A ODL permite também uma maior facilidade de interligação entre diferentes fornecedores de soluções nesta área.

��������� ���� �

(��������)��������������������

Os tipos de objectos da ODL podem ser implementados numa grande variedade de linguagens de programação. A sintaxe da ODL estende a sintaxe da IDL (a linguagem de definição de interfaces do CORBA). A sintaxe da ODL é bastante próxima da sintaxe usada na definição de classes em C++.Diversos princípios guiaram o desenvolvimento da ODL: · a ODL deve suportar todas as construções semânticas do modelo de objectos da ODMG· a ODL não deve ser uma linguagem de programação completa, deve ser fundamentalmente uma linguagem para especificação de assinaturas de interfaces· a ODL deve ser independente da linguagem de programação · a ODL deve ser compatível com a linguagem de definição de interfaces da OMG (IDL)· a ODL deve ser extensível, não apenas tendo em vista futuras funcionalidades, mas também optimizações físicas· a ODL deve ser prática, fornecendo valor acrescentado para os desenvolvedores de aplicações, e ao mesmo tempo ser suportada pelos fornecedores de SGBDOO num intervalo de tempo razoável após a publicação da sua especificação

��������� ���� ��

(��������)��������������������

Um ficheiro ODL pode conter uma ou mais especificações. Essas especificações podem definir:

· Interfaces · Constantes · Tipos · Módulos

� OQL é uma linguagem associativa de consulta do ODMG� inspirada em SQL� originária do Software O2

OQL baseia-se no mesmo sistema de tipos de uma LP OO� Consultas podem ser embutidas dentro da LP OO� Consultas podem chamar operações programadas na LP OO

��������� ���� �%

(��������)��������������������

Objectos consultados: � Objectos com nomes � Extensões de classes (extent)Linguagem funcional com expressões aninhadasOQL não é uma linguagem completa para desenvolvimento de aplicaçõesOQL não possui comandos de alteração� alterações são feitas com o uso de operações definidas na LP OOOQL é baseada em SQL 92, com extensões para OO� Objectos complexos� Identidade de objectos� Expressões de caminho� Polimorfismo� Chamada de operações� Late-binding

��������� ���� �&

(��������)��������������������

� VANTAGENS DAS BDOO� Dados não homogéneos – permite representar dados com formatos variáveis. O modelo

relacional exigia homogeneidade dos tuplos e a atomicidade dos seua atributos.� Objectos complexos – utilizando os conceitos de herança e agregação dão origem a um

conjunto de tipos de dados praticamente ilimitado� Poder de modelação – permite a construção de modelos semânticamente mais ricos que

os modelos convencionais, atrvés de uma modelação mais natural e intuitiva.� Comportamento bem definido – o objecto apenas reage a determinadas mensagens e

para cada uma reage de forma bem determinada� Eliminação do ‘impedance mismatch’ – trabalha-se só com uma única linguagem

comum às bases de dados e ao nível aplicacional� Versões de objectos – para cada objecto podem ser mantidos pelo sistema as suas versões

anteriores, e mesmo versões alternativas do mesmo objecto.� Alterações bem localizadas – alterações à ‘caixa preta’ não afectam o resto do sistema� Reutilização do software – os objectos armazenados na BD são partilhados pelo nível

aplicacional.O código correspondente aos métodos definidos para as várias classes persistentes é também partilhado, resultando numa efectiva reutilização do software.

��������� ���� �

(��������)��������������������

� DIFICULDADES DA TECNOLOGIA OO

� Segurança – quem pode aceder, a que objectos, e para fazer o quê. O conceito de herança ao longo de uma hierarquia de classe torna difícil a segurança de acessos a cada utilizador.

� Recuperação/tolerância a falhas – é mais complexa que nas BD convencionais em que as transacções são curtas e atómicas.

� Controlo da concorrência – devido ao conceito de herança quando uma transacção acede a instâncias de uma dada classe, qualquer transacção deve ser impedida de modificar as super-classes e o mesmo às sub-classes

� Interface com o utilizador - pelo facto de todas as operações terem de estar pré-definidas e as referências entre os objectos se fazerem por meio de apontadores, estamos perante um modelo com características navegacionais, o que vem colocar algumas limitações ao nível da interface com os utilizadores.