Trabalho Eng Software

1. INTRODUÇÃO A engenharia de software é a ciência e a arte de com economia, em tempo útil e de forma elegante, especificar, projetar, implementar e manter atualizados e corretos, programas, documentação e procedimentos operacionais para sistemas computacionais de utilidade para a humanidade (Alan Brown, Anthony Earl e John McDermid). A engenharia de software é definida, também, como "aplicação prática do conhecimento científico no projeto e construção de programas e da documentação requerida para desenvolver, operar e manter esses programas" (Boehm 80). O estudo e sistematização do processo de desenvolvimento de software requer que se conheçam as características do produto desejado e da tecnologia que será utilizada em seu desenvolvimento. Este processo é orientado pelo modelo de ciclo de vida, cujas funções primárias são a de determinar as fases e a ordem das atividades envolvidas no desenvolvimento e o estabelecimento de critérios para a transição das fases. Estes critérios de transição incluem a determinação de diretrizes para o começo e a finalização das fases. Os métodos, por sua vez, podem ser definidos como: "prescrições explícitas para a realização de uma atividade ou conjunto de atividades do modelo de ciclo de vida" [Charette 86]. Eles devem refletir um conjunto de diretivas para a aplicação sistemática de técnicas e instrumentos. As técnicas podem ser definidas como um conjunto de princípios para execução de uma tarefa específica do processo de desenvolvimento do software. Os instrumentos tornam possível o uso de métodos e técnicas (Rocha 87), (Crispim 92). Este trabalho abordará o processo de desenvolvimento de software em geral, através da descrição de alguns modelos de ciclo de vida e de alguns métodos de construção de sistemas.

2. MODELOS DE CICLO DE VIDA Modelos de ciclo de vida descrevem as etapas do processo de desenvolvimento de sistemas e as atividades a serem realizadas em cada etapa. A definição dessas etapas e atividades possibilitam prover marcos e pontos de controle para avaliação da qualidade e gerência do projeto (Park 91). O estudo do processo de desenvolvimento provocou o surgimento de várias propostas de ciclo de vida que incluem desde o simples modelo artesanal de codificar e consertar (Connors 92), (Pressman 92) até o modelo espiral (Boehm 88). Inicialmente, o desenvolvimento de software era algo feito em pequena escala com equipes pequenas ou, até mesmo, apenas com esforço individual. Neste momento, a ênfase do processo estava na etapa de programação. Neste escopo o desenvolvimento de software caracterizou-se pelo codificar e consertar, também chamado de desenvolvimento artesanal ou ad-hoc, que consiste em se partir diretamente para a codificação, seguida de correção. Esse ciclo é repetido até se completar o projeto (Connors 92). O aumento da complexidade e tamanho dos sistemas gerou algumas propostas de ciclo de vida levando em conta o desenvolvimento de sistemas em grande escala envolvendo grandes equipes. Isto acarretou uma mudança de enfoque com ênfase no desenvolvimento de sistemas e não apenas de programas.

A primeira proposta deu origem ao modelo tradicional ou cascata. Nesse modelo as fases são executadas sistematicamente de forma seqüencial como ilustrado na figura 1 e normalmente tem as seguintes fases: Análise, Projeto, Construção, Avaliação e Manutenção (Rocha 87), (Davis 90), (Ghezzi 91), (Pressman 92).

Análise Projeto Construção Avaliação Manutenção

Figura 1 - Modelo de Ciclo de Vida Clássico ou Cascata

Na fase de análise, também denominada análise de requisitos, são estabelecidos os requisitos do sistema a ser desenvolvido. Nesta fase, o engenheiro de software necessita compreender o domínio do problema no qual está trabalhando. Os requisitos e a modelagem conceitual do sistema são documentados e, posteriormente, revisados pelo usuário. A análise de requisitos começa ao se reconhecer que um problema necessita da tecnologia de informação como solução ou ao surgir uma idéia de um novo negócio ou de um novo sistema de informação na empresa. Esta fase é concluída ao se ter uma descrição completa do comportamento do software a ser construído documentado na Especificação de Requisitos. Nesta fase são realizadas as atividades de análise do problema, descrição do produto e avaliação da especificação do produto. O projeto do software é, na realidade, um processo de múltiplos passos que reforça quatro atributos importantes: estrutura de dados, arquitetura do software, detalhe procedural e projeto da interface. A fase de projeto tem por objetivo traduzir os requisitos definidos em uma representação de software com detalhes suficientes para que possa ser implementado. Como os requisitos, o projeto é documentado (Especificação de Projeto), sendo este realizado com base na Especificação de Requisitos. Pode-se verificar que quanto mais refinado (detalhado) for a fase de projeto, mais clara será a fase de construção. Na fase de construção, os programas são codificados, as bases de dados criadas e os módulos do software integrados. Uma vez que o código foi gerado, segue-se a fase de avaliação da qualidade do software. Esta avaliação deve ser realizada através de certificação utilizando inspeção, walkthrough, ou prova formal1 ou através de execução experimental (testes). Os testes concentram-se em validar os procedimentos lógicos internos do programa, garantindo que todos os comandos foram testados e que o comportamento funcional externo do sistema produz os resultados esperados para determinadas entradas de dados. _________________ 1

