Uma proposta de um processo prático para apoiar o reuso de software

Transcrição

1 Uma proposta de um processo prático para apoiar o reuso de software Rosangela Kronig (UNIP) rkronig.mes.engprod@unip.br Ivanir Costa (UNIP) icosta@unip.br Mauro Spínola (UNIP) mspinola@unip.br Resumo A evolução da Engenharia de Software tem avançado consideravelmente nas últimas décadas, principalmente com o uso do paradigma de objetos, permitindo que a proposta de reutilização de funcionalidades, de regras de negócios ou mesmos de dados levaram à necessidade de uma nova proposta de processo para apoiar o desenvolvimento de softwares baseados em componentes. Esse processo é necessário na aplicação de uma abordagem de reuso de software exige a construção de um ambiente de informações que suporte a desde a descoberta, definição, documentação até a distribuição desses componentes. Palavras-chave: Administração de dados; Reuso de software; Componentes. 1. Introdução O objetivo deste artigo é apresentar um processo de Administração de Componentes como apoio ao desenvolvimento estruturado e padronizado de software baseado em componentes, relacionando suas atividades e um conjunto de tecnologias necessárias para sua efetiva implementação. A proposta desse processo baseia-se nas premissas da Administração de Dados, que surgiu com a finalidade de dar suporte ao desenvolvimento de sistemas baseados em banco de dados, promovendo a conceituação, segurança, integridade e compartilhamento dos dados corporativos armazenados. Inicialmente serão apresentados os fundamentos do processo da Administração de Dados para embasamento do processo da Administração de Componentes. De acordo com Pall (1987), um processo pode ser definido como uma organização lógica de pessoas, materiais, equipamentos, informações e procedimentos em atividades de trabalho orientadas a produzir um determinado resultado final. 2. Administração de dados No período de 1980, os conceitos da Engenharia de Informação foram definidos por James Martin e Clive Finkenstein. A premissa básica da Engenharia da Informação é que os dados permanecem no centro dos sistemas de informações e formaliza as técnicas pelas quais os dados são criados. (MARTIN & FINKELSTEIN, 1985). Neste mesmo período, surgiu a Administração de Dados como uma função da empresa responsável por desenvolver e administrar centralizadamente estratégias, procedimentos, práticas e planos capazes de disponibilizar os dados corporativos necessários, quando necessário, revestidos de integridade, privacidade, documentação e compartilhamento. (BARBIERI, 1994). 3. Processo de administração de dados O Processo de Administração de Dados corresponde a um conjunto de atividades, cuja missão é disponibilizar e manter a informação como um diferencial competitivo do negócio. ENEGEP 2005 ABEPRO 4243

2 As atividades mais evidentes estão diretamente associadas ao desenvolvimento e manutenção de sistemas. Dentro deste contexto é necessário caracterizar os papéis desempenhados e as principais atividades. Os seguintes papéis estão envolvidos com o processo de Administração de Dados: Administrador de dados (A.D.), responsável pelo planejamento, integração, segurança e disponibilização da informação como um recurso necessário aos processos de negócio. Gerencia o armazenamento e utilização dos dados nos aspectos relacionados à integridade, reutilização e segurança dos mesmos, assegurando uma documentação íntegra e de fácil acesso; Administrador de Banco de Dados (D.B.A.), responsável pelo mapeamento do modelo de dados em projetos de implementação, criação, manutenção, administração e otimização do SGBD (BARBIERI. 1994); Analistas de sistemas, envolvidos com as atividades de análise, modelagem e projeto de banco de dados. As atividades são apoiadas e executadas através de técnicas, ferramentas, normas e procedimentos estabelecidos no processo de Administração de Dados; Analistas de negócio, envolvidos com o levantamento dos requisitos de negócios, identificando as informações necessárias para dar suporte aos objetivos corporativos. Destacamos as atividades relacionadas com as funções do Administrador de Dados, responsável pelo trabalho metodológico e conceitual dos dados (BARBIERI, 1994): Identificar e compreender as necessidades de informação: presentes e futuras; Definir responsabilidades sobre os dados: geração, atualização e consulta; Definir critérios de segurança, proteção, integridade e privacidade dos dados; Desenvolver e implementar políticas, procedimentos e padrões para a criação e manipulação dos modelos de dados; Acompanhar, orientar e homologar os modelos de dados; Orientar no uso das técnicas, ferramentas de apoio à modelagem de dados, conceitos corporativos etc; Estabelecer o controle centralizado dos dados: dicionário de dados. O Processo de Administração de Dados utiliza-se dos seguintes recursos: Uma metodologia de desenvolvimento de sistemas, alinhada com as premissas da Administração de Dados; Um conjunto de técnicas para o desenvolvimento de sistemas em todas as fases, entre elas: JAD para levantamento de dados, modelagem de dados para análise e projeto de banco de dados, análise por pontos de função, entre outras; Uso de padrões para a incorporação de conceitos de dados, através de um glossário de termos, Ferramenta para apoio às técnicas utilizadas, destacando-se as ferramentas CASE, Repositório de dados para o armazenamento, a busca e a recuperação de modelos e todas as informações relacionadas. Com a estruturação do processo de Administração de Dados, os seguintes produtos são implementados: Fluxo do processo de administração de dados com a descrição detalhada das atividades; Roteiros de execução e responsabilidades das atividades; Check-list das atividades; Manual de normas e padronização; ENEGEP 2005 ABEPRO 4244

