Parte 1 - Padrões de Análisejef/PA1.pdf · Parte 1 Pegue o seu livro de endereços. O que você vê? Se ele for parecido com o meu, você irá ver um monte de endereços, números

Primeira Parte

Padrões de Análise

Osvaldo Kotaro TakaiJoão Eduardo Ferreira

última atualização: agosto 2005

Padrão

Parte

Parte 1

Pegue o seu livro de endereços. O que você vê? Se ele for parecido com o meu, você irá ver um monte de endereços, números de telefone, e endereços estranhos de e-mail... todos ligados a alguma coisa.Normalmente, essa alguma coisa é uma pessoa, mas algumas vezes aparece uma organização. Normalmente eu chamo o Táxi da Cidade, mas não existe uma pessoa em particular com quem eu queira falar – eu apenas quero um táxi.

Parte 2

A primeira tentativa em modelar o livro de endereços poderia ser a seguinte:

Figura 2.1

Pessoa Endereço0..10..* 0..10..*

Endereço de e-mail

0..1

0..*

0..1

0..*

Organização0..*0..1 0..*0..1

0..*

0..1

0..*

0..1

Número Telefônico

0..*

0..1

0..*

0..1

0..*

0..1

0..*

0..1

Parte 3

Mas esse modelo tem uma duplicação que é horrível de se ver. Instintivamente eu vejo uma generalização de pessoa e organização.Este tipo é um caso clássico de conceito sem nome –um que todos conhecem e usam mas que ninguém tem um nome para ele. Eu já vi esse conceito em incontáveis modelos com vários nomes: pessoa / empresa, jogadores, entidade legal, pessoa, entre outros.O termo que o autor prefire é parte.

Parte 4

Figura 2.2

Figura 2.1

Organização

Endereço

Endereço de e-mail

Pessoa

Número Telefônico

Parte 0..* 0..10..* 0..1

0..1

0..*

0..1

0..*0..1 0..*0..1 0..*

Pessoa Endereço0..10..* 0..10..*

Endereço de e-mail

0..1

0..*

0..1

0..*

Organização0..*0..1 0..*0..1

0..*

0..1

0..*

0..1

Número Telefônico

0..*

0..1

0..*

0..1

0..*

0..1

0..*

0..1

Parte 5

A figura define uma parte como supertipo de uma pessoa ou organização.Isso permite que departamentos dentro de uma organização, ou mesmo equipes informais, tenham endereços e números telefônicos.É surpreendente como muitas coisas se relacionam àparte. Você recebe e envia cartas tanto para pessoas quanto para unidades organizacionais; eu posso pagar pessoas e organizações; tanto pessoas quanto organizações realizam ações, tem contas bancárias, registro de taxas.Eu acho que esses exemplos são suficientes para valer a pena esta abstração.

Parte 6

Exemplo: No serviço de assistência à saúde, poderiam ser parte:

Dr. Tom CairnsA equipe da unidade renal do hospital Sta. MariaO Hospital Sta. MariaAutoridade de Saúde do Distrito ParksideO Universidade Real de Física

Introdução aos Naked Objects

Apresentação Prática dos Naked Objects

As ‘melhores práticas’ no projeto de sistemas de negócio contemporâneos dividem uma aplicação em

quatro camadas principais

Apresentação

Aplicação, Processo ou Controlador de Use-Case

Modelo de objetos de domínio

Persistência

O Padrão Naked Objects elimina a camada controlador encapsulando todas as funcionalidades de negócio nos

objetos entidade

Apresentação


Modelo de objetos de domínio

Persistência

E tem uma camada de apresentação genérica que automaticamente reflete o modelo de objetos de domínio

como uma interface de usuário orientada a objetos

Apresentação


Modelo de objetos dedomínio

Persistência

Para um sistema standalone, ou para prototipação, étambém possível autogerar a persistência a partir do

mesmo modelo de domínio

Presentation


Modelo de objetos dedomínio

Persistência

O Padrão Parte

Organização

Endereço

Endereço de e-mail

Pessoa

Número Telefônico

Parte 0..* 0..10..* 0..1

0..1

0..*

0..1

0..*0..1 0..*0..1 0..*

Padrão

Hierarquia Organizacional

Hierarquia Organizacional 0

Associação dos Fabricantes de Café : Organização

Vendas : Organização

Compras : Organização

Vendas de Boston : Organização

Vendas de Londres : Organização


Considere uma empresa multinacional chamada ACM (Aroma Coffe Makers, Inc).Ela possui Unidades Operacionais, as quais são divididas em Regiões, as quais por sua vez são divididas em Divisões, que são divididas em Escritórios de Venda.Podemos modelar essa estrutura simples da seguinte forma:

Unidade Operacional

Região1 0..*1 0..* Divisão1 0..*1 0..* Escritório de Venda

0..*1 0..*1

Figura 2.3


Eu não ficaria contente com este modelo.Se a organização mudar, digamos que a Região seja retirada para deixar a estrutura mais plana, então modelo também terá que ser alterado. O modelo a seguir apresenta um modelo mais simples – um que é mais fácil de resistir a tais mudanças.


Unidade Operacional

Região0..*1 Divisão0..*1 Escritório de Venda

0..*11 0..* 1 0..* 1 0..*

Figura 2.4

Figura 2.3

RegiãoUnidade Operacional

Departamento

Divisão

Restrição:não pode ter um pai.

{self.parent -> isEmpty}

Restrição:o pai deve ser uma unidade operacional.

{x: self.parent x->notEmpty and x.oclType = (Unidade Operacional)}

Restrição :o pai deve ser uma região.

{x: se lf.parent x->notEmpty and x.oclType = Região}

Restrição:o pai deve ser uma d ivisão .

{x: self.pa rent x->notEmpty and x.oclType = Divisão}Organização

0 ..1

0..*

0 ..1

0..*

+pai

+filho

{hierarquia}