Certificações e técnicas de avaliação da qualidade são definidos na seção 4 deste trabalho

Teste é um elemento crítico no controle da qualidade de software e representa uma revisão final das fases de análise, projeto e construção. A intenção da realização de testes é achar erros e para que os testes sejam eficazes é necessário que estes sejam planejados com seus objetivos claramente definidos. Na análise dos resultados deve-se procurar identificar a falha que causou o erro evidenciado pelo teste. Testar exaustivamente e completamente um software nem sempre é possível, por isso os testes não podem assegurar a correção total de um sistema. Entretanto, a utilização de testes combinados com algumas técnicas de controle da qualidade contribuem para se obter um nível aceitável de confiabilidade. O sistema é entregue ao usuário após se chegar a um resultado satisfatório na fase de avaliação, com um certo grau de confiança. É claro que o sistema ainda passará por alterações, devido principalmente a erros observados pelo usuário, ou por mudanças necessárias para melhor adaptação ao ambiente do usuário, ou por problemas de desempenho. A manutenção do software pode invocar novamente as outras fases do ciclo, conforme indicado pelas setas na Figura 1. O modelo de ciclo de vida evolucionário surgiu propondo um desenvolvimento que expandisse o sistema gradativamente, permitindo que se obtivessem modelos do comportamento do software antecipadamente, os denominados protótipos. A prototipagem é uma forma de desenvolvimento incremental e contém quatro tipos diferentes: ilustrativo (telas), simulado (acesso ao banco de dados é simulado), funcional (subconjunto limitado) e evolucionário (começa pequeno e cresce). Os três primeiros tipos são construídos para se atingir objetivos propostos a priori, sendo considerados protótipos descartáveis. O protótipo evolucionário se tornará ao final um produto operacional. Na figura 2, pode-se observar a seqüência de eventos verificada no paradigma da prototipagem (Pressman 92). Tal como o processo de desenvolvimento convencional de software (modelo cascata), a prototipagem se inicia com a etapa de definição dos requisitos. Todos os objetivos a serem atingidos pelo software são definidos, sendo identificadas às áreas que merecem uma definição mais refinada. A partir dos requisitos levantados na fase de definição, um projeto inicial é construído e apresentado ao usuário, refletindo os aspectos visíveis do software. Este projeto rápido leva à construção de um protótipo, que será avaliado pelo usuário e usado para refinar os requisitos do software a ser desenvolvido. O processo de refinamento dos requisitos traz benefícios para ambas as partes envolvidas no processo de desenvolvimento do software. O usuário, ao participar do processo de desenvolvimento, tem condições de contribuir para um maior refinamento dos requisitos, gerando maior confiança no software em desenvolvimento. Outro benefício é que o desenvolvedor do software pode compreender melhor o domínio sobre o qual está trabalhando e, a partir das questões levantadas pelo usuário, bem como suas sugestões, poderá desenvolver um produto de melhor qualidade e mais próximo ao produto requisitado.

Início Fim

Figura 2 -

Definição de requisitos e refinamento

Produto Final

Projeto rápido

Construção do protótipo

Refinamento do protótipo

Avaliação do usuário

Prototipagem (Pressman 92)

A rapidez na construção de um protótipo pode ser obtida com a reutilização de software e ferramentas que automatizem a geração do protótipo. Reutilização de software é o processo de desenvolvimento de software cujo objetivo é utilizar a experiência adquirida e os produtos obtidos anteriormente, para o desenvolvimento de novos produtos, podendo ser aplicada nas fases de Análise, Projeto, Construção ou Avaliação. Assim sendo, a reutilização utiliza: código já testado anteriormente, projetos validados, especificações de requisitos, e/ou planos para testes (Pressman 92). A expressão "reutilização de software" indica uma atividade particular no desenvolvimento do software. As mudanças observadas no ciclo de vida do software são mostradas na figura 3.

