Engenheiros ainda usam diagramas de casos de uso e diagramas de classe?

Gustavo Serafim wrote:
Você está subestimado meu comentário.

Estou falando em definir os conceitos certos observando o negócio (abstrações focando em responsabilidade, heranças verdadeiras, cuidando do espaço estado no caso de polimorfismo, tipos relacionamentos corretos, manter o estado consistente do objeto).

Efeito acumulativo de integrações com acoplamento forte no nível do negócio, só e possível analisar olhando para o negócio.

Ou seja, analise/entendimento do negócio necessário para codificar os testes, codificar o domínio e algumas decisões arquiteturais importantes. É nesse entendimento/validação do entendimento que a UML pode ajudar. E o próprio código é a documentação.

Não, Gustavo, você que subestimou o meu qundo vinculou com modelos executáveis. Recomendo que você d6e uma lida sobre Domain-Driven Design e Test-Driven Development para entender como fazer a "análise" diretamente em um modelo executável e ao mesmo tempo validar este modelo automaticamente usando uma técnica de design que cria baixo acoplamento.

Gustavo Serafim wrote:
Muitos conceitos importantes foram reproduzidos nessa nova literatura com outros nomes e em alguns casos até com o mesmo nome. A parte que não funcionou saiu por seleção natural. Nenhuma abordagem é perfeita, logo é complicado dizer que essa não funcionou.

Programação procedural trouxe muitos conceitos importantes. Assembly trouxe muitos conceitos importantes. Java 1.0 trouxe muitos conceitos importantes. Só por isso você o usaria?

Gustavo Serafim wrote:
Quando eu falei em seguir todas as regras?

Então qual o problema das abordagens mencionadas, por exemplo, pelo Maurício?

Gustavo Serafim wrote:
Modelos duplicados é um conceito interessante e fico atento com isso. Por isso costumo gerar algumas estruturas de código usando UML. E, algum nível de duplicação é aceitável, mas muito pouco. Tem que agregar valor de forma clara o modelo UML, mas não manter diagramas.

A literatura que sugeri acima mostra - e não ésó ela, são apenas exemplos- que voc6e pode dispensar o UML para praticamente tudo, exceto talvez comunicação visual.

Gustavo Serafim wrote:
A Vale, por exemçlo, exigia vários diagramas em contrato, concordo que nesse caso e só documentação inútil.

Se a CVRD solicitasse que todos os programadores fossem canhotos, torcedores do Madureira e usassem camisa verde todas as consultorias de três letrinhas iriam seguir as ordens sem pensar meia vez

Gustavo Serafim wrote:
Estou usando o termo "componente de negócio" de forma mais ampla. Nunca segui exatamente os conceitos do curso da PUC ou do livro que ela indicava, nem na minha primeira leitura (que tem muito tempo!), eu já tinha outras influências na época.

Você tem muitas reservas com esse termo, por isso, eu parei de usar - componente de negócio - nos meus comentários, passei usar subsistema (mais neutro). Serviços básicos/negócio realmente ficam melhor. Até por isso usei um exemplo com o termo serviço.

Só concordo com o Maurício se ele trocar "Sistema" por "backend" ou "subsistema".

Um subsistema não é um componente, nem um serviço. Um subsistema pode ser componentizado mas componente (e serviço) indica uma acoplamento muito menor que um subsistema teria. Um subsistema não vive sem o sistema, um componente ou um serviço vivem.

This message was edited 1 time. Last update was at 22/05/2008 03:33:01

Maurício Linhares wrote:
Imagine que você tem uma loja, sua loja tem pedidos, que contém itens (que são os seus produtos sendo vendidos) e você precisa controlar o que foi pago ou nãoe quando foi pago, você resolve então usar o ActiveMerchant pŕa fazer isso, isso não seria um componente de negócio?

Outro exemplo é o Freemium, que vai ma mesma idéia só que em vez de ordens e produtos existem as inscrições. Se isso faz parte do meu negócio (não dá pra imaginar um serviço que "se vende" sem ser por inscrições) e o plugin implementa isso, ele não se torna um componente de negócio?

