Laboratrio de Programao Projeto de Software Eng De

Laboratório de Programação Projeto de Software – Eng. De Requisitos e UML George Cabral

Definindo o Sucesso do Software Clientes satisfeitos p Eles estão satisfeitos quando você: p n n n Atende às expectativas Entrega no prazo Entrega no orçamento O Sucesso começa com a Gerência de Requisitos !!

Como os Projetos podem ter sucesso? p p Análise do Problema n Entenda o problema n Obtenha concordância dos envolvidos Levantamento dos Requisitos n n p Identifique quem usará o sistema (atores) Descubra como o sistema será usado (casos de uso) Gerência de Requisitos n n Especifique os requisitos completamente Gerencie expectativas, mudanças e erros Controle o aumento do escopo Defina a equipe e a mantenha informada

Fatores de Falha dos Projetos o Objetivos não estavam oclaros Ignorar um grupo de clientes I o Requisitos e especificações o incompletos Requisitos e especificações instáveis o(mudanças) Omitir um grupo de orequisitos Permitir inconsistências entre grupos de orequisitos Aceitar requisito inadequado, incorreto, indefinido, ou A oimpreciso Aceitar um requisito ambíguo e inconsistente A

Mas o que são Requisitos? n n n Os requisitos de um sistema de computação constituem uma especificação das características e propriedades do sistema ou Uma descrição do que o sistema deve fazer, de como ele deve se comportar, bem como das suas restrições de operação. É importante ressaltar que os requisitos descrevem "o que o sistema deve fazer"- e também "o que ele não deve fazer"- sem dizer "o como fazer".

Requisitos e Especificação n Requisito (IEEE) n n n Uma condição ou capacidade necessitada por um usuário para resolver um problema ou alcançar um objetivo Uma condição ou capacidade que deve ser satisfeita por um sistema para satisfazer um contrato ou um padrão Especificação: n n descrição rigorosa e minuciosa das características que um material, uma obra, ou um serviço deverá apresentar processo de representação dos requisitos de uma forma que leva à implementação bem-sucedida

Importância da Especificação Correta n Não importa quão bem projetado ou codificado está um programa, se ele for mal analisado e especificado desapontará o usuário e trará aborrecimentos ao desenvolvedor

Análise de Requisitos Definição e especificação de requisitos Documento de requisitos 7 8 Validação dos requisitos Entrada do processo Entendimento do domínio Coleta de requisitos 6 1 Atrib. Prioridade 5 4 2 3 Classificação Resolução de conflito

Entendimento do Domínio n n Desenvolver sistemas envolve domínios além de software e hardware Podemos ter que entender sobre n n n Contabilidade Saúde Supermercados Mercado Etc.

Coleta de Requisitos n n n A coleta de requisitos é feita através de técnicas Nesta etapa, os requisitos são simplesmente documentados à medida que são coletados Resulta em documento preliminar (draft)

Classificação dos Requisitos n n Esta etapa consiste basicamente em agrupar os diversos requisitos coletados em categorias bemdefinidos Por exemplo n n Requisitos Funcionais: descrevem o comportamento do sistema, suas ações para cada entrada, ou seja, é aquilo que descreve o que tem que ser feito pelo sistema. Requisitos não funcionais: expressam como deve ser feito. Em geral se relacionam com padrões de qualidade como confiabilidade, performance, robustez, etc.

Problema da Análise de Requisitos n n n Stakeholders em geral não sabem o querem Stakeholders expressam requisitos em sua terminologia Stakeholders diferentes podem gerar requisitos conflitantes

Problema da Análise de Requisitos n n Fatores políticos e organizacionais podem influenciar os requisitos do sistema Requisitos mudam durante o processo de análise. Stakeholders novos podem surgir e o ambiente de trabalho muda

Resolução de Conflitos n n n É normal que ocorram requisitos conflitantes Por exemplo n R-23: O sistema deve. . . n R-45: O sistema não deve. . . Cliente/usuário deve ser consultado para resolver conflitos (ambigüidades)

Atribuição de Prioridade n n n Alguns requisitos são mais urgentes que outros É essencial determinar a prioridade dos requisitos junto ao cliente Requisitos de maior prioridade são considerados em primeiro lugar

Prioridade n Requisitos podem ser vistos em três classes distintas n n Essenciais Importantes Desejáveis Em princípio, sistema deve resolver todos os requisitos de essenciais para desejáveis

Exemplo de Prioridade n [RF 001] Consulta X ao B. D. deve retornar dados A, B, C n n [RNF 001] Consulta X ao B. D. deve visualizar dados segundo padrão Y n n Prioridade: Essencial Prioridade: Importante [RNF 010] Consulta X ao B. D. deve usar cores azuis nos resultados n Prioridade: Desejável

Validação dos Requisitos n n n Será que realmentendi o que o cliente deseja? Devo me certificar de que não houve falha em nossa interação (comunicação) Há diversas técnicas de validação

Validação de Requisitos n n Demonstrar que os requisitos definem o sistema que o cliente realmente deseja Custos com erros de requisitos são altos n Consertar um erro de requisitos após entrega do sistema pode custar mais de 100 vezes o custo de um erro de implementação

