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

[Gustavo_Serafim]

[quote=Maurício Linhares]
Porque em vez de dividir a aplicação em módulos nós não dividimos a aplicação monstro em pequenas aplicações especializadas no que elas tem que fazer? É mais fácil de escalar, implantar e, especialmente,manter já que cada uma viveria separada das outras, se comunicando apenas através de interfaces bem definidas, usando seja lá o que for que você ache interessante (como WS-* ou REST).[/quote]

Nessa abordagem, dividir em pequenas aplicações, com qual o critério? Decomposição de domínio? Como considerar o negócio na divisão para não ter regras duplicadas, regras comuns entre elas ou muito tráfico de rede?

Qual sua definição de aplicação, mesmo EAR, mesmo datasource?

Exemplo:

Imagine uma empresa grande com muitos sistemas que usam serviços de funcionário e vendas.

Se uma aplicação possuir em sua implementação esses dois conceitos importantes (funcionário e vendas) você disponibilizaria os serviços desses conceitos - que possuem muitas regras de negócio corporativas - no mesmo backend?

Não seria melhor (para corporação não para o projeto) que estivessem isolados logicamente - interfaces protegendo a implementação, backend diferentes - em subsistemas, ou seja, deixando os dois serviços com acoplamento mais fraco?

Eu sei que depende do caso, por isso tentei montar um cenário.

[Gustavo_Serafim]

Ah, outra coisa, esse negócio de “os componentes de negócio” não vingaram é quase uma coisa específica do Java, componentes de negócio em outros ambientes (como os plugins do Rails) vão muito bem obrigado

Não estamos falando de EJB, CORBA… Estamos falando de divisão de sistemas, como interfaces distribuídas ou não. (Acho que saímos do Assunto)

[Mauricio_Linhares]

[quote=Maurício Linhares]Ah, outra coisa, esse negócio de “os componentes de negócio” não vingaram é quase uma coisa específica do Java, componentes de negócio em outros ambientes (como os plugins do Rails) vão muito bem obrigado

Não estamos falando de EJB, CORBA… Estamos falando de divisão de sistemas, como interfaces distribuídas ou não.[/quote]

E eu estou falando de componentes de negócio, que era aonde estava inserido o comentário do Phillip também.

[Mauricio_Linhares]

[quote=Gustavo Serafim]Imagine uma empresa grande com muitos sistemas que usam serviços de funcionário e vendas.

Se uma aplicação possuir em sua implementação esses dois conceitos importantes (funcionário e vendas) você disponibilizaria os serviços desses conceitos - que possuem muitas regras de negócio corporativas - no mesmo backend?

Não seria melhor (para corporação não para o projeto) que estivessem isolados logicamente - interfaces protegendo a implementação, backend diferentes - em subsistemas, ou seja, deixando os dois serviços com acoplamento mais fraco?

Eu sei que depende do caso, por isso tentei montar um cenário.[/quote]

Como você já disse, depende do caso.

Sistemas realmente independentes deixam a implementação muito mais protegida e ajudam ainda em uma coisa muito especial, eles vão ser desenvolvidos em torno dos serviços que eles vão oferecer de verdade as outras aplicações, você não vai ter features mirabolantes ou desnecessárias, tudo vai ser feito em cima da responsabilidade de cada um. Além disso, montar novos serviços em cima dos que já existem fica ainda mais simples, é só você olhar como funcionam os mashups na internet hoje, alguém faz um serviço simples que faz muito bem alguma coisa e outros implementam funcionalidades avançadas ou para nichos específicos.

As aplicações “enterprise” deveriam aprender um pouco mais em como a internet funciona, porque eles estão se dando bem com isso.

[pcalcado]

O compilador: não valida conformidade dos conceitos com o negócio; não valida coesão e acoplamento nos diversos níveis de encapsulamento (método, classe, pacote, componente e ser preferir: serviço); não valida o efeito acumulativo de integrações com acoplamento forte no nível do negócio.

Uma abordagem gráfica ajuda analisar essas questões.

Como o Mauricio falou, eu nao estou falandod e compilador, estou falando de testes que executam especificacoes.

Eu não tenho referencias estatística para falar que essa abordagem falhou, talvez a abordagem apenas evoluiu. Gostaria de entender o contexto da sua conclusão.

