Transcript
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
1
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. 2
Implementação do método Cada fase do ciclo de vida será subdividida em etapas com atividades específicas, com produtos finais claros e objetivos. Como referência bibliográfica, indicamos: Engenharia de Software, Sommerville, Ian. Engenharia de Software, Pressman, Roger. Orientação a Objetos com UML, Larman, Craig. Fase 1 – Estudo de viabilidade As etapas desta fase deverão caracterizar em profundidade os requisitos aos quais o software deverá atender, bem como os recursos e prazos estimados previstos para a sua construção. 1.1 Introdução Uma descrição breve do software, das suas funcionalidades principais e justificativas da sua necessidade. Check-List: Software já existente com novas necessidades Objetivo estratégico Mercado Produto final: Texto 1.2 Definição de requisitos do usuário Nesta definição descrevem-se as interações do software com os usuários que o operam, com as funcionalidades descritas em nível elevado, podendo-se mencionar requisitos não funcionais relevantes, também em nível elevado. A utilização de diagramas, se possível, é indicada. Check-List: Todos os usuários representados? Todos os requisitos funcionais relevantes? Todos os requisitos não funcionais relevantes? Produto final: Texto Diagrama de contexto 1.3 Arquitetura de Sistema Uma visão geral da arquitetura com os módulos componentes. Check-List Todas as funcionalidades (Ver texto)? Indicação de módulos já existentes? Indicação de interfaces com outros softwares/módulos? Produto final: Diagrama Hierárquico de funções 1.4 Especificação de requisitos do software
3
Descrição detalhada dos requisitos funcionais e não funcionais do software a ser construído. Requisitos de domínio são estabelecidos. Check-List: Requisitos de domínio. Requisitos funcionais: Identificar os eventos do software, criando uma matriz de eventos, com os componentes: Evento, Tipo de evento, Dados envolvidos no evento, Ação do sistema sobre os dados, Origem dos dados e Resultado da ação sobre os dados. Requisitos não funcionais: Requisitos do produto Facilidade de uso Eficiência Desempenho Espaço Confiabilidade Portabilidade Requisitos organizacionais Entrega Implementação Padrões Requisitos externos Interoperabilidade Éticos Legais Privacidade Segurança Produto Final: Matriz de eventos Texto para requisitos não funcionais e de domínio. 1.5 Glossário Todos os termos, técnicos ou característicos do negócio, e que não sejam de domínio público, utilizados nas descrições devem ser explicados. Produto final: Texto 1.6 Plano para as atividades seguintes A identificação dos requisitos de um software permite que as atividades das fases seguintes possam ser previstas com bastante acuidade. Da mesma forma, os recursos que serão necessários poderão ser dimensionados com precisão. Surge daí um plano de trabalho para as fases e etapas seguintes. Este plano conterá cronogramas de todas as atividades, com os produtos a serem gerados em pontos de controle. A administração contará com este plano na gestão das atividades, acompanhando todas as ações de construção do software. Check-List: Módulos do DHF abordados? Todas as fases/etapas seguintes cronogramadas? Em todas as etapas estão definidos os recursos de pessoal técnico e usuário? 4
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:
Caso de uso 1 Cadastrar tipos de funcionário Caso de uso 2 Cadastrar funcionário
Cadastrar Tipo de funcionário Administrador
Cadastrar tipo de funcionário
«uses»
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.
Cadastrar funcionário 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.
Obs.: À partir do release 2.0, <> foi substituído por <>
5
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.
:Aluno Administrador
Alunos +IdAluno : int +NomeAluno : char +Get() : bool
Get() Mensagem (Opcional)
6
01 - TRATAR TIPO DE FUNCIONÁRIO
Tipo de funcionario Usuário Incluir() Msg
Tipo de funcionário -Id_tipo_funcionário : int -DescTipo : char +Incluir() +Editar() +Excluir() +Consultar()
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" Incluir Tipo_funcionário e enviar Msg " Tipo_funcionário incluído"
senão
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
7
02 - TRATAR FUNCIONÁRIO
funcionário
Tipo de funcionário
tipo de funcionário
-Id_tipo_funcionário : int -DescTipo : char +Incluir() +Editar() +Excluir() +Consultar()
Usuário Incluir()
Consultar()
Msg
1..1
Editar()
Consultar()
*
Msg
Funcionário -Idfunc : int -Nome : char -End : char -cpf : int +set() +get() +exc() +edit()
Excluir() Msg
Consultar()
Consultar()
Msg
02 - Tratar funcionário 02.1 Incluir funcionário O usuário aciona o método Incluir() da classe funcionário Argumentos (Id_tipo-funcionário, Idfunc,nome, end, cpf) Se dados cadastrais não forem válidos Abortar com a Msg "Dados cadastrais inválidos" senão O método get() da classe tipo_Funcionario é acionado Argumentos (id_tipo_func) Se id_tipo_func não for válido abortar com a msg "Tipo funcionário inválido" senão Incluir funcionário e enviar Msg " funcionário incluído" 02.2 Editar fFuncionário O usuário aciona o método Editar() da classe funcionário Argumentos (Id_funcionário, dados cadastrais) Se argumentos inválidos(inclusive id_tipo_func) Abortar com a Msg " Dados Inválidos" senão Editar dados do funcionário e enviar Msg "Dados alterados" (Pode ser necessária consulta à classe tipo de funcionário) 02.3 Excluir funcionário O usuário aciona o método Excluir() da classe funcionário Argumento (id_func) Sr argumento inválido Abortar com a Msg "Identificação do funcionário excluir funcionário e enviar Msg "funcionário excluído) 02.4 Consultar funcionário O usuário aciona o método Consultar() da classe funcionário Argumento (Id_func) Se argumento inválido Abortar com a Msg "Identificação do Ativar método get() da classe tipo_de_funcionário Argumento (Id_tipo_func) enviar resposta com os dados do funcionário ao Ator
inválido" senão
funcionário nválido" senão
8
120 - Usuário gera dados do boleto.
:Boleto
:Sócio/Não Sócio
:Item Boleto
:Cota
:Dependentes
:Condomínio
:Participante
:Evento
Usuário
Gerar Dados Boleto Consultar Sócio/Não Sócio Erro ao Consultar Sócio Sócio/Não Sócio Validado Incluir Item Boleto
Consultar Cota Erro ao Consultar Cota Valor Cota Informado
Consultar Dependentes Erro ao Consultar Dependentes Dependente Informado
Consultar Condomínio Erro ao Consultar Condomínio Incluir Item Boleto
Valor de Condomínio Informado
Consultar Participante Erro ao Consultar Participante Participante Confirmado
Consultar Evento Erro ao Consultar Evento Valor Evento Confirmado
Erro ao Incluir Item Item Incluído Erro ao Gerar Boleto Boleto Gerado
9
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.
10
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:
Modelagem lógica
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
Fase 3 – Modelagem física
11
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 5Implantação do software.
12
Produtos finais Descrição funcional Descrição das funcionalidades do software em nível elevado para Usuários não operacionais (Diretores, gerentes,...) Documento de Instalação Os procedimentos para a instalação do software para Administrador do sistema Manual de Introdução Procedimentos de operação do sistema para usuários iniciantes Manual de consulta Procedimentos de operação do sistema para usuários avançados Guia do Administrador Procedimentos de operação e manutenção do software para Administrador de sistema Fase 4 – Implementação e Testes A construção do software (programação) é realizada nesta fase, utilizando-se linguagens de programação definidas na fase anterior. 4.1 Verificação e validação do software Os softwares construídos são submetidos a testes de verificação e validação Check-List Plano de testes de aceitação elaborado? Plano de testes de integração de sistema elaborado? Plano de testes de integração de subsistemas elaborado? Plano de testes de unidades e de módulos elaborado? Produtos finais Softwares aprovados nos: Testes de aceitação Testes de integração de sistema Testes de integração de subsistemas Testes de integração de unidades e de módulos 4.2 Inspeção de softwares Adicionalmente à Verificação & Validação os softwares são inspecionados estaticamente, na sua codificação. Check-List Defeitos nos dados Defeitos de controle Defeitos de entrada/saída Defeitos de interface Defeitos de gerenciamento de armazenamento Defeitos de gerenciamento de exceções Produtos finais Softwares aprovados em inspeção estática Fase 5 – Implantação e manutenção de softwares Esta fase do ciclo de vida ocorre com o software já construído e aceito pelo usuário. Neste momento o software se torna um componente de um sistema de informações com etapas próprias de implantação. As manutenções, sejam corretivas ou evolutivas, serão re-submetidas ao ciclo de vida, até sua reimplantação. 13
Referências bibliográficas: AMBLER, Scott. ANÁLISE E PROJETO ORIENTADOS A OBJETO LARMANN, Craig. UTILIZANDO UML E PADRÕES – ANÁLISE E PROJETO ORIENTADOS A OBJETO FURLAN, David , ANÁLISE ESSENCIAL SOMMERVILLE, Ian – ENGENHARIA DE SOFTWARE (6ª edição)
14