São funcionaldiades isoladas, Maurício, que dependem de configuração e customização. Eles são acoplados com regras de negócio e daí surgem as aplicações. É como se eu crio um site de busca e uso uma search engine como o Lucene, ele faz 99% do que meu site é só que não é um componente de negócios, é infra-estrutura. Eu ainda preciso dizer para ele como meu negócio se parece e aí eu crio um componente de negócio. Resumindo: componentes de negócio COTS devem estar prontos out-of-the-box.

Este tipo de componente não é incomum, aliás, a diferença em Rails é que eles são livres. Quando comentei sobre componentes Rails na outra thread não era sobre os componentes em específico e sim sobre a estrutura e ecossistema. Contruir componentes instance-based em 2008 é algo bem complicado.

Eu entendo o que o Gustavo está falando porque, além de termos trabalhado juntos e sermos amigos lemos um livro muito interessante (apesar de super-defasado) chamado UML Components, que prega uma metodologia para componentes de negócio.

JavaEvangelist Membro desde: 02/06/2005 16:28:38 Mensagens: 425 Offline

sapulha wrote:
Afirmar que Casos de Uso são histórias que não agregam nada a um projeto, é uma típica resposta de pessoas bitoladas que não sabem abstrair as necessidades de um projeto, tentando resolver tudo sempre com o olhar de quem domina uma linguagem muito bem, MAIS não entende nada de planejamento.
Casos de Uso, assim como a UML, tem o objetivo principal de manter o conhecimento em modelos, e não em pessoas.
Assim como as metodologias ágeis, a UML tem e sempre terá um papel muito importante no mundo orientado a objetos.

Cara que escreve MAIS em vez MAS nem merece resposta....

Thread.start() Membro desde: 04/09/2006 15:33:40 Mensagens: 35 Offline

pcalcado wrote: Um subsistema não é um componente, nem um serviço. Um subsistema pode ser componentizado mas componente (e serviço) indica uma acoplamento muito menor que um subsistema teria. Um subsistema não vive sem o sistema, um componente ou um serviço vivem.

Maurício Linhares wrote:
Bem, isso eu não posso fazer, subsistema pra mim é um sistema que fica dentro de outro [...]

Pra facilitar troca de idéias, segue os conceitos que estou usando:

Definição de subsistema: Possui a semântica de um pacote, de modo que possa conter outros elementos, de modo que tenha comportamento. O comportamento do subsistema é definido por classes ou outros subsistemas contidos nele. Um subsistema compreende uma ou mais interfaces, que definem o comportamento que ele pode apresentar. (O subsistema vive de forma independente sim, ele uma forma de abstração. Sistema é um conceito também muito genérico.)

No vejo como poderia ser mais genérico essa definição e o seu uso. Fica aderente com: serviços; componente de infra; componente de negócio.

Definição componentes de negócio: um subsistema que contém regras de negócio e seus dados. (Também genérico, poderia ser um serviço básico (ou algo parecido com serviços corporativos na definição de Erl), não estou restringindo com o Livro usado no curso da Puc).

Usei esses termos para simplificar, pois senão teríamos que discutir muitos detalhes para formar uma simples idéia.

pcalcado wrote: [...] fazer a "análise" diretamente em um modelo executável e ao mesmo tempo validar este modelo automaticamente usando uma técnica de design que cria baixo acoplamento [...]

cmoscoso wrote:
Eu não entendi qual é o público alvo do seu modelo UML. [...]

Como tenho usado a UML:

No auxilio de tomada de decisões quando estamos falando de abstrações maiores que classe (código está diretamente relacionado com classe) como, por exemplo, subsistemas, serviços, pacotes. (A UML ajuda tomar decisões). E também na documentando as principais abstrações da arquitetura.

No sentido de rascunho, desenhamos os conceitos (ou gerando diagramas com o código com alguns ajustes se preferir) para validar com o processo de negócio que está sendo "automatizado" e/ou com o usuário. Em alguns casos no próprio mapeamento do processo de negócio. E talvez, gerando algum código se for possível.

Já conheço o benefício de especificação diretamente nos testes, no entanto, para analise, algumas abstrações são úteis. Como você sugeriu, vou pesquisar como os testes podem ajudar em tomadas de decisão. (Já citei algumas necessidades, por exemplo, avaliar dependência circular e distribuição de responsabilidades).

pcalcado wrote: Então qual o problema das abordagens mencionadas, por exemplo, pelo Maurício?

