1

INF1404 – MODELAGEM DE SISTEMAS

Bacharelado em Sistemas de Informação

Ivan Mathias Filho

ivan@inf.puc-rio.br

© LES/PUC-Rio

Programa – Capítulo 5

• Generalização

• Modelo de Domínio

2

© LES/PUC-Rio

Programa – Capítulo 5

• Generalização

• Modelo de Domínio

© LES/PUC-Rio

• Muito antes do alvorecer da ciência os seres humanos já nomeavam as espécies;

• Isso os permitia obter sucesso nas suas atividades de caça e coleta;

• A Taxonomia, palavra de origem grega cujo significado é “estudo das classificações”, surgiu no século XVII;

• Ela ganhou força no século seguinte, graça ao trabalho do naturalista sueco Carl Linnaeus, que inventou um sistema para organizar os seres vivos em grupos cada vez menores;

• Neste sistema, os membros de um grupo particular compartilhavam determinadas características.

Taxonomia (1)

3

© LES/PUC-Rio

Taxonomia (2)

© LES/PUC-Rio

• Posteriormente, a palavra taxonomia começou a ser usada em um sentido mais abrangente, podendo ser aplicada na classificação de quase tudo – objetos animados, inanimados, lugares e eventos.

Taxonomia (3)

4

© LES/PUC-Rio

Exemplo – Taxonomia de polígonos

© LES/PUC-Rio

• A generalização é atividade de identificar aspectos comuns e não comuns entre os conceitos pertencentes a um domínio de aplicação;

• Ela nos permite definir relações entre superclasses –conceitos gerais – e subclasses – conceitos específicos;

• Tais relações formam uma taxonomia de conceitos de um certo domínio, que é ilustrada através de uma hierarquia de classes.

Generalização

5

© LES/PUC-Rio

• A generalização pode ser vista sob a ótica da Teoria dos Conjuntos;

• Desse ponto de vista, o diagrama de Venn abaixo é equivalente ao diagrama de classes do slide anterior.

Teoria dos Conjuntos

© LES/PUC-Rio

• Identificar superclasses e subclasses nos oferecem os seguintes benefícios:

– Nos permite compreender aspectos de um problema em termos mais gerais e abstratos;

– Resulta em mais expressividade, melhoria na compreensão e redução das redundâncias de um modelo;

– Nas atividades de design e implementação, a utilização de superclasses e subclasses, juntamente com o mecanismo de polimorfismo, nos permite construir softwares bem organizados.

Benefícios

6

© LES/PUC-Rio

• Podemos afirmar, informalmente, que toda instância de uma classe é também instância da sua superclasse;

• Isso é conhecido como a regra é-um (is-a): todo quadrado é um retângulo, e todo retângulo é um polígono;

• Logo, podemos concluir que todas as propriedades válidas para os objetos de uma classe também são válidas para os objetos das suas subclasses.

Regra “É-UM”

© LES/PUC-Rio

• Por propriedades devemos entender:

– Atributos (variáveis);

– Operações (métodos);

– Relações (variáveis).

Propriedades de uma classe

7

© LES/PUC-Rio

Exemplo

© LES/PUC-Rio

• Pela regra é-um podemos afirmar o seguinte em relação ao exemplo anterior:

– Um pagamento com cartão de crédito é uma espécie de pagamento, logo, ele possui um valor e salda uma venda(propriedades herdadas de Pagamento);

– A operação getValor() é válida para as três formas de pagamento existentes.

Regra “É-UM” – Exemplo

8

© LES/PUC-Rio

• Nem todas as propriedades válidas para os objetos de uma classe são válidas para os objetos da sua superclasse;

• No exemplo anterior, o número e a validade de um cartão são propriedades exclusivas do pagamento através de cartão de crédito, não sendo aplicáveis às outras formas de pagamento;

• Poderíamos também associar um pagamento com cartão a uma classe que representasse a operadora do cartão usado;

• Tal associação seria válida apenas para os pagamentos com cartão.

Regra “É-UM” – Comentários

© LES/PUC-Rio

Exemplo – Pagamento com cartão

9

© LES/PUC-Rio

Generalização e herança

• Não devemos confundir generalização com herança;

• Uma generalização é uma relação entre classes, onde uma classe mais especializada (subclasse) é definida em termos de uma classe mais geral (superclasse);

• A herança é o mecanismo pelo qual todos as propriedades não privadas de uma superclasse fazem parte do espaço de nomes de uma subclasse.

© LES/PUC-Rio

• No exemplo da hierarquia de polígonos, poderíamos ter definido uma operação chamada perímetro, que seria responsável pelo cálculo do perímetro de um polígono;

• Como esta operação é válida para qualquer polígono, o mais razoável seria declará-la na classe Polígono;

• Dessa forma, todas as subclasses de Polígono herdariam a implementação desta operação;

• Tal implementação iria calcular o comprimento de cada lado de um polígono e depois somá-los.