O perigo com o relacionamento recursivo utilizado na figura anterior é que ele permite que uma Divisãoseja parte de um Escritório de Vendas.Cuidamos disso definindo subtipos correspondentes aos níveis e colocando restrições nesses subtipos.Se a hierarquia organizacional mudar, devemos alterar esses subtipos e regras.Normalmente, é fácil mudar uma regra que muda a estrutura do modelo, assim, o autor prefere a figura 2.4 ao invés da 2.3.


As hierarquias são estruturas comuns em organizações. Isso porque elas refletem uma técnica natural e comum para o ser humano lidar com complexidade.Modelar uma hierarquia é dessa forma, uma coisa comum, ainda que seja simples e complicada ao mesmo tempo.Fácil porque você pode mostrá-la com uma associação recursiva. Porém a associação recursiva não conta toda a estória. Em muitos casos existe um pai, mas quem está no do topo?


Hierarquia também tem regras, tal como o fato de que você não pode ter ciclos (seu avô não pode ser seu neto)Não existe notação padrão para lidar com isso em UML; o autor usa uma restrição {hierarquia} sobre a associação sugerindo o que está ocorrendo.No entanto, mesmo a restrição {hierarquia} érigorosamente imprecisa. Ela não diz para você qual a diferença entre uma árvore (um no topo) e uma floresta (múltiplos topos).


Você não precisa se limitar a uma única associação hierárquica. Se uma organização tiver estruturas diferentes para o gerenciamento regional vsfuncional, você pode usar duas hierarquias como na figura abaixo.

Organização0..1

0..*+pai regional0..1

+filho regional0..*

0..10 ..*

+filho funcional0 ..* +pai funcional

0..1

{hierarquia}

{hierarquia}


Isso permite que as vendas do escritório de Londres tenham vendas como seu pai funcional e escritório de Londres como seu pai regional.Naturalmente, quanto mais hierarquias mais confuso se tornará o modelo, e é ai que usamos o padrão Responsabilidade.

Exemplo

Uso dos Padrões Parte e Hierarquia Organizacional para Modelar uma

Estrutura Organizacional

Modelando uma Estrutura Organizacional 1

Aparentemente, nós nos familiarizamos com estruturas organizacionais desde muito cedo. A hierarquia clássica de gerenciamento aparecem nos organogramas no início de nossas carreiras, mas nós já topamos com esta noção em vários lugares.Então não deve ser surpresa que tais estruturas organizacionais apareçam também e com freqüência nos softwares de negócio.


Imagine uma empresa onde pessoas trabalham em departamentos, os quais são organizados em divisões.

O modelo acima mostra, explicitamente, cada parte da estrutura em classes separadas.

Divisão Departamento0..*1 0..*1 Pessoa0..*1 0..*1


Estruturas explícitas possuem duas desvantagens:Elas não funcionam bem se existirem vários comportamentos comuns entre os tipos de organização.Elas também embutem as categorias da organização atual dentro do projeto.

Se algum “imbecil” decidir adicionar regiões entre divisões e departamentos, você teria que fazer modificações.


Diante desses problemas, a ação óbvia é utilizar o padrão Hierarquia Organizacional criando um supertipo Organização para Divisão e Departamento:

Divisão Departamento0..*1 0..*1

Organização+fi lho

+pai0..1

0..*0..1

0..*

DepartamentoDivisão

{hierarquia}


Agora, utilizamos o padrão Parte para finalizar o modelo da empresa onde pessoas trabalham em departamentos, os quais são organizados em divisões. Lembre-se que Parte tem como subtipo a Organização e Pessoa.

Organização+filho

+pai0..1

0..*

0..1

0..*

Parte

Pessoa

{hierarquia}


Normalmente não existe muita diferença entre associação hierárquica entre organizações e a associação entre pessoas e organizações, assim você pode usar tais associações para o supertipo.

OrganizaçãoPessoa

Parte0..*

0..1

0..*

0..1+fi lho

+pai

{hierarquia}

Organização+filho

+pai0..1

0..*

0..1

0..*

Parte

Pessoa

{hierarquia}


Esta hierarquia é uma boa escolha para muitas organizações e certamente captura muito bem, os organogramas usuais.Mas organizações maiores tendem a ter vários tipos diferentes de ligações entre as partes.Essas ligações podem ser estruturas organizacionais matriciais, onde pessoas são organizadas simultaneamente pelas sua funções e localizações geográficasObviamente, uma maneira de fazer isso é criar uma segunda hierarquia de partes; porém isso pode deixar o modelo confuso. A solução é o padrão Responsabilidade.

Padrão

Responsabilidade

Responsabilidade 1

Se você estiver lidando com uma organização com uma hierarquia simples, ou até dupla, então o padrão Hierarquia Organizacional é a maneira mais simples de lidar com isso.No entanto, organizações crescem além disso. Normalmente você encontra muitos relacionamentos diferentes entre as partes, todas com seus próprios significados.Se sua hierarquia começar a procriar feito coelhos que tomaram “viagra”, então é hora de conhecer o padrão Responsabilidade.

Tipo de Res ponsabi lidade

Res ponsabi lidade

1

0..*0..*

1

Parte

1

0..*+filho 0..*

+pai

1

Responsabilidade 2

OUTipo de

Responsabilidade

Responsabilidade

0..*

1

0..*

1

Parte

10..*

10..*

0..*

0..*

1

1

+pai

+filho

Responsabilidade 3

Este padrão utiliza um tipo de relacionamento para fornecer a flexibilidade necessária.Cada instância de responsabilidade representa uma ligação entre duas partes, o tipo de responsabilidadeindica a natureza dessa ligação. Isso permite que você manipule qualquer número de relacionamentos organizacionais.

Responsabilidade 4

R1 : Responsabilidade R2 : Responsabilidade

Vendas Boston : Parte

Nova Inglaterra : Parte Vendas : Pa rte

Regional : Tipo de Responsabilidade

tipo Funcional : Tipo de Responsabi lidade

tipo

filho filho

pai pai