A definição de sistema também é genérica, por isso procurei entender melhor a idéia do Maurício, mas não descordei diretamente.

Um serviço encapsula um ou mais backends. Na definição de backend, podemos ter componentes, sistemas ou outros serviços. Muitos autores divergem como seria um backend para um serviço, mas o importante que ele representa alguma instancia do negócio digitalmente, portanto não podem ficar inconsistentes e são, ou deveriam ser únicos.

Quanto aos componentes de negócio como backend, sabemos que subsistemas que encapsulam conceitos de negócio e suas regras unicamente e sem redundância corporativa, não existem, e é inviável. (Serviços compostos ajudam encapsular essas redundâncias.) Mas deveria ser uma meta arquitetural para desenvolvimento, alguns autores citam como abordagem a Decomposição de domínio. O objetivo final é apoiar a automatização de processos de negócio - pensar corporativamente - pois empresas são coleções de processos de negócio.

Acho que poderíamos criar um tópico com isso.

Gustavo Serafim wrote:
Já conheço o benefício de especificação diretamente nos testes, no entanto, para analise, algumas abstrações são úteis. Como você sugeriu, vou pesquisar como os testes podem ajudar em tomadas de decisão. (Já citei algumas necessidades, por exemplo, avaliar dependência circular e distribuição de responsabilidades).

Como mj;a mencionei algumas vezes aqui nesta thread isso pode ser feito por códigio sem qualquer problema. Na verdade, se você possui um modeo de análise que difere do modelo de implementação eu diria que voê tem um problema, e grave.

Gustavo Serafim wrote:
Um serviço encapsula um ou mais backends. Na definição de backend, podemos ter componentes, sistemas ou outros serviços. Muitos autores divergem como seria um backend para um serviço, mas o importante que ele representa alguma instancia do negócio digitalmente, portanto não podem ficar inconsistentes e são, ou deveriam ser únicos.

Quanto aos componentes de negócio como backend, sabemos que subsistemas que encapsulam conceitos de negócio e suas regras unicamente e sem redundância corporativa, não existe, e é inviável. (Serviços compostos ajudam encapsular essas redundâncias.) Mas deveria ser uma meta arquitetural para desenvolvimento, alguns autores citam como abordagem a Decomposição de domínio. O objetivo final é apoiar a automatização de processos de negócio - pensar corporativamente - pois empresas são coleções de processos de negócio.

Acho que poderíamos criar um tópico com isso.

Desculpe mas eu não entedi absolutamente coisa alguma. Pode explicar de outra forma?

Gustavo Serafim wrote:...

Cara desculpa fugir do aspecto técnico da thread, mas faz tempo que não vejo alguém falando tão "burocraticamente" sem dizer nada, parece muito um povo da IBM falando, enchem de termos e nomes bonitos pra justificar as coisas ruins que fazem rs

JavaEvangelist Membro desde: 23/01/2008 11:14:35 Mensagens: 418 Offline

A UML e seu Lugar no Processo de Software

A UML não é um modelo de processo de software ou uma metodologia de desenvolvimento de sistemas; ela é uma notação, um mecanismo para "apontar o problema" e forma a expor a essência do domínio de um aplicativo.

Marcio Duran wrote:A UML e seu Lugar no Processo de Software

A UML não é um modelo de processo de software ou uma metodologia de desenvolvimento de sistemas; ela é uma notação, um mecanismo para "apontar o problema" e forma a expor a essência do domínio de um aplicativo.

Estamos presenciando um momento único, essa foi a mensagem mais sensata do gato félix no GUJ até hoje.

This message was edited 1 time. Last update was at 23/05/2008 12:31:27

Luiz Aguiar wrote:

Gustavo Serafim wrote:...

Cara desculpa fugir do aspecto técnico da thread, mas faz tempo que não vejo alguém falando tão "burocraticamente" sem dizer nada, parece muito um povo da IBM falando, enchem de termos e nomes bonitos pra justificar as coisas ruins que fazem rs

..... ++

This message was edited 1 time. Last update was at 23/05/2008 13:30:19

pcalcado wrote:
Desculpe mas eu não entedi absolutamente coisa alguma. Pode explicar de outra forma?

Realmente não ficou legal, tentei ser muito sintético. Vou reescrever.

Luiz Aguiar wrote:
[...] mas faz tempo que não vejo alguém falando tão "burocraticamente" [...]