Técnicas de Validação de Requisitos n Revisões de Requisitos n n Prototipação n n Análise manual sistemática dos requisitos Uso de modelo executável do sistema para avaliar requisitos Geração de Casos de Teste n Desenvolver testes específicos para os requisitos para avaliá-los

Gerenciamento de Requisitos n Gerenciamento de requisitos é o processo de controlar as mudanças dos requisitos durante n n O processo da engenharia de requisitos E desenvolvimento do sistema

Gerenciamento de Requisitos n Requisitos são inevitavelmente incompletos e inconsistentes n n Requisitos novos surgem durante o processo de acordo com mudanças necessidades do negócio e um entendimento melhor do sistema é desenvolvido Diferentes pontos de vista têm diferentes requisitos e esses geralmente são contraditórios

Rastreamento n n Responsável por dependências entre requisitos, suas origens e projeto do sistema Rastreamento de Origem n Associação entre requisitos e stakeholders que propuseram tais requisitos

Rastreamento n Rastreamento de Requisitos n n Rastreamento de Projeto n n Associação entre requisitos dependentes Associação dos requisitos com o projeto Usar hipertexto ou referência cruzada n Ou matriz de rastreamento

Estrutura de um Documento de Requisitos n n n n 1. 2. 3. 4. 5. 6. 7. 8. Introdução Definição dos Requisitos do Usuário Especificação dos Requisitos do Sistema Arquitetura do Sistema Modelos do Sistema Evolução do Sistema Apêndices Índice

Documento de Requisitos n Fonte: IEEE/ANSI (830 -1998) n 1. Introdução n n n 1. 1 1. 2 1. 3 1. 4 1. 5 Propósito do documento Escopo do sistema Glossário, acrônimos e abreviaturas Referências Descrição do resto do documento

Documento de Requisitos n Fonte: IEEE/ANSI (830 -1998) n 2. Descrição geral n n n 2. 1 2. 2 2. 3 2. 4 2. 5 Perspectiva do produto Funções do produto Características dos usuários Restrições gerais dependências

Documento de Requisitos n Fonte: IEEE/ANSI (830 -1998) n 3. Requisitos específicos n requisitos funcionais, não-funcionais, GUI com o usuário: n funcionalidade, interfaces externas, desempenho, restrições, atributos do sistema, caract. qualidade, . . .

Documento de Requisitos n n 4. Arquitetura do Sistema 5. Modelos do Sistema n n n n Diagrama de Atores Modelo de Caso de Uso Modelo de Análise Modelo de Projeto Diagrama de Pacotes 6. Evolução do Sistema (Futuro) 7. Apêndices 8. Índice

Abreviações e Glossário Abreviação Significado Explicação / Condição ou situação no sistema A Administrador Usuário com maiores privilégios no sistema AT Auto-treinamento Um dos três perfis de avaliação. O operador/treinando solicita ao sistema uma avaliação que lhe é montada de modo randômico a partir de alguns parâmetros CT Certificação Técnica Um dos três perfis de avaliação. Os supervisores (RL/RS) agendam com antecedência dia e hora da avaliação. É o teste que certifica o treinando/operador. O Operador Usuário. Treinando que realiza as avaliações. RL Responsável Local Usuário. Responsável, na unidade da empresa, por um grupo de operadores. Propõe, elimina e valida questões e avaliações. RS Responsável Setorial Usuário. Responsável por um setor da empresa. Coordena um ou mais RL. Propõe, elimina e valida questões e avaliações. TO Treinamento Orientado Um dos três perfis de avaliação. Serve para os RS/RL diagnosticarem o estágio da aprendizagem dos operadores. V Validador Usuário. Checa e valida as questões propostas pelos RS/RL. M Módulo Refere-se aos módulos do sistema. Backup Refere-se à cópia de dados de um dispositivo para o outro com o objetivo de posteriormente os recuperar (os dados), caso haja algum problema. Logon É a ação necessária para acessar um sistema computacional restrito inserindo uma identificação, podendo esta ser ou não única para cada usuário, e a senha relacionada a ela. Uma vez logado, o usuário passa a ser identificado no sistema, sendo restringido ou permitido a acessar recursos do sistema.

UML

O que é um modelo? n Construímos modelos para compreender melhor o sistema que estamos desenvolvendo. n Um modelo é uma simplificação da realidade. n Um modelo pode ser estrutural ou comportamental.

O que é um modelo?

O que é um modelo?

Por que modelar software? n Ajuda a ter uma visão geral do sistema n Permite especificar a estrutura e o comportamento do sistema n Proporciona um guia para a construção do sistema n Documenta as decisões tomadas

O que é a UML? n Unified Modeling Language (UML) é. . . uma linguagem gráfica para visualizar, especificar, construir e documentar os artefatos de um sistema de software. . resultado da unificação das notações utilizadas nos métodos Booch, OMT (Object Modeling Technique) e OOSE (Object. Oriented Software Engineering). . adotada por grande parte da indústria de software e por fornecedores de ferramentas CASE como linguagem padrão de modelagem. … utilizada com qualquer processo de desenvolvimento já que é independente dele.