Exemplo de uma instância do diagrama mostrando Vendas Boston como filho de Nova Inglaterra sob a estrutura Regional e como filho de Vendas sob a estrutura Funcional.

Tipo de Res ponsabi lidade

Res ponsabi lidade

1

0..*0..*

1

Parte

1

0..*+filho 0..*

+pai

1

Uma Instância

Responsabilidade 5

Você pode usar Responsabilidades para fornecer comportamento navegacional similar ao que você tem com a Hierarquia Organizacional.A principal diferença é que a maioria deste comportamento é agora qualificado pelo tipo de responsabilidade.Assim, ao invés de dizer “Quem são os pais de Vendas de Boston” você diz “Quem são os pais da Regional das Vendas de Boston”.O Padrão Responsabilidade tende a encorajar variações mais complicadas, a mais significativa éusar o nível de conhecimento para capturar regras sobre quais tipos de partes podem ser conectados.

Padrão

Variação de Responsabilidade com Nível de Conhecimento

Variação de ResponsabilidadeA forma básica de Responsabilidade é muito livre, permitindo organizar qualquer forma de combinação das partes com qualquer tipo de responsabilidade.Embora isso funcione bem em algumas aplicações, as vezes é preciso colocar algumas restrições para limitar as possíveis maneiras de organizar as responsabilidades.Isso pode ser feito usando um Nível de Conhecimento. O Nível de Conhecimento para Responsabilidade requer um conjunto de tipos de partes, e colocar os tipos de responsabilidades descrevendo os tipos de partes que podem estar conectados.

Variação de Responsabilidade

Parte

Tipo de Parte

0..*

1

0..*

1

Responsabilidadeperíodo de tempo()

0..* 10..*

+pai

1

0..* 10..*+filho

1

Regras de Conexão

0 ..*

1

0 ..*

1+pais permitidos

0..*

1

0..*

1+filhos permitidos

Tipo de Responsabilidadeverifica a validade das responsabilidades()

1

0..*

1

0..*

10..*

10..*

Nível Operacional

Nível de Conhecimento

Variação de ResponsabilidadeAs regras de conexão fornecem uma forma de conhecimento simples e flexível.Nesta forma, cada tipo de responsabilidade contém um grupo de regras de conexão, sendo que cada um define uma associação legal de tipos de pais e filhos.A figura a seguir ilustra um exemplo de como você pode configurar um desses níveis de conhecimento.

doutor : Tipo de Parte

: Regras de Conexão

hospital : Tipo de Parteconsulta : Tipo de Responsabilidade


clínico geral : Tipo de Parte


paciente : Tipo de Parte

cuidar de paciente : Tipo de Responsabilidade

filhos permitidos

paispermitidos

paispermitidos

filhos permitidos

filhos permitidos

paispermitidos

Este exemplo ilustra dois tipos de responsabilidades.

O tipo de responsabilidade consulta permite que clínico geral e doutor dêem consultas em hospitais. O tipo de responsabilidade cuidar de paciente registra que clínico geral éresponsável por pacientes.

Variação de ResponsabilidadeUse o Nível de Conhecimento para verificar as responsabilidades.Sempre que criar uma responsabilidade, a responsabilidade usa seu tipo para verificar se a responsabilidade é válida.O tipo de responsabilidade é o melhor lugar para se fazer essa verificação, porque tipos diferentes de responsabilidades irão definir diferentes regras sobre conectividades.Assim, se você quiser mudar as regras trocando apenas um único objeto, o tipo de responsabilidade éo ponto de troca.

Padrão

Posto

Posto 1

Normalmente, o escopo operacional de uma pessoa –suas responsabilidades – são definidos antes da descrição do trabalho de uma pessoa.Quando uma pessoa deixa o trabalho, o substituto pode herdar todo o conjunto de responsabilidades.Essas responsabilidades estão amarradas ao trabalho ao invés de estarem na pessoa.Podemos lidar com esta situação introduzindo o Posto como um terceiro subtipo de Parte, como ilustra a figura a seguir.

Posto 2

Parte

Pessoa Organização Posto

Responsabilidades inerentes ao trabalho e que são independentes das pessoas que as execute, são anexadas ao posto.Uma pessoa preenche um posto ao ter uma responsabilidade com o posto.A idéia é que a pessoa seja responsável pelas responsabilidades do posto durante o período de tempo em que ele ocupar o posto.

Posto 3

O padrão Posto não deve ser usado a todo o momento. Ele adiciona significativa complexidade ao nível operacional com seu nível extra de indireção.Somente use Posto quando existirem significativas responsabilidades que são estáticas num posto e pessoas mudarem de posto com razoável freqüência.Os Postos não são necessários em modelos em que todas as responsabilidades podem ser anexadas às pessoas.

Padrão

Quantidade

Quantidade 1

A maneira mais comum e a mais simples de registrar medidas num sistema computacional é registrá-las num campo numérico projetado para uma particular medida.

PessoaAltura : NuméricoPeso : NuméricoNível de Glicose no Sangue : Numérico

Quantidade 2

O problema com esta forma de representar é que usar um número para representar a altura ou o peso de uma pessoa não é muito apropriado.

O que significa dizer que minha altura é 1.83, ou que meu peso é 83?

Para que o número faça sentido, precisamos de unidade.Uma maneira de fazer isso é introduzir uma unidade dentro do nome da associação (por exemplo, peso em quilos).A unidade esclarece o significado do número, mas a representação permanece inadequado.

Quantidade 3

Um outro problema com esta técnica é que o registro deve usar unidades corretas para a informação. Se alguém me disser que o seu peso é de 185 libras, o que eu registro?Idealmente um melhor registro, especialmente na medicina, é registrar exatamente o que foi medido –nem mais nem menos. Mesmo uma conversão determinística não segue esse princípio fielmente.

Quantidade 4

Nesse contexto, um conceito mais útil é o da Quantidade.

Quantidadevalor : Númerounidade : Unidade

+, -, *, /, =, <, >()

