Gerenciamento de Componentes

Caros,

Em um ambiente onde a infra-estrutura e a arquitetura de software promovam o uso de componentes distribuídos (ou mesmo locais) e exista uma área que centraliza este conhecimento, a exemplo das áreas de arquitetura e/ou governança de TI, é extremamente necessário haver um gerenciamento efetivo e eficaz destes componentes e do conhecimento gerado.

Como exemplo prático cito uma companhia que tem diversos sistemas e usa uma arquitetura componentizada, onde vários componentes são reutilizados por esses diversos sistemas, para promover o reuso e evitar redundâncias.

Alguém trabalha em um cenário deste tipo? Como gerenciam estes componentes e o conhecimento?

Entendam por componente, por exemplo, os pacotes JAR, WAR, EAR gerados e que devem ser disponibilizados no container ou mesmo para as equipes de desenvolvimento ou consultorias de outsourcing.

Agradeço antecipadamente o compartilhamento do conhecimento e das experiências.

Onde eu trabalhava antes, simplesmente compartilhávamos na rede. Havia um local na rede que centralizava os componentes.

Abs!

Ola
Daniel

O ambiente aqui é bem parecido com cenario que vc descreveu.
O conhecimento de como utilizar essas bibliotecas postamos no Wiki e controle de versão utilizamos o SVN

This message was edited 1 time. Last update was at 14/05/2008 12:14:50

Eu trabalho numa empresa que tem (ou deveria ter) esse controle de componentes/conhecimento. Vou tentar explicar como as coisas aqui funcionam:
Existe uma área chamada "administração de dados e componentes" que é responsável por:

A) Definir os nomes e a localização dos componentes (componentes aqui são EJBs, ORMs, tabelas, etc) e
B) Cuidar do reuso destes componentes.

Eles cadastram todos estes dados numa aplicaçãozinha web. Se eu pesquiso, por exemplo, por um nome de ORM, consigo ver em que projeto ela está, quais EJBs a utilizam, etc. Assim eu consigo reutilizar o que já foi implementado. Isso não funciona muito bem aqui por 2 motivos, basicamente:

1) Pra definir os nomes dos componentes, alguém daquela área pega um documento de visão (que não é bem um DV) e um monte de casos de uso, supostamente lê tudo, "caga" os nomes dos componentes e diz "isso aqui vocês vão criar neste projeto, aquilo já tem no projeto tal, etc". Não se pode criar nada diferente daquele bolo marrom que eles determinam. Aí você soma a isso uma arquitetura de caixinha (todos os projetos usam a mesma arquitetura, as necessidades de negócio e oportunidades de simplificação não importam) e se vê no meio de um Bean com mais de 12KLOC, métodos com mais de 200 linhas, etc. Sem testes, ninguém que percebe o tamanho da encrenca (e são poucos aqui que percebem isso) tem coragem de refatorar. Isso se eles liberassem a criação de novos componentes.
2) O cadastro dos componentes na ferramenta de consulta é feita manualmente. Se alguém esquece de cadastrar o componente lá, ou se alguém não consulta antes de fazer, o reuso vai pro ralo.

Desculpe a choradeira, mas como você não disse que queria uma experiência boa, eu falei da minha. Cada vez mais acredito que o melhor jeito de fazer isso é tendo boas pessoas nos times, escrevendo um monte de testes e disseminando o conhecimento da todas as formas possíveis (pair programming, apresentações das releases para todos da empresa, fórum eletrônico interno, pessoas participativas, etc).

GUJ Ranger Membro desde: 02/06/2005 16:28:38 Mensagens: 939 Offline

danieldestro wrote:Caros,

Alguém trabalha em um cenário deste tipo? Como gerenciam estes componentes e o conhecimento?

Maven. Não só componentes internos, mas tb externos.

Ahh, e ainda tem plugin para Eclipse.

Maven gerencia componentes?

Digo, ele é capaz de guardar informações relativas aos componentes, permite pesquisas, mostrar dependências e versionamento?

Adolfo Rodrigues wrote:Eu trabalho numa empresa que tem (ou deveria ter) esse controle de componentes/conhecimento. Vou tentar explicar como as coisas aqui funcionam:...

Gostei muito da sua experiência. Não foge muito do que eu havia pensado.
O software para gerenciar isso é feito por vocês ou vocês compraram/licença free?

