Nome: Lucas Alves Martins Rodney Garcia Profª: Flávia Balbino

Apresentação em tema: "Nome: Lucas Alves Martins Rodney Garcia Profª: Flávia Balbino"— Transcrição da apresentação:

1 Nome: Lucas Alves Martins Rodney Garcia Profª: Flávia Balbino
Universidade Castelo Branco Análise e Projeto Nome: Lucas Alves Martins Rodney Garcia Profª: Flávia Balbino

2 Identificar agregações
As hierarquias de agregação, também conhecidas como hierarquias de “parte-todo” entre duas ou mais classes distintas possibilitam representar uma abstração a partir das partes em que a compõem. Além disso, o fato de cada parte poder possuir seus próprios componentes, possibilita uma refatoração recursiva.

3 Identificar agregações
De uma maneira geral, dadas duas classes (A e B), podemos dizer que B agrega A quando: (i) A é uma parte física ou lógica de B; (ii) A está contida em B; (iii) A é um item de uma transação ou relatório B; (iv) A é um membro de B; (v) A é uma sub-unidade organizacional de B; e (vi) A é possuído por B.

4 Identificar agregações
Exemplo:

5 Identificar Herança A identificação de relacionamentos de herança é mais simples do que a de associações. Para encontrar relacionamentos de herança entre as classes de análise identificadas, basta estudá-las e procurar por relações do tipo “é-um-tipo-de” entre elas.

6 Identificar Herança Um exemplo claro no sistema de biblioteca é o relacionamento entre a classe Usuário e as classes Atendente, Aluno e Professor. Além disso, as classes Periódico, Livro, Tese e Manual podem ser consideradas como sub-tipos de Publicação. A relação das classes identificadas para o sistema pode ser identificada a partir do domínio do problema ou do dicionário de dados.

7 Identificar Herança

8 Identificar Herança Após a identificação dos relacionamentos de herança, pode ser necessário refatorar as associações entre as classes. Essa refatoração tem o objetivo principal de mover as associações comuns a todas as classes derivadas (“filhas”) para a classe base (“superclasse”). Além disso, a existência de hierarquias de generalização e especialização bem estruturada possibilitarão outros benefícios ao modelo.

9 Identificar Herança A figura a seguir apresenta o diagrama de classes de análise depois da adição de associações, agregações e relacionamentos de herança. Devido ao excesso de agregações entre a classe Sistema e as demais classes modeladas, essa informação conceitual de composição das partes do sistema pode ser expressada através do conceito de módulo, que pode ser representado por pacotes UML.

10 Identificar Herança

11 Identificar Atributos das Classes de Análise
No último estágio da modelagem estática, são identificados os atributos das classes de análise. Porém, nem todos os atributos precisam ser encontrados durante a análise; é esperado que uma parte deles pertença à solução e por isso devem ser identificadas durante a fase do projeto.

12 Identificar Atributos das Classes de Análise
Os atributos que são identificados durante a fase de análise, ou são inerentes ao domínio da aplicação, ou são aqueles que representam informações relevantes para a realização dos casos de uso, isto é, aqueles que representam informações explicitadas na especificação dos casos de uso. Sendo assim, esses atributos quase sempre estão associados a classes de entidade.

13 Identificar Atributos das Classes de Análise
Essas classes normalmente só precisam ter estado se for necessário guardar informações relativas à interação com um certo usuário, por exemplo informações de seções, utilizadas no caso de vários usuários acessarem o sistema ao mesmo tempo. Mas normalmente esse tipo de informação só é levado em consideração e identificado a partir da fase de projeto.

14 Identificar Atributos das Classes de Análise
A identificação dos atributos é feita de maneira análoga à identificação das classes, isto é, os atributos normalmente são identificados através da análise do domínio e do estudo das especificações dos casos de uso do sistema, do enunciado do problema e do dicionário de dados.

15 Identificar Atributos das Classes de Análise
De uma maneira em geral, eles podem ser identificados a partir das classes candidatas descobertas através da análise textual desses artefatos, mais especificamente, a partir das classes descartadas no refinamento do diagrama de classes de análise.

16 Identificar Atributos das Classes de Análise
Esses atributos normalmente representam conceitos simples que podem ser expressados usando-se tipos primitivos, como inteiros e caracteres. Quando não é o caso, é comum criar novas classes que representam registros de dados, onde cada atributo representa um campo de registro.

