Heurísticas para construir diagramas de Classes a partir de diagramas de

A Figura 6.1 exibe os quatro passos que são propostos para a construção da primeira versão de um diagrama de classes para ser trabalhado posteriormente durante o design detalhado, o projeto e a implementação do sistema. A Figura 6.2 apresenta um exemplo de um diagrama de ontologia, que será utilizado para explicar a abordagem proposta.

Figura 6.1 - Os passos propostos

Quando iniciamos a modelagem OO com a Análise Semântica como base, provavelmente a primeira questão a ser respondida é “Onde estão os objetos no diagrama de Ontologia?” Durante a Análise Semântica o mundo é modelado pela identificação de construções sociais chamadas affordances e durante a análise OO o mundo é modelado pela identificação de objetos presentes no mundo. A presença de um affordance no diagrama de ontologia sugere classes para serem modeladas no diagrama de classes, por exemplo: Um “departamento” pela perspectiva da Análise Semântica é um affordance da

1. A partir dos nomes dos affordances criar uma lista

com as possíveis classes e operações

2. Modelar as relações entre classes e operações a partir

das relações existentes no diagrama de ontologia

4. Dar nomes às associações e reordenar o diagrama

de classes caso necessário

3. Modelar atributos a partir dos determinantes

sociedade e sob a perspectiva da OO ele pode ser um objeto com atributos internos e operações.

Se o affordance “departamento” foi representado no diagrama de ontologias, isto sugere que, pela perspectiva OO, existe um objeto no contexto e provavelmente é possível referenciar a sua classe utilizando o nome “departamento”. Esta é a primeira heurística proposta (baseada no conhecido procedimento de extrair nomes de classes a partir de substantivos): nomes de affordances que são “substantivos” podem ser traduzidos para classes.

Figura 6.2 - Diagrama de Ontologia para a gerência de projetos (de Liu, 2000, pp. 79)

A Figura 6.2 exibe alguns signos que estão relacionados a objetos na perspectiva OO. Nós podemos dizer que “sociedade”, “organização”, “departamento”, “pessoa”, “empregado”, “empregador” e “tarefa” são todos nomes de objetos pela perspectiva OO. Após listar alguns objetos que potencialmente serão parte do diagrama de classes inicial, podemos fazer outra pergunta “O quê os outros affordances sugerem?”. Por exemplo, “trabalha” é um affordance na Figura 6.2 e ele pode ser visto como uma operação de algum objeto pela perspectiva OO. A presença de “trabalha” no diagrama de ontologia sugere que existe alguma classe com a operação “trabalha”. A segunda heurística sugerida é: nomes de affordances que são “verbos” podem ser traduzidos para operações. Desta maneira é possível construir uma tabela com as classes e as operações potenciais. A Tabela 6.1 foi construída pela aplicação destas duas heurísticas ao diagrama da Figura 6.2; este é o resultado do primeiro passo proposto.

sociedade organização departamento projeto emprega trabalha trabalha na designado para tarefa responsável por (empregado) (empregador) #orçamento

#função #carga horária

#orçamento

#tempo gasto pessoa

Tabela 6.1 – Classes e Operações Potenciais

Classes Potenciais Operações Potenciais

sociedade trabalha

organização designado para

departamento emprega

pessoa trabalha na

empregado responsável por

empregador projeto tarefa

O segundo passo envolve descobrir as relações entre classes e operações para construir a primeira versão do diagrama de classes. O diagrama de ontologia pode sugerir algumas relações entre os conceitos da tabela de classes e operações. Por exemplo: existe uma dependência entre os affordances “sociedade” e “pessoa” na figura 6.2, e eles são classes na tabela 6.1. A dependência ontológica sugere que existe uma associação entre as classes “sociedade” e “pessoa”.

“Por quê a dependência ontológica sugere este tipo de relação?” Se existe uma dependência ontológica no diagrama de ontologia, isso significa que o affordance dependente somente é possível durante a existência do affordance antecedente. Pela perspectiva OO nós podemos dizer que objetos derivados do affordance dependente (por exemplo “pessoa”) são criados e destruídos durante a existência do objeto derivado do

affordance antecedente (por exemplo “sociedade”). Esta interpretação sugere que o

