Diretrizes:  Transição de Modelos de Negócios para Sistemas

Tópicos

• Introdução
• Modelos de Negócios e Arquitetura de Sistemas
• Modelos de Negócios e Atores para o Sistema
• Trabalhadores de Negócios Automatizados
• Modelos de Negócios e Classes de Entidades no Modelo de Análise
• Interação entre os Trabalhadores de Negócios Convertidos para os Requisitos do Sistema
• Uso do Modelo de Objetos de Negócios para o Planejamento de Recursos
• Tabela de Resumo

Introdução

A abordagem para a modelagem de negócios apresentada no Rational Unified Process inclui uma maneira concisa e simples de gerar requisitos de suporte a ferramentas ou sistemas. Um bom entendimento dos processos de negócios é importante para criar os sistemas certos. Mais valor é agregado se você usa os papéis e as responsabilidades das pessoas, bem como as definições dos "objetos" que serão tratados pelo negócio como base de criação do sistema. É dessa visão mais interna do negócio, capturada em um modelo de objetos de negócios, que você pode ver o link mais direto para o que os modelos do sistema precisam ser semelhantes.

A relação entre os modelos do negócio e os modelos de um sistema de informações de suporte

Modelos de Negócios e Arquitetura de Sistemas

Do ponto de vista da arquitetura, usar modelos de negócios é particularmente útil se você pretende criar um dos seguintes tipos de sistemas:

• Sistemas personalizados para uma ou mais empresas em um tipo determinado de indústria como, por exemplo, bancos e companhias de seguro.
• Uma família de aplicativos para o mercado aberto como, por exemplo, sistemas de gerenciamento de pedidos, sistemas de faturamento e sistemas de controle de tráfego aéreo.

Os modelos de negócios fornecem a entrada para a visão de caso de uso e para a visão lógica da maneira apresentada no modelo de análise. Você também pode localizar os principais mecanismos no nível da análise, denominados mecanismos de análise.

Considere o seguinte:

• Para cada caso de uso de negócios suportado pelo sistema, identifique um subsistema no modelo de análise. Esse subsistema está na camada do aplicativo e é considerado uma primeira iteração do protótipo. Por exemplo, se você tem um processo de Pedido e um processo de Faturamento no modelo de casos de uso de negócios, identifique um subsistema de Pedido e um subsistema de Faturamento na camada do aplicativo do modelo de análise. Você pode considerar Pedido e Faturamento como sistemas separados. É uma questão de escopo. Se você estiver considerando todas as ferramentas de negócios como um sistema com vários aplicativos que compartilham a arquitetura, Pedido e Faturamento seriam subsistemas de aplicativos. Se o escopo fosse para criar apenas um aplicativo de Gerenciamento de Pedidos, o Gerenciamento de Pedidos seria o sistema e a recomendação acima não faria sentido. Isso só faz sentido se o escopo for o que você considera todas as ferramentas de negócios na organização como um sistema.
• Para cada trabalhador de negócios suportado pelo sistema, identifique os casos de uso que representam o que deve ser automatizado.
• Para cada entidade de negócios suportada pelo sistema, identifique as classes de entidades no modelo de análise. Algumas são sugestões a serem consideradas principais mecanismos, as entidades de componentes, no sistema.
• Para clusters de entidades de negócios, um grupo de entidades de negócios usado somente em um caso de uso de negócios ou um grupo de entidades de negócios intrinsecamente relacionadas de outra maneira, crie um subsistema na camada específica do negócio.

Em uma arquitetura de sistema de quatro camadas, os modelos de negócios fornecem a entrada para as duas camadas superiores

Modelos de Negócios e Atores para o Sistema

Para cada trabalhador de negócios, identifique uma sugestão de ator do sistema. Para cada caso de uso de negócios em que o ator de negócios participa, crie uma sugestão de caso de uso de sistema.

Para identificar casos de uso do sistema de informações, comece com os trabalhadores de negócio no modelo de objetos de negócios. Para cada trabalhador, siga estes passos:

• Decida se o trabalhador de negócio usará o sistema de informações.
• Em caso afirmativo, identifique um ator para o sistema de informações no modelo de casos de uso desse sistema. Dê ao ator o mesmo nome do trabalhador de negócio.
• Para cada caso de uso de negócios em que o trabalhador de negócios participa, crie um caso de uso de sistema.
• Repita esses passos para todos os trabalhadores de negócio.

Exemplo:

Com base nos modelos de negócios de um banco, você pode derivar as sugestões de atores do sistema e os casos de uso de sistema.

Trabalhadores de Negócios Automatizados

