Analise e Desenho Orientado a Objecto. Msc. Eng. Beldo A. J. Mário

Transcrição

1 Analise e Desenho Orientado a Objecto Msc. Eng. Beldo A. J. Mário /Bmario@ucm.ac.mz

2 Eng. de Sw.

3 Métodos: proporcionam os detalhes de "como fazer"para construir o software. Ferramentas: fornecem suporte automatizado ou semi-automatizados aos métodos. Processos: é a fundação da engenharia de software, provendo a sustentação e relacionamentos entre as camadas Foco na qualidade: garante toda qualidade do software gerado.

4 Modelos de Processo Uma linguagem de modelagem não é suficiente precisamos também de um processo de desenvolvimento Linguagem de modelagem + processo de desenvolvimento = método (ou metodologia) de desenvolvimento.

5 Metodologia de Desenvolvimento de Software Especificação de Software Projeto e Implementação de Software Validação de Software Evolução de Software

6 Metodologias (O Ciclo de Vida do Desenvolvimento de Sistemas)

7 Metodologias Ágeis Extreme Programming (XP) Scrum Feature Driven Development ( FDD )

8 Metodologia de Analise e Desenho Orientado a Objecto

9 Análise de Sistemas

10 Objetivos Básicos: Desenvolver a especificação lógica, independente do Software e Hardware utilizado. Elaborar um Modelo de Sistema (Ex: Planta de uma Casa) Analisar as características importantes ao sistema, tais como, levantamento dos dados, processos e informações que usuário necessita. Documentar o processo de análise, para que se tenha uma fidelidade no momento da construção do Software por parte dos projetistas e Desenvolvedores.

11 Analise Orientado a Objecto A AOO é formada por um conjunto de objetos que interagem entre si, apresentam características próprias representadas pelos atributos e operações. A Análise Tradicional baseia-se na idéia que um sistema é um conjunto de programas que executam processos sobre os dados.

12 Motivos que Levaram ao surgimento da AOO Dificuldade de resolver problemas complexos com o uso das análises tradicionais Surgimento de linguagens de Programação Orientada a Objetos (C++) Necessidade de Desenvolvimento de sistemas baseado em Real Time com muito mais freqüência

13 Justificativa de Mudança Objetos já existem na natureza antes de haver qualquer tipo de aplicação deles pelo negócio: Equipamentos, pessoas, minerais, etc..., existem por si só, apresentam características representadas por seus atributos e, adiante, pelo seu comportamento no mundo real.

14 Problemas da Análise e Projeto Orientado a objetos Fundamentação teórica da AOO não é simples Os SGBDs ainda não são totalmente orientado a objetos A mudança de mentalidade e introdução de uma nova tecnologia sempre traz receio Existência de várias abordagens para APOO

15 UML Unified Modeling Language ou Linguagem de Modelagem Unificada é uma linguagem visual utilizada para modelar softwares baseados no paradigma de orientação a objetos. a UML não é uma linguagem de programação, e sim uma linguagem de modelagem podendo ser utilizada por muitos processos de desenvolvimento diferentes ou mesmo da forma que o analista considerar mais adequada.

16 Histórico da UML Nos anos 90, conhecida como a época da guerra dos métodos, vários métodos coexistiam com notações muitas vezes conflitantes entre si. Dentre estes, os mais conhecidos eram: OMT (Object Modelling Technique) de Rumbaugh; Método de Booch; OOSE (Object Oriented Software Engineering) de Jacobson;

17 A importância da Modelagem A modelagem consiste em construir um modelo visando reduzir a incerteza do Software, aproximando-se ao máximo a expectativa da realização. A modelagem Orientada a Objetos tem como objetivo: Padronizar, automatizar, incentivar a reutilização de componentes e aumentar a maturidade em uma equipe de desenvolvimento de um projeto.