objeto “pessoa” somente existe se o objeto “sociedade” também existir. Este tipo de dependência “existencial” não pode ser diretamente representado no diagrama de classes, visto que este diagrama não especifica quando os objetos são construídos e destruídos. Para representar este tipo de dependência podemos utilizar os diagramas de comportamento da UML (esta dependência pode ser armazenada em uma lista de dependências de ciclo de vida para ser utilizada durante a construção dos diagramas de comportamento). Como uma terceira heurística nós propomos modelar uma associação entre classes, sempre que um objeto não pode existir se outro não existir.

O caso descrito no último parágrafo é somente um entre os casos possíveis de relações entre affordances no diagrama de ontologia que resultam em relações entre elementos da tabela com as classes e operações potenciais. No total foram identificados 10 casos diferentes. As Tabelas 6.2 até a 6.5 descrevem as regras heurísticas para serem aplicadas para cada caso e a fundamentação para cada uma delas. Estes casos estão distribuídos em quatro grupos:

• Grupo A (Tabela 6.2). Regras para serem aplicadas em relações entre

affordances cujos nomes são “substantivos” no diagrama de ontologia. Por

exemplo, na Figura 6.2 as relações deste grupo são: “sociedade-pessoa”, “sociedade-organização”, “pessoa-empregado”, “organização-empregador”, “organização-departamento”, “organização-projeto” e “projeto-tarefa”;

Tabela 6.2 - Regras do Grupo A

Regra Descrição da Regra e Exemplo Fundamentação a.i Se a relação é “parte-todo” no diagrama de

ontologia então o diagrama de classes terá uma composição. Por exemplo o affordance “departamento” é parte da “organização” no diagrama de ontologia; então, no diagrama de classes a “organização” ira compor a classe “departamento”

O relacionamento “parte-todo” significa que um

affordance não é só parte de seu antecedente

mas também é ontologicamente dependente dele. Na Orientação a Objetos uma “agregação” representa um objeto como parte de outro, mas não especifica que a parte não pode existir sem o todo. Por isso, é proposto o uso de “composição”, um tipo de especial de “agregação”, que especifica que o objeto que compõe é responsável por criar e destruir as suas partes. Desta maneira o ciclo de vida da “parte” está restrito ao ciclo de vida do “todo” a.ii Se a relação é uma “dependência ontológica”

então existirá uma associação entre as classes correspondentes aos affordances que fazem parte desta dependência. A dependência existencial deve ser representada nos diagramas de comportamento. Por exemplo: se o affordance “problema” é ontologicamente dependente do affordance “organização”, então no diagrama de classes existirá uma associação entre “problema” e “organização”, e nos diagramas de comportamento o objeto da classe “problema” é instanciado e destruído somente se existir um objeto da classe “organização”

Uma “dependência ontológica” significa que o

affordance dependente somente é possível se

existir o antecedente. Pela perspectiva OO nós podemos dizer que o objeto derivado do

affordance dependente deveria ser criado e

destruído durante a existência do objeto derivado do antecedente. Este tipo de dependência não pode ser representado no diagrama de classes, visto que ele não especifica quando os objetos são construídos e destruídos. Esta é a razão pela qual propomos o uso de diagramas de comportamento para representar isto. Nós propomos também uma associação entre as classes, pois esta dependência entre

affordances sugere uma associação entre as

classes

de ontologia, a classe correspondente ao papel será uma subclasse da classe correspondente ao affordance antecedente e terá uma associação com a classe correspondente ao affordance da sua direita (se esta não for uma de suas operações). Por exemplo: o “papel” “empregado” na figura 6.2 é dependente de “pessoa” e “emprega”, então no diagrama de classes “empregado” será uma sub-classe de “pessoa” e terá uma relação com a classe que contém a operação “emprega”

que um agente possui um papel específico. Pela perspectiva OO nós poderíamos ter um objeto que foi derivado do papel como uma especialização do objeto derivado do affordance antecedente; ou seja, ele é um objeto de uma subclasse da classe do “agente”. Em alguns casos uma alternativa é o uso do conceito de “papel” da orientação a objetos, mas este conceito tem um significado diferente, pois ele especifica o papel de um objeto em uma associação e não um objeto que tem um papel específico

a.iv Se a relação é uma “especialização” ela pode ser traduzida para uma relação hierárquica no diagrama de classes. Por exemplo se “pessoa física” e “pessoa jurídica” são termos específicos para “pessoa legal” então no diagrama de classes “pessoa física” e “pessoa jurídica” serão subclasses da classe “pessoa legal”

