UML – Casos de Uso_Diag_Classes

Transcript UML – Casos de Uso_Diag_Classes

Universidade Católica de Angola Faculdade de Engenharia UML Frei Joaquim José Hangalo [email protected]

UML



A Unified Modeling Language (UML) é a linguagem mais utilizada atualmente para especificação e projecto de software na abordagem orientada a objectos. A UML é o instrumento que permite a modelagem do software “visualmente”, tornando fácil partir dos requisitos do sistema à implementação de uma forma amigável.

UML



A UML está formalmente em desenvolvimento desde 1994, porém, a UML não é uma ideia que partiu do zero, a UML é uma consolidação de renomadas técnicas retiradas de metodologias já existentes e bastante praticadas até então.



A UML abrange todas as etapas da produção de software, mas principalmente é utilizada para traduzir os requerimentos(requisitos) do sistema (em alto nível e mais próximos do usuário) em componentes codificáveis (mais próximos da aplicação).

UML



Mesmo estando entre essas duas camadas, a UML pretende ser fácil de entender para todos os envolvidos. A UML é uma linguagem, e como tal, é um meio de comunicação. Através de diagramas gráficos é mais fácil discutir e visualizar as ideias e soluções entre a equipa, ou com o usuário. Muito mais simples do que com programas em código.

Diagrama de casos de Uso

Casos de Uso



Modelando ou escrevendo, o principal para entender a importância do Caso de Uso são os objectivos dele:



Definir Escopo



Organizar e dividir o trabalho



Estimar o tamanho do projecto



Direccionar os testes

Escopo do sistema com Casos de Uso



Definir Escopo: Um conjunto de Casos de Uso define o escopo do sistema de uma maneira simples. Se no diagrama aparece um Caso de uso chamado “Plantar Batata”, os usuários não poderão dizer que “plantar couve” está no escopo do sistema.

Organizar e dividir o trabalho:



O Caso de Uso é uma importante unidade de organização do trabalho dentro do projecto, geralmente nas equipes de projecto é comum ouvir que “o Zé está trabalhando no Caso de Uso X e o João está com o Caso de Uso Y”.

Organizar e dividir o trabalho:



A unidade do Caso de Uso divide o trabalho da equipe entre as pessoas, fora isso, é comum dizer que o Caso de Uso está em Análise, em Programação ou em Teste.

Organizar e dividir o trabalho:



Casos de Uso também são entregues separadamente aos usuários em conjuntos divididos em fases ou iterações no projecto. Então, dizemos que a primeira iteração (ou entrega) terá os Casos de Uso X, Y, Z e W e na segunda iteração terá os Casos de Uso T, H, I e J.

Estimar o tamanho do projecto:



O Caso de Uso fornece métricas para definir o tempo de desenvolvimento. Uma das métricas que pode ser aplicada sobre Casos de Uso é a UCP (Use Case Point) que consiste em classificar os Casos de Uso em nível de complexidade e somando todos os Casos de Uso do projecto (e mais alguns factores) você consegue estimar o esforço do projecto em horas. Além do UCP, podem ser aplicadas as técnicas de Pontos de Função (Function Points) que são mais padronizadas e completas.

Direccionar os testes:



Os testes do sistema (essencialmente os funcionais que são os mais importantes) são derivados do Caso de Uso. Essa característica é uma das mais importantes e geralmente é desprezada, pois com Casos de Uso, os testes são planejados no início do projecto e não no fim, diminuindo os riscos. A partir dos Casos de Uso, Casos de Teste são criados para validar o funcionamento do software.

Diagrama de Casos de Uso

• O diagrama de

CASOS DE USO

procura, por meio de uma linguagem simples, possibilitar a compreensão do

comportamento

externo do sistema por qualquer pessoa, através da perspectiva do

usuário

...

• Diagrama mais ABSTRATO • Diagrama mais FLEXÍVEL • Diagrama mais INFORMAL



Olhando para um diagrama de Casos de Uso, pela sua simplicidade, um analista poderá observar rapidamente as funcionalidades envolvidas no sistema, os usuários envolvidos e integrações com sistemas externos. O propósito maior do Caso de Uso é fornecer uma descrição do comportamento do sistema do ponto de vista do usuário.

