| Autor |
Mensagem |
|
|
Kenobi wrote:
Ao invés do BI ir diretamente à fonte, você disponibilizaria o conteúdo através de um proxy ( ESB).
Kenobi, concordo que - de forma complementar - serviços focados em dados são necessários. No entanto, adotar uma abordagem SOA com EDA, pode contribuir muito nestes casos. Recentemente eu estava levantando algumas questões parecidas em blog de SOA (Dados e BI):
"SOA tem uma base sólida em Design by Contract (DbC) e Component Based Development (CBD).[...]"
"[...] Serviços encapsulam os dados de seu backend - essa é uma questão essencial. Caso um determinado cliente esteja utilizando dados obtidos por intermédio de um serviço para a "execução" de uma regra de negócio, provavelmente essa regra ficaria mais coesa no serviço, não no cliente, ou seja, o serviço deveria fornecer uma operação que encapsula a regra, retornando, por exemplo, um boolean, evitando desta forma que o cliente receba dados desnecessários.
Seguindo o mesmo princípio, um serviço não deve receber dados de outros serviços para cumprir uma regra de negócio. Normalmente, tudo o que recebem são seus próprios dados ou, no máximo, identificadores únicos de conceitos de outros serviços, evitando dados/objetos que não estejam coesos. [...]"
"[...]Serviços encapsulam seus dados, por isso, sempre achei estranhas as abordagens de BI com SOA. BI consolida dados, para isso, consomem dados; serviços seguem o caminho oposto, escondem dados. Ainda temos questões de desempenho envolvidas pela característica distributiva dos serviços. No entanto, um interessante artigo da InfoQ, mostra que SOA com EDA pode, em muitos casos, substituir abordagens ETL para consolidar bases, com vantagens, para apoiar iniciativas de BI.[...]"
[]'s
|
 |
