Investigação a respeito de fatores limitantes para reuso de artefatos de processo de software

UNIVERSIDADE FEDERAL DO RIO GRANDE DO NORTE

CENTRO DE TECNOLOGIA

DEPARTAMENTO DE ENGENHARIA DE COMPUTAÇÃO E AUTOMAÇÃO

CURSO DE ENGENHARIA DE COMPUTAÇÃO

Investigação a respeito de fatores limitantespara reuso de artefatos de processo de software

Renata Brasil Silva

Orientador: Prof. Samuel Xavier de Souza

Natal, RN, Dezembro de 2012

Investigação a respeito de fatores limitantes para reuso deartefatos de processo de software

Renata Brasil Silva

Orientador: Prof. Samuel Xavier de Souza

Monografia apresentada à Banca Examina-dora do Trabalho de Conclusão do Curso deEngenharia de Computação e Automação,em cumprimento às exigências legais comorequisito parcial à obtenção do título de En-genheiro de Computação e Automação.


Trabalho de Conclusão de Curso aprovado em 20 de dezembro de 2012 pela banca exa-minadora composta pelos seguintes membros:

—————————————————————————-Prof. Dr. Samuel Xavier de Souza

Orientador

Departamento de Computação e Automação - UFRN

—————————————————————————-Prof. Dr. Luiz Felipe de Queiroz Silveira

Departamento de Computação e Automação - UFRN

—————————————————————————-Prof. Dr. Reinaldo Antônio Petta

Departamento de Geologia - UFRN


Agradecimentos

Agradeço à minha família por me fornecer suporte emocional durante todo o curso. Mi-nhas irmãs Adriana, Patrícia, Maria do Socorro e Daniela por confiarem e cuidarem demim durante o percurso percorrido na graduação. E, sobretudo aos meus pais que insisti-ram em me proporcionar educação de qualidade ao longo da minha carreira estudantil medando a oportunidade de chegar até aqui.

A todos os meus colegas de curso e de trabalho que tornaram a convivência fácil, praze-rosa e muito divertida. Que estiveram presentes oferecendo ajuda e crescendo juntos nodia-a-dia.

Aos meus amigos e sócios Eduardo André, Douglas Leandro, Victor Lennon e AlbanoRocha, por toda a motivação e companheirismo.

A todos os professores do DCA, por contribuírem com a minha formação estimulandomeu esforço e aprendizado, e em especial ao meu orientador, Prof. Samuel Xavier deSouza pela confiança.

Ao meu co-orientador, Júlio Gustavo Costa que me auxiliou na pesquisa e em grandeparte da construção deste trabalho.

Resumo

Este trabalho apresenta a investigação dos elementos que contribuem para que os sis-temas de informação que seguem metodologias de reuso de artefatos de software não con-sigam um grau satisfatório para isto. Através da avaliação de aspectos e conceitos usadosem processos de desenvolvimento de produtos computacionais, tais como: Engenharia deDomínio, Desenvolvimento Baseado em Componentes, Orientação à Objetos e Linhas deProdutos de Software, identificou-se que o principal fator limitante para que os softwaressejam produzidos com o mínimo esforço possível é o acoplamento sintático-semânticodas fases desse desenvolvimento.

Partindo da aplicação das metodologias amplamente discutidas na Engenharia de Soft-ware em um sistema tomado como modelo - uma agenda de compromissos e contatos -extrai-se a crítica necessária para sugerir uma solução viável baseada em uma arquite-tura amorfa que consegue o desacoplamento sintático-semântico da etapa de codificação,concentrado os esforços de produção de software na construção do modelo.

Palavras-chave: Engenharia de Domínio, Desenvolvimento Baseado em Componen-tes, Linhas de Produto de Software, Interpretador de semântica, Modelo de Software,Interpretador de Semântica, Arquitetura Amorfa.

Abstract

This paper presents research into the elements that contribute to information systemsthat follow methodologies reuse of software artifacts not achieve a satisfactory degree forthis. Through the evaluation of aspects and concepts used in the development processesof computing products, such as Domain Engineering, Component Based Development,Object-Orientation and Software Product Lines, we identified that the main limiting factorfor the software can be produced with minimum effort possible is the coupling syntactic-semantic stages of this development.

Starting from the application of the methodologies discussed widely in Software En-gineering in a system taken as a model - a calendar and contacts - extract the necessarycritical to suggest a viable solution based on an amorphous architecture that achieves de-coupling syntactic-semantic stage coding, concentrated efforts to produce software forconstructing the model.

Keywords: Domain Engineering, Component Based Development, Software ProductLines, Interpreter semantics, Model Software, Semantic Interpreter, Amorphous Archi-tecture.

Sumário

Sumário i

Lista de Figuras iii

Abreviaturas iv

1 Introdução 11.1 Contexto e Motivação . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.3 Organização do Documento . . . . . . . . . . . . . . . . . . . . . . . . . 2

2 Fundamentação Teórica 42.1 Visão Geral . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42.2 Engenharia de Domínio . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.3 Orientação à Objetos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.4 Desenvolvimento Baseado em Componentes (DBC) . . . . . . . . . . . . 92.5 Linha de Produtos de Software (LPS) . . . . . . . . . . . . . . . . . . . 102.6 Discussão de custos nas abordagens existentes . . . . . . . . . . . . . . . 11

3 Análise do Processo de Desenvolvimento de Software 133.1 Visão Geral . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3.1.1 Sintaxe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143.1.2 Semântica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

3.2 Acoplamento Sintático-Semântico . . . . . . . . . . . . . . . . . . . . . 143.2.1 Desenvolvimento baseado em orientação a objeto sob o prisma

do acoplamento sintático semântico . . . . . . . . . . . . . . . . 153.2.2 Desenvolvimento baseado em componentes (DBC) sob o prisma

do acoplamento sintático semântico . . . . . . . . . . . . . . . . 253.2.3 Conclusão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

i

4 Metodologia 304.1 Desacoplamento Sintático-Semântico . . . . . . . . . . . . . . . . . . . 304.2 Arquitetura Amorfa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324.3 Exemplo: Agenda de Compromissos e Contatos . . . . . . . . . . . . . . 34

5 Conclusões 365.1 Contribuições do Trabalho . . . . . . . . . . . . . . . . . . . . . . . . . 365.2 Trabalhos Futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

Referências bibliográficas 38

Lista de Figuras

2.1 Ciclo de vida de um processo de desenvolvimento de software . . . . . . 42.2 Ciclo de vida da Engenharia de Domínio . . . . . . . . . . . . . . . . . . 72.3 Evolução do desenvolvimento de produtos . . . . . . . . . . . . . . . . . 11

3.1 Representação do que seria o fluxo de desenvolvimento de software . . . 143.2 Artefato: Diagrama de Classes . . . . . . . . . . . . . . . . . . . . . . . 163.3 Artefato: Diagrama de Classes . . . . . . . . . . . . . . . . . . . . . . . 203.4 Artefato: Diagrama de Classes . . . . . . . . . . . . . . . . . . . . . . . 233.5 Artefato: Diagrama de Classes . . . . . . . . . . . . . . . . . . . . . . . 263.6 Sintaxe e semântica ao longo de um processo de desenvolvimento de soft-

ware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

4.1 Estrutura de classes de Domínio . . . . . . . . . . . . . . . . . . . . . . 314.2 Representação do esquema da arquitetura amorfa . . . . . . . . . . . . . 334.3 Representação do modelo da arquitetura amorfa . . . . . . . . . . . . . . 34

iii

Abreviaturas

DBC: Desenvolvimento Baseado em ComponentesLPS: Linhas de Produtos de SoftwareUML: Unified Modeling Language

OO: Orientação à ObjetoMVC: Model-view-controller

AP: Application Client

AS: Application Server

PS: Provider Semantic

CRUD: Create, Read, Update e Updade

Capítulo 1

Introdução