Uma “especialização” na Análise Semântica significa que nós temos um affordance genérico e outro especializado. Na perspectiva OO nós temos um objeto genérico e outro especializado; este conceito é modelado como uma relação hierárquica no diagrama de classes

• Grupo B (Tabela 6.3). Regras para serem aplicadas a relações entre

affordances onde o nome do antecedente é um “substantivo” e o nome do

dependente é um “verbo” (ou “expressão verbal”). Por exemplo na figura 6.2, nós temos: “empregado-trabalha”, “departamento-trabalha”, “empregado-trabalha na”, “tarefa-trabalha na”, “departamento-responsável por”, “projeto-responsável por”, “projeto-designado para” e “empregado- designado para”;

Tabela 6.3 - Regras do Grupo B

Regra Descrição da Regra e Exemplo Fundamentação b.i Se a relação é uma “dependência ontológica”

nós temos duas opções: (1) a operação correspondente ao affordance dependente será parte (como operação) da definição correspondente a um de seus antecedentes, ou (2) se ele já é parte de alguma classe, então o diagrama de classe terá uma associação entre esta classe (classe na qual o affordance foi modelado como operação) e a classe correspondente ao affordance antecedente. A escolha sobre qual classe irá conter a operação é feita de acordo com os princípios da OO (por exemplo: “andar” pode ser uma operação da classe “pessoa”). A dependência existencial será representada nos diagramas de comportamento. Por exemplo: o affordance

Uma “dependência ontológica” significa que o

affordance dependente somente é possível se

existir o antecedente. Se a operação (derivada do affordance dependente) é parte da definição da classe (derivada do affordance antecedente) a operação somente é possível se a classe é possível, visto que não existe operação sem classe na abordagem OO refletindo assim a dependência ontológica. Se a operação já é parte da definição de outra classe nós propomos uma associação entre as classes, porque a operação (derivada do affordance dependente) somente é possível se a classe (derivada do affordance antecedente) for possível. O diagrama de classe não especifica quando os objetos são construídos e destruídos, para isso propomos o

“andar” é dependente de “pessoa” e “superfície” no diagrama de ontologia; no diagrama de classes “andar” será uma operação de “pessoa” e existirá uma associação entre “pessoa” e “superfície”. Os diagramas de comportamento devem refletir o fato de que o método “andar” não é possível sem um objeto da classe “superfície”

uso de diagramas de comportamento

b.ii Se a relação é uma “especialização” no diagrama de ontologia, então o diagrama de classe terá a operação derivada do affordance especializado (no diagrama de ontologia) como parte da definição da classe derivada do affordance genérico. Por exemplo: o

affordance genérico “atitude” e os affordances

especializados “desejo”, “querer” e “gostar”, no diagrama de classe “atitude” terá as operações “desejo”, “querer” e “gostar”

Uma “especialização” significa que nós temos um affordance genérico e outro especializado. Não existe relações hierárquicas entre classes e operações em um diagrama de classes. Por isso é proposto que a operação deveria ser parte da definição da classe derivada do affordance genérico visto que a “especialização” no diagrama de ontologia sugere que os affordances têm algum comportamento em comum

• Grupo C (Tabela 6.4). Regras para serem aplicadas em relações entre

affordances onde o nome do antecedente é um “verbo” (ou “expressão

verbal”) e o nome do dependente é um “substantivo”. Um exemplo deste grupo pode ser (não existe este caso no exemplo da Figura 6.2): o

affordance “erro” (de transmissão) é ontologicamente dependente do verbo

“transmitir”, ou seja erros de transmissão existem enquanto algum agente transmite algo;

Tabela 6.4 - Regras do Grupo C

Regra Descrição da Regra e Exemplo Fundamentação c.i Se a relação é uma “dependência ontológica” o

diagrama de classes terá uma associação entre a classe relacionada ao dependente e a classe onde a operação (derivada do antecedente) foi especificada. A dependência existencial será representada nos diagramas de comportamento. Por exemplo, o affordance “erro” é

ontologicamente dependente do affordance “transmite”; então, o diagrama de classes terá uma associação entre a classe que possui o método “transmite” (por exemplo a classe “servidor de email”) e a classe “erro”

Uma “dependência ontológica” significa que o

affordance dependente somente é possível se