18 UML Unified Modeling Language Características: Uma tentativa de padronização das linguagens de modelagem para ADOO criada a partir da Rational Corporation ( e aprovada pela OMG Object Management Group ( A UML não é uma metodologia e sim uma linguagem de modelagem que procura integrar as melhores práticas existentes no mercado. É uma linguagem para especificar, visualizar e construir os artefatos de sistemas de software.... É um sistema de notação dirigida à modelagem de sistemas, usando conceitos orientados a objetos. Tem se tornado um padrão mundial utilizado por desenvolvedores, autores e fornecedores de ferramentas CASE. É independente de linguagens de programação OO.

19 A UML pode ser usada para : Mostrar as fronteiras de um sistema e suas funções utilizando atores e casos de uso Ilustrar a realização de casos de usos com diagramas de interação Representar uma estrutura estática de um sistema utilizando diagramas de classe Modelar o comportamento de objetos através dos diagramas de transição de estado Revelar a arquitetura de implementação física com diagramas de comportamento e de implantação Entender sua funcionalidade através de estereótipos.

20 Conceitos Básicos da Orientada a Objetos Conceitos e Princípios Objeto Encapsulamento Mensagens Tipos, Classes Herança

21 Objeto um dos principais elementos AOO é o próprio objeto. Um objeto nada mais é que uma ocorrência específica de uma classe e é similar a uma entidade no modelo entidade / relacionamento até no ponto que uma coleção de dados une-se para formar um tema em comum. Um objeto pode ser: Concreto ou abstrato

22 Notação de objeto em UML

23 Classe É uma coleção de objetos que podem ser descritos com os mesmos atributos e as mesmas operações. Representam uma idéia ou um conceito simples e categoriza objetos que possuem propriedades similares. Todos os objetos de uma classe possuem as mesmas definições, mas podem possuir valores diferentes nos dados, respondendo de modo diferente as mensagens enviadas.

24 A classe Pessoa deverá ter atributos e métodos comuns

25 Classe e Objeto

26 SuperClasse e SubClasse Na criação de classe existe a possibilidade de ocorrer uma conexão de elementos no modelo Pai / Filho em que uma classe filha ( Subclasse ) herda as propriedades de seu pai ( superclasse ) direta ou indiretamente. Cada classe pode ter suas propriedades particulares herdadas diretamente da classe pai, podendo ser substituídas ou mascaradas nessa transição. Novas propriedades poderão ser acrescentadas a classe filha. Todo esse processo narrado acima descreve mais um dos princípios da orientação a objeto: Herança.

27 Herança É a capacidade de um novo objeto tomar atributos e operações de um objeto existente, permitindo criar classes complexas sem ter que repetir o código. Se uma classe herda comportamento e atributos de mais de uma classe damos a ela o nome de herança múltipla, uma variação semântica de generalização, na qual um tipo pode ter mais de um supertipo.

28 Exemplo:

29 Mensagens Os objetos se comunicam através de mensagens, isto é, um sinal é enviado a um objeto requisitando um serviço, as operações são executadas e o resultado da operação é enviado ao objeto solicitante. Uma mensagem é a chamada de uma função de um objeto, o acionamento de uma operação encapsulada no objeto de destino, feita a partir do objeto de origem. A informação transmitida é passada ao objeto de destino através dos parâmetros de uma função, enquanto a resposta é passada pelo parâmetro de retorno da função. Para que os objetos se comuniquem é necessário que haja algum tipo de ligação / vínculo entre eles. Esses vínculos podem ser relacionamentos entre os objetos.

30 Polimorfismo É a propriedade que o emissor de uma mensagem não precisa saber a instância da classe que recebe esta mensagem. Essa propriedade leva ao fato de que uma mensagem pode ser interpretada de várias formas daí o nome Polimorfismo. Geralmente as pessoas confundem polimorfismo e encapsulamento porque ambos referem-se ao ocultamento da implementação do mundo externo ao objeto.

31 breve descrição dos principais conceitos da teoria de objetos

32

33 Fases do Desenvolvimento de um Sistema em UML Existem cinco fases no desenvolvimento de sistemas de software: análise de requisitos, análise, design (projeto), programação e testes. os problemas detectados numa certa fase podem modificar e melhorem as fases desenvolvidas anteriormente de forma que o resultado global gere um produto de alta qualidade e performance.

34 Análise de Requisitos Esta fase captura as intenções e necessidades dos usuários do sistema a ser desenvolvido através do uso de funções chamadas "use-cases". Através do desenvolvimento de "use-case, as entidades externas ao sistema que interagem e possuem interesse no sistema são modelados entre as funções que eles requerem, funções estas chamadas de "usecases". Os atores externos e os "use-cases" são modelados com relacionamentos que possuem comunicação associativa entre eles ou são desmembrados em hierarquia. Cada "use-case especifica os requerimentos do ator externo que utilizará este "use-case". O diagrama de "use-cases mostrará o que os atores externos, ou seja, os usuários do futuro sistema deverão esperar do aplicativo, conhecendo toda sua funcionalidade sem importar como esta será implementada.

35 Análise A fase de análise está preocupada com as primeiras abstrações (classes e objetos) e mecanismos que estarão presentes no domínio do problema. As classes são modeladas e ligadas através de relacionamentos com outras classes, e são descritas no Diagrama de Classe. As colaborações entre classes também são mostradas neste diagrama para desenvolver os "use-cases" modelados anteriormente, estas colaborações são criadas através de modelos dinâmicos em UML. Na análise, só serão modeladas classes que pertençam ao domínio principal do problema do software, ou seja, classes técnicas que gerenciem banco de dados, interface, comunicação, concorrência e outros não estarão presentes neste diagrama.

36 Design (Projeto) Na fase de design, o resultado da análise é expandido em soluções técnicas. Novas classes serão adicionadas para prover uma infraestrutura técnica. As classes do domínio do problema modeladas na fase de análise são mescladas nessa nova infra-estrutura técnica tornando possível alterar tanto o domínio do problema quanto a infra-estrutura. O design resulta no detalhamento das especificações para a fase de programação do sistema.

37 Programação Na fase de programação, as classes provenientes do design são convertidas para o código da linguagem orientada a objetos escolhida. Dependendo da capacidade da linguagem usada, essa conversão pode ser uma tarefa fácil ou muito complicada. No momento da criação de modelos de análise e design em UML, é melhor evitar traduzi-los mentalmente em código. Nas fases anteriores, os modelos criados são o significado do entendimento e da estrutura do sistema, então, no momento da geração do código onde o analista conclua antecipadamente sobre modificações em seu conteúdo, seus modelos não estarão mais demonstrando o real perfil do sistema. A programação é uma fase separada e distinta onde os modelos criados são convertidos em código.

38 Testes Um sistema normalmente é rodado em testes de unidade, integração, e aceitação. Os testes de unidade são para classes individuais ou grupos de classes e são geralmente testados pelo programador. Os testes de integração são aplicados já usando as classes e componentes integrados para se confirmar se as classes estão cooperando uma com as outras como especificado nos modelos. Os testes de aceitação observam o sistema como uma " caixa preta e verificam se o sistema está funcionando como o especificado nos primeiros diagramas de "use-cases". O sistema será testado pelo usuário final e verificará se os resultados mostrados estão realmente de acordo com as intenções do usuário final.

39 EXERCÍCIOS 1. Um usuário deseja uma calculadora que efetue as quatro operações básicas. As expressões permitidas envolvem apenas dois números, por exemplo, ou 3 * 3.2. Identifique os objetos, seus métodos e atributos.

40 2. Seguindo a abordagem de orientação a objetos, identificar no enunciado abaixo os objetos e usuários do sistema. Liste os nomes dos objetos, seus atributos e os usuários do sistema. UMA LOCADORA de veículos necessita de um sistema para facilitar o atendimento a seus clientes. Os carros são classificados por tipo: popular, luxo e utilitário. As informações que interessam à locadora sobre cada um dos veículos são: placa do carro, tipo e valor diário do aluguel. Os funcionários da locadora são responsáveis pelo cadastro dos clientes e dos veículos. Eles também fazem as locações e encerram as mesmas. Há clientes especiais e comuns. Os especiais têm direito a uma taxa de desconto e um valor de quilometragem extra nas suas locações. Um cliente é identificado pelo nome, número do cartão de crédito e data de expiração.

41 Principais Digramas:

42 Requisitos

43 Requisitos.

44 Identificação e elicitação de Requisitos: Documento (Artefato) desta etapa: Documento de Visão

45 As fases da Identificação/Elicitação de Requisitos:

46 Identificação dos Requisitos: Tipos de Requisitos Os Requisitos de Software podem ser divididos em duas categorias:

47 Identificação dos Requisitos:

48 Análise de Requisitos

49 Atividades da Análise de Requisitos

50 Análise de Requisitos. Classificar Classificacao de Requisitos Não Funcionais: Performance: Tempo de resposta Segurança: Uso de senhas, certificados digitais e etc.. Usabilidade: Identidade Visual e Interfaces amigáveis Disponibilidade: O software deve estar disponível para usuário 24x7. Exemplo: Tolerância a falha Flexibilidade: Capacidade de adaptação quando um requisito muda Portabilidade: Capacidade de se adaptar a outros ambientes (sistemas operacionais) Escalabilidade: Capacidade de responder aumento de carga (novos usuários)

51

52 Especificação de Requisitos

53 Especificação de Requisitos

54 Atividades e Passos:

55 Diagrama de casos de uso

56 Casos de Uso

57 Casos de Uso

58 Casos de Uso e Cenários: Os casos de uso exibem a funcionalidade na perspectiva do usuário. Entretanto, podemos ter vários caminhos para completar esta função. Um cenários é como uma instance do Caso de uso, isto é, um caminho lógico com início e fim.

59 Ator

60 Representação UML (Atores)

61 Casos de Uso e Fluxo de Eventos: Tipos de fluxos: Fluxo de eventos principal e Fluxo alternativo de eventos.

62 Fluxo de Eventos (1) Especifica o comportamento de um caso de uso E uma sequencia de comandos declarativos que descreve as etapas de execucao de um Caso de Uso Permanece focado no domınio do problema e nao em sua solucao Pode conter testes condicionais e iteracoes Contem informacoes relativas: As condicoes de inıcio e termino do caso de uso Quais os atores interessados no sistema Como o caso de uso interage com esses atores

63 O fluxo de eventos de um caso de uso e composto por: Um Fluxo Basico - descreve a funcionalidade principal do caso de uso, quando nenhum desvio e tomado Zero ou Mais Fluxos Alternativos- descrevem desvios pre-definidos do fluxo basico Esses fluxos podem ser especificados atraves de: Descricao textual informal Texto semi-formal (atraves de pre-pos-condicoes e invariantes) Pseudocodigo Ou uma combinacao dessas maneiras

64 Fluxo Basico de Eventos Descrito em pseudocodigo: 1. O cliente chega ao ponto de vendas com os produtos da compra 2. para cada( produto trazido pelo cliente): (a) O atendente registra o codigo e a quantidade do produto (b) O sistema determina o preco do produto e o adiciona `a compra 3. O atendente indica que a lista de produtos est a completa 4. O sistema calcula e apresenta o total 5. O atendente informa o cliente sobre o total da compra e pergunta qual e a forma de pagamento 6. se(dinheiro) forma de pagamento = dinheiro 7. O atendente registra a quantia recebida 8. O sistema mostra o troco e gera o recibo 9. O atendente deposita o dinheiro, devolve o troco e entrega o recibo da compra 10. O sistema registra o final da transacao

65 Casos de Uso. Relacionamentos Organização dos Casos de Uso: Os casos de uso também podem ser organizados pela especificação de relacionamento de generalização, inclusão e extensão, existentes entre eles. Esses podem ser aplicados com a finalidade de fatorar o comportamento comum (obtendo esse comportamento a partir de outros casos de uso que ele inclui) e fatorar variantes (obtendo esse comportamento em outros casos de uso que o estendem)

66 Podemos usar a generalização entre casos de uso, pelo mesmo motivo que utilizamos nas classes, para compartilhar comportamento: Generalização:

67 Generalização entre atores

68 Extends:

69 Include:

70 Explicando o estereotipo include

71 É importante ressaltar que: um caso de uso nunca deve ser incluído apenas por um caso, ou seja, não utilizar <<include>> para decompor o diagrama em partes; um caso de uso que é incluído por vários outros não tem conhecimento sobre quem o inclui, portanto, podem ser incluídos por qualquer caso sem sofrer modificações; não utilizar a relação de inclusão para representar opções de menu, pois o caso que faz a inclusão seria um simples despachante, todo o comportamento estaria fragmentado nos casos incluídos. Enfim, inclusão deve ser utilizada para administrar comportamentos comuns e não para estruturar funcionalmente o diagrama.

72 Associação Ator x Ator

73 Ator x Caso

74

75 Descricao: Sistema de Ponto de Vendas principais Requisitos: Registrar os ıtens vendidos em cada venda. Calcular o total de uma venda. Obter e apresentar as informacoes sobre cada produto mediante a leitura de seu codigo de barras. Reportar ao estoque os dados dos produtos vendidos. Registrar cada venda completada com sucesso. Exigir senha pessoal para operar o sistema. Receber pagamentos em dinheiro ou cartao. Emitir mensalmente o balanco do estoque.

76 Exercıcio (PDV) Classifica c ao dos Requisitos - (F/NF): Registrar os ıtens vendidos em cada venda. Calcular o total de uma venda. Obter e apresentar as informa c oes sobre cada produto mediante a leitura de seu c odigo de barras. Reportar ao estoque os produtos vendidos. Registrar cada venda completada com sucesso. Exigir senha pessoal para operar o sistema. Receber pagamentos em dinheiro ou cart ao. Emitir mensalmente o balan co do estoque.

77 Exemplo (Caso de Uso) Caso De Uso: Comprar Produtos Atores: Cliente, Atendente Descricao: Um cliente chega ao ponto de vendas para comprar produtos. O atendente registra a compra e coleta o pagamento. O cliente vai embora com a compra.

78 Exemplo (Fluxo Basico de Eventos) Descrito em pseudocodigo: 1. O cliente chega ao ponto de vendas com os produtos da compra 2. para cada ( produto trazido pelo cliente): (a) O atendente registra o codigo e a quantidade do produto (b) O sistema determina o preco do produto e o adiciona `a compra 3. O atendente indica que a lista de produtos esta completa 4. O sistema calcula e apresenta o total...

79 O atendente informa o cliente sobre o total da compra e pergunta qual e a forma de pagamento 6. se (dinheiro) forma de pagamento = dinheiro 7. O atendente registra a quantia recebida 8. O sistema mostra o troco e gera o recibo 9. O atendente deposita o dinheiro, devolve o troco e entrega o recibo da compra 10. O sistema registra o final da transacao