Análise Projeto Construção Avaliação Manutenção

Repositório

Figura 3 - Ciclo de Vida com Reutilização

Outra forma de desenvolvimento é caracterizada pelo modelo de síntese automática (figura 4) que transforma as especificações em programas (Balzer 81), (Boehm 88), (Bersoff 91), (Connors 92).

Análise Projeto Construção Avaliação

Síntese de Projeto

Manutenção Síntese de Projeto e Código

Síntese completa do Software

Figura 4 - Ciclo de Vida com Síntese Automática

O modelo em espiral proposto por Boehm (Boehm 88) mostrado na figura 5, fornece uma estrutura de trabalho para a produção de software baseada em processo e níveis de risco permitindo a análise dos riscos em várias etapas do desenvolvimento. Esse modelo pode ser considerado um meta-modelo, pois podem abranger diferentes outros modelos, desde o modelo cascata até os vários tipos de protótipos. É um modelo cíclico. A análise dos modelos de ciclo de vida pode ser feita considerando-se a identificação monolítica ou incremental do processo de desenvolvimento. Na estrutura de trabalho monolítica, os detalhes de cada fase são completados em sua totalidade, antes do início da etapa seguinte. Sendo assim, o comportamento do software só pode ser avaliado no final do desenvolvimento. Na estrutura incremental, os detalhes podem ser retardados com o benefício de se produzir antecipadamente um protótipo mostrando o funcionamento do produto (Connors 92).

Figura 5 - Modelo Espiral (Boehm 88)

3. MÉTODOS DE DESENVOLVIMENTO Na literatura de engenharia de software (Ross 77), (Yourdon e Constantine 78), (Page-Jones 80), (Chandersekaran e Linder 81), (Jackson 83), (Ward e Mellor 85), (Booch 86), (Warnier 86), (Chen 87), (De Marco 89), (Jones 90), (Yourdon 90), (Hatley e Pirbhai 91), (Coad 92), encontramos diversas propostas de métodos que podem atender diferentes paradigmas (dados, funções, objetos), para diversos domínios de aplicação, com rigor de expressão diferente e aplicação em fases específicas. Esses métodos apóiam os desenvolvedores de software na análise e documentação do problema provendo um mecanismo de abstração, particionamento e representação do problema a ser desenvolvido pelo sistema. A fase de análise de requisitos é de suma importância no desenvolvimento de um sistema, pois é a base para o desenvolvimento do software. Outro aspecto a considerar é que o custo de correção de um erro encontrado nas fases posteriores à fase de projeto é muito maior (2 a 40 vezes mais). Hoje em dia sabe-se que muitos erros (mais de 50%) são cometidos na fase de análise e que estes podem ser facilmente detectados. As consequências de não se detectar os erros nas fases de análise e projeto acarretam na não satisfação do usuário, desentendimento entre os envolvidos, perda de tempo e dinheiro e em até problemas jurídicos. Por isso, os métodos de construção mais difundidos nos diferentes paradigmas e as técnicas de elicitação dos requisitos serão abordados. Estas técnicas facilitam a comunicação entre usuários e desenvolvedores, sendo fundamental principalmente por ser a fase de análise uma atividade que requer uma intensa comunicação entre as partes envolvidas.

3.1 SADT SADT (Structured Analysis and Design Technique) foi desenvolvido no início dos anos 70 por Ross, sendo utilizado inicialmente pela U.S. Air Force e pela ITT européia (Ross e Schoman 77), (Ross 85). A estrutura de trabalho do SADT utiliza a técnica top-down onde o desenvolvedor inicia representando o sistema a nível macro (diagrama de contexto), e depois refina repetidamente cada diagrama representando um aspecto do sistema num nível mais detalhado. Uma especificação com SADT é uma representação gráfica da estrutura hierárquica do sistema. SADT permite a modelagem em termos de função e de dados, possuindo como instrumentos um diagrama de atividades e um diagrama de dados onde as atividades e os dados são representados através de retângulos e setas. Uma definição sucinta deste método pode ser encontrada em (Rocha 87) e (Davis 90).