17 Identificar Atributos das Classes de Análise
Para enfatizar a sua importância, alguns autores dão a essas classes o estereótipo << datatype >>. Exemplos de classes que normalmente definem tipos de dados são Endereço, Cor, Telefone, Ponto cartesiano, etc.

18 Identificar Atributos das Classes de Análise
De um modo em geral, se um atributo de uma classe é muito complexo, provavelmente ele deveria ser definido como uma classe à parte. Depois, se for necessário, as classes de atributos podem ser facilmente transformadas em atributos na fase de projeto do sistema.

19 Atributos das Classes de Análise no Estudo de Caso
Olhando rapidamente a lista de classes eliminadas a seguir, percebemos que várias delas não se tornaram classes de análise por representarem, na verdade, atributos de outras classes. Além dessas informações, é possível extrair algumas outras examinando a especificação do dicionário de dados e os atributos inerentes ao domínio da aplicação.

20 Atributos das Classes de Análise no Estudo de Caso
*Categorias e Entidades identificadas para o sistema da biblioteca. Classes eliminadas: Exemplar,Bibliotecária, Sistema de cadastro de publicações e usuários, Devolução com atraso, Bloqueio e Desbloqueio.

21 Atributos das Classes de Análise no Estudo de Caso
A tabela a seguir associa os atributos identificados às classes correspondentes:

22 Atributos das Classes de Análise no Estudo de Caso
*Atributos identificados para o sistema de bibliotecas.

23 Atributos das Classes de Análise no Estudo de Caso
Algumas informações foram modificadas para se tornarem mais simples e de acordo com as orientações descritas na imagem anterior. Por exemplo, o período de um empréstimo foi definido através de dois atributos: a data em que o empréstimo foi realizado (data empréstimo) e a data esperada para a devolução data de devolução.

24 Atributos das Classes de Análise no Estudo de Caso
Também podem ser adicionados ao modelo de análise atributos “óbvios”, relativos ao domínio e que não apareceram na descrição dos casos de uso analisados. Deve-se ter cuidado, porém, com a definição do que é ou não inerente ao domínio. Por exemplo, no nosso estudo de caso, é perfeitamente coerente adicionar o atributo “Título” à classe Publicação, já que qualquer publicação tem um título.

25 Atributos das Classes de Análise no Estudo de Caso
Por outro lado, apesar de tentador, não é adequado adicionar um atributo “Autor” a essa classe, já que, entre as publicações com as quais o sistema deve lidar, estão periódicos, publicações para as quais o conceito de autor normalmente não faz sentido.

26 Atributos das Classes de Análise no Estudo de Caso
A figura a seguir apresenta o diagrama de classes de análise depois de adicionados os atributos identificados anteriormente:

27 Atributos das Classes de Análise no Estudo de Caso

28 Identificar Classes de Análise
O processo RUP sugere que classes de análise sejam dividas em três grupos, a fim de classificar os elementos de acordo com o seu papel no modelo. O principal objetivo dessa classificação ́e simplificar a transição da análise para o projeto. Os três grupos definidos são: Classes de entidade Classes de controle Classes de fronteira

29 Classe de Entidade •Representação dos conceitos do domínio do problema
–Informações e regras de negócio que direcionam a manipulação dessas informações • Também chamadas de classes de negócio • A maioria já descoberta na fase de análise • Aspecto importante a analisar: quais geram objetos que devam ser persistentes – Definir o mecanismo de persistência • Prática interessante: – Para ajudar na identificação única de objetos de uma classe, sugere-se a criação de um atributo identificador de implementação (“identificador” ou “id”) do tipo Inteiro “id”) do tipo inteiro • Muito úteis em caso de mapeamento para mecanismos de armazenamento persistente

30 Classes de Fronteira Interação com os elementos externos
– Apresentação de informações –Captação de informação • Classes de fronteira NÃO devem ter responsabilidades relativas as regras de negócio da Aplicação • Exemplo: uma classe para representar um formulário de inscrição em uma escola •Tipos de fronteira: –Classes de interface com o usuário –Classes de interface com equipamentos –Classes de interface com outros sistemas • As formas de interação do sistema com o ambiente influenciam no projeto arquitetural do mesmo

