A apresentação está carregando. Por favor, espere

A apresentação está carregando. Por favor, espere

Um método para Análise Orientada a Objetos usando UML Técnicas para extração de Informações Atividade 1 - Identificar Classes de Análise Extrair Classes.

Apresentações semelhantes


Apresentação em tema: "Um método para Análise Orientada a Objetos usando UML Técnicas para extração de Informações Atividade 1 - Identificar Classes de Análise Extrair Classes."— Transcrição da apresentação:

1

2 Um método para Análise Orientada a Objetos usando UML Técnicas para extração de Informações Atividade 1 - Identificar Classes de Análise Extrair Classes Candidatas Eliminar Classes Inapropriadas Refinar a Lista de Classes Candidatas Atividade 2 - Atualizar Dicionário de Dados Atividade 3 - Identificar os relacionamentos entre as classes Identificar Associações Referencial 2

3 A análise orientada a objetos cria uma especificação do domínio do problema e dos requisitos do ponto de vista da classificação baseada em objetos e do entendimento dos termos usados no domínio do problema. Os elementos estatísticos e dinâmicos do domínio do problema são modelados na fase de análise. A modelagem estática visa identificar os conceitos do mundo real. Esses conceitos são incluídos em um diagrama de classes de análise, ou modelo conceitual relevantes para o sistema. 3

4 Existem várias metodologias orientadas a objetos, cada uma delas introduz uma característica que permite que o modelo de análise seja criado de uma maneira consistente. As Metodologias mais famosas são: OMT e RUP. As etapas seguidas para realizar a análise orientada a objetos são parecidas, independente da metodologia aplicada. 4

5 Modelo Estático das etapas da análise orientada a objetos 5

6 A UML foi desenvolvida para ser uma linguagem padrão de modelagem. Por causa disto a ela não depende de uma metodologia específica. Qualquer processo de desenvolvimento baseado em UML possui 4 características: Direcionamento por casos de uso Centrado na arquitetura Iterativo Incremental 6

7 Direcionamento por casos de uso: Os casos de uso capturam os requisitos funcionais do sistema. Os casos de uso afetam todas as etapas do desenvolvimento. 7

8 Centrado na arquitetura: A arquitetura de um sistema computacional é formada por sua estrutura, que é composta por hardware e software. Iterativo: Em um processo interativo, sistemas são construídos através de diversas iterações, onde cada uma passa por todas as etapas do desenvolvimento e acrescenta algum elemento ao produto final. 8

9 Incremental: Em um processo iterativo-incremental, cada iteração pode ser usada para construir uma parte do sistema, isto é, um resultado que pode ser testado e avaliado. 9

10 É importante extrair o máximo de informações através de casos de uso, durante a fase de identificação de conceitos importantes para o domínio do problema. Nessa fase inicial de modelagem é importante extrair mais classes de análise do que necessário. Pois é mais fácil tirar classes desnecessárias, do que adicionar classes necessárias no meio do desenvolvimento. (Evitar voltar atras no ciclo de desenvolvimento) 10

11 Uma outra maneira de agilizar o processo de desenvolvimento é identificar claramente os limites do sistema. Dessa forma, é possível excluir do modelo qualquer aspecto que não esteja diretamente relacionado com o problema que o sistema deve resolver. Um usuário ou cliente é tipicamente um objeto que está fora do escopo sistema que estamos tentando construir, a não ser que o sistema precise manter um registro dos seus dados, por exemplo, para controle de acesso. 11

12 Diversas estratégias podem ser empregadas para se obter as informações relevantes para a construção do diagrama de classes de análise a partir de especificações de casos de uso. Principais estratégias Lista de categorias conceituais Análise textual 12

13 Nessa estratégia, classes candidatas podem ser identificadas com o auxílio de uma lista de categorias. Essa lista contém diversas categorias que normalmente devem ser levadas em consideração para a construção de sistemas de software. Principais Categorias: Objetos físicos ou tangíveis Especificações ou descrições de coisas Locais Transações 13

14 Itens de transações Papéis de pessoas Outros sistemas ou dispositivos externos Eventos 14

15 15

16 A análise textual pode ser usada desde os primeiros passos da fase de análise, pois ela é baseada em descrições textuais do problema. Na análise textual, os substantivos identificados correspondem a objetos ou atributos e os verbos correspondem normalmente a associações ou operações. Os adjetivos e indicações de estado (palavras após verbo de ligação) podem indicar a necessidade de um atributo. 16

17 A eficácia da análise textual é relativa, uma vez que sua precisão depende da clareza do texto analisado. 17

18 18

19 O primeiro passo para analisar os requisitos da aplicação é identificar os conceitos relevantes para o sistema que se pretende construir, no contexto do domínio do problema. A atividade de extração dessas entidades consiste basicamente na análise dos casos de uso e dos outros documentos de requisitos do sistema. As informações obtidas da análise, são transformadas em classes, constituindo assim a primeira versão do diagrama de classes de análise. Esse diagrama deve ser revisado até que todos os elementos redundantes ou irrelevantes sejam removidos. 19