Se o seu objetivo for criar um sistema que automatize completamente um conjunto de processos de negócios-que é o caso se você estiver criando um aplicativo de comércio eletrônico-por exemplo, não é mais o trabalhador de negócios que se torna o ator do sistema. Em vez disso, é o ator de negócios que se comunicará diretamente com o sistema e atuará como um ator do sistema.

Ao criar um aplicativo desse tipo, você está, de fato, alterando o modo como o negócio é realizado. As responsabilidades do trabalhador de negócios serão movidas para o ator de negócios.

Exemplo:

Ao criar um site de comércio eletrônico para um banco, você estará modificando a maneira como o processo é realizado.

• As responsabilidades do Funcionário serão movidas para o Cliente.

• Crie um ator de sistema Cliente correspondente ao ator de negócios Cliente.

• Remova o ator de sistema Responsável.

• Modifique o caso de uso de sistema Transação Financeira 1 para trabalhar com o ator de sistema Cliente em vez de Responsável.

Trabalhadores de negócios completamente automatizados modificam a maneira como o processo de negócios é realizado, bem como a maneira de localizar os atores de sistema e os casos de uso

Modelos de Negócios e Classes de Entidade no Modelo de Análise

Para cada entidade de negócios, crie uma classe no modelo de análise do sistema

Uma entidade de negócios a ser gerenciada por um sistema de informações corresponderá a uma entidade no modelo de análise do sistema de informações. Em alguns casos, entretanto, pode ser adequado deixar os atributos da entidade de negócios corresponderem às entidades no modelo do sistema de informações. Vários trabalhadores de negócios podem acessar uma entidade de negócios. Conseqüentemente, as entidades correspondentes no sistema podem participar de vários casos de uso do sistema de informações.

Exemplo:

As entidades de negócios Perfil do Cliente, Conta e Empréstimo são sugestões de automação.

Interação entre Trabalhadores de Negócios Convertidos em Requisitos de Sistema

Como você deve interpretar um link entre trabalhadores no modelo de negócios? Você deve descobrir como os sistemas de informações podem suportar a comunicação dos trabalhadores. Um sistema de informações pode eliminar a necessidade de transportar informações entre os trabalhadores tornando as informações disponíveis no sistema de informações.

Uso do Modelo de Objetos de Negócios para o Planejamento de Recursos

Se você pretende usar o modelo do objeto de negócios para o planejamento de recursos ou como base de simulação, será preciso atualizá-lo para refletir os tipos de recursos que serão usados. É necessário modificá-lo para que cada trabalhador de negócios e entidade de negócios seja implementado somente por um tipo de recurso. Se a meta é fazer a reengenharia do processo de negócios, na primeira iteração do modelo de objetos de negócios, você não deve considerar os recursos. A tendência, com isso, é que você se concentre nas soluções já existentes, em vez de identificar os problemas que podem ser resolvidos com novos tipos de soluções. Aqui está um exemplo de procedimento a considerar:

• Em uma primeira iteração do modelo de objetos de negócios, trabalhe sem considerar os recursos ou os sistemas que serão usados para implementar o negócio.
• Explique o que pode ser automatizado.
• Explique como a automação pode mudar o processo de negócios e iniciar o esboço de um modelo de casos de uso do sistema e os requisitos do sistema.
• Em uma segunda iteração com o modelo de objetos de negócios, atualize-o para refletir os recursos usados e o que é para ser automatizado.
  • Alguns trabalhadores de negócios serão rotulados como trabalhadores automatizados.
  • Alguns trabalhadores de negócios serão divididos em dois, um automatizado e outro não.
  • As partes de dois trabalhadores de negócios podem ser particionadas em um novo trabalhador automatizado.
  • Partes da responsabilidade de umtrabalhador de negóciospodem ser movidas para fora da organização para que se tornem a responsabilidade de um ator de negócios.

  Exemplo:

No exemplo do banco, decidimos atualizar o modelo de objetos de negócios para usá-lo no planejamento de recursos.

• O trabalhador de negócios Responsável é completamente automatizado e torna-se um Responsável Automatizado. O banco só fará transações bancárias on-line.

• O Especialista em Empréstimos é parcialmente automatizado e dividido em um Especialista em Empréstimos Automatizado e um Especialista em Empréstimos.

Os trabalhadores de negócios são modificados para que reflitam a automação

Tabela de Resumo

A seguinte tabela resume o relacionamento entre os modelos de negócios e os modelos de sistemas.

Copyright  (c) 1987 - 2001 Rational Software Corporation

Rational Unified Process