1.1 Contexto e Motivação

O progresso dos sistemas operacionais e das empresas de informática por trás delespopularizou o uso de computadores. A facilidade que as interfaces com os usuários pro-porcionam foi a principal causa desse crescimento.

O mercado enxergou nesse avanço, uma solução para aproximar os clientes e princi-palmente melhorar os mecanismos de gerência financeira e de estoques através do uso desoftwares.

Com a evolução das metodologias de desenvolvimento de software que surgiram a par-tir disso, hoje a construção de sistemas de informática não é uma tarefa pensada apenaspara resolver problemas de grandes corporações e sim algo palpável para suprir necessi-dades de usuários comuns e pequenos comerciantes.

Para tanto, o estudo na área de Engenharia de Software auxiliou nesse avanço aosugerir conceitos que viabilizam aos profissionais da área serem capazes de compartilharformas de análise de problemas e suas soluções. Estimulou-se, então, a ideia de reuso deprocessos de software.

Durante o desenvolvimento de um sistema de informática, procura-se identificar eespecificar etapas - artefatos de software - que compõem todo o desenvolvimento paraque a produção do software seja orientada e gerenciada tal como se faz na indústria ao seutilizar as linhas de produção.

Neste contexto, foi possível perceber que as metodologias - que existem e são aplica-das nos dias de hoje - para gerência e desenvolvimento de sistemas computacionais sãocarentes de técnicas que ofereçam um grau satisfatório de reuso de artefatos de software,visto que, a necessidade de manutenção destes sistemas implica em altos custos sempreque for necessário alterar requisitos ou corrigir falhas do software em operação.

Este trabalho propõe uma investigação dos fatores que prejudicam a concepção de

CAPÍTULO 1. INTRODUÇÃO 2

sistemas de software utilizando reusabilidade. E sugere, a partir do que foi revelado nestainvestigação, um método que pretende aumentar o grau de satisfatibilidade de reuso emsistemas de informação, isto é, minimizar custos de desenvolvimento e manutenção deprodutos de software.

As metodologias utilizadas e exaustivamente estudas atualmente, nasceram em con-sequência dos desenvolvedores, em muitas ocasiões, se depararem com sistemas que ti-nham características nucleares e intrínsecas identificadas em outros sistemas pertencentesa um domínio de problema diferente. Assim surgiram os conceitos de Engenharia deDomínio, Desenvolvimento Baseado em Componentes (DBC) e Linhas de Produtos deSoftware (LPS). Metodologias que tem como objetivo identificar essas características esepará-las de, tal forma, que seja possível construir um produto a partir de componentese artefatos de software reusáveis.

Ainda que façamos uso das abordagens atuais de gerência de processos de desen-volvimento de software, sempre que ocorre necessidade de interferir em alguma fase dodesenvolvimento - quer seja por falha na análise de requisitos, quer seja por detecção deerros na etapa de produção - as fases seguintes são afetadas e os profissionais responsáveispor elas devem trabalhar novamente até que o produto final consiga ser fiel aos documen-tos de requisitos e o sistema seja estável, isto é, que o produto resultante esteja de acordocom os requisitos do cliente contratante e funcionando sem falhas.

1.2 Objetivos

O objetivo deste trabalho é identificar quais os empecilhos encontrados pelas metodo-logias existentes em Engenharia de Software para reuso através do estudo dos conceitosenvolvidos e em contrapartida indicar um caminho para contorná-los.

1.3 Organização do Documento

Este documento está organizado em mais quatro capítulos além deste introdutório.O capítulo 2 apresenta a fundamentação teórica definindo em suas subseções: Enge-

nharia de Domínio, Desenvolvimento Baseado em Componentes (DBC), Linhas de Pro-dutos de Software (LPS) e discutindo brevemente a relação de custos de projeto quandoaplicamos cada um dos conceitos expostos nas subseções anteriores, de tal forma queforneça a motivação para buscar uma nova abordagem que elimine - ou amenize - asdesvantagens encontradas.

CAPÍTULO 1. INTRODUÇÃO 3

O capítulo 3 apresenta o estudo das dificuldades de fazer reuso indicando que issoacontece devido ao acoplamento sintático semântico. Para ilustrar esta situação, sugere-se uma aplicação simples de uma Agenda de Compromissos e Contatos aplicando duastécnicas diferentes de reuso, e a partir daí, expondo quais as dificuldades encontradaspelas abordagens existentes.

O capítulo 4 discute a metodologia usada para a investigação e inferência da soluçãoencontrada. Solução esta que pode aumentar o grau de satisfação de reuso: o desacopla-mento sintático semântico. E isto é posto de tal forma, que descrevemos o que poderia vira ser a estrutura de um interpretador para modelos de software. Base para uma arquiteturaamorfa.

Por fim, no capítulo 5, retomamos a discussão à respeito do acoplamento sintático se-mântico e finalizamos expondo as contribuições do trabalho e as sugestões para trabalhosfuturos.

Capítulo 2

Fundamentação Teórica

Neste capítulo são apresentados os conceitos fundamentais para entender o processode desenvolvimento de software. As seções 2.1, 2.2, 2.3 e 2.4 expõem metodologias queviabilizam reuso no desenvolvimento de software (Engenharia de Domínio, Orientação àObjeto, Desenvolvimento Baseado em Componentes e Linhas de Produtos de Software).E a seção 2.5 apresenta uma breve discussão acerca dos custos envolvidos na produção desoftware utilizando estas técnicas estudadas em Engenharia de Software.

2.1 Visão Geral

O desenvolvimento de um sistema de informação normalmente segue algumas etapas(ver Figura 2.1) para garantir que ao final de todo o processo, o resultado seja um pro-duto confiável e de acordo com as expectativas do cliente final. Estas etapas, em geral,compreendem [AURUM 2005]:

Figura 2.1: Ciclo de vida de um processo de desenvolvimento de software

• Levantamento de requisitos: equipe de analistas deve tentar prever as necessida-des do usuário descrevendo requisitos funcionais e não funcionais, além das regrasde negócio do sistema.

CAPÍTULO 2. FUNDAMENTAÇÃO TEÓRICA 5

• Análise de requisitos: deve-se verificar o impacto de uma determinada funcionali-dade, analisar as restrições que ela impõe ao sistema e resolver como implementá-la.

• Definição da arquitetura: compreende as etapas de Construção do modelo e Co-dificação (vistas na Figura 2.1). Escolhe-se a metodologia de desenvolvimento docódigo-fonte. Isso inclui definir a linguagem de programação, o ambiente de de-senvolvimento, os padrões de projeto envolvidos e outras características necessáriaspara o produto final.

• Verificação e Validação: o software é liberado para que haja a verificação de ocor-rências de falha nas funcionalidades (testes) e se estas funcionalidades estão deacordo com os requisitos, isto é, com o que o usuário definiu inicialmente comocomportamento do sistema (validação).

• Operação: quando o sistema entra em produção.

Apesar de mais lógico, estas etapas não ocorrem obrigatoriamente em sequência de talmaneira que o próximo passo só aconteça quando o atual é concluído. O ideal é que sejamrealizadas paralelamente para que todo o desenvolvimento do software seja orientadoà gerência de requisitos a fim de evitar custos maiores por alterações em requisitos oufalhas na escolha da infraestrutura de software e sua codificação em uma fase anterior dociclo[AURUM 2005].

A validação e verificação, por exemplo, são executadas diversas vezes enquanto oproduto computacional vai sendo desenvolvido e seu objetivo é encontrar o maior númeropossível de erros para garantir a estabilidade do código, por esta razão, os requisitos de-vem estar sempre sendo atualizados para eliminar ambiguidades e inconsistências, pois éatravés da especificação de funcionalidades e da definição de suas métricas que é possívelter os parâmetros para a realização dos testes [KOTONYA 1998] [PRESSMAN 2006].

2.2 Engenharia de Domínio