20 O diagrama de classes de análise oferece meios para que desenvolvedores e especialistas no domínio (usuários, por exemplo) se comuniquem mais facilmente. As classes de análise ajudam a entender o domínio do problema. O diagrama de classes de análise é uma das maiores fontes de informação para desenvolvedores na fase de projeto. 20

21 Durante a análise, assim como em todas as outras etapas de um processo de desenvolvimento orientado a objetos, não há obrigação de acertar tudo na primeira tentativa. É perfeitamente normal que o analista deixe escapar alguns conceitos relevantes durante a análise e só perceba isso adiante no projeto. Isso ocorre pois o processo de desenvolvimento é iterativo, sendo assim haverá mais do que uma fase de iteração. 21

22 O principal produto da análise orientada a objetos é o diagrama de classes e este é uma descrição dos elementos do domínio do problema no mundo real. 22

23 Os métodos existentes para extrair as classes candidatas são: Lista de Categorias Conceituais Análise Textual 23

24 A identicação de classes candidatas a partir de análise textual consistiu basicamente na procura de substantivos e referências a mudanças de estado nas especificações dos casos de uso do sistema. Posteriormente, para denir as ações e operações, será enfatizada a identicação de verbos. 24

25 Caso de Uso: Fazer Pedido Atore: Cliente Descrição: O caso de uso começa quando o cliente seleciona "fazer pedido". O cliente fornece seu nome e endereço. Se o cliente fornece apenas o CEP, o sistema coloca automaticamente a cidade e o estado. O cliente fornece os códigos do produto. O sistema devolve as descrições e o preço de cada produto. O sistema calculará os valores totais para cada produto fornecido. O cliente fornece as informações sobre cartão de crédito. Em seguida, ele submete os dados ao sistema. O sistema verifica as informações fornecidas, marca o pedido como "pendente" e envia as informações de pagamento para o sistema de contabilidade e pagamento. Quando o pagamento é confirmado, o pedido é marcado como "confirmado" e o número de pedido (NP) é dado ao cliente. 25

26 Pré-condição: O usuário deve ter feito "log-in" e obtido autorização do sistema. Pós-condição: O pedido deve ter sido gravado no sistema e marcado como confirmado. Fluxo de Eventos (caminho básico): 1. O caso de uso começa quando o cliente seleciona "fazer pedido". 2. O cliente fornece seu nome e endereço. 3. Se o cliente fornece apenas o CEP, o sistema coloca automaticamente o acidade e o estado. 4. O cliente fornece os códigos do produto. 5. O sistema devolve as descrições e o preço de cada produto. 6. O sistema calculará os valores totais para cada produto fornecido. 26

27 7. O cliente fornece as informações sobre cartão de crédito. 8. O cliente submete os dados ao sistema. 9. O sistema verifica as informações fornecidas, marca o pedido como "pendente" e envia as informações de pagamento para o sistema de contabilidade e pagamento. 10. Quando o pagamento é confirmado, o pedido é marcado como "confirmado" e o número de pedido (NP) é dado ao cliente. 27

28 ClienteFazer pedido NomeEndereço Preço de cada produto Sistema Informações de pagamento Estado Códigos do produtoPendente Devolve as descriçõesCPF Calculará os valoresProduto Cartão de créditoVerifica as informações CidadeSistema de conta. e paga. ConfirmadoPedido Número de pedidoLog-in Autorização do sistemaCópias 28

29 As principais justificativas para a eliminação de classes candidatas são: (i) itens sinônimos; (ii) itens irrelevantes para o contexto do sistema; (iii) itens que representam atributos de outra classe; e (iv) itens que representam conceitos vagos. Entre as classes candidatas listadas anteriormente, podemos eliminar as seguintes: 29

30 Número de pedido: sinônimo de pedido Pendente: estado do pedido Confirmado: estado do pedido Cidade: atributo de endereço Estado: atributo de endereço CEP: atributo de endereço Fazer pedido: sinônimo de pedido Nome: atributo de cliente 30

31 Códigos do produto: atributo de produto Cartão de crédito: atributo de cliente Sistema de contab. e paga.: sinônimo de sistema Autorização do sistema: atributo de sistema Devolve as descrições: atributo de sistema Informações de pagamento: atributo de sistema Calculará os valores: atributo de sistema Verifica as informações: atributo de sistema 31

32 ClienteFazer pedido NomeEndereço Preço de cada produto Sistema Informações de pagamento Estado Códigos do produtoPendente Devolve as descriçõesCEP Calculará os valoresProduto Cartão de créditoVerifica as informações CidadeSistema de contab. e paga ConfirmadoPedido Log-in Número de pedido Autorização do sistemaCópias A classe sistema é uma representação semântica do sistema e em fases posteriores do desenvolvimento poderá ser eliminada. 32

