Aula 05

Prévia do material em texto

Universidade Paulista (UNIP)
Instituto de Ciências Exatas e Tecnológicas (ICET)
Disciplina: Engenharia de Software
Tema: UML
Prof. MSc. Vladimir Camelo
Unified Modeling Language (UML)
Introdução
A Unified Modeling Language (UML), linguagem de modelagem unificada é utilizada para especificar, visualizar, construir e documentar artefatos de um software ou mesmo outros sistemas que não sejam especificamente um software (Larman, 2004).
A criação da UML iniciou oficialmente em outubro de 1994, quando Rumbaugh se juntou a Booch na Rational. O foco inicial do projeto era a unificação dos métodos Booch e OMT. O esboço da versão 0.8 foi lançado em outubro de 1995. Na mesma época Jacobson se associou à Rational com a finalidade de incorporar o OOSE no escopo inicial da versão 0.8, resultando no lançamento da versão 0.9 da UML em junho de 1996.
A UML é a sucessora de um conjunto de métodos de análise orientada a objetos (AOO) que surgiu no final dos anos 80 e início dos anos 90 (Flower & Kendall, 2000). Entre janeiro a julho de 1997, o grupo original se expandiu, passando a incluir virtualmente todos os participantes e colaboradores iniciais:
Andersen Consulting, Ericson, Object Time Limited, Platinum Technology, Ptech, Reich Technologies, Softeam, Sterling Software e outros.
Outras empresas que contribuíram para a definição da UML 1.0:
Digital Equipment Corporationm Hewlett-Packard, I-Logix, Intel-licorp, IBM, ICON Computing, MCI Systemhouse, Microsoft, Oracle, Rational, Texas Instruments, Unisys, etc.
Diagrama de casos de Uso
Existem duas variações que são:
Os diagramas de casos de uso que mostram as interações que ocorrem no sistema por meio notações padrão da UML (formas geométricas).
Os casos de usos descritivos que compõem uma narrativa das funcionalidades do sistema. Formalmente, são descrições narrativas de processos do domínio da aplicação. Documentam a seqüência de eventos de um ator (um agente externo) usando o sistema para completar, do início ao fim, um determinado processo.
Em diagrama de casos de uso uma interação se inicia a partir de um evento externo ao sistema, gerado por um ator;
A seguir podem ocorrer outras interações:
 entre o ator e o sistema, 
 entre o sistema e outros sistemas, 
 entre o sistema e outros atores.
Uma interação tem início, meio e fim.
Os objetivos de um caso de uso são:
Ser compreensíveis para os usuários não especialistas em informática;
Auxiliar a tarefa de análise, especificando funcionalidades e comportamentos do sistema;
Delimitar o sistema;
Servir de base para derivar casos de teste. 
Usando-se UML, os casos de uso modelam os comportamentos adotados no sistema, sem nenhuma preocupação quanto à forma como tais comportamentos serão implementados ou mesmo independente de qual linguagem de programação será utilizada.
Exemplo: Um cliente do banco vai ao caixa automática para retirar dinheiro. Ele indica a quantia desejada e a caixa lhe fornece o dinheiro, através da saída conveniente. Um caso de uso pode incluir variantes em relação ao comportamento principal do sistema. Por exemplo: O cliente do banco especifica uma quantia de dinheiro que a caixa automática não possui; o caso de uso adota uma variante, emitindo uma mensagem, sugerindo que o cliente retire uma quantidade menor, disponível na caixa automática neste momento.
Variantes
Casos de uso que são:
versões especializadas de outros casos de uso (especialização);
extensões de comportamento de casos base (“extend”);
partes de casos de uso, partilhadas entre vários casos de uso (“include”)
Cenários em um diagrama de casos de uso
Um caso de uso pode ser imaginado como um conjunto de cenários, onde cada cenário é uma seqüência de passos a qual descreve uma interação entre um usuário e o sistema.
Os cenários podem ser imaginados como caminhos diferentes utilizados para realizar alguma tarefa, algum requisito.
Dentre outras situações, o importante é prever todas as que realmente são importantes, que possam ocorrer no Cenário Básico.
Atores em diagrama de casos de uso
Entidades externas ao sistema que de algum modo participam da estória do caso de uso e estimulam o sistema com eventos de entrada, ou recebem alguma coisa dele e são designados pelo papel que exercem no caso de uso;
Ex.: Cliente, Operador, etc.
Representação em UML: 
Um caso de uso possui um ator que o inicia, que gera o estímulo inicial, e possivelmente vários atores participantes.
O ator iniciador deve ser indicado explicitamente na descrição do caso de uso.
Algumas categorias típicas de atores incluem:
papeis exercidos por pessoas;
sistemas de computação, outros softwares;
dispositivos elétricos e mecânicos;
Hardware.
Caso de uso descritivo
A descrição do Caso de Uso deverá conter as seguintes informações:
Identificador do Caso de Uso: Identificador numérico do Caso de Uso, caso seja usada uma ferramenta automatizada para sua descrição, este identificador facilitará a busca no dicionário de dados.
Nome: identifica a atividade realizada pelo Caso de Uso.
Descrição: breve descrição do Caso de Uso, identificando seu objetivo.
Evento Iniciador: nome do evento que inicia sua execução.
Atores: identificação dos atores participantes do Caso de Uso.
Pré-condição: condições que iniciam o Caso de Uso.
Seqüência de Eventos: Descrição dos passos principais da seqüência do cenário principal do Caso de Uso.
Pós-Condição: condições após a execução do Caso de Uso.
Extensões: caminhos alternativos do caso de uso, incluindo as exceções de um curso normal de eventos; Exemplo: o usuário entra com a senha errada, o sistema deve enviar uma mensagem de erro.
Inclusões: lista de Casos de Uso usados pelo Caso de Uso corrente.
	Caso de uso descritivo 
	Identificador 
	Valor numérico (ID)
	Prioridade de execução 
	Alta / média / baixa
	Nome do caso de uso 
	Especificar o nome do caso de uso
	Objetivo (Responsabilidade) 
	Descrever de forma sucinta o objetivo do caso de uso
	Descrição 
	Descrever de forma sucinta qual a função do caso de uso
	Ator principal 
	Que interage com o caso de uso
	Ator secundário 
	Que interage com o caso de uso
	Inclusões 
	Includes / uses
	Extensões 
	Extends
	Exceções 
	Caso tenha exceções na execução do processo
	Pré-Condições 
	O que é necessário para que ele funcione
	Fluxo principal 
	Primeira tarefa 