Sistemas diferentes podem possuir muitas características similares que precisam serreaproveitadas visando, sobretudo, enxugar os custos de desenvolvimento e manutenção.

A Engenharia de Domínio é a área de estudo da Engenharia de Software responsávelpor investigar o domínio do problema e oferecer uma solução voltada para o reuso decomponentes.

Enquanto a Engenharia de Requisitos existe para garantir que todo o processo dedesenvolvimento de software seja útil para produzir um sistema estável sem se preo-


cupar em especificar uma única solução para isto, a Engenharia de Domínio é menosgeneralista porque o resultado da sua aplicação será uma única solução que utiliza al-guma metodologia de desenvolvimento que envolva reuso para o domínio do problema[GUIZZARDI 2000]. Em comparação com a Engenharia de Requisitos, usando Enge-nharia de Domínio, as etapas serão equivalentes [GUIZZARDI 2000] (conforme vimosna Figura 2.2):

• Análise de Domínio: o domínio do problema é estudado com detalhes.• Especificação de Domínio: a partir do conhecimento do domínio, devem ser de-

finidos os relacionamentos entre classes e entidades que o sistema terá a fim degarantir que será possível gerar componentes reusáveis.

• Definição da infraestrutura: implementação dos componentes da arquitetura usandopadrões de projetos e outros artefatos reusáveis a partir das especificações levanta-das na etapa anterior.

Quanto a análise de Requisitos, esta é a etapa anterior ao desenvolvimento do código-fonte de um sistema de informação. A etapa que precede esta, o levantamento de requisito,é o processo onde o cliente é ouvido e define-se o comportamento do software.

No levantamento de requisitos, há a tentativa de descrever os casos de uso que o sis-tema terá. Essa descrição inclui os usuários que acessarão determinada funcionalidade,todo o fluxo que essa funcionalidade terá - inclusive se houver fluxos extras - o compor-tamento esperado e informações sobre pré-condições para acesso da mesma.

As etapas de Levantamento de Requisitos e de Análise de Requisitos correspondemao levantamento do modelo conceitual do sistema. Como ferramenta de descrição do mo-delo, utiliza-se a linguagem de modelagem unificada UML (Unified Modeling Language)composta de elementos como diagramas e regras padronizadas e aceitas pela comunidadede computação.

Ao término dessas etapas de levantamento de modelo, os desenvolvedores e o clienteterão em mãos dois documentos contendo a especificação do sistema. O Documento deDefinição de Requisitos (ou apenas documento de requisitos) e o Documento de Especi-ficação [PFLEEGER 2004][SOMMERVILLE 2007].

O primeiro a ser desenvolvido é o Documento de Definição de Requisitos. Ele é com-posto dos requisitos funcionais, não funcionais e requisitos de domínio (regras de negócio)descritos em linguagem simples e compreensível para um usuário comum. Deve conterdescrição dos casos de uso e seus fluxos bem como suas pré-condições (requisitos funcio-nais) e descrição das restrições do sistema (requisitos não funcionais) e regras de negócio.


Figura 2.2: Ciclo de vida da Engenharia de Domínio


Se for necessário, pode ser usado o recurso dos diagramas de casos de uso. Diagramas daUML descrevendo através de elementos gráficos o comportamento do sistema.

Somente a partir do Documento de Definição de Requisitos é que é possível ter o Do-cumento de Especificação de Requisitos que tem exatamente todas as funcionalidades dodocumento anterior. A diferença é o grau de detalhamento e informações relevantes paraos desenvolvedores. Pois este especifica detalhes envolvidos como classes de domínio,tabelas do banco, usuários que podem ter acesso ao caso de uso, cenários para comporta-mentos esperado e inesperado e dados para testes. Ou seja, a partir desse texto, qualquerdesenvolvedor da equipe é capaz de implementar o caso de uso e testá-lo.

A análise de requisitos é hoje imprescindível, pois dá suporte a todo o desenvolvi-mento e principalmente a manutenção de um sistema de informação. Ela ocorre durantetodo o processo de desenvolvimento do software, para que se assegure a estabilidade doproduto final.

A decisão de que metodologia de implementação escolher é totalmente independentedeste passo. O que deve ser levado em conta para a construção da arquitetura é a finalidadedo sistema e principalmente os custos de desenvolvimento e manutenção.

2.3 Orientação à Objetos

O desenvolvimento de software baseado no paradigma Orientado à Objeto (OO) su-gere que todas as fases desse processo sejam realizadas usando a abordagem OO.

Segundo [ROSADO 2003], as principais vantagens existentes em utilizar este para-digma são:

• Encapsulamento: permite que os componentes do código estejam protegidos dealterações externas indevidas, pois sua estrutura e comportamento não estão trans-parentes para os desenvolvedores. O que se conhece são as especificações do objetoe não detalhes de como implementar os métodos.

• Herança: contribui para que haja menos classes, pois uma classe que herda deoutra possui a mesma estrutura de dados (atributos) da superclasse e o mesmo com-portamento (métodos).

• Escalabilidade: capacidade de usar o mesmo código para finalidades diferentesrealizando apenas pequenas mudanças na implementação.

• Reusabilidade: característica que existe em decorrência dos pontos anteriormentecitados.


Na fase de construção do modelo, existem inúmeras técnicas que podem ser apli-cadas, tais quais: método Booch, TMO, OOSE/Objectory, Fusão e Coad/Yourdon, paracitar alguns. A diferença entre eles pode ser notada quanto a quantidade de diagramas,detalhamento de informações e notação que é necessário para descrever o modelo.

A principal atribuição da análise orientada à objeto é tentar estudar o domínio doproblema para encontrar como solução o melhor modelo. Um bom modelo consegue serfacilmente alterado - sempre que haja demanda externa, como mudança em requisitos- sem gerar grandes impactos no sistema. Por isso, este paradigma é frequentementeutilizado junto com o conceito de Engenharia de Domínio para gerar softwares com altograu de escalabilidade.

2.4 Desenvolvimento Baseado em Componentes (DBC)

Diante das inúmeras metodologias que vem sendo estudada para propor sistemas es-táveis e reusáveis, o desenvolvimento baseado em componentes é a abordagem através daqual se cria um modelo para concepção de componentes - ou artefatos reutilizáveis - depropósito mais genéricos - podendo sofrer adaptações ou não (adaptabilidade) - e uso decomponentes existentes que estão incorporados a uma arquitetura.

Outras áreas da engenharia sempre usaram a ideia de componentes. Podemos verexemplos na engenharia elétrica, mecânica, naval e etc. Na própria indústria, produtossão desenvolvidos por uma organização a partir de estruturas prontas fornecidas por ou-tras, pois não é necessário reinventar, produzir e testar cada elemento sempre que estiverconstruindo um novo produto. Isso elevaria os custos e o tempo de produção.

No caso da engenharia de software, um componente pode ser classe, interface e atémesmo relacionamento entre classes, contudo existem componentes de nível mais altode abstração como padrões de projeto, documentação e frameworks. Estes últimos, ge-ralmente são projetos em uma linguagem específica que são integrados ao produto emdesenvolvimento, fazendo-se as alterações necessárias para que ele se adeque à finalidadedo sistema. Os artefatos estão especificados, possuem uma interface bem definida e jáforam testados, portanto há a garantia que funcionam. É através da interface que sabe-mos quais são suas funcionalidades, como fazer adaptações e entendemos como podemosusá-los juntamente com outros.

A prática de DBC produz uma série de instruções de como produzir artefatos de soft-ware, como adaptá-los, alterá-los e como integrá-los aos existentes em uma infraestrutura.A principal ferramenta para fazer as descrições é a linguagem UML, que por ser padroni-zada pela comunidade de computação, é consistente e inteligível.