PessoaAltura : QuantidadePeso : QuantidadeNível de Glicose no Sangue : Quantidade

Quantidade 5

A figura ilustra uma classe de objeto que combina número e unidade, por exemplo, 1.83 metros ou 83 quilos.Quantidade inclui operações aritméticas e relacionais apropriadas. Por exemplo, uma operação de adição permite que uma quantidade seja adicionada de forma tão fácil quanto números, mas verificando as unidades tal que 34 polegadas não são adicionadas à68 quilogramas.Quantidade é um “valor integral” que a interface do usuário pode interpretar e mostrar (uma simples operação de impressão pode mostrar o número e a unidade).

Quantidade 6

Desta forma, quantidade em pouco tempo, torna-se tão útil e tão utilizado quanto um atributo inteiro ou data.Quantidade deve sempre ser usada onde unidades são requeridas.Valores monetários devem também ser representado como quantidades (dinheiro), usando uma moeda como unidade.Com quantidade, você pode facilmente lidar com múltiplas moedas, ao invés de ficar amarrado a uma única moeda.

Quantidade 7

Objetos Dinheiro podem também controlar a representação do montante. Normalmente, problemas de arredondamento ocorrem em sistemas financeiros se números em ponto flutuante são usados para representar valores monetários; quantidades monetárias podem reforçar o uso de números de ponto fixo para o atributo valor.

Padrão

Medida

Medida 1

O objetivo é o de capturar as medidas de um paciente dentro de um ambiente de assistência àsaúde. A maneira óbvia de capturar as medidas de um paciente é representá-las como atributos do paciente. Isso funciona bem se não existirem muitos, mas um hospital pode fazer centenas ou milhares de medidas. Ao definir um atributo para cada um, significa que a pessoa teria que ter milhares de operações – uma interface invariavelmente complexa.

Medida 2

Uma solução para isso é considerar todas esses parâmetros que podem ser medidas (altura, peso, nível de glicose no sangue, entre outras) como instâncias de um tipo de fenômeno

Pessoa Quantidade

Tipo de Fenômeno

Medida0..*1 10..*0..*

1

1 0..* 0..* 10..*

1

Nível Operacional


Medida 3

Agora uma pessoa pode ter muitas medidas, cada uma associada à quantidade de um tipo de fenômeno específico. Uma pessoa agora tem apenas um atributo para todas as medidas e a complexidade de lidar com essas medidas é transferida para a pesquisa de milhares de instâncias de medições e tipos de fenômenos. Uma outra vantagem desta abordagem é que nós podemos agora adicionar novos atributos de medidas para registrar, por exemplo, quem solicitou, quando foi realizado, onde foi realizado, entre outros.

Medida 4

Exemplo: O fato de Martin ter 1.83 metros de altura pode ser representado por uma medida onde a pessoa é o Martin, o tipo de fenômeno é a altura e a quantidade é 1.83 metros.

Padrão

Observação

Observação 1

Da mesma forma que existem muitas declarações quantitativas que podemos fazer sobre um paciente, existe também muitas declarações qualitativasimportantes, tais como gênero, grupo sanguíneo e se tem ou não diabetes.Não podemos usar atributos para essas declarações porque possibilidades são infinitas. Assim, uma construção similar a medida seria útil.

Observação 2

Considere um problema de registrar o gênero de uma pessoa, que tem dois valores possíveis: masculino e feminino.Podemos pensar no gênero como sendo o que nós estamos medindo, e masculino e feminino são seus dois possíveis valores, da mesma forma que um número positivo é uma valor significativo para a altura de uma pessoa.Podemos inventar um novo tipo: observação de categoria, que é similar a medida, mas que tem uma categoria ao invés de quantidade.

Observação 3

Pessoa

Tipo de Fenômeno

Observação0..*1 0..*10..*

11

0..*

Quantidade

Medida

0..*

1

0..*

1

Observação de Categoria

Categoria1

0..*0..*

1

gênero

masculino

Uma pessoa é do gênero masculino

Observação 4

Usando o modelo anterior, podemos dizer que o gênero é a instância do Tipo de Fenômeno e masculino e feminino são instâncias de categoria.Para registrar que uma pessoa é do gênero masculino, nós criamos uma observação com uma categoria masculino e um Tipo de Fenômeno de gênero.

Observação 5

Mas como podemos considerar que certas categorias podem ser usadas apenas para certos tipo de fenômeno?Alta, mediana e baixa podem ser categorias do Tipo de Fenômeno altura, enquanto que A, B, A/B e O podem ser categorias do Tipo de Fenômeno grupo sanguíneo.Isso pode ser feito fornecendo um relacionamento entre Categoria e Tipo de Fenômeno. Uma questão interessante é a cardinalidade desse relacionamento:

O objeto A usado no grupo sanguíneo tem potencial para ligar com outros Tipos de Fenômenos?

Observação 6

Quantidade

Medida

0..*

1

0..*

1


Pessoa

Categoria1

0..*

1

0..*

Tipo de Fenôm eno ????????

????????

Observação1 0..*1 0..*

1

0..*

1

0..*

Observação 7

Resposta: Claro que sim: A nossa classificação de função hepática na escala de Childs-Pugh, possui valores A (razoável), B (moderado) e C (deficiente). Isso dispara a questão: O que entendemos por A:

Se entendermos como sendo uma mera string contendo o caractere ‘A’, então o mapeamento é multivalorado e a categoria é independente do Tipo de Fenômeno. A outra alternativa é tornar o mapeamento univalorado, onde a categoria somente é definida dentro do contexto do Tipo de Fenômeno; isto é, não é A mas o grupo sanguíneo A.

Observação 8

Qual é a diferença?O caso univalorado permite registrar informações úteis sobre categorias, tais como A é melhor que B com relação àfunção hepática, enquanto tal ordem não existe em grupos sanguíneos.

Observação 9

Quantidade

Medida

0..*

1

0..*

1


Pessoa

Categoria1

0..*

1

0..*

Tipo de Fenôm eno 1

