Aula03-MetodologiaOrientadaObjetos

(1)

1

UNIP – Universidade Paulista

POO – Projeto Orientado a Objeto

Material cedido por Antônio G. R. Vidal

Orientação a Objetos

Conteúdo

1. Conceitos de Orientação a Objetos - 6

 Classes  Objetos  Programação

2. Introdução à Linguagem Java - 41

 Conceitos e recursos básicos

3. Projeto de Sistemas Orientados a Objetos – 65

4. Análise de Processos - 81

5. UML -Unified Modeling Language - 98

- 2

Paradigma

“Paradigma é um conjunto de regras

que estabelece fronteiras e descreve

como resolver problemas dentro destas

fronteiras. Os paradigmas influenciam

nossa percepção: ajudam-nos a

organizar e a coordenar a maneira

como olhamos para o mundo...”

Daniel Morris e Joel Brandon

3

Paradigmas

Tradicional: baseia-se na compreensão de um sistema de informação como um conjunto de programas que executam processos sobre dados.

Objetos: vê um sistema de informação como uma coletânea de objetos que interagem entre si, apresentam características próprias, que são representadas pelas suas propriedades (dados) e métodos (processos).

4

Paradigmas

5 Programa Classe Processos Propriedades Métodos Dados Tradicional Objetos

Orientação a Objetos - OO

Análise, projeto e programação orientados a objetos representam uma mudança de paradigma em relação às técnicas clássicas. Objetos são os componentes de um sistema que pertencem a uma classe e possuem:

Encapsulamento Herança Polimorfismo Propriedades Métodos Eventos Mensagens 6 Reutilização Flexibilidade Interoperabilidade

(2)

Bases das Metodologias OO

Diretamente derivada dos conceitos da programação orientada a objetos, a análise e o projeto orientados a objeto definem uma nova maneira de pensar nos problemas utilizando modelos organizados a partir de conceitos do mundo real.

O componente fundamental é a classe de objetos, algo que combina estrutura e comportamento em uma única entidade que pode derivar várias ocorrências ou instâncias de objetos semelhantes.

7

Origens da OO

Linguagens de Programação: Simula,

Smaltalk, Flavours, Objective C, C++,

Java, C#, Object Pascal e outras.

Inteligência Artificial: frames.

Banco de Dados: modelos semânticos

de dados.

8

Expectativas da OO

A tecnologia de objetos oferece a modularidade de seus elementos podendo-se tomar um subconjunto existente e integrá-lo de uma maneira diferente em outra parte do software (sistema aplicativo). Uma aplicação no universo de objetos consiste de um conjunto de blocos de construção auto-contidos e predefinidos que podem ser localizados, reparados ou substituídos.

A construção de código auto-contido propicia o teste completo antes de ser utilizado dentro da lógica de um sistema de informação.

9

Expectativas da OO

Possibilita incrementos graduais de componentes aos já instalados, ampliando a abrangência do sistema.

A combinação de módulos provê inicialmente um nível básico de funcionalidade que é estendido sucessivamente para atender novas situações, em um progresso contínuo da aplicação perante os usuários.

Forte direcionamento à reutilização de artefatos de software já existentes, que são criados uma única vez e disseminados. 10

Objetos Concretos

Coisas Tangíveis Automóvel Eventos Casamento Transações Transação comercial 11

Objetos de Software

Objetos são pacotes de software compostos por dados e procedimentos, que atuam sobre estes dados.

Os procedimentos são também conhecidos como métodos e determinam o comportamento do objeto.

Os dados são também conhecidos como propriedades e determinam o estado do objeto.

Objeto = dado + procedimento Objeto = estado + comportamento

(3)

Objetos de Software

13 Propriedades Dados Variáveis Comportamentos Métodos Procedimentos

Objeto Automóvel

14 Potência Dimensões Preço Mover Parar Buzinar Cor 15

Objetos de Software

16

Todo acesso aos dados ou propriedades de um objeto é feito através da sua interface, que expõe métodos e propriedades a outros objetos.

Encapsulamento

É definido como uma técnica para

minimizar interdependências entre

“módulos” através da definição de

interfaces externas.

17

Interface Mudanças na implementação de uma classe que preserve a interface externa não afetam outras definições de classes.

Interfaces de Classes

Uma Interface descreve um grupo de classes com as mesmas:

Propriedades constantes;

Métodos abstratos;

Uma Interface define a estrutura ou “esqueleto” padrão de uma classe. Não implementa nenhum comportamento real, mas apenas os declara.

Implementa propriedades constantes e métodos abstratos.

(4)

Mensagens

Objetos interagem e comunicam-se

através de mensagens...

19

Emissor

Receptor Andar(...)

