Análise e Projeto Orientados a Objetos

Modelagem conceitual do domínio

Diretoria Acadêmica de Gestão e Tecnologia da Informação

Introdução

• A modelagem do domínio está relacionada à descoberta das informações que são gerenciadas pelo sistema. O resultado dessa investigação é expressa no modelo de domínio.– Um modelo pode ser visto como uma representação

idealizada de um sistema a ser construído (e.g, maquetes, plantas de circuitos, plantas arquitetônicas).

– Diagramas UML integram os modelos utilizados em desenvolvimento de software.

– Benefícios do uso de modelos: melhor gerenciamento da complexidade (abstração), melhor comunicação, redução dos custos, predição do comportamento do sistema.

2

Introdução

• Denomina-se domínio do problema, ou apenas domínio, a área de conhecimento específica na qual um determinado sistema de software será desenvolvido.

• Modelo de domínio é uma representação visual de conceitos do domínio do problema. É um dos artefatos mais importantes e mais utilizados em desenvolvimento de software.– Diagramas de classes da UML são amplamente utilizados

para expressar os conceitos do domínio. No entanto, diagramas do tipo entidade-relacionamento também possuem essa mesma aplicabilidade.

3

Introdução

4

Benefícios

• Melhor compreensão do negócio (domínio do problema).

• Estabelecimento de uma comunicação menos ambígua.– Desenvolvedores e pessoas do negócio passam a falar a

mesma língua (menor hiato representacional)

• Abstração: foco nos dados e conceitos que devem ser manipulados pelo sistema e não na solução tecnológica.– Modelos de domínio são utilizados principalmente na

identificação dos dados persistentes, mas podem ser aplicados em outras camadas ou módulos do sistema.

5

Perspectiva conceitual

• Um modelo de domínio é uma descrição de coisas em uma situação real do domínio de interesse, e não de objetos de software.

• O modelo de domínio faz parte da análise, ou seja, da investigação do problema.– Modelo de domínio não é projeto.

• As classes em um diagrama de domínio representam conceitos e não classes de software a serem implementadas em um linguagem de programação.

• Um modelo de domínio também não é um modelo de dados. Portanto, não exclua classes que não serão persistidas mas que possuem significado comportamental no domínio.

6

Perspectiva conceitual

• O modelo de domínio descreve a informação que o sistema deve gerenciar.

– Mas não indica como o sistema a deve gerenciar.

• O modelo de domínio é estático. Então, não devem existir referências a operações ou aspectos dinâmicos do sistema.

– Embora o modelo conceitual seja representando pelo diagrama de classes da UML, o analista não deve ainda adicionar métodos a essas classes.

7

Perspectiva conceitual

• Análise:

• Projeto:

8

Elementos do modelo de domínio

• Atributos: informações alfanuméricas simples, como números, textos, datas, etc.

• Classes ou conceitos: são a representação da informação complexa que agrega atributos e que não pode ser descrita meramente por tipos alfanuméricos.

• Associações: consistem em um tipo de informação que liga diferentes conceitos entre si.

9

Encontrando classes conceituais

• Algumas técnicas:– Revisar modelos existentes.

– Lista de categorias. Larman apresenta um exemplo de lista com 16 categorias que são úteis na identificação inicial.

– Modelagem CRC (classes, responsabilidades e colaboradores). Identifica as classes candidatas a partir de sessões envolvendo especialistas do negócio e desenvolvedores. As classes são registradas em cartões. Bezerra apresenta informações detalhadas sobre este método.

– Análise linguística. Técnica simples e muito difundida. Realizada a partir de descrições textuais do domínio.

10

Análise linguística

• A partir do texto dos casos de uso:

– Passo 1: isole os substantivos e frases nominais.

• Também inclua os verbos relacionados a eventos que possuem informações importantes que devem ser guardadas pelo sistema.

– Passo 2: mantenha aqueles que são importantes para o sistema.

– Passo 3: agrupe os sinônimos.

– Passo 4: diferencie conceitos e atributos.

11

Atributos

• São os tipos escalares.

• NÃO são estruturas de dados como listas, tabelas e arrays.

– Atributos sempre são monovalorados.

• São sempre representados no contexto de uma classe:

12

Tipagem

• Atributos podem ter tipos clássicos como string, inteiro, data, etc., ou tipos primitivos definidos pelo analista:

13

Valores Iniciais

• Atributos podem ser definidos com valores iniciais.

• Valores iniciais são produzidos no atributo no momento que as instâncias da classe correspondente forem criadas.

14

Atributos Derivados

• Seu valor não é armazenado, mas sim calculado ou determinado por alguma regra.

15

Enumerações• São um meio termo entre o conceito e o

atributo.• Uma enumeração é um tipo (classe) que

contém um conjunto pré-definido de valores (instâncias) válidos(as).

16

Características de Enumerações• NÃO podem ter associações com outros

elementos.

• NÃO podem ter atributos.