0..*


1

0..*

1

0..* 0..*

0..*

0..*

+evidência0..*

+avaliação

1

0..*

Observação 10

Em minhas investigações do processo clínico revelou uma seqüência comum:

1. O paciente chega para o exame2. Evidências são coletadas sobre as condições do paciente3. E o médico faz uma avaliação.

Por exemplo, um paciente pode se queixar de excessiva sede, perda de peso e freqüência urinária (poliúria). Isso pode levar à diabetes.

Observação 11

Duas coisas são importantes no registro de diagnoses.1. Não é suficiente apenas anotar que o paciente tem diabetes;

o médico deve também registrar explicitamente a evidência usada para apresentar este diagnóstico.

2. O médico não faz esse tipo de dedução do nada. O médico deve contar com o conhecimento clínico.

Considere o seguinte: O paciente está sofrendo de perda de peso. Podemos capturar isso dizendo que existe um Tipo de Fenômeno alteração no peso, ligado à Categoria ganho, perda e estável.

Observação 12

Da mesma forma, existe um Tipo de Fenômenodiabetes com Categorias presente e ausente.Claramente podemos registrar o link entre observações colocando um relacionamento recursivo apropriado sobre a observação de diabetes e sua evidência.

Observação0..*

0..*0..*0..*

+avaliação

+evidência

Observação 13

Podemos assim registrar o link entre a perda de peso e diabetes.O Tipo de Fenômeno alteração de peso e a Categoriaperda de peso são ligados apenas quando a observação é realizada.Precisamos de uma maneira de dizer que o baixo peso, que pode existir sem nenhuma observação, está no nível de conhecimento. Esta foi a evidência que obrigou fazer o mapeamento:

de Categoria para Tipo de Fenômeno univaloradoCategoria renomeado para Fenômeno e movida pelo o nível de conhecimento.

Observação 14

Quantidade

Medida

0..*

1

0..*

1


Fenômeno

0..*

1

0..*

1

Pessoa Observação

0..*

0..*

+evidência0..*

+avaliação0..*

1 0..*1 0..*

Tipo de Fenôm eno 0..*1 0..*1

1

0..*

1

0..*Quantidade

Medida

0..*

1

0..*

1


Pessoa

Categoria1

0..*

1

0..*

Tipo de Fenôm eno 1

0..*


1

0..*

1

0..* 0..*

0..*

0..*

+evidência0..*

+avaliação

1

0..*

Renomeado para Fenômeno

Observação 15

Exemplo 1:O fato de uma pessoa ser do grupo sanguíneo A é indicado por uma Observação de Categoria de uma pessoa cujo Fenômeno é grupo sanguíneo A.O Fenômeno grupo sanguíneo A é ligado ao Tipo de Fenômeno grupo sanguíneo.

Exemplo 2:Podemos modelar o baixo nível de óleo de um carro como uma Observação de Categoria do carro.O Tipo de Fenômeno é nível de óleo com possíveis Fenômenos: cheio, OK e baixo. A observação liga o carro ao Fenômeno baixo.

Observação 16

ObservaçãoPessoa 1 0..*1 0..*

Quantidade

Medida

0..*

1

0..*

1


Tipo de Fenômeno

1

0..*

1

0..*

Fenômeno

0..*

1

0..*

1

0..*1 0..*1

Grupo Sanguíneo A

Grupo Sanguíneo

Pessoa ser do Grupo Sanguíneo A

Observação 17

O modelo anterior funciona bem com vários valores de um Tipo de Fenômeno.Mas muitas observações envolvem meramente uma declaração de ausência ou presença ao invés de uma faixa de valores. Doenças são bons exemplos disso:

Diabetes está ou presente ou ausente.

Observação 18

Esta habilidade de registrar explicitamente a ausência de diabetes é importante, mas pode ser lógico registrar também a ausência de perda de peso.

Por exemplo, se um paciente chegar com sintomas de diabetes mas não estiver perdendo peso, então isso poderia contra-indicar diabetes. Isso não implica que o peso estáaumentando ou esteja estável, apenas que não estádecrescendo.

De fato, podemos registrar a ausência de qualquer Fenômeno, particularmente por eliminar diagnoses hipotéticas.Desse modo, o modelo a seguir permite que qualquer categoria de observação tenham presença ou ausência.

Observação 19

Nível Operacional


Pessoa

FenômenoTipo de Fenômeno 1 0..*1 0..*

Observação de Categor ia

Ausência PresençaQuantidade

Medida

0..*

1

0..*

1


1

0..*

1

0..*

Protocolo

1

0..*

1

0..*

Conceito de Observação 1

0 ..*

1

0 ..*

0..*0..*0..*

0..*

+supertipos

Observação 20

O Conceito de Observação é adicionado como um supertipo do Fenômeno.Isso é feito para permitir que diabetes seja um Conceito de Observação sem ligação com qualquer Tipo de Fenômeno.

diabetes

Conceito de Observação

Fenômeno

Observação 21

Exemplo:Registramos o fato de que John Smith tem diabetes pela presença de uma observação de John Smith ligada a Conceito de Observaçãodiabetes.

John Smith

diabetes

Pessoa




Medida

0..*

1

0..*

1


1

0..*

1

0..*

Protocolo

1

0..*

1

0..*


0 ..*

1

0 ..*

0..*0..*0..*

0..*

+supertipos

Observação 22

Foi introduzido um relacionamento de generalização (supertipo / subtipo) de Conceitos de Observação.Isso é muito comum na medicina e tem seu valor porque Observações podem ser realizadas em qualquer nível de generalidade.

Conce ito de Observação0..*0..*0..*

0..*

+supertipos

ObservaçãoSe uma Observação é realizada na Presença do subtipo, então todos os supertipos são também considerados presentes.No entanto, se uma Observação é realizada na Ausência de um subtipo, então isso não implica na a Presença ou na Ausência de supertipos.A Observação de Ausência do supertipo implica que todos os subtipos estão também ausentes.Assim, a presença é propagada para cima na hierarquia de supertipos, enquanto a ausência épropagada para baixo.

