Mostrando postagens com marcador UML. Mostrar todas as postagens
Mostrando postagens com marcador UML. Mostrar todas as postagens

domingo, 30 de março de 2008

Diretrizes: Regras de Negócios

Regras de Negócios
As regras de negócios são declarações de políticas ou condições que devem ser cumpridas.

Tópicos
Explicação

As regras de negócios são tipos de requisitos de como os negócios, incluindo suas ferramentas de negócios, devem operar. Elas podem ser leis e regulamentos impostos ao negócio, mas também expressam a arquitetura e o estilo de negócio escolhidos.

Níveis de Formalismo

As regras de negócios devem ser expressas rigorosa e formalmente para que sejam uma base para automação. Uma alternativa pode ser o uso da Linguagem de Restrição de Objetos (OCL) conforme especificado na Linguagem Unificada de Modelagem. [RUM98]

Exemplo:

É possível expressar um limite para o tamanho da equipe; por exemplo, menos de dez membros em uma equipe. Com a OCL, é possível definir essa regra de negócio com uma invariante:

context Team inv:

    self.numberOfMembers <= 10

Lembre-se que esse tipo de linguagem formal pode ser difícil de interpretar para muitos dos envolvidos; portanto, é preferível um estilo de linguagem mais natural. É possível definir um conjunto de expressões reservadas que são usadas para definir as regras. Essas expressões poderiam ser as mesmas das definidas em [ODL98]:

  • IF
  • ONLY IF
  • WHEN
  • THEN
  • ELSE
  • IT MUST ALWAYS HOLD THAT
  • IS CORRECTLY COMPLETED

Exemplo:

Nessa linguagem menos formal, o exemplo acima poderia ser:

IT MUST ALWAYS HOLD THAT o número dos membros da equipe é menor ou igual a 10.

Categorias de Regras de Negócios

As regras podem ser classificadas de várias formas, embora seja comum separá-las em regras de restrição e de derivação. [ODL98] As categorias podem ser subdivididas posteriormente conforme descrito abaixo:

  • Regras de restrição especificam políticas e condições que restringem o comportamento e a estrutura de objetos. 
  • Regras de estímulo e resposta restringem o comportamento especificando quando e se as condições devem ser verdadeiras para que o comportamento seja disparado. 
  • Regras de restrição de operação especificam as condições que devem ser verdadeiras antes e após uma operação para garantir que a operação seja executada corretamente. 
  • Regras de restrição de estrutura especificam políticas ou condições sobre classes, objetos e seus relacionamentos que não podem ser violados. 
  • Regras de derivação especificam políticas ou condições para deduzir ou calcular fatos de outros fatos. 
  • Regras de dedução especificam que se determinados fatos são verdadeiros, uma conclusão pode ser deduzida. 
  • Regras de cálculo derivam seus resultados pela forma de processar algoritmos, uma variante mais sofisticada de regras de dedução. 

Essa classificação de regras de negócios é prática para explicar quais são as regras de negócios, como localizá-las e como trabalhar com elas. Contudo, elas não são um grupo fixo ao qual é necessário fazer referência sempre. Portanto, nosso template de artefato de regras de negócios não mostra essa classificação; é proválvel que no seu projeto haja outros grupos (de domínio, de usuário ou de produto) que merecem ser exibidos.

Como as Regras de Negócios são Refletidas nos Modelos

Uma regra de negócio afeta a aparência do modelo. Ela também pode afetar as atividades de seqüência no diagrama de atividades, além de afetar as associações entre as entidades de negócios. Não é fácil converter algumas regras diretamente para a aparência de um diagrama; elas devem estar presentes em descrições dos elementos de modelos.

Independentemente, é útil mostrar regras de negócios como notas de texto, vinculadas ao elemento de modelo que elas afetam no diagrama.

Também é útil controlar regras de negócios em Atributos de Requisitos, para fins de rastreabilidade e relatório.

Regras de Estímulo e Resposta

Esse tipo de regra de negócio afeta o fluxo de trabalho de um caso de uso de negócios e pode ser rastreada nos casos de uso de negócios aos quais se aplica. É possível mostrar um caminho condicional ou alternativo através do fluxo de trabalho. Se as ações envolvidas são menos significativas, talvez seja suficiente deixar a avaliação da regra de negócio ser incluída em um estado de atividade.

No modelo de objetos de negócios, uma regra desse tipo poderia, por exemplo, afetar a forma como você descreve o ciclo de vida de uma entidade de negócios ou ser parte da descrição de uma operação em um trabalhador de negócio.

Exemplo:

Em uma organização de gerenciamento de pedidos, é possível encontrar a seguinte regra:

WHEN um Pedido é cancelado

IF um Pedido não é enviado

THEN fechar Pedido.

Essa regra de negócio é refletida mostrando dois caminhos alternativos em um fluxo de trabalho e especificamente usando condições de guarda e decisão em transições de saída.

image

A regra de negócio nesse caso é convertida em um caminho alternativo através do fluxo de trabalho

Regras de Restrição de Operação

