UML Disciplina: Orientação a Objetos

(1)

Instituto Federal de Mato Grosso do Sul Campus Aquidauana

Tecnólogo em Sistemas Para Internet

UML

Disciplina: Orientação a Objetos

Prof. Me. Pedro Henrique Neves da Silva pedro.silva@ifms.edu.br

Técnico em Informática

(2)

Introdução

O que é a UML?

• É uma linguagem padrão de notação de projetos;

• Especifica, visualiza e documenta os elementos de um sistema OO;

• UML significa Unified Modeling Language, ou Linguagem de Modelagem Unificada de projetos orientados a objetos.

(3)

Introdução

É importante:

• serve como linguagem para expressar decisões de projeto que não são óbvias ou que não podem ser deduzidas do código;

• provê uma semântica que permite capturar as decisões estratégicas e táticas;

• provê uma forma concreta o suficiente para a

compreensão das pessoas e para ser manipulada pelas máquinas;

• É independente das linguagens de programação e dos métodos de desenvolvimento.

(4)

Histórico

• Nos anos 90, conhecida como a época da “guerra dos métodos”, vários métodos coexistiam com notações muitas vezes conflitantes entre si.

• Dentre estes, os mais conhecidos eram:

• OMT (Object Modelling Technique) de Rumbaugh;

• Método de Booch;

• OOSE (Object Oriented Software Engineering) de Jacobson;

• Em 1995, Rumbaugh e Booch fundiram seus métodos criando o Modelo Unificado;

• Jacobson juntou-se a eles mais tarde e seu método OOSE foi incorporado à nova metodologia;

(5)

Histórico

• Na década de 90, surge uma organização importante no mundo dos objetos a OMG (Object Management Group), uma entidade sem fins lucrativos onde participam empresas e acadêmicos para definirem padrões de tecnologias OO;

• Primeira versão da UML foi aceita em 1997;

• Em março de 2003, a OMG lançou a versão 1.5;

• Em outubro de 2004, a OMG lançou versão 2.0;

(6)

Análise e Projeto Orientado a Objetos

• Diferentemente da análise e projeto estruturados, na orientação a objetos o processo a ser informatizado é visto como um conjunto de objetos que interagem para realizar as funções.

• As vantagens do modelo OO são:

• maior grau de abstração;

• maior encapsulamento;

• modelos apoiados em conceitos do mundo real;

• reutilização (reusabilidade)

(7)

Objetos

• É uma abstração que representa uma entidade do mundo real;

• Pode ser algo concreto ou abstrato;

• Um objeto num sistema possui três propriedades:

• Estado: definido pelo conjunto de propriedades do objeto (os atributos) e de suas relações com os outros objetos;

• Comportamento: como um objeto responde às solicitações dos outros e tudo mais o que um objeto é capaz de fazer;

• Identidade: significa que cada objeto é único no sistema.

(8)

Classe

• Uma classe é uma descrição de um conjunto de objetos com propriedades, comportamento, relacionamentos e semântica comuns;

• Uma classe pode ser vista como um esqueleto/modelo para criar objetos;

(9)

APOO

1. Análise de requisitos: lista de requisitos funcionais e não-funcionais e diagrama de Casos de Uso.

2. Levantamento das classes candidatas: montar o diagrama de classes com um levantamento preliminar das classes, com atributos, métodos e relações (quando possível).

3. Estudo da interação entre objetos: diagramas de interação.

4. Refinamento do diagrama de classes

5. Definição do comportamento de classes com estado através de máquinas de estados e diagrama de atividades

6. Modelo de implantação 7. Modelo de implementação 8. Codificação

(10)

Análise de Requisitos

• Consiste em determinar os serviços que o usuário espera do sistema e as condições (restrições) sob as quais o sistema será desenvolvido e operar.

• Funcionais: lista de serviços que o sistema deve oferecer ao usuário.

• Não funcionais: propriedades e características desejadas do sistema relativas à capacidade de armazenamento, tempo de resposta, configuração, uso (ex. uso intuitivo), confiabilidade, etc.

(11)

Análise de Requisitos

(12)

Casos de Uso

• Casos de uso representam funcionalidades completas para o usuário e não, funcionalidades internas do sistema.

• Outro ponto importante é que o diagrama de casos de uso é um artefato de comunicação entre cliente, usuários e desenvolvedores;

• Por ser extremamente simples e, consequentemente, de fácil compreensão, incentiva a participação do cliente e usuários no processo de desenvolvimento;