Diagrama de Casos de Uso

• MAS

extremamente importante

...

• Mapeamento dos

REQUISITOS

• Base para os demais diagramas da UML

Diagrama de Casos de Uso

Objetivos – Funções

• Apresentar uma visão externa geral das funções e serviços que o sistema deverá oferecer aos usuários • Sem se preocupar com o

COMO

• Tenta identificar os tipos de usuários que irão interagir com o sistema, quais os papéis que estes usuários irão assumir e quais funções serão requisitas por cada usuário específico

Diagrama de Casos de Uso

COMPONENTES PRINCIPAIS



A notação básica do diagrama são Atores representados pelos bonequinhos. Uma linha conecta atores aos Casos de Uso informando que o sistema permitirá ao Ator usar o Caso de Uso directamente. Os Casos de Uso são representados por elipses (existem notações alternativas para os elementos, mas essas são as mais usuais).

Diagrama de Casos de Uso

ACTORES

• Representam os papéis desempenhados pelos diversos usuários que poderão utilizar de alguma maneira os serviços e funções do sistema • Normalmente  PESSOAS • Eventualmente  HARDWARE – SOFTWARE que interajam com o sistema

Diagrama de Casos de Uso

ACTORES



um Actor é um PAPEL DESEMPENHADO POR ALGUMA COISA EXTERNA ao sistema (não necessariamente uma pessoa). Até mesmo o tempo pode ser um Actor para tarefas que ocorrem com frequência temporal.

Diagrama de Casos de Uso

ATORES representação



componentes internos do sistema não são Actores:

É comum o analista imaginar que porque sistemas externos podem ser atores, o banco de dados da aplicação que está sendo desenvolvida deve ser um actor também, mas isso é errado, lembre que Actor é um papel de responsabilidade externa ao sistema. O que deve funcionar dentro da responsabilidade do sistema não pode ser extraído como um Actor.



• Hardwares internos do sistema não são Atores: pode se imaginar que um servidor é externo ao sistema, ou uma impressora num Caso de Uso que precise imprimir alguma coisa é externa ao sistema também, porém, esses itens externos ao sistema são componentes que o software pressupõe que existem e cumprirão seu papel. Então, são como os componentes do funcionamento interno do software (como a base de dados da aplicação) e assim sendo, não são Actores.



Alguns tipos de hardwares podem ser Actores, mas somente quando for importante para a análise do sistema destacar a presença desse hardware. Por exemplo, softwares para controles industriais podem ter alguns sensores que indicam algum tipo de problema na linha de produção e disparam algum comportamento (Caso de Uso) no sistema. Este sim pode ser um hardware que é um Actor no sistema, pois é importante destacar isso para o funcionamento do Caso de Uso. Outro hardware que pode ser um Actor seria o aparelho de controlo de ponto (entrada e saída de funcionários) para um sistema de Administração de Pessoal. Ela desempenha um papel no sistema, seria um Actor.



A definição de Actores (e Casos de Uso) não é o controle de acessos da

aplicação: Esse erro também é comum: confundir a definição de Actores com o que os usuários podem ou não fazer dentro do sistema. Não é essa a ideia! A representação do Actor somente destaca o papel que um usuário assume ao usar o Caso de Uso.

Papéis x Utilizadores Neste exemplo, o diagrama de Casos de Uso somente diz que para “Emitir Pedido” o utilizador deverá assumir o papel de “Vendedor”, isso não implica que um usuário que possui o cargo de vendedor na organização não possa “Aprovar Pedido”.



O que consideramos mais importante na definição de Actores é dar nome aos papéis que pessoas assumirão ao utilizar o sistema e informar integrações com sistemas externos. Enfim, em 90% dos casos um Actor será uma pessoa (utilizador do sistema) ou um sistema externo. Isso serve para dar clareza a quem lê o diagrama deixando as coisas o mais simples possível.



é possível definir uma herança entre Actores para estabelecer generalizações de Actores.

Generalização de Actores