3.2 MÉTODOS ESTRUTURADOS Os métodos conhecidos como estruturados são Análise Estruturada (DeMarco 89), Projeto Estruturado (Yourdon e Constantine 78), (Page-Jones 80), Análise Essencial (Análise Estruturada Moderna) (McMenamim e Palmer 91), (Yourdon 90), Análise Estruturada para Sistemas de Tempo Real (Ward e Mellor 85), (Hatley 87). A Análise Estruturada foi desenvolvida por Gane (Gane 77) e DeMarco (DeMarco 78) e está intimamente relacionada ao método de projeto desenvolvido por Constantine e Yourdon, denominado Projeto Estruturado (Yourdon 78). A Análise Estruturada consiste de um conjunto de técnicas e instrumentos com o objetivo de auxiliar na análise e definição do sistema. Este método é similar ao SADT. Utiliza uma linguagem gráfica e fornecendo uma visão top-down e particionada do sistema. A Análise Estruturada é composta dos seguintes instrumentos:  Diagrama de Fluxo de Dados, que representa o sistema como uma rede de processos interligados entre si por fluxos de informação e depósitos de dados.  Dicionário de Dados que contém a definição dos dados utilizados no DFD.  Especificação de Processos que define a lógica dos processos representados no DFD. No final dos anos 80, a Análise Estruturada havia sido aplicada nos mais variados tipos de problemas (Davis 90). Entretanto, alguns problemas foram encontrados e a Análise Essencial (McMenamin 84) surge definindo alguns conceitos e facilitando a modelagem conceitual do sistema:  Essência do Sistema ou Requisitos Essenciais é o conjunto de requisitos verdadeiros, ou seja, requisitos que o sistema deve possuir para atingir o seu propósito.  Requisitos Falsos são aqueles requisitos que o sistema não necessita para atingir seu propósito. Estes requisitos podem ser tecnológicos ou arbitrários.

 Tecnologia Perfeita é definida como a tecnologia que não possui limitações físicas.  Eventos e Respostas: um evento é uma mudança no ambiente externo que o sistema deve responder e respostas é um conjunto de ações executadas pelo sistema ao ocorrer um evento.  Essência do sistema é composta de atividades essenciais e da memória essencial. A atividade essencial é aquela que o sistema deve executar para atingir o seu propósito utilizando uma tecnologia perfeita. Memória Essencial são os dados armazenados pelo sistema para executar as atividades essenciais.  Encarnação da Essência é um termo utilizado para representar a materialização dos conceitos contidos no sistema, ou seja, o processo de desenvolvimento de sistemas é redefinido nas seguintes etapas: definição da essência do sistema (análise), seleção de uma encarnação da essência (escolha da tecnologia utilizada) e projeto da implementação (projeto). Esses conceitos possibilitaram algumas modificações na Análise Estruturada, surgindo a denominada Análise Estruturada Moderna (Yourdon 90). Essas mudanças reconhecem que:  a construção da modelagem física e lógica da situação atual pode paralisar, isto é, pode acarretar uma produtividade muito baixa na fase de análise;  a estrutura top-down pura não é boa para sistemas complexos, podendo introduzir decisões de implementação na fase de análise;  os diagramas de entidade e relacionamento são extremamente válidos para capturar a complexidade dos dados e seus relacionamentos. O processo de modelagem da Análise Estruturada foi alterado para uma estrutura outside-in, onde se define primeiro o contexto do sistema em relação ao seu ambiente (definição de seus eventos externos). E a seguir, para cada evento é definido o comportamento interno do sistema e criado o modelo comportamental que é composto de: DFD’s particionados por eventos, hierarquia de DFD’s, Diagrama de Entidade e Relacionamentos, Dicionário de Dados e Especificação de Processos. Algumas aplicações são dependentes do tempo e por isso necessitam processar informações sobre controle. Algumas extensões foram propostas para a Análise Estruturada se adequar a sistemas de tempo real (Ward 85), (Hatley 87). Esses métodos introduzem um novo diagrama, o Diagrama de Transição de Estados, que apresenta as mudanças ocorridas no sistema dependentes do tempo. O conceito de fluxo de controle é também introduzido, pois este não contém informação e sim um controle que dispara um processo do sistema. O Projeto Estruturado foi desenvolvido no início dos anos 70 por Constantine e Yourdon (Yourdon e Constantine 78), (Page-Jones 80) e estabelece um conjunto de características de qualidade de um bom projeto (coesão e acoplamento) e uma linguagem para construir gráficos de estrutura. O objetivo do Projeto Estruturado é projetar a arquitetura do sistema e de programas como estruturas de módulos de função únicas e independentes. Esse método é utilizado na fase de projeto, principalmente ao modelar o sistema com Análise Estruturada.

