Aula 1 - POO

Prévia do material em texto

Programação Orientada a Objeto
Programa
Programas são operações sobre dados
Quanto maior a capacidade computacional maior a complexidade
Por que OO?
Grande complexidade dos sistemas
Ciclo de vida;
Pouco provável que um único indivíduo entenda toda a complexidade do sistema;
 A complexidade pode ser gerenciada não eliminada.
Ter o domínio do problema é difícil, tornando necessário pensar na evolução do sistema
Por que OO?
Modelagem OO
Conhecemos e gerenciamos as complexidades do mundo através de objetos
Desenvolvemos o conceito de OBJETO desde criança,
Faz parte da nossa cognição
Exemplo
Bola, carro, camisa, casa, boneca, música,...
Desenvolvimento
Análise, defina o que vai ser feito
Projete, definindo com será feito
Implemente, escreva o código em uma linguagem de programação da sua escolha
Diferentes pontos de vista para a criação de software, com isso a grande importância da documentação
Com isso !!!
Engenharia de Software
Lucilvan Freitas
O que é?
Engenharia de Software é uma estratégia sistemática, disciplinada e quantificável para a Programação
Envolve o desenvolvimento, operação e manutenção do software.
Existe durante toda a vida do software, mas focada durante seu desenvolvimento
Engenharia de Software Abrange
Planejamento
Especificação
Desenho
Implementação
Validação
Teste
Medição
Manutenção
Aprimoramento
Engenharia de Software Visa
Otimizar sempre o desempenho
Desenvolvimento de software
De alta qualidade
De forma prática, ordenada e medida.
Satisfatórios dentro dos prazos e orçamentos
Robustez do Sistema
Facilitar a manutenção
Permitir o crescimento do sistema
Engenharia de Software
“Conjunto total de atividades necessárias para transformar os requisitos de um usuário em software” ES James página 1, 5º parágrafo
Requisitos
Eng. de Software
Software
Engenheiro de Software
É um programador ?
Contato com o futuro usuário e cliente
Escreve formalmente as necessidades do usuário (requisitos)
Escreve formalmente o que deve ser feito para construir o futuro software
Produção do Software
Descreve estratégias de teste, durante o desenvolvimento e após a implantação no ambiente do cliente
Engenharia de Software
As técnicas são baseadas, com isso muito se assemelham, as utilizadas por engenheiros no desenvolvimento de automóveis, prédios etc
Alguns conceitos mais diretamente dizem respeito à Administração empresarial do que à Ciência da Computação
Engenharia de Software
Em áreas tradicionais de engenharia, 2 % de tolerância pode ser considerado aceitável
Num sistema contábil, por exemplo, que apresente uma precisão de 2% não é aceitável
Engenharia de Software
Ferramentas de Desenvolvimento
DFD (Diagrama de Fluxo de Dados)
Diagrama Entidade/Relacionamento
Dicionário de Dados
Astah (Judi)
Documentação
Diagramas de Caso de Uso
Diagrama de Sequência
Diagrama de Classe
Diagrama de Classe
Diagrama de Caso de Uso
Diagrama de Sequência
Engenharia de Software
“É a aplicação dos princípios científicos, métodos, modelos, padrões e teorias que possibilitem gerenciar, planejar, modelar, projetar, implementar, medir, analisar, manter e aprimorar um sistema de software”.
Resulta numa produção econômica de software de qualidade.
Processos
Diferentes formas de orientar o desenvolvimento do sistema
Seminário
Processos
Scrum
RUP
XP
ICONIX
Crystal
Modelagem de Processos de Software
Teste de Software e suas ferramentas
Início
Analise de Requisitos
Requisitos
São capacidades e condições às quais o sistema – e em termos mais amplos, o projeto – deve atender [Larmam];
Funções do sistema;
Classificados como funcionais e não-funcionais;
Analise de Requisitos
Requisitos Funcional 
Descreve a funcionalidade ou o serviço do sistema
Descreve “O que?” será feito
Requisitos Não-Funcional 
Definem a arquitetura do sistema
Descreve “Como?” será feito
Visam aspectos como: usabilidade, desempenho, confiabilidade, segurança, implementação, entre outros.
Requisitos Não-Funcionais
Exemplos
Integração: Integra-se com outro o sistema
Legais: Deverá atender normas legais, tais como padrões e leis
Eficiência: Deverá processar um número indeterminado de requisitos por um determinado tempo
Confiabilidade: Deverá ter politica de segurança de dados
Padrões: Uso de POO na plataforma J2SE
Interoperabilidade: O sistema deverá se comunicar com o SQL Server
Entrega: Deverá ser entregue um relatório de acompanhamento semanalmente
Levantamento de Requisitos
Atividade fundamental no entendimento e desenvolvimento de Software;
Captura os requisitos sobre a visão do usuário;
Erros na fase de Levantamento de Requisitos, acarretam problemas em todas as outras fases
Requisitos Globais
Requisitos gerais de criação do sistema
Definidos em reunião interna
Definição da tecnologia, plataformas, servidores, etc
Dificuldades no Levantamento de Requisitos
Cliente não saber de fato o que o sistema deverá fazer;
Cliente ter dificuldade de explicar o problema em questão;
Cliente e Analista ter pontos de vistas diferentes sobre o problema;
Resistencia dos usuários a novidades;
Falta de conhecimento por parte dos usuários;
Problema a ser Solucionado
Contexto do negócio
Necessidades e Restrições do Cliente
Domínio da Aplicação
Atividades para o levantamento dos Requisitos
Entendimento do domínio da aplicação
É o conhecimento geral onde o sistema será aplicado
Entendimento do problema
Os detalhes problema do cliente onde o sistema será aplicado devem ser entendidos
Entendimento do negócio
Deve-se entender como os sistemas interagem e contribuem de forma geral com os objetivos de negócio.
Entendimento das necessidades e limitações dos stakeholders do sistema
Deve-se entender, em detalhe, as necessidades específicas das pessoas que requerem suporte do sistema no seu trabalho.
É necessário entender a língua do usuário
89
Técnicas para o levantamento dos Requisitos
Entrevistas e questionários;
Workshop de requisitos;
Cenários;
Prototipagem;
Estudo etnográfico.
Entrevistas
A entrevista é o momento inicial para conversar com os “stakeholders”, ou seja, as pessoas que vão te ajudar no desenvolvimento do sistema.
Stakeholders: patrocinadores, proprietários, usuários de muitas ou poucas permissões, estoquistas, funcionários etc.
Entrevistas
Em um momento inicial, não é necessário sugerir muito, mas sim ouvir o cliente e extrair as informações
Inicialmente fazer as perguntas de contexto-livre e após, as perguntas centradas na solução
Entrevistas
Prepare uma entrevista de contexto livre apropriada
Antes da entrevista faça uma pesquisa ao background do stakeholder e da empresa a serem entrevistados. 
Anote as respostas no seu bloco de notas durante a entrevista. (Não tente capturar a informação de forma electrónica nesta fase!)
Consulte as notas da estrutura da entrevista no decorrer da mesma. 
Discuta os problemas com o utilizador. Esclareça situações que possa observar no ambiente. Faça sugestões e observações baseadas em conhecimento teórico e familiarização com outros sistemas.
Entrevistas
Perguntas de Contexto-livre
Quem são os utilizadores?
Quem é o cliente?
Têm necessidades diferentes?
Onde podem ser encontradas outras soluções para este problema?
Qual o problema em foco?
Entrevistas
Perguntas Centradas na solução
(Apresentar as capacidade gerais de uma solução) E se pudesse fazer … e …?
Como classificaria a importância de cada uma das funcionalidades apresentadas?
Saiba como o cliente deseja o sistema!
Entrevistas
Fatores condicionantes:
Influência do entrevistador sobre o entrevistado
Relação pessoal entre os intervenientes
Predisposição do entrevistado
Capacidade de seguir um plano na entrevista
Entrevistas
Mais Informações
http://pontogp.wordpress.com/2007/04/05/como-entrevistar-o-patrocinador-do-projeto/ 
http://pt.wikipedia.org/wiki/Entrevistas_a_stakeholders 
Atividade
Reúnam-se em duplas
Um será o cliente e o outro o desenvolvedor
Entrevista:
3 minutos prévios para preparação
5minutos de entrevista
10 min para processar as informações obtidas
O desenvolvedor criará uma lista de requisitos e soluções propostas
O cliente fará um relatório do que achou do entrevistador
Enviar imediatamente para lucilvan@hotmail.com
Atividade
Crie uma lista com os requisitos funcionais e não funcionais do seu projeto final
89
Entrevistas
Reunião estruturada com o objetivo de obter um conjunto de requisitos bem definidos;
Integrantes: analistas e representantes do cliente
Interação entre todos os presentes;
Momentos de descontração;
Conduzido por um facilitador que promove a discussão entre os integrantes;
Decisões são tomadas de acordo com processos bem definidos;
Produz documentação que reflete os requisitos e decisões tomadas.
Cenários
Cenários são estórias que explicam como um sistema poderá ser usado. Eles devem incluir:
uma descrição do estado do sistema antes de começar o cenário
o fluxo normal de eventos do cenário
exceções ao fluxo normal de eventos
informações sobre atividades concorrentes
uma descrição do estado do sistema ao final do cenário
Cenários são exemplos de sessões de interação que descrevem como o usuário interage com o sistema
A descoberta de cenários expõe interações possíveis do sistema e revela as facilidades que o sistema pode precisar
Prototipagem
Um protótipo é uma versão inicial de um sistema que poderá ser usado para experimentação;
Protótipos são úteis para elicitação de requisitos porque os usuários poderão experimentar o “sistema” e mostrar os pontes fortes e fracos. Eles terão algo concreto para criticar;
O desenvolvimento rápido dos protótipos é essencial para que eles fiquem disponíveis logo para o processo de elicitação ;
Deve-se observar a relação custo-benefício de construção dos protótipos.
Estudo etnográfico
Análise social das tarefas desempenhadas numa organização;
Capaz de obter requisitos que não seriam observáveis através de outras técnicas;
Capaz de obter processos reais de trabalho;
Baseada em observação direta do desempenho das atividades das pessoas.
Documento de Software
Serve para:
Melhor entendimento dos requisitos do Sistema
Divisão de tarefas dentro da equipe
Quando Será feito
Prazos a serem seguidos
O que será feito?
Documentação
Documento de Visão
Documento de Risco
Plano de Projeto
Documento de Visão
Visão geral que os desenvolvedores tem do sistema
É um dos documento mais completos que tem todas as informações para os membros da equipe sobre o cliente e sobre o que será feito.
Clientes
Stakeholders
Escopo do Sistema
Casos de Uso
Diagramas
Modelo
Documento de Risco
Enumeração dos Riscos que o software tem de não dar certo
Devemos prever desde a doença dos membros, até mesmo a tecnologia imprópria
Apresentação de solução para minimizar os impactos desde risco
Contornar o risco
Desistir, e não correr o risco
Assumir o risco
Modelo???????????????
Plano de Projeto
Documento que pode ser entregue ao cliente
Lista as fases de desenvolvimento, prazos e o que será feito em cada uma delas
Modelo????????????
Atividade
Com base nos requisitos levantados na atividade anterior e com os modelos mostrados anteriormente inicie a criação dos documentos mencionados para o possível sistema
Atividade
Inicia a criação da documentação do seu projeto final
UML 
Unified Modeling Language
Lucilvan Freitas
UML
O que é?
É um modelo de linguagem adotado pela indústria de Engenharia de Software
É um modelo visual utilizado para modelar software O.O.
Surgiu a partir da necessidade de possibilitando a fácil compreensão completa do projeto.
Método x Modelo de Linguagem
Método: Modelo de Linguagem e um processo.
	Processo: Orientação para a construção de um projeto (Passos).