Segunda tarefa
Terceira tarefa
Teste
	Fluxo alternativo 
	Referente a segunda tarefa 
4 realizar novamente
	Pós-condição 
	Após o término da tarefa é exigido alguma realização
	Regras de negócio 
	Regras referente ao negócio
	Freqüência de execução 
	Diária / Semanal / Mensal
	Saída 
	O que o caso de uso deve apresentar
Regras para criação de casos de usos:
Não se deve detalhar muito um determinado caso de uso, isso depende do risco que o mesmo corre, quanto maior o risco, mais detalhes terá o caso de uso.
Trate apenas dos casos de usos mais críticos para o sistema, os casos de uso que são tarefas rotineiras não precisam ser desenvolvidos.
Geralmente são tratados apenas de 10% à 20% dos casos de uso mais críticos do sistema (podem variar dependendo do sistema).
O nome dos casos devem sempre usar verbos.
Relacionamentos em um Diagrama de Casos de Uso
Os relacionamentos em um caos de uso podem ocorrer entre:
Atores;
Atores e casos de uso;
Casos de uso. 
Relacionamento de Associação: 
Relacionamento de Generalização: 
Herança entre atores: 
Relacionamento entre atores e casos de uso:
A seta pode indicar duas alternativas a escolher: ator que inicia o caso de uso ou simplesmente a direção dos dados 
Relacionamento de uso ou include (uses ou include)
Utilizar quando se tem um bloco de comportamento que é o mesmo para vários casos de uso.
Representar o fluxo comum como um outro caso de uso B a ser chamado pelo caso de uso A complexo: A <<uses>>B
Validar Cliente pode ser um caso de uso utilizado por outro caso tal como Abrir Conta alémde Realizar Pedido 
Relacionamento de extensão (extends)
Utilizar quando se tem dois casos de usos que fazem algo parecido, só que o caso de uso B faz alguma coisa a mais que A. B estende A
B representa alguma situação não muito comum que ocorre em A mediante a satisfação de uma pré-condição
Relacionamento de herança (generalização)
relação estrutural entre um caso de uso mais geral e um caso de uso mais específico.
O caso de uso mais geral é uma generalização (abstração) do ou dos casos de uso mais específicos. O caso de uso geral, representa as partes comuns de casos de uso especializados. 
Identificam quais operações o ator (ou o caso de uso) realizam
Auxiliam a especificar as interações e a reutilizar casos de uso 
Tipos de casos de uso
Importância
Primário: Representam os processos principais ou mais comuns (ex.: Comprar Itens)
Secundário: Representam processos menos importantes ou mais raros (ex.: Cadastrar Operadores)
Opcional: Representam processos que podem ser ignorados ou incluídos em futuras versões do sistema (ex.: Solicitar Estoque para um Novo Produto)
Descrição textual
Alto-nível
Breve descrição de um processo, normalmente em duas ou três frases, e deliberadamente vago em decisões de projeto
Criados na fase inicial de requisitos 
Expandido
Descrição passo a passo dos fluxos de eventos de um processo
Durante a fase de requisitos, apenas os casos de uso mais importantes são geralmente escritos nesse formato
Implementação
Essencial
Descrição de um processo em termos de sua motivação e atividades essenciais
Expressos relativamente livres de detalhes de implementação, decisões de projeto, e uso de tecnologias
Real
Descrição de um processo em termos de seu projeto real, comprometido com tecnologias de desenvolvimento, interfaces de entrada e saída, etc. 
Decomposição de Caso de uso
Pode-se dividir sistemas complexos em sub-sistemas e para cada um deles um diagrama de Casos de Uso;
Para mostrar o relacionamento entre esses sub-sistemas, os Casos de Uso são agrupados em Pacotes.
Diagrama de classes
É uma notação gráfica que possibilita modelar e descrever objetos reais ou abstratos de um software e seus relacionamentos por meio de classes; 
Uma classe é uma descrição de um conjunto de objetos que partilham as mesmas propriedades (atributos), comportamentos (operações ou ações), relações e semântica. Um diagrama de classes é uma representação das abstrações importantes do sistema (classes) e das suas relações.
Um objeto é algo com domínios bem definidas e relevante para o problema abordado, que possuí uma identidade, um estado (os dados associados a esses objeto) e um comportamento (ações).
Estado:
modelado por valores de atributos (tamanho, forma, peso, etc.) e por ligações que num dado momento tem com outros objetos (em qualquer sistema existem objetos que se relacionam entre si).
A relação entre objetos é representada por meio das relações entre as classes.
Existem diferentes tipos de relações como, por exemplo, pode-se classificar em dois tipos, associações e generalizações.
Comportamento
um objeto exibe comportamentos invocáveis (por resposta a chamadas de operações) ou reativos (por resposta a eventos);
Identidade
espaço: é possível distinguir 2 objetos mesmo que tenham o mesmo estado; exemplo: pode-se distinguir 2 folhas de papel A4, mesmo que tenham os mesmos valores dos atributos;
tempo: é possível saber que se trata do mesmo objeto mesmo que o seu estado mude; exemplo: se pintar um folha de papel A4 de amarelo, continua a ser a mesma folha de papel.
Objetivo de um diagrama de classes
O diagrama de classes define a arquitetura (estrutura) estática do sistema. Elementos do modelo de classes:
Classes
Relações entre classes:
Associação - relação de utilização
Agregação - relação de constituição
Generalização (herança) - relação de especialização.
Um diagrama de classes serve para modelar o vocabulário de um sistema, do ponto de vista do utilizador (problema) ou do implementador (solução);
Ponto de vista do utilizador (problema): na fase de captura e análise de requisitos, em paralelo com a identificação dos casos de uso;
Vocabulário do implementador (solução): na fase de projeto do sistema (design);
Construído e refinado ao longo das várias fases do desenvolvimento do software, por analistas, projetistas (designers) e implementadores.
Representação de uma Classe
Habitualmente escreve-se o nome da classe no singular (nome de uma instância), com a 1ª letra em maiúscula;
Para se precisar o significado pretendido para uma classe, deve-se explicar o que é (e não é ...) uma instância da classe;
Exemplo: “Um aluno é uma pessoa que está inscrita em um curso ministrado em uma escola. Uma pessoa que esteve no passado inscrita em um curso, mas não está presentemente inscrita em nenhum curso, não é um aluno.”;
Em geral, o nome da classe não é suficiente para se compreender o significado da classe.
Visibilidade de atributos e operações em uma classe
Visibilidade de atributos e operações
Visibilidade:
+ (public) : visível por todos
- (private) : visível só por operações da própria classe
# (protected): visível por operações da própria classe e descendentes (subclasses)
Princípio do encapsulamento: esconder todos os detalhes de implementação que não interessam aos clientes (utilizadores) da classe
Possibilita alterar representação do estado sem afetar clientes
Possibilita validar alterações de estado
Tipos de relacionamentos em um diagrama de classes
Associação : São relacionamentos estruturais entre instâncias e especificam que objetos de uma classe estão ligados a objetos de outras classes. Tipos de associações: uniária, binária, ternárias, etc. A associação pode existir entre classes ou entre objetos. Por exemplo:
Uma associação entre a classe Professor e a classe disciplina (um professor ministra uma disciplina) significa que uma instância de Professor (um professor específico) vai ter uma associação com uma instância de Disciplina.
Dependência - São relacionamentos de utilização no qual uma mudança na especificação de um elemento pode alterar a especificação do elemento dependente. A dependência entre classes indica que os objetos de uma classe usam serviços dos objetos de outra classe
Generalização (herança : simples ou composta) - Relacionamento entre um elemento mais geral e um mais específico. Onde o elemento mais específico herda as propriedades e métodos do elemento mais geral. Como a relação de dependência, ela existe só entre as classes. Um objeto particular não é um caso geral de um outro objeto, só conceitos (classes no modelo a objetos) são generalização de outros conceitos.
Agregação Regular - tipo de associação ( é parte de , todo/parte) onde o objeto parte é um atributo do todo; onde os objetos partes somente são criados se o todo ao qual estão agregados seja criado. Pedidos é composto por itens de pedidos.
Composição - Relacionamento entre um elemento ( o todo) e outros elementos (as partes) onde as parte só podem pertencer ao todo e são criadas e destruídas com ele.