Orientao para Objetos Projeto de Sistemas Aplicativos para

Orientação para Objetos Projeto de Sistemas Aplicativos para a Internet FEA/USP EAD-5881 – Tecnologia de Informática Prof. Antonio Geraldo da Rocha Vidal vidal@usp. br 1

Conteúdo 1. Conceitos de Orientação a Objetos n n n Classes Objetos Programação 2. Introdução à Linguagem Java n Conceitos e recursos básicos 3. Projeto de Sistemas Orientados a Objetos 4. UML - Unified Modeling Language 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 Programa Classe Processos Propriedades Dados Métodos Tradicional Objetos 5

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: n n n n Encapsulamento Herança Polimorfismo Propriedades Métodos Eventos Mensagens Reutilização Flexibilidade Interoperabilidade 6

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 12

Objetos de Software Comportamentos Variáveis Dados Procedimentos Propriedades Métodos 13

Objeto Automóvel Mover Preço Dimensões Cor Potência Buzinar Parar 14

Objetos de Software 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. 15

Encapsulamento É definido como uma técnica para minimizar interdependências entre “módulos” através da definição de interfaces externas. Interface Mudanças na implementação de uma classe que preserve a interface externa não afetam outras definições de classes. 16

Interfaces de Classes Uma Interface descreve um grupo de classes com as mesmas: n n 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. 17

Mensagens Objetos interagem e comunicam-se através de mensagens. . . Andar(. . . ) Emissor Receptor As mensagens identificam os métodos a serem executados no objeto receptor e passam-lhes alguma informação. 18

Métodos Um determinado método define um comportamento do objeto. Tipos básicos de métodos: n n Construtor (constrói estados) Destruidor (destrói estados) Transformador (transforma estados) Acesso (fornece estados) 19

Abstração Focalizar o essencial, ignorar propriedades acidentais ou específicas. 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 20

Classes de Objetos Uma classe de objetos descreve um grupo de objetos com: n n n Propriedades semelhantes; Comportamentos semelhantes; Relacionamentos comuns com outros objetos. 21

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

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

Classes vs. Subclasses Classes: n n 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: n n 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. 24

Classes vs. Objetos Classes: n n 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: n n 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. 25

Relacionamentos entre Classes Generalização Herança Agregação Polimorfismo 26

Generalização / Especialização Generalização é o relacionamento entre uma classe e uma ou mais versões refinadas dessa classe. Generalização é a abstração que permite compartilhar semelhanças entre classes, preservando suas diferenças. Especialização 27

Hierarquia de Classes 28

Herança Uma classe derivada ou subclasse herda as propriedades e métodos da classe mãe ou superclasse, mas pode: n n n Adicionar novos métodos próprios; Estender suas propriedades/atributos; Redefinir a implementação de métodos existentes. 29

Herança Localização de Métodos e Propriedades na Hierarquia Calcular() Instância 30

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

Agregação Um objeto agregado é “construído” por vários componentes Agregação Fixa 32

Agregação Um objeto agregado é “feito” de componentes Empresa Departamento Setor Agregação Variável Pessoa 33

Polimorfismo Refere-se a: n n 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. 34

Evento vs. Estado Evento: n n n 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: n Situação de um objeto em um dado instante do tempo. 35

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 n n Número: 000001 CPF: 999. 888. 777 -66 Nome: José da Silva Endereço: Rua da Independência, 709 Telefone: 3089 -9090 Etc. 36

Objetos: métodos & eventos Cada objeto reconhece e pode responder a ações denominadas eventos próprios da sua classe/subclasse. Eventos: n n São atividades específicas e predeterminadas provocada pelo usuário ou pelo sistema. Possuem métodos associados a eles. Métodos: n n São comportamentos ou procedimentos associados ao objeto. Métodos podem existir independentemente de eventos. 37

Objetos: mensagens Objetos recebem mensagens de outros objetos com os quais se relacionam. Mensagens: n n n 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. 38