Subtipos

Diabetes

diabetes tipo I diabetes tipo II

Supertipo

Pessoa




Medida

0..*

1

0..*

1


1

0..*

1

0..*

Protocolo

1

0..*

1

0..*


0 ..*

1

0 ..*

0..*0..*0..*

0..*

+supertipos

ObservaçãoExemplo:

Diabetes é um Conceito de Observação com dois subtipos: diabetes tipo I e diabetes tipo II.

Uma Observação da Presença de diabetes tipo I em John Smith implica que diabetes está presente para John Smith.Uma Observação da Ausência de diabetes Tipo I não implica na Ausência ou na Presença de diabetes em John Smith.Uma Observação da Ausência de diabetes implica na Ausência de diabetes tipo I ou II em John Smith.Não podemos tirar nenhuma conclusão sobre os subtipos quando existir apenas uma Observação da Presença de diabetes.

Subtipos

John Smith

Diabetes

diabetes tipo I diabetes tipo II

Supertipo

Observação 25

Protocolo:Um importante conceito conhecido no registro de observações é o Protocolo – o método pelo qual as observações são realizadas.Podemos medir a temperatura corporal de uma pessoa de várias formas. Normalmente a temperatura lida por essas técnicas pode ser considerada a mesma; a pesar disso, é vital registrar qual foi a abordagem usada.Uma observação estranha normalmente pode ser explicada entendendo-se a técnica usada.

Observação 26

Dessa forma, na Saúde, a prática aceita é sempre registrar quais testes foram usados quando se registram as observações.Um dos benefícios do Protocolo é que ele pode ser usado para determinar a precisão e sensibilidade de uma medida.Esta informação pode ser registrada como Medida, mas normalmente é é baseada no Protocolo que éusado para a Observação.

Observação 27

Registro de Dualidades TemporaisNormalmente, pode ser aplicado um limite de duração para observações.O final de um período indica quando uma observação deixa de ser válida.Este período é diferente do tempo em que a observação éfeita.Assim, existem dois tipos de registros (que podem ser períodos ou um ponto no tempo) para cada observação:

1. Para registrar o período válido da observação. 2. Quando ela foi registrada.

Observação 28

Um Registro de Tempo permite registrar tanto um período quanto um único ponto do tempo. Muitos eventos possuem o tempo de sua ocorrência separado do tempo de seu registro.

Ponto do Tem poPeríodo de Tempo

Registro de TempoObservação

10..*

0..* 1

0..*

0..*

1

1

+período

+mom ento de registro

Observação 29

Exemplo:Numa consulta em 1 de maio de 1997, John Smith disse ao seu médico que ele teve dor no peito seis meses atrás e que durou uma semana.O seu médico registrou isso como uma Observação com Presençado Conceito de Observação dor no peito, com o registro do período iniciando em 1 de novembro de 1996 e o finalizando em 8 de novembro de 1996.O momento de registro é o ponto do tempo 1 de maio de 1997. Ponto do Tem poPeríodo de Tempo

Registro de TempoObservação

10..*

0..* 1

0..*

0..*

1

1

+período

+mom ento de registro

Pessoa




Medida

0..*

1

0..*

1


1

0..*

1

0..*

Protocolo

1

0..*

1

0..*


0 ..*

1

0 ..*

0..*0..*0..*

0..*

+supertipos

Observação 30

Observação RejeitadaInevitavelmente cometemos enganos quando fazemos observações.No entanto, no caso de registros médicos, não podemos simplesmente apagá-los. Tratamentos podem ter sido realizados com base nesses enganos, e normalmente existem restrições legais.Para manipular esta situação, podemos classificar as observações como observações rejeitadas quando se descobrir que elas não eram verdadeiras.

Observação

Observação Rejeitada0..*

1

0..*

1

Observação 31

Note que a diferença entre a Observação Rejeitada e uma Observação é que era verdadeira mas que não émais. Exemplo:

Uma braço quebrado que foi curado nunca será uma Observação Rejeitada e sua validade é registrada numa data final.Observações Rejeitadas são Observações incorretas e que devem ser ligadas à Observação que a rejeitou.

Ponto do TempoPeríodo de Tempo

Registro de Tempo

Observação Rejeitada

Observação

10..*

10..*

+período

0..* 10..*

+momento de registro

11

0..*

1

0..*

Observação 32

Exemplo:John Smith fez um exame de sangue que indicou um grande volume corpuscular.

Isso pode ser devido a uma anemia perniciosa ou por abuso de álcool.

John Smith informou ao seu médico que ele havia tomado muito pouco álcool.Isso indicou a presença da anemia perniciosa, a qual levou a futuros exames e tratamentos.Seis meses depois o médico descobriu que John Smith havia bebido pesadamente. Esta informação indica que a observação de anemia perniciosa deve ser rejeitada pela observação de abuso alcoólico. A observação rejeitada de anemia perniciosa deve ser mantida para explicar o tratamento realizado.

Observação 33

Observação Ativa, Hipótese e ProjeçãoQuando observações são registradas, muitos níveis de segurança são necessários. Um médico pode estar com um paciente apresentando todos os sintomas clássicos de diabetes.O médico registra o que ele pensa que o paciente provavelmente tem diabetes, mas não pode ter certeza atéque um exame seja realizado e em muitas doenças mesmo um exame não fornece 100% de certeza. Uma abordagem para registrar esse tipo de informação éassociar probabilidades às observações, mas este método não é claro e não parece natural.

Observação 34

A alternativa é usar duas classificações: observações ativas e hipótese.

A distinção é sutil: uma Observação Ativa é aquela com a qual o médico trabalha, provavelmente usando-a como base para tratamento.Uma Hipótese mais provavelmente lida com os exames futuros.

Observação

Hipótese Projeção Observação Ativa

Observação 35