As mensagens identificam os métodos a serem executados no objeto receptor e passam-lhes alguma informação.

Métodos

Um determinado método define um

comportamento do objeto.

Tipos básicos de métodos:

Construtor (constrói estados) Destruidor (destrói estados) Transformador (transforma estados) Acesso (fornece estados)

20

Abstração

Focalizar o essencial, ignorar

propriedades acidentais ou específicas.

21

Classe Automóvel Classe Mamífero

A abstração deve sempre ter algum objetivo, pois é o objetivo, ele que determina o que é e o que não é essencial

Classes de Objetos

Uma classe de objetos descreve um

grupo de objetos com:

Propriedades semelhantes; Comportamentos semelhantes; Relacionamentos comuns com outros

objetos. 22

Classes

23 Objetos Instâncias Classe Automóvel Atributos Potência Velocidade Cor... Métodos Acelerar Frear Buzinar... Classificação Instanciação

Classes

24 Classe Pai Super Classe Atributos e métodos da classe. Instanciação de classe Atributos e métodos específicos. Subclasse Subclasse

(5)

Classes vs. Subclasses

Classes:

 Contém informações sobre como uma subclasse

ou um objeto deve ser e como deve se comportar.

 Definem a forma e o comportamento padrão de

subclasses e objetos nela baseados.

Subclasses:

 São instâncias ou ocorrências de uma classe.

 Herdam todas as suas características padrão de

uma classe.

 Além disso, podem possuir características

específicas.

 Podem derivar outras subclasses ou objetos nelas

baseados.

25

Classes vs. Objetos

Classes:

Contém informações sobre como um objeto deve

ser e como deve se comportar.

Definem a forma e o comportamento padrão de

objetos nela baseados.

Objetos:

São instâncias ou ocorrências de uma classe.

Herdam todas as suas características padrão de

uma classe ou subclasse.

Além disso, podem possuir características

específicas.

Não podem derivar outros objetos neles baseados.

26

Relacionamentos entre Classes

Generalização

Herança

Agregação

Polimorfismo

27

Generalização /

Especialização

Generalização é o relacionamento entre

uma classe e uma ou mais versões

refinadas dessa classe.

28

Generalização

Especialização

Generalização é a abstração que permite compartilhar semelhanças entre classes, preservando suas diferenças.

Hierarquia de Classes

Sub Classe A

Classe Derivada Classe DerivadaSub Classe B Classe DerivadaSub Classe C Super Classe

Classe Primitiva

29

Herança

Uma classe derivada ou subclasse herda

as propriedades e métodos da classe

mãe ou superclasse, mas pode:

Adicionar novos métodos próprios; Estender suas propriedades/atributos; Redefinir a implementação de métodos

existentes.

(6)

Herança

31

Sub Classe A

Classe Derivada Classe DerivadaSub Classe B

Subsub Classe 1 Subsub Classe 2

Sub Classe C Classe Derivada Super Classe

Classe Primitiva

Localização de Métodos e Propriedades na Hierarquia

Instância Calcular()

Herança

32 Automóvel Automóvel Esportivo Ferrari Generalização Especialização Propriedades e métodos comuns compartilhados por classes. Propriedades e métodos diferentes de uma subclasse, acrescentando ou alterando características herdadas.

Agregação

Chassi Carroceria Suspensão Motor

Automóvel

33

Um objeto agregado é “construído” por vários componentes

Agregação Fixa

Agregação

34

Pessoa

Empresa Departamento Setor

Um objeto agregado é “feito” de componentes

Agregação Variável

Polimorfismo

Refere-se a:

 Vários comportamentos que um mesmo método

ou operação pode assumir;

 Capacidade de um nome referir-se a objetos

diferentes que executam certas responsabilidades dependendo da mensagem que lhes é passada.

Um nome pode denotar objetos de muitas subclasses diferentes que estão relacionadas por alguma superclasse comum. Assim, um objeto identificado por esse nome tem a capacidade de responder a algum conjunto comum de operações de modos diferentes.

35

Evento vs. Estado

Evento:

Uma ocorrência significativa no mundo real que

deve ser tratada pelos objetos de software.

São atividades específicas e predeterminadas,

provocada pelo usuário ou pelo sistema.

Possuem métodos de objetos associados a eles.

Estado:

Situação de um objeto em um dado instante do

tempo.

(7)

Objetos: propriedades

Características ou atributos dos objetos que são próprias da classe ou subclasse à qual pertencem.

Exemplo: objeto JOSÉ, pertencente à subclasse CLIENTE, da subclasse PESSOA FÍSICA, da classe PESSOA.

 Número: 000001

 CPF: 999.888.777-66

 Nome: José da Silva

 Endereço: Rua da Independência, 709

 Telefone: 3089-9090

 Etc.

