o processo unified zprocesso de desenvolvimento de software zelementos participantes ytrabalhadores...
TRANSCRIPT
![Page 1: O Processo Unified zProcesso de Desenvolvimento de Software zElementos Participantes yTrabalhadores yAtividades yRecursos Humanos yArtefatos de Software](https://reader035.vdocuments.com.br/reader035/viewer/2022070507/5706384c1a28abb8238f61c5/html5/thumbnails/1.jpg)
O Processo Unified
Processo de Desenvolvimento de Software
Elementos Participantes Trabalhadores Atividades Recursos Humanos Artefatos de Software
Necessidadesdo Usuário
Sistema deSoftware
Processo de Desenvolvimento
![Page 2: O Processo Unified zProcesso de Desenvolvimento de Software zElementos Participantes yTrabalhadores yAtividades yRecursos Humanos yArtefatos de Software](https://reader035.vdocuments.com.br/reader035/viewer/2022070507/5706384c1a28abb8238f61c5/html5/thumbnails/2.jpg)
O Processo Unified
Ciclo de Vida de um Software
![Page 3: O Processo Unified zProcesso de Desenvolvimento de Software zElementos Participantes yTrabalhadores yAtividades yRecursos Humanos yArtefatos de Software](https://reader035.vdocuments.com.br/reader035/viewer/2022070507/5706384c1a28abb8238f61c5/html5/thumbnails/3.jpg)
O Processo Unified
![Page 4: O Processo Unified zProcesso de Desenvolvimento de Software zElementos Participantes yTrabalhadores yAtividades yRecursos Humanos yArtefatos de Software](https://reader035.vdocuments.com.br/reader035/viewer/2022070507/5706384c1a28abb8238f61c5/html5/thumbnails/4.jpg)
O Processo Unified
![Page 5: O Processo Unified zProcesso de Desenvolvimento de Software zElementos Participantes yTrabalhadores yAtividades yRecursos Humanos yArtefatos de Software](https://reader035.vdocuments.com.br/reader035/viewer/2022070507/5706384c1a28abb8238f61c5/html5/thumbnails/5.jpg)
Modelos
![Page 6: O Processo Unified zProcesso de Desenvolvimento de Software zElementos Participantes yTrabalhadores yAtividades yRecursos Humanos yArtefatos de Software](https://reader035.vdocuments.com.br/reader035/viewer/2022070507/5706384c1a28abb8238f61c5/html5/thumbnails/6.jpg)
O Começo do Processo
Pré-Projeto antes de começar o projeto de um software, (ou seja, antes
de começarmos as iterações) é necessário fazermos um planejamento prévio de como esse desenvolvimento se dará
Visão do Problema Compreensão do Problema - descrição verbal do domínio
do problema - elicitação das necessidades dos investidores Proposta de Solução de Software - descrição verbal
propondo como se pode visualizar um sistema de software para resolver o problema
estabelecimento de metas e objetivos Visão Geral dos Pré-Requisitos
funções do sistema - o que se supõe que o sistema faça atributos do sistema - o que se supõe que o sistema seja
![Page 7: O Processo Unified zProcesso de Desenvolvimento de Software zElementos Participantes yTrabalhadores yAtividades yRecursos Humanos yArtefatos de Software](https://reader035.vdocuments.com.br/reader035/viewer/2022070507/5706384c1a28abb8238f61c5/html5/thumbnails/7.jpg)
O Começo do Processo
Planejamento Logístico Equipes de Trabalho - pessoas envolvidas no projeto Grupos Afetados - grupos afetados pelo projeto Fatos Presumidos - fatos que se presumem verdadeiros
antes de se iniciar o projeto Riscos - coisas que podem levar ao fracasso ou atrasos
no projeto - potenciais consequências do fracasso ou do atraso
Dependências - outros parceiros, sistemas ou produtos dos quais o projeto depende para sua implementação
Glossário (Vocabulário) de Termos levantamento dos principais termos utilizados para
descrever as características do problema
![Page 8: O Processo Unified zProcesso de Desenvolvimento de Software zElementos Participantes yTrabalhadores yAtividades yRecursos Humanos yArtefatos de Software](https://reader035.vdocuments.com.br/reader035/viewer/2022070507/5706384c1a28abb8238f61c5/html5/thumbnails/8.jpg)
Modelo Conceitual de Domínio
Modelo Conceitual ilustra conceitos significativos de um domínio - aquilo que
devemos estar cientes a respeito do domínio representa coisas do mundo real, NÃO componentes de
software obtido a partir da Análise do Domínio
Conteúdo conceitos, expressos em um diagrama de classes associações entre os conceitos atributos dos conceitos
Análise Estruturada x Análise Orientada a Objetos Análise estruturada enfoca em processos ou funções Análise orientada a objetos enfoca em conceitos
![Page 9: O Processo Unified zProcesso de Desenvolvimento de Software zElementos Participantes yTrabalhadores yAtividades yRecursos Humanos yArtefatos de Software](https://reader035.vdocuments.com.br/reader035/viewer/2022070507/5706384c1a28abb8238f61c5/html5/thumbnails/9.jpg)
Modelo Conceitual de Domínio
Lista de Categorias de Conceitos objetos físicos ou tangíveis especificações ou descrições de coisas lugares transações ítens sendo transacionados papéis de pessoas coisas que contém outras coisas coisas que são contidas em outras coisas regras e políticas eventos catálogos de coisas etc...
![Page 10: O Processo Unified zProcesso de Desenvolvimento de Software zElementos Participantes yTrabalhadores yAtividades yRecursos Humanos yArtefatos de Software](https://reader035.vdocuments.com.br/reader035/viewer/2022070507/5706384c1a28abb8238f61c5/html5/thumbnails/10.jpg)
Modelo Conceitual de Domínio
Lista de Associações Comuns A é uma parte física de B A é uma parte lógica de B A está fisicamente contido em B A está logicamente contido em B A é uma descrição para B A é um ítem transacionado por B A é armazenado em B A é membro de B A utiliza ou gerencia B A se comunica com B A possui ou é possuído por B A está próximo de B
![Page 11: O Processo Unified zProcesso de Desenvolvimento de Software zElementos Participantes yTrabalhadores yAtividades yRecursos Humanos yArtefatos de Software](https://reader035.vdocuments.com.br/reader035/viewer/2022070507/5706384c1a28abb8238f61c5/html5/thumbnails/11.jpg)
Modelo Conceitual de Domínio
EmergencyCatalog PreviousDialedMemory
Ring VibraCall
MainCatalogConfidentialCatalog
ConfidentialPhoneNumber
Password
VoiceRegister
PagerMessage
Listener
get
PhoneNumber
show
Digit
Character
String
DialingRequest
has
Dialer
dials
receives
Name
Catalog
search feed
IncomingCall
receives
has
Channel
opensuses
![Page 12: O Processo Unified zProcesso de Desenvolvimento de Software zElementos Participantes yTrabalhadores yAtividades yRecursos Humanos yArtefatos de Software](https://reader035.vdocuments.com.br/reader035/viewer/2022070507/5706384c1a28abb8238f61c5/html5/thumbnails/12.jpg)
Especificação dos Requisitos
![Page 13: O Processo Unified zProcesso de Desenvolvimento de Software zElementos Participantes yTrabalhadores yAtividades yRecursos Humanos yArtefatos de Software](https://reader035.vdocuments.com.br/reader035/viewer/2022070507/5706384c1a28abb8238f61c5/html5/thumbnails/13.jpg)
Encontrar Atores e Casos de Uso
![Page 14: O Processo Unified zProcesso de Desenvolvimento de Software zElementos Participantes yTrabalhadores yAtividades yRecursos Humanos yArtefatos de Software](https://reader035.vdocuments.com.br/reader035/viewer/2022070507/5706384c1a28abb8238f61c5/html5/thumbnails/14.jpg)
Encontrar Atores e Casos de Uso
Objetivo iniciar o processo de especificação dos requisitos,
desenvolvendo cenários genéricos descrevendo a interação entre o(s) usuário(s) e o sistema
Nesta Atividade Explora-se a descoberta de diferentes possíveis casos de uso Casos de uso devem envolver todos os tipos de interações
desejadas entre o sistema e os usuários Caso de Uso
Narrativa genérica de um caso de interação entre o(s) usuário(s) e o sistema
Resultado diagrama de casos de uso
![Page 15: O Processo Unified zProcesso de Desenvolvimento de Software zElementos Participantes yTrabalhadores yAtividades yRecursos Humanos yArtefatos de Software](https://reader035.vdocuments.com.br/reader035/viewer/2022070507/5706384c1a28abb8238f61c5/html5/thumbnails/15.jpg)
Diagrama de Casos de Uso
Exemplo: Casos de Uso para um Telefone Celular
Program Number in Memory
Search Memory
Delete Number in Memory User
Validate User
Check Password
Voice Validation
Dial Confidential Phone Number
<<include>>
Dial Number in Memory
Dial Phone Number
<<extends>> <<extends>>
![Page 16: O Processo Unified zProcesso de Desenvolvimento de Software zElementos Participantes yTrabalhadores yAtividades yRecursos Humanos yArtefatos de Software](https://reader035.vdocuments.com.br/reader035/viewer/2022070507/5706384c1a28abb8238f61c5/html5/thumbnails/16.jpg)
Priorização dos Casos de Uso
![Page 17: O Processo Unified zProcesso de Desenvolvimento de Software zElementos Participantes yTrabalhadores yAtividades yRecursos Humanos yArtefatos de Software](https://reader035.vdocuments.com.br/reader035/viewer/2022070507/5706384c1a28abb8238f61c5/html5/thumbnails/17.jpg)
Priorização dos Casos de Uso
Objetivo coletar subsídios para a priorização dos casos de uso,
determinando quais deles devem ser desenvolvidos (i.e. analisados, desenhados, implementados, etc) nas primeiras iterações e quais podem ser desenvolvidos nas iterações posteriores
Resultados capturados na visão arquitetural do modelo de casos de uso esta visão é considerada pelo gerente de projeto e utilizada
para o planejamento do que deve ser desenvolvido na iteração este planejamento leva em consideração também aspectos
não-técnicos, tais como aspectos políticos ou estratégicos visão arquitetural deve destacar os casos de uso que
descrevem funcionalidades críticas ou importantes
![Page 18: O Processo Unified zProcesso de Desenvolvimento de Software zElementos Participantes yTrabalhadores yAtividades yRecursos Humanos yArtefatos de Software](https://reader035.vdocuments.com.br/reader035/viewer/2022070507/5706384c1a28abb8238f61c5/html5/thumbnails/18.jpg)
Detalhamento de Casos de Uso
![Page 19: O Processo Unified zProcesso de Desenvolvimento de Software zElementos Participantes yTrabalhadores yAtividades yRecursos Humanos yArtefatos de Software](https://reader035.vdocuments.com.br/reader035/viewer/2022070507/5706384c1a28abb8238f61c5/html5/thumbnails/19.jpg)
Detalhamento de Casos de Uso
Objetivo descrever de maneira detalhada os caso de uso
selecionados na etapa anterior, referenciando de maneira minuciosa o fluxo de eventos entre os atores e o sistema, incluindo-se como o caso de uso começa, termina e quais as atividades realizadas tanto pelos atores como pelo sistema
Descrição de Caso de Uso pode ser realizada por meio de diferentes tipos de artefatos
de software: texto (sumarizada ou detalhada) diagrama de estados diagrama de atividades
a escolha do artefato ideal depende do grau de complexidade do caso de uso
![Page 20: O Processo Unified zProcesso de Desenvolvimento de Software zElementos Participantes yTrabalhadores yAtividades yRecursos Humanos yArtefatos de Software](https://reader035.vdocuments.com.br/reader035/viewer/2022070507/5706384c1a28abb8238f61c5/html5/thumbnails/20.jpg)
Exemplo de Descrição (Sumária) de Caso de Uso
Caso de Uso DialPhoneNumber Atores Usuário Propósito Descrever o processo de discagem de
um número Fluxo de Eventos O Usuário informa ao dispositivo
que deseja fazer a discagem de um número, entra com uma sequência de n dígitos, informa ao sistema que
terminou o número e o sistema iniciao processo de discagem
Tipo Primário e Conceitual
![Page 21: O Processo Unified zProcesso de Desenvolvimento de Software zElementos Participantes yTrabalhadores yAtividades yRecursos Humanos yArtefatos de Software](https://reader035.vdocuments.com.br/reader035/viewer/2022070507/5706384c1a28abb8238f61c5/html5/thumbnails/21.jpg)
Variações na Descrição de Casos de Uso
Descrição de Caso de Uso pode se tornar bem intrincada
Estratégia Básica descrever um fluxo de eventos básico, do começo ao fim, e
acrescentar as excessões que podem aparecer a cada instante
todas as alternativas, desvios ou excessões devem ser colocadas, para que se possa dizer que o caso de uso está especificado
Elementos Essenciais pré-condições: condições necessárias para que o caso de
uso possa se iniciar pós-condições: condições que determinam que o caso de
uso tenha realmente se encerrado
![Page 22: O Processo Unified zProcesso de Desenvolvimento de Software zElementos Participantes yTrabalhadores yAtividades yRecursos Humanos yArtefatos de Software](https://reader035.vdocuments.com.br/reader035/viewer/2022070507/5706384c1a28abb8238f61c5/html5/thumbnails/22.jpg)
Detalhamento de um Caso de Uso por Diagrama de Atividades
![Page 23: O Processo Unified zProcesso de Desenvolvimento de Software zElementos Participantes yTrabalhadores yAtividades yRecursos Humanos yArtefatos de Software](https://reader035.vdocuments.com.br/reader035/viewer/2022070507/5706384c1a28abb8238f61c5/html5/thumbnails/23.jpg)
Prototipação da Interface com o Usuário
![Page 24: O Processo Unified zProcesso de Desenvolvimento de Software zElementos Participantes yTrabalhadores yAtividades yRecursos Humanos yArtefatos de Software](https://reader035.vdocuments.com.br/reader035/viewer/2022070507/5706384c1a28abb8238f61c5/html5/thumbnails/24.jpg)
Prototipação da Interface com o Usuário
Objetivos construir um protótipo da interface com o usuário essa interface não será a interface definitiva, mas deve conter
as informações necessárias para a efetivação dos casos de usos descritos nas etapas anteriores
Etapas observação dos casos de uso e abstração das informações
necessárias a serem implementadas pelas interfaces, para cada ator
criação física de protótipos de interfaces com o usuário que ilustram como o sistema poderia implementar os casos de uso
Resultado Final conjunto de sketches e protótipos de interface com o usuário,
que servirão de inspiração posteriormente na fase de design
![Page 25: O Processo Unified zProcesso de Desenvolvimento de Software zElementos Participantes yTrabalhadores yAtividades yRecursos Humanos yArtefatos de Software](https://reader035.vdocuments.com.br/reader035/viewer/2022070507/5706384c1a28abb8238f61c5/html5/thumbnails/25.jpg)
Estruturação do Modelo de Casos de Uso
![Page 26: O Processo Unified zProcesso de Desenvolvimento de Software zElementos Participantes yTrabalhadores yAtividades yRecursos Humanos yArtefatos de Software](https://reader035.vdocuments.com.br/reader035/viewer/2022070507/5706384c1a28abb8238f61c5/html5/thumbnails/26.jpg)
Estruturação do Modelo de Casos de Uso
Objetivo reestruturar os elementos do modelo de casos de uso
capturados anteriormente (que podem ter sido capturados de maneira independente entre si) e gerar um modelo que seja homogêneo, consistente e simples de ser interpretado
Identificando Descrições Compartilhadas de Funcionalidade relação de generalização
Identificando Descrições Adicionais ou Opcionais de Funcionalidade relação de extensão
Identificando Descrições Repetidas de Funcionalidade relação de inclusão
![Page 27: O Processo Unified zProcesso de Desenvolvimento de Software zElementos Participantes yTrabalhadores yAtividades yRecursos Humanos yArtefatos de Software](https://reader035.vdocuments.com.br/reader035/viewer/2022070507/5706384c1a28abb8238f61c5/html5/thumbnails/27.jpg)
Análise
Análise dos Requisitos: aprofundamento das investigações, detalhamento e refinamento das especificações dos requisitos
Objetivos obter uma melhor compreensão dos requisitos, mantendo uma
descrição dos requisitos que seja compreensível e auxilie no posterior design do sistema
transladar as especificações dos requisitos que se encontram na “linguagem do cliente” para uma representação que use uma “linguagem do desenvolvedor”
passar de um modelo de casos de usos para um modelo de análise
Principal Desafio: manter um nível abstrato de investigação, sem entrar em questões de design
![Page 28: O Processo Unified zProcesso de Desenvolvimento de Software zElementos Participantes yTrabalhadores yAtividades yRecursos Humanos yArtefatos de Software](https://reader035.vdocuments.com.br/reader035/viewer/2022070507/5706384c1a28abb8238f61c5/html5/thumbnails/28.jpg)
Classes Estereotipadas
Classes Boundary utilizada para modelar a interação
entre o sistema e os atores interação envolve o recebimento e
apresentação de informações Classes Control
representam a coordenação, sequenciamento, transações e controle de outros objetos
derivações e cálculos Classes Entity
modela informações (dados) de longa duração, frequentemente persistentes
![Page 29: O Processo Unified zProcesso de Desenvolvimento de Software zElementos Participantes yTrabalhadores yAtividades yRecursos Humanos yArtefatos de Software](https://reader035.vdocuments.com.br/reader035/viewer/2022070507/5706384c1a28abb8238f61c5/html5/thumbnails/29.jpg)
Análise
![Page 30: O Processo Unified zProcesso de Desenvolvimento de Software zElementos Participantes yTrabalhadores yAtividades yRecursos Humanos yArtefatos de Software](https://reader035.vdocuments.com.br/reader035/viewer/2022070507/5706384c1a28abb8238f61c5/html5/thumbnails/30.jpg)
Análise Arquitetural
![Page 31: O Processo Unified zProcesso de Desenvolvimento de Software zElementos Participantes yTrabalhadores yAtividades yRecursos Humanos yArtefatos de Software](https://reader035.vdocuments.com.br/reader035/viewer/2022070507/5706384c1a28abb8238f61c5/html5/thumbnails/31.jpg)
Análise Arquitetural
Objetivo gerar um outline do modelo de análise e da
arquitetura por meio da identificação dos pacotes de análise, das classes de análise e de requisitos especiais necessários
Sub-Tarefas Identificação dos Pacotes de Análise Identificação de Classes Óbvias do tipo “Entity” Identificação de Requisitos Especiais
persistência, distribuição ou concorrência, restrições de segurança, tolerância a falhas e gerenciamento de transações
![Page 32: O Processo Unified zProcesso de Desenvolvimento de Software zElementos Participantes yTrabalhadores yAtividades yRecursos Humanos yArtefatos de Software](https://reader035.vdocuments.com.br/reader035/viewer/2022070507/5706384c1a28abb8238f61c5/html5/thumbnails/32.jpg)
Análise dos Casos de Uso
![Page 33: O Processo Unified zProcesso de Desenvolvimento de Software zElementos Participantes yTrabalhadores yAtividades yRecursos Humanos yArtefatos de Software](https://reader035.vdocuments.com.br/reader035/viewer/2022070507/5706384c1a28abb8238f61c5/html5/thumbnails/33.jpg)
Análise dos Casos de Uso
Objetivos identificação das classes de análise cujos objetos são
necessários para implementar o fluxo de eventos de um caso de uso em particular – diagrama de classes estereotipadas
distribuição do comportamento em um caso de uso por um conjunto de objetos interagindo entre si – diagrama de colaboração ou sequência
captura dos requisitos especiais relativos à realização de um caso de uso em particular
![Page 34: O Processo Unified zProcesso de Desenvolvimento de Software zElementos Participantes yTrabalhadores yAtividades yRecursos Humanos yArtefatos de Software](https://reader035.vdocuments.com.br/reader035/viewer/2022070507/5706384c1a28abb8238f61c5/html5/thumbnails/34.jpg)
Análise de Casos de Uso
Exemplo de Diagrama de Classes de Análise
![Page 35: O Processo Unified zProcesso de Desenvolvimento de Software zElementos Participantes yTrabalhadores yAtividades yRecursos Humanos yArtefatos de Software](https://reader035.vdocuments.com.br/reader035/viewer/2022070507/5706384c1a28abb8238f61c5/html5/thumbnails/35.jpg)
Análise de Casos de Uso
Exemplo de Diagrama de Colaboração da Análise
![Page 36: O Processo Unified zProcesso de Desenvolvimento de Software zElementos Participantes yTrabalhadores yAtividades yRecursos Humanos yArtefatos de Software](https://reader035.vdocuments.com.br/reader035/viewer/2022070507/5706384c1a28abb8238f61c5/html5/thumbnails/36.jpg)
Análise de uma Classe
![Page 37: O Processo Unified zProcesso de Desenvolvimento de Software zElementos Participantes yTrabalhadores yAtividades yRecursos Humanos yArtefatos de Software](https://reader035.vdocuments.com.br/reader035/viewer/2022070507/5706384c1a28abb8238f61c5/html5/thumbnails/37.jpg)
Análise de uma Classe
Objetivos identificação e formalização das responsabilidades de
uma classe de análise – contrato identificação e formalização dos atributos e
relacionamentos de uma classe de análise – enriquecimento do diagrama de classes
captura de requisitos especiais Identificação de Responsabilidades
Responsabilidades: papéis que objetos da classe assumem em diferentes realizações de casos de uso
Associadas às mensagens que uma classe pode receber
![Page 38: O Processo Unified zProcesso de Desenvolvimento de Software zElementos Participantes yTrabalhadores yAtividades yRecursos Humanos yArtefatos de Software](https://reader035.vdocuments.com.br/reader035/viewer/2022070507/5706384c1a28abb8238f61c5/html5/thumbnails/38.jpg)
Análise de uma Classe
Descrição de Responsabilidades por meio de Contratos Contratos: descrevem as responsabilidades de uma determinada
classe, em termos de quais mudanças no estado do objeto são realizadas quando este recebe mensagens (ou invocações)
descrevem O QUE o objeto deve fazer, sem explicar COMO ele o faz
Para cada mensagem aparecendo em um diagrama de colaboração, deve haver um contrato correspondente
Seções de um Contrato Um contrato está dividido em seções Cada seção provê informações sobre uma parte específica do
contrato Nem todas as seções são obrigatórias, devendo aparecer
quando necessário
![Page 39: O Processo Unified zProcesso de Desenvolvimento de Software zElementos Participantes yTrabalhadores yAtividades yRecursos Humanos yArtefatos de Software](https://reader035.vdocuments.com.br/reader035/viewer/2022070507/5706384c1a28abb8238f61c5/html5/thumbnails/39.jpg)
Análise de uma Classe
Seções de um Contrato Nome: nome da operação e eventualmente seus parâmetros Responsabilidades: uma descrição informal das
responsabilidades que a operação deve implementar Tipo:conceitual, classe de software ou interface Referências Cruzadas: outras classes que utilizam o mesmo
contrato, etc. Notas: informações adicionais, algoritmos, etc. Exceções: casos excepcionais Saídas Secundárias: saídas não relacionadas à interface com o
usuário, e.g. mensagens de erros, logs, etc. Pré-Condições: condições referentes ao estado do sistema antes
da execução da operação Pós-Condições: estado do sistema após a conclusão da
operação
![Page 40: O Processo Unified zProcesso de Desenvolvimento de Software zElementos Participantes yTrabalhadores yAtividades yRecursos Humanos yArtefatos de Software](https://reader035.vdocuments.com.br/reader035/viewer/2022070507/5706384c1a28abb8238f61c5/html5/thumbnails/40.jpg)
Analisando Pacotes
![Page 41: O Processo Unified zProcesso de Desenvolvimento de Software zElementos Participantes yTrabalhadores yAtividades yRecursos Humanos yArtefatos de Software](https://reader035.vdocuments.com.br/reader035/viewer/2022070507/5706384c1a28abb8238f61c5/html5/thumbnails/41.jpg)
Analisando Pacotes
Objetivos garantir a independência entre diferentes pacotes garantir que um pacote de análise implementa seu propósito de
realizar classes de domínio ou casos de uso descrever dependências entre pacotes, de tal forma que o efeito
de mudanças futuras possa ser estimado Guidelines para a Análise de Pacotes
definir e formalizar as dependências entre pacotes, dependendo das classes que estes contiverem
garantir que os pacotes contenham as classes corretas. Deve-se tentar manter os pacotes coesos, por meio da inclusão somente de objetos que estejam funcionalmente correlacionados
tentar limitar as dependências entre pacotes - deve-se considerar a relocação de classes que criem muitas dependências entre pacotes
![Page 42: O Processo Unified zProcesso de Desenvolvimento de Software zElementos Participantes yTrabalhadores yAtividades yRecursos Humanos yArtefatos de Software](https://reader035.vdocuments.com.br/reader035/viewer/2022070507/5706384c1a28abb8238f61c5/html5/thumbnails/42.jpg)
Design
Objetivos do Design Requisitos não-funcionais e restrições relacionadas a:
linguagens de programação, reuso de componentes, sistemas operacionais, tecnologias de distribuição e concorrência, tecnologias de bancos de dados, tecnologias de interface com o usuário, tecnologias de gerenciamento de transações, etc ...
Definição de subsistemas, interfaces e classes Decomposição do trabalho entre equipes de trabalho Interfaces entre subsistemas
arquitetura do software, para a sincronização entre diferentes equipes de trabalho
Especificação de elementos lógicos Abstração objetiva da implementação do sistema
implementação seja um mero refinamento para o design geração automática de código
![Page 43: O Processo Unified zProcesso de Desenvolvimento de Software zElementos Participantes yTrabalhadores yAtividades yRecursos Humanos yArtefatos de Software](https://reader035.vdocuments.com.br/reader035/viewer/2022070507/5706384c1a28abb8238f61c5/html5/thumbnails/43.jpg)
Patterns e Design Patterns
Patterns desenvolvedores de software orientado a objetos experientes
acumularam um repertório de princípios gerais e soluções que os guiam frequentemente em suas decisões no desenvolvimento de novos softwares
esses princípios são formalizados/compilados, dando origem aos chamados Patterns (padrões)
patterns codificam um conhecimento comum sobre princípios de como resolver problemas que aparecem repetidamente
Formato par problema/solução que pode ser aplicado em novos
contextos, acompanhados de conselhos sobre como devem ser aplicados
nomes sugestivos: enraízam o conceito do pattern em nossa memória e promovem seu uso, sempre que possível
![Page 44: O Processo Unified zProcesso de Desenvolvimento de Software zElementos Participantes yTrabalhadores yAtividades yRecursos Humanos yArtefatos de Software](https://reader035.vdocuments.com.br/reader035/viewer/2022070507/5706384c1a28abb8238f61c5/html5/thumbnails/44.jpg)
Patterns e Design Patterns
Origem dos Patterns “Design Patterns: Elements of Reusable Object-Oriented
Software” de Erich Gamma, Richard Helm, Ralph Johnson e John Vlissides (Gang of Four - GoF)
Vários diferentes domínios:organizações, processos, ensino, arquitetura, etc….
Atualmente: arquitetura e design de software, outras fases do desenvolvimento de software (análise, etc…)
Outros livros:Pattern-Oriented Software Architecture: A System of Patterns”
(POSA book), de Frank Buschmann, Regine Meunier, Hans Rohnert, Peter Somerlad e Michael Stal (Siemens Gang of Five - GoV)
Pattern Languages of Program Design and PLPD 2 - selected papers from 1st and 2nd conferences on Patterns Languages of Program Design
![Page 45: O Processo Unified zProcesso de Desenvolvimento de Software zElementos Participantes yTrabalhadores yAtividades yRecursos Humanos yArtefatos de Software](https://reader035.vdocuments.com.br/reader035/viewer/2022070507/5706384c1a28abb8238f61c5/html5/thumbnails/45.jpg)
Frameworks
Frameworks de Software são mini-arquiteturas reutilizáveis que provêm a estrutura
genérica e comportamento para famílias de abstrações de software, junto com um contexto de metáforas que especificam sua aplicação e uso dentro de um dado domínio
correspondem a um conjunto de classes cooperantes que permitem uma reutilização de design para uma classe de software específica. Um framework provê uma orientação arquitetural, definindo quais as responsabilidade e colaborações entre objetos. Um designer customiza um framework para uma aplicação em particular, normalmente por meio do sub-classeamento e geração de instâncias de classes derivadas das classes do framework
reutilização do design por meio da reutilização do código implementação de um sistema de design patterns
![Page 46: O Processo Unified zProcesso de Desenvolvimento de Software zElementos Participantes yTrabalhadores yAtividades yRecursos Humanos yArtefatos de Software](https://reader035.vdocuments.com.br/reader035/viewer/2022070507/5706384c1a28abb8238f61c5/html5/thumbnails/46.jpg)
Design
![Page 47: O Processo Unified zProcesso de Desenvolvimento de Software zElementos Participantes yTrabalhadores yAtividades yRecursos Humanos yArtefatos de Software](https://reader035.vdocuments.com.br/reader035/viewer/2022070507/5706384c1a28abb8238f61c5/html5/thumbnails/47.jpg)
Design Arquitetural
![Page 48: O Processo Unified zProcesso de Desenvolvimento de Software zElementos Participantes yTrabalhadores yAtividades yRecursos Humanos yArtefatos de Software](https://reader035.vdocuments.com.br/reader035/viewer/2022070507/5706384c1a28abb8238f61c5/html5/thumbnails/48.jpg)
Design Arquitetural
Objetivo desenvolver um outline dos modelos de design e de
distribuição, bem como sua arquitetura, identificando-se os seguintes:
nós computacionais envolvidos e arquitetura de rede subsistemas e suas interfaces classes de design arquiteturalmente significativas, tais como
classes ativas mecanismos genéricos de design que garantam a implementação
dos requisitos especiais sobre persistência, distribuição, desempenho, etc.
Reuso nesta atividade, considera-se as diferentes possibilidade de
reuso, tais como o reuso de partes, componentes, subsistemas, etc...
![Page 49: O Processo Unified zProcesso de Desenvolvimento de Software zElementos Participantes yTrabalhadores yAtividades yRecursos Humanos yArtefatos de Software](https://reader035.vdocuments.com.br/reader035/viewer/2022070507/5706384c1a28abb8238f61c5/html5/thumbnails/49.jpg)
Design Arquitetural
Sistemas de Software Aplicações Monolíticas Aplicações Multi-Thread Sistemas Cliente-Servidor Sistemas Baseados em Componentes
![Page 50: O Processo Unified zProcesso de Desenvolvimento de Software zElementos Participantes yTrabalhadores yAtividades yRecursos Humanos yArtefatos de Software](https://reader035.vdocuments.com.br/reader035/viewer/2022070507/5706384c1a28abb8238f61c5/html5/thumbnails/50.jpg)
Design Arquitetural
Identificação de Nós e Configuração de Rede configuração de rede pode ser fundamental para a aplicação
em desenvolvimento configurações de rede normalmente utilizam uma arquitetura
em três camadas aspectos da configuração de rede incluem:
quais nós estão envolvidos e quais suas capacidades que tipo de conexões há entre os nós e quais protocolos utilizam quais as características das conexões (capacidade, qualidade, etc) existe necessidade de processamento redundante, etc..
Conhecendo os limites e possibilidades dos nós e suas conexões, o arquiteto pode incorporar tecnologias tais como ORBs (Object Request Brokers), serviços de replicação de dados, etc ...
![Page 51: O Processo Unified zProcesso de Desenvolvimento de Software zElementos Participantes yTrabalhadores yAtividades yRecursos Humanos yArtefatos de Software](https://reader035.vdocuments.com.br/reader035/viewer/2022070507/5706384c1a28abb8238f61c5/html5/thumbnails/51.jpg)
Design Arquitetural
Exemplo de Identificação de Nós e Configuração de Rede cada configuração de rede, incluindo configurações
especiais para teste e simulações, deve ser descrita em um diagrama de distribuição em separado
![Page 52: O Processo Unified zProcesso de Desenvolvimento de Software zElementos Participantes yTrabalhadores yAtividades yRecursos Humanos yArtefatos de Software](https://reader035.vdocuments.com.br/reader035/viewer/2022070507/5706384c1a28abb8238f61c5/html5/thumbnails/52.jpg)
Design Arquitetural
Identificando Subsistemas e suas Dependências
![Page 53: O Processo Unified zProcesso de Desenvolvimento de Software zElementos Participantes yTrabalhadores yAtividades yRecursos Humanos yArtefatos de Software](https://reader035.vdocuments.com.br/reader035/viewer/2022070507/5706384c1a28abb8238f61c5/html5/thumbnails/53.jpg)
Design Arquitetural
Identificando Interfaces de Subsistemas interfaces de subsistemas definem operações que são
acessíveis “de fora” do subsistema essas interfaces são providas por classes ou outros
subsistemas (recursivamente) dentro do subsistema inicialmente, antes que o conteúdo de um subsistema seja
conhecido começa-se considerando as dependências entre subsistemas em seguida, analisa-se as classes dentro dos pacotes de análise
interfaces para os subsistemas de middleware e software de sistema
interfaces pré-definidas pelo produto utilizado não basta identificar somente quais são as interfaces
identificar as operações disponibilizadas por cada interface
![Page 54: O Processo Unified zProcesso de Desenvolvimento de Software zElementos Participantes yTrabalhadores yAtividades yRecursos Humanos yArtefatos de Software](https://reader035.vdocuments.com.br/reader035/viewer/2022070507/5706384c1a28abb8238f61c5/html5/thumbnails/54.jpg)
Design Arquitetural
Identificando Classes de Design Arquiteturalmente Significativas classes de design derivadas de classes de análise identificação de classes ativas: considerações sobre os
requisitos de concorrência do sistemarequisitos sobre desempenho, throughput, disponibilidade e tempo
de resposta necessários pelos diferentes atores interagindo com o sistema (e.g. caso o ator demande certo tempo de resposta, deve-se disponibilizar um objeto ativo somente para a interação)
distribuição do sistema pelos nós (e.g. caso seja necessário suportar distribuição por diversos nós, cada nó demandará pelo menos um objeto ativo para gerenciar a comunicação)
outros requisitos, tais como requisitos de inicialização e shutdown, sobrevivência, evitação de deadlocks, capacidade de reconfiguração de nós, etc ...
![Page 55: O Processo Unified zProcesso de Desenvolvimento de Software zElementos Participantes yTrabalhadores yAtividades yRecursos Humanos yArtefatos de Software](https://reader035.vdocuments.com.br/reader035/viewer/2022070507/5706384c1a28abb8238f61c5/html5/thumbnails/55.jpg)
Design Arquitetural
Identificação de Mecanismos Genéricos de Design neste passo, estudam-se os requisitos comuns, tais como
os requisitos especiais identificados durante a análise, decidindo-se como implementá-los, dadas as tecnologias de implementação disponíveis
resultado é um conjunto de mecanismos genéricos de design, instanciados em classes de design
tipos de requisitos instanciados persistência distribuição de objetos transparente (objetos distribuídos) requisitos de segurança detecção e recuperação de erros gerenciamento de transações
![Page 56: O Processo Unified zProcesso de Desenvolvimento de Software zElementos Participantes yTrabalhadores yAtividades yRecursos Humanos yArtefatos de Software](https://reader035.vdocuments.com.br/reader035/viewer/2022070507/5706384c1a28abb8238f61c5/html5/thumbnails/56.jpg)
Design de Casos de Uso
![Page 57: O Processo Unified zProcesso de Desenvolvimento de Software zElementos Participantes yTrabalhadores yAtividades yRecursos Humanos yArtefatos de Software](https://reader035.vdocuments.com.br/reader035/viewer/2022070507/5706384c1a28abb8238f61c5/html5/thumbnails/57.jpg)
Design de Casos de Uso
Objetivos identificação das classes de design e subsistemas cujas
instâncias são necessárias para realizar o fluxo de eventos de um caso de uso
distribuição do comportamento do caso de uso entre objetos de design interagindo entre si ou com outros subsistemas
definição dos requisitos sobre as operações disponíveis nas classes de design e/ou subsistemas com interfaces
Sub-Atividades identificação das classes de design participantes descrição das interações entre objetos de design identificação de subsistemas participantes e suas interfaces descrição das interações entre subsistemas captura dos requisitos de implementação para o caso de uso
![Page 58: O Processo Unified zProcesso de Desenvolvimento de Software zElementos Participantes yTrabalhadores yAtividades yRecursos Humanos yArtefatos de Software](https://reader035.vdocuments.com.br/reader035/viewer/2022070507/5706384c1a28abb8238f61c5/html5/thumbnails/58.jpg)
Design de Casos de Uso
Identificação das Classes de Design Participantes estudo das classes de análise estudo dos requisitos especiais diagrama de classes de design
Descrição das Interações diagramas de sequência ou de
colaboração
![Page 59: O Processo Unified zProcesso de Desenvolvimento de Software zElementos Participantes yTrabalhadores yAtividades yRecursos Humanos yArtefatos de Software](https://reader035.vdocuments.com.br/reader035/viewer/2022070507/5706384c1a28abb8238f61c5/html5/thumbnails/59.jpg)
Design de Casos de Uso
Identificação de Subsistemas e Interfaces estudo das classes de análise estudo dos requisitos especiais diagrama de classes
Descrição das Interações entre Subsistemas diagramas de sequência
lifelines denotam subsistemas e não objetos cada subsistema deve ter sua própria lifeline mensagens dizem respeito a operações da interface do
subsistema Captura de Requisitos de Implementação
captura de requisitos (não funcionais) que afetam diretamente a implementação
![Page 60: O Processo Unified zProcesso de Desenvolvimento de Software zElementos Participantes yTrabalhadores yAtividades yRecursos Humanos yArtefatos de Software](https://reader035.vdocuments.com.br/reader035/viewer/2022070507/5706384c1a28abb8238f61c5/html5/thumbnails/60.jpg)
Design de Classes
![Page 61: O Processo Unified zProcesso de Desenvolvimento de Software zElementos Participantes yTrabalhadores yAtividades yRecursos Humanos yArtefatos de Software](https://reader035.vdocuments.com.br/reader035/viewer/2022070507/5706384c1a28abb8238f61c5/html5/thumbnails/61.jpg)
Design de Classes
Objetivos criação de classes de design que exercem seu papel na
realização do caso de uso, obedecendo os requisitos não-funcionais que se aplicam
aspectos sendo detalhados: operações atributos relacionamentos dos quais participa métodos (como realizar as operações) estados válidos dependências para com mecanismos genéricos de design requisitos importantes para a implementação realização correta das interfaces com as quais está envolvida
![Page 62: O Processo Unified zProcesso de Desenvolvimento de Software zElementos Participantes yTrabalhadores yAtividades yRecursos Humanos yArtefatos de Software](https://reader035.vdocuments.com.br/reader035/viewer/2022070507/5706384c1a28abb8238f61c5/html5/thumbnails/62.jpg)
Design de Classes
Sub-Etapas criando um outline da classe de design identificando operações e atributos identificando associações, agregações e generalizações descrevendo métodos descrevendo estados gerenciando requisitos especiais
![Page 63: O Processo Unified zProcesso de Desenvolvimento de Software zElementos Participantes yTrabalhadores yAtividades yRecursos Humanos yArtefatos de Software](https://reader035.vdocuments.com.br/reader035/viewer/2022070507/5706384c1a28abb8238f61c5/html5/thumbnails/63.jpg)
Design de Subsistemas
![Page 64: O Processo Unified zProcesso de Desenvolvimento de Software zElementos Participantes yTrabalhadores yAtividades yRecursos Humanos yArtefatos de Software](https://reader035.vdocuments.com.br/reader035/viewer/2022070507/5706384c1a28abb8238f61c5/html5/thumbnails/64.jpg)
Design de Subsistemas
Objetivos garantir que os subsistemas sejam tão independentes
quanto possível de outros subsistemas e suas interfaces garantir que os subsistemas provêm uma interface adequada garantir que os subsistemas realizam seu propósito, ou seja,
oferecem uma realização adequada das operações definidas por suas interfaces
Sub-Etapas Gerenciamento das Dependências entre Subsistemas Gerenciamento das Interfaces providas pelo susbsistema Gerenciamento do Conteúdo dos subsistemas
para cada interface, associa com as classes de design do subsistema que provê a funcionalidade
![Page 65: O Processo Unified zProcesso de Desenvolvimento de Software zElementos Participantes yTrabalhadores yAtividades yRecursos Humanos yArtefatos de Software](https://reader035.vdocuments.com.br/reader035/viewer/2022070507/5706384c1a28abb8238f61c5/html5/thumbnails/65.jpg)
Implementação
Implementação utiliza-se os artefatos desenvolvidos no design para
implementar o sistema em termos de seus componentes, ou seja, código fonte, scripts, binários, executáveis, etc ...
Objetivos planejar a integração do sistema necessária na iteração
corrente distribuir o sistema entre componentes executáveis
localizados nos nós do modelo de distribuição implementação das classes de design e dos subsistemas
especificados no design (geração de código) teste individual dos componentes e posterior integração
em módulos executáveis
![Page 66: O Processo Unified zProcesso de Desenvolvimento de Software zElementos Participantes yTrabalhadores yAtividades yRecursos Humanos yArtefatos de Software](https://reader035.vdocuments.com.br/reader035/viewer/2022070507/5706384c1a28abb8238f61c5/html5/thumbnails/66.jpg)
Implementação
Componentes possuem diversos estereótipos
«executable», «file», «library», «table», «document» possuem relacionamentos do tipo «trace» com os
elementos do modelo que implementam podem implementar individualmente diversos modelos
diferentes
![Page 67: O Processo Unified zProcesso de Desenvolvimento de Software zElementos Participantes yTrabalhadores yAtividades yRecursos Humanos yArtefatos de Software](https://reader035.vdocuments.com.br/reader035/viewer/2022070507/5706384c1a28abb8238f61c5/html5/thumbnails/67.jpg)
Implementação
![Page 68: O Processo Unified zProcesso de Desenvolvimento de Software zElementos Participantes yTrabalhadores yAtividades yRecursos Humanos yArtefatos de Software](https://reader035.vdocuments.com.br/reader035/viewer/2022070507/5706384c1a28abb8238f61c5/html5/thumbnails/68.jpg)
Implementação
Subsistemas de Implementação package em Java project em VisualBasic diretório de arquivos em um projeto C++ subsistema em IDEs tais como o Rational Apex component view package, em ferramentas de
modelagem visual tais como o Rational Rose
![Page 69: O Processo Unified zProcesso de Desenvolvimento de Software zElementos Participantes yTrabalhadores yAtividades yRecursos Humanos yArtefatos de Software](https://reader035.vdocuments.com.br/reader035/viewer/2022070507/5706384c1a28abb8238f61c5/html5/thumbnails/69.jpg)
Implementação
![Page 70: O Processo Unified zProcesso de Desenvolvimento de Software zElementos Participantes yTrabalhadores yAtividades yRecursos Humanos yArtefatos de Software](https://reader035.vdocuments.com.br/reader035/viewer/2022070507/5706384c1a28abb8238f61c5/html5/thumbnails/70.jpg)
Implementação Arquitetural
![Page 71: O Processo Unified zProcesso de Desenvolvimento de Software zElementos Participantes yTrabalhadores yAtividades yRecursos Humanos yArtefatos de Software](https://reader035.vdocuments.com.br/reader035/viewer/2022070507/5706384c1a28abb8238f61c5/html5/thumbnails/71.jpg)
Implementação Arquitetural
Objetivo criar um outline do modelo de implementação
identificação de componentes arquiteturalmente significativos, tais como componentes executáveis
mapeamento desses componentes em nós da configuração de rede
Identificação de Componentes arquiteturalmente significativos diagrama de componentes
Identificação dos Componentes Executáveis e seu Mapeamento nos Nós diagrama de distribuição, mostrando onde se localizam
componentesobjetos ativos (aqueles com Thread de controle individual)
![Page 72: O Processo Unified zProcesso de Desenvolvimento de Software zElementos Participantes yTrabalhadores yAtividades yRecursos Humanos yArtefatos de Software](https://reader035.vdocuments.com.br/reader035/viewer/2022070507/5706384c1a28abb8238f61c5/html5/thumbnails/72.jpg)
Integração do Sistema
![Page 73: O Processo Unified zProcesso de Desenvolvimento de Software zElementos Participantes yTrabalhadores yAtividades yRecursos Humanos yArtefatos de Software](https://reader035.vdocuments.com.br/reader035/viewer/2022070507/5706384c1a28abb8238f61c5/html5/thumbnails/73.jpg)
Integração do Sistema
Objetivos criação da um plano de construção integrado, descrevendo as
construções necessárias na iteração corrente e quais os requisitos que essa construção implementa
definição efetiva de quais componentes serão integrados e criação de scripts de compilação e linkagem
Planejamento da Construção verificação de implementações de iterações anteriores e
eventual reuso de partes já consolidadas adição de funcionalidades para a construção corrente, por
meio da adição de novos casos de uso Integrando a Construção
criação de scripts de compilação e linkagem das versões corretas dos diferentes componentes sendo integrados
![Page 74: O Processo Unified zProcesso de Desenvolvimento de Software zElementos Participantes yTrabalhadores yAtividades yRecursos Humanos yArtefatos de Software](https://reader035.vdocuments.com.br/reader035/viewer/2022070507/5706384c1a28abb8238f61c5/html5/thumbnails/74.jpg)
Implementação de Subsistemas
![Page 75: O Processo Unified zProcesso de Desenvolvimento de Software zElementos Participantes yTrabalhadores yAtividades yRecursos Humanos yArtefatos de Software](https://reader035.vdocuments.com.br/reader035/viewer/2022070507/5706384c1a28abb8238f61c5/html5/thumbnails/75.jpg)
Implementação de Subsistemas
Objetivos garantir que a implementação de um subsistema cumpra seu
papel, a cada construção, como estipulado pelo plano de construção integrada
garantir que os casos de uso e cenários estejam corretos e que as interfaces estejam corretas
Gerenciamento do Conteúdo de Subsistemas mesmo que o conteúdo de um subsistema já esteja
determinado pelo arquiteto, ele pode requerer pequenos refinamentos implementados pelo engenheiro de componentes, a medida que a implementação se desenvolve
à medida que subsistemas contenham outros subsistemas recursivamente, a metodologia de mapeamento entre componentes e classes de design é análoga em cada nível
![Page 76: O Processo Unified zProcesso de Desenvolvimento de Software zElementos Participantes yTrabalhadores yAtividades yRecursos Humanos yArtefatos de Software](https://reader035.vdocuments.com.br/reader035/viewer/2022070507/5706384c1a28abb8238f61c5/html5/thumbnails/76.jpg)
Implementando Classes
![Page 77: O Processo Unified zProcesso de Desenvolvimento de Software zElementos Participantes yTrabalhadores yAtividades yRecursos Humanos yArtefatos de Software](https://reader035.vdocuments.com.br/reader035/viewer/2022070507/5706384c1a28abb8238f61c5/html5/thumbnails/77.jpg)
Implementando Classes
Objetivos implementação de classes de design na forma de
componentes distribuição do código fonte em um ou diversos arquivos
• componentes do tipo «file» geração do código fonte a partir das classes de design e dos
relacionamentos em que participa• esqueletos de código podem ser gerados automaticamente
implementação das operações das classes de design em termos de métodos
• alguns tipos de operações podem também ser geradas automaticamente, sendo complementadas com edição posterior
verificação de que o componente provê a mesma interface que a classe de design que implementa
eventualmente, conserto de defeitos, quando a classe já havia sido implementada em outras iterações
![Page 78: O Processo Unified zProcesso de Desenvolvimento de Software zElementos Participantes yTrabalhadores yAtividades yRecursos Humanos yArtefatos de Software](https://reader035.vdocuments.com.br/reader035/viewer/2022070507/5706384c1a28abb8238f61c5/html5/thumbnails/78.jpg)
Teste de Unidade
![Page 79: O Processo Unified zProcesso de Desenvolvimento de Software zElementos Participantes yTrabalhadores yAtividades yRecursos Humanos yArtefatos de Software](https://reader035.vdocuments.com.br/reader035/viewer/2022070507/5706384c1a28abb8238f61c5/html5/thumbnails/79.jpg)
Teste de Unidade
Objetivos realização de um teste individual do componente
implementado, sem considerar sua posterior integração Tipos de Testes
Teste de Especificação verifica o comportamento observável externo da unidade, sem
entrar no mérito de como esse comportamento é implementado focaliza nas entradas e saídas da unidade
Teste Estrutural verifica a implementação interna da unidade, fazendo com que
cada trecho do código seja executado Outros Testes
testes de desempenho, uso de memória, escalabilidade e capacidade
![Page 80: O Processo Unified zProcesso de Desenvolvimento de Software zElementos Participantes yTrabalhadores yAtividades yRecursos Humanos yArtefatos de Software](https://reader035.vdocuments.com.br/reader035/viewer/2022070507/5706384c1a28abb8238f61c5/html5/thumbnails/80.jpg)
Testes
Fase de Testes verificação dos resultados da implementação por meio do
teste de cada módulo do sistema e sua integração Objetivos
planejamento dos testes a serem executados em cada iteração
design e implementação dos testes por meio de casos de teste que especificam o que testar e quais os procedimentos a serem utilizados para os testes
criação de componentes de teste executáveis para a automação de testes, quando possível
avaliar sistematicamente os resultados de cada teste e encaminhar os módulos defectivos para que estes possam ser retrabalhados
![Page 81: O Processo Unified zProcesso de Desenvolvimento de Software zElementos Participantes yTrabalhadores yAtividades yRecursos Humanos yArtefatos de Software](https://reader035.vdocuments.com.br/reader035/viewer/2022070507/5706384c1a28abb8238f61c5/html5/thumbnails/81.jpg)
Testes
Modelos de Teste descreve como componentes executáveis do modelo de
implementação são testados por meio de testes de integração e testes de sistema
descreve os aspectos específicos do sistema que serão testados
coleção de casos de teste, procedimentos de teste e componentes de teste
Caso de Teste corresponde a um caso de uso, só que com finalidades de teste especifica um cenário de teste, incluindo o que testar, com que
entradas e com quais resultados esperados caso de teste pode estar associado a um caso de uso ou à
realização do caso de uso no design
![Page 82: O Processo Unified zProcesso de Desenvolvimento de Software zElementos Participantes yTrabalhadores yAtividades yRecursos Humanos yArtefatos de Software](https://reader035.vdocuments.com.br/reader035/viewer/2022070507/5706384c1a28abb8238f61c5/html5/thumbnails/82.jpg)
Testes
Procedimentos de Teste especifica como realizar
um ou mais casos de teste
Componente de Teste automatizam um ou mais
procedimentos de teste linguagens de script ou
linguagens de programação
![Page 83: O Processo Unified zProcesso de Desenvolvimento de Software zElementos Participantes yTrabalhadores yAtividades yRecursos Humanos yArtefatos de Software](https://reader035.vdocuments.com.br/reader035/viewer/2022070507/5706384c1a28abb8238f61c5/html5/thumbnails/83.jpg)
Testes
Tipos de Teste Testes de Instalação
verificam que o sistema pode ser instalado na plataforma do cliente e que o sistema opera corretamente após instalado
Testes de Configuração verificam que o sistema opera corretamente sob diferentes
configurações Testes Negativos
tentam ocasionar falhas no sistema para revelar suas fraquezas tenta-se utilizar o sistema de maneiras para as quais ele não foi
projetado, e.g. testando-se configurações de rede defeituosas, hardware insuficiente ou demanda de uso (carga) intensiva
Testes de Stress tentam verificar como o sistema se comporta quando os recursos
disponíveis são insuficientes ou estão indisponíveis
![Page 84: O Processo Unified zProcesso de Desenvolvimento de Software zElementos Participantes yTrabalhadores yAtividades yRecursos Humanos yArtefatos de Software](https://reader035.vdocuments.com.br/reader035/viewer/2022070507/5706384c1a28abb8238f61c5/html5/thumbnails/84.jpg)
Testes
![Page 85: O Processo Unified zProcesso de Desenvolvimento de Software zElementos Participantes yTrabalhadores yAtividades yRecursos Humanos yArtefatos de Software](https://reader035.vdocuments.com.br/reader035/viewer/2022070507/5706384c1a28abb8238f61c5/html5/thumbnails/85.jpg)
Planejamento de Testes
![Page 86: O Processo Unified zProcesso de Desenvolvimento de Software zElementos Participantes yTrabalhadores yAtividades yRecursos Humanos yArtefatos de Software](https://reader035.vdocuments.com.br/reader035/viewer/2022070507/5706384c1a28abb8238f61c5/html5/thumbnails/86.jpg)
Planejamento de Testes
Objetivos planejar os esforços de teste dentro de uma iteração
descrevendo uma estratégia de testesestimando os requisitos para o esforço de teste, tais como
recursos humanos e do sistemacriando uma escala de testes a ser executada
Plano de Testes são construídos com base nos diversos modelos utilizados nas
fases de especificação, análise, design e implementação Estratégia Geral de Testes
que tipos de testes serão executados, como executá-los, quando executá-los e como avaliar os resultados dos testes
testes custam recursos e tempo, portanto deve-se efetuar uma solução de testes que tenha uma boa relação custo/benefício
![Page 87: O Processo Unified zProcesso de Desenvolvimento de Software zElementos Participantes yTrabalhadores yAtividades yRecursos Humanos yArtefatos de Software](https://reader035.vdocuments.com.br/reader035/viewer/2022070507/5706384c1a28abb8238f61c5/html5/thumbnails/87.jpg)
Projeto de Testes
![Page 88: O Processo Unified zProcesso de Desenvolvimento de Software zElementos Participantes yTrabalhadores yAtividades yRecursos Humanos yArtefatos de Software](https://reader035.vdocuments.com.br/reader035/viewer/2022070507/5706384c1a28abb8238f61c5/html5/thumbnails/88.jpg)
Projeto de Testes
Objetivos identificar e descrever casos de teste para cada módulo identificar e estruturar procedimentos de teste especificando
como realizar os casos de teste Sub-Etapas
Projetando casos de teste de integração Projetando casos de teste de sistema Projetando casos de teste regressivos
aproveitam casos de teste de iterações anteriores Identificando e Estruturando Procedimentos de Teste
Regra Geral deve-se utilizar um conjunto de testes que requeiram um mínimo
esforço, dado um plano de testes mínimo “overlap” entre casos de teste
![Page 89: O Processo Unified zProcesso de Desenvolvimento de Software zElementos Participantes yTrabalhadores yAtividades yRecursos Humanos yArtefatos de Software](https://reader035.vdocuments.com.br/reader035/viewer/2022070507/5706384c1a28abb8238f61c5/html5/thumbnails/89.jpg)
Implementação de Testes
![Page 90: O Processo Unified zProcesso de Desenvolvimento de Software zElementos Participantes yTrabalhadores yAtividades yRecursos Humanos yArtefatos de Software](https://reader035.vdocuments.com.br/reader035/viewer/2022070507/5706384c1a28abb8238f61c5/html5/thumbnails/90.jpg)
Implementação de Testes
Objetivos automatizar procedimentos de teste por meio da criação de
componentes de teste, se possível (nem todos os procedimentos de teste podem ser automatizados)
Componentes de Teste criados utilizando os procedimentos de teste como entrada quando se utiliza uma ferramenta de automação, um
conjunto de ações são previamente criadas para que o módulo em questão seja testado. A própria ferramenta se encarrega de criar os componentes de teste
quando programando os componentes de teste explicitamente, utiliza-se os procedimentos de teste como uma forma de especificação para que os componentes de teste sejam desenvolvidos
![Page 91: O Processo Unified zProcesso de Desenvolvimento de Software zElementos Participantes yTrabalhadores yAtividades yRecursos Humanos yArtefatos de Software](https://reader035.vdocuments.com.br/reader035/viewer/2022070507/5706384c1a28abb8238f61c5/html5/thumbnails/91.jpg)
Teste de Integração
![Page 92: O Processo Unified zProcesso de Desenvolvimento de Software zElementos Participantes yTrabalhadores yAtividades yRecursos Humanos yArtefatos de Software](https://reader035.vdocuments.com.br/reader035/viewer/2022070507/5706384c1a28abb8238f61c5/html5/thumbnails/92.jpg)
Teste de Integração
Objetivos realizar os testes de integração especificados para cada módulo
do sistema Sequência de Testes de Integração
realizar os testes de integração relevantes por meio da execução manual dos procedimentos de teste para cada caso de teste ou por meio de algum componente de teste disponível para o procedimento de teste em questão
comparação dos resultados com os resultados esperados e a discriminação dos casos que apresentaram resultados inesperados
relatar os defeitos encontrados ao engenheiro de componentes, para que estes possam corrigir os componentes defeituosos
relatar os defeitos ao engenheiro de testes, para que este possa estimar os resultados finais da sequência de testes
![Page 93: O Processo Unified zProcesso de Desenvolvimento de Software zElementos Participantes yTrabalhadores yAtividades yRecursos Humanos yArtefatos de Software](https://reader035.vdocuments.com.br/reader035/viewer/2022070507/5706384c1a28abb8238f61c5/html5/thumbnails/93.jpg)
Teste de Sistema
![Page 94: O Processo Unified zProcesso de Desenvolvimento de Software zElementos Participantes yTrabalhadores yAtividades yRecursos Humanos yArtefatos de Software](https://reader035.vdocuments.com.br/reader035/viewer/2022070507/5706384c1a28abb8238f61c5/html5/thumbnails/94.jpg)
Teste de Sistema
Objetivos realizar os testes de sistema especificados a cada iteração,
capturando os resultados do teste Teste de Sistema
se inicia quando os testes de integração indicam que o sistema atende as metas de qualidade quanto a integração de seus componentes para a iteração corrente (e.g. 95 % dos testes de integração executam com resultado esperado)
são realizados de maneira análoga aos testes de integração (i.e. seguindo uma sequência de testes análoga ao dos testes de integração
avaliam o comportamento do funcionamento do sistema como um todo, e não somente com relação à integração individual entre alguns de seus componentes
![Page 95: O Processo Unified zProcesso de Desenvolvimento de Software zElementos Participantes yTrabalhadores yAtividades yRecursos Humanos yArtefatos de Software](https://reader035.vdocuments.com.br/reader035/viewer/2022070507/5706384c1a28abb8238f61c5/html5/thumbnails/95.jpg)
Avaliação de Testes
![Page 96: O Processo Unified zProcesso de Desenvolvimento de Software zElementos Participantes yTrabalhadores yAtividades yRecursos Humanos yArtefatos de Software](https://reader035.vdocuments.com.br/reader035/viewer/2022070507/5706384c1a28abb8238f61c5/html5/thumbnails/96.jpg)
Avaliação de Testes
Objetivo avaliação dos esforços de teste para a iteração corrente
comparação dos resultados com as metas especificadas no planejamento de testes
criação de métricas que determinem o nível de qualidade do software, especificando maiores testes que necessitem ser realizados
Exemplos de Métricas Métricas de Completude
derivadas da cobertura dos casos de teste e dos componentes de teste. Indicam qual a porcentagem de casos de teste que foram executados e qual a porcentagem de código que foi testada
Métricas de Confiabilidadebaseadas na análise dos defeitos descobertos com relação aos
casos que tiveram um resultado como esperado
![Page 97: O Processo Unified zProcesso de Desenvolvimento de Software zElementos Participantes yTrabalhadores yAtividades yRecursos Humanos yArtefatos de Software](https://reader035.vdocuments.com.br/reader035/viewer/2022070507/5706384c1a28abb8238f61c5/html5/thumbnails/97.jpg)
Referências Complementares
The Unified Software Development Process Ivar Jacobson, Grady Booch, James Rumbaugh Addison-Wesley, 1999 - ISBN 0-201-57169-2
UML Distilled, Second Edition: A Brief Guide to the Standard Object Modeling Language Martin Fowler, Kendall Scott, Grady Booch 2nd edition, Addison-Wesley, 1999 - ISBN 0-201-65783-X
Applying UML and Patterns Craig Larman Prentice Hall, 1998 - ISBN 0-137-48880-7
Unified Modeling Language (UML), version 1.5 Norma Técnica da OMG ftp://ftp.omg.org/pub/docs/formal/03-03-01.pdf