1 / 33

Processo Unificado

Processo Unificado. Objetivos. Discutir a necessidade de um processo “padrão” Apresentar um subconjunto do Processo Unificado. Simular a execução do processo. Motivação. Processos. É necessário adotar um processo de desenvolvimento para manter a execução das atividades em um fluxo coerente.

reia
Download Presentation

Processo Unificado

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Processo Unificado PRISMA@COPPE/UFRJ - Toacy C. de Oliveira

  2. Objetivos Discutir a necessidade de um processo “padrão” Apresentar um subconjunto do Processo Unificado. Simular a execução do processo PRISMA@COPPE/UFRJ - Toacy C. de Oliveira

  3. Motivação PRISMA@COPPE/UFRJ - Toacy C. de Oliveira

  4. Processos • É necessário adotar um processo de desenvolvimento para manter a execução das atividades em um fluxo coerente. People are more important than any process. Good people with a good process will outperform good people with no process every time. —Grady Booch PRISMA@COPPE/UFRJ - Toacy C. de Oliveira

  5. Processo Unificado • Processo Iterativo e Incremental • Orientado a Casos de Uso • Define um conjunto de • Atividades – o que fazer • Papéis – que participa • Artefatos – quais dados são necessários • Workflows – organização das atividades PRISMA@COPPE/UFRJ - Toacy C. de Oliveira

  6. Fases Disciplinas do Processo Elaboração Construção Transição Concepção Modelagem do Negócio Requisitos Análise e Projeto Implementação Teste Entrega Disciplinas do Suporte Gerenciamento de Alterações e Configuração Gerenciamento de Projeto Ambiente Iter.#1 Iter.#2 Iter.#n Iter.#n+1 Iter.#n+2 Iter.#m Iter.#m+1 Iteração(ões) Preliminar(es) UP - Resumo PRISMA@COPPE/UFRJ - Toacy C. de Oliveira

  7. Fases e Disciplinas • Organizam o trabalho em blocos lógicos • Fases – Identificam o momento dentro do ciclo-de-vida. • Disciplinas – Identificam quais elementos de processo são usados para resolver um problema específico dentro do ciclo-de-vida. PRISMA@COPPE/UFRJ - Toacy C. de Oliveira

  8. Fases • Concepção: estabelece o caso de negócio para o sistema e delimita o escopo do projeto. • Elaboração: envolve a análise do domínio do problema e a especificação da arquitetura do sistema. • Construção: envolve a elaboração do software a partir de arquitetura em um produto completo para utilização pelos usuários. • Transição: viabiliza que o software possa ser utilizado pelos usuários. PRISMA@COPPE/UFRJ - Toacy C. de Oliveira

  9. Disciplinas Análise de Negócio Requisitos Análise e Projeto Implementação Testes Entrega Gerenciamento de Mudanças Ambiente Gerenriamento de Projeto PRISMA@COPPE/UFRJ - Toacy C. de Oliveira

  10. UP & Cronograma PRISMA@COPPE/UFRJ - Toacy C. de Oliveira From Larman

  11. Iterativo e Incremental No contexto do ciclo de vida de desenvolvimento de um software: • Iterativo: processo que envolve o gerenciamento de uma seqüência de versões executáveis. • Cada iteração pode ser vista como um mini-projeto, envolvendo um ciclo completo de desenvolvimento, resultando em uma versão de um produto executável. • Incremental: processo que envolve a integração contínua da arquitetura do sistema para a produção de novas versões do sistema, onde cada nova versão incorpora aperfeiçoamentos incrementais em relação a anterior pela incorporação do produto resultante da última iteração. PRISMA@COPPE/UFRJ - Toacy C. de Oliveira

  12. Experimentando........ PRISMA@COPPE/UFRJ - Toacy C. de Oliveira

  13. Um Processo Unificado* PRISMA@COPPE/UFRJ - Toacy C. de Oliveira * Tipicamente processos são específicos para um projeto

  14. Uma Sequência PRISMA@COPPE/UFRJ - Toacy C. de Oliveira

  15. O Problema (Documento de Visão) Este projeto tem como objetivo implementar um sistema que simula um jogo de dados. O jogo começa quando o jogador arremessa dois dados. Caso a soma das faces dos dados seja 7, o jogador é vencedor, caso contrário é perdedor. Os dados possuem 6 lados e em cada lado há um número de 1 a 6 (sem repetições) REQ01: O Jogador pode iniciar um jogo novo REQ02: O Jogador arremessa os dados. REQ Não Funcionais: O sistema deverá ser desenvolvido utilizando linha de comando, ou seja, não há interface gráfica. PRISMA@COPPE/UFRJ - Toacy C. de Oliveira

  16. Concepção/Elaboração • Modelo de Casos de Uso (Funcional) • Diagrama de Caso de Uso • Especificação de Casos de Uso • Modelo de Classes (Estrutural) • Classes de Análise PRISMA@COPPE/UFRJ - Toacy C. de Oliveira

  17. Diagrama de Caso de Uso • Especifica os atores que interagem com o sistema • Especifica quais funções cada ator tem “acesso” PRISMA@COPPE/UFRJ - Toacy C. de Oliveira

  18. Especificação de Caso de Uso • Texto estruturado que detalha um Caso de Uso em específico. • Contém • Nome do Caso de Uso • Atores Envolvidos • Lista com pré e pós condições para a execução do Caso de Uso • Fluxos básicos e alternativos, com os passos executados pelo ator e pelo sistema. PRISMA@COPPE/UFRJ - Toacy C. de Oliveira

  19. Exemplo UC: Arremessar Dados Atores : Jogador Pré-condição : jogo inicializado Pós-condição : vencedor é conhecido PRISMA@COPPE/UFRJ - Toacy C. de Oliveira

  20. Importante!!!!! • Como o Caso de Uso é um modelo da fase de análise não é desejável atrelá-lo a uma plataforma de execução. • Quem disse que o sistema tem menu??? Será que não dá para fazer a mesma função via comando de voz? PRISMA@COPPE/UFRJ - Toacy C. de Oliveira

  21. Como achar Casos de Uso/Atores • Analisar Requisitos Funcionais • Dica: Analisar os verbos e sujeitos presentes na especificação. • Procurar ações que o sistema faz e que são perceptíveis para um elemento externo(atores). • Imprimir Texto, Pagar com Cartão de Crédito, Fazer Empréstimo, etc • Procurar quem dispara as ações • Gerente Faz Empréstimo, Cliente Paga com Cartão, etc PRISMA@COPPE/UFRJ - Toacy C. de Oliveira

  22. Diagrama de Classes Estamos usando o Processo Unificado como referência, ou seja, a abstração utilizada na implementação será orientada a objetos. Casos de Uso organizam funções, mas não ressaltam os conceitos e relacionamentos importantes para o sistema. Classes expressam conceitos e seus relacionamentos. PRISMA@COPPE/UFRJ - Toacy C. de Oliveira

  23. Classes – Modelo Conceitual • Especifica conceitos, seus atributos e relacionamentos • É parte da fase de Análise PRISMA@COPPE/UFRJ - Toacy C. de Oliveira

  24. Importante!!! • Classes de Análise não especificam operações. Estas entram no início do projeto. • Não há metodos • Classes de Análise também não especificam conceitos da plataforma de execução. • Menu, Banco de Dados,...... PRISMA@COPPE/UFRJ - Toacy C. de Oliveira

  25. Descobrindo Classes • Destacando COISAS no texto de requisitos • REQ01: O Jogador pode iniciar um jogo novo • REQ02: O Jogador arremessa os dados • Cartões CRC • Class – Responsability - Collaboration PRISMA@COPPE/UFRJ - Toacy C. de Oliveira

  26. Descobrindo Operações CRC Cenários de Execução PRISMA@COPPE/UFRJ - Toacy C. de Oliveira

  27. Cenário - Iniciar Jogo • Utiliza o Diagrama de Sequencia da UML para simular a execução de um Caso de Uso, distribuindo as funcionalidades pelas classes especificadas anteriormente (Classes de Análise) PRISMA@COPPE/UFRJ - Toacy C. de Oliveira

  28. Cenário – ArremessarDados PRISMA@COPPE/UFRJ - Toacy C. de Oliveira

  29. Classes – Modelo de Projeto • As classes de projeto refinam as classes descobertas na análise. • Adicionam operações • Verificam Boas Práticas de Modelagem • Coesão, Acoplamento, Reuso • Se conectam com a plataforma de execução • Hibernate, J2EE, .NET PRISMA@COPPE/UFRJ - Toacy C. de Oliveira

  30. Classes de Projeto • A Classe jogador foi eliminada -> Não há necessidade durante execução • Os relacionamentos foram direcionados -> Assim o acoplamento é diminuído. • As operações apareceram (vieram do diagrama de sequencia) PRISMA@COPPE/UFRJ - Toacy C. de Oliveira

  31. Código public class Dado { private intresultado; protected void Randomize() { // your code here } public void Arremessa() { // your code here } } public class Jogo { public Dado dado; public Dado dado_1; public void ApresentaResultado() { // your code here } public void ZerarSoma() { // your code here } } PRISMA@COPPE/UFRJ - Toacy C. de Oliveira

  32. Resumindo • O Processo utilizado • ....foi capaz de capturar as informações necessárias para a implementação do sistema eu questão. • ..facilitou o entendimento pois organizou as atividades de “raciocínio” em uma sequência. • Os conceitos capturados estão claramente presentes em vários modelos e é possível rastreá-los. PRISMA@COPPE/UFRJ - Toacy C. de Oliveira

  33. Mais informações... • Openup • http://epf.eclipse.org/wikis/openup/ • UpEDU • http://www.upedu.org/ PRISMA@COPPE/UFRJ - Toacy C. de Oliveira

More Related