Não existem estatísticas -confiáveis- de falha ou adoção mas basta você olhar quem usa componentes desta forma e qual a literatura produzida sobre isso na última década.

Você não dividiria sua aplicação - em sistemas para grandes corporações - para controlar complexidade (efeito acumulativo) com interfaces bem definidas? Criaria outro sistema para controlar a complexidade ou não vê necessidade?

Isso não é resolvido apenas com componentes do estilo UML components. Ultimamente (desde 2002?) usamos serviços para isso ou mesmo componentes que Não seguem todas as 2000 regras do Cheesman. Uma coisa não implica na outra.

Manter muitas vistas? Acho que você está criticando uma metodologia burocrática ou processos de referencias - que as pessoas olham as descrições no template e acham que sabem usar - não a utilidade da UML.
[…]
Não estou criticando como você desenvolve - já fui testemunha da sua capacidade de entrega -, mas as abstrações estão cada vez mais importantes em grandes corporações. Neste sentido que defendo a UML, não metodologias burocráticas de quem não sabe o que está fazendo.

Se eu tenho um modelo UML que não é executável e tenho que gerar um modelo executável (i.e. código) dele eu tenho modelos duplicados, a menos que eu jogue o modelo UML fora (ou o código…).

Nessa abordagem, dividir em pequenas aplicações, com qual o critério? Decomposição de domínio? Como considerar o negócio na divisão para não ter regras duplicadas, regras comuns entre elas ou muito tráfico de rede?

Qual sua definição de aplicação, mesmo EAR, mesmo datasource?

Imagine uma empresa grande com muitos sistemas que usam serviços de funcionário e vendas.

Se uma aplicação possuir em sua implementação esses dois conceitos importantes (funcionário e vendas) você disponibilizaria os serviços desses conceitos - que possuem muitas regras de negócio corporativas - no mesmo backend?

Não seria melhor (para corporação não para o projeto) que estivessem isolados logicamente - interfaces protegendo a implementação, backend diferentes - em subsistemas, ou seja, deixando os dois serviços com acoplamento mais fraco?

Eu sei que depende do caso, por isso tentei montar um cenário.

Foi exatamente o que o maurício sugeriu, Gustavo, só qu sem “coponentes de negócios” e sim com serviços.

[quote=Maurício Linhares]Ah, outra coisa, esse negócio de “os componentes de negócio” não vingaram é quase uma coisa específica do Java, componentes de negócio em outros ambientes (como os plugins do Rails) vão muito bem obrigado

Não estamos falando de EJB, CORBA… Estamos falando de divisão de sistemas, como interfaces distribuídas ou não. (Acho que saímos do Assunto)[/quote]

Creio que os dois estão enganados aqui. Maurício, os componentes do Rails não têm nada a ver com componentes de negócio, eles ou oferecem funcionalidades isoladas ou oferecem requisitos não-funcionais.

[Gustavo_Serafim]

[quote=pcalcado][quote=Gustavo Serafim]
O compilador: não valida conformidade dos conceitos com o negócio; não valida coesão e acoplamento nos diversos níveis de encapsulamento (método, classe, pacote, componente e ser preferir: serviço); não valida o efeito acumulativo de integrações com acoplamento forte no nível do negócio.

Uma abordagem gráfica ajuda analisar essas questões.
[/quote]

Como o Mauricio falou, eu nao estou falandod e compilador, estou falando de testes que executam especificacoes.
[/quote]

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.

Eu não tenho referencias estatística para falar que essa abordagem falhou, talvez a abordagem apenas evoluiu. Gostaria de entender o contexto da sua conclusão.

Não existem estatísticas -confiáveis- de falha ou adoção mas basta você olhar quem usa componentes desta forma e qual a literatura produzida sobre isso na última década.

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.

Você não dividiria sua aplicação - em sistemas para grandes corporações - para controlar complexidade (efeito acumulativo) com interfaces bem definidas? Criaria outro sistema para controlar a complexidade ou não vê necessidade?

Isso não é resolvido apenas com componentes do estilo UML components. Ultimamente (desde 2002?) usamos serviços para isso ou mesmo componentes que Não seguem todas as 2000 regras do Cheesman. Uma coisa não implica na outra.

Quando eu falei em seguir todas as regras?