Esse tipo de regra de negócio geralmente é convertida em precondições e pós-condições de um fluxo de trabalho ou em um caminho condicional ou alternativo em um fluxo de trabalho. Ele também pode ser uma meta de desempenho ou alguma outra regra não comportamental que deve ser rastreado nos casos de uso de negócios aos quais ela se aplica.

Exemplo:

Em uma organização de gerenciamento de pedidos, é possível encontrar a seguinte regra:

Enviar Pedido ao Cliente

ONLY IF O cliente tiver um endereço de entrega.

image

A regra de negócio é convertida em um caminho alternativo no fluxo de trabalho

Exemplo:

Um outro exemplo de regra de restrição de operação é:

IT MUST ALWAYS HOLD THAT

Todas as pesquisas do cliente devem ser respondidas dentro de 24 horas do seu recebimento

Essa regra de negócio seria convertida em uma meta de desempenho de um caso de uso de negócios. Consulte a seção sobre Meta de Desempenho em Diretrizes: Caso de Uso de Negócios.

Regras de Restrição de Estrutura

Esse tipo de regra de negócio afeta as relações entre instâncias de entidades de negócios. Elas são expressas pela existência de uma associação entre duas entidades de negócios; às vezes como uma multiplicidade na associação. 

Exemplo:

Em uma organização de gerenciamento de pedidos, é possível encontrar a seguinte regra:

IT MUST ALWAYS HOLD THAT

um Pedido se refere a 1 Produto no mínimo.

image

Essa regra de negócio é convertida em uma associação com a multiplicidade de 1..*.

Regras de Dedução

Geralmente, as regras de dedução parecem semelhantes aos tipos de regra de estímulo e resposta, de restrição de operação ou de restrição de estrutura; a diferença é a existência de algumas etapas que precisam ser atingidas para chegar à conclusão. A regra implica um método que precisa ser refletido em um estado de atividade do fluxo de trabalho e eventualmente em uma operação em um trabalhador de negócio ou entidade de negócios.

Exemplo:

Talvez você tenha definido a seguinte regra para determinar o status de um cliente:

Um Cliente é um Bom Cliente IF AND ONLY IF

as faturas não pagas enviadas a esse Cliente têm menos de 30 dias.

image

Essa regra de negócio corresponde a um caminho alternativo através do fluxo de trabalho, e o método prescrito será parte da atividade Avaliar Cliente

Regras de Cálculo

As regras de cálculo são diferentes das regras de dedução; a diferença é que o método é mais formal e semelhante a um algoritmo. Assim como as regras de dedução, esse método precisa ser rastreado em uma atividade no fluxo de trabalho e eventualmente em uma operação em um trabalhador de negócio ou uma entidade de negócios.

Exemplo:

Uma regra de cálculo pode especificar cálculo de valor:

O preço líquido de um Produto IS COMPUTED AS FOLLOWS

preço do produto * (1+porcentagem de imposto/100).

A avaliação do preço líquido poderia ser parte da atividade Enviar Pedido quando você prepara a cobrança a ser enviada com o pedido. Nesse modelo de objetos de negócios, essa regra é convertida em associações e operações.

image

Essa regra precisa ser refletida como um método na operação de cálculo do preço líquido, mas também implica a necessidade de relacionamentos entre classes no modelo. 

Copyright  (c) 1987 - 2001 Rational Software Corporation

Rational Unified Process   

OCL - Object Constraint Language

quinta-feira, 27 de março de 2008

IBM RedBook: Livros gratuitos sobre desenvolvimento com Java | Meio Bit

IBM RedBook: Livros gratuitos sobre desenvolvimento com Java Meio Bit: "Estava procurando por material sobre J2EE, SOA, RUP e UML e sem querer acabei encontrando um pequeno tesouro em material farto, gratuito e bem organizado, com os cumprimentos da IBM. São os RedBooks, 2179 livros publicados (até o momento) em PDF que também podem ser encomendados impressos em papel.
Um dos livros que estou lendo é o Rational Application Developer V7 Programming Guide. O material, obviamente, apresenta as soluções puxando para o lado do Websphere, o equivalente da IBM ao Visual Studio, mas voltado para o Java e integração com ferramentas e processos da Rational. Mas o conteúdo é apresentado de tal forma que mesmo quem não trabalha com essas ferramentas, pode usufruir de capítulos como o o capítulo 6, Rational Unified Process (RUP) e Unified Modeling Language (UML) e o capítulo 18, sobre WebServices e Service-Oriented Architecture (SOA)."

segunda-feira, 22 de outubro de 2007

Exemplo de Diagrama de Classes da UML


Diagrama de Objetos


Mostram um conjunto de objetos e seus relacionamentos em um ponto no tempo, contém objetos e vínculos e são usados para fazer a modelagem da visão de projeto estática de um sistema a partir da perspectiva de instâncias reais ou prototípicas.

Essa visão atende principalmente aos requisitos funcionais do sistema, ou seja, os serviços que o sistema deverá proporcionar aos seus usuários finais.

