Baixe Construção de softwares com qualidade e outras Manuais, Projetos, Pesquisas em PDF para Informática, somente na Docsity! 1 NEWTON PAIVA O seu Centro Universitário Centro Universitário Newton Paiva Curso de Sistemas de Informação Disciplinas: Elaboração de projetos Projetos experimentais em informática Um método para a construção de softwares com qualidade Prof. Pedro de Castro Miranda 2 Introdução A qualidade do software está condicionada aos recursos e processos que o produzem. Os processos devem ser identificados com clareza, devem ser documentados e repetidos para toda nova produção. Considera-se que uma empresa de informática( ou depto de informática em qualquer instituição) poderá ter produtos de qualidade se, na sua administração, os recursos e processos forem identificados e utilizados seguindo uma metodologia previamente estabelecida. Aqui apresentamos um modelo de método para construção de software, uma abstração, que pode ser utilizado com este objetivo. Cada empresa, em verdade, definirá seu método para a construção de softwares, baseando-se no seu quadro de pessoal técnico, sua experiência, competência e habilidades, e a plataforma e ferramentas disponíveis para auxílio aos processos. Softwares são componentes de sistemas de informação, muito mais abrangentes. Neste método o foco é dado fundamentalmente ao software. A construção obedece ao ciclo de vida de softwares, resumido em seguida. Ciclo de vida de um software As fases para a construção de um software são: Estudo de viabilidade: A identificação das necessidades do usuário, sua justificativa, custos e prazos estimados para a construção, com a indicação de sua viabilidade técnica e financeira. Estas necessidades formam um conjunto inicial de requisitos. Modelagem lógica: Os requisitos completos que caracterizam as necessidades do usuário são detalhados no início da modelagem lógica e formam a base para esta modelagem do software aplicativo. Diagramas para o modelo são elaborados. As fases de Estudo de viabilidade e de Modelagem lógica dão origem aos produtos finais: Documento de Requisitos de Software e Diagramas diversos, segundo a abordagem utilizada (OO ou Estruturada). O “Documento de Requisitos de Software”.deve ser analisado cuidadosamente pelos usuários responsáveis envolvidos no processo, pois caracteriza de forma cabal o produto que será implantado. Modelagem física Nesta fase são definidas a tecnologia a ser empregada na operação do software, a estruturação dos dados e as interfaces dos usuários com o software aplicativo, sendo elaborada a documentação específica para sua operacionalização. Implementação/Testes A codificação dos programas e os testes de atendimento aos requisitos. Finalização da documentação de operação do software. Implantação/Manutenção A instalação do software aplicativo, as atividades de treinamento dos envolvidos na sua operação e a manutenção, corretiva ou evolutiva, que se faça necessária. Nesta fase o software é um componente do sistema de informações. 5 Em todas as atividades estão definidos os recursos de hardware e software necessários para as tarefas? Ao final de todas as etapas estão definidos pontos de controle para avaliação dos produtos finais? As necessidades de instalações físicas estão abordadas? Produtos finais Cronogramas de Gannt separados por fases e dentro de cada fase por etapas Produtos gerados nos pontos de controle Texto Fase 2 - Modelagem lógica A modelagem lógica do sistema é efetuada utilizando a abordagem orientada a objetos com UML 2.1 Diagramas de caso de uso Baseado nos requisitos funcionais (Matriz de eventos) elaborar um diagrama de caso de uso para cada evento identificado na matriz Check-List Número de eventos igual ao número de diagramas? Atores nos eventos? Produto final: Diagramas de caso de uso. Veja os exemplos seguintes: Funcionário Cadastrar funcionário Cadastrar tipo de funcionário «uses» Caso de uso 2 - Cadastrar funcionário Descrição do caso de uso 1 - Os dados cadastrais do funcionário são informados ao sistema. 2 - Se o tipo de funcionário não existir, exibir mensagem de erro. 3 - O sistema confirma o cadastramento, ou exibe mensagem de erro. Administrador Cadastrar Tipo de funcionário Descrição do caso de uso 1 - Os tipos de funcionário são informados pelo Administrador. 2 - O sistema confirma o cadastramento, ou informa msg de erro. Caso de uso 1 - Cadastrar tipos de funcionário Obs.: À partir do release 2.0, <<uses>> foi substituído por <<include>> 6 2.2 Diagramas de seqüência A elaboração de diagramas de seqüência para cada caso de uso identificado anteriormente. A análise dos requisitos funcionais permitirá identificar todos os objetos envolvidos Check-List Número de diagramas igual ao número de casos de uso? Atores dos casos de uso estão todos representados nos diagramas de seqüência? Objetos identificados na descrição dos requisitos funcionais estão todos representados? Mini-especificações para processos complexos ou especiais? Produto final: Diagramas de seqüência Mini-especificações. Veja as considerações e exemplos seguintes: Estrutura de uma classe Nome da classe Atributos da classe Métodos da classe Mensagens São endereçadas a classes para que estas executem métodos e, como padrão, têm a seguinte sintaxe : Return type;Nome do método(Tipo de dado; Argumentos) | | | |___________|________ O tipo de dado a ser retornado pela função | | |________ O nome do método a ser executado pela classe | |__ Os argumentos,com os tipos de dados respectivos Ex.: Boolean;Get(Integer, IdAluno) Este método retorna (Sim ou não) se o aluno, identificado por IdAluno, existe. Obs.: Na modelagem lógica não é obrigatória a informação de tipos de dados e argumentos para não congestionar o diagrama. Administrador :Aluno Get() Mensagem (Opcional) +Get() : bool +IdAluno : int +NomeAluno : char Alunos 7 Usuário Tipo de funcionario Incluir() Msg Editar() Msg Excluir() Msg Consultar() Msg 01 - Tratar tipo de funcionário 01.1 Incluir tipo de funcionário O usuário aciona o método Incluir() da classe Tipo de funcionário Argumentos (Id_tipo-funcionário, Descrição_tipo) Se Descrição_Tipo não for válida Abortar com a Msg "Descrição Inválida" senão Incluir Tipo_funcionário e enviar Msg " Tipo_funcionário incluído" 01.2 Editar tipo de Funcionário O usuário aciona o método Editar() da classe Tipo de funcionário Argumentos (Id_tipo_funcionário, Descrição_tipo) Se argumentos inválidos Abortar com a Msg " Dados Inválidos", senão Editar Descrição_tipo e enviar Msg "Descrição alterada" 01.3 Excluir tipo de funcionário O usuário aciona o método Excluir() da classe Tipo_funcionário Argumento (Tipo_funcionário) Sr argumento inválido Abortar com a Msg "Argumento Inválido" senão excluir tipo_funcionário e enviar Msg "Tipo_funcionário excluído) 01.4 Consultar tipo de funcionário O usuário aciona o método Consultar() da classe Tipo_funcionário Argumento (Id_tipo_funcionário) Se argumento inválido Abortar com a Msg "Argumento inválido" senão enviar resposta com os dados do tipo de funcionário +Incluir() +Editar() +Excluir() +Consultar() -Id_tipo_funcionário : int -DescTipo : char Tipo de funcionário 01 - TRATAR TIPO DE FUNCIONÁRIO 10 Descrição Geral do Caso de Uso: Usuário Gera Dados do Boleto significa calcular a boleta de cobrança, destinada aos sócios titulares e não sócios relacionando todas as atividades que geram alguma cobrança, descriminadas no Item de Boleto, praticadas pelos não sócios, e sócios ( sócios e seus titulares). Funções: “Gerar Dados Boleto ()” - Função de solicitação do calculo e geração dos boletos. Uma vez iniciado todas as buscas exigidas serão automáticas, ou seja processos da propria função. Repostas: “Erro ao Gerar Boleto” - Houve um erro na validação, dados passados para consulta não foram encontrados. Função não executada perfeitamente, tratar o erro específico. “Boleto Gerado” - A função foi executada com sucesso gerando o resultado esperado. “Consultar Sócio/NãoSócio ()” - Função que retorna os dados referentes ao sócio a ser destinado o boleto”. Repostas: “Erro ao Consultar Sócio” - Houve um erro na validação, dados passados para consulta não foram encontrados. Passar dados coerentes. “Sócio/Não Sócio Validado” - A função foi executada com sucesso, a consulta foi validada e retornado o ID de um Sócio. “Incluir Item de Boleto()” - Função que registra um novo Item de Boleto, conforme cada item específico a ser cobrado. Repostas: “Erro ao Incluir Item” - Houve um erro na validação, dados passados para consulta não foram encontrados. Passar dados coerentes. “Item Íncluído” - A função foi executada com sucesso, item de cobrança relacionado. “Consultar Cota ()” - Função que valida os dados referentes a cota do sócio, passado por parâmetro. O retorno desta função corresponde a um Item de Boleto registrado. Repostas: “Erro ao Consultar Cota” - Houve um erro na validação, dados passados para consulta não foram encontrados. Próxima consulta será executada ou deverá ser passado dados coerentes. “Valor Cota Informado” - A função foi executada com sucesso, a consulta foi validada e o VALOR de cota a ser cobrado será retornado. “Consultar Dependente ()” - Função que retorna o(s) dependente(s) do titular destinado o boleto”. Repostas: “Erro ao Consultar Dependentes ” - Não há dependentes cadastrados ou houve um erro na validação, dados passados para consulta não foram encontrados. Passar dados coerentes. “Dependente Informado” - A função foi executada com sucesso, a consulta foi validada e o ID do Dependente será retornado. “Consultar Condomínio ()” - Função que valida os dados referentes ao condomínio do sócio e seus dependentes. O retorno desta função corresponde a um Item de Boleto registrado. Repostas: “Erro ao Consultar Condomíno” - Houve um erro na validação, dados passados para consulta não foram encontrados. Próxima consulta será executada ou deverá ser passado dados coerentes. “Valor Condomínio Informado” - A função foi executada com sucesso, a consulta foi validada e o VALOR de Condomínio referente um sócio ou dependente a ser cobrado será retornado. “Consultar Participante ()” - Função que confirma a participação de um sócio, dependente ou não sócio a um determinado evento. Repostas: “Erro ao Consultar Participante” - Não há participação do sujeito consultdo ou houve um erro na validação, dados passados para consulta não foram encontrados. Próxima consulta será executada ou deverá ser passado dados coerentes. “Participante Confirmado” - A função foi executada com sucesso, a consulta foi validada e o ID do Evento participado pelo sujeito consultado será retornado. “Consultar Evento ()” - Função que valida a cobrança de um determinado evento particiapdo. O retorno desta função corresponde a um Item de Boleto registrado. Repostas: “Erro ao Consultar Evento” - Houve um erro na validação, dados passados para consulta não foram encontrados. Deverá ser passado dados coerentes. “Valor Evento Informado” - A função foi executada com sucesso, a consulta foi validada e o VALOR do Evento participado por um sócio, não sócio ou dependente, a ser cobrado será retornado. 11 Obs.: No diagrama de sequência não se coloca, usualmente, classes não persistentes, como as interfaces, quando se tratar de modelagem lógica. 2.3 Diagrama lógico de classes (Persistentes) Todos as classes identificadas nos diagramas de seqüência serão associadas Check-List: A quantidade de classes no diagrama condiz com os diagramas de seqüência? Os atributos identificados atendem necessidades previstas, em especial as consultas e relatórios? Os métodos identificados nos diagramas de seqüência estão todos representados? Produto Final: Diagrama de classes 2.4 Glossário O “dicionário de dados”, baseado na estrutura lógica global da aplicação, desde as definições de regra de negócio até os dados identificados no diagrama de classes. Check-List Caracterização da organização-usuária, inclui ligações com outras áreas (se existente)? Há descrição de funcionalidades de áreas que apresentem interesse no entendimento do sistema aplicativo? Todos os dados persistentes estão mencionados? Produto Final: Diagramas hierárquicos de estrutura da empresa e interfaces Texto Os produtos finais das etapas anteriores comporão um conjunto de documentos , como segue: Fase 3 – Modelagem física 2.4 2.3 2.2 2.1 1.6 1.5 1.4 1.3 1.2 1.1 Introdução Documento de Requisitos de software Modelagem lógica 12 A modelagem física é efetuada. Todos os recursos tecnológicos adequados (Disponíveis ou passíveis de aquisição) são analisados quanto a sua utilização na operacionalização do software que será componente de um sistema de informações. Todas as etapas desta fase deverão obedecer e se orientar pelos produtos gerados nas fases anteriores. 3.1 Estrutura do software A decomposição do sistema em função de todos os requisitos identificados. Check-List O DHF elaborado na fase 1 foi comparado? Prazos de desenvolvimento e implantação foram analisados (Requisitos não funcionais)? Requisitos para o sistema de informações foram levantados? Produto final Diagrama hierárquico funcional consolidado Diagrama de pacotes Texto 3.2 Estrutura de dados Nesta metodologia utilizamos como manipuladores de banco de dados gerenciadores relacionais. Os passos seguintes deverão ser levados a efeito: Geração do DER (Diagrama de entidades-relacionamentos) Geração do script para a geração da estrutura de dados Geração do banco de dados Produto final DER Script Banco de dados 3.3 Interfaces gráficas com o usuário (GUI) Todas as interações serão definidas e os lay-outs estabelecidos. Check-List e Produtos finais Janelas Ícones Menus Gráficos Relatórios Outros (Se necessários) 3.4 Especificações de programas Programas com detalhamento mais complexo, ou que apresentem comportamento fora dos padrões devem ter suas funcionalidades detalhadas em documentos apropriados. Produtos finais Mini-especificações Fluxogramas 3.5 Documentação operacional A documentação operacional final do software é elaborada nesta etapa. Deverá ser revista na fase 5- Implantação do software.