Manter muitas vistas? Acho que você está criticando uma metodologia burocrática ou processos de referencias - que as pessoas olham as descrições no template e acham que sabem usar - não a utilidade da UML.
[…]
Não estou criticando como você desenvolve - já fui testemunha da sua capacidade de entrega -, mas as abstrações estão cada vez mais importantes em grandes corporações. Neste sentido que defendo a UML, não metodologias burocráticas de quem não sabe o que está fazendo.

Se eu tenho um modelo UML que não é executável e tenho que gerar um modelo executável (i.e. código) dele eu tenho modelos duplicados, a menos que eu jogue o modelo UML fora (ou o código…).

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 Vale, por exemçlo, exigia vários diagramas em contrato, concordo que nesse caso e só documentação inútil.

Nessa abordagem, dividir em pequenas aplicações, com qual o critério? Decomposição de domínio? Como considerar o negócio na divisão para não ter regras duplicadas, regras comuns entre elas ou muito tráfico de rede?

Qual sua definição de aplicação, mesmo EAR, mesmo datasource?

Imagine uma empresa grande com muitos sistemas que usam serviços de funcionário e vendas.

Se uma aplicação possuir em sua implementação esses dois conceitos importantes (funcionário e vendas) você disponibilizaria os serviços desses conceitos - que possuem muitas regras de negócio corporativas - no mesmo backend?

Não seria melhor (para corporação não para o projeto) que estivessem isolados logicamente - interfaces protegendo a implementação, backend diferentes - em subsistemas, ou seja, deixando os dois serviços com acoplamento mais fraco?

Eu sei que depende do caso, por isso tentei montar um cenário.

Foi exatamente o que o maurício sugeriu, Gustavo, só qu sem “coponentes de negócios” e sim com serviços.

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”.

[Mauricio_Linhares]

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

Bem, isso eu não posso fazer, subsistema pra mim é um sistema que fica dentro de outro e é exatamente esse tipo de abordagem que eu não acredito que seja a ideal

Acho que os sistemas devem ser independentes ao máximo no que eles fazem, eles não devem estar contidos em outros, mas sim fazer uso de outros. Mais uma vez, veja o conceito de mashups, é exatamente o que eu quero exemplificar aqui e eu não consigo imaginar mashups como “sub-sistemas”.

[Mauricio_Linhares]

Creio que os dois estão enganados aqui. Maurício, os componentes do Rails não têm nada a ver com componentes de negócio, eles ou oferecem funcionalidades isoladas ou oferecem requisitos não-funcionais.

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?

[cmoscoso]

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.

Eu não entendi qual é o público alvo do seu modelo UML.

Para stakehoelders eu ainda acho mais adequado o uso de DSLs textuais como mencionado pelo Mauricio, criadas a partir de estorias ou casos de uso (td bem, uma pontinha UML), tanto faz.

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.

Acho que todos nós concordamos quanto a utilidade para comunicação entre programadores (como falei para o cliente eu prefiro outra abordagem), mas eu não iria além de rascunhos e wikis. Qualquer transformação inversa/reversa exigira intervencao e aí você estara mantendo dois modelos.

Eu diria que o código é o modelo, documentação está em parte nos testes.

[pcalcado]

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.

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?

Quando eu falei em seguir todas as regras?

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

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.

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

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.

[pcalcado]

[quote=Maurício Linhares]
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?[/quote]

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.

[andre_salvati]

[quote=sapulha]
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.[/quote]

Cara que escreve MAIS em vez MAS nem merece resposta…

[Gustavo_Serafim]

[quote=pcalcado] 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.
[/quote]

[quote=Maurício Linhares]
Bem, isso eu não posso fazer, subsistema pra mim é um sistema que fica dentro de outro […] [/quote]

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.

[…] 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 […]

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).

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.

[pcalcado]

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.

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?

[Luiz_Aguiar]

…

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

[Marcio_Duran]

[size=18]A UML e seu Lugar no Processo de Software[/size]

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.

[Mauricio_Linhares]

[quote=Marcio Duran][size=18]A UML e seu Lugar no Processo de Software[/size]

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.[/quote]

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

[andre_salvati]

[quote=Gustavo Serafim]…

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
[/quote]

:?: … ++

[Gustavo_Serafim]

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.

[…] 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”.

[Marcio_Duran]

[quote=Maurício Linhares]
Estamos presenciando um momento único, essa foi a mensagem mais sensata do gato félix no GUJ até hoje.[/quote]

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