PRINCÍPIO DE ANÁLISE E PROJETOS DE DE SISTEMAS Bruno R. Rosa Marcelo C. Santos Tiago S. Dos Santos Professora: Flavia Balbino Costa
2 SUMARIO 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 Um Método Para Análise Orientada a Objetos Usando UML
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 Um Método Para Análise Orientada a Objetos Usando UML
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 Um Método Para Análise Orientada a Objetos Usando UML
Modelo Estático das etapas da análise orientada a objetos 5
6 Um Método Para Análise Orientada a Objetos Usando UML
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 Um Método Para Análise Orientada a Objetos Usando UML
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 Um Método Para Análise Orientada a Objetos Usando UML
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 Um Método Para Análise Orientada a Objetos Usando UML
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 Técnicas para Extração de Informações
É 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 Técnicas para Extração de Informações
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 Técnicas para Extração de Informações
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 Lista de Categorias Conceituais
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 Lista de Categorias Conceituais
Itens de transações Papéis de pessoas Outros sistemas ou dispositivos externos Eventos 14
15 Lista de Categorias Conceituais
16 Analise Textual 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 Analise Textual A eficácia da análise textual é relativa, uma vez que sua precisão depende da clareza do texto analisado. 17
18 Atividade 1 – Identificar Classes de Análise
19 Identificar Classes de Análise
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 Identificar Classes de Análise
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 Identificar Classes de Análise
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 Identificar Classes de Análise
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 Atividade 1.1: Extrair Classes Candidatas
Os métodos existentes para extrair as classes candidatas são: Lista de Categorias Conceituais Análise Textual 23
24 Exemplo utilizando Análise Textual
A identificaçã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 definir as ações e operações, será enfatizada a identificação de verbos. 24
25 Exemplo de Caso de Uso 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 Fluxo de Eventos (caminho básico):
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 a	cidade 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
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 Entidades identificadas:
Cliente	Fazer pedido Nome	Endereço Preço de cada produto Sistema Informações de pagamento Estado Códigos do produto	Pendente Devolve as descrições	CPF Calculará os valores	Produto Cartão de crédito	Verifica as informações Cidade	Sistema de conta. e paga. Confirmado	Pedido	Número de pedido	Log-in	Autorização do sistema	Cópias 28
29 Atividade 1.2: Eliminar Classes Inapropriadas
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 Atividade 1.3: Refinar a Lista de Classes Candidatas
Cliente Fazer pedido Nome Endereço Preço de cada produto Sistema Informações de pagamento Estado Códigos do produto Pendente Devolve as descrições CEP Calculará os valores Produto Cartão de crédito Verifica as informações Cidade Sistema de contab. e paga Confirmado Pedido Log-in Número de pedido Autorização do sistema Cópias A classe sistema é uma representação semântica do sistema e em fases posteriores do desenvolvimento poderá ser eliminada. 32
33 Atividade 2 – Atualizar Dicionário de Dados
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 Atualizar Dicionário de Dados
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 Atualizar Dicionário de Dados
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 Atualizar Dicionário de Dados
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 Procedimentos para Uso e Atualização do Dicionário
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 Atualizando Banco de Dados
40 Atividade 3 – Identificar Relacionamento Entre Classe
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 Identificar Relacionamento Entre Classe
Tipos de relacionamento: Associação Agregação Generalização (herança) 41
42 Vejamos o Relacionamento de um Sistema para Automatizar um Consultório Dentário:
43 Atividade 3.1: Identificar Associações
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 Identificar Associações
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 Identificar Associações
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 Associação 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) 0…* (zero ou mais) 1…* (um para muitos) * (muitos)
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…
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 Assim temos a hierarquia bem definida dentro de nossas classes.
(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 Referencial RUBIRA, M.F Cecília. Introdução à Analise Orientada a Objetos e Projeto Arquitetural Disponivel em: ARIADNE. Modelagem Estática.Dísponivel em: 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