Terceiro Resumo de Projeto de Engenharia de Software

Transcrição

1 Pontifícia Universidade Católica do Rio de Janeiro Terceiro Resumo de Projeto de Engenharia de Software Grupo Open Source: Eduardo Telles Giovani Tadei Marco Aurélio Renata Monique

2 Primeira Aula O aspecto da propriedade industrial do software (24/08/2004) 1) O que Aprendi A aula começou com algumas dúvidas sobre o tema da semana anterior, a teoria geral de sistemas (TGS). Foram explicados alguns termos: acoplamento, coesão e encapsulamento. O acoplamento é o grau de dependência entre dois módulos. Quanto menor o acoplamento, maior o reuso. O acoplamento fraco é quando um módulo passa apenas dados simples para o outro; esse é nível de acoplamento desejado, já que uma atualização não impactará tanto os demais módulos. Já o acoplamento médio é quando um módulo passa informações de controle para o outro. Por último temos o acoplamento forte, onde há informações compartilhadas entre os módulos; esse tipo de acoplamento deve ser evitado. O Just in time é uma idéia de não temos um estoque (ou buffer). A idéia é que a matéria prima chegue no exato momento em que será utilizada. Isso é um contraexemplo para a idéia de evitar o forte acoplamento, sem o qual não conseguimos ter o sincronismo necessário nessas situações. A coesão é o grau de interdependência entre os elementos de um módulo. Alguns tipos de coesão: aleatória ou incidental, a mais fraca, quando escolhemos indistintamente os elementos de um módulo, não havendo interdependência entre eles; lógica, quando os elementos possuem alguma funcionalidade correlata, mas não existe uma definição única e bem delimitada para o conjunto; temporal, quando os elementos estão em um mesmo módulo porque são acionados em um mesmo intervalo de tempo; procedural, quando os elementos são ativados um apos o outro; e a mais forte, a funcional, quando os elementos definem um único conceito. O encapsulamento ( ou information hiding ) é o ato de esconder parte do código, de maneira que só fique visível, ou acessível diretamente, o que for realmente necessário para a aplicação. Isso facilita a manutenção, protege os elementos contra alterações acidentais, além de permitir diferentes implementações para uma mesma interface. Alguns exemplos: encapsulamento de documentação (?) e encapsulamento de variáveis (?). Aspecto da propriedade industrial do software: Com o crescimento das empresas produtoras de software, mostrou-se necessário uma forma de regulamentar e proteger os softwares produzidos. Como não temos nenhuma proteção exclusivamente criada para atender essa necessidade, tentamos adequar as já existentes. Data: 31/08/2004 Página 1/5

3 A legislação de direitos autorais ou copyright foi a que mais se mostrou eficaz para a proteção do software. Em quase a totalidade dos países onde se admite a proteção, essa foi a forma admitida. Contudo, desde o início, com primeiros pedidos, surgiram vários opositores com fortes argumentos, como o de Paisant, que um software não constitui uma expressão que possa ser sentida pelo homem. Contudo, Le Stanc contraria tal afirmação, dizendo que como músicas ou películas cinematográficas, o software necessita de uma máquina (o computador) para tornar-se acessível aos sentidos humanos. O sistema de proteção à propriedade intelectual por patentes difere dos direitos autorais, pois exige que o bem protegido possa ser inserido em um processo industrial e também porque garante mais direitos aos titulares da proteção. Não foi necessário muito tempo para o repúdio a essa forma de proteção. Um dos fortes argumentos contrários ao patenteamento do software foi que o programa de computador em si escapa à idéia de industriabilidade, pois a máquina faz o processo produtivo e o programa somente o conduz. Se não está inserido em um processo industrial, não pode ser patenteado. A nova Lei de Patentes brasileira (Lei n /96) traz a expressa proibição do patenteamento de programas de computador (art.10, V). Software Livre X Software Gratuito Software livre (open-source) é um conceito de extrema importância no mundo da computação. Quando um software é livre, significa que seu código-fonte está disponível para qualquer um e você pode alterá-lo para adequá-lo às suas necessidades, sem ter que pagar. Portanto, software livre, é de fato gratuito, mas usar este termo somente para designar softwares sem custo, é um erro grosseiro. Associação Brasileira de Direito de Informática (ABDI ) o define como sendo "aquele com a permissão para qualquer um usar, estudar, copiar, e distribuir, com ou sem modificações". O melhor exemplo de software livre é o Linux, sistema operacional de código aberto criado por Linus Torvalds em Outro defensor deste tipo de programa é Richard Stallman que criou a Free Software Foundation em 1986, servindo de base para o desenvolvimento do GNU, um sistema operacional. A dupla GNU/Linux pode ser obtida gratuitamente na internet e representa umas das principais ameaças ao domínio absoluto do Windows da Microsoft. A principal diferença entre o software proprietário e o livre não é sua proteção legal, como muitos acreditam. Ambos estão protegidos pela Lei de Direitos Autorais e pela Lei do Software. A diferença está no licenciamento do programa que no primeiro caso é oneroso e no segundo gratuito. Além disto, no software proprietário o código fonte é fechado ao usuário, diferente do que ocorre no software livre, permitindo que este aperfeiçoe ou adapte o programa as suas necessidades. Os defensores do software livre apontam como vantagens deste programa: o custo econômico-financeiro da obtenção do software (quase sempre gratuito); a liberdade para adaptá-lo a cada usuário; a inclusão digital das pessoas de baixa renda que não tem acesso Data: 31/08/2004 Página 2/5