A generalização de Atores serve para passar a ideia de algo em comum entre papéis no sistema. Assim, se um Caso de Uso requer um “Vendedor”, vendedores remotos e locais se encaixam no papel pela herança. Essa notação também não é muito comum, pois para pessoal não técnico, o conceito de generalização não é fácil de compreender.

casos de uso

Diagrama de Casos de Uso

CASOS DE USO

• Referem-se aos serviços, tarefas ou funções que podem ser utilizados pelos usuários do sistema • Utilizados para expressar/documentar os comportamentos pretendidos para as funções do sistema

Abrir Conta



A representação do Caso de Uso no Diagrama é simples: a elipse representa uma forma que o sistema se comporta do ponto de vista do Actor. O nome do Caso de Uso é uma forma de elucidar esse comportamento do sistema, assim sendo, o nome do caso de uso define o OBJETIVO do Actor, isto é, o que ele quer fazer no sistema.

Caso de Uso = Objectivo do Actor



Todo o conjunto de Casos de Uso e Actores do sistema organiza o escopo do sistema a respeito dos objectivos que os usuários atingirão quando o sistema estiver pronto.

Todos os Casos de Uso = Escopo



Dar nomes aos Casos de Uso com o objectivo do Actor é a maneira de tornar o diagrama claro para o pessoal menos técnico saber exactamente o que será possível fazer no sistema. A narrativa (texto) do Caso de Uso deve ser consistente com esse objectivo definido pelo seu nome.

Diagrama de Casos de Uso

Narrativa ou documentação do Caso de Uso



existem inúmeros formatos ou templates de preenchimento de uma narrativa de Caso de Uso.



a UML não define o modo como uma narrativa deve ser descrita.

Diagrama de Casos de Uso

• Narrativa • Objectivo • Descrever, através de uma linguagem simples, a função em linhas gerais do caso de uso, quais atores interagem com o mesmo, quais etapas devem ser executadas pelo ator e pelo sistema, quais parâmetros devem ser fornecidos e quais as restrições/validações o caso de uso deve possuir



A narrativa do Caso de Uso é um texto passo a passo sobre as acções que o Actor pode tomar e como o Sistema responderá a esta acção. A narrativa vai então evoluindo, entre acções do Actor e as respostas do Sistema, para o objectivo do Actor, até este ser alcançado.



o Caso de Uso “Emitir Pedido” envolve várias tarefas menores como seleccionar produtos, escolher forma de pagamento, calcular descontos, escolher forma de entrega, porém, tudo isso são partes do objectivo maior que é emitir o pedido.



IMPORTANTE: Na narrativa do Caso de Uso a resposta do sistema deve-se limitar somente ao que o Actor consegue ver. Não é necessário se preocupar em como o sistema obteve ou calculou os dados. Limite-se a escrever o que o sistema responde e não como ele obtém a resposta.

Diagrama de Casos de Uso

ASSOCIAÇÕES

• Representam INTERAÇÕES/RELACIONAMENTOS entre: • ATORES • ATORES e CASOS DE USO • CASOS DE USO e CASOS DE USO • Relacionamentos entre CASOS DE USO: • INCLUSÃO • EXTENSÃO • GENERALIZAÇÃO

Diagrama de Casos de Uso

ASSOCIAÇÕES

• ATOR  CASO DE USO • Demonstra que o ator utiliza-se da função do sistema representada pelo caso de uso – requisitando a execução, recebendo o resultado produzido

Diagrama de Casos de Uso

ASSOCIAÇÕES ATOR



CASO DE USO

Diagrama de Casos de Uso

ASSOCIAÇÕES

•

ESPECIALIZAÇÃO/GENERALIZAÇÃO

• Associação entre Casos de Uso com características semelhantes • A estrutura de um Caso de Uso generalizado é herdada pelos Casos de Usos especializados

Diagrama de Casos de Uso

ASSOCIAÇÕES

•

ESPECIALIZAÇÃO/GENERALIZAÇÃO

Diagrama de Casos de Uso

ASSOCIAÇÕES

•

ESPECIALIZAÇÃO/GENERALIZAÇÃO

Diagrama de Casos de Uso

ASSOCIAÇÕES

•

INCLUSÃO

