![Fechar [x]](http://dw1.s81c.com/i/c.gif){kind=small}
Novos projetos de desenvolvimento frequentemente começam com o código de origem existente. Entender o código é essencial para a reutilização, que não é tão simples quanto parece. Por exemplo, talvez o desenvolvedor original tenha se mudado ou aposentado. O código pode ter sido escrito por diversos desenvolvedores ou vir de diversas origens. O código pode existir como um código pertencente à sua empresa, um código externo (por exemplo, de software livre ou de prateleira) ou como bibliotecas. Provavelmente ele foi alterado e evoluiu com o passar dos anos. Qualquer que seja a história do código, você precisa saber como o código de origem interage e o que ele contém. Você precisa entender como o código se ajusta, qual é a melhor maneira de usá-lo no futuro e quais partes convém modificar.
Motivos para a análise do código
Os principais motivos para analisar o código podem ser resumidos como: documentação, reutilização, modificação ou manutenção. Dependendo da situação, os motivadores são:
- Documentar seu código de modo que você o entenda melhor e esteja preparado da próxima vez que um desenvolvedor se aposentar ou mudar ("documentação" sugere que há diagramas que explicam o código)
- Desenvolver uma linha de produtos com funcionalidades em um produto que talvez você não precise em outro produto
- Revisar ou atualizar o aplicativo para uma versão mais recente
- Manter seu código existente
Todos esses motivos fazem sentido para entender melhor seu código. Este artigo se concentra nos motivos para a reutilização e na análise do código necessária para chegar até a reutilização.
Há possíveis riscos com a reutilização, alguns motivos específicos para a possibilidade de falha da reutilização. Um dos desafios em justificar o investimento é que alguns gerentes não permitirão que uma equipe gaste tempo entendendo um código antigo. Outro possível risco de falha é a falta de compreensão dos domínios e componentes do código. A paralisação da análise é outro risco possível.
Esforçar-se para entender todo o código pode ser uma tarefa monumental – é importante dividi-lo e identificar o código-chave para reutilização. Reserve um tempo com antecedência para avaliar quais componentes do código devem ser reutilizados. Em alguns casos, pode ser necessário documentar tudo em seu código – por exemplo, por motivos regulamentares, mas tentar reutilizar e documentar todo o seu código normalmente não é eficiente. Geralmente, o objetivo é ser inteligente com relação a quais partes do código devem ser documentadas e quais partes devem ser reutilizadas.
Os quatro fatores essenciais para o sucesso
Para alcançar o sucesso, é necessário:
- Entender a arquitetura do código original a fim de identificar os componentes, os limites e as interfaces
- Determinar o que pode ser reutilizado
- Estimar o tempo de reutilização versus o redesenvolvimento dos componentes
- Decidir-se, de acordo com o componente, sobre o que e como reutilizar - sem mudança, pequena atualização, atualização importante
Esclareça o código do software com a Linguagem de Modelagem Unificada
Sempre que você quiser ter uma compreensão clara de seu código, a Linguagem de Modelagem Unificada (UML) é uma ótima maneira de conseguir isso. UML é uma linguagem gráfica padrão para representação de código. Ela permite que você ilustre o que o código está fazendo, o que, por sua vez, permite que você veja a totalidade do design do componente. Ela permite que você entenda a arquitetura do código original a fim de identificar os componentes, limites e interfaces. A UML esclarece como o código se ajusta. Use a UML para analisar seu código. A análise é a primeira etapa antes de documentar seu código.
Combinando o desenvolvimento centrado no código com a modelagem de UML
Um dos quatro fatores essenciais para o sucesso exibidos anteriormente aqui é tomar uma decisão de acordo com o componente com relação a o que reutilizar e como fazer isso. Se você quiser manter seu código existente e documentá-lo, continue a realizar o desenvolvimento centrado no código como sempre fez, mas combine isso com a modelagem. Provavelmente não seria necessário gerar seu código no modelo, mas você deseja comunicar melhor e aprender como o código existente se ajusta. Isso pode ser feito com o desenvolvimento centrado no código combinado com a modelagem.
Se você quiser entender o código de software existente para possivelmente reutilizá-lo a fim de criar novos produtos ou manter os diversos produtos existentes, o desenvolvimento conduzido por modelo pode ser a melhor solução. Ao realizar o desenvolvimento centrado no código combinado com o desenvolvimento conduzido por modelo, você identifica qual parte de seu código você deseja manter e reutilizar.
- Centrado no modelo
- O modelo não apenas conduz a arquitetura, mas também o código final de seu
aplicativo.
- Centrado no código
- O código é importado no modelo como uma referência para visualização. Isso significa que o modelo
é usado para ajudar a mostrar a arquitetura, mas isso nunca muda o código. Para atualizar o
design, você precisa atualizar o código e trazê-lo de volta para o
modelo.
- Dynamic Model Code Associativity (DMCA)
- No software de modelagem IBM® Rational® Rhapsody® , isso se refere à
direção das atualizações. É possível ir do modelo para o código, ou do código para o modelo, ou é possível ter
atualizações bidirecionais automáticas. Round-tripping é o processo de levar atualizações
do código para o modelo.
Tipos diferentes de usuário preferem determinados cenários de desenvolvimento com relação a outros. Os usuários que gostam de trabalhar em modelos são chamados de "usuários centrados no modelo", enquanto os usuários centrados no código preferem fazer tudo no código. E há as pessoas que estão no meio. Você pode acomodar os diversos tipos de usuários com o tipo de reutilização de código e modelagem que escolher. Os tipos diferentes de usuário podem colaborar e trabalharem juntos de forma coesa, com uma combinação de codificação tradicional e desenvolvimento conduzido pelo modelo.
As definições de tecnologia podem ser mapeadas em três cenários diferentes descritos na seção a seguir.
Observação:
elas podem ser usadas de acordo com o componente, ou seja,
um componente em um aplicativo pode ser centrado no modelo, enquanto outro é centrado no código.
Cenários para combinação do desenvolvimento centrado no código e conduzido por modelo
Há diversas maneiras de combinar a reutilização de código tradicional com a modelagem. O espectro de opções pode ser descrito, em alto nível, como um destes quatro cenários:
- Visualizando o código externo (somente visualização) é um processo centrado no código. O código externo permanece externo à sua ferramenta de modelagem visual. Você faz referência ao código externo na ferramenta de modelagem a fim de usá-lo e testá-lo.
- Codificação contínua com documentação atualizada é um processo centrado no código com suporte para o envio de atualizações para o modelo. É possível visualizar o código em um modelo, mas nunca mudar o modelo.
- Desenvolvimento centrado no código com algumas mudanças feitas no modelo que são geradas no código. O código é o mestre.
- Modernizando o código usando o desenvolvimento conduzido por modelo, no qual o modelo é o mestre. Uma parte do código externo é identificada para reutilização e levada diretamente para o modelo.
Visualização implica que você possui diagramas que o ajudam a entender o design, a estrutura do código e os relacionamentos entre objetos (como classes, arquivos). Como usuário, você também tem a capacidade de criar novos diagramas com base nos elementos do modelo, adicionar comentários aos diagramas e conectar elementos de modelo aos requisitos. Uma descrição dos elementos que chegou do código é mantida no modelo e pode ser usada para gerar um relatório realizando um relatório sobre o modelo. Há mudanças que podem ser feitas com mais facilidade em um modelo, como a adição de elementos que podem ser desenhados em um diagrama, a cópia de elementos em um diagrama, herança e muito mais.
Com a visualização do código, as atualizações no código são realizadas no código fora da ferramenta de modelagem. A visualização do código externo é realizada para mostrar os relacionamentos do código com um modelo. Por exemplo, convém fazer referência a uma biblioteca C externa e mostrar essa referência em um diagrama. O relacionamento que a biblioteca tem com outras partes do modelo é visualizado e documentado dessa forma. O teste conduzido por modelo da biblioteca pode ser feito dentro do modelo. Com o desenvolvimento conduzido por modelo, você não apenas visualiza seu código, mas também executa seu modelo para verificar e testá-lo.
Codificação contínua com documentação atualizada
No segundo cenário, à medida que as mudanças são feitas no código externo, o round-tripping pode ser executado a fim de enviar as mudanças do código para o modelo. Isso mostra o código alterado a partir do código externo, atualizando dessa forma a documentação. Se você escolher a opção de visualizar e atualizar o código, poderá continuar a desenvolver o código no modelo, ou no código externo, e manter ambos em sincronia.
Desenvolvimento centrado no código
Conforme foi mencionado anteriormente no cenário 3, é possível modernizar o código usando o desenvolvimento conduzido por modelo, gerando o código no Rational Rhapsody e atualizando o código externo com as mudanças. A geração do código pode ser realizada na ferramenta de modelagem, preservando as diretrizes de código existentes no arquivo de origem original. A opção de executar a geração do código no modelo é útil para aplicar mudanças do modelo de volta no código. A animação do modelo pode ser usada para mostrar o comportamento do código. Nesse cenário, o código é o mestre.
Modernizando o código usando o desenvolvimento conduzido por modelo
Você pode escolher manter o código do modelo. Essa é a base para o cenário 4. O critério principal a ser usado para determinar se você deseja visualizar o código, como é realizado nos cenários 1 a 3, ou mantê-lo diretamente no modelo a fim de executar o desenvolvimento conduzido por modelo, é se você deseja ou não gerar o código seguindo estritamente o modelo. Se você mantiver o código do modelo, será mais eficiente fazer outras mudanças no design e aprimoramentos. O modelo é o mestre.
Agora, o Rational Rhapsody mostra um exemplo simples de como a UML permite a reutilização do código existente. Esse exemplo é de um usuário desenvolvendo uma nova caixa registradora com base no hardware existente. O primeiro diagrama é chamado de digrama de pacotes. Ele fornece uma visualização de alto nível dos pacotes do sistema. Os pacotes são CashRegister, o pacote Hardware, e um link entre eles por meio do pacote Interfaces. O pacote Interfaces permite a reutilização fácil do Hardware, além da capacidade de trocar entre os hardwares existentes para obter um hardware mais recente, conforme o necessário.
Figura 1. Diagrama de pacote
O diagrama de classes abaixo mostra o Cash Register herdando da interface IBarcodeReader. Isso permite que a classe CashRegister implemente a interface e receba comunicação da classe BarcodeReader, proveniente do pacote de hardware externo. A classe BarcodeReader não precisa ser exibida no diagrama, embora a interface Barcode Reader seja exibida (Figura 2), pois o CashRegister precisa implementar somente a interface para obter o comportamento desejado.
Figura 2. Diagrama de classe
O diagrama de classe na Figure 3 mostra a classe Tester realizando uma inclusão de um arquivo de origem em C de uma origem externa. A origem externa é visualizada para mostrar as operações e variáveis do arquivo point_of_sale de modo que a classe Tester possa determinar o que pode chamar.
Figura 3. Classe Tester incluindo um arquivo de origem em C a partir de uma origem externa
Na Figura 4, um diagrama de sequência animado mostra uma classe CashRegister examinando os códigos de barra nos produtos e adicionando os produtos à fatura do cliente.
Figura 4. Diagrama de sequência animado
A animação permite que você execute um aplicativo em um host ou em um destino e visualize os resultados no design com o Rational Rhapsody. Essa é uma ferramenta importante para visualização do comportamento do código e para depuração do código, o que é importante ao reutilizar o código. A visualização do código estático mostra somente os possíveis caminhos existentes por ele. Um diagrama de sequência como o da Figura 4 mostra o caminho pelo aplicativo da forma como ele realmente responde a um estímulo externo. Consequentemente, você vê qual caminho é executado no ciclo de vida real de um aplicativo. Portanto, a animação de um modelo é uma forma de testar e verificar o comportamento de seu código reutilizável.
Reutilização e engenharia de linha de produto ou PLE
O santo graal da reutilização é algo chamado engenharia de linha de produto (PLE). É a prática de identificar recursos em seu aplicativo que variam de acordo com o produto e mapear esses recursos a fim de especificar as variações de cada produto, de modo que, ao final, você tenha um conjunto de código que suporta diversos produtos. Esse é o santo graal porque o objetivo principal da reutilização é reutilizar no próximo produto a ser lançado. Esse também é o objeto da PLE.
As outras opções para desenvolvimento de diversos produtos são clonagem e propriedade ou o uso de ifdefs.
- A clonagem e propriedade desencadeiam muitos problemas. Por exemplo, ao encontrar um erro em um produto, o erro existe em outros produtos também? O que acontece quando você deseja propagar um recurso por meio dos produtos? Analisar as mudanças nos clones se torna um pesadelo.
- Ifdefs tornam o código ilegível e muito difícil de navegar ao tentar trabalhar em um produto específico.
A modelagem ajuda a resolver esse dilema adicionando um nível de abstração acima do código. É possível identificar um elemento de modelo específico (uma classe, função ou qualquer outra coisa) como mapeamento para um recurso e, em seguida, adicionar tags para as diferenças específicas ao produto. Como são gráficas, as tags podem ser links que podem ser investigados conforme o necessário. Além disso, quando você gera o código a partir do modelo, ele usa somente as tags para o produto específico, de modo que você obtenha um código customizado para cada produto. Em seguida, você faz as alterações no modelo e cada produto que possui esse recurso recebe essas mudanças. Não há necessidade de propagar as mudanças em cada produto.
Resumindo, como os prazos são curtos, a reutilização é essencial para atendê-los. O segredo é como integrar a reutilização efetiva a o que você faz. Primeiro, certifique-se de que entendeu sua arquitetura e se aprofunde nos componentes que deseja reutilizar. A modelagem é importante nesse processo, pois o ajuda a analisar o código e a tomar decisões sobre o que é reutilizado. Quando você entende a arquitetura geral, o desenvolvimento de seus produtos em um fluxo de trabalho completo de engenharia de linha de produto (PLE) se torna muito mais fácil de executar e manter.
Aprender
- Para aprender mais sobre essa ferramenta para desenvolvimento colaborativo
e conduzido por modelo para sistemas embarcados, comece com a Introdução ao Rational Rhapsody e a página do Rational Rhapsody no IBM developerWorks.
Para obter a documentação, consulte o Centro de informações do Rational Rhapsody 7.6 (consulte Changing the location of help content para obter uma cópia local da
documentação).
- Confira o IBM®
Rational® Rhapsody® Design Manager para colaborar, compartilhar, revisar e gerenciar designs e modelos com toda a equipe de engenharia.
- Visite a área do software Rational no developerWorks para visualizar os recursos técnicos e as melhores práticas dos produtos da Rational Software Delivery Platform.
- Fique por dentro dos eventos técnicos e webcasts do developerWorks com foco em uma variedade de produtos da IBM e tópicos do segmento de mercado de TI.
- Participe de um briefing ao vivo e gratuito do developerWorks para se atualizar rapidamente sobre produtos e ferramentas IBM, bem como tendências do segmento de mercado de TI.
- Acompanhe as Demos on demand do developerWorks, variando de demos de instalação e configuração de produtos para iniciantes a funcionalidades avançadas para desenvolvedores experientes.
- Melhore suas qualificações. Consulte o Treinamento e certificação do Rational que inclui muitos tipos de cursos em uma ampla variedade de tópicos.
É possível realizar alguns deles em qualquer local, a qualquer momento, e muitos dos cursos para iniciantes são gratuitos.
Obter produtos e tecnologias
- Faça o download do
Rational Rhapsody Developer e teste-o gratuitamente por 30 dias.
- Avalie o software IBM da forma que melhor lhe convier: faça o download para uma versão de testes, experimente-o on-line, use-o em um ambiente de nuvem ou passe algumas horas no SOA Sandbox
aprendendo a implementar Arquitetura Orientada a Serviços de forma eficiente.
Discutir
- Participe da discussão no fórum do Rational Rhapsody.
- Classifique ou revise o software Rational. É rápido e fácil. Realmente.
- Compartilhe seu conhecimento e ajude outros a usar o software Rational, escrevendo um artigo para o developerWorks. Descubra quais são as características de um bom artigo do developerWorks e como realizá-lo.
- Siga o software Rational no Facebook, Twitter (@ibmrational) e no YouTubee adicione seus
comentários e solicitações.
- Faça e responda perguntas, e aumente seu conhecimento participando dos Fóruns do Rational, cafés e wikis.
- Obtenha liderança em pensamento social. Faça parte da comunidade Rational para compartilhar seu conhecimento em software Rational e ficar conectado a seus colegas.
Joanne Scouler é arquiteta de currículo na IBM, onde realiza planejamento de negócio e desenvolvimento de curso para software de engenharia de sistemas. Ela desenvolveu e ministrou cursos de treinamento para a ferramenta Rational Rhapsody nos últimos seis anos. Seu histórico com treinamento de sistemas embarcados e modelagem de software envolveu o trabalho com diversos clientes, incluindo Raytheon, Draper Lab, Pratt & Whitney, Zoll Medical e Kollmorgren. Antes da IBM, Joanne trabalhou na Telelogic, Hewlett-Packard, 3Com Corporation, Symantec e Addison-Wesley.
Martin Bakal tem 15 anos de experiência no campo de software embarcado, incluindo o trabalho como engenheiro de aplicativo do IBM Rational Rhapsody, consultor e instrutor, além de várias outras funções. Ele é um instrutor de UML e SysML experiente, além de um instrutor de processo do IBM Rational Harmony e de ambiente model-driven development (MDD) do IBM Rational Rhapsody. Em seu treinamento e consultoria de sistemas embarcados e modelagem de software, ele trabalhou com uma ampla lista de clientes, no mundo todo, incluindo Lockheed Martin, General Dynamics, GM e Philips. Ele escreveu diversos artigos técnicos sobre modelagem, reutilização e linhas de produto, além de outros tópicos variados.
Índice
Conheça a IBM da sua cidade
Tags
Use a barra de rolagem para ver mais ou menos tags.
Tags populares mostra as principais tags para esta zona de conteúdo em particular (por exemplo, Java technology, Linux, WebSphere).
Minhas tags mostra suas tags para esta zona de conteúdo em particular (por exemplo, Java technology, Linux, WebSphere).
Tags de artigo populares |
Minhas tags de artigoIr para lista de tags
Tags de artigo populares |
Minhas tags de artigo