31 Classes de Fronteira •Clientes WEB clássicos
– Representação na forma de classes de páginas WEB estáticas e dinâmicas •Clientes móveis –Classes de fronteira em protocolos específicos •Clientes stand-alone –Janelas, menus, formulários, botões, etc. •Serviços WEB (WEBservices) – Serviços da aplicação disponíveis pela Internet

32 Classes de Fronteira

33 Classes de Controle • Responsáveis por coordenar a interação entre os demais objetos • Normalmente podem haver várias classes de controle em uma aplicação – Uma para cada aspecto da solução • Responsabilidades: – Preenchimento de controles da interface gráfica – Autenticação de usuários – Controle de acesso às funcionalidades do sistema • Tipo comum de classe de controle é o controlador de caso de uso – Coordenar a realização de um caso de uso – Servir de canal de comunicação entre os objetos de – Fronteira e os objetos de entidade

34 Classes de Controle • Mapeando ações dos atores em mensagens para objetos de entidade – Comunicar-se com outros controladores, quando for necessário – Estar apto a manipular exceções • Em uma aplicação WEB é comum o uso de um “front controller” (FC) – Receber as requisições de um cliente – Identificar o controlador adequado para processar a – Redirecionar para o controlador adequado • Características a serem evitadas – Acoplamento excessivo – Repetição de código

35 Relacionamento entre Classes
Os objetos tem relações entre eles: um professor ministra uma disciplina para alunos numa sala, um cliente faz uma reserva de alguns lugares para uma data, etc. Essas relações são representadas também no diagrama de classe. Geralmente as classes não estão sós e se relacionam entre si. O relacionamento e a comunicação entre as classes definem responsabilidades ● E um dos principais diagramas da UML → define o esqueleto do sistema ● Ha tres tipos de relacionamientos entre classes: associação, agregação e generalização

36 Associação ● E o tipo de relacionamento mais comum e mais
importante em um sistema orientado a objetos ● E um relacionamento ou ligacao entre duas classes permitindo que objetos destas possam se comunicar ● Objetivo essencial da associacao: possibilitar a comunicacao entre objetos de duas classes ● A comunicacao pode ser uni ou bidirecional ● Segmento de reta ligando as duas classes ● Associacao unidirecional: inclui-se uma seta na extremidade de destino ● Pode-se incluir um nome na associacao ● Indica a natureza ou finalidade da comunicacao

37 Associação

38 Associação ● Papeis das classes
● Pode-se incluir uma indicacao dos papeis das classes nas associacoes ● Nao e comum indicar o nome da associacao e os papeis das classes para uma mesma associacao → opta-se por uma ou outra

39 Associação

40 Associação ● Cardinalidade
● Especifica o numero de objetos de cada classe envolvidos com a associacao ● Quando nao ha especificacao, entende-se que a ● cardinalidade e 1

41 Associação

42 Associação ● A leitura da cardinalidade exige cuidados:
● Deve-se fazer a leitura de forma distinta para os dois sentidos da associação ● Para cada um dos sentidos: ● Deve-se esquecer a cardinalidade no extremo de inicio ● Deve-se considerar que existe a associação de um objeto da classe de inicio com vários objetos da classe de destino

43 Agregacão ● Relacionamento de pertinência entre classes
● Permite a inclusão de objetos de uma classe no interior de objetos de outra classe ● Relação 'parte-de', 'tem-um', 'todo-parte' ● Objeto que agrega conhece o agregado mas este não conhece aquele → comunicação unidirecional ● Notação UML: segmento de reta ligando a classe dos objetos que agregam a classe dos objetos agregados

44 Agregacão Na extremidade da classe dos objetos que
agregam inclui-se um losango:

45 Agregacão

46 Agregacão ● Cardinalidade ● Numero de objetos envolvidos na relacao
● Um objeto pode incluir varios outros mas nao pode estar contido em mais de um objeto ● i.e. cardinalidade no lado da classe dos objetos que agregam sera sempre 1

47 Associação A leitura da cardinalidade exige cuidados:
● Deve-se fazer a leitura de forma distinta para os dois sentidos da associacao ● Para cada um dos sentidos: ● Deve-se esquecer a cardinalidade no extremo de inicio ● Deve-se considerar que existe a associacao de um objeto da classe de inicio com varios objetos da classe de destino