3 Manual técnico de modelagem de dados; Guia de utilização de ferramentas. A figura 1 apresenta uma macro-visão do Processo de Administração de Dados, em um ambiente de desenvolvimento de sistemas clássico. Figura 1. Visão macro do Processo de Administração de Dados 4. Administração de componentes A seguir, serão apresentados os fundamentos da Administração de Componentes necessários para o entendimento da proposta. 5. Ambiente de desenvolvimento baseado em componentes A solução de um problema, muitas vezes, é baseada na aplicação de uma solução similar que já foi desenvolvida ou adaptada para resolver um outro problema. O mesmo raciocínio pode ser aplicado na Engenharia de Software, para solução de um problema computacional. Desta forma, partes de software já desenvolvidas podem ser utilizadas novamente para auxiliar na solução de um novo problema (ROSSI, 2004). O desenvolvimento baseado em componentes (CBD) ou a Engenharia de Software baseada em componentes (CBSE), consolidou-se no final de 1990 com uma abordagem baseada no ENEGEP 2005 ABEPRO 4245

4 reuso, motivada pela frustração de que o desenvolvimento orientado a objetos não tinha conduzido a um efetivo reuso, como originalmente foi sugerido (SOMMERVILLE, 2003). Segundo Vitharana et al (2003), várias abordagens de desenvolvimento, da estruturada a orientada a objetos, tinham como propósito reduzir o risco e o custo de desenvolvimento. O desenvolvimento baseado em componentes é uma evolução dessas abordagens, pois tem como conceito construir um todo integrado a partir de partes padronizadas e independenteso artigo deve ser escrito no programa Word for Windows, em versão 6.0 ou superior. Se você está lendo este documento, significa que você possui a versão correta do programa. 6. Componentes O conceito de componente é extremamente abrangente, pois componente pode ser algo tão simples quanto um elemento de uma interface gráfica ou tão complexo como uma funcionalidade completa de um sistema. Os princípios que definem a tecnologia orientada a objetos são elementos importantes para a evolução do conceito de componentes de software. Segundo Costa (2003), o paradigma da orientação a objetos traz enormes benefícios ao desenvolvimento de software, pois ela torna o desenvolvimento e a manutenção muito mais fáceis. A aplicação correta do paradigma de objetos, com uso de encapsulamento de componentes, dos mecanismos de herança e polimorfismo tem produzido softwares cada vez mais simples, possibilitando a aplicação intensiva do reuso. Um componente é uma unidade de composição e deve ser especificado de tal forma, que é possível compô-lo com outros componentes e integrá-los nos sistemas de uma maneira previsível. Deve ter suas interfaces claramente documentadas e a sua implementação encapsulada (CRNKOVIC et al.,2003). 7. Reuso de Software O reuso de software tem sido praticado há muitos anos, à medida que estes sistemas de software são implementados em uma série de máquinas e adaptados para diferentes ambientes (SOMMERVILLE, 2003). Muitos dos sistemas de software que construímos são semelhantes. Há características comuns entre sistemas com propósitos semelhantes. Portanto, deve-se considerar estes sistemas, avaliar seus componentes e determinar suas adaptações ou até mesmo reutilizá-los por completo na construção de um novo sistema (PFLEEGER, 2004). Entende-se por reuso, o uso de um artefato na solução de problemas diferentes (IEEE-Std ) e por reuso de software, um artefato de software desenvolvido em outro lugar - em outro projeto ou em outra companhia e utilizado em mais de um contexto, com ou sem modificações (MORISIO et al, 2000). Um outro conceito importante é o de reusabilidade, que estabelece o grau para o qual um artefato de software pode ser utilizado em mais de um sistema de software ou na construção de outros artefatos de software (IEEE-Std ). Paralelamente a abordagem de reuso, temos o conceito da análise de domínio, que segundo Pressman (2000), tem por objetivo identificar, analisar e especificar os requisitos comuns de um domínio de aplicação específico, para reuso em vários projetos dentro do domínio da aplicação. Sommerville (2003), usa o conceito de famílias de aplicações, ou linha de produtos, para caracterizar um conjunto de aplicações relacionadas e que têm uma arquitetura de domínio específico em comum. O núcleo em comum da família de aplicações é reutilizado cada vez que uma nova aplicação é requerida. ENEGEP 2005 ABEPRO 4246

