ARQUITETURA Desenho de Solução para Mapeamento do Negócio Versão 2.2

COMO ESTÁ A ARQUITETURA DO PROJETO: Fluxo, Serviço, Batch, Relatórios, Geração da Documentação, Diretrizes COMO FAZER : Ferramentas Utilizadas, Requerimentos, Passos Gerais, Fluxos, Serviços, Tela...

Engenharia de Negócios ou Engenharia de Requisitos? Empresas estão voltadas hoje no foco inovação negócio – inovação consegue com mudança rápida e a área de arquitetura com seus modelos propõe isso; Modelo Preciso de TI: Existe negócio mapeado sendo necessário otimizar o processo e para implantá-lo precisa área específica; Existem modelo de arquitetura que apresenta construção juntamente funcionalidade de serviços e negócios; Ex.: Pesquisar Aparelho, Pesquisar Telefone, Pesquisar Produto; Dividido diversos partes: funcionais, cesta de serviços já construídos na empresa, com isso consegue acelerar implantação do sistema. Idéia básica: quebrar o negócio, parecer em componentes lógicos de chamada serviços, verifica o que já existe, cruzam os dois e temos a funcionalidade implementada. Determinar Conjuntos de operação agrupadas de forma funcional e responsáveis por um segmento de informação: Ex.: Pesquisar Cliente: operações registrar e consultar – esse serviço é responsável por qualquer informação de cliente ou seja ninguém vai escrever ou verificar coisas sem por esses serviços ou uma dessas operações do meu serviço.

Estrutura Padrão: Interface com o mundo exterior; Lógica : o que o serviço faz; Dados que o serviço acessa;

Para que os serviços devem ter um processo de negócio? Ex.: Calcular Valor Produto existe processo interno – pesquisar tarifas, calcular tributos fiscais, incluir exceção log. - torna-se necessário efetivar vários passos para aquela funcionalidade. Vários passos são executados para que a funcionalidade de negócio seja efetivada.

Serviço: são funcionalidades de negócios. O tamanho dele a granularidade é voltado a negócio; nunca vamos ter um serviço de cálculo de digito verificador; Serviço tem funcionalidade maior; Componentes: são pedaços de códigos que normalmente são reutilizados. São funcionalidades técnicas. Ex cálculo digito verificador, criptografia, inclusão de dados numa base. Esse conceito e uma quebra de paradigma da programação normal; Erro comum: WebServices não são serviços. São uma forma de expor disponibilizar componente, programa, sistema inteiro num formado pré-definido onde existe uma série de padronização.

Cesta de Serviço ??? Hoje a idéia com essa Arquitetura é ter uma cesta de serviços onde vai criando diversos serviços; Isso permite uma manutenção rápida devido sua localização estratégica. Um serviço - de inclusão de saldo cliente - a idéia é que seja usado nos diversos módulos - seja a única forma de acessar as informações. Diagrama de Caso de Uso: fala cada “pedacinho” do sistema envolvido para realizar o caso de uso; Batch: devem consumir sempre que possível os serviços já pronto que consomem camada de dados. Os programas batch hoje são os únicos que podem acessar base de dados direta sem chamar os serviços devido a performance. Portanto não se deve fazer chamada de lote através serviço pois serviço é um a um assim os serviço de batch são voltados para lotes. Caso de batch estiver chamando um a um pela implementação usa o serviço. Batch são exceção a uso de serviço.

Serviço um serviço completo existem "n" processos encapsulados; Importante identificar os pré-requisitos e isolar o problema; Assim os diagramas deverão estar atualizados e sincronizados; Quais são os dados de entrada, o que faz... Há reaproveitamento de serviço; Quando um serviço é construído não sabe quais são as partes do sistemas deverá usa-lo por isso construí-lo para que possa ser reutilizado de forma independente; Cada Serviço tem uma documentação específica (exemplo no word de Documento Esp. Técnica e no EA Diagrama Classe Conceitual + Diagrama de Atividades). -Desses documentos observa-se o nome serviço, quais são as Entrada, Saídas, todos informações para funcionar (regra de negocio) e repassada para pessoal especificação para criarem documentos específicos; -Serviços simples de acesso a uma tabela física na base de dados não faz diagrama atividade; Alguns casos podem ser acordados para outros diagrama por exemplo diagrama de sequencia. -Toda lógica e regra do programa está escrita e detalhada APENAS no diagrama de atividade; -Normalmente cada objeto “control” descreve exatamente qual é o programa que está realizando. Em alguns casos pode-se não ter ou alguns controls realizadas por um programa só. ex.: componente;

Como fazer? Para identificar os Requerimentos/Requisitos de negócio que se tem que cumprir deve-se atentar para os passos abaixo: Passos gerais: 1)Levantamento geral tem que estar perfeito (esse levantamento é feito com o analista funcional que escreveu o caso de uso); 2)Estrutura de caso de uso – levantamento com analista; Designer tem que apontar falhas senão T O D O o processo posterior será comprometido porque não há visão do todo; 3)Ler o módulo inteiro para depois diagramar; 4)Ler caso de uso e fazer analise; 5)Validar protótipo - entender protótipo como navega (para tela); 6)Validar modelo de dados lógico; 7)Entender o modelo dados; 8)Verificar se estão coerentes entre lógico e físico; 9)Analisar e entender para fazer validação do modelo de dados e começar diagramação; 10)Disponibilizar o desenho para fábrica validado anteriormente pelo analista funcional. Isso é um acordo entre grupo de gerencia e a área de arquitetura; *Cuidado para designer não programar – mas tem coisas que devem ser mencionadas; *Todo desenho de solução adotado nesta metodologia (e em geral na UML) refere-se apenas a mapeamento em base de dados - exemplo serviços ou batch. Nunca será desenhado nada que não faça referencia a base de dados. (obs.: componente é uma exceção pois faz parte da regra/lógica de negócio e que não acessa base de dados – é desenhado para que seja realizada a funcionalidade de negócio).

Estrutura na Ferramenta Enterprise Architect Como exemplo pois essa estrutura está evoluindo como toda a arquitetura do projeto

Esteriotipos da UML

Padrão de Cores

Padrão de Nomes para Funcionalidade Pesquisar = buscar, listar, verificar, validar.... Excluir = deletar, apagar, remover.... Alterar = modificar, atualizar, editar.... Incluir = inserir, criar, cadastrar.... Calcular=somar, sumarizar.... Fechar, Processar são contextos genéricos devem ser reavaliados. Padrão de Nome para esteriotipos da UML: SV = serviço BT = batch CP = componente FL=fluxo Possíveis Exceções: quando fogem do contexto de realização do objetos???

Modelo de Desenho - Diagrama Entidade Realizado

Modelo de Desenho - Diagrama Classe Realizado

Próximo Passo: Diagrama de Atividades Swinlaines, condição, etc...

Diagrama de Atividades Atentar-se para a navegação dos campos; Atentar-se para a regra de negócio; NÃO PENSAR em programação; Não entrar em detalhes de programação; Não generalizar as atividades conforme exemplos abaixo:

Próximo Passo: Como desenhar? Todo esteriotipo utilizado deve ser mencionado o evento disparado para Fluxo (em casos de on show, on exit, ....) ‏ ou a navegação dos campos para serviço, componente, batch devem estar coerentes com a chamada de ENTRADA do esteriotipo invocado ou com a proria tabela do modelo de análise.

Como desenhar Serviço? Regras: Serviços são reutilizados; Só poderá ser acessado informação de tabela através do serviço correspondente; Caso não exista serviço para acesso a tabela poderá ser feita a referencia direta; A inobservância da regra acima gera erro na utilização da regra de negócio e redundancia acarretando perda do mapeamento do processo; Serviço chama tabela; Tabela nunca chama serviço; Serviço nunca chama fluxo; Componente não chama serviço; Serviço chama componente;

Como desenhar Tela? Regras: Tela chama fluxo; Fluxo chama serviço; Serviço chama tabela; Tabela nunca chama serviço; Serviço nunca chama fluxo; fluxo nunca chama tela; Tela conversa com Tela; Fluxo NUNCA será reutilizado ou reaproveitado – por que???

Como desenhar Componente? Regras: Componentes são reutilizados; Componentes não acessam tabela; Componente são funcionalidades de negócio específicos para realização da regra de negócio;

Como desenhar Batch? Regras: Batch são exceção de serviço; Estão voltados a performance; Estão voltados a lote;

Ferramentas Utilizadas

Dúvidas, sugestões, reclamações .... Google talk: [email_address] 11-80241111