Como o projeto aqui é imenso e quem faz os sistemas são consultorias em outsourcing, e como todo o sistema está em desenvolvimento paralelo (não existia nada pré-existente em java), então fica bem mais difícil essa gestão, mas precisamos controlar para não ficarmos perdidos ou vendidos.

No momento estou levantando os sistemas e suas dependência, para que eu posso criar diagramas de componentes, para ter uma visão geral do que temos e para onde estamos indo. Depois cadastrar e manter esses componentes, para então ser capaz de gerenciá-los da melhor forma possível.

danieldestro wrote:
Gostei muito da sua experiência. Não foge muito do que eu havia pensado.

Gostou? Hehehe... Eu que não estou gostando nem um pouco

danieldestro wrote:
O software para gerenciar isso é feito por vocês ou vocês compraram/licença free?

Foi feito internamente. É bem simples mesmo. É só um sisteminha de cadastros e consultas.

This message was edited 1 time. Last update was at 14/05/2008 12:47:25

Taz wrote:
Maven. Não só componentes internos, mas tb externos.
Ahh, e ainda tem plugin para Eclipse.

Não sei se o Maven faz esse tipo de controle. O Maurício Linhares indicou uns links de download para um livro "Better Builds with Maven" aqui no GUJ. Se ajudar, dá uma pesquisada.

[editado] corrigindo o Português [/editado]

Adolfo Rodrigues wrote:

danieldestro wrote:
Gostei muito da sua experiência. Não foge muito do que eu havia pensado.

Gostou? Hehehe... Eu que não estou gostando nem um pouco

Gostei que tenha compartilhado a sua experiência... hehehe!

Daniel, acho que wiki+SVN+Maven podem ajudar bastante.

Deixa a parte "burocrática" num wiki, crie meios de organizar o versionamentos desses componentes via VCS mesmo, tags ou coisa do tipo, congelando os fontes das releases e o Maven para que cada sistema que utilize esses componentes possa gerenciar as versões que utiliza de cada um.

É uma maneira simplória mas se bem definida e organizada pode ajudar bastante.

GUJ Ranger Membro desde: 02/06/2005 16:28:38 Mensagens: 939 Offline

danieldestro wrote:Maven gerencia componentes?

Digo, ele é capaz de guardar informações relativas aos componentes, permite pesquisas, mostrar dependências e versionamento?

Que tipo de informações sobre os componentes vc quer guardar?

This message was edited 1 time. Last update was at 14/05/2008 13:17:46

Taz wrote:Que tipo de informações sobre os componentes vc quer guardar?

Nome componente: Persistência Base XYZ
Descrição: Faz a persistência dos dados da base de dados XYZ, envolvendo as operações básicas (CRUD), além das buscas específicas para cada entidade. Entidades envolvidadas - Pessoa, Departamento, Empresa, Endereco.
Projeto: XYZ
Responsável: Zé da Silva - TI - ze.silva@acme.com
Tags: persistência modelo java dao ejb XYZ

-----------------------------

Nome componente: Gestão Recursos Humanos
Descrição: Faz a gestão dos recursos humanos, blá blá blá.
Projeto: RH
Responsável: Tião Macalé - RH - tiao.macale@acme.com
Dependências: Persistência Base XYZ
Tags: rh java

GUJ Ranger Membro desde: 02/06/2005 16:28:38 Mensagens: 939 Offline

danieldestro wrote:

Taz wrote:Que tipo de informações sobre os componentes vc quer guardar?

Nome componente: Persistência Base XYZ
Descrição: Faz a persistência dos dados da base de dados XYZ, envolvendo as operações básicas (CRUD), além das buscas específicas para cada entidade. Entidades envolvidadas - Pessoa, Departamento, Empresa, Endereco.
Projeto: XYZ
Responsável: Zé da Silva - TI - ze.silva@acme.com
Tags: persistência modelo java dao ejb XYZ

Acho que o Maven resolve. No começo dói pra vc entedê-lo, mas depois de muita fé e persistência é 10 a 0 no ant.

danieldestro wrote:
Nome componente: Gestão Recursos Humanos
Descrição: Faz a gestão dos recursos humanos, blá blá blá.
Projeto: RH
Responsável: Tião Macalé - RH - tiao.macale@acme.com
Dependências: Persistência Base XYZ
Tags: rh java

daniel neste caso um Wiki não ajudaria?

Notícias, artigos e o maior fórum brasileiro sobre Java