Modelo de Linguagem: Notação que o método usa para descrever o projeto.
<número>
UML
Define uma notação e um meta-modelo
Notação: Representação gráfica da sintaxe da linguagem
Meta-modelo: Diagrama de classe
Por que modelar o Software?
UML – Diagramas
Representação gráfica de um conjunto de elementos
UML – Diagramas
Diagramas Comportamentais
Possuem aspectos dinâmicos do sistema
Mostram como as entidades interagem para executar uma funcionalidade
Diagramas estruturais
Modelam a estrutura do sistema
Mostra como as entidades são compostas e seus relacionamentos
Por que tantos diagramas?
UML
Ferramenta para modelagem
Astah: 
< http://astah.change-vision.com/en/product/astah-community.html >
Documentação UML
www.uml.org
Conceitos essenciais para o entendimento
Conceitos
Paradigma
Abstração
Objeto
Classe
Paradigma
Forma de pensar e perceber o mundo real;
Forma de desenvolver e analisar o projeto a ser desenvolvido.
Abstração
Permite ignorar aspectos não relevantes com o propósito de diminuir a complexidade.
Objeto
Qualquer coisa real ou abstrata, existente no mundo real, ao qual armazenamos dados e métodos que os manipulam.
Algo capaz de armazenar um estado (informação), operações (comportamentos) e identidade.
Objeto
“Um objeto representa um item identificável, uma unidade, ou entidade, individual, seja real ou abstrata, com regra bem definida”
OBJETO = DADOS + OPERAÇÕES
Objeto
Objeto é qualquer entidade que possua características e comportamento
Características
Representada pelos dados
Chamados de ATRIBUTOS
Variáveis de instância
Comportamento
Definido pelas operações
Métodos de um objeto
Funções executados em um objeto
Objeto
Possuem
Estado
Representado pelos valores dos atributos de um objeto
Comportamento
Definido pelo conjunto de operações (métodos) do objeto
Estado representa o resultado cumulativo de seu comportamento
Identidade
Forma que conhecemos os objetos, é a referência ao objeto
Classe
Constrói objetos do mesmo tipo.
Descreve o tipo de objeto
É onde conceituamos o objeto
É a essência do objeto
É onde podemos definir os atributos e os métodos
Atributos: define características do objeto
Métodos: Operações que o objeto pode realizar
Classe x Objetos
Objeto é a instância de uma classe
Objetos semelhantes pertencem a uma mesma classe
Classe x Objetos
Classe Lâmpada
Classe Lâmpada
Classe Lâmpada
Atributos
Ligada (boolean)
Potência (double)
Operadores
Ligar
Desligar
Esta Ligada
Classe Lâmpada
Classe Lâmpada em Java
Continuação
Objeto
Classe
Continuação dos diagramas UML
Diagramas
Estáticos
Uteis na estruturação do sistema
Diagrama de Casso de Uso
Descreve as tarefas realizadas pelo sistema
Diagrama de Classe
Classes necessárias para o desenvolvimento do sistema
Iterativos
Demonstra a interação entre os objetos em um CDU
Uteis na modelagem de aspectos dinâmicos do sistema
Diagrama de Sequencia
Prevê a sequencia de ações do objeto
Caso de Uso
Identifica e registra os requisitos
Utilizando como base para outras atividades no processo de desenvolvimento
Descrição do Caso de Uso
Narrativa de utilização do sistema
Permite a compreensão e descrição dos requisitos
Caso de Uso - Descrição
Exemplo de Descrição do Caso de Uso
Caso de Uso Processar Venda: um cliente vai até ao caixa com os produtos que deseja adquirir. O caixa usa o sistema para registrar cada item comprado. O sistema vai apresentando um total parcial e uma linha de detalhes à medida que registra cada item. O cliente entra os dados sobre o pagamento, que são validados e, em seguida, registrados pelo sistema. O sistema atualiza o estoque. O cliente recebe um recibo do sistema e sai com os itens comprados.
Caso de Uso - Descrição
Exemplo de Descrição do Caso de Uso
Caso de Uso Processar Venda: 
O cliente vai até ao caixa com os produtos que deseja adquirir.
O caixa usa o sistema para registrar cada item comprado.
O sistema vai apresentando um total parcial e uma linha de detalhes à medida que registra cada item.
O cliente entra os dados sobre o pagamento, que são validados e, em seguida, registrados pelo sistema.
O sistema atualiza o estoque. 
O cliente recebe um recibo do sistema e sai com os itens comprados.
Atividade
Com base nas atividades anterior e no conteúdo explanado acima descreva oscasos de uso para o sistema proposto
Atividade
Continue a documentação do seu projeto final descrevendo o caso de uso do mesmo.
Atualize o documento de visão
Diagrama de Caso de Uso
Objetivo
Representação visual externa das funcionalidades do sistema
Mostra os atores e suas respectivas ações no sistema
Caso de Uso - Conceitos
Ator – é algo com comportamento, como uma pessoa (identificada por seu papel) ou um sistema de computador, que interage com o sistema (ex. um caixa)
Cenário – sequência específica de ações e interações entre atores e o sistema (instância de caso de uso)
Caso de Uso - Cenário
Exemplos
Efetuar com sucesso a compra de itens com dinheiro
Efetuar com sucesso a compra de itens com cartão de crédito
Não efetuar a compra por causa da recusa de autorização de crédito
Caso de Uso
Serviços, tarefas ou funções que podem ser utilizadas pelos usuários do sistema
Coleção de cenários relacionados
Sucesso e Fracasso
Descrevem atores usando o sistema afim de atingir um objetivo
Associação
Representam as interações ou relacionamentos entre:
Os casos de uso
Inclusão, Extensão e Generalização/Especialização
Os atores e os casos de uso
Indica que este ator pode usar a função do sistema representada pelo caso de uso
Os atores que fazem parte do diagrama
Generalização/Especialização
Associações
Pode conter setas indicando o sentido da navegação das informações
Pode possuir descrição própria
Esclarecer informações transmitidas
Pode possuir um nome próprio
Relacionamento de Generalização/Especialização
Relaciona Casos de Uso com características semelhantes
Define-se um caso de uso geral e outros casos de uso com suas especializações
Evita redundância:
No caso de uso geral descreve tudo que for comum 
No caso de uso especifico concentra-se na descrição das diferenças
Relacionamento de Generalização/Especialização
Pode ocorrer entre atores
Serve para facilitar a leitura do diagrama
Associações feitas pelo ator genérico são herdadas pelos atores específicos
Relacionamento de Inclusão
Serviços utilizados por mais de um caso de uso
Evita redundância
Indicam uma obrigatoriedade 
Caso de Uso A possui relação com B, indica que na execução A implica na execução de B
Relacionamento de Inclusão
Relacionamento de Extensão
Descreve senários opcionais em um caso de uso
Os casos de uso nessa situação descrevem cenários que ocorrerão apenas em uma situação especifica, se uma condição for satisfatória
Relacionamento de Extensão
Restrição a Associação de Extensão
É indicado através de uma nota explicita a condição para que um caso de uso estendido seja executado
Ponto de Extensão
Ponto no comportamento de um CDU ao qual esse comportamento poderá ser estendido pelo comportamento de um outro caso de uso, se a condição para que isto ocorra for satisfeita
Multiplicidade
Determina o número de vezes que um ator pode utilizar um determinado CDU.
Fronteiras do Sistema
Permite identificar um subsistema, ou mesmo o sistema completo, além de destacar o que está contido no sistema e o que não está.
Documento de Caso de Uso
Modelo de Documento de Especificação de Caso de Uso
Atividade
Com base nas atividades anterior e no conteúdo explanado acima crie o diagrama de caso de uso para o sistema proposto
Atividade
Continue a documentação do seu projeto final criando o Diagrama de caso de uso do mesmo.
Atualize o documento de visão
Caso de Uso – Sistema de Controle Bancário
O sistema deve permitir que os clientes abram e encerrem contas, bem como depositem ou saquem valores e emitam saldos ou extratos. Essas últimas quatro o cliente utilizará diretamente por meio de um caixa eletrônico, porém, para abrir e encerrar uma conta ele necessitará interagir com um funcionário do banco, que poderá ainda realizar alguma manutenção em seu cadastro.
Diagrama de Caso de Uso
Atores
Cliente – Representa as pessoas físicas ou jurídicas que mantém ou mantiveram contas na instituição bancária, com direito a saque, depósito, saldo ou extrato enquanto mantinham contas abertas.
Funcionário – Representa os funcionários com função de atender presencialmente os clientes da Instituição.
Caso de Uso – Abrir Conta Especial
CDU: Abrir Conta
Ator: Funcionário
Resumo: Descreve as etapas necessárias para a abertura da Conta Especial para um cliente
Pré-Condição: Aprovação do pedido de abertura
Pós-Condição: Necessário a realização de um depósito inicial
Caso de Uso – Abrir Conta Especial
Fluxo:
O funcionário solicita a abertura de Conta Especial.
O funcionário consulta o cliente por seu CPF ou CNPJ.
É definido o valor limite do cheque especial.
É inserida uma senha de acesso.
A conta é criada.
É fornecido o valor a ser depositado.
É realizado o registro do depósito.
É emitido o cartão da conta.
Restrições:
Para abrir uma conta especial é preciso ser maior de idade.
É necessário estar empregado e o salário ser superior a 500,00.
O valor mínimo de depósito inicial é R$ 50,00. 
Caso de Uso – Emitir Saldo
CDU: Emitir Saldo
Ator: Cliente
Resumo: Descreve as etapas necessárias para a emissão do saldo referente a uma determinada conta
Pré-Condição: Está com a conta ativa
Pós-Condição:
Caso de Uso – Emitir Saldo
Fluxo:
O cliente informa o número da conta.
O sistema verifica a existência da conta.
O sistema solicita a senha da conta.
O cliente informa a senha.
O sistema verifica se a senha está correta.
O sistema emite o saldo.
Restrições:
A Conta deve existir e estar ativa.
A senha deve estar correta
Fluxo de Exceção
Conta não encontrada: Comunicar ao cliente que o número da conta não foi encontrado
Senha Inválida: Comunica ao cliente que a senha é inválida.
Diagramas de Classe
Dá a visualização das Classes que compõe o sistema e seus respectivos atributos e métodos
Demonstra o relacionamento entre as classes 
Identifica tipos de retorno e parâmetros dos métodos
Dá uma visão estática de como as classes estão organizadas entre si
Responde “O que?” será feito na classe, não “Como?” será feito
Mostra um conjunto de Classes e Interfaces e sues relacionamentos
Diagramas de Classe
ContaBancaria
numConta: int
dataAbertura: int
senha: int
saldo: double
+ toString(): String
Nome da Classe
Atributos
Métodos
Diagramas de Classe
Visibilidades
Atributos e Métodos
private (-): Acessível somente na própria classe
public(+): Acessível para qualquer classe
protected (#): Acessível para própria classe e suas subclasses
default: Acessível para classes que pertencem ao mesmo pacote
Diagramas de Classe
Visibilidades - Atributos e Métodos
private:
public:
protected:
 
default:
Diagramas de Classe
Deve conter apenas os métodos principais do sistema
Apresenta a assinatura dos métodos
Parâmetros e retorno
Pode presentar atribuição de valores
O código de programação será criado com base no diagrama
Associação
Associação Unária ou Reflexiva
Ocorre na relação de um objeto da classe com objetos da mesma classe
Associação
Associação Binária
Relacionamento entre duas classes distintas
Associação
Associação Ternária
Relacionam objetos de mais de duas classes
Associação
Agregação
Informações de um objeto complementadas pelas informações contidas em um ou mais objetos de outra classe
Associação
Composição
Variação da agregação
Apresenta um vinculo mais forte entre os objetos associados
Objeto parte está associado a um único objeto todo.
Associação
Generalização/Especialização
Representa a herança entre classes
Identificam as super e sub classes
Associação
Generalização/Especialização
Métodos podem ser redeclarados nas subclasses com comportamentos diferentes
Associação
Classes Associativas
Criadas em ocorrências de relacionamentos múltiplos
São necessárias caso exista atributos que não possam ser armazenados por nenhum das classes que compõe a associação
Associação
Associação
Dependência
Identifica dependência de uma classe em relação autra
Ex: A classe cliente depende de serviços da classe fornecedora
A mudança de elementos na classe fornecedora poderá acarretarmudanças em elementos da classe cliente
Associação
Realização
Possui características de generalização e dependência
Identificam classes responsáveis por executar funções para outras classes
Associação
Realização
Possui características de generalização e dependência
Identificam classes responsáveis por executar funções para outras classes
Associação
Restrição
Informações extras
Definem condições avaliadas durante a implementação
Relacionamentos
Atividade
Com base nas atividades anterior e no conteúdo explanado acima crie o diagrama de classe para o sistema proposto
Atividade
Continue a documentação do seu projeto final criando o Diagrama de classe do mesmo.
Atualize o documento de visão
Exemplo
Sistema de Controle bancário
Modelo Conceitual
Diagrama de Classe
Diagramas de Sequência
Usado para visualizar o comportamento de um ou vários objetos dentro de um único Caso de Uso, a partir das mensagens que são passadas entre eles.
Diagramas de Sequência
Usado para visualizar o comportamento de um ou vários objetos dentro de um único Caso de Uso, a partir das mensagens que são passadas entre eles.
Determina a sequencia de eventos que ocorre em um determinado processo.
Identifica quais mensagens devem ser disparadas e em qual ordem.
Baseado no Diagrama de Caso de Uso
Um diagrama de Sequencia para cada caso de uso descrito
Diagramas de Sequência
Utilização
Na fase de Analise
Identificar eventos e operações do sistema
Importância de demonstrar como os atores interagem com o sistema
Na fase de projeto
Descreve como os objetos interagem entre si na realização de algumas funcionalidade do sistema
Diagramas de Sequência - Analise
Representa eventos partindo dos atores
Mostra a interação dos atores no sistema
Dependentes do Caso de Uso
Criado apenas para os CDUs mais importantes
Diagramas de Sequência - Analise
Diagramas de Sequência - Projeto
Representa eventos partindo dos objetos
Mostra a utilização dos objetos e suas trocas de mensagens
Qual objeto é responsável por cada parte do documento?
Qual ações entre objetos são realizadas para gerar toda a funcionalidade do sistema?
Objeto
Pode existir desde o inicio do processo ou ser cria durante a execução do mesmo
Novos objetos não são representados no topo do diagrama
LINHA DE VIDA
Representada por uma linha tracejada
Representa o ciclo de vida de um objeto durante uma iteração
O “X” representa que o objeto foi destruído
Atores
Mesmos usados no diagrama de caso de uso
Contem umas linha de vida
Mensagem
Representado por linhas com setas
Linhas horizontais entre as linhas de vida de dois objetos
As linhas vem acompanhadas com o nome da mensagem, e opcionalmente, os parâmetros da mesma
Pode haver envio de mensagem para o mesmo objeto, isso representa uma interação
Mensagem
Ativação
Mensagem de Retorno
Identifica a resposta a uma mensagem para o objeto e/ou ator que chamou
Pode retornar informações especificas ou apenas informar se o método foi executado com êxito ou não
Foco de Controle ou Ativação
Identifica o período de tempo em que um determinado objeto participa ativamente do processo
Determina o tempo ao qual um objeto está executando diretamente uma ação ou através de um procedimento subordinado
Autodelegação/Autochamada/
Chamada Reflexiva
Mensagens que um objeto envia para si mesmo.
Diretrizes
Transforme o CDU em uma descrição algorítmica
Avalie as classes que podem fazer parte deste CDU
Monte o Diagrama de Sequência
Para cada passo descrito no caso de uso, verifique qual classe será classe responsável pela tarefa indicada.
Se a tarefa for muito complexa divida-a entre mais de uma classe
Estudo de Caso
Consultório médico
1º Passo: Caso de Uso Marcar Consulta
Paciente deseja marcar consulta
Atendente verifica se o paciente está cadastrado na clínica
Se não tiver, o cadastro é solicitado
Atendente verifica se há disponibilidade no horário e data
Se houver, a consulta é marcada
Estudo de Caso
Consultório médico
2º Passo: Avaliar as classes participantes
Estudo de Caso
Consultório médico
3º Passo: Montar o diagrama
Atividade
Com base nas atividades anterior e no conteúdo explanado acima crie o diagrama de sequencia para os requisitos globais do sistema proposto
Atividade
Continue a documentação do seu projeto final criando o Diagrama de sequencia para os requisitos globais do mesmo.
Atualize o documento de visão
Diagrama de Atividades
Diagrama de Pacotes
Introdução a Planning Poker
Jogo de cartas com uma plataforma digital
Objetivo de ajudar as equipes ágeis, de forma colaborativa, estimar o tempo necessário para concluir um conjunto de histórias do usuário 
Prevê com precisão o trabalho a ser elaborado
https://www.planningpoker.com/
Planning Poker
Introdução a Planning Poker
Com alista dos requisitos em mãos, estórias a serem analisadas, deverá ser escolhido o requisito mais simples do sistema para iniciar as rodadas do Planning Poker, esse servirá de base para as demais rodadas.
Cada requisito acarretará em uma rodada no jogo
É necessário uma ampulheta para limitar o tempo de cada rodada
A carta 100 especifica que o requisito deverá ser repensado e provavelmente dividido em requisitos menores
Introdução a Planning Poker
A carta 0 indica que a estória já foi resolvida em situações anteriores
A carta ? Indica que não ficou claro a funcionalidade do requisito
A carta “Café” pede uma pousa para descanso
Os números mostrados nas cartas são representações de tempo para o desenvolvimento em questão
Referencias
http://diatinf.ifrn.edu.br/doku.php?id=corpodocente:rosemary:analise_e_projeto_orientado_a_objetos