33 Dicionários de dados são repositórios com metadados sobre bancos de dados, que descrevem a estrutura básica de um esquema de banco de dados. Num dicionário de dados as seguintes informações são armazenadas: Classe Usuário: representa indivíduo que faz o pedido no sistema e recebe notícias sobre a compra efetuada. 33

34 Classe Endereço: representa a classe que recebera informações (dados), que serão armazenados no sistema. Classe Sistema: representa o sistema como um todo e engloba todas as classes identificadas. 34

35 Classe Produto: Representa os produtos que são vendidos pela loja. Classe Pedido: Representa um pedido de produtos feito pelo cliente. Esse classe contem informações sobre o produto e seu status(pendente ou confirmado). 35

36 Classe Log-in: Representa a permissão de entrada no funcionário no sistema. Guarda informações do usuário e seus pedidos. 36

37 A função de compressão de dados emprega um algoritmo na qual a string do caractere lido do DTE (Data Terminal Equipment = Computador) e codificado como uma palavra- código de comprimento fixo. O processo de emprego do dicionário, na qual as strings são armazenados, e que são dinamicamente inseridos durante uma operação normal. A função contém dois dicionários, um contido pela codificação de compressão de dados para uso na compressão de dados recebidos do DTE, e o outro contido pela codificação de compressão de dados para uso na decodificação de dados recebidos da função de controle de erro. 37

38 As funções do dicionário são: a) String "matching", na qual a sequência de caracteres e lida do DTE, e o dicionário procura pelo resultado da string. b) Inserindo, na qual uma nova string e adicionada ao dicionário. c) A deletação de strings pouco usadas para que a capacidade de armazenamento possa ser reutilizada. 38

39 39

40 Neste estágio, realiza-se a identificação de associações, agregações e relacionamentos de herança entre as classes. A identificação das associações e agregações torna clara a responsabilidade de cada objeto e é o primeiro passo em direção à especificação das operações das classes do sistema. A identificação de relacionamentos de herança, por sua vez, promove um melhor particionamento dessas responsabilidades, através do agrupamento das características comuns a alguns subconjuntos de entidades. 40

41 Tipos de relacionamento: Associação Agregação Generalização (herança) 41

42 42

43 Uma associação em UML é um relacionamento estrutural entre objetos. Assim como as classes, associações podem ser identificadas tanto através das características do domínio, quanto analisando-se os documentos de requisitos e as descrições dos elementos do dicionário de dados. 43

44 Alguns critérios que podem ser utilizados para auxiliar na descoberta de associações entre as classes de análise A e B : A é uma parte física ou lógica de B. A está contida em B. A é uma descrição de B. A é um item de uma transação ou relatório B. A é um membro de B. A é uma sub-unidade organizacional de B. A usa ou gerencia B. A se comunica com B. A está relacionada com uma transação B. A é possuído por B. 44

45 Associações em excesso podem deixar o modelo confuso, ao invés de mais claro. Descobrir associações pode ser muito trabalhoso e trazer poucos benef´ıcios concretos. Por isso é aconselhavel não colocar no modelo associações que podem ser derivadas a partir de outras Na etapa de modelagem estática, é mais importante identificar classes do que associações. 45

46 Uma associação deve ter sempre duas pontas, onde uma é o objeto de início e a outra o objeto final. Uma associação pode representar a multiplicidade entre os objetos. Podemos ter as seguintes representações de multiplicidade: 0 (zero) 1 (um) 0…1 (zero ou um) Associação 0…* (zero ou mais) 1…* (um para muitos) * (muitos) 46

47 Exclusiva: Uma associação exclusiva é representada por uma linha tracejada entre as associações, entre elas existe a especificação {ou}. 47

48 Qualificada: As associações qualificadas representam as ligações de 1…* (um para muitos) ou * (muitos). O qualificador identifica no final da associação qual o objeto está identificado. 48

49 Agregação: é um tipo de associação onde o todo está relacionado com suas partes. É representada com o símbolo de um diamante junto à classe agregadora. 49

50 Herança: é um relacionamento pelo qual uma classe, chamada de sub-classe, herda todos comportamentos e estados possíveis de outra classe, chamada de super-classe ou classe base. Não poderemos ter os filhos antes dos pais e antes dos avós. A hierarquia correta para este tipo de classe seria: 50

51 51 ( quando vi esta imagem, não resisti. Serve perfeitamente para o exemplo de hierarquia) Assim temos a hierarquia bem definida dentro de nossas classes. Transformando isso em programação teríamos generalização e especialização.

52 RUBIRA, M.F Cecília. Introdução à Analise Orientada a Objetos e Projeto Arquitetural Disponivel em: cmrubira ARIADNE. Modelagem Estática.Dísponivel em: 3.pdf SEIXAS FILHO, Constantino. UFMG – Departamento de Engenharia Eletrônica Disponível em : STAPLER. 2. Procedimentos para uso e atualização do dicionário Disponível em: 52


Carregar ppt "Um método para Análise Orientada a Objetos usando UML Técnicas para extração de Informações Atividade 1 - Identificar Classes de Análise Extrair Classes."

Apresentações semelhantes


Anúncios Google