Ao usar o conceito de DBC, o modelo de software resultante está organizado a partirde componentes - que para uma linguagem de computador seria um pacote - de tal formaque para expandir o sistema, basta que sejamos capazes de reconhecer o formato doscomponentes para fazer uma refatoração ou construir novos.

2.5 Linha de Produtos de Software (LPS)

Linhas de Produto de Software é mais uma solução para reuso na Engenharia de Soft-ware e baseia-se na ideia de linhas de produção das indústrias para diminuir os custos deprodução e aumentar as margens de lucros das empresas.

Para entender a ideia, basta imaginarmos o processo de criação de um produto indivi-dualizado. Este produto deve contemplar tudo o que o cliente que vai comprá-lo precisa,logicamente como partimos do zero na produção, o andamento de todo o processo até che-gar ao item final vai ser demorado com relação à situação em que temos todo o alicerce deuma linha de produção, onde o artefato é montado a partir de componentes selecionadosem uma etapa de planejamento e a partir da base de conhecimento que especifica comoconstruir aquele item.

Usando LPS como critério para a fabricação de sistemas computacionais, o produtogerado não atende apenas um cliente, mas sim um grupo de clientes que está interes-sado em obter soluções para uma classe de problemas identificados. Podemos citar comoexemplo: softwares de gerenciamento de estoque, de gerência financeira e gerência derecursos humanos. A desvantagem imediata de ter um software genérico como esse é aausência de funcionalidades específicas existentes em cada empresa, porém, para o usuá-rio comprador o custo é bem menor do que o de um produto feito sob demanda usando astécnicas convencionais de elaboração de softwares.

Em oposição ao que normalmente acontece nos procedimentos comuns para constru-ção de sistemas usando Engenharia de Software, para implantar este paradigma de Linhade Produtos ou Família de Produtos de Software, é preciso que haja uma mudança es-trutural na empresa. A adoção dessa metodologia só é possível com a adoção de prazos,metas e cronogramas que precisam ser cumpridos para que resultados positivos possamvir e esses resultados são observados somente a médio prazo. Isso porque no princípio doprocesso, há muito tempo direcionado às atividades de análise e planejamento dos ativosde base que comporão a plataforma da família de produtos [DA SILVA et al. 2011]. Apósessa etapa inicial, as demais são bem mais rápidas.

Para montar a plataforma que será o alicerce dos softwares que compõem a Linhade Produtos, a equipe de Engenharia de Domínio e Requisitos deve produzir os Ativos


Figura 2.3: Evolução do desenvolvimento de produtos

Base. Ativos Base são o conjunto de artefatos que farão parte do esqueleto da arquite-tura. Requisitos, Arquitetura, Implementação e Testes reusáveis são ativos base de umaplataforma [DA SILVA et al. 2011].

Uma vez definidos, quando pretendemos lançar um produto, basta fazer uma instanci-ação desses elementos base atendendo a possíveis variações e pronto. Temos um softwareestável e fácil de ser testado. Na hipótese de haver necessidade de acréscimo de funcio-nalidades, a equipe de desenvolvimento pode lançar uma extensão para ser incorporadaao software e este deverá funcionar normalmente.

2.6 Discussão de custos nas abordagens existentes

O conceito de reusabilidade é aplicado em praticamente todas as áreas de conheci-mento, porque nós temos a capacidade natural de observar o meio e adaptá-lo para melho-res experiências, então é normal que observemos e classifiquemos os problemas existentesa fim de usar as soluções já conhecidas e confiáveis.

Portanto, nas engenharias isso não é diferente. No desenvolvimento de software, aindahá uma grande dificuldade de incorporar metodologias desse tipo, pois sob alguns pontos,conceber um software é uma tarefa com certo grau de subjetividade, isto é, o comporta-mento de um sistema pode ser programado usando vários critérios diferentes, porque cadaprofissional tem uma forma de lidar e resolver problemas.

Percebendo que os esforços para a produção de software estavam se tornando muitocustosos devido ao nível de complexidade que os sistemas foram ganhando com o pas-sar do tempo, a ausência de metodologias comprovadamente eficientes de gerência deprocessos de software e com o aumento das exigências do mercado, as organizações fo-


ram obrigadas a direcionar seu interesse para o estudo de reusabilidade de artefatos deprocessos de construção de softwares.

Com isso surgiram diversas metodologias que oferecem um processo de desenvol-vimento de software focado na gerência e redução de custos de desenvolvimento e ma-nutenção. Neste contexto, surgiu as tecnologia anteriormente discutidas neste trabalho:Engenharia de Domínio, Desenvolvimento Baseado em Componentes e Linhas de Produ-tos.

Papel da Engenharia de Domínio é analisar os requisitos e sugerir um projeto de de-senvolvimento de software orientado à reusabilidade dos artefatos, sem com isso prefixaras metodologias que serão usadas pelo restante do processo. A dificuldade aqui, portanto,reside na exigência de tempo necessário para que os engenheiros de domínio possam re-alizar, a contento, seu trabalho. Nem sempre, para o cliente, esperar por um produto dequalidade é atraente. O mercado é pragmático e muitas vezes encaram esses processos deanálise e projeto como preciosismo - tomando-os, portanto, como desnecessários.

Para DBC, por exemplo, a dificuldade é localizar dentre os componentes existentes,aqueles que são apropriados ao processo de produção do software em questão, já quenem sempre existem componentes em quantidade e que sejam bem documentados. Usarcomponentes pode diminuir o trabalho de codificação, mas em termos de reuso, quandopossível, o grau de satisfação ainda não é suficiente. E isso devido às exigências deadaptação ao novo contexto em que deve ser empregado.

Por outro lado, para adotar a metodologia LPS, além de ser necessário uma mudançade mentalidade da equipe de desenvolvedores, é preciso que haja engenheiros de softwareque detenham vasto conhecimento das etapas desse paradigma [DA SILVA et al. 2011].Além de serem capazes de garantir a execução do planejamento uma vez que pode ha-ver insatisfações quanto à verificação de resultados positivos (os resultados da aplicaçãodesta metodologia ocorrem no longo prazo). Outra desvantagem é a demora em iniciar aprodução devido à execução das fases do processo. Outro ponto relevante em termos decusto desse tipo de procedimento é o foco, que em primeira vista parece ser vantajoso,contudo, em termos de customização é claramente desvantajoso: o ponto final não é umcliente específico e suas necessidades e sim um mercado de clientes.

Capítulo 3

Análise do Processo de Desenvolvimentode Software

Este capítulo descreve como ocorrem as fases de desenvolvimento de software en-cenando como as mudanças que podem ocorrer devido a falhas na análise de requisitos,falhas de modelagem ou modelo, ou acréscimo de novas funcionalidades podem afetartodas as fases de projeto provocando o retrabalho e aumento dos custos [AURUM 2005].

3.1 Visão Geral

Observando o processo de construção de software, exaustivamente discutido em dis-ciplinas da Engenharia de Software, nota-se que o processo como um todo emprega di-ferentes linguagens com a finalidade de representar, fase a fase do processo, um dadoconjunto de conhecimento. Cada uma das fases possuem finalidades específicas e, porisso mesmo, uma linguagem apropriada para representação do conhecimento em ques-tão. Este capítulo tem por fim apresentar de forma sucinta o processo de construção desoftware para uma dada instância de domínio de conhecimento (uma agenda de compro-missos) e investigar os impactos, pelo prisma do acoplamento sintático-semântico dasformas de representação do conhecimento (sobretudo na fase de desenvolvimento do pro-cesso) quando são exigidas alterações de requisitos de sistema. O fim disto é o de auxiliara apresentação da discussão das dificuldades quanto à produção de software com ênfaseem reuso (para o fim de diminuição de custos de processo) empregando técnicas de DBCem sua construção.

CAPÍTULO 3. ANÁLISE DO PROCESSO DE DESENVOLVIMENTO DE SOFTWARE14

Figura 3.1: Representação do que seria o fluxo de desenvolvimento de software

