INF1404 MODELAGEM DE SISTEMAS

Transcrição

1 INF1404 MODELAGEM DE SISTEMAS Bacharelado em Sistemas de Informação Ivan Mathias Filho Programa Capítulo 5 Generalização Modelo de Domínio 1

2 Programa Capítulo 5 Generalização Modelo de Domínio Taxonomia (1) 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. 2

3 Taxonomia (2) Taxonomia (3) 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. 3

4 Exemplo Taxonomia de polígonos Generalização 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. 4

5 Teoria dos Conjuntos 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. Benefícios 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. 5

6 Regra É-UM 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. Propriedades de uma classe Por propriedades devemos entender: Atributos (variáveis); Operações (métodos); Relações (variáveis). 6

7 Exemplo Regra É-UM Exemplo 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. 7

8 Regra É-UM Comentários 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. Exemplo Pagamento com cartão 8

9 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. Redefinição de operação (1) 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. 9

10 Redefinição de operação (2) 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 - 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. 10

11 Generalização Simples 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. Programa Capítulo 5 Generalização Modelo de Domínio 11

12 Modelo de domínio 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 - Objetivos 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. 12

13 Modelo de domínio - Representação 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. Exemplo 13

14 Benefícios 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. Gap de representação 14

15 Classes conceituais 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. Construção do modelo 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. Um modelo de domínio não é intrinsecamente correto ou errado, mas sim, mais ou menos útil. Ele é uma ferramenta de comunicação. 15

16 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. Atributos vs. Classes 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: 16

17 1º Princípio 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. Exemplo (1) Caso não seja necessário distinguir duas cidades com o mesmo nome, o modelo abaixo será satisfatório. 17

18 Exemplo (2) Caso contrário, a solução a seguir deverá ser a escolhida. Domínio de valores 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? 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. 18

19 2º Princípio 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. Exemplo (1) 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. 19

20 Exemplo (2) 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. Classes de descrição (1) Seja uma concessionária que comercializa automóveis zero Km; Cada automóvel deve ser descrito pelos seguintes atributos: marca, modelo, n o do chassi, preço e cor; O diagrama a seguir ilustra a classe Automóvel: 20

21 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? Solução 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. 21

22 Associações indiretas 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). O atributo coddisciplina foi usado para relacionar uma turma à sua disciplina Solução Estabeleça uma relação explícita entre a classe Turma e a classe Disciplina. 22

23 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. Uso da generalização (1) 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? 23

24 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? Criação de subclasses 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. 24

25 Criação de superclasses 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. Atributo vs. Generalização Qual das duas soluções seria mais adequada para um modelo de domínio? 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 25

26 Artefatos do UP 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. 26

27 Bibliografia Bezerra, E. Princípios de Análise e Projeto de Sistemas com UML. 1ª edição, Campus, Larman, C. Utilizando UML e Padrões. 3ª edição, Bookman,