• Também serve como um contrato entre a equipe/empresa desenvolvedora e o cliente;

(13)

Casos de Uso

• A coleção de casos de uso representa todos os modos pelos quais o sistema pode ser utilizado pelos atores envolvidos;

• Um caso de uso é uma seqüência de ações realizadas colaborativamente pelos atores envolvidos e pelo sistema que produz um resultado significativo (com valor) para os atores;

• Um ator pode ser um usuário ou o sistema;

(14)

Casos de Uso

Para uma calculadora de linha de comando cujo objetivo é executar expressões aritméticas (ex. -2 + 3*5), o diagrama de casos da figura pode ser considerado adequado.

(15)

Casos de Uso

• O diagrama de casos de uso é apenas um panorama visual das funcionalidades do sistema;

• É necessária uma descrição textual para detalhar os casos de uso.

(16)

Casos de Uso

Nome do caso de uso Efetuar expressões aritméticas básicas

Descrição Permite resolver expressões envolvendo

números inteiros e

reais e as operações básicas de soma, subtração,

multiplicação e divisão sem parênteses.

Ator Envolvido Usuário

Pré-condições Sistema deve estar em execução

aguardando por uma expressão

Pós-condições Expressão aritmética resolvida ou

abandono da expressão pelo usuário.

(17)

Casos de Uso

Fluxo básico

Usuário Sistema

{Solicita expressão}

Solicita a expressão. (A2) Fornece a expressão

{Valida expressão}

Avalia se a expressão é sintaticamente correta (A1)

{Calcula valor}

Calcula o valor da expressão.

{Mostra o resultado}

Informa o resultado da expressão.

{Fim} Fim do caso de uso

(18)

Casos de Uso

Fluxo alternativo

A1: em {Valida expressão} Se o usuário fornecer uma expressão sintaticamente

incorreta, informá-lo sobre o erro e retomar o fluxo

básico em {Solicita expressão}

A2: em {Solicita expressão} O usuário pode decidir encerrar o caso de uso sem

fornecer uma expressão. Nesse caso retomar o fluxo

básico em {Fim}

(19)

Análise de Requisitos

• Portanto, a saída da fase de análise de requisitos é composta por:

• lista de requisitos funcionais e não-funcionais;

• diagrama de casos de uso e definições textuais dos casos.

(20)

Exercício

Arnaldo deseja escrever uma aplicação de controle de tarefas para colocar em seu Palm. As especificações da aplicação são as seguintes:

O cadastro de cada tarefa contém o número da prioridade, representado por um valor real. Isso permite entrar com intervalos intermediários. Além da prioridade, o cadastro deve conter: o nome da tarefa, a data limite de execução (se houver), o percentual já concluído e o detalhamento da tarefa.

Para cada tarefa há uma lista de itens que descrevem sua execução. Para cada item de execução, cadastram-se:

• o percentual correspondente

• a descrição da execução

• a data da execução (quando for concluída)

Quando uma tarefa receber 100% de execução, esta deve ser movida automaticamente para a lista de tarefas concluídas, podendo ser apagada, se

for o caso.

(21)

Exercício

(22)

Exercício

Bruna resolveu desenvolver uma aplicação para controlar as ligações telefónicas de sua casa, a fim de checar se o valor que paga mensalmente está correio. Assim, sempre que desejar, poderá listar as ligações efetuadas num determinado período, contabilizando o valor a pagar.

Para que isso seja possível, toda ligação será feita pelo computador. A cada solicitação de ligação, a aplicação deverá registrar: a data da ligação, a hora da ligação, quantidade de minutos gastos (que deve ser registrado no momento que a ligação for encerrada), o número de pulsos (que deve ser calculado pela aplicação) e o telefone para onde se discou.

A aplicação permitirá o controle de uma agenda de telefones, com número do telefone e nome da pessoa de contato. O usuário poderá escolher, no momento da ligação, se deseja um dos registros da agenda ou se digitará diretamente o número do telefone,

(23)

Exercício

A forma de cálculo dos pulsos considera os seguintes critérios:

- A ligação ao ser completada já conta um pulso. A partir dai, a cada quatro minutos de conversação concluída, cobra-se mais um pulso.

- Cada pulso custa R$0,08 para ligações locais.

Exemplo:

Ligação de 2m - 1 pulso Ligação de 4m30s - 2 pulsos Ligação de 8m - 3 pulsos

- Os finais de semana possuem uma promoção. Cada ligação contabiliza somente um pulso, independente do número de minutos de conversação

(24)

• Continua na próxima aula...