• Se isso acontecer, então não se trata mais de uma enumeração mas sim de um conceito complexo.

17

Tipos Primitivos• O analista pode e deve definir tipos primitivos

sempre que se deparar com atributos que tenham regras de formação, como no caso em que uma quantidade é composta de valor e unidade.

• Tipos primitivos podem ser classes estereotipadas com <<primitive>>.

18

Associações

• Relacionam dois ou mais conceitos entre si.

19

Papeis

• Correspondem à função que um lado da associação representa em relação aos objetos do lado oposto.

• Múltiplas associações demandam o uso de papeis.

20

Como encontrar associações?

• Procure observar cada conceito complexo e pergunte se a informação representada por ele é completa . Se não for, deve-se criar uma associação entre este conceito e outro(s) conceito(s) de forma a complementar a informação necessária para que o conceito faça sentido.

21

Dependência entre Conceitos

• Conceitos dependentes (como Compra) precisam necessariamente estar ligados aos conceitos que os complementam (como Comprador e Item).

• Informações associativas só podem ser representadas através de associações.

22

Atributos Disfarçando Associações

• Não se deve colocar no modelo conceitual os atributos que representam “chaves estrangeiras”, como se fosse uma tabela de banco de dados relacional.

Pessoa

Automovel

dono: Pessoa

Errado Errado

Pessoa

<<OID>>cpf: CPF

Automovel

cpfDono: CPF

Correto

Pessoa

Automovel

+dono

23

Multiplicidade ou cardinalidade

• Indica quantos objetos podem se associar.• Sempre há um limite inferior.• Pode haver um limite superior.• Considerações de Multiplicidade:

o O papel é obrigatório ou não?―Uma pessoa é obrigada a ter pelo menos um automóvel?―Um automóvel deve obrigatoriamente ter um dono?

o A quantidade de instâncias que podem ser associadas através do papel tem um limite conceitual definido?

―Existe um número máximo ou mínimo de automóveis que uma pessoa pode possuir?

24

Armadilha da Obrigatoriedade

• A toda venda corresponde um pagamento. Mas, dependendo do contexto, isso não torna a associação obrigatória, pois a venda pode existir sem um pagamento. Um dia ela possivelmente será paga, mas ela pode existir sem o pagamento por algum tempo. Então, esse papel não é obrigatório para a venda.

25

Armadilha do Limite Máximo

• O número máximo de automóveis que uma pessoa pode possuir é o número de automóveis que existe no planeta. Mas à medida que outros automóveis venham a ser construídos, esse magnata poderá possuí-los também.

• Embora exista um limite físico, não há um limite lógico para a posse. Então o papel deve ser considerado virtualmente sem limite superior.

26

Exemplo: CDU Comprar Livros

• Fluxo Principal1. [IN] Comprador informa sua

identificação.2. [OUT] Sistema informa os livros

disponíveis para venda (título, capa e preço) e o conteúdo atual do carrinho de compras.

3. [IN] Comprador seleciona os livros que deseja comprar.

4. Comprador decide finalizar a compra.5. [OUT] Sistema informa o valor total dos

livros e apresenta as opções de endereço cadastradas.

6. [IN] Comprador seleciona um endereço para entrega.

7. [OUT] Sistema informa o valor do fretee total geral, bem como a lista de cartões de crédito já cadastrados para pagamento.

8. [IN] Comprador seleciona um cartão de crédito.

9. [OUT] Sistema envia os dados do cartão e valor da venda para a operadora.

10. [IN] Operadora informa o código de autorização.

11. [OUT] Sistema informa o prazo de entrega.

•Fluxo alternativo (4): Comprador decide guardar carrinho

4a.1 [OUT] Sistema informa o prazo em dias em que o carrinho será mantido.

•Fluxo de exceção 6a: Endereço consta como inválido

6a.1 [IN] Comprador atualiza o endereço e caso de uso segue para o passo 6.

•Fluxo de exceção 10a: Operadora não autoriza a venda

10a.1 [OUT] Sistema apresenta outras opções de cartão ao comprador.•10a.2 [IN] Comprador seleciona outro cartão e caso de uso segue para o passo 9.

27

Exemplo: CDU Comprar Livros

28

Exercício

• As informações a seguir se referem a uma aplicação de controle de comanda eletrônica da padaria Doce Sabor de Seu Joaquim.– O cliente utiliza uma comanda eletrônica durante suas

compras na padaria. A cada produto consumido, o atendente registra em sua comanda (que possui uma numeração) o produto e a quantidade. Ao passar no caixa na saída da padaria, a caixa lê os gastos da comanda finalizando a compra. Na leitura da comanda, verifica-se o valor unitário de cada produto a fim de calcular o valor total da compra.

• Faça um diagrama de classes conceituais desse cenário.

29

Herança

• Utilizada para fatorar uma estrutura (atributos e associações) comum a mais de uma classe.