Redefinição de operação (1)

10

© LES/PUC-Rio

• Podemos especular, entretanto, que por questão de eficiência, seria mais interessante implementar, em certos casos, uma nova versão desta operação;

• Por exemplo, no caso de um quadrado seria mais eficiente calcular o comprimento de qualquer um dos lados e multiplicar o resultado por quatro.

Redefinição de operação (2)

© LES/PUC-Rio

Redefinição de operação - Exemplo

A operação perimetro, definida na classe Poligono, foi redefinida nas classes Retangulo e Quadrado, podendo, assim, tirar proveito de implementações mais eficientes.

11

© LES/PUC-Rio

• Até agora, em todos os exemplos de generalização apresentados foi usada apenas a herança simples;

• Na generalização simples um classe só pode ser subclasse de uma única superclasse;

• Isso quer dizer, sob a ótica da Teoria dos Conjuntos, que em uma generalização simples a interseção entre duas classes (conjuntos) quaisquer é sempre vazia, exceto quando uma for subclasse da outra – direta ou transitivamente;

• Neste caso, a interseção será a própria subclasse;

• Mais adiante iremos tratar da generalização múltipla.

Generalização Simples

© LES/PUC-Rio

Programa – Capítulo 5

• Generalização

• Modelo de Domínio

12

© LES/PUC-Rio

• Um modelo de domínio é uma representação visual –embora possa conter especificações textuais – das classes conceituais, ou objetos reais, de um certo domínio de aplicação;

• O modelo de domínio é também conhecidos por modelo conceitual, modelo de objetos de domínio e modelo de objetos de análise.

Modelo de domínio

© LES/PUC-Rio

• A construção de um modelo de domínio tem os seguintes objetivos:

– Identificar os principais conceitos relacionados a um certo domínio de aplicação, para melhor compreendê-lo;

– Analisar o problema sob uma perspectiva conceitual, evitando, assim, tratar dos aspectos relacionados ao design e à implementação nos estágios iniciais de um projeto.

Modelo de domínio - Objetivos

13

© LES/PUC-Rio

• Um modelo de domínio é representado, utilizando-se a linguagem UML, através de um ou mais diagramas de classes onde nenhuma operação (assinatura de um método) é definida;

• Em geral, este modelo apresenta o seguinte:

– Objetos de domínio ou classes conceituais;

– Associações entre as classes conceituais;

– Atributos das classes conceituais.

Modelo de domínio - Representação

© LES/PUC-Rio

Exemplo

14

© LES/PUC-Rio

• Os nomes e as principais propriedades das classes de software da camada de domínio de uma aplicação devem ser baseados nas suas contrapartes do modelo de domínio;

• Isso diminui o gap de representação entre o nosso modelo mental e o modelo de software de uma aplicação.

Benefícios

© LES/PUC-Rio

Gap de representação

15

© LES/PUC-Rio

• As classes conceituais fazem parte do vocabulário de um determinado domínio aplicação;

• Informalmente, uma classe conceitual representa uma idéia ou um conjunto de objetos.

Classes conceituais

© LES/PUC-Rio

• Para construir um modelo de domínio proceda da seguinte maneira:

– Liste os candidatos a classes conceituais levando em consideração o seu conhecimento prévio do domínio do problema, e identificando os substantivos nas descrições dos casos de uso;

– Crie uma versão inicial do modelo de domínio;

– Acrescente os relacionamentos;

– Acrescente os atributos.

Construção do modelo

Um modelo de domínio não é intrinsecamente correto ou errado, mas sim, mais ou menos útil. Ele é uma ferramenta de comunicação.

16

© LES/PUC-Rio

Candidatos a conceitos

• Papéis desempenhados por pessoas;

• Objetos tangíveis ou intangíveis;

• Lugares;

• Descrições de coisas;

• Contêineres de alguma coisa;

• Coisas em um contêiner;

• Contratos, operações financeiras e etc;

• Organizações;

• Serviços.

Olhe com carinho para os substantivos encontrados na descrição de um problema.Eles são sérios candidatos a classes.

© LES/PUC-Rio

• Uma das maiores fontes de dúvidas durante a modelagem de domínio é a representação de um determinado conceito como classe ou como atributo de uma classe;

• Os princípios a seguir podem nos ajudar a debelar tais dúvidas:

Atributos vs. Classes

17

© LES/PUC-Rio

• Se houver necessidade de distinguir dois objetos distintos que possuam o mesmo valor, devemos tratar tais objetos como instâncias de uma classe;

• Caso contrário, eles podem se considerados um valor, não podendo ser distinguidos um do outro.

1º Princípio

© LES/PUC-Rio

• Caso não seja necessário distinguir duas cidades com o mesmo nome, o modelo abaixo será satisfatório.

Exemplo (1)

18

© LES/PUC-Rio