37

Objetos: métodos & eventos

Cada objeto reconhece e pode responder a ações denominadas eventos próprios da sua classe/subclasse.

Eventos:

São atividades específicas e predeterminadas

provocada pelo usuário ou pelo sistema.

Possuem métodos associados a eles.

Métodos:

São comportamentos ou procedimentos

associados ao objeto.

Métodos podem existir independentemente de

eventos. 38

Objetos: mensagens

Objetos recebem mensagens de outros

objetos com os quais se relacionam.

Mensagens:

Transferem informações de um objeto para

outro.

São enviadas e recebidas através de

eventos.

São caracterizadas pelos métodos ou

comportamentos dos objetos; tanto do que envia como do que recebe.

39

Objetos: polimorfismo

Usando a mesma mensagem, objetos

podem assumir características e

comportamentos diferentes:

De acordo com contextos específicos; De acordo com eventos específicos; De acordo com eventos e contextos

específicos.

Um objeto pode assumir várias formas:

Propriedades/atributos diferentes; Métodos/comportamentos diferentes.

40

Linguagens Orientadas a Objetos

41

Introdução às Linguagens

Orientadas a Objetos

Conceitos Básicos

(Válidos para C++, C#, Java, J++ e J#)

(8)

Java

43

It’s a jungle out there

So drink your Java

Propaganda do Printer’s Café em Palo Alto CA/USA

Por que surgiu o Java?

Software para eletro-domésticos (1992)

 Mínimo uso de memória

 Mínimo preço

 C++ simplificado

Desenvolvida pela Sun Microsystems Inc. (1994)

Distribuição de software através da Internet (1996)

Novo paradigma de programação:

 Orientada a objeto

 Totalmente aberta

 Independente de plataforma e sistema operacional44

Características do Java da

Sun

Linguagem orientada a objetos Estrutura semelhante ao C++ Gera Bytecodes

 Interpretada

 Alta Performance (JIT)

Segurança

 Endereçamento restrito

 Objetos assinados

Aplicação Carregada Localmente

45

Características do Java da

Sun

Aplicações Personalizadas Independência de Arquitetura Neutra Distribuída

Não há herança múltipla Não há aritmética de ponteiros Inclui tratamento de exceções Implementa “Coletor de Lixo”

46

Arquitetura de Programas Java

47

Java Script

Primeira Versão do Java

Aplicação Interna ao HTML

Interpretada

Não havia o conceito de ByteCodes

48

---{ ... } </script>

(9)

Applet Java

Aplicação executada quando se chama

uma página WWW

É carregada na Máquina Cliente

Restringe-se a uma determinada área

(janela)

49 <applet code=“apl.class” codebase=“http://www.fia.fea.usp.br/vidal align=left width=300 height=100

<param name=tamanho value=30> <param name=fonte value “Arial”> </applet:

Aplicação Java

Aplicação executada “stand-alone”

Exige somente a presença do

interpretador Java (Java Virtual Machine)

50

public class HelloWorldApp {

// Definição do Método MAIN public static void main (String args[]) {

String text = "Hello World!"; System.out.println(text); }

}

Java e Orientação a Objetos

Java suporta as principais características da programação orientada a objeto através de seus construtores de classes e de interfaces. Uma classe é um modelo que descreve um conjunto inteiro de objetos. Em geral, uma classe tem os mesmos membros, isto é, propriedades (dados) e métodos

(procedimentos), que os objetos criados a partir dela.

Uma interface representa uma coleção de comportamentos relacionados. Contém somente declarações de métodos e

propriedades constantes. 51

Criando Classes

Uma classe é composta por métodos

(comportamento) e propriedades

(variáveis que determinam o estado).

52