• Usada quando existe um serviço, situação ou rotina comum a mais de um Caso de Uso • Outros Casos de Uso utilizam-se de um Caso de Uso • “Chamada de Sub-Rotina” • Linha tracejada com texto “<>”

Diagrama de Casos de Uso

ASSOCIAÇÕES - INCLUSÃO

Diagrama de Casos de Uso

ASSOCIAÇÕES

•

EXTENSÃO

• Descrever cenários opcionais de um Caso de Uso • Descrevem cenários que somente ocorrerão em uma situação específica – se uma determinada condição for satisfeita • “<>”

Diagrama de Casos de Uso

ASSOCIAÇÕES - EXTENSÃO

Diagrama de Casos de Uso

EXTRAS GERAIS

•

Notas

• Apresentar texto explicativo

Diagrama de Casos de Uso

EXTRAS GERAIS

•

Pacotes

• Organizar elementos em grupos para serem utilizados na modelagem de sistemas muito extensos – principalmente quando existem vários sistemas ou sub-sistemas integrados • Demonstram os limites de cada sub-sistema e como eles se inter-relacionam

Diagrama de Casos de Uso

EXTRAS GERAIS

•

Pacotes

Diagrama de Casos de Uso

EXTRAS GERAIS

•

Estereótipos

• Permitem a identificação de componentes – permitindo sua diferenciação dando maior destaque no diagrama

Diagrama de Casos de Uso

Exercícios – Estudos de Caso

• Video Club • Gestão de Cursos • Venda de Passagens Aéreas • Clínica Veterinária • Escritório de Advocacia

Diagrama de Casos de Uso

Exercícios – Estudos de Caso

• Controlo de Cinema • Controlo de Clube Social • Locação de Veículos • Leilão via Internet • Controlo de Hotelaria

Diagrama de Casos de Uso

Exercícios – Estudos de Caso

Diagrama de Classes

Introdução



O modelo de casos de uso fornece uma perspectiva do sistema a partir de um ponto de vista externo.



De posse da visão de casos de uso, os desenvolvedores precisam prosseguir no desenvolvimento do sistema.

Aspectos dinâmico e estático

66  

A funcionalidade externa de um sistema orientado a objetos é fornecida através de colaborações entre objetos.

•

Externamente, os atores visualizam resultados de cálculos, relatórios produzidos, confirmações de requisições realizadas, etc.

•

Internamente, os objetos colaboram uns com os outros para produzir os resultados.

Essa colaboração pode ser vista sob o aspecto dinâmico e sob o aspecto estrutural estático.

Modelo de classes

 

O diagrama da UML utilizado para representar o aspecto estrutural estático é o diagrama de classes.

O modelo de classes é composto desse diagrama e da descrição textual associada.



O modelo de classes evolui durante o desenvolvimento do sistema.

•

À medida que o sistema é desenvolvido, o modelo de classes é incrementado com novos detalhes.

Classes

68 

Uma classe representa um grupo de objetos semelhantes.



Uma classe descreve esses objetos através de atributos e operações.



Os atributos correspondem às informações que um objeto armazena.



As operações correspondem às ações que um objeto sabe realizar.

Classes



Uma classe é uma descrição de um conjunto de objectos que partilham os mesmos atributos, operações, relações e semântica

Notação para uma classe



Representada através de uma “caixa” com no máximo três compartimentos exibidos.



Notação utilizada depende do nível de abstração desejado.



Na secção de topo indica-se o nome da classe (que tem que ser único num diagrama), na secção intermédia enumeram-se os atributos da classe, e na secção inferior enumeram-se as operações que são permitidas efectuar sobre os objectos da classe.

classes



Como regra geral de bom senso, de modo a não sobrecarregar os diagramas, é aconselhável não enumerar o conjunto básico de operações que usualmente podem ser aplicadas a todos os objectos de todas as classes, nomeadamente, adicionar, remover , listar e alterar



Estas operações apenas devem ser indicadas caso possuam alguma particularidade específica

Exemplo (classe ContaBancária)

Relações



Em qualquer sistema existem objectos que se relacionam entre si.



Por exemplo, se considerarmos a classe das facturas de uma empresa, o cliente “Abel” relaciona-se com as facturas emitidas em seu nome

