analise e desenho orientado a objecto · pdf filepassada ao objeto de destino através...
TRANSCRIPT
Eng. de Sw.
• 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.
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.
Metodologia de Desenvolvimento de
Software
• Especificação de Software
• Projeto e Implementação de Software
• Validação de Software
• Evolução de Software
Metodologias (O Ciclo de Vida do
Desenvolvimento de Sistemas)
Metodologias Ágeis
• Extreme Programming (XP)
• Scrum
• Feature Driven Development ( FDD )
Metodologia de Analise e Desenho
Orientado a Objecto
Análise de Sistemas
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.
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.
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
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”.
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
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.
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;
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.
UML – Unified Modeling
Language
Características:• Uma tentativa de padronização das linguagens de modelagem para
ADOO criada a partir da Rational Corporation (http://www.rational.com)e aprovada pela OMG –Object Management Group(http://www.omg.org).
• A UML não é uma metodologia e sim uma linguagem de modelagemque procura integrar as melhores práticas existentes no mercado.
• “É uma linguagem para especificar, visualizar e construir os artefatos desistemas de software...”.
• “É um sistema de notação dirigida à modelagem de sistemas, usandoconceitos 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.
A UML pode ser usada para :
• Mostrar as fronteiras de um sistema e suas funções utilizandoatores 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 utilizandodiagramas de classe
• Modelar o comportamento de objetos através dos diagramas detransição de estado
• Revelar a arquitetura de implementação física com diagramas decomportamento e de implantação
• Entender sua funcionalidade através de estereótipos.
Conceitos Básicos da Orientada a
Objetos
• Conceitos e Princípios
• Objeto
• Encapsulamento
• Mensagens
• Tipos, Classes
• Herança
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
Notação de objeto em UML
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.
A classe Pessoa deverá ter atributos e
métodos comuns
Classe e Objeto
SuperClasse e SubClasse
• Na criação de classe existe a possibilidade de ocorreruma conexão de elementos no modelo Pai / Filho emque uma classe filha ( Subclasse ) herda as propriedadesde seu pai ( superclasse ) direta ou indiretamente.
• Cada classe pode ter suas propriedades particularesherdadas diretamente da classe pai, podendo sersubstituídas ou mascaradas nessa transição. Novaspropriedades poderão ser acrescentadas a classe filha.Todo esse processo narrado acima descreve mais umdos princípios da orientação a objeto:
• Herança.
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.
Exemplo:
Mensagens
• Os objetos se comunicam através de mensagens, isto é, um sinalé enviado a um objeto requisitando um serviço, as operações sãoexecutadas e o resultado da operação é enviado ao objetosolicitante.
• Uma mensagem é a chamada de uma função de um objeto, oacionamento 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 umafunção, enquanto a resposta é passada pelo parâmetro de retornoda função.
• Para que os objetos se comuniquem é necessário que haja algumtipo de ligação / vínculo entre eles. Esses vínculos podem serrelacionamentos entre os objetos.
Polimorfismo
• É a propriedade que o emissor de uma mensagemnão precisa saber a instância da classe que recebeesta mensagem. Essa propriedade leva ao fato deque uma mensagem pode ser interpretada de váriasformas daí o nome Polimorfismo.
• Geralmente as pessoas confundem polimorfismo eencapsulamento porque ambos referem-se aoocultamento da implementação do mundo externoao objeto.
breve descrição dos principais
conceitos da teoria de objetos
Fases do Desenvolvimento de um
Sistema em UML
• Existem cinco fases no desenvolvimento de sistemas desoftware:
• análise de requisitos,
• análise,
• design (projeto),
• programação e
• testes.
• os problemas detectados numa certa fase podem modificar emelhorem as fases desenvolvidas anteriormente de forma queo resultado global gere um produto de alta qualidade eperformance.
Análise de Requisitos
• Esta fase captura as intenções e necessidades dos usuários do sistema aser desenvolvido através do uso de funções chamadas "use-cases".
• Através do desenvolvimento de "use-case“, as entidades externas aosistema que interagem e possuem interesse no sistema são modeladosentre as funções que eles requerem, funções estas chamadas de "use-cases".
• Os atores externos e os "use-cases" são modelados com relacionamentosque possuem comunicação associativa entre eles ou são desmembradosem hierarquia.
• Cada "use-case“ especifica os requerimentos do ator externo queutilizará este "use-case". O diagrama de "use-cases” mostrará o que osatores externos, ou seja, os usuários do futuro sistema deverão esperar doaplicativo, conhecendo toda sua funcionalidade sem importar como estaserá implementada.
Análise
• A fase de análise está preocupada com as primeiras abstrações (classes eobjetos) e mecanismos que estarão presentes no domínio do problema.
• As classes são modeladas e ligadas através de relacionamentos comoutras classes, e são descritas no Diagrama de Classe. As colaboraçõesentre classes também são mostradas neste diagrama para desenvolver os"use-cases" modelados anteriormente, estas colaborações são criadasatravés de modelos dinâmicos em UML.
• Na análise, só serão modeladas classes que pertençam ao domínioprincipal do problema do software, ou seja, classes técnicas quegerenciem banco de dados, interface, comunicação, concorrência eoutros não estarão presentes neste diagrama.
Design (Projeto)
• Na fase de design, o resultado da análise é expandidoem soluções técnicas.
• Novas classes serão adicionadas para prover uma infra-estrutura técnica.
• As classes do domínio do problema modeladas na fasede análise são mescladas nessa nova infra-estruturatécnica tornando possível alterar tanto o domínio doproblema quanto a infra-estrutura.
• O design resulta no detalhamento das especificaçõespara a fase de programação do sistema.
Programação
• Na fase de programação, as classes provenientes do design sãoconvertidas para o código da linguagem orientada a objetos escolhida.
• Dependendo da capacidade da linguagem usada, essa conversão podeser uma tarefa fácil ou muito complicada. No momento da criação demodelos de análise e design em UML, é melhor evitar traduzi-losmentalmente em código.
• Nas fases anteriores, os modelos criados são o significado doentendimento e da estrutura do sistema, então, no momento da geraçãodo código onde o analista conclua antecipadamente sobre modificaçõesem seu conteúdo, seus modelos não estarão mais demonstrando o realperfil do sistema.
• A programação é uma fase separada e distinta onde os modelos criadossão convertidos em código.
Testes
• Um sistema normalmente é rodado em testes de unidade, integração, eaceitação.
• Os testes de unidade são para classes individuais ou grupos de classes esão geralmente testados pelo programador.
• Os testes de integração são aplicados já usando as classes ecomponentes integrados para se confirmar se as classes estão cooperandouma com as outras como especificado nos modelos.
• Os testes de aceitação observam o sistema como uma " caixa preta” everificam se o sistema está funcionando como o especificado nosprimeiros diagramas de "use-cases".
• O sistema será testado pelo usuário final e verificará se os resultadosmostrados estão realmente de acordo com as intenções do usuário final.
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, 2 +
3.5ou 3 * 3.2. Identifique os objetos, seus métodos e
atributos.
• 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.
Principais Digramas:
Requisitos
Requisitos.
Identificação e elicitação de
Requisitos:
Documento (Artefato) desta etapa: “Documento de Visão”
As fases da Identificação/Elicitação de
Requisitos:
Identificação dos Requisitos:
Tipos de Requisitos
Os Requisitos de Software podem ser divididos em duas categorias:
Identificação dos Requisitos:
Análise de Requisitos
Atividades da Análise de Requisitos
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)
Especificação de Requisitos
Especificação de Requisitos
Atividades e Passos:
Diagrama de casos de uso
Casos de Uso
Casos de Uso
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.
Ator
Representação UML (Atores)
Casos de Uso e Fluxo de Eventos:
Tipos de fluxos:
• Fluxo de eventos principal e
• Fluxo alternativo de eventos.
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
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
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
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)
Generalização:
• Podemos usar a
generalização entre casos
de uso, pelo mesmo
motivo que utilizamos
nas classes, para
compartilhar
comportamento:
Generalização entre atores
Extends:
Include:
Explicando o estereotipo
“include”
É 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.
Associação
Ator x Ator
Ator x Caso
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.
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.
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.
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
• ...
...
• 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