Exemplo:Um paciente com observações da presença de sede, perda de peso e poliúria indica diabetes.No entanto, com apenas estes sintomas, o médico faz uma Hipótese de diabetes e solicita um exame de glicose no sangue em jejum. O resultado que este exame indicar confirmará a hipótese ou a rejeitará.

Observação 36

Ambos os subtipos, Observação Ativa e Hipótese, representam observações do estado atual do paciente.Projeções são observações sobre o que o médico pensa que irá ocorrer no futuro.Freqüentemente, os médicos decidem o tratamento considerando as condições futuras que podem ocorrer.Se a predição é verdadeira, ela é registrada com uma Observação Ativa adicional.

Observação 37

Exemplo:Se um paciente tem reumatismo, ou doença conseqüente da válvula reumática, existe um risco de endocardite.Este risco é registrado como uma projeção de endocardite.Os tratamentos terão como base esta projeção.

Padrão

Faixa

Faixa 1

É muito comum ver comparações onde é verificado se um valor pertence ou não a uma faixa de valores. Faixas são normalmente tratadas por um par de valores.O padrão Faixa usa um único objeto para representar uma faixa como um todo, e então fornece as operações relevantes para verificar se valores pertencem à faixa.

Faixa 2

A idéia básica é muito simples. Você tem uma classe com dois campos que representam o início e o final da faixa.Você também fornece um método pertence que teste para ver se o valor fornecido está ou não dentro da faixa.

<T>

Faixainício : <T>fim : <T>

pertence(<T>) : Boolean

Faixa 2

Uma abordagem simples de adicionar Faixa a um Fenômeno é apresentada no modelo abaixo:

<T>

Faixa Fenômeno0..*

0..1

0..*

0..1

Tipo de Fenômeno1

0..*

1

0..*

Restrição:A faixa do fenômeno de negócio não deve se sobrepor.

Restrição:A faixa do fenômeno de negócio deve cobrir todos os possíveis valores do Tipo de Fenômento de negócio.

Faixa 3

Exemplo:O desvio percentual da receita (DPR) e dividido em quatro categorias:

maior que 5% é bom5% a -5% é OK-5% a -10% é Alerta e menor que -10% é Problema.

Elas podem ser representadas como quatro Fenômenos do Tipo de Fenômeno DPR.

Faixa 4

O Fenômeno bom do DPR tem uma Faixa com nenhum início e fim igual a 5.O Fenômeno OK do DPR tem uma Faixa com início igual a 5 e fim igual a -5.O Fenômeno Alerta do DPR tem uma Faixa com início igual a -5 e fim igual a -10.O Fenômeno Problema do DPR tem uma Faixa com início igual a -10 e nenhum fim.

Padrão

Inventário e Contabilidade

Inventário e Contabilidade 1

Grande parte dos sistemas computacionais comerciais são projetados para rastrear o movimento financeiro da empresa, registrando como o dinheiro éobtido e gasto.A idéia fundamental subjacente ao rastreamento da contabilidade e inventário é que existem várias contas de dinheiro e de bens, e devemos registrar como o dinheiro e bens se movem entre essas contas.


O padrão Inventário e Contabilidade pode ser utilizado como base para o gerenciamento da contabilidade financeira, de inventário ou recursos.O padrão não descreve diretamente o processo, ao invés disso descreve as idéias a partir das quais o processo pode ser construído.


ContaEm muitas áreas é importante manter um registro não apenas do valor atual de alguma coisa, mas também dos detalhes de cada movimento que afeta este valor.Uma conta de banco precisa registrar todos os saques e depósitos; no inventário é necessário registrar os momentos de adição e remoção do itens.Uma Conta é similar ao atributo Quantidade, com Lançamentos dos movimentos de valor.

Contasaldo : Quantidade

Lançamentoquantia : Quantidade

dataMovimento() : Ponto do TempodataRegistro() : Ponto do Tempo

0..*11 0..*Restrição :ba lanço = som a (Lançamento.quantia)


O saldo, que representa o valor atual da Conta, é o resultado final de todos os Lançamentos ligados àConta.Isso não significa que o saldo precise ser recalculado toda vez que for consultado.Valores derivados podem ser guardados em cache, embora o cache possa estar invisível ao usuário da Conta.Com os Lançamentos, um cliente pode também determinar os movimentos ocorridos num período de tempo e a quantia total de depósitos e saques.


O sinal da quantia indica se o Lançamento é um depósito ou um saque.Um extrato é uma lista de todos os Lançamentos que foram realizados na Conta num dado período de tempo.


Exemplos:Eu saquei R$ 100 de minha conta. Isso é representado como um Lançamento com a quantia igual a -100 reais anexado a minha conta corrente.Eu comprei 4 resmas de papel carta padrão na loja. A loja representa esse Lançamento como uma conta de papel carta padrão com quantia -4 resma.Em janeiro eu usei 350 kwh de energia elétrica. Isso érepresentado como um Lançamento de 350 kwh na minha conta de consumo de energia elétrica residencial.


Princípio de Modelagem:

Para registrar a história dos movimentos de um valor, use uma conta para esse valor.


O modelo indica dois pontos do tempo para o Lançamento:

dataMovimento: um indica quando o movimento foi feito.dataRegistro: indica quando o Lançamento foi registrado na conta.

Isso é importante em alterações retroativas.Um preço pode ter mudado entre a dataMovimento e a dataRegistro, de forma que ambas as datas são necessárias

Exemplo:Eu fiz uma refeição no Jae’s Café no dia 1 de abril. A empresa de cartão de crédito recebeu a nota de pagamento em 4 de abril. A dataMovimento do Lançamento é 1 de abril e a dataRegistro é 4 de abril.


Transações:Usar Lançamentos ajuda a manter um registro dos movimentos de uma Conta.Esses movimentos normalmente movimentam um item de uma Conta para outra.Quando eu realizo um saque de minha conta bancária, eu adiciono dinheiro em minha carteira.Quando existem muitos item, não é suficiente registrar as saídas e entradas; devemos também registrar de onde eles vieram e para onde eles irão.As transações ajudam ligando explicitamente um saque de uma conta para um depósito em a outra.