Relações



A relação entre objectos é representada através das relações entre as classes.



Existem diferentes tipos de relações,



Aqui serão abordadas algumas que se podem classificar em dois tipos, associações e generalizações.

Associações

 

Para representar o fato de que objetos podem se relacionar uns com os outros, utiliza se a associação.

Uma associação representa relacionamentos (ligações) que são formados entre objetos durante a execução do sistema.

•

embora as associações sejam representadas entre classes do diagrama, tais associações representam ligações possíveis entre objetos das classes envolvidas.

Notação para uma associação



Representada através de um segmento de reta ligando as classes cujos objetos se relacionam.



Exemplos:

Associação



Os intervalos de valores indicados nos extremos da semi-recta indicam, a multiplicidade da associação

 

O intervalo {0..*} significa o intervalo entre entre 0 e infinito, o intervalo {1..1} (que usualmente é abreviado para {1}, isto é, quando o limite inferior é igual ao superior apenas se indica um dos limites) corresponde ao intervalo que apenas contém o valor 1 O exemplo da figura indica que: um cliente pode estar associado a várias (infinitas) facturas, ou a nenhuma, e uma factura necessariamente tem que estar associada a um cliente e a não mais do que um

Multiplicidades



Representam a informação dos limites inferior e superior da quantidade de objetos aos quais um outro objeto pode estar associado.



Cada associação num diagrama de classes possui duas multiplicidades, uma em cada extremo da linha de associação.

Multiplicidade



Uma associação deve ser sempre lida nos dois sentidos

Multiplicidade



A multiplicidade diz sempre respeito ao número de objectos da classe mais próxima que podem estar associados a um objecto da classe do extremo oposto.

Multiplicidades

Nome

Apenas Um Zero ou Muitos Um ou Muitos Zero ou Um Intervalo Específico

Simbologia

1..1 (ou 1) 0..* (ou *) 1..* 0..1

i l ..l

Exemplo (multiplicidade)

Cliente Pedido

1 0..* 

Pode haver um cliente que esteja associado a vários pedidos.



Pode haver um cliente que não esteja associado a pedido algum.



Um pedido está associado a um, e somente um, cliente.

Exemplo (multiplicidade)

Velocista Corrida

2..6

0..* 

Uma corrida está associada a, no mínimo, dois velocistas



Uma corrida está associada a, no máximo, seis velocistas.



Um velocista pode estar associado a nenhuma ou várias corridas.

Conectividade



A conectividade corresponde ao tipo de associação entre duas classes: “muitos para muitos”, “um para muitos” e “um para um”.



A conectividade da associação entre duas classes depende dos símbolos de multiplicidade que são utilizados na associação.

Conectividade X Multiplicidade

Conectividade Um para um Um para muitos 0..1

1 0..1

1 Num extremo Muitos para muitos * 1..* 0..*

0..1

1 * 1..* 0..* * 1..* 0..* No outro extremo

Exemplo (conectividade)

Empregado

0..*

Empregado

0..* 0..1

Departamento Departamento

Projeto

1..*

Um para um Um para muitos Muitos para muitos

Participação



Uma característica de uma associação que indica a necessidade (ou não) da existência desta associação entre objetos.



A participação pode ser obrigatória ou opcional.

• •

Se o valor mínimo da multiplicidade de uma associação é igual a 1 (um), significa que a participação é obrigatória Caso contrário, a participação é opcional.

Nome de associação, direção de leitura e papéis



Para melhor esclarecer o significado de uma associação no diagrama de classes, a UML define três recursos de notação:

• •

Nome da associação: fornece algum significado semântico a mesma.

Direção de leitura: indica como a associação deve ser lida

•

Papel: para representar um papel específico numa associação.

Exemplo (Nome de associação, direção de leitura e papéis)

Agregação



É um caso especial da associação

•

conseqüentemente, multiplicidades, participações, papéis, etc. podem ser usados igualmente



Utilizada para representar conexões que guardam uma relação todo-parte entre si.

Agregação



Numa agregação, um objeto está contido no outro, ao contrário de uma associação.