4 aos computadores e aplicativos e seu uso na administração pública que diminuiria os gastos com a área de informática. Por outro lado, seus críticos acusam os usuários de software livre de "pirataria" por criarem e desenvolverem este tipo similar aos software proprietários, o alto custo de manutenção que o software livre pode criar já que não há garantia prevista, nem assistência nos contratos de licenciamento gerais (GPL) de software livre; além de argumentarem sobre a inconstitucionalidade de leis que estão sendo aprovadas em diversos países, inclusive no Brasil, ao dar preferência ao software livre O software gratuito (freeware), por si só, é um software que você usa sem precisar pagar, mas só usa. Você não tem acesso ao seu código-fonte, portanto não pode alterá-lo ou simplesmente estudá-lo. Somente pode usá-lo, da forma como ele foi disponibilizado. Isso deixa claro a diferença entre software livre e um sofware simplesmente gratuito. 2) O que não entendi - Mesmo com a proibição pela lei brasileira de patentear softwares, ainda há alguma dúvida em qual forma de assegurar a propriedade do software? Na verdade não sei te responder. O uso de patente para software é comum na Europa e EUA, mas esses patentes são feitas com base nos algoritmos ou processos. Desconheço se essas brechas podem se utilizadas, tendo em vista proibição de programas de computador. Não sei também até que ponto esse assunto tem sido discutido (nova lei de informática?). Deleted: patentiar 3) O que duvido Não houve. Excelente resumo! Data: 31/08/2004 Página 3/5

5 Segunda Aula O famoso ou detestado ciclo de vida (26/08/2004) 1) O que Aprendi Da Biologia temos o termo Ciclo de Vida, tendo como principal característica a vida longa. Da Engenharia temos o termo Processo de Produção, cujo principal objetivo, ou característica, é a entrega. Ambos os termos procuram definir a produção de software. De acordo com a visão clássica, temos as fases bem definidas nesse processo de produção: Planejamento, Análise ou Definição de Requisitos, Projeto Lógico ou Desenho Lógico, Projeto Físico ou Desenho Físico, Codificação ou Produção, Teste, Manutenção ou Entrega. Sendo que do ponto de vista da Engenharia, a manutenção não faz parte do ciclo de produção. Essas fases estão em ciclo, de forma que constantemente temos que voltar à(s) fase(s) anterior(es), até mesmo como forma de dar e receber feedback. Na fase do projeto ou desenho lógico, temos a idéia mais geral dos sistemas, mais abstrata, sem comprometimento com técnicas de implementação, o que só é atingido na fase do projeto ou desenho físico. O custo da correção de erros é inversamente proporcional à fase em que foram encontrados, ou seja, o quanto antes detectado e corrigido o erro, menor o custo para o reparo, já que poucas fases se passaram. De acordo com algumas pesquisas, o custo de correção de erros encontrados na fase de planejamento é 1, enquanto que ao chegar na fase de codificação esse custo pode variar de 20 a 100. Por volta de 1985, a comunidade de software passou a discordar do ciclo de vida do software devido aos muitos projetos sem fim. Essa discórdia ficou explícita no artigo Parem o ciclo de vida que eu quero descer. Surge então uma nova proposta, o Processo de Prototipação, que é constituído das seguintes fases: definição, especificação, protótipo e feedback (que leva a uma nova definição). O protótipo gerado é geral e sem qualidade, sendo rapidamente substituído por outro. Esta é uma desvantagem desse processo, pois sendo sem qualidade, não poderia ser colocado em produção. Porém, isso acontece freqüentemente. Em 1988, Boehm propõe o Modelo Espiral, um modelo com desenvolvimento mais estruturado. Uma maneira simplista de analisar este modelo é considerá-lo como um modelo cascata onde cada fase é mais curta e precedida por uma análise de risco e sua Data: 31/08/2004 Página 4/5

6 execução é feita evolucionariamente (ou incrementalmente). E ao final de cada fase de testes temos um protótipo específico e de qualidade. Faltou um pouco mais detalhe sobre o tema. 2) O que não entendi - Qual a vantagem do Processo de Prototipação? Obtém-se um feedback bastante cedo, isto é existe um curto circuito no processo. A implementação em menos tempo, se por um lado ajuda aos clientes/usuários materializarem o sistema, por outro faz com que esse protótipo tenha várias falhas, justamente por ser feito rapidamente. O fato de ter-se a materialização precoce e um ciclo de feedback faz com que o problema (o sistema a ser feito) seja mais bem compreendido tanto pelos desenvolvedores como também pelos clientes/usuários. 3) O que duvido Não houve. Bibliografia: Data: 31/08/2004 Página 5/5