Burocraticamente?
Acho que fui formal ou vocabulário de conceitos diferente, mas isso é diferente de não "dizer nada".

JavaEvangelist Membro desde: 23/01/2008 11:14:35 Mensagens: 418 Offline

Maurício Linhares wrote:
Estamos presenciando um momento único, essa foi a mensagem mais sensata do gato félix no GUJ até hoje.

"Estou lislongiado, pela observação do mais célebre entre os Moderadores "

Thread.start() Membro desde: 04/09/2006 15:33:40 Mensagens: 35 Offline

pcalcado wrote:
Desculpe mas eu não entedi absolutamente coisa alguma. Pode explicar de outra forma?

Maurício Linhares wrote:...

Qual definição de sistema que você usa? Um frontend + backend? Como o termo sistema é muito genérico, depende da cultura da empresa, é comum que vários conceitos importantes - que deveriam ser isolados - ficarem no mesmo sistema. (exemplo) É interessante considerar - no caso de SOA - um sistema como uma camada de apresentação, e serviços/componentes como um backend compartilhado por vários sistemas (esses serviços são orquestrados por serviços orientados ao possesso ou por uma camada de aplicação).

Detalhando melhor:

Contexto

As empresas são grandes coleções de processos de negócio. Por isso, basicamente, estou falando de serviços para automação de processos de negócio com ferramentas BPMS, serviços básicos para encapsular as regras/dados do negócio e encapsular sistemas legado.

Para um projeto de desenvolvimento de sistema com qualidade não é necessária essa estratégia SOA. Não existe SOA para um sistema apenas. SOA resolve problemas corporativos visando flexibilidade.

Definição de serviço

Um serviço encapsula um ou mais backends. Na definição de backend, podemos ter subsistemas, componentes, sistemas ou outros serviços.

Existem muitas definições de backend no contexto de SOA, mas o importante é que ele representa uma instancia do negócio digitalmente (regras de negócio ou atividade do processo de negócio automatizado), portanto não podem ficar inconsistentes, seria melhor que fossem únicos e independentes.

Componentes de negócio com seus problemas e serviços

E comum tratarmos o backend de serviços básicos (ou algo parecido com serviços corporativos na definição de Erl) como componente de negócio.

O objetivo do componente de negócio é proteger as regras de negócio, evitando, sobretudo, a duplicidade - ou seja, primando para que, quando da modificação de alguma regra, seja possível obter um único ponto de alteração -, os componentes de negócio (subsistemas) são normalmente identificados decompondo-se o domínio, e disponibilizados como um recurso corporativo.

Na prática, a implementação de tal ponto singular, não é simples e muitos casos inviável. Dois motivos básicos para essa conclusão:

Primeiro, seria necessário uma harmonização dos conceitos da empresa. Exemplo, todos os sistemas deveriam entender o conceito de negócio ?produto? da mesma forma, mas em função do legado e da falta de análise, temos em um ambiente corporativo com várias semânticas para o mesmo conceito, no caso de ?produto?, poderia significar coisas diferentes em sistemas/serviços diferentes. Harmonizar e unificar esses conceitos e em muitos casos inviável.

Segundo, existe duplicação de conceitos em sistemas diferentes, replicando muito as regras de negócio. A duplicação de regras é muito comum, em função: do legado; da forma de desenvolvimento sem considerar o processo de negócio (que traz uma visão interdeparmental); integração baseada em bases de dados corporativos; e outras questões.. (Conceitos importantes com relacionamento forte (agregação ou composição) separados em sistemas diferentes, também é um problema para evitar replicação de código).

Os serviços básicos (componentes de negócio ou não) como suas inevitáveis duplicações de conceitos/regras e inconsistências, normalmente são encapsuladas/controladas em serviços compostos e em serviços orientados a processo de negócio.

Conclusão

Mesmo com todas as dificuldades os componentes de negócio isolados e pouco acoplados deveriam ser uma meta/um norte para arquitetura. Por isso a importância de técnicas decomposição do domínio e decomposição do processo de negócio para identificação de serviços em sistemas como a estratégia SOA.