• Caso contrário, a solução a seguir deverá ser a escolhida.

Exemplo (2)

© LES/PUC-Rio

• Ainda em relação ao exemplo anterior:

– Como poderíamos validar o nome de uma cidade que foi informada por um usuário de um sistema?

Domínio de valores

Como não existe nenhuma regra de validação de nomes de cidades, nós só poderemos proceder a validação se existir um cadastro que contenha a relação dos nomes das cidades válidas.

19

© LES/PUC-Rio

• Se no mundo real, a existência de um determinado objeto não estiver subordinada a existência de nenhum outro, então o conjunto de tais objetos deverá ser tratado como uma classe.

2º Princípio

© LES/PUC-Rio

• Tratar o curso no qual um aluno está matriculado como um atributo de aluno não é adequado;

• Os cursos oferecidos por uma universidade existem independentes dos alunos que nele estão matriculados.

Exemplo (1)

20

© LES/PUC-Rio

• A melhor solução é criar uma classe chamada Curso e associá-la à classe Aluno;

• Dessa forma, uma ligação entre dois objetos destas duas classes, representada pelo par (a1, c1), significa que o aluno a1 está matriculado no curso c1.

Exemplo (2)

© LES/PUC-Rio

• Seja uma concessionária que comercializa automóveis zero Km;

• Cada automóvel deve ser descrito pelos seguintes atributos: marca, modelo, no do chassi, preço e cor;

• O diagrama a seguir ilustra a classe Automóvel:

Classes de descrição (1)

21

© LES/PUC-Rio

Classes de descrição (2)

Se a concessionária não possuir no estoque nenhum automóvel de uma determinada marca e modelo, como informar a um cliente interessado o preço do automóvel em questão?

© LES/PUC-Rio

• A melhor solução é criar uma classe de descrição;

• Essa classe deve conter todos os atributos cujos valores descrevam as características comuns a um conjunto de automóveis;

• Os atributos cujos valores descrevam características específicas de um veículo devem permanecer na classe Automóvel.

Solução

22

© LES/PUC-Rio

• Atributos não devem ser usados para relacionar indiretamente duas classes conceituais de um modelo de domínio, embora esta técnica seja empregada para relacionar linhas de tabelas relacionais (chave estrangeira).

Associações indiretas

O atributo codDisciplina foi usado para relacionar uma turma à sua disciplina

© LES/PUC-Rio

• Estabeleça uma relação explícita entre a classe Turma e a classe Disciplina.

Solução

23

© LES/PUC-Rio

Candidatos a associações

Olhe com carinho para os verbos encontrados na descrição de um problema.Eles são sérios candidatos definir relações entre classes.

© LES/PUC-Rio

• Em relação à generalização, as seguintes questões devem ser respondidas:

– Quando devemos criar uma generalização?

– Em quais circunstâncias o uso de uma generalização nos ajuda a criar uma concepção mais clara e abstrata de um domínio de aplicação?

– Que critérios devemos seguir para criar generalizações que realmente nos ajude a melhor compreender um problema?

Uso da generalização (1)

24

© LES/PUC-Rio

Uso da generalização (2)

Em relação a um determinado problema, será que existem diferenças significativas entre clientes do

sexo masculino e do sexo feminino?

© LES/PUC-Rio

• Crie uma subclasse de uma classe conceitual quando:

– For necessário criar atributos aplicáveis apenas às instâncias da subclasse;

– Houver associações aplicáveis apenas à subclasse;

– Quando houver diferença no comportamento (operações) das instâncias da subclasse e tais diferenças forem significativas para o correto entendimento do problema.

Criação de subclasses

25

© LES/PUC-Rio

• Crie uma superclasse para um conjunto de classes quando:

– As potenciais subclasses conceituais representarem variações de um mesmo conceito;

– A regra é-um puder ser plenamente aplicada às subclasses em relação à superclasse que será criada;

– Existirem propriedades comuns a todas as classes, que poderão ser fatoradas na superclasse que será criada.

Criação de superclasses

© LES/PUC-Rio

• Qual das duas soluções seria mais adequada para um modelo de domínio?

Atributo vs. Generalização

ou

Por ser mais objetiva, a segunda opção é mais adequada a um modelo de domínio, mesmo que não existam diferenças significativas entre os dois tipos de cliente.

Durante a implementação, entretanto, podemos utilizar a primeira opção por uma questão de simplicidade e eficiência

26

© LES/PUC-Rio

Artefatos do UP

© LES/PUC-Rio

Quando criar os modelos?

A tabela abaixo ilustra alguns artefatos produzidos dentro do Processo Unificado, e as fases nas quais eles são criados e refinados.

27

© LES/PUC-Rio

Bibliografia

• Bezerra, E. Princípios de Análise e Projeto de Sistemas com UML. 1ª edição, Campus, 2006.

• Larman, C. Utilizando UML e Padrões. 3ª edição, Bookman, 2007.