Os diagramas de objetos só podem ser usados de uma única maneira: para fazer a modelagem de estruturas dos objetos. Ao se utilizar estes diagramas pode-se expor significativamente apenas conjuntos interessantes de objetos concretos ou prototípicos.

Ao se fazer a modelagem de uma estrutura de objetos deve-se:


  1. identificar o mecanismo cuja modelagem você deseja fazer;

  2. para cada um destes mecanismos, identificar classes, interfaces e outros elementos que participam dessa colaboração e seus relacionamentos;

  3. congelar o cenário em determinado momento e representar cada objeto que participa do mecanismo;

  4. expor o estado e os valores dos atributos de cada um desses objetos para a compreensão do cenário; e

  5. expor os vínculos existentes entre esses objetos, representando instâncias de associações entre eles.

Diagrama de Classes


1.0 - Introdução

Na modelagem de sistemas orientados a objetos, são os diagramas encontrados com maior freqüência e mostra um conjunto de classes, interfaces e colaborações e seus relacionamentos.

Os diagramas de classes costumam conter os seguintes itens: Classes, Interfaces, Colaborações, Relacionamentos de dependências, Generalizações e Associação e também pode conter Pacotes ou Subsistemas utilizados para agrupar elementos do seu novo modelo em um conjunto maior.
Basicamente, os diagramas de classes são utilizados para fazer a modelagem da visão estática de um sistema, ou seja, oferecer suporte para os requisitos funcionais do sistema, os serviços que este fornecer aos usuários finais.

Ao se fazer a modelagem estática de um sistema o diagrama de classes será usado de três formas: para fazer a modelagem do vocabulário de um sistema; para fazer a modelagem de colaborações simples e para fazer a modelagem do esquema lógico de um banco de dados.

Na modelagem do vocabulário do sistema, o diagrama de classes visa definir os limites do sistema, o que envolve uma decisão a respeito de quais abstrações fazem parte do sistema e quais estão fora do limite representando essas abstrações e suas responsabilidades.

Uma colaboração é um conjunto de classes, interfaces e outros elementos que funcionam em conjunto proporcionando algum comportamento cooperativo, maior que a soma de todos os elementos e podem ser representados pelo diagrama de classes.

Os diagramas de classes também podem ser usados para fazer a modelagem de esquemas para banco de dados relacionais ou orientado a objetos onde se deseja armazenar informações persistentes, ou seja, que podem ser armazenadas para serem recuperadas posteriormente.

Enquanto os diagramas de Entidade-Relacionamentos clássicos têm seu foco apenas nos dados já os diagramas de classes vão um pouco além permitindo ainda a modelagem de comportamentos.

2.0 - Perspectivas:

Um diagrama de classes pode oferecer três perspectivas, cada uma para um tipo de observador diferente. São elas:



  1. Conceitual (exemplo)
    Representa os conceitos do domínio em estudo.
    Perspectiva destinada ao cliente.

  2. Especificação (exemplo)
    Tem foco nas principais interfaces da arquitetura, nos principais métodos, e não como eles irão ser implementados.
    Perspectiva destinada as pessoas que não precisam saber detalhes de desenvolvimento, tais como gerentes de projeto.

  3. Implementação - a mais utilizada de todas (exemplo)
    Aborda vários detalhes de implementação, tais como navegabilidade, tipo dos atributos, etc.
    Perspectiva destinada ao time de desenvolvimento.

Diagramas da UML


Um diagrama é uma apresentação gráfica de um conjunto de elementos (classes, interfaces, colaborações, componentes, nós etc) e são usados para visualizar o sistema sob diferentes perspectivas.

A UML define um número de diagramas que permite dirigir o foco para aspectos diferentes do sistema de maneira independente. Se bem usados, os diagramas facilitam a compreensão do sistema que está sendo desenvolvido.

A UML define 9 tipos de diagramas, no entanto, não existe uma limitação pois podem ser criados novos diagramas com a finalidade de visualizar os elementos da UML de maneira diferente.

As partes estáticas de um sistema são visualizadas através dos diagramas de classes, objetos, componentes e implantação, já as partes dinâmicas podem ser representadas pelos diagramas de caso de uso, interação (seqüência e colaboração), estados e atividades.

Os diagramas estruturais existem para visualizar, especificar, construir e documentar os aspectos estáticos de um sistema, ou seja, a representação de seu esqueleto e estruturas relativamente estáveis. Os aspectos estáticos de um sistema de software abrangem a existência e a colocação de itens como classes, interfaces, colaborações, componentes e nós, enquanto que os diagramas comportamentais são usados para visualizar, especificar, construir e documentar os aspectos dinâmicos de um sistema que é a representação das partes que sofrem alterações, como por exemplo o fluxo de mensagens ao longo do tempo e a movimentação física de componentes em uma rede.

Tipos de diagramas:

Estruturais/Estáticos:

  1. Diagramas de Classes
  2. Diagramas de Pacotes

Comportamentais/Dinâmicos:

  1. Diagramas de Use Cases
  2. Diagramas de Interação
  3. Diagramas de Sequência
  4. Diagramas de Colaboração
  5. Diagramas de Estado (Statechart)
  6. Diagramas de Atividade