3.1.1 Sintaxe

Sintaxe, em qualquer contexto, pode ser definida como o conjunto de regras e símbo-los que fornecem todo o alicerce necessário para representar e manipular dados, isto é,disponibiliza as ferramentas para estruturar o conhecimento.

No âmbito da Computação, não é diferente. Em todos os níveis de abstração existemestruturas para representar conhecimento. Elas variam de acordo com a natureza do usoque se pretenda da representação.

3.1.2 Semântica

Semântica é o próprio conhecimento que existe e precisa ser expresso através de sím-bolos. Estes símbolos são fornecidos pela sintaxe e podem representar a semântica dediversas formas diferentes.

3.2 Acoplamento Sintático-Semântico

Tal como sugerido na seção anterior, tomemos a demanda de construção de um sis-tema de agenda de compromissos. Tal domínio de conhecimento/problema já nos traz àmemória uma série de informações/conhecimentos que precisam ser, de alguma forma,representados com a finalidade de se construir um software que possa guardar a devida


equivalência de representação estrutural e comportamental entre o que ocorre no mundoreal e o que ocorre no mundo computacional.

3.2.1 Desenvolvimento baseado em orientação a objeto sob o prismado acoplamento sintático semântico

De início, tal domínio de conhecimento já possui uma representação válida (empirica-mente válida) em nossa memória; a representação em linguagem natural. A questão é queeste conhecimento precisa "sair"de nossa memória e, aos poucos, ganhar os contornosde uma representação que possa ser igualmente válida computacionalmente. Para isso,empreguemos o processo de software tal como sugerido pela disciplina de Engenharia deSoftware.

Para a instância de domínio de conhecimento de uma agenda de compromissos, apli-cando técnicas de análise e especificação de requisitos para sistemas de software, podere-mos ter como resultado, por exemplo, a seguinte síntese:

Artefato: Especificação dos Requisitos de Sistema

1. O sistema deverá ser capaz de associar pessoas a compromissos;

1.1. Para cada compromisso pode-se associar uma ou mais pessoas a estes com-promissos;

1.2. Para cada pessoa pode-se associar um ou mais compromissos a esta pessoa;1.3. Cada pessoa deverá ser descrita pelo seu nome e sexo;

2. Cada compromisso precisa informa data, hora e local onde ocorrerá;3. Cada compromisso deve ser capaz de ter a ele associado informações a respeito do

que dever ser feito ou tratado no momento do compromisso, estas informações deveser representadas pelo conceito pauta;

4. O sistema deverá ser capaz de quando for preciso, em algum momento no futuro,fazer distinções de natureza de pessoas, a física e a jurídica.

Como pode ser visto acima, este documento/artefato (Especificação dos Requisitosde Sistema) é produzido em linguagem natural (e portanto usando os aspectos sintáticos-semânticos intrínsecos da língua portuguesa) para informar a qualquer leitor - a um ana-lista de sistemas, ou a um projetista de sistemas, por exemplo - o que constitui o sistemade agenda de compromissos para uma determinada demanda de um cliente qualquer. Estedocumento orientará o trabalho que deve de ser realizado na fase de projeto. Portanto,


o produto da fase de projeto é função do documento de especificação de requisitos que,por sua vez, é o resultado da fase de análise e especificação de requisitos. Note-se adependência.

Seguindo-se adiante, o artefato Especificação dos Requisitos de Sistema ao ser em-pregado pelo pessoal da fase de projetos poderá, por exemplo, determinar a construção detal artefato representado pela Figura 3.2.

Figura 3.2: Artefato: Diagrama de Classes

Tal como observado na Figura 3.2, foi empregada a linguagem UML para representaro conhecimento posto nos requisitos do sistema. A necessidade de uso de uma linguagemcomo a UML surge em função de se buscar, à medida do avanço das fases do processo nadireção do produto final, maior grau de concisão e menor grau de ambiguidade quanto àdefinição estrutural e comportamental do sistema.

O produto da fase de projeto deve ser um documento conciso e livre de ambiguida-des (quanto à interpretação do conhecimento) para que os desenvolvedores possam levaradiante a tarefa de codificar o sistema desejado.

É importante observar o acoplamento sintático-semântico nesta etapa. A UML comolinguagem possui sua própria sintaxe que foi pensada para representar conhecimento deforma concisa e livre de ambiguidades. Dentre os símbolos sintáticos empregados naconstrução do diagrama de classes anteriormente apresentado, podemos listar e definir osignificado:


Especialização: indica o fato de uma classe ser uma especializa-ção de uma outra classe;

Associação: indica que há uma relação entre as duas classes quesão postas conectadas às extremidades da linha;

Classe: este símbolo representa um determinado conceito de domínio,uma classe de objetos aí identificados;

Apropriando-se destes símbolos, o conhecimento que teve início na memória de umapessoa - um especialista de domínio, por exemplo - foi transposto para um documento -o artefato Especificação de Requisitos de Sistema - em linguagem natural que pretende jáalguma clareza e objetividade em informar adequadamente determinado conhecimento.Esta documentação (em linguagem natural) foi transposta, por sua vez, para outra lin-guagem (a UML no caso) que é outra forma de representação do mesmo conhecimentosistematizado na fase de análise e especificação de softwares. O resultado desta trans-posição foi a produção de um diagrama de classes que foi apresentado, por exemplo, naFigura 3.2. Este, por fim, é o documento que o pessoal da fase de desenvolvimento devese apropriar para iniciar suas tarefas.

Importante ser notado que este documento, o diagrama de classes, nada mais é doque resultado da apropriação, por parte do conhecimento, dos símbolos e regras sintáticasda linguagem UML, e isto com o fim de diminuir o nível de abstração, favorecendo oaumento de concisão e eliminação de ambiguidades possíveis quanto à interpretação doconhecimento que é por ele exposto.

Seguindo adiante no processo de construção de tal demanda, a agenda, tem vez a fasede desenvolvimento. Guiado pelo diagrama de classes, os desenvolvedores precisarãodecidir qual melhor linguagem de programação podem usar para garantir uma implemen-tação válida - que atenda às solicitações que foram especificadas inicialmente no docu-mento de requisitos de sistema, ou seja, que equivalha ao conhecimento do que seja umaagenda de compromissos - em linguagem de computador. Isto dito, podemos esperar queum artefato possível, o produto desta fase, seja tal como apresentado a seguir:

Artefato: Classes Java (instâncias de código para o sistema trabalhado)


Conceito de Domínio Pessoa:

Conceito de Domínio Pessoa Física:

Conceito de Domínio Compromisso:

Conceito de Domínio Envolvido:

Conceito de Domínio Pauta:

Acima estão representados os conceitos do domínio de conhecimento agenda de com-promissos. Aqui o que ocorre nada mais é do que a construção de outra forma de represen-tação do mesmo conhecimento que perpassou as fases anteriores e que guiou o desenrolar


do trabalho até este momento. A representação do conhecimento neste momento, emcódigo (linguagem de programação de computador), é realizada de maneira a eliminartoda a ambiguidade e ter o máximo de concisão na representação. Apenas para efeito deilustração, optou-se pela linguagem de programação de computadores Java. Finalmenteé possível dizer que existe uma estrutura computacionalmente válida que representa odomínio de conhecimento trabalhado neste texto.

Algumas observações são necessárias com vistas ao objetivo do trabalho: primeiro,que o domínio do conhecimento precisou manter-se o máximo possível invariável quantoa definição estrutural e comportamental de cada um dos conceitos do domínio (os con-ceitos Pessoa, PessoaFisica, Compromisso, Envolvido e Pauta). Segundo, o processo deconstrução de software possui fases que são dependentes umas das outras. Terceiro, queo domínio de conhecimento é o mesmo do início ao fim do processo, ou seja, o mesmovalor de conhecimento perpassa todas as fases do processo. Quarto, o mesmo conheci-mento sofre alterações apenas quanto à sua forma de representação.