A UML é uma Linguagem para Visualização n No processo de desenvolvimento de sistemas de software, é quase impossível a visualização de toda a estrutura de um sistema sem o uso de modelos que a represente. n A UML fornece os símbolos gráficos para a representação de artefatos de software. n Por trás de cada símbolo empregado na notação da UML, existe uma sintaxe e uma semântica bem-definidas. n Dessa maneira, um desenvolvedor poderá usar a UML para escrever seu modelo, diminuindo a ambigüidade em sua interpretação.

A UML é uma Linguagem para Construção n Os modelos de UML podem ser diretamente ”traduzidos” para várias linguagens de programação. n n n Isso significa que é possível mapear os modelos da UML para linguagens de programação tais como, Java, C++ e Visual Basic. Esse mapeamento permite a realização de uma engenharia de produção: geração de código a partir de um modelo em UML. O processo inverso, a engenharia reversa, também é possível, com a reconstrução de um modelo a partir de sua implementação.

A UML é uma Linguagem para Documentação n Cada modelo criado é um artefato do software Diagrama de Casos de Uso Diagrama de Classes Diagrama de Seqüência …

Uma linguagem de diagramas Diagramas de Seqüência Diagramas de Colaboração Diagrama de Casos de Uso Diagramas de Classe Modelos Diagramas de Estado Diagramas de Atividade Diagramas de Objetos Diagramas de Componentes Diagrama de Deployment Ponto de Vista Estático Ponto de Vista Dinâmico

Casos de Uso Este caso de uso é responsável por autenticar um usuário do sistema. Descrição Narrativa Pré-condição: nenhuma Pós-condição: um usuário válido é logado e sua sessão é registrada no sistema. Fluxo de eventos principal 1. O cliente informa login e senha. 2. O sistema verifica se o login e a senha são válidos (verifica-se se o login e senha pertencem a uma conta). 3. O sistema registra o início de uma sessão de uso. Fluxos secundários - No passo 2, se o login ou a senha forem inválidos, o sistema exibe uma mensagem e volta ao passo 1.

Diagrama de Casos de Uso Solicitar histórico <<estende>> Solicitar histórico do semestre atual <<estende>> Solicitar histórico de todos os semestres Estudante Sistema de controle de pré-requisitos <<inclui>> Matricular aluno Verificar dependências Secretária

Diagrama de Classes Cliente Pedido -codigo: Integer -data. Recebido -total: Currency 0. . * faz -nome: String -endereco: String -data. Primeira. Compra: Date -data. Ultima. Compra: Date -total. Comprado: Currency 1 +confirmar() +cancelar() -calcular. Total(): Currency gerar. Novo. Codigo: String #credito. Permitido: Currency #nivel. Credibilidade() itens Item de Pedido -quantidade: Integer -preco: Currency -em. Estoque: Boolean Cliente pessoa-jurídica nome. Contato: String telefones[1. . 10]: String CGC: String FAX[1. . 3]: String Cliente pessoa-física nome: String CPF: String num. Cartao. Credito colocar. Lista. Negra() * Produto representante de vendas * Empregado IPessoa

Diagrama de Objetos Curso Professor ministra -matrícula: String -nome: String [1. . 3] -cod. Disciplina: String [1. . 5] -descrição: String -cod. Turma: String Aluno * -matrícula: String -nome: String -período: Integer [0. . 10] p 1: Professor p 2: Professor matricula: "205 -6712 -09" nome: "Jaelson Castro" c 1: Curso c 2: Curso cod. Curso: "IF 291" descrição: "MPS" cod. Turma: I 7 c 3: Curso cod. Curso: "IF 185" descrição: "AER" cod. Turma: I 6 : Aluno : Aluno : aluno Bill matricula: "219846534" nome: "Nelson Mandella" : aluno matricula: "562746134" nome: "John Major" : Aluno Lewinsky

Diagrama de Sequência

Diagrama de Colaboração

Diagrama de Estados

Diagrama de atividades Pessoa H Procurar bebida [sem café] [achou café] Colocar café no filtro Adicionar água à máquina [sem Coca] [achou Coca] Pegar xícara Pegar lata de Coca Colocar filtro na máquina Ligar máquina Filtrar café Colocar café na xícara Beber H

Diagrama de Componentes Cadastro. exe <<link>> Usuários Form. Cadastro. html Banco <<link>> Autenticacao. exe Principal. html Form. Entrada. html Senhas

Diagrama de Implantação PC - G 309 Nestscape Communicator 5. 0 Principal. html servidor. Web Form. Cadastro. html Autenticação. exe servidor. De. Arquivos Cadastro. exe Form. Entrada. html servidor. Banco. De. Dados SGBD O SGBD a ser utilizado ainda não foi escolhido.

Atores: Especialização É possível definir tipos gerais de atores e especializá-los usando o relacionamento de especialização

Bibliografia § The Unified Modelling Language User Guide (Grady Booch) § The Unified Modelling Language Reference Manual (James Rumbaugh) § The Unified Software Development Process (Ivar Jacobson) § UML Distilled (Martin Fowler)