• Instâncias da subclasse também são instâncias das superclasses.

– Associações também são herdadas.

30

Herança

31

Sem herança Com herança

Herança

• Evite o uso da herança quando:

– A superclasse não possuir atributos ou associações.

– As subclasses não possuem atributos ou associações que as diferenciem uma da outra.

32PIOR

MELHOR

Herança e papeis

• Atenção em conceitos que parecem subtipos, mas que na verdade são papeis

– Considere Comprador e Funcionário, ambos com atributos em comum. No caso em que o Funcionário realiza uma compra, ele está assumindo o papel de Comprador.

– Na modelagem com herança seria necessário um novo cadastro de Funcionário quando este realizasse uma compra.

33

Herança e papeis

34

PIOR

MELHOR

XOR (ou exclusivo)

• Indica que apenas uma das associações é possível.

35

Classes modais

• Segundo Wazlawick, são classes utilizadas para modelar conceitos cujas instâncias podem mudar de um estado para outro ao longo de sua existência, possivelmente alterando estrutura, valores de atributos ou comportamento de métodos.

• Wazlawick define três situações relacionadas a modelagem de estados:– Transição estável: diferentes estados não afetam a

estrutura do objeto, apenas os valores de seus atributos.– Transição monotônica: diferentes estados acrescentam

novos atributos ou associações.– Transição não monotônica: diferentes estados

acrescentam, ou removem, atributos ou associações.

36

Transição estável

• Normalmente utiliza um único atributo para determinar o estado de um objeto.

37

Usuário

nome: stringlogin: stringsenha: stringe-mail: stringativo: boolean

Pedido

número: stringemissão: datastatus: StatusPedido

StatusPedido<<enumeration>>

+AGUARDANDO ANÁLISE+AGUARDANDO FATURAMENTO+FATURADO+FINALIZADO+CANCELADO

Usuário somente pode utilizar o sistema caso o

mesmo esteja ativo.

O estado de um pedido é determinado pelo valor do atributo

status.

Transição monotônica

• Geralmente preenche uma associação vazia com uma referência a um objeto contendo dados que surgiram após certo período de tempo

38

Fatura

número: stringvencimento: datavalor: moeda/estado: StatusFatura

Pagamento

data pagamento: datavaor pago: moeda0..11

StatusFatura<<enumeration>>

+PENDENTE+LIQUIDADA

Uma instância de Fatura é criada sem um pagamento associado, por isso a multiplicidade 0..1.

Após a liquidação, é criada uma instância de Pagamento associada à respectiva instância de Fatura. O

estado da fatura é derivado da associação estar vazia ou não.

Transição não monotônica

• Ao mudar de estado, o objeto ganha e/ou perde associações.– Difícil de acontecer visto que é raro um sistema que deseja perder

alguma informação.

• Considere o seguinte contexto de um sistema de reservas de hotel:– Inicialmente, um potencial hóspede faz uma reserva indicando os dias

de chegada e saída, o tipo de quarto e número de pessoas. O hotel lhe informa a tarifa.

– Quando o hóspede faz o check in, é registrado o dia da chegada (que pode ser diferente do dia da reserva). O hotel lhe atribui um quarto, que pode ser diferente do inicialmente reservado. A data de saída prevista continua existindo, embora possa mudar no momento do checkout.

– No checkout deixa de existir a data prevista de saída e é registrada a data de saída de fato. Nesse momento a conta é paga.

39

Transição não monotônica

40

Hóspede

cpfnome

Hospedagem

qtd pessoas: int

EstadoHospedagem

Reserva

chegada prevista: data

AndamentoConcluída

saída: data

PrevisãoDeSaída

previsão: data

Checkin

chegada: data

TipoQuarto

descriçãotarifa

Quarto

número

*1

+estado

11

1

*

1

0..1

1

0..1

1

0..1

1

0..1

1

0..1

1

*

*1

Uma Hospedagem sempre possui um estado, o qual pode ser

Reserva, Andamento ou Concluída. Quando o estado

muda de Reserva para Andamento, a Hospedagem

perde sua associação (indireta) com TipoQuarto e ganha

associações indiretas com Quartoe Checkin. Ao mudar o estado

para Concluída, perde a associação (indireta) com

PrevisãoDeSaída.

Referências

• LARMAN, Craig. Utilizando UML e padrões: uma introdução à análise e ao projeto orientados a objeto e ao desenvolvimento iterativo. Porto Alegre: Bookman, 2007, 3ª ed.

• WAZLAWICK, Raul Sidnei. Análise e Projeto de Sistemas de Informação Orientados a Objetos. Rio de Janeiro: Elsevier, 2011, 2ª ed.

• BEZERRA, Eduardo.Princípios de Análise Projeto de Sistemas com UML. Rio de Janeiro: Campus, 2002.

• MELO, Ana Cristina. Exercitando modelagem em UML. Rio de Janeiro: Brasport, 2006.

41