5 8. Infra-estrutura para especificação, controle e armazenamento de componentes No processo de desenvolvimento de sistemas através da utilização de componentes, é necessário descrever, compreender e identificar como integrá-los com outros componentes. Uma forma de representar este conjunto de informações é através de uma linguagem padrão de modelagem, como a UML (Unified Modeling Langauge), que define como modelar componentes através de seu metamodelo (HOPKINS, 2000). A UML é uma linguagem para especificação, visualização, construção e documentação de sistemas de softwares, bem como para modelagem de negócios e outros sistemas não ligados a softwares (FOWLER & SCOTT, 2000). Embora o UML seja uma linguagem de modelagem e não um método de software, ela fornece um conjunto de notações (principalmente gráficas) que podem ser usadas nas várias fases no ciclo de vida de um software (KOBRYN, 2000). Ainda segundo Kobryn (2000), os componentes na UML são modelados tipicamente nos diagramas de implementação, tais como diagramas de componentes e diagramas de utilização (deployment diagram). Um diagrama de componentes mostra a organização e as dependências dos componentes, e um diagrama de utilização mostra como os componente são acessados em nós computacionais. A UML suporta a modelagem de componentes, desde a modelagem lógica, através do diagrama de classes, passando pela modelagem física, através dos diagrama de componentes e diagrama de utilização ou deployment diagram. Desta forma, conforme Hopkins (2000), ela permite a rastreabilidade do componente através destes diagramas, desde a especificação lógica, passando pela definição do componente, até a execução. Um outro aspecto a ser considerado é o controle sobre as mudanças do componente durante o desenvolvimento e as possíveis manutenções. Uma gerência de configuração deve garantir a integridade do componente ao longo de seu ciclo de vida, identificando, organizando, rastreando e controlando as suas modificações. Para Pressman (2002), uma relação de recursos deve fazer parte da infra-estrutura de um ambiente de apoio à reutilização de componentes de software, que são: Base de dados de componentes capaz de armazenar os componentes de software e classificar a informação necessária para recuperá-los; Sistema de gerência de biblioteca que forneça acesso à base de dados de componentes; Sistema de recuperação de componentes de software que possibilite uma aplicação cliente recuperar os componentes e os serviços a partir do servidor de biblioteca; Ferramentas de engenharia de software baseada em componentes que forneçam suporte à integração de componentes reutilizáveis em um novo projeto ou implementação. Cada um destes recursos interage ou está incorporado a uma biblioteca de reutilização. 9. Processo de Administração de Componentes Semelhante ao processo de Administração de Dados, o processo de Administração de Componentes também é composto por um conjunto de atividades, ferramentas, papéis e responsabilidades, cuja missão é apoiar e promover o reuso de componentes de software, permitindo a redução do custo e do tempo de desenvolvimento de sistemas. No processo de Administração de Componentes destacam-se os seguintes papéis: Administrador de componentes, responsável por gerenciar o conjunto de informações e artefatos relacionados aos componentes reutilizáveis; ENEGEP 2005 ABEPRO 4247

6 Administrador de configuração de componentes, responsável por armazenar, catalogar e divulgar os componentes reutilizáveis para construção de novos sistemas; Analistas de sistemas, responsáveis pelas atividades de análise, modelagem e projeto de componentes. As atividades são apoiadas e executadas através de técnicas, ferramentas, normas e procedimentos estabelecidos no processo de Administração de Componentes; Analistas de negócio, envolvidos com o levantamento dos requisitos de negócios, identificando as informações necessárias para dar suporte aos objetivos corporativos; Programação, área responsável pela codificação e teste dos componentes. Destacamos as principais atividades relacionadas da Administração de Componentes, responsável pelo trabalho metodológico e conceitual dos componentes: Definir responsabilidades sobre os componentes: construção, manutenção e consulta; Definir critérios de segurança, proteção, integridade, certificação e privacidade dos componentes; Desenvolver e implementar políticas, procedimentos e padrões para a construção, manutenção, classificação, catalogação e certificação dos componentes; Orientar a confecção de componentes, através de padrões; Apoiar quanto ao uso de componentes reutilizáveis; Homologar a implementação de novos componentes; Estabelecer o controle centralizado dos componentes: biblioteca ou repositório de componentes. Infra-estrutura O Processo de Administração de Componentes deve ser apoiado pelos seguintes recursos: Uma metodologia de desenvolvimento de sistemas baseada em componentes, alinhada com as premissas da Administração de Componentes; Um conjunto de técnicas para o desenvolvimento de sistemas baseado em componentes para todas as fases, entre elas: JAD para levantamento de requisitos, UML, Use Case points, entre outras; Uso de padrões; Ferramentas para apoio às técnicas utilizadas, destacando-se as ferramentas CASE; Um repositório ou uma biblioteca para armazenamento, busca e recuperação de componentes e toda a informação relacionada. Uma biblioteca inclui uma base de dados, um dicionário de sinônimos e as ferramentas para consultas e recuperação dos componentes. Com a estruturação do processo de Administração de Componentes, os seguintes produtos são implementados: Fluxo do processo de administração de componentes com a descrição detalhada das atividades; Roteiros de execução e responsabilidades das atividades; Check-list das atividades; Manual de normas e padronização; Manual técnico; Guia de utilização de ferramentas. A figura 2 apresenta uma macro-visão do Processo de Administração de Componentes. ENEGEP 2005 ABEPRO 4248