Uma vez que se tem o sistema devidamente codificado, segue-se sua implantação euso, isto é, a fase de operacionalização de software. Ocorre que, neste momento/fase, sehouverem novos trabalhos para as pessoas que estiveram envolvidas ao longo das fasespara a construção da solução de software, será devido a um erro do processo ou a umaalteração de requisito de sistema.

Passemos a investigar as consequências, em termos de esforço necessário depreen-dido, para corrigir um erro de funcionamento do sistema (uma análise de requisito falha,por exemplo), ou para atender às mudanças de requisito do sistema (surgiu uma novademanda do contratante, por exemplo). Primeiro vejamos o efeito de um erro de análise.

Suponhamos que o analista de requisitos não percebeu, por meio das entrevistas querealizou, que o cliente havia solicitado em uma de suas falas que "as pessoas devem con-firmar participação no compromisso marcado". A consequência é que o documento derequisitos precisa ser alterado para que se adicione mais um item de requisito:





2. Cada compromisso precisa informa data, hora e local onde ocorrerá;


3. Cada compromisso deve ser capaz de ter a ele associado informações a respeito doque dever ser feito ou tratado no momento do compromisso, estas informações deveser representadas pelo conceito pauta;

4. O sistema deverá ser capaz de quando for preciso, em algum momento no futuro,fazer distinções de natureza de pessoas, a física e a jurídica.

5. As pessoas envolvidas em compromissos devem notificar suas participações nocompromisso marcado;

Ocorre que esta alteração deve, portanto, provocar novo trabalho para o pessoal que éresponsável pelo projeto do sistema. O modelo do sistema projetado precisa ser modifi-cado para refletir a mudança do requisito (devido a erros da fase de análise). A alteraçãopode ser vista de forma sucinta na Figura 3.3.


Chamamos atenção para o traço vermelho que está sob a mudança (destacando-a dorestante do modelo que permanece o mesmo). Seguindo adiante e lembrando-se da de-pendência das fase (n) do processo em relação à fase (n-1), o pessoal do desenvolvimentopossui agora o diagrama corrigido que os guiará acerca de onde deverão ocorrer as mo-dificações no código que implementa a representação do domínio do conhecimento deagenda de compromissos. Pelo Diagrama de Classes da Figura 3.3 vê-se que a modifi-cação deve ser feita na classe Envolvido, adicionando-se o atributo de classe chamadosituação do tipo String.


Artefato modificado: Classe Java Envolvido

Alteração do Conceito de DomínioEnvolvido:

Após este trabalho de correção da falha, alterando-se a representação de código dosistema pretendido será, sim, possível disponibilizar nova versão do sistema com a falhacorrigida. E agora, finalmente pode-se dizer que o trabalho de construção da solução desoftware para o domínio do conhecimento agenda de compromissos chega ao fim, porestar de acordo com todas as especificações solicitadas do contratante.

Importante neste ponto chamar atenção para o fato de que as alterações de requisitos,neste caso por falha do analista de requisitos, provocou a necessidade de novos esforçosno sentido de alteração nas representações do domínio do conhecimento.

Fase quatro, trabalho devido a mudanças no domínio do conhecimento: Vejamosagora o caso de uma mudança de requisitos devido a uma nova solicitação do cliente:"é preciso adicionar as informações de contato". Não basta mais agendar compromissos,é preciso ter as informações que auxiliem o usuário da agenda a ter o contato dos en-volvidos nos compromissos. Assim fica notada a mudança, ou variação, do domínio deconhecimento.

Bom, como na situação anterior (falha na análise de requisitos), o documento de re-quisitos sofrerá nova alteração, passando a ficar tal como apresentado na Figura 3.4:





2. Cada compromisso precisa informa data, hora e local onde ocorrerá;3. Cada compromisso deve ser capaz de ter a ele associado informações a respeito do

que dever ser feito ou tratado no momento do compromisso, estas informações deve


ser representadas pelo conceito pauta;4. O sistema deverá ser capaz de quando for preciso, em algum momento no futuro,

fazer distinções de natureza de pessoas, a física e a jurídica.5. As pessoas envolvidas em compromissos devem notificar suas participações no

compromisso marcado;6. Cada pessoa possui uma lista de contatos que podem ser e-mail, telefone ou

facebook.

Perceba novamente a necessidade de trabalho para a alteração deste documento apresen-tado acima. Trabalho a ser realizado pela equipe responsável por documentar e armazenaros requisitos de sistemas desenvolvidos pela empresa.

Esta alteração no documento de especificação do sistema de agenda de compromissos,que agora passa a ser uma agenda de compromissos e contatos pessoais, será analisadapela equipe de projetos de sistemas e provocará uma atualização do projeto de sistemaagenda de compromissos (e agora de contatos pessoais, também nesta fase). Esta atuali-zação pode ser visualizada na Figura 3.4.

Este será o diagrama (3.4) que sintetiza os requisitos anteriores e o novo requisito.Como é de se esperar, pelo processo, estas alterações neste documento provocará o pes-soal da equipe de desenvolvedores a alterar o código do sistema (o modo de representaçãodo domínio do conhecimento desta fase) para que tais alterações possam refletir, assimcomo na fase de projeto, as alterações de requisitos solicitadas pelo contratante. A seguir,apresentamos apenas as novas classes que surgem:


Alteração do Conceito de DomínioTipo de Contato:

Conceito de Domínio Contato:

Acima o resultado do trabalho da equipe de desenvolvimento, cujo trabalho é manter a




forma de representação do conhecimento (a forma de código de programa de computador)sempre atualizada com os documentos da fase de projeto. Uma vez que o trabalho éconcluído aí, o sistema está atualizado com a implantação dos novos requisitos em todasas fases do processo e, por isso mesmo, pronto para ser entregue ao usuário.

Contudo, imaginemos que o sistema, ao ser usado pelo cliente, o tal notou que nãoconsegue obter a informação de a qual pessoa um dado contato está associado. E notificouao fornecedor. Este por sua vez, buscou nos documentos que especificam os requisitos epercebeu que eles contêm a informação que indicam ao pessoal de projeto que esta fun-cionalidade deveria ser figurada nos diagramas de projeto. Seguiu então a análise dosdocumentos que especificam o projeto para os desenvolvedores e foi percebido que látambém havia a informação acerca da necessidade da implementação da funcionalidadeque está ausente do produto entregue ao cliente. Contudo, ao analisar o código (artefatoda equipe responsável pelo desenvolvimento) foi visto que houve falha na transposição doconhecimento representado nos diagramas do projeto para a estrutura de código, ou seja,houve falha na representação do conhecimento no nível da linguagem de programação decomputadores. A seguir, vejamos o erro detectado pelos auditores:


Conceito de Domínio Contato antesdo erro detectado:

Conceito de Domínio Contato corri-gido:

Chama-se atenção para a distinção de representação. A primeira representação nãopossui o código necessário que viabilize a informação de associação de uma dada instân-cia de Contato a uma dada instância de Pessoa (representação falha). A segunda repre-sentação fornece a estrutura necessária para que este tipo de informação seja alcançada.


3.2.2 Desenvolvimento baseado em componentes (DBC) sob o prismado acoplamento sintático semântico

Orientado pelo conceito de DBC, o processo de construção do software tende a in-vestigar e indicar uma solução com base em componentes de códigos reutilizáveis, de talforma que seja possível construir um modelo de sistema usando UML Components paraguiar o desenvolvimento.

Para a agenda de compromisso que pretendemos desenvolver, se ela fosse pensadausando DBC, o modelo do software seria como o da Figura 3.5. Os requisitos são exa-tamente os mesmos. A única diferença entre ambos os métodos é o modelo de software(ao qual é aplicado a técnica DBC) e a codificação - em consequência da mudança domodelo.