3.3 MODELAGEM DE DADOS O modelo de dados conceitual mais usado é o Modelo de Entidades e Relacionamentos (MER) desenvolvido por Chen em 1976 (Battini 92) e adotado em 1988 como modelo de dados padrão pela ANSI. O MER utiliza um diagrama (Diagrama de Entidades e Relacionamentos, DER) que contém uma estrutura simples e um conjunto de conceitos restritos:  entidades são qualquer objeto do mundo real sobre o qual se deseja guardar informações;  atributos são as informações sobre as instâncias de entidades, podendo ser propriedades, fatos ou características das entidades;  relacionamentos entre entidades é definido quando a informação desejada de uma entidade A diz respeito a uma entidade B e a recíproca é verdadeira. Assim existe um relacionamento entre a entidade A e B;  generalização/especialização define um conjunto de entidades que representam objetos do mundo real que se subdividem em categorias com atributos parcialmente distintos. Este foi um conceito introduzido em algumas extensões do MER;  agregação é utilizada ao se necessitar relacionar um conjunto de entidades e um conjunto de relacionamentos. O mecanismo de agregação define uma nova classe a partir de um conjunto de outras classes que representam seus componentes, ou seja, suas partes. Este também é um conceito introduzido, posteriormente, em algumas extensões do MER. O MER é um modelo bastante elogiado, mas existem também críticas. O conjunto de conceitos incorporados no seu diagrama é uma vantagem, pois provê um modelo poderoso de descrição da realidade. Entretanto, essa mesma simplicidade é criticada, pois alguns detalhes não podem ser plenamente documentados no modelo. Outra crítica é a de não existir um procedimento definido para construção do modelo (Batini 92).

3.4 MÉTODOS ORIENTADOS A OBJETOS O conceito de Orientação a Objetos (OO) no desenvolvimento de software tem sua raiz na linguagem Smalltalk. Nessa estrutura, os átomos da computação são objetos que mandam mensagens entre si. Essas mensagens resultam na invocação de métodos, que desempenham as ações necessárias. O objeto que envia a mensagem não necessita conhecer como o objeto está organizado internamente, somente a resposta do objeto, isto é, a mensagem específica enviada por esse objeto e seu formato (Colleman 94). Objetos são grupados em classes quando elas compartilham a mesma interface, respondem as mesmas mensagens da mesma forma. Isto permite que vários objetos possam ser descritos em poucas classes. O modelo é dinâmico, pois quando o sistema executa, objetos passam a existir, desempenham ações e depois cessam de existir ou tornam-se inacessíveis. Objetos e classes de objetos possuem atributos, sendo que todos os objetos de uma classe herdam os atributos das classes de que eles são membros. Algumas vantagens da Orientação a Objetos são apontadas, tais como, flexibilidade, reuso, extensibilidade e manutenibilidade. A abstração de dados, também é considerada uma vantagem, pois detalhes da representação das classes são visíveis somente para seus métodos, permitindo que diferentes implementações de uma classe possa ser usada sem modificação do código (Colleman 94).

Entretanto, alguns problemas também são mencionados: dificuldade de identificar objetos e classes, necessidade de mudanças no gerenciamento do projeto e falta de suporte para o trabalho em grupo (Colleman 94). Na literatura existem várias propostas de métodos de análise e projeto orientado a objetos: OOA/OOD (Object Oriented Analysis/ Object Oriented Design) de Coad e Yourdon (1992), OMT (Object Modeling Technique) de Rumbaugh et alli (1991), e OOIE (Object Oriented Information Engineering) de Martin e Odell (1992). O método Fusion (Colleman 94) é um método para desenvolvimento OO considerado de segunda geração que se baseou em outros métodos previamente definidos. Ele provê suporte para três fases:  Análise, no qual identifica objetos e classes do sistema, descreve seus relacionamentos e define as operações que o sistema deve desempenhar.  Projeto, onde se decide como representar as operações do sistema através da interação com os objetos relacionados e como esses objetos ganham acesso entre si.  Implementação, onde se codifica o projeto em uma linguagem de programação. UML é uma linguagem padrão para modelagem orientada a objetos. Ela surgiu da fusão de três métodos, do BOOCH, OMT (Rumbaugh et al) e do Jacobson. E é adotada como padrão para desenvolvimento orientado a objetos.

Bibliografia: 1) http://www.ime.uerj.br/~vera/projeto/apostila.pdf

2) http://www.inf.pucrs.br/~lleite/seII/material/ciclodevida.pdf

3) http://pt.wikipedia.org/wiki/Modelos_ciclo_de_vida

4) http://imasters.uol.com.br/noticia/1861/gerencia/modelos_de_ciclo_de_vida_por

_que_precisamos_deles_no_desenvolvimento/