existir o antecedente. Como o primeiro é um “verbo” e o segundo é um “substantivo” então temos uma operação e uma classe. O fato de um objeto existir somente se uma certa operação também existir pode ser interpretado como o objeto deve ser criado e destruído durante a execução de uma certa operação (possivelmente através de invocação em cadeia). Este fato pode ser representado pelos diagramas de comportamento da UML e as invocações entre classes sugerem associações no diagrama de classes

• Grupo D (Tabela 5). Regras para serem aplicadas em relações entre

affordances cujos nomes são “verbos” no diagrama de ontologia. Um

exemplo deste grupo pode ser (não existe este caso no exemplo da Figura 6.2): o affordance “tropeçar” é ontologicamente dependente do affordance “andar”.

Tabela 6.5 - Regras do Grupo D

Regra Descrição da Regra e Exemplo Fundamentação d.i Se a relação é “parte-todo” nós temos duas

opções: (1) se as operações são parte da mesma classe então a operação derivada do antecedente deverá invocar (talvez não diretamente) a outra operação e (2) se elas são parte da definição de classes diferentes então existirá uma associação entre as duas classes, e o antecedente irá invocar (talvez não diretamente) a outra operação. Por exemplo: uma parte do affordance “registrar” é o

affordance “preencher”; desta maneira, o

diagrama de classe poderia ter “registrar” e “preencher” como parte da mesma classe (por exempo a classe pessoa) e os diagramas de comportamento iriam refletir que a execução de “preencher” somente é possível durante a execução de “registrar”

A relação “parte-todo” significa na análise semântica que um affordance é parte de outro

affordance. Na perspectiva OO isto pode

significar que uma operação é parte de outra operação. Então propomos que uma operação poderia invocar (talvez não diretamente) a outra operação. Os diagramas de comportamento devem refletir esta relação. Se elas forem parte da definição de classes diferentes então deverá existir uma associação uma vez que invocações entre classes nos diagramas de comportamento sugerem associações a serem modeladas no diagrama de classes

d.ii Se a relação é uma “dependência ontológica” nós temos duas opções (como na regra d.i): (1) se as operações são parte da mesma classe então a operação derivada do antecedente deverá invocar (talvez não diretamente) a outra operação e (2) se elas são parte da definição de classes diferentes então existirá uma associação entre as duas classes, e o antecedente irá invocar (talvez não diretamente) a outra operação. Por exemplo o affordance “tropeçar” é ontologicamente dependente do affordance “andar”; no diagrama de classes, se eles são parte da definição da mesma classe (por exemplo “pessoa”) então os diagramas deverão refletir que a execução de “tropeçar” ocorre durante a execução de “andar”

Uma “dependência ontológica” significa que o

affordance dependente somente é possível se

existir o antecedente. Como os dois são “verbos” pela perspectiva OO, uma operação existe somente se outra operação também existir. Desta maneira, uma operação deveria estar executando se e somente se outra também estivesse. Por esta razão propomos que a operação relacionada ao antecedente deveria invocar (talvez não diretamente) a outra operação. Estes aspectos são representados pelos diagramas de comportamento na UML. Se elas forem parte da definição de classes diferentes, então deverá existir uma associação uma vez que invocações entre classes nos diagramas de comportamento sugerem associações a serem modeladas no diagrama de classes

d.iii Se a relação é uma “especialização” no diagrama de ontologia, nós temos duas opções: (1) se os affordances genérico e especializado foram traduzidos para operações da mesma classe, a especializada deveria utilizar a genérica durante sua execução e (2) se os

affordances genérico e especializado foram

traduzidos para operações de classes diferentes, isso pode sugerir uma relação hierárquica entre

Uma “especialização” significa que nós temos um affordance genérico e outro especializado. Como ambos são “verbos” na perspectiva OO nós supostamente teríamos uma operação “genérica” e outra “especializada”. No diagrama de classes não existe relação hierárquica direta entre operações. A operação mais especializada poderia utilizar a genérica para executar algum comportamento genérico. Se eles estão em

as classes. Por exemplo os affordances “andar” e “correr” são uma especialização do

affordance “locomover”, se eles foram

traduzidos para a mesma classe (por exemplo “pessoa”) as operações “andar” e “correr” poderiam utilizar a operação “locomover”

classes diferentes, isto poderia sugerir que as classes têm pelo menos algum tipo de comportamento comum para estas operações, sugerindo assim que deveríamos indagar se pode ou não existir uma relação hierárquica entre as classes