Onde se puder utilizar uma agregação, uma associação também poderá ser utilizada.

Agregação



Sejam duas classes associadas, X e Y. Se uma das perguntas a seguir for respondida com um sim, provavelmente há uma agregação onde X é todo e Y é parte.

• •

X tem um ou mais Y?

Y é parte de X?

Notação para uma agregação



Representada como uma linha conectando as classes relacionadas, com um diamante (losango) branco perto da classe que representa o todo.



Exemplo:

Composição



Forma ainda mais forte da agregação.



Objetos parte pertencem a um único todo.



Objetos parte são sempre criados e destruídos pelo objeto-todo.



Se o todo deixa de existir, o mesmo acontece com as suas partes.

1 Pedido 1..* ItemPedido

Generalização/Especialização (Herança)



É um relacionamento no qual os objetos especializados (filhos) são substituídos por objetos generalizados (pais);



Graficamente, é representada por linhas sólidas com uma seta em branco apontando para o pai:

Pessoa Fisica Juridica

Exemplos

Professor Pessoa

nome email

Aluno

matricula

Sistema Acadêmico

SistemaAcademico Pessoa

nome email

Professor Aluno

matricula

Locadora de DVD

MinhaLocadora Pessoa

nome email

Funcionario Cliente

registo

DVD

titulo

Locadora de DVD

MinhaLocadora Pessoa

nome email

Funcionario DVD

titulo

Cliente

registo

Campeonato de Futebol

CampeonatoAngolano Pessoa

nome email

Time

nome

Presidente Tecnico Jogador

posicao

...

Classe Associativa



As associações também podem ter atributos, nestas situações (Classes Associativas) cria-se uma classe (unida à associação por uma semi-recta a tracejado) onde se colocam os respectivos atributos.

Classe associativa

104  

É uma classe que está ligada a uma associação, ao invés de estar ligada a outras classes.

É normalmente necessária quando duas ou mais classes estão associadas, e é necessário manter informações sobre esta associação.



Uma classe associativa pode estar ligada a associações de qualquer tipo de conectividade.

Notação para uma classe associativa



Representada pela notação utilizada para uma classe. A diferença é que esta classe é ligada a uma associação.



Exemplo:

Emprego

salário dataContratação

Pessoa

nome telefone endereço 105 * empregado * empregador

Empresa

razãoSocial endereço

106

Associações reflexivas

  

Associa objetos da mesma classe.

•

Cada objeto tem um papel distinto na associação.

A utilização de papéis é bastante importante para evitar ambigüidades na leitura da associação.

Uma associação reflexiva não indica que um objeto se associa com ele próprio.

•

Ao contrário, indica que objetos de uma mesma classe se associam

107

Exemplo (associação reflexiva)

Supervisão supervisor 1

Empregado

* supervisionado

108

Classe Abstrata



São parcialmente implementadas e compostas por pelo menos 1 (em JAVA isso não é imposto) ou mais operações abstratas (operações sem implementação);



Tem como finalidade servir de base para a implementação do polimorfismo;

Classe Abstrata



São identificadas pela palavra abstract e na UML são em itálico;

109  

Não gera instâncias e existem apenas em hierarquia; Uma classe abstrata pode ter subclasses abstratas, mas nos níveis mais baixos (especializados) devem estar classes concretas;

110

Classe Abstrata



Podem herdar de classes abstratas e não abstratas;



Podem possuir dados (atributos);



Uma subclasse de uma classe abstrata só pode ser instanciada se sobrescrever todos os métodos abstratos da superclasse e implementá los.

Interface



É um conjunto de especificações de serviços (operações);



Um serviço tem especificação e implementação;



A especificação define “o que” faz o serviço (operação);



A implementação define “como” o serviço é feito (método);



Uma interface pode ser representada na UML por uma pequena circunferência ligada por um segmento de reta sólido (não pontilhado) a uma classe.

111

112

Interface



Uma interface é uma classe onde todos os serviços possuem apenas especificação (método com apenas assinaturas sem implementação).



Impõe especificação do que uma classe deve oferecer e implementar.



Há semelhanças entre Interface e Classe Abstrata.

113

Interface

 