Todas as etapas descritas em 3.2.1 ocorrem exatamente igual mesmo que usemos oconceito de DBC para a concepção do modelo. O contraste entre ambas ocorre na concep-ção do modelo do software, isto é, etapa ilustrada pela figura 3.5 e nas etapas dependentesdesta.


Conceito de Domínio Pessoa:

Conceito de Domínio Pessoa Física:




Conceito de Domínio Compromisso:

Conceito de Domínio Envolvido:

Conceito de Domínio Pauta:


Conceito de Domínio Tipo Contato:

Conceito de Domínio Contato:

Note-se que as únicas alterações na codificação - em relação ao modelo orientado àobjeto - dizem respeito à organização das classes de domínio em pacotes, ou seja, apenasuma refatoração das classes.

3.2.3 Conclusão

É possível arriscarmos certa conclusão após a avaliação que se seguiu acima: por meioda análise realizada, é possível afirmar que todo artefato do processo de construção é umajunção entre estrutura sintática (de uma determinada linguagem) e estrutura semântica(um determinado domínio de conhecimento); que o produto/artefato de cada uma dasfases precisa ser trabalhado/modificado todas as vezes que houverem modificações deuma destas estruturas: ou sintática, ou semântica. Todo sistema é, portanto, resultado deum acoplamento sintático semântico devido à necessidade de representação, qualquer queseja a fase do processo de construção de software. Qualquer que seja o nível de abstraçãodesejado.

Além disto, pode-se dizer que qualquer metodologia de construção de software, quese realize por meio de uma equivalência necessária entre conceito de domínio e represen-tação de conceito de domínio, haverá de demandar trabalho em todas as fases do processo,todas as vezes que os requisitos de domínio forem modificados, seja por erro de análise,projeto ou desenvolvimento; seja por evolução/alteração no domínio do conhecimento.

E isto, a necessidade do trabalho, ocorre devido ao acoplamento sintático-semântico,


que é necessário à realização da construção das representações específicas de cada fase doprocesso de software. Perceba-se que o aspecto sintático das representações do sistema(a estrutura da linguagem qualquer que fosse; linguagem natural, UML, Java) se man-teve invariável ao longo das modificações de representação do conhecimento que foramnecessárias para a correção de erro de requisitos, de projeto, ou de desenvolvimento. Aestrutura da linguagem se manteve igualmente invariável quando as modificações de re-presentação ocorreram por motivo da evolução/alteração do domínio de conhecimento (ocaso da necessidade de adição de funcionalidades ao sistema). O aspecto variante, por-tanto, ficou por conta da dimensão semântica da estrutura que representa o conhecimento.Esta noção pode ser visualizada observando a Figura 3.6.

Figura 3.6: Sintaxe e semântica ao longo de um processo de desenvolvimento de software

Capítulo 4

Metodologia