|
|
Mais uma referência interessante: Robert C. Martin
http://blog.objectmentor.com/articles/category/service-oriented-architecture
|
|
|
|
Trabalho com adoção SOA e também gosto muito desse autor, tenho alguns posts baseados nele. http://www.soacorporativa.com.br
|
|
|
|
pcalcado wrote:...
Ok, não precisa pedir minha cabeça. 
Este post contribui com o tema: http://blog.fragmental.com.br/2008/08/09/analista-pedreiro
|
|
|
|
Para contribuir com o tema, segue citação: "No tempo que levaria criando o código para um design, você pode comparar três designs usando imagens" - Kent Beck, em Extreme Programming Explained
Uso a UML para modelar, o modelo pode ser quadro branco... o importante é o ato de modelar, e talvez, deveria ser descartável.
Claro que em um quadro branco, usamos todo tipo de símbolo gráfico inventado no momento para complementar a idéia, ou seja, sem formalismo.
Outro uso interessante da UML seria ensinar praticas e métodos, uma vez entendido os mecanismos, podem ser trocados por um processo mais mental ou direto no código...
No entanto, concordo que código também é um modelo.
|
|
|
|
gilmatryx wrote:
Gustavo Serafim wrote:
Um caso de uso "não abstrato", tem que trazer um valor observável para o ator (gravar ou calcular, por exemplo, não é "observável" acontece internamente no sistema). Contudo, você pode dividir em cenários.
Desculpe, mas "calcular" pode ser um cálculo requisitado e observável pelo ator sim. Mas acho que entendi o sentido da frase.
Pode ser... depende do negócio. Em um UC Calcular Empréstimo, o retorno observável é o valor do empréstimo (o empréstimo calculado), então está aderente a um negócio de banco. Como o calculo é feito, quais sistemas participam, em que banco eh gravado, não é observável pelo ator.
|
|
|
|
MarceloAraujo wrote:
Pois é. Caso de uso não precisa disso, não precisa daquilo. Eles são quase tão customizáveis quanto o RUP 
Toda abordagem tem usa essência, sua invariante... o importante é entender o conceito, o retorno. E escolher a abordagem em função do retorno que você precisa.
Fluxos do UC ajuda levantar os dados/conceitos da interação ator/sistema. Ajuda também na organização dos cenários no UC, pois permite referenciar/relacionar fluxos alternativos.
|
|
|
|
Tentando comparar as abordagens:
rodrigoy wrote:
História 3: O sistema envia um e-mail ao reservar o quarto
UC não tem necessariamente uma discrição em passos, neste sentido pode ser igual a historia, eu acredito. A diferença está na identificação, existe mais formalismo para ser um UC.
Enviar e-mail não seria um UC (só se o sistema fosse um servidor de e-mail), mas Reservar Quarto poderia ser. Depende do negócio.
rodrigoy wrote:
História 2: Um atendente não pode reservar quartos para clientes não aprovados
A História 2 é uma regra de negócio. Pode ficar diretamente no código, testes, ou documentada (no UC) se algum gerente exigir.
|
|
|
|
gilmatryx wrote:
Nesse caso acho que pela técnica do caso de uso pode-se dividi-lo em outros menores não? Se puder qual seria a grande diferença então nesse caso da "Funcionalidade X"?
Um caso de uso "não abstrato", tem que trazer um valor observável para o ator (gravar ou calcular, por exemplo, não é "observável" acontece internamente no sistema). Contudo, você pode dividir em cenários.
|
|
|
|
rodrigoy wrote:
Esse caso de fato é muito banal, porém, ocorrem situações como um sistema de Call Center Vendas onde 85% das funcionalidades estão num único caso de uso e de lá se extraem umas 20 histórias. Aí o caso de uso é bom para concentrar tudo.
Acredito que UC fica mais organizado, quando bem feito.
(tenho bons resultados com UC, mas concordo que não é necessariamente melhor que História, é apenas meu ponto de vista atual).
Seguindo essa idéia: retorno atômico, observável, na perspectiva do ator; um sistema de Call Center poderia ter um UC por serviço prestado. Depende do negócio.
Obrigado pelo exemplo.
|
|
|
|
A formação das pessoas deve se verificada. Só processo ou práticas, mesmo ágeis, não resolve se sua empresa contrata mão-de-obra barata e usa processos para compensar a falta de formação da equipe. A burocracia gerada vai inviabilizar qualquer prazo razoável.
É provável que seja um projeto virtualmente impossível.
|
|
|
|
|
"Vamos fazer uma entrega política..."
|
|
|
|
Acredito que quando a equipe é formada de desenvolvedores, Stories funcionam bem, mas quando temos um analista de negócio na equipe (com formação apenas de negócio), acho que o formalismo do UC é mais indicado. (Acredito que ajuda o analista de negocio pensar em uma solução funcional para os requisitos.)
Considerações: O formalismo do UC - retorno atômico observável na perspectiva do ator - ajuda organizar melhor o desenvolvimento (solução funcional pra os requisitos, não CRUDs ), pois representam formalmente uma funcionalidade significativa para o negócio. As iterações podem ser organizadas por cenários, se for o caso. Ainda temos recursos interessantes como, por exemplo, extensão e inclusão.
O caso de uso deve ser simples e sintético. Gosto da abordagem de especificar apenas os dados que passam na fronteira ator/sistema.
Segue exemplo simples para ilustrar (um exemplo mais complexo justificaria melhor a abordagem, acredito)
Reservar Apartamento
Fluxo básico
1. Atendente informa hotel, datas e tipo de apartamento
2. Sistema fornece disponibilidade e preço
3. Atendente informa CPF do cliente e confirma
4. Sistema exibe um identificador (R1)
5. Sistema envia a confirmação por e-mail
(R1 - Regra de negócio, apenas clientes aprovados poderão reservar apartamentos)
Fluxo Alternativo: Quarto não disponível
(substitui passo 2)
Sistema exibe mensagem de indisponibilidade.
(volta passo 1)
Como ficaria com Stories o exemplo?
|
|
|
|
|
Mais uma Referência: http://www.infoq.com/news/2008/07/use-case-or-user-story
|
|
|
|
Um exemplo melhor: Cliente; ClienteCorporativo; ClientePessoa; (Uma herança honesta, aderente ao negócio)
Operação: obterCassificação (calculada em função da data de adesão do cliente e do endereço; data e endereço são atributos de Cliente)
A implementação desta Operação seria um método na classe mais abstrata. (Não teríamos mais métodos nas outras classes para essa operação, pois o comportamento é idêntico)
Eu estava considerando este caso como uma herança sem polimorfismo, pois o método para essa operação não será escolhido em tempo de execução (sem polimorfismo, só existe um método para essa Operação)
OK, talvez conceito de polimorfismo esteja impreciso. Podemos considerar polimorfismo, mesmo com apenas um método para a Operação?
|
|
|
|
|
|