Uma interface não pode ser instanciada; Interface só possui métodos (exceto construtores). Não possui atributos (em JAVA pode possuir atributos);



Uma classe implementa uma ou mais interface (através da cláusula implements);



Uma classe pode ao mesmo tempo herdar de uma classe e implementar uma interface;

Visibilidade

114

Atributo e Método em A Público (+) Protegido (#) Pacote (default) (Java) Privado (-) Podem ser acedido por A,B,C,D,E A,B,C,D A,B,D A (Maior Encapsulamento)

115

Identificando classes



Um sistema de software orientado a objetos é composto de objetos em colaboração para realizar as tarefas do sistema.

 

Por outro lado, todo objeto pertence a uma classe.

Portanto, quando se fala na identificação das classes, o objetivo na verdade é saber quais objetos irão compor o sistema.

116

Categorias de responsabilidades

  • • •

Costuma-se categorizar os objetos de um sistema de acordo com o tipo de responsabilidade a ele atribuída.

objetos de entidade (a que estudaremos) objetos de controle objetos de fronteira Esta categorização foi proposta por Ivar Jacobson (Jacobson et al, 1992) em uma técnica denominada Análise de Robustez.

117

Objetos de Entidade



Um objeto de entidade é um repositório para alguma informação manipulada pelo sistema.



Esses objetos representam conceitos do domínio do negócio.

 

Normalmente esses objetos armazenam informações persistentes.

Há várias instâncias de uma mesma classe de entidade coexistindo no sistema.

118

Objetos de Fronteira

 

Esses objetos traduzem os eventos gerados por um ator em eventos relevantes ao sistema.

Também são responsáveis por apresentar os resultados de uma interação dos objetos em algo inteligível pelo ator.



Um objeto de fronteira existe para que o sistema se comunique com o mundo exterior.

Objetos de Controle

119  

São a “ponte de comunicação” entre objetos de fronteira e objetos de entidade.

Responsáveis por controlar a lógica de execução correspondente a um caso de uso.



Decidem o que o sistema deve fazer quando um evento externo relevante ocorre.

• •

Eles realizam o controle do processamento Agem como gerentes (coordenadores, controladores) dos outros objetos para a realização de um ou mais caso de uso.

Projecto Exemplo (UML)

Por onde começar?

Identificar os Objetos

Dado Jogo Jogador

Identificar Métodos e Atributos

Dado

numeroDeLados jogarDado() objetivo

Jogo

sorteiarIniciante() mostrarSituacao() iniciar() mostrarVencedor()

Jogador

nome pontos aumentarPontos() jaGanhou()

Qual é a visibilidade?

Dado

- numeroDeLados + jogarDado()

Jogo

# objetivo + sorteiarIniciante() + mostrarSituacao() + iniciar() + mostrarVencedor()

Jogador

+ nome # pontos + aumentarPontos() + jaGanhou()

Relacionamentos entre Classes

Dado

- numeroDeLados + jogarDado()

Jogo

# objetivo + sorteiarIniciante() + mostrarSituacao() + iniciar() + mostrarVencedor()

Jogador

+ nome # pontos + aumentarPontos() + jaGanhou()

Definir Multiplicidade

Dado

1..1

- numeroDeLados + jogarDado()

Jogo

# objetivo + sorteiarIniciante() + mostrarSituacao() + iniciar() + mostrarVencedor() 1..1

2..*

Jogador

0..1

+ nome # pontos + aumentarPontos() + jaGanhou()

Alguma dependência?

Dado

1..1

- numeroDeLados + jogarDado()

Jogo

# objetivo + sorteiarIniciante() + mostrarSituacao() + iniciar() + mostrarVencedor() 1..1

2..*

Jogador

0..1

+ nome # pontos + aumentarPontos() + jaGanhou()

Uma Possível Solução UML

Dado

1..1

- numeroDeLados + jogarDado()

Jogo

# objetivo + sorteiarIniciante() + mostrarSituacao() + iniciar() + mostrarVencedor() 1..1

2..*

Jogador

0..1

+ nome # pontos + aumentarPontos() + jaGanhou() O método jaGanhou precisa saber o objetivo do jogo