Como foi visto no capítulo 3, cada fase do processo de desenvolvimento de um soft-ware possui a representação do conhecimento utilizando a linguagem adequada ao seunível de abstração. Assim sendo, na primeira fase - levantamento de requisitos - a lingua-gem natural é usada como ferramenta de descrição semântica. Na fase seguinte, a UML -cujas regras diminuem a ambiguidade e aumentam a concisão em relação à linguagem na-tural - empresta sua simbologia à semântica, por fim, a linguagem de programação (Java,C#, PHP, ...) - mais uma vez, quanto mais baixo é o nível de abstração, mais concisa emenos ambígua é a linguagem - traduz aquele conhecimento em objeto computacional(ver Figura 3.6).

4.1 Desacoplamento Sintático-Semântico

Agora é fácil perceber que o conhecimento perpassa todas as fases de desenvolvimentoe em todas essas fases são os elementos sintáticos que são moldados para representar asemântica que permanece constante até o último estágio de produção do software. Carac-terizando o que chamamos no capítulo 3 de acoplamento sintático-semântico.

Ora, se este conhecimento é invariável ao longo dos estágios de desenvolvimento dosistema computacional, é natural que pensemos em como aproveitar esta condição paraviabilizar a estabilidade do produto final, no sentido de não precisar alterar os artefatosreusáveis toda vez que precisarmos modificar, corrigir falhas no modelo, ou erros deimplementação.

Ao observar a linha de vida da linguagem natural, UML ou uma linguagem de pro-gramação, nota-se que em relação ao seu tempo de vida ocorrem poucas mudanças signi-ficativas na sua estrutura. Em contrapartida, a semântica varia rapidamente ou lentamentedependendo do conhecimento que ela representa.

Se sintaxe e semântica estão fortemente unidas, e uma dessas duas estruturas está mais

CAPÍTULO 4. METODOLOGIA 31

susceptível a passar por modificações, então as duas tem que ser remodeladas sempre quehouver mudanças em uma delas para que continuem coexistindo e refletindo esse mesmoconhecimento.

O propósito de realizar o desacoplamento sintático-semântico tem como objetivo che-gar a um núcleo onde sintaxe e semântica são fracamente ligadas.

Isso não foi possível na primeira etapa (Análise de requisitos) porque a linguagemnatural é muito ambígua e pouco precisa necessitando de alto grau de ligação com oconhecimento que ela representa.

Na fase de construção de modelo, a linguagem UML é fortemente ligada ao conheci-mento que o modelo representa e possui um elevado grau de abstração que ainda impos-sibilita a independência da semântica.

A fase de codificação, entretanto, é a o estágio ideal para aplicar o desacoplamentosintático-semântico e isso precisamente em consequência do baixo grau de abstração deuma linguagem de programação que já é mais próxima do universo computacional e por-tanto mais concisa e precisa.

Veja a Figura 4.1, ela ilustra a equivalência entre a representação de duas classes dedomínio diferentes: Pessoa e Aluno. Elas possuem a mesma estrutura, porém diferentesatribuições semânticas. Com este exemplo, nota-se claramente a possibilidade de encon-trar estruturas genéricas independentes de semântica.

Figura 4.1: Estrutura de classes de Domínio

Na subseção 4.2, sugere-se uma arquitetura apta a alcançar o desacoplamento sintático-semântico na etapa de codificação. Com isso, a maior parte do esforço do desenvolvi-mento de um software estaria concentrado no levantamento de requisitos e sobretudo naconstrução do modelo. Este modelo pode ser construído por qualquer profissional comconhecimento das regras de negócio e da linguagem UML.


4.2 Arquitetura Amorfa

Poderíamos imaginar um interpretador semântico de modelos de software. Este com-ponente manteria a estrutura sintática intacta, visto que ao longo do tempo as variaçõesnas estruturas das linguagens ocorrem muito mais lentamente que as alterações nos requi-sitos de um sistema (ver Figura 3.6), e teria como função interpretar um dado modelo emtempo de execução, isto é, o sistema só saberá como se comportar quando um modelo éatribuído a ele, pois é a partir da aglutinação entre sintaxe e semântica que ele passa a tersentido de existir.

Tomando como paradigma um modelo de desenvolvimento de software, qual seja,MVC (Model-view-controller), temos que, classes diferentes podem ser agrupadas quantoà sua finalidade estrutural, que pode ser classes de domínio, classes de controle e classesresponsáveis pela camada de apresentação/visão.

A partir disso, poderíamos sugerir um elemento para interpretar - ou seja, apropriar-seda descrição semântica do modelo - as classes de cada dimensão da arquitetura.

Na camada de apresentação, o interpretador, dada uma entidade do modelo, se apro-priará da descrição semântica atributo por atributo a fim de obter a informação necessáriapara desenhar na tela os componentes que representam aquele modelo. Entretando, énecessário informar a este interpretador - chamemos de Application Client (AC) - comoserão as características dos componentes que representarão os atributos das entidades domodelo na interface. Essas características dizem respeito ao tipo de item que será usado- checkbox, combobox, radiobutton, label, text area, text field, ... - e suas propriedades -tamanho e nome do rótulo, por exemplo. Porque a partir do modelo de software, não épossível inferir quais itens serão usados para representar os atributos na interface com ousuário.

Revendo a Figura 4.1, compreende-se como seria o AC. Um interpretador que mantémuma estrutura de classes de domínio e que atribui a essas estruturas o conhecimento queextrai do modelo semântico que recebe.

Não obstante, um sistema de informação não é um recurso estável. Há manipulaçãode informações do usuário pro banco de dados e no caminho inverso também. No núcleodo software, todas as operações se resumem a CRUD (Create, Read, Update e Delete).

Por conseguinte, um dado por si só não diz nada ao sistema. É necessário que venhaacompanhado da informação do que fazer com ele: persistir, atualizar, apagar do bancoou buscar no banco de dados.

Logo, deve existir uma outra unidade nessa arquitetura, seria um interpretador de clas-ses da dimensão de controle e modelo. Chamemos essa unidade de Application Server


(AS). Sua atribuição seria, atender as requisições e decidir o que fazer com os dadosvindos do AC. Em outras palavras, o AS deve saber como persistir ou recuperar dadosreconhecendo sua natureza. Portanto, o AS não precisa ter conhecimento de como repre-sentar o modelo na tela para o usuário, isto é de competência do AC.

Até este ponto, esta arquitetura é capaz de construir classes de domínio através dediagramas de entidades e seus relacionamentos (modelos de software) e compreender oque fazer com as requisições do usuário.

Figura 4.2: Representação do esquema da arquitetura amorfaFonte: [COSTA 2012]

Por último, sugerimos um elemento, chamemos Provider Semantic (PS) - capaz de ar-mazenar modelos de sistema - para eventuais necessidades de recuperação de informação- segundo uma forma específica de representação.

Por fim, estes componentes que foram descritos são a base para uma arquitetura (verFigura 4.3) amorfa que sugere um método para conseguir desacoplamento sintático se-mântico da fase de codificação no processo de desenvolvimento de software.

Nota-se que se o AC e AS não possuem nenhuma referência à finalidade do sistema- visto que isto está definido no modelo de software e que o conhecimento representadoem todas as etapas do desenvolvimento é invariável - então, temos autonomia para codi-ficar estes elementos da forma que acharmos mais conveniente e utilizando a linguagemde programação que desejarmos desde que a comunicação entre AC, AS e PS sigam umprotocolo que define como os dados devem ser tratados e a ordem que as mensagens de


Figura 4.3: Representação do modelo da arquitetura amorfa

requisição e resposta devem ser entregues entre eles. Esse protocolo seria o equivalente ainterface de um componente, isto é, especificaria e descreveria como os módulos funcio-nariam quando conectados para formar a arquitetura.

E a existência desse protocolo para determinar como os componentes da arquiteturase comunicam é importante para garantir que os componentes conectados irão funcio-nar como um sistema de informação atuando como cliente-servidor com mensagens derequisição e respostas.

4.3 Exemplo: Agenda de Compromissos e Contatos

Vamos retomar o exemplo da Agenda de Compromissos e Contatos que vimos no ca-pítulo 3. Se a arquitetura amorfa fosse adotada para o desenvolvimento dessa aplicação, oartefato de domínio de requisitos e o artefato de modelo do sistema seriam concebidosnormalmente.

Entretanto, não haveria necessidade de programar mais nada. Apenas incluir o modelodo software no banco de dados que armazena esses modelos e logar no sistema. Tal comoestá ilustrado na Figura 4.2.

Em tempo de execução, o modelo seria carregado e interpretado pelo AC e AS gerandoa aplicação resultado do processo de junção de sintaxe e semântica.


É preciso enfatizar que fazer o levantamento de requisitos e construir o modelo de umsoftware não é tarefa exclusiva de profissionais da área de informática, essas tarefas po-dem ser competência de alguém com conhecimento das regras de negócio do contratantee que compreenda da estrutura destes dois artefatos de software.

Capítulo 5

Conclusões

Neste capítulo apresentamos as conclusões deste trabalho resultado da investigaçãodo processo de desenvolvimento de software.

5.1 Contribuições do Trabalho

Avaliando o processo de desenvolvimento de sistemas, sugerido em disciplinas de En-genharia de Software, pode-se verificar que as metodologias vigentes, as quais empregamo conceito de reusabilidade, muitas vezes não atingem um grau satisfatório para este fim.

Isto acontece devido ao acoplamento sintático-semântico das etapas de processo desoftware. Como o conhecimento do domínio do problema (semântica do software) per-passa todas as fases do desenvolvimento, ele se mantém constante até a concepção doproduto final. Em contrapartida, a estrutura sintática varia de acordo grau de abstração daetapa.

Por outro lado, qualquer necessidade de alteração em requisitos ou detecção de falhas(semântica) no sistema em operação em alguma fase (n), implica refazer as fases n a n+ide forma a adequar a estrutura sintática ao conhecimento a ser representado.

Em virtude disso, o tempo até o produto chegar ao mercado será maior, há a perspec-tiva de o sistema se tornar instável e os custos da manutenção serem elevados.

Para contornar as consequências do acoplamento sintático-semântico, sugere-se a con-cepção de uma arquitetura amorfa visualizando o desacoplamento sintático-semântico.Para tanto, a arquitetura depende apenas do modelo de software.

A arquitetura prevê que os elementos possuam flexibilidade de implementação (esco-lha da linguagem de programação é livre), exigindo-se apenas que as mensagens trocadasentre os módulos sigam um protocolo definindo o formato da mensagem e a ordem emque devem ser trocadas.

CAPÍTULO 5. CONCLUSÕES 37

5.2 Trabalhos Futuros

Esta seção apresenta algumas ideias que motivam trabalhos futuros. Incluindo ideiaspara aplicação do que foi discutido neste.

• Refinar a descrição da arquitetura que consegue o desacoplamento sintático-semânticona etapa de codificação sugerindo e implementando uma estrutura apta a receberum modelo com entidades e relacionamentos de um sistema e conseguir gerar umproduto estável.

• Implementar os módulos AC, AS e PS descritos nesse trabalho, tornando esta ar-quitetura funcional.

• Investigar as etapas de análise de requisitos e construção de modelo a fim de iden-tificar características reaproveitáveis entre softwares de domínios de problemas di-ferentes para que sejam aplicadas ao uso dessa arquitetura amorfa. Exemplo: Rea-proveitar regras de negócios e requisitos não funcionais.

Referências Bibliográficas

AURUM, A., WOHLIN C. (2005), Engineering and Managing Software Requirements,Springer-Verlag.

COSTA, A. R. DA (2012), ‘Sistema de monitoramento e rastreamento por GPS & GSM’,UFRN .

DA SILVA, FRANCISCO A. P., P. A. DA M. S. NETO, V. C. GARCIA & P. F. MUNIZ(2011), ‘Linhas de produtos de software: Uma tendência da indústria’, UFPI .

GUIZZARDI, G. (2000), ‘Desenvolvimento para e com reuso: Um estudo de caso nodomínio de vídeo sob demanda’, UFES .

KOTONYA, G., SOMMERVILLE I. (1998), Requirements engineering: processes and

techniques, Chichester, England: John Wiley.

NEVES, E. A. (2012), ‘Especificação e projeto eletrônico de um módulo de rastreamentousando GPS & GSM’, UFRN .

PFLEEGER, S.L. (2004), Engenharia de Software: Teoria e Prática, 2a edição, SãoPaulo: Prentice Hall.

PRESSMAN, R.S. (2006), Engenharia de Software, McGraw-Hill.

ROSADO, SOILA MARA PEREIRA (2003), ‘Desenvolvimento de sistemas utilizandoorientação a objetos’, UFPB .

SOMMERVILLE, I. (2007), Engenharia de Software, 8a edição, Pearson: Addison Wes-ley.

38

Technology

Investigação a respeito de fatores limitantes para reuso de artefatos de processo de software