public class Pessoa {

// Variáveis ou propriedades String Nome;

boolean ComFome; // Métodos

int Comer(int quantidade) { //... }

}

Métodos mudam o estado das variáveis

Exemplo de Definição de

Classe (propriedades)

53

public class Morador... { String nomeCompleto; String apartamento; String telefone; int anoChegada; ....

Exemplo de Definição de

Classe (métodos)

54

public class Morador... {....

public morador(String no, String ap, String te, int an)

{ nomeCompleto = no; apartamento = ap; telefone = te; anoChegada = an; }

public int permanencia() { return (2002 - anoChegada); } }

(10)

Criando Objetos

Criação do Objeto lassie a partir da

classe Cachorro:

55

/*Crie uma variável de referência para a classe Cachorro:*/ Cachorro lassie;

/*Crie um objeto da classe Cachorro e designe-o para a referência:*/ lassie = new Cachorro();

Usando Objetos

Executando um método do objeto

criado:

56

Cachorro.latir();

/* Errado!-não se pode fazer todos

os cachorros latirem.*/ lassie.latir();

/* Correto!pode-se fazer um determinado cachorro latir.*/

Exemplo de Instanciação de

uma Classe

57 ... Morador prof; ....

prof = new morador(“Vidal”, “82”, “3081-0001”,1998); ...

Exemplo de Métodos com

Mensagens

58 ... Morador prof; int p; ....

prof = new morador(“Vidal”, “81”, “3081-0001”,1998); ....

p = prof.permanencia(); // acionando o método // permanencia para o // objeto definido em prof indica o envio de mensagem para o objeto prof

....

Herança

A herança permite a você reutilizar e modificar código já existe.

A herança forma relações hierárquicas entre classes ou interfaces.

A meu ver a mais significativa contribuição do paradigma da Orientação para Objetos para o desenvolvimento de software.

59

Exemplo de Herança

60

import morador;

public class morador_inq extends morador {

int aluguel;

public morador_inq(String no, String ap, String tel, int an, int va) { super(no, ap, tel, an);

aluguel = va; }

(11)

Objeto Composto

61

public class material extends Object { String rotulo; Boolean emCaixa; int anoEstocagem; double valor; Morador proprietario; public material (....) ....

Objeto Composto

62

public class material extends Object {....

public material (String ro, double va, boolean em, Morador pro, int an) {rotulo = ro; valor = va;

emCaixa = em; proprietario = pro; anoEstocagem = an;

}

public int permanencia() { return (2002 - anoEstocagem); }

Pacotes

Um pacote é um grupo de classes

relacionadas.

Eles são semelhantes a bibliotecas em

outras linguagens de programação.

Ajudam a organizar classes,

relacionando-as em categorias com

funcionalidades (métodos e

comportamentos) semelhantes.

63

Pacotes JAVA

java.lang

java.util

java.io

java.awt

java.applet

Para usar um pacote pré-existente, você

deve importá-lo para o seu programa.

64

Pacotes Java

65

Análise e Projeto de Sistemas

Orientados a Objeto

UML - Unified Modeling Language

(12)

Conteúdo

Visão Geral

UML

Técnicas de Modelagem

Análise: Classes

Projeto: Objetos, Interface e Sistema

Considerações Finais

67

Metodologia

Conjunto de técnicas e diretrizes para

construção, manutenção e melhoria de

produtos de software.

Fornece uma base de comunicação: um

conjunto de técnicas e uma base para

engenharia de software.

68

Fases Clássicas do

Desenvolvimento de Sistemas

69 Definição de Requisitos Análise Projeto Implementação Teste Implantação Domínio do Problema Domínio da Solução

Metodologia OO

Uma metodologia de desenvolvimento

de sistemas é considerada Orientada a

Objetos se ela orienta a construção de

sistemas a partir do entendimento do

mundo real como um conjunto de

objetos que comunicam-se entre si de

forma coordenada.

70

Metodologia OO

Principais Atividades:

Entender quais são os objetos envolvidos

no domínio do problema.

Entender como se comunicam no mundo

real.

Projetar a forma como devem ser

implementados.

71

UML – Unified Modeling Language

72

UML

Booch Rumbaugh Jacobson

Meyer Harel Wirgs-Brock Fusion Gamma et al Shlaer-Mellor Odell

Objetivo: linguagem de modelagem unificada que tratasse assuntos de escala inerentes a sistemas complexos e de missão crítica, que se tornasse poderosa o suficiente para modelar qualquer tipo de aplicação em tempo real, cliente/servidor, orientada a objetos e outros tipos e padrões de software.

(13)

A UML

Os fomentadores da UML não inventaram a maioria das idéias, em vez disso, seu papel foi selecionar e integrar as melhores práticas, tornando-a um meio padrão de expressar projetos de sistemas.

Ajuda a desmistificar o processo de modelagem de sistemas de software. Linguagem-padrão para encorajar os desenvolvedores a modelar os seus sistemas de software, antes de construí-los.

Adoção rápida e muito difundida.

73

A UML

Tornou-se o modo-padrão para desenhar diagramas de projetos orientados a objetos. Também foi adotada em campos não-orientados a objetos.

É projetada para ser independente do processo de software.

É uma linguagem padrão para especificar, visualizar, documentar e construir

componentes de um sistema de informação. Pode ser utilizada em todos os processos ao longo do ciclo de desenvolvimento e através de diferentes tecnologias de implementação.74

A UML

É uma linguagem de modelagem; não é uma metodologia. Não possui um processo! Uma linguagem de modelagem é a notação, principalmente gráfica, utilizada por métodos para expressar projetos.

O processo é a sugestão de quais passos devem ser seguidos na elaboração de um projeto.

A linguagem de modelagem é a parte-chave do processo para a comunicação.

75

A UML

Está na sua versão 2.5.1 de 2017. Define uma notação e um metamodelo:

 Notação é a parte gráfica dos modelos; é a

sintaxe da linguagem de modelagem.

 Metamodelo é um diagrama, geralmente o

diagrama de classes, que define a como notação deve ser utilizada corretamente.

A UML tem pouco rigor; suas notações apelam para a intuição em vez da definição formal. O mais importante é a utilidade para o projeto.

Atualmente é um padrão do OMG –Object

Management Group. 76

A UML pode ser usada para:

1. Mostrar as fronteiras de um sistema e suas funções

principais utilizando atores e casos de uso;

2. Ilustrar a realização de casos de uso com

diagramas de interação;

3. Representar uma estrutura estática de um sistema

utilizando diagramas de classe;

4. Modelar o comportamento de objetos com

diagramas de transição de estados;

5. Revelar a arquitetura de implementação física com

diagramas de componente e de implantação;

6. Estender sua funcionalidade através de

estereótipos.

77

UML & Análise e Projeto

O objetivo real do desenvolvimento de

software é o código executável.

Nenhum usuário ficará satisfeito apenas

com diagramas de projeto bonitos.

O usuário quer um software que seja

executado!

Portanto, ao utilizar a UML é importante

pensar em como ela ajudará a escrever

o código executável.

(14)

Processo de

Desenvolvimento

79 Domínio da Solução Domínio do Problema CONCEPÇÃO Projeto Lógico (Análise Conceitual) ELABORAÇÃO Projeto Físico (Projeto de Software) TRANSIÇÃO Teste Ajuste Treinamento CONSTRUÇÃO Implementação (Desenvolvimento) 1 2 3 ... Interativo e Incremental ITERAÇÕES: •Análise •Projeto •Implementação •Teste & Ajuste •Treinamento RISCOS: •Requisitos •Tecnologia •Pessoal Habilitado •Fatores Políticos REQUISITOS Revisão de Processos de Negócio

Tipos de Análise

Análise Estática: descreve as

estruturas e os relacionamentos entre

os objetos do domínio do problema

(Diagrama de Classe de Objetos).

Análise Dinâmica: descreve o

comportamento dos objetos em termos

de suas mudanças ao longo do tempo

(Diagrama de Transição de Estados e

Diagrama de Interação).

80

Modelagem com a UML

1. O que fazem e desejam os usuários do sistema?

(análise de processos e casos de uso).

2. Quais são os objetos no mundo real que interagem

com o sistema em estudo e suas associações?

(diagrama de classes e MER).

3. Quais objetos são necessários para cada caso de

uso? (análise de processos, casos de uso e CRC).

4. Como colaboram entre si objetos dentro de um

caso de uso? (diagramas de interação).

5. Como serão implementados os controles de tempo

real? (diagramas de estados e de atividades).

6. Como será construído o sistema? (diagrama de

pacotes, diagrama de componentes, diagrama de

implantação). ₈₁

ANÁLISE DE PROCESSOS

(Não faz parte formal da UML)

Processos & Organizações

Uma organização pode ser vista como

um grande processo que recebe

insumos, informações e recursos do

ambiente, os processa e os devolve ao

ambiente na forma de serviços.

A organização também pode ser vista

como um conjunto de processos

operacionais e gerenciais, que se

desdobram em etapas, e que por sua vez

se subdividem em atividades e estas em

tarefas.

₈₃

Revisão vs. Reengenharia

de Processos

84

Melhoria Contínua Reengenharia

Mudanças suaves, graduais e contínuas. Mudanças drásticas, fundamentais e descontínuas. •Qualidade Total •Racionalização e Produtividade •Desenvolvimento de Processos

Baixo Risco Alto Risco

Não informatize, destrua (Hammer). Evolua lenta e

gradualmente (Kaizen).

(15)

Mudança Organizacional

85

Do foco nas funções...(Sistemas Isolados)

Mudança Organizacional

86

...ao foco nos Processos (Sistemas Integrados).

Processo

87

É um conjunto de atividades estruturadas, seqüenciais e medidas que transforma um ou mais tipos de entrada e cria um produto ou serviço que tem valor para determinados usuários, clientes ou mercados.

Entradas Requisitos Produtos/ Serviços Fornecedores Clientes PROCESSO

Características dos Processos

Processos eficientes e eficazes possuem

as seguintes características:

Repetitibilidade Estabilidade Previsibilidade Mensurabilidade Documentação 88

Elementos de um Processo

Nome Escopo e Limites

Clientes (internos e/ou externos) Fornecedores (internos e/ou externos) Requisitos de Entrada e Saída Atividades e Participantes Mapa do Processo

Indicadores e Medidas (tempo, custo etc.)

Informações! (incluindo sua documentação)

89

Diagrama de um Processo

90

Fornecedor Processo Cliente

Atividades com Valor Agregado Transformação Entradas •Informações • Insumos • Instruções • Materiais • Tecnologia Saídas • Produtos • Serviços •Informações (informação é serviço)

(16)

Análise do Processo

91 Fornecedor - Insumos - Informações - Instruções - Materiais - Tecnologia Entradas Requisitos Cliente Produtos - Serviços - Informações Saídas Requisitos Recursos Instalações Padrões de Desempenho Conhecimentos Habilidades Métodos Procedimentos Regras PROCESSO

Processo

1. Identificação de Produtos e Processos:

 A partir do entendimento dos negócios da organização.

2. Matriz Serviço/Fornecedor/Cliente:

 Detalha os produtos finais e intermediários de um

processo

 Detalha seus fornecedores e clientes internos e externos

 Detalha as responsabilidades envolvidas

3. Mapa do Processo:

 Fluxograma de atividades: identificando as unidades

organizacionais, tarefas, tempos, pessoas e interfaces envolvidas em cada atividade.

 Fluxograma de informações: identificando as

informações utilizadas no processo, detalhando seu recebimento, processamento, envio, registro e interfaces

envolvidas. 92

Matriz Fornecedor X Cliente

Cliente

A ClienteB ClienteC ... ClienteX

Fornecedor A Serviço 1 Serviço 3 Fornecedor B Serviço 2 Fornecedor C Serviço 4 ... Fornecedor X Serviço X 93

Símbolos para Fluxogramas

94 Operação Operação Manual Decisão Documento Arquivar Extrair Entrada Conector Página Conector Início/Fim Processo Armazenamento Preparação Dados Disco Acesso Consulta

Mapa de Processo

95 Processo de Negócio D e pt o. 2 D e pt o. 3 D ep to .1

Início Atividade 1 Decisão

Atividade 2 Atividade 3 Fim Não Sim

Mapa de

Processo

Processo de Pedidos de Venda

Evento Atividade Informação Unidade Organizacional Loja Vendas Vendas Vendas Pedido Recebido PedidoEntrar

Pedido

Reigstrado ProcessarPedido

Perguntar ao Cliente Preparar Pedido Suplementar Pedido Pronto Necessidade de Informações Informações Recebidas Pedido Suplementado Pedido do Cliente Clientes Regulares 96

(17)

Processos

97 Entendimento do Negócio Análise do Processo Projeto do Processo Implementação do Processo (automação) Gerenciamento do Processo

da Tecnologia da Informação

Identificação clara do que deverá ser automatizado Aponta a priorização das atividades a serem automatizadas

Visão do todo com responsabilidades bem definidas Garantia de automatização de um processo já racionalizado e preparado para usar a TI

Necessidades de suporte de Sistemas de Informação já identificadas (dados, políticas, normas, regras do negócio, procedimentos, recursos, capacitação etc.) Redução do tempo para obtenção da visão global.

98

UML: Casos de Uso

(UML Use Case)

A partir dos Processos de Negócio explicita requisitos de usuários em partes

significativas.

Descreve a funcionalidade do sistema percebida por atores externos ligados ao Processo de Negócio.

Um ator interage com o sistema podendo ser um usuário, dispositivo ou outro sistema. O planejamento e a construção de sistemas é realizado pela implementação de alguns Casos de Uso em cada iteração.

99

UML: Casos de Uso

Técnica proposta por Jacobson (1992). Conceitos básicos:

Cenário: é uma seqüência de passos que

descreve uma interação entre um usuário e um sistema.

Caso de uso: é um conjunto de cenários

amarrados por um objetivo comum de um usuário.

Base para testes dos requisitos do sistema.

100

UML: Casos de Uso

Características dos Casos de Uso:

 Há um caso comum, em que tudo dá certo, e que

ocorre com mais freqüência.

 Há casos alternativos, menos freqüentes, que

podem ocorrer quando algo sai fora do comum (outros caminhos ou erros).

Captura de Casos de Uso:

 Descrição do cenário primário como uma

seqüência de passos numerados.

 Descrição descrição das alternativas, como

variações daquela seqüência de passos mais

comum. ₁₀₁

UML: Casos de Uso –

Exemplo

Compra de um Produto na Web

1. O cliente navega pelo catálogo e seleciona itens

a serem comprados.

2. O cliente vai para o check out.

3. O cliente preenche o formulário para remessa.

4. O sistema apresenta a informação total

incluindo: faturamento, remessa, preços e impostos.

5. O cliente preenche a informação de cartão de

crédito.

6. O sistema autoriza a compra.

7. O sistema confirma imediatamente a venda.

8. O sistema envia uma confirmação para o cliente

(18)

Exemplo

Caso Alternativo 1 – Falha na Autorização:

 No passo 6, o sistema falha na autorização da

compra por cartão de crédito. Permite ainda ao cliente reenviar a informação do cartão de crédito ou tentar novamente com outro.

Caso Alternativo 2 – Cliente Habitual

 O sistema mostra a informação total e os quatro

últimos dígitos do cartão de crédito.

 O cliente pode aceitar ou escrever por cima

destas opções e retornar para o Caso Comum no passo 6.

103

UML: Diagrama de Casos de Uso

104

Sistema

Ator

Caso de Uso «uses»

UML: Diagrama de Classes

(UML Static Structure)

Um dos mais importantes componentes da UML. Mostra a estrutura estática de conceitos, tipos e classes do sistema.

Conceitos mostram como os usuários pensam

sobre o mundo real.

Tipos mostram interfaces de componentes de

software.

Classes mostram a implementação dos

componentes de software.

É considerado estático pois a estrutura descrita é sempre válida para o sistema.

105

UML: Diagrama de Classes

Gráfico bidimensional de elementos de modelagem que pode conter:

Tipos Pacotes Relacionamentos Classes

Um diagrama de objetos é uma variação do diagrama de classes que mostra objetos em vez de classes.

106

UML: Diagrama de Classes

107 +IncluirPedido() +AtenderPedido() -Número -Data Pedido +Incluir() +Avaliar() -Código -Nome -Limite Crédido -Endereço Cliente -Pedido 0..* -Cliente 1 +IncluirItem() +CalcularTotal() -Quantidade Item Pedido -Pedido 1 -Item 1..* +IncluirProduto() +AtualizarPreço() +AtualizarSaldo() -Código -Nome -Preço -SaldoEstoque Produto -Item 0..* -Produto 1

Hardware Software Suprimento

Generalização Associação Agregação Dados/Propriedades Operações/Métodos Super Classe Subclasse Composição Multiplicidade

Diagrama de Classes - Exemplo

108 -lastName : char -firstName : char -address : char -city : char -state : char -zipcode : char -phoneNumber : char -faxNumber : char -email : char Person «event» +ir() : float -salary : float -cpfNum : char -title : char Person::Employe e +prazo() : int -creditLimit : float -creditCarg : char -expireDate : char Person::Client +salePrice() : float -productName : char -productPrice : float -cgcNum : char Person::Supplier

(19)

Cartões CRC

(Classe responsabilidade e colaboração)

(Não fazem parte formal da UML)

Ajudam a chegar à essência do objetivo

de uma classe.

Bons para explorar como implementar

Casos de Uso.

Devem se utilizados para simplificar e

esclarecer detalhes.

Úteis para o entendimento de Classes e

Objetos.

109

Classe, Responsabilidade e Colaboração

110

Cartões CRC

111

PEDIDO

Verifique se os itens estão em estoque Item Pedido

Determine o Preço Produto

Verifique se o pagamento é válido Cliente

Despache para o endereço de entrega Cliente

Responsabilidade Colaboração

UML: Diagramas de Interação

(Sequence & Collaboration)

São modelos que descrevem como grupos de objetos colaboram em algum comportamento do sistema.

Tipicamente capturam o comportamento de um único Caso de Uso.

Mostram vários objetos e as mensagens que são passadas entre estes objetos em um Caso de Uso.

Categorias de Diagramas de Interação:

Diagramas de Seqüência Diagramas de Colaboração

112

UML: Diagramas de Seqüência

(UML Sequence)

Mostram o fluxo global de controle da interação entre objetos através de mensagens.

Permitem o entendimento da seqüência de métodos em classes distintas que revela o comportamento pretendido.

Ajudam o entendimento de processos concorrentes.

As duas dimensões de um diagrama de seqüência são: tempo (vertical) e objetos (horizontal).

113

UML: Diagrama de Seqüência

114

Prepare()

Entrada de Pedido Pedido Item de Pedido

Adicione Item() Produto VerificarEstoque() RetirarEstoque() Retorno OK() PrecisaRepor() Item Reposição Message1() Item Entrega Message2()

(20)

UML: Diagramas de Colaboração

(UML Collaboration)

Mostra uma interação dinâmica de um Caso de Uso organizada em torno de objetos e seus vínculos mútuos.

Utiliza números de seqüência para evidenciar a seqüência de mensagens.

Flechas indicam as mensagens enviadas dentro de um dado Caso de Uso. Mostra como objetos são ligados entre si. Utiliza o layout de Diagramas de Classes ou de Pacotes para esboçar a colaboração entre objetos.

115

UML: Diagrama de Colaboração

116 Janela Entrada Pedido Pedido

Incluir() Item Pedido Incluir() Produto VerificarEstoque() AtualizarSaldo() Item Entrega In cl u ir( ) Item Reposição In cl ui rP ro du to ()

UML: Diagramas de Estados

(UML Statechart)

Mostram como um único objeto se comporta através de muitos Casos de Uso.

Mostra seqüências de estados que um objeto ou uma interação assume em sua vida em resposta a eventos, juntamente com suas respostas e ações.

É um complemento de uma classe

relacionando os possíveis estados que objetos da classe podem ter e quais eventos podem causar a mudança de estado (transição).

117

UML: Diagrama de Estados

118 Registrando Pedido Analisando Pedido Alterando Pedido Pedido enviado Analise requisitada Alteração de Pedido Solicitada Cancelamento de Pedido Cancelamento de Pedido Solicitado

Pedido deve ser cancelado

Aprovando Pedido Pedido para

Aprovação

Pedido Pendente Pedido não pode

ser atendido no

momento Pedido já pode_{ser atendido}

Atendendo Pedido Pedido deve ser

Atendido Pedido Atendido

Eventos

UML: Diagramas de Atividades

(UML Activity)

Mostra comportamento com estrutura de controle.

Pode mostrar:

 Muitos objetos em muitos usos.

 Muitos objetos em Caso de Uso único.

 A implementação de métodos.

É um diagrama de estados especial onde a maioria dos estados é de ação e a maioria das transições é ativada por conclusão das ações dos estados de origem.

Seu propósito é estudar fluxos dirigidos por processamento interno, descrevendo as atividades desempenhadas numa operação.119

UML: Diagrama de Atividades

120 Registrar Pedido Cancelar Pedido Autorizar Pagamento Atualizar Estoqe Aceitar Pedido

(21)

UML: Pacotes

(UML Deployment)

Mostra grupos de classes e as

dependências entre elas.

121 Pessoa

Indivíduo Organização

UML: Diagramas de Componentes

(UML Component)

São mostradas dependências entre

componentes de software.

Tipos de componentes:

Código-fonte Código-binário Executáveis. 122

UML: Diagrama de Componentes

123 Componente da Interface 1 Componente da Interface 2 Componente de Negócios 1

UML: Diagramas de Implantação

(UML Deployment)

Mostra elementos de configuração de processamento e os componentes de software, processos e objetos que neles se mantêm.

Inclui o uso físico do sistema considerando computadores, dispositivos e suas interconexões.

Mostram o layout físico dos componentes nos nós de hardware.

124

UML: Diagrama de Implantação

125 SERVIDOR BANCO DE DADOS ESTAÇÃO CLIENTE (PC) ESTAÇÃO CLIENTE (PC) SERVIDOR WEB Entrada do Pedido Registro do Pedido

Relacionamento entre as

Técnicas de Modelagem

126 Use Case Diagrama de Classes CRC DTE DI Componentes Pacotes Implantação Revisão de Revisão de Processos

(22)

Tecnologias de Implementação

Ferramentas CASE:

 Rational Rose (Rational), Visio Enterprise (Microsoft) etc.

Linguagens Orientadas a Objetos:

 Java, J++, J#, C#, VB.NET, C++ e Smalltalk

Ambientes de Desenvolvimento:

 VisualAge for Java (WebSphere) (IBM)

 Oracle Applications (Oracle)

 Visual Studio .NET (Microsoft)

 Visual Café (Symantec)

 Jbuilder (Borland/Inprise)

Banco de Dados Orientado a Objetos:

 O2 (O2 Technology)

 Objectstore (Object Design Inc.)

 Jasmine (Computer Associates)

127

Metodologia OO

Mudança de paradigma – requer treinamento intensivo.

Protótipos sem compromisso.

Os primeiros sistemas devem ser “livres”. Grupo formal de metodologia – proposta e treinamento.

Acerto do ambiente de desenvolvimento – suporte e padrões.

Administração de classes/objetos – Biblioteca de Classes. Ferramenta CASE. 128

Benefícios da OO

Reutilização de código. Estabilidade.

O projetista pensa em termos de comportamento dos objetos e não em detalhes de baixo nível.

Construção de objetos cada vez mais complexos.

Confiabilidade. Verificação de precisão. Novos mercados de software. Desenvolvimento acelerado.

Integridade. 129

Benefícios da OO

Programação facilitada. Manutenção facilitada. Ciclo de vida dinâmico.

Refinamento durante a construção. Modelagem mais realista.

Melhor comunicação entre profissionais de sistemas e usuários.

Interoperabilidade.

Processamento Cliente/Servidor. Processamento distribuído e paralelo. Bibliotecas de classes industrializadas e