48 Associação ● Relacionamento de pertinência entre classes
● Permite a inclusão de objetos de uma classe no interior de objetos de outra classe ● Relação 'parte-de', 'tem-um', 'todo-parte' ● Objeto que agrega conhece o agregado mas este não conhece aquele → comunicação unidirecional ● Notação UML: segmento de reta ligando a classe dos objetos que agregam a classe dos objetos agregados

49 Associação Na extremidade da classe dos objetos que
agregam inclui-se um losango:

50 Associação Exemplo: um objeto da classe CCarro contem 4
objetos da classe CRoda e 5 objetos da classe Cporta:

51 Associação

52 Associação ● Não existe uma técnica precisa para de se definir as
agregações em um sistema ● Sugestões: ● definição das agregações a partir de decomposições ● quando uma classe tem muitas responsabilidades, tende-se a dividi-la. Tal divisão pode fazer com que a classe perca sua identidade ● neste contexto, as agregações são muitos uteis porque dividem uma classe grande em outras menores, sem que a grande perca a identidade ● definição das agregações a partir de composições ● raciocinio e o inverso ao da decomposicao ● procura-se identificar conjuntos de objetos que juntos compoem objetos maiores

53 Associação ● definição de agregações a partir de partes comuns
● quando se percebe dentro de duas ou mais classes um conjunto de atributos e/ou métodos semelhantes ● se estes juntos possuem uma identidade, então poderia ser criada uma nova classe:

54 Agregação Definicao de agregacoes a partir de partes comuns

55 Generalização/Especialização de classes
● Relacionamento estrutural entre duas classes ● classe base (superclasse) ● classe base (subclasse) ● Herança (relacionamento 'e um' ● a derivada herda as propriedades da base

56 Generalização/Especialização de classes

57 Padrões de Modelagem Desenvolvedores experientes de sistemas orientados a objetos construíram ao longo dos anos um repertório de soluções para problemas comuns encontrados durante o desenvolvimento. Para serem consideradas como padrões, essas soluções, devem ser validadas através do uso em diversas circunstâncias distintas, especificadas de uma maneira estruturada que descreve tanto a solução quanto o problema que ela se propõe a resolver.

58 Padrões de Modelagem Inicialmente, os padrões surgiram no contexto do projeto arquitetônico, na construção ̃ao civil [1]. Segundo Christopher Alexander, cada padrão descreve um problema que ocorre recorrentemente em nosso ambiente e uma solução para ele, de tal maneira que se pode usar essa solução várias vezes e de diversas maneiras [1]. No desenvolvimento de software, padrões podem ser encontrados em diversas circunstâncias diferentes. Padrões de projeto foram os primeiros a aparecer [19] e não demorou muito para que uma miríade de outros, como padrões arquiteturais [10], análise [18] e de implementação [29] surgissem. Atualmente, padrões de variados tipos são empregados em projetos de desenvolvimento

59 Padrões de Modelagem para tornar os sistemas construídos mais fáceis de entender e manter, além de facilitar a reutilização de suas partes Em geral, um padrão tem quatro elementos fundamentais: 1. Nome do padrão: um identificador que podem ser utilizados para descrever um problema, sua solução e suas consequências em uma ou duas palavras. 2. Problema: uma descrição de quando aplicar o padrão. Ele explica o problema que o padrão Um exemplo de padrão de análise que discutimos neste capítulo foi o padrão

60 Padrões de Modelagem Controlador [29], apresentado como parte do padrão de análise MVC (Seção ). Este padrão consiste em atribuir a uma classe a responsabilidade de tratar os eventos do sistema, sendo responsável por implementar a lógica do negócio. Esse padrão de análise é descrito resumidamente a seguir: Nome: Controlador Problema : definir qual classe implementa as regras do negócio e ́e responsável por lidar com os eventos do sistema. Solução : atribuir essa responsabilidade a uma classe cujo propósito é justamente lidar com esses eventos e implementar as regras de negócios. Essa classe representa a “inteligência” do sistema. Consequências: (i) aumenta o potencial para reutilização, já que separa o controle de outras características do sistema, como a interface com o usuário e a representação dos dados; e (ii) melhorar a manutenibilidade do sistema, uma vez que a rápida localização do controle facilita evolução das regras de negócio

61 Bibliografia www.macoratti.net/net_uml1.htm

62 Bibliografia