Trabalho em uma empresa que tem hoje 200 sistemas em desenvolvimento (automatizando partes diferentes de uma grande processo de negocio, exemplo "vender seguro", compartilhando com isso muitos serviços que possuem muitas regras), o efeito acumulativo de conceitos e regras duplicadas, são refletidos em pouca flexibilidade para o negócio, ou seja, dificuldade para assimilar mudanças. SOA ajuda efetivamente controlar essas questões.

Na prática é muito difícil que uma equipe comprometida com os resultados do projeto tenha tempo ou interesse de usar essa estratégia SOA, que não traz muitos benefícios imediatos para o projeto (talvez reuso), apenas traz benéficos significativos se pensarmos corporativamente e no efeito acumulativos da abordagem. Por isso governanca é importante para SOA.

Gustavo Serafim wrote:[...]
Conclusão

Mesmo com todas as dificuldades os componentes de negócio isolados e pouco acoplados deveriam ser uma meta/um norte para arquitetura. Por isso a importância de técnicas decomposição do domínio e decomposição do processo de negócio para identificação de serviços em sistemas como a estratégia SOA.

Trabalho em uma empresa que tem hoje 200 sistemas em desenvolvimento, o efeito acumulativo de conceitos e regras duplicadas, são refletidos em pouca flexibilidade para o negócio, ou seja, dificuldade para assimilar mudanças. SOA ajuda efetivamente controlar essas questões.

Na prática é muito difícil que uma equipe comprometida com os resultados do projeto tenha tempo ou interesse de usar essa estratégia SOA, que não traz muitos benefícios imediatos para o projeto (talvez reuso), apenas traz benéficos significativos se pensarmos corporativamente e no efeito acumulativos da abordagem. Por isso governanca é importante para SOA.

Além de não concordar com pontos em suas definições eu não entendi exatamente sua conclusão. O que você concluiu, que serviços e componentes são a mesma coisa?

This message was edited 1 time. Last update was at 25/05/2008 13:54:19

pcalcado wrote:
Além de não concordar com pontos em suas definições eu não entendi exatamente sua conclusão. O que você concluiu, que serviços e componentes são a mesma coisa?

A conclusão teve a pretensão de passar a idéia que componentes de negócio são uma boa base, uma maneira de organizar a casa para serviços (organizar no sentido de evitar replicação de regras e de manter pouco acoplado os conceitos chaves para empresa, garantindo uma evolução minimamente independente).

Todo componente pode ser considerado um serviço básico, mas acredito que o contrário não é verdadeiro. Componente de negócio é mais especializado, trata diretamente da organização (dependência, evitar duplicação de regras) dos conceitos corporativos.

Teve também a pretensão de mostrar que deveriam ser apenas um norte arquitetural, mas não uma obrigação em função dos problemas que foram mostrados. Abstrações maiores de serviços (serviços compostos, de negócio dependendo do autor) podem ajudar em casos em que não é possível usar os conceitos de componentes de negócio.

Gustavo Serafim wrote:
A conclusão teve a pretensão de passar a idéia que componentes de negócio são uma boa base, uma maneira de organizar a casa para serviços (organizar no sentido de evitar replicação de regras e de manter pouco acoplado os conceitos chaves para empresa, garantindo uma evolução minimamente independente).

Hm.. e por que eu deveria pensar em componentes ao invés de partir para serviços de vez?

Gustavo Serafim wrote:
Todo componente pode ser considerado um serviço básico, mas acredito que o contrário não é verdadeiro. Componente de negócio é mais especializado, trata diretamente da organização (dependência, evitar duplicação de regras) dos conceitos corporativos.

Teve também a pretensão de mostrar que deveriam ser apenas um norte arquitetural, mas não uma obrigação em função dos problemas que foram mostrados. Abstrações maiores de serviços (serviços compostos, de negócio dependendo do autor) podem ajudar em casos em que não é possível usar os conceitos de componentes de negócio.

Não. Se você ler Peter Herzum/Oliver Sims vai ver que mesmo CBD possui os mesmos conceitos de 'servico básico' e um componente pode assumir diversas granularidades nesta dimensão. CBD possui conceitos de componentes granulares, orquestração de processos, roteamento e quase tudo que se pensa que surgiram com serviços. Basicamente SOA se resume à utilizar apenas componentes type-based e remotos.

Eu já tentei correlacionar CBD com SOA e falhei miseravelmente, 90% dos conceitos presentes em SOA são um subconjunto de CBD.