7 Figura 2. Visão macro do Processo de Administração de Componentes 10. Conclusão O ambiente de desenvolvimento baseado em componentes (CBD) está se tornando o principal modelo de desenvolvimento de software, com uma abordagem voltada para a produtividade e benefícios da reutilização. Porém, a implementação da reutilização de software exige mudanças conceituais, culturais e tecnológicas no processo de desenvolvimento de sistemas. Neste cenário, consolida-se a importância de implementar um ambiente estruturado, padronizado e um conjunto de atividades e recursos organizados logicamente em um processo denominado Administração de Componentes, para apoiar o estabelecimento e o desenvolvimento de software baseado em componentes. ENEGEP 2005 ABEPRO 4249

8 Utilizando-se como base as premissas da Administração de Dados, espera-se obter os seguintes benefícios com a implementação de um processo de Administração de Componentes: Padronização, facilitando a construção de novos sistemas; Redução no tempo de desenvolvimento, com uma administração centralizada dos artefatos de softwares homologados e catalogados em uma biblioteca; Redução dos custos, com a utilização de artefatos de software reutilizáveis; Integração no desenvolvimento de sistemas; identificando os papéis e responsabilidades envolvidas no processo. A proposta do processo de Administração de Componentes, apresentada neste artigo, será implementada e testada no ambiente de fábrica de software do Laboratório de Pesquisa de Software do programa de Mestrado em Engenharia de Produção da UNIP Universidade Paulista. Referências BARBIERI, C. (1994) - Modelagem De Dados. Rio de Janeiro: Infobook. COSTA, I. (2003) - Contribuição para o Aumento da Qualidade e Produtividade de uma Fábrica de Software através da Padronização do Processo de Recebimento de Serviços de Construção de Softwares. São Paulo.Tese de Doutorado Escola Politécnica da Universidade de São Paulo CRNKOVIC, I. et al. (2002) - Specification, implementation, and deployment of components. Communications of the ACM, v. 45, n. 10, p FOWLER, M.; SCOTT, K. (2000) - UML Essencial, Brasil: Bookman, Porto Alegre. HOPKINS, J. (2000) - Component Primer.Communications of the ACM, v..43, n. 10, p IEEE-Std 1517 (1999) - IEEE Standard for Information Technology Software Life Cycle Processes Reuse Processes. KOBRYN, C. (2000) - Modeling components and frameworks with UML. Communications of the ACM, v. 43, n.10, p MARTIN, J.; FINKELSTEIN, C. (1985) - Engenharia da Informação. São Paulo: Compucenter Sistemas, Fascículo 1-3. MORISIO, M.; TULLY, C.; EZRAN, M..(2000) - Diversity in reuse processes. IEEE Software, v. 17, n.4, p PALL, G.(1987) - Quality Process Management. Prentice Hall. PFLEEGER, S. L.(2004) - Engenharia de Software: Teoria e Prática. 2º ed. São Paulo: Prentice Hall. PRESSMAN, R.S. (2002) - Engenharia de Software. 5º.ed.. Rio de Janeiro: McGraw-Hill. ROSSI, A.C. (2004) - Representação do Componente de software na FARCSoft: ferramenta de apoio à reutilização de componentes de software. São Paulo. Tese de dissertação - Escola Politécnica, Universidade de São Paulo. São Paulo. SOMMERVILLE, I.(2003) - Engenharia de Software. 6ed., São Paulo: Addison Wesley. VITHARANA, P; ZAHEDI, F.M.; JAIN, H.(2003) - Knowledge-based repository scheme for storing and retrieving business components: a theoretical design and an empirical analysis. IEEE Transactions on Software Engineering, v.29, n.7, p ENEGEP 2005 ABEPRO 4250