Objetos: polimorfismo Usando a mesma mensagem, objetos podem assumir características e comportamentos diferentes: n n n De acordo com contextos específicos; De acordo com eventos e contextos específicos. Um objeto pode assumir várias formas: n n Propriedades/atributos diferentes; Métodos/comportamentos diferentes. 39

Linguagens Orientadas a Objetos 40

Introdução às Linguagens Orientadas a Objetos Conceitos Básicos (Válidos para C++, C#, Java, J++ e J#) 41

Java It’s a jungle out there So drink your Java Propaganda do Printer’s Café em Palo Alto CA/USA 42

Por que surgiu o Java? Software para eletro-domésticos (1992) n n n 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: n n n Orientada a objeto Totalmente aberta 43 Independente de plataforma e sistema operacional

Características do Java da Sun Linguagem orientada a objetos Estrutura semelhante ao C++ Gera Bytecodes n n Interpretada Alta Performance (JIT) Segurança n n Endereçamento restrito Objetos assinados Aplicação Carregada Localmente 44

Características do Java da Sun Aplicações Personalizadas Independência de Arquitetura n n 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” 45

Arquitetura de Programas Java 46

Java Script Primeira Versão do Java Aplicação Interna ao HTML Interpretada Não havia o conceito de Byte. Codes <script language=“Java Script” Function -------{. . . . } </script> 47

Applet Java Aplicação executada quando se chama uma página WWW É carregada na Máquina Cliente Restringe-se a uma determinada área (janela) <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: 48

Aplicação Java Aplicação executada “stand-alone” Exige somente a presença do interpretador Java (Java Virtual Machine) public class Hello. World. App { // Definição do Método MAIN public static void main (String args[]) { String text = "Hello World!"; System. out. println(text); } } 49

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 50 propriedades constantes.

Criando Classes Uma classe é composta por métodos (comportamento) e propriedades (variáveis que determinam o estado). public class Pessoa { // Variáveis ou propriedades String Nome; boolean Com. Fome; // Métodos int Comer(int quantidade) { //. . . } } Métodos mudam o estado das variáveis 51

Exemplo de Definição de Classe (propriedades) public class Morador. . . { String nome. Completo; String apartamento; String telefone; int ano. Chegada; . . 52

Exemplo de Definição de Classe (métodos) public class Morador. . . {. . public morador(String no, String ap, String te, int an) { nome. Completo = no; apartamento = ap; telefone = te; ano. Chegada = an; } public int permanencia() { return (2002 - ano. Chegada); } } 53

Criando Objetos Criação do Objeto lassie a partir da classe Cachorro: /*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(); 54

Usando Objetos Executando um método do objeto criado: Cachorro. latir(); /* Errado! -não se pode fazer todos os cachorros latirem. */ lassie. latir(); /* Correto! pode-se fazer um determinado cachorro latir. */ 55

Exemplo de Instanciação de uma Classe. . . Morador prof; . . prof = new morador(“Vidal”, “ 82”, “ 3081 -0001”, 1998); . . . 56

Exemplo de Métodos com Mensagens. . . 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. . 57

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. 58

Exemplo de Herança 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; } } 59

Exemplo de Agregação Objeto Composto public class material extends Object { String rotulo; Boolean em. Caixa; int ano. Estocagem; double valor; Morador proprietario; public material (. . ). . 60

Exemplo de Agregação Objeto Composto public class material extends Object {. . public material (String ro, double va, boolean em, Morador pro, int an) {rotulo = ro; valor = va; em. Caixa = em; proprietario = pro; ano. Estocagem = an; } public int permanencia() { return (2002 - ano. Estocagem); } 61

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. 62

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. 63

Pacotes Java 64

Análise e Projeto de Sistemas Orientados a Objeto UML - Unified Modeling Language 65

Conteúdo Visão Geral UML Técnicas de Modelagem Análise: Classes Projeto: Objetos, Interface e Sistema Considerações Finais 66

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. 67

Fases Clássicas do Desenvolvimento de Sistemas Definição de Requisitos Domínio do Problema Análise Projeto Implementação Teste Domínio da Solução Implantação 68

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. 69

Metodologia OO Principais Atividades: n n n 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. 70

UML – Unified Modeling Language Booch Odell Rumbaugh UML Shlaer-Mellor Gamma et al Jacobson Meyer Harel Fusion Wirgs-Brock 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, 71 orientada a objetos e outros tipos e padrões de software.

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. 72

A UML Tornou-se o modo-padrão para desenhar diagramas de projetos orientados a objetos. Também foi adotada em campos nãoorientados 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. 73

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. 74

A UML Está na sua versão 1. 3 de 1999. Define uma notação e um metamodelo: n n 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 75 Management Group.

A UML pode ser usada para: 1. Mostrar as fronteiras de um sistema e suas 2. 3. 4. 5. 6. funções principais utilizando atores e casos de uso; Ilustrar a realização de casos de uso com diagramas de interação; Representar uma estrutura estática de um sistema utilizando diagramas de classe; Modelar o comportamento de objetos com diagramas de transição de estados; Revelar a arquitetura de implementação física com diagramas de componente e de implantação; Estender sua funcionalidade através de estereótipos. 76

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. 77

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

Tipos de 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). 79

Modelagem com a UML 1. O que fazem e desejam os usuários do sistema? 2. 3. 4. 5. 6. (análise de processos e casos de uso). Quais são os objetos no mundo real que interagem com o sistema em estudo e suas associações? (diagrama de classes e MER). Quais objetos são necessários para cada caso de uso? (análise de processos, casos de uso e CRC). Como colaboram entre si objetos dentro de um caso de uso? (diagramas de interação). Como serão implementados os controles de tempo real? (diagramas de estados e de atividades). Como será construído o sistema? (diagrama de pacotes, diagrama de componentes, diagrama de implantação). 80

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. 82

Revisão vs. Reengenharia de Processos • Qualidade Total • Racionalização e Produtividade • Desenvolvimento de Processos Evolua lenta e gradualmente (Kaizen). Baixo Risco Melhoria Contínua Melhoria, Programas, Projetos Mudanças suaves, graduais e contínuas. Não informatize, destrua (Hammer). Alto Risco Reengenharia Redesenho, Reprojeto Mudanças drásticas, fundamentais e descontínuas. 83

Mudança Organizacional Do foco nas funções. . . (Sistemas Isolados) 84

Mudança Organizacional. . . ao foco nos Processos (Sistemas Integrados). 85

Processo É 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. Fornecedores PROCESSO Produtos/ Clientes Serviços Entradas Requisitos 86

Características dos Processos eficientes e eficazes possuem as seguintes características: n n n Repetitibilidade Estabilidade Previsibilidade Mensurabilidade Documentação 87

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) 88

Diagrama de um Processo Forneced Processo Cliente Transformação Entradas or • Informações • Insumos • Instruções • Materiais • Tecnologia Atividades com Valor Agregado Saídas • Produtos • Serviços • Informações (informação é serviço) 89

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

Metodologia para Análise do Processo 1. Identificação de Produtos e Processos: w A partir do entendimento dos negócios da organização. 2. Matriz Serviço/Fornecedor/Cliente: w Detalha os produtos finais e intermediários de um processo w Detalha seus fornecedores e clientes internos e externos w Detalha as responsabilidades envolvidas 3. Mapa do Processo: w Fluxograma de atividades: identificando as unidades organizacionais, tarefas, tempos, pessoas e interfaces envolvidas em cada atividade. w Fluxograma de informações: identificando as informações utilizadas no processo, detalhando seu recebimento, processamento, envio, registro e interfaces envolvidas. 91

Matriz Fornecedor X Cliente A Fornecedor B Fornecedor C Cliente B Serviço 1 Cliente C . . . Cliente X Serviço 3 Serviço 2 Serviço 4 . . . Fornecedor X Serviço X 92

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

Mapa de Processo 94

Mapa de Processo 95

Ciclo de Melhoria de Processos Análise do Processo Entendimento do Negócio Projeto do Processo Implementação do Processo (automação) Gerenciamento do Processo 96

Benefícios para a Aplicação 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. 97

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. 98

UML: Casos de Uso Técnica proposta por Jacobson (1992). Conceitos básicos: n Cenário: é uma seqüência de passos que descreve uma interação entre um usuário e um sistema. n Caso de uso: é um conjunto de cenários amarrados por um objetivo comum de um usuário. Base para testes dos requisitos do sistema. 99

UML: Casos de Uso Características dos Casos de Uso: n n 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: n n Descrição do cenário primário como uma seqüência de passos numerados. Descrição das alternativas, como variações daquela seqüência de passos mais comum. 100

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 101 cliente via e-mail.

UML: Casos de Uso – Exemplo Caso Alternativo 1 – Falha na Autorização: n 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 n n 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. 102

UML: Diagrama de Casos de Uso 103

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. n Conceitos mostram como os usuários pensam sobre o mundo real. n Tipos mostram interfaces de componentes de software. n Classes mostram a implementação dos componentes de software. É considerado estático pois a estrutura descrita é sempre válida para o sistema. 104

UML: Diagrama de Classes Gráfico bidimensional de elementos de modelagem que pode conter: n Tipos n Pacotes n Relacionamentos n Classes Um diagrama de objetos é uma variação do diagrama de classes que mostra objetos em vez de classes. 105

UML: Diagrama de Classes Associação Composição Agregação Dados/Propriedades Operações/Métodos Multiplicidade Super Classe Generalização Subclasse 106

Diagrama de Classes - Exemplo 107

Cartões CRC (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. 108

Cartões CRC Responsabilidade PEDIDO Verifique se os itens estão em estoque Determine o Preço Verifique se o pagamento é válido Despache para o endereço de entrega Colaboração Item Pedido Produto Cliente 109

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: n Diagramas de Seqüência n Diagramas de Colaboração 110

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). 111

UML: Diagrama de Seqüência 112

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. 113

UML: Diagrama de Colaboração 114

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). 115

UML: Diagrama de Estados Eventos 116

UML: Diagramas de Atividades (UML Activity) Mostra comportamento com estrutura de controle. Pode mostrar: n n n 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. 117

UML: Diagrama de Atividades 118

UML: Pacotes (UML Deployment) Mostra grupos de classes e as dependências entre elas. 119

UML: Diagramas de Componentes (UML Component) São mostradas dependências entre componentes de software. Tipos de componentes: n n n Código-fonte Código-binário Executáveis. 120

UML: Diagrama de Componentes 121

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. 122

UML: Diagrama de Implantação 123

Relacionamento entre as Técnicas de Modelagem Revisão de Processos Use Case Diagrama de Classes DTE Pacotes CRC DI Componentes Implantação 124

Tecnologias de Implementação Ferramentas CASE: n Rational Rose (Rational), Visio Enterprise (Microsoft) etc. Linguagens Orientadas a Objetos: n Java, J++, J#, C#, VB. NET, C++ e Smalltalk Ambientes de Desenvolvimento: n n n Visual. Age for Java (Web. Sphere) (IBM) Oracle Applications (Oracle) Visual Studio. NET (Microsoft) Visual Café (Symantec) Jbuilder (Borland/Inprise) Banco de Dados Orientado a Objetos: n n n O 2 (O 2 Technology) Objectstore (Object Design Inc. ) Jasmine (Computer Associates) 125

Implementação de uma 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. 126

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. 127

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 corporativas. 128

Fim! Obrigado e Sucesso! 129