Conta Lançam ento1 0..*1 0..* Transação122 1

Restrição :Soma(Lançam ento.quantia)=0

A abordagem do duplo Lançamento reflete um princípio de contabilidade muito básico de que o dinheiro (ou qualquer coisa que possamos contar) nunca é criado ou destruído, ele meramente move de uma conta para a outra.


Exemplo:Eu uso o meu cartão de crédito para pagar R$ 500 para Boston Airlines por uma passagem aérea. Isso é uma transação que parte da conta cartão de crédito para a conta da Boston Airlines, com a quantia de R$ 500. Mais tarde eu irei fazer uma transação de minha conta corrente para a conta do cartão de crédito para deixar o saldo da conta do cartão de crédito igual a zero.


Em estruturas de contabilidade complexa, nós queremos ter a conta para balanço – isto é, alcançar zero – em vários pontos do ciclo de negócio.Devido a construção do princípio de conservação no modelo, fica fácil encontrar qualquer “furo” no sistema.


Princípio de Modelagem

Quando trabalhar com contas, siga o princípio da conservação. O item que

estiver sendo contado não pode ser criado ou destruído, apenas movido de um lugar para o outro. Isso facilita encontrar e

evitar falhas.


Transações MultipernasO modelo anterior implica que cada transação consiste de um simples saque e de um simples depósito correspondente.Na verdade, podemos ter vários saques e depósitos numa transação.

Digamos que eu tenha recebido R$ 3000 do Megabank e R$ 2000 da Total Telecom. Eu decidi depositar ambos os cheques em minha conta corrente. Meu extrato bancário irá mostrar R$ 5000 de crédito.


Note que embora dois cheques tenham sido depositados em minha conta, um único Lançamento é apresentado.Esta transação é representada pelo modelo de transação multipernas.

Conta Lançam ento Transação

Restr ição:Soma(Lançam ento.quantia)=0

1 0..*1 0..* 2..n 112..n


O número do mapeamento só é limitado pela quantidade de Lançamentos da transação.A regra importante é que os Lançamentos devem bater com o total da transação, mas nenhuma igualdade é necessária entre Lançamentos individuais.Assim, eu posso modelar a situação de minha conta bancária com uma transação que consiste de três Lançamentos:

[conta: conta corrente, quantia: R$ 5000], [conta: Megabank, quantia: (R$ 3000)], [conta: Total Telecom, quantia: (R$ 2000)].

A transação é responsável por assegurar que o dinheiro não seja criado ou destruído.


Exemplo:A Aroma Coffe Makers remove 5 toneladas de caféde Nova York e envia 2 toneladas para Boston e 3 toneladas para Washington. Esta é uma única transação com três Lançamentos:

[conta: New York, -5 toneladas][conta: Boston, 2 toneladas][conta: Washington, 3 toneladas]


O modelo de duas-pernas é um caso particular do modelo multipernas, onde a transação tem apenas duas entradas.Em algumas aplicações o modelo de duas-pernaspredomina, mas eu recomendo a abordagem multipernas porque ele permite maior flexibilidade.


Conta ResumoNum sistema de contas é normalmente útil agrupar contas.Por exemplo, eu posso querer agrupar minha conta do Total Telecom e Megabank numa conta de rendimento de negócio.Similarmente, eu posso querer colocar o aluguel, gastos com alimentação pessoal, gastos com viagens e despesas de escritório na conta despesas de negócio.Este tipo de estrutura pode ser apoiado por uma simples hierarquia de contas detalhes e Resumo.


Conta

TransaçãoConta Detalhe Lançamento 2..n 12..n 11 0..*1 0..*Conta Resumo

+lançamento [abstrato]0..*

0..10..1

0..*

+lançamentos

+componentes [hierarquia]

Importante:Lançamentos são derivados como componentes.lançamentos

Uma conta resumo pode ser composta tanto de conta resumo quanto de conta detalhe.Isso forma uma hierarquia, com contas detalhes como folhas (um exemplo de composite [GoF]).Os Lançamentos de uma conta resumo são derivados dos Lançamentos de componentes de maneira recursiva.


Nós restringimos o sistema para que coloque Lançamentos apenas nas Contas Detalhes e não nas Contas Resumo.As Contas Resumo podem ainda ser tratadas como Contas porque seus Lançamentos são derivados de acordo com os seus componentes, obtidos recursivamente.Esta derivação do mapeamento dos Lançamentos nos permite descrever o atributo saldo e quaisquer operações e atributos que dependem dos Lançamentos, no nível do supertipo.


Exemplo:Eu tenho uma Conta Resumo de viagens aéreas com Contas Detalhe de viagens aéreas de Megabank e de TotalTecom.

Note que o relacionamento entre componentes precisa ser marcado para indicar uma hierarquia.As cardinalidades não reforçam suficientemente esta restrição: Nós não devemos permitir ciclos nesta estrutura.A separação entre Contas Resumo e Detalhes émuito comum em contabilidade, mas não éabsolutamente necessária.


O modelo a seguir ilustra um modelo sem esta distinção.Neste caso pode ser feito um Lançamento em qualquer Conta e todas as Contas podem ser colocadas numa estrutura hierárquica.

LançamentoConta0..*0..*+todosLançamentos

0..*1 0..*1

+LançamentoBase

0..*0..1

0..*0..1

+Componentes [hierarquia]

Considerações

ConsideraçõesExistem vários outros padrões de análise documentados:

PlanningTradingDerivative ContractsTrading Packeges

Existem outros que provavelmente ainda não foram documentados.No entanto, os padrões vistos até agora, deram uma boa idéia do que são os Padrões de Análise.

Documents

Parte 1 - Padrões de Análisejef/PA1.pdf · Parte 1 Pegue o seu livro de endereços. O que você vê? Se ele for parecido com o meu, você irá ver um monte de endereços, números