ApresentaçãO Metodologia

1,299 views

Published on

Published in: Education, Career
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
1,299
On SlideShare
0
From Embeds
0
Number of Embeds
14
Actions
Shares
0
Downloads
22
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • Layer 1: Operational systems layer. This consists of existing custom built applications, otherwise called legacy systems, including existing CRM and ERP packaged applications, and older objectoriented system implementations, as well as business intelligence applications. The composite layered architecture of an SOA can leverage existing systems and integrate them using serviceoriented integration techniques. Layer 2: Enterprise components layer. This is the layer of enterprise components that are responsible for realizing functionality and maintaining the QoS of the exposed services. These special components are a managed, governed set of enterprise assets that are funded at the enterprise or the business unit level. As enterprisescale assets, they are responsible for ensuring conformance to SLAs through the application of architectural best practices. This layer typically uses containerbased technologies such as application servers to implement the components, workload management, highavailability, and load balancing. Layer 3: Services layer. The services the business chooses to fund and expose reside in this layer. They can be discovered or be statically bound and then invoked, or possibly, choreographed into a composite service. This service exposure layer also provides for the mechanism to take enterprise scale components, business unit specific components, and in some cases, projectspecific components, and externalizes a subset of their interfaces in the form of service descriptions. Thus, the enterprise components provide service realization at runtime using the functionality provided by their interfaces. The interfaces get exported out as service descriptions in this layer, where they are exposed for use. They can exist in isolation or as a composite service. Level 4: Business process composition or choreography layer. Compositions and choreographies of services exposed in Layer 3 are defined in this layer. Services are bundled into a flow through orchestration or choreography, and thus act together as a single application. These applications support specific use cases and business processes. Here, visual flow composition tools, such as IBM® WebSphere® Business Integration Modeler or Websphere Application Developer Integration Edition, can be used for the design of application flow. Layer 5: Access or presentation layer. Although this layer is usually out of scope for discussions around a SOA, it is gradually becoming more relevant. I depict it here because there is an increasing convergence of standards, such as Web Services for Remote Portlets Version 2.0 and other technologies, that seek to leverage Web services at the application interface or presentation level. You can think of it as a future layer that you need to take into account for future solutions. It is also important to note that SOA decouples the user interface from the components, and that you ultimately need to provide an endtoend solution from an access channel to a service or composition of services. Level 6: Integration (ESB). This layer enables the integration of services through the introduction of a reliable set of capabilities, such as intelligent routing, protocol mediation, and other transformation mechanisms, often described as the ESB (see Resources). Web Services Description Language (WSDL) specifies a binding, which implies a location where the service is provided. On the other hand, an ESB provides a location independent mechanism for integration. Level 7: QoS. This layer provides the capabilities required to monitor, manage, and maintain QoS such as security, performance, and availability. This is a background process through sense and respond mechanisms and tools that monitor the health of SOA applications, including the all important standards implementations of WSManagement and other relevant protocols and standards that implement quality of service for a SOA.
  • ApresentaçãO Metodologia

    1. 1. Mapeamento de Processo de Negócio Apresentação Metodologia
    2. 2. Objetivo Mapeamento de Processos <ul><li>Promover a otimização da plataforma operacional do ambiente empresarial através da abordagem integral dos elementos inseparáveis que o compõe. </li></ul><ul><li>Promover a harmonia e o equilíbrio na abordagem dos elementos. </li></ul><ul><li>Configurar soluções integrais para o atendimento ideal das reais necessidades dos clientes, minimizando recursos e maximizando qualidade. </li></ul>Foco em Processo Grau de Aplicação da Tecnologia Simplicidade (Eficácia e Ineficiência) Excelência (Alta Eficácia e Alta Eficiência) Paralisia (Ineficácia e Ineficiência) Engessamento (Ineficácia e Eficiência)
    3. 3. Visão do Método
    4. 4. Fluxo de Processo
    5. 5. Elementos da Cadeia <ul><li>Evento </li></ul><ul><ul><li>Um evento é algo que ocorre no ambiente externo e que provoca uma ação do processo como conseqüência. </li></ul></ul><ul><ul><li>É um acontecimento referente à ação de alguém, à passagem do tempo ou quando se alcança uma determinada condição. </li></ul></ul><ul><li>Atividade </li></ul><ul><ul><li>É toda atividade humana ou sistêmica contida no contexto do processo. </li></ul></ul><ul><li>Fluxo de Informação ( Input ) </li></ul><ul><ul><li>São as informações, ou seja, um grupo de dados úteis ao processo, utilizadas na atividade, tanto como “insumos” para produção de outputs como “parâmetro ou instrução” para execução da ação. </li></ul></ul><ul><li>Fluxo de Informação (Output) </li></ul><ul><ul><li>São informações que, ou foram produzidas pela ação do processo ou foram recebidas pela ação do processo como inputs e estão sendo destinadas a outras ações. </li></ul></ul>
    6. 6. Elementos da Cadeia (continuação) <ul><li>Regras de Negócio </li></ul><ul><ul><li>São todas as regras, concernentes ao contexto do negócio da empresa, que devem ser aplicadas na execução de uma determinada atividade, independentemente de seu interpretador ou de sua forma de implementação. </li></ul></ul><ul><ul><li>São “balizas”, “parâmetros” que orientam os processadores em relação à execução de determinadas atividades do contexto no negócio. Determinam como executar, quando executar ou quem executa a atividade. </li></ul></ul><ul><li>Sistema de Apoio </li></ul><ul><ul><li>São recursos (equipamentos, sistemas de informação, máquinas, etc.) que suportam e auxiliam a execução da ação. </li></ul></ul><ul><li>Ator (Recurso Humano) </li></ul><ul><ul><li>É a classe de pessoas responsável pela execução da ação. </li></ul></ul><ul><ul><li>Uma atividade pode ser realizada por mais de um processador apesar de, no diagrama, só ser apresentado o primeiro processador, os demais fazem parte da documentação gerada. </li></ul></ul>
    7. 7. Etapas do Processo de Modelagem <ul><li>A metodologia permeia todas as etapas de desenvolvimento de um Sistema de Informação: </li></ul><ul><ul><li>Diagrama de Processo </li></ul></ul><ul><ul><ul><li>Níveis de Observação; </li></ul></ul></ul><ul><ul><li>Modelo Conceitual de Dados; </li></ul></ul><ul><ul><li>Diagrama de Use Case; </li></ul></ul><ul><ul><li>Modelo Lógico de Dados; </li></ul></ul><ul><ul><li>Diagrama de Objetos de Use Case; </li></ul></ul><ul><ul><li>Definição do Sistema de Informação </li></ul></ul>
    8. 8. Decomposição de Processos <ul><li>Processos podem ser decompostos e dessa forma, os detalhes de um processo vão surgindo </li></ul><ul><li>O maior nível de decomposição de um Diagrama de Processo apresenta as atividades de negócio </li></ul><ul><li>Essas atividades representam as atividades humanas efetuadas, que podem ou não possuir apoio sistemico </li></ul>
    9. 9. Decomposição de Atividades <ul><li>Permeando para a Cadeia de Tecnologia, teremos </li></ul><ul><ul><li>Atividades transformam-se em Use Cases </li></ul></ul><ul><ul><li>Fluxos de Informação transformam-se em Modelos de Dados </li></ul></ul><ul><ul><li>Atores das atividades transformam-se em Atores do Use Case </li></ul></ul><ul><li>Geram-se então dois novos diagramas </li></ul><ul><ul><li>Diagrama Entidade Relacionamento </li></ul></ul><ul><ul><li>Diagrama de Use Cases </li></ul></ul>
    10. 10. Decomposição de Diagrama de Use Case <ul><li>Decompondo-se o Diagrama de Use Cases, gera-se o Diagrama de Objetos de Use Case </li></ul><ul><ul><li>Objetos de Interface </li></ul></ul><ul><ul><ul><li>Tipo de classe usada para modelar as interações entre um sistema e os seus atores. </li></ul></ul></ul><ul><ul><ul><li>Representam normalmente, janelas de aplicação, APIs, etc. </li></ul></ul></ul><ul><ul><li>Objetos de Controle </li></ul></ul><ul><ul><ul><li>Tipo de classe usada para encapsular e modelar o fluxo de controle para um dado caso de uso. </li></ul></ul></ul><ul><ul><ul><li>Representam coordenação e sequenciamento de outros objetos. </li></ul></ul></ul><ul><ul><li>Objetos de Entidade </li></ul></ul><ul><ul><ul><li>Tipo de classe usada para modelar informação com grande duração (possivelmente persistente) </li></ul></ul></ul><ul><ul><ul><li>Representam mensagens ou dados. </li></ul></ul></ul>
    11. 11. Modelagem de Sistemas de Informação a partir de “Diagramas de Objeto de Use Case” <ul><li>Objetivos da modelagem e arquitetura de sistemas de informação: </li></ul><ul><ul><li>Modelar uma solução de sistema de informação para atender aos processos de negócio </li></ul></ul><ul><li>A partir dos diagramas de Objeto de Use Case é possível partir para a modelagem e arquitetura dos sistemas de informação necessários para suportar os processos de negócio. </li></ul><ul><li>Para isso temos duas estratatégias de desenvolvimento possível: </li></ul><ul><ul><li>A-Modelagem e arquitetura convencional </li></ul></ul><ul><ul><ul><li>Modelo Cliente/ Servidor </li></ul></ul></ul><ul><ul><li>Modelo em camadas (n tier´s) Internet </li></ul></ul><ul><ul><ul><li>B-Modelagem e arquitetura orientada a serviços (SOA) </li></ul></ul></ul>
    12. 12. Comparação de modelos “Tradicional” e “Orientado a Serviço (SOA)” SOA é uma revolução Organizacional e uma evolução Técnica Modelagem tradicional Modelagem SOA Baseada em componentes Baseada em serviços Modelo procedimental (orientado à invocação de funções) Modelo “colaborativo”/ event-driven (orientado às chamadas para fornecimento/consumo de serviços) Produto mais rígido (build to last) Produto mais flexível (build to change) Ciclos de desenvolvimento longos Desenvolvimento (e deployment) incremental Favorece o desenvolvimento de aplicações isoladas e independentes (“nichos” aplicacionais) Favorece o desenvolvimento de soluções integradas “ Partes” fortemente ligadas (acoplamento forte) “ Partes” fracamente ligadas (acoplamento fraco) Modelo de comunicação orientada ao “objeto” Modelo de comunicação orientado a “mensagens” Foco na implementação (“como faz”) Abstração (“o que faz”)
    13. 13. O que é SOA? <ul><li>SOA é uma abordagem arquitetural corporativa que permite a criação de serviços de negócio interoperáveis que podem ser facilmente reutilizados e compartilhados entre aplicações e empresas. Além disso, é a resposta da indústria de TI para a nova realidade do mercado, que exige agilidade para mostrar resultados e aumentar a produtividade com recursos cada vez mais limitados. </li></ul><ul><li>São objetivos comuns em iniciativas SOA: </li></ul><ul><ul><li>Melhorar o alinhamento entre os objetivos das áreas de negócio e as prioridades das áreas de TI </li></ul></ul><ul><ul><li>Aumentar a agilidade na entrega de novas soluções </li></ul></ul><ul><ul><li>Reduzir custos nas áreas de TI liberando recursos para novos investimentos </li></ul></ul><ul><ul><li>Padronizar a arquitetura de software, gerando produtos mais maduros, com mais qualidade </li></ul></ul><ul><ul><li>Aumentar a competitividade para que os clientes finais usufruam de soluções mais rápidas </li></ul></ul><ul><ul><li>Reduzir os custos de manutenção e aumentar o foco em inovação </li></ul></ul><ul><ul><li>Gerar receita através de novas soluções “as a service” atendendo as necessidades do mercado </li></ul></ul>
    14. 14. Síntese de SOA <ul><li>Foco na funcionalidade e não na sua implementação </li></ul><ul><ul><li>Foco em “o que faz?” e não “como faz” </li></ul></ul><ul><li>Separação “clara” entre o “fornecedor” e o “consumidor” do serviço </li></ul><ul><li>Foco na definição dos “contratos” </li></ul><ul><ul><li>Funcionais – obrigações do “fornecedor” e do “consumidor” </li></ul></ul><ul><ul><li>Não-funcional – SLAs (Service Level Agreements) </li></ul></ul><ul><li>Capacidade de “composição” e “agregação” de “serviços” mais básicos no desenvolvimento de “serviços” mais complexos/completos </li></ul>
    15. 15. Camadas numa implementação SOA
    16. 16. Modelagem e Arquitetura para SOA Metodologia Magna Sistemas <ul><li>A estrutura abaixo, demonstra as principais fases do método, incluindo as influências que conduzem cada fase e os artefatos produzidos. O principal artefato manipulado pelo método é o Modelo de Serviço. </li></ul>
    17. 17. Modelagem e arquitetura para SOA Fluxo de trabalho <ul><li>O fluxo de trabalho contempla desde a análise de transformação do negócio até a realização </li></ul>

    ×