Orientao a Objetos e UML Parte I Objetivos

Orientação a Objetos e UML Parte I

Objetivos – Apresentar os conceitos fundamentais de modelagem e orientação a objetos; – Apresentar os quatro diagramas principais da UML: Casos de Uso, Classes, Seqüência e Atividade; – Estabelecer a ligação entre a modelagem e a programação de sistemas orientados a objetos.

Bibliografia 1. Modelagem de Objetos Através da UML, José Davi Furlan, Editora Makron Books, 2000, ISBN 8534609241; 2. UML Guia do Usuário, Grady Booch, James Rumbaugh, Ivar Jacobson, Editora Campus, 2000, ISBN 8535205624; 3. Mastering UML com Rational Rose 2002 – Bíblia, Boggs Wendy, Michael Boggs, Editora Alta Books Ltda, 2002; 4. UML Essencial: Um breve guia para a linguagem-padrão de modelagem de objetos, Martin Fowler e Kendal Scott, Ed. Bookman, 2000.

Referências na Internet 1. http: //www. uml. org 2. http: //www. uml-forum. com 3. http: //www. rational. com 4. http: //argouml. tigris. org/ (Ferramenta CASE Argo) 5. http: //www. gentleware. com (Ferramenta CASE Poseidon) 6. http: //www. borland. com/together/index. html (Ferramenta CASE Together)

1. Conceitos Fundamentais Unidade de Aprendizado

1. Conceitos Fundamentais • Objetivos – Apresentar os conceitos envolvidos na Modelagem de Sistemas; – Explorar a importância e a necessidade de modelar sistemas. – Apresentar os conceitos fundamentais sobre Orientação a Objetos. • Conteúdo 1. Modelagem de Sistemas. 2. Orientação a Objetos.

1. 1. Objetivo da Modelagem de Sistemas

1. 1. Objetivo da Modelagem de Sistemas • A Atividade de Desenvolvimento de Sistemas – Objetivos da Empresa de Desenvolvimento de Software: • Produtos de Qualidade; • Atender as necessidades do cliente; • Preços competitivos. – Foco nos Clientes: • Centro da atenção no desenvolvimento; • Atender aos requisitos do usuário. – Viabilidade do Projeto: • Equilíbrio entre custos de desenvolvimento e benefícios para o cliente.

1. 1. Objetivo da Modelagem de Sistemas • O Papel da Modelagem – Existem dois tipos de modelos: • Estrutura; • Comportamento; – Os modelos traduzem COMO as coisas serão construídas: • Relações entre as partes; • Funcionamento; • Disposição. – Os modelos traduzem o tamanho e a complexidade do sistema.

1. 1. Objetivo da Modelagem de Sistemas • O Que é um Modelo? – Um modelo é uma simplificação da realidade. – Modelos são esquemas gráficos que representam o sistema. – Os modelos traduzem: • ESTRUTURA: – Organização de módulos; – Relacionamentos; • COMPORTAMENTO: – Dinâmica; – Inter-relacionamento; – Funcionalidade.

1. 1. Objetivo da Modelagem de Sistemas • O Que é um Modelo? – Construímos modelos para: • Visualizar o sistema como ele é ou como desejamos que ele seja; • Dominar a complexidade e entender o sistema; • Delimitar o escopo de um problema; • Comunicação entre equipe; • Ajudar a planejar as soluções; • Guiar o desenvolvimento do sistema.

1. 1. Objetivo da Modelagem de Sistemas • O Que é um Modelo? – Características dos Modelos: • Perspectivas diferentes; • Analogia com a realidade; • Complementaridade;

1. 1. Objetivo da Modelagem de Sistemas • Modelagem Orientada a Objetos – Tradicional: • Foco do desenvolvimento nos processos; – Orientada a Objetos: • Foco do desenvolvimento nas entidades que participam dos processos. – Entidades do mundo real: • Pessoas - Funcionário, Vendedor, Professor, Aluno. • Lugares - Sala, Estoque, Estante, Prateleira. • Fatos - Conta-Corrente, Matrícula, Pedido de Compra, Apólice de Seguro. • Coisas - Livro, Caminhão, Fita VHS, Computador.

1. 1. Objetivo da Modelagem de Sistemas • Modelagem Orientada a Objetos

1. 1. Objetivo da Modelagem de Sistemas • Modelagem Orientada a Objetos - Benefícios – Benefícios Técnicos: • Reusabilidade; • Extensibilidade e manutenção; • Aumento da qualidade; – Benefícios Econômicos: • Apoio ao planejamento; • Reaproveitamento de esforços.

1. 1. Objetivo da Modelagem de Sistemas • Modelagem Orientada a Objetos - Definições – James Rumbaugh Uma nova maneira de pensar os problemas, utilizando modelos organizados a partir de conceitos do mundo real. O componente fundamental é o objeto, que combina estrutura e comportamento em uma única entidade.

1. 1. Objetivo da Modelagem de Sistemas • Modelagem Orientada a Objetos - Definições – Grady Booch Leia a especificação do software que você quer criar. Sublinhe os verbos se quiser uma codificação procedural ou os substantivos se visar a um programa orientado a objetos.

1. 1. Objetivo da Modelagem de Sistemas • Exercício Nº 1 2 3 Substantivos Verbos

1. 2. Orientação a Objetos

1. 2. Orientação a Objetos • Analogia Orientada a Objetos – Imagine que você recebeu como herança, um grande terreno. – Esse terreno é identificado por um número.

1. 2. Orientação a Objetos • Analogia Orientada a Objetos – Você contrata um arquiteto a fim de projetar uma casa. – O arquiteto faz várias perguntas sobre a casa, a sua forma, estilo e funcionalidade. – O arquiteto trabalha algum tempo no projeto da casa e entrega as plantas para que você possa construir.

1. 2. Orientação a Objetos • Analogia Orientada a Objetos – Você contrata uma construtora para erguer a casa. – A construtora leva algum tempo e termina o serviço. – Existe alguma casa no terreno? Sim, a casa ocupa espaço no terreno.

1. 2. Orientação a Objetos • Processador e Memória – A memória é dividida em partes referenciadas por endereços. – Existem partes da memória que estão ocupadas e outras livres. – Dentro de um programa, podemos alocar espaço na memória e construir objetos. – Esses objetos são acessados através de um endereço de memória ou de uma referência ao endereço.

1. 2. Orientação a Objetos • Classe – Conceito de Classe: • As plantas da casa representam a classe. • É a partir da classe que se constrói um objeto na memória. • É a definição da forma e funcionalidade de alguma coisa. – Responsabilidade da Classe: • É o que a classe “sabe” e o que ela “faz”. • O que a classe “sabe” são as propriedades ou seus atributos. • O que a classe “faz” são os seus métodos ou funções.

1. 2. Orientação a Objetos • Exemplo – Vamos imaginar que em um sistema exista a classe Aluno. – O que Aluno sabe? • Seu nome, • Seu endereço, • Seu número de matrícula etc. – O que o Aluno faz? • Se matricula em um Curso, • Tranca a matricula, • Tem Avaliações etc.

1. 2. Orientação a Objetos • Tipos de Classes – Classes de Interface: • • Botões, Listas, Checkboxes, Scrollbars etc. – Classes de Negócio: • • Cliente, Pedido, Item de Pedido, Produto etc. – Classes de Controle: • • Data, Conexão com Banco de Dados, Gerenciador de Impressão, Leitura e Gravação de Arquivos etc.

1. 2. Orientação a Objetos • Objeto – Quando alocamos espaço na memória e usamos o construtor de uma classe, um objeto é criado. – Um objeto não interfere em outro. – Instância é sinônimo de objeto. – Instanciar significa criar um objeto a partir de uma classe.

1. 2. Orientação a Objetos • Classe e Objeto

1. 2. Orientação a Objetos Outra forma de desenhar a classe Propriedades Cliente Criar() Nome Idade Destruir() Funções

1. 2. Orientação a Objetos • Propriedade – As propriedades são os dados que guardam as características e o estado dos objetos criados a partir da classe. – É o que a classe “sabe”. – O relógio digital tem as propriedades “hora” e “minuto”.

1. 2. Orientação a Objetos • Método – O termo método representa as funcionalidades inerentes à classe. – É o que a classe “faz”. – Para alterar o mostrador do relógio digital não podemos simplesmente exibir um número qualquer. – Existe um “método” para fazer isso.

1. 2. Orientação a Objetos • Método Construtor e Destrutor – A função do método construtor é inicializar um objeto na memória. • Através dele é possível que o objeto na memória tenha valores iniciais. • Esse método é usado, por exemplo, para construir a tela da aplicação e abrir a conexão com o banco de dados. – O método destrutor permite “fechar” o ciclo de vida do objeto, dando condições de finalização ao programador.

1. 2. Orientação a Objetos • Assinatura – É a chamada de um método. Identifica um método pelo nome, a quantidade e tipos dos argumentos passados por parâmetros. – Um método é reconhecido pelo seu nome e seus parâmetros Cancelar. Assinatura(cod. Assinante) Alterar. Pagamento(cod. Assinante, nova. Data. Pagamento)

1. 2. Orientação a Objetos • Herança – Relacionamento de generalização e especialização entre classes. – Permite ao programador criar uma nova classe “estendendo” uma classe anterior. – A herança define uma hierarquia onde o conceito mais genérico fica sobre o conceito mais específico.

1. 2. Orientação a Objetos • Herança

1. 2. Orientação a Objetos • Encapsulamento A Classe é um “pacote”, contendo dados e operações; O objeto é referenciado como um módulo único; É a proteção dos dados internos da classe; Os dados só podem ser acessados sob determinadas condições. • É implementado através da “Visibilidade” mais restrita. • •

1. 2. Orientação a Objetos • Encapsulamento – Um sistema não deve depender da sua implementação interna e sim de sua interface com o mundo exterior. – A interface de uma classe é a forma pela qual ela Cliente será acionada e se relacionará com as outras partes do sistema. Encapsulamento – acessar os Nome Dt_nascim dados através dos métodos da classe

1. 2. Orientação a Objetos • Polimorfismo – Vários comportamentos que uma mesma operação pode assumir. – Polimorfismo (muitas formas) é a capacidade de um programa orientado a objetos distinguir, dentre métodos homônimos, qual deverá ser executado.

1. 2. Orientação a Objetos Polimorfismo – Métodos Sobrecarregados - são os métodos homônimos dentro de uma mesma classe. Retângulo Desenhar(p 1, p 2, p 3, p 4) Desenhar(alt, larg) Métodos na mesma classe com assinatura diferente - Sobrecarga Empregado Nome Funcao Dt_Admissao Empregado(nome) Empregado(nome, funcao, dt)

1. 2. Orientação a Objetos • Polimorfismo • Métodos Sobrescritos - são métodos homônimos em uma relação de herança. Empregado nome Obter. Empregado( ) Métodos com a mesma assinatura em uma herança - Sobrescrita Vendedor comissão Obter. Empregado( )

1. 2. Orientação a Objetos • Polimorfismo

1. 2. Orientação a Objetos • Modularidade – É a separação dos serviços em um conjunto de módulos que guardam independência de compilação e execução. – A modularidade leva a uma separação entre a interface do sistema e o código que vai executar os serviços. – Otimiza o processo de manutenção de código.

1. 2. Orientação a Objetos • Persistência – É o tempo total que um objeto permanece na memória (auxiliar ou principal). – Os objetos de negócio devem ser persistentes. – É comum a utilização de bancos de dados para tornar os objetos persistentes.

1. 2. Orientação a Objetos • Abstração – É a ocultação de certos aspectos de implementação. – O objetivo é diminuir a complexidade, focando um problema por vez.

1. 2. Orientação a Objetos • Classe Abstrata – E uma classe que define o comportamento e atributos para subclasses. – Não é instanciada diretamente.

1. 2. Orientação a Objetos • Estereótipo – Os estereótipos são extensões de elementos do modelo. Podem ser usados para denotar especializações significativas de classes. – Os atores, por exemplo, são tratados pelas ferramentas de modelagem como classes estereotipadas. – Os estereótipos podem ser indicados através de ícones próprios, ou incluindo-se o nome do estereótipo em aspas francesas (os caracteres « » , representados nos desenhos por << >>).

1. 2. Orientação a Objetos • Estereótipo – Estereótipos são usados para criar especializações da UML em relação a determinadas áreas de modelagem. – Ivar Jacobson propõe a divisão das classes do Modelo de Análise de acordo com estereótipos, que foram incorporados ao padrão oficial da UML. Esses estereótipos podem ser representados por textos ou ícones. São eles: Entidades (tabelas), Fronteiras (telas) e de Controle (conexão com banco, gerenciador de impressão, . . . ).

1. 2. Orientação a Objetos • Exercício • Identifique as propriedades e métodos das classes listadas. Nº Nome da Classe 1 Professor 2 Aluno 3 Filme Propriedades Métodos Nome, Endereço, Telefone, Disciplina Lançar Notas, Fornecer Nome, Requisitar lista de Alunos

1. 2. Conclusão da UA 1 – A Orientação a Objetos é uma TECNOLOGIA que envolve desde a concepção do sistema e da sua modelagem até a implementação utilizando linguagens orientadas a objetos.

2. A UML e o Processo de Desenvolvimento de Sistemas

2. A UML e o Processo de Desenvolvimento de Sistemas • Objetivos – Apresentar as origens da UML e suas versões; – Mostrar os diagramas da linguagem e os seus principais conceitos; – Relacionar como ocorre o processo de desenvolvimento iterativo e incremental. • Conteúdo 1. Origens da UML; 2. Versionamento da UML; 3. Diagramas da UML; 4. Rational Unified Process;

2. 1. Origens da UML

2. 1. Origens da UML • O Que é UML? – A Unified Modeling Language nasceu (1994) da junção de vários métodos (Booch, OOSE e OMT), por isso se chama unificada. – A UML é uma linguagem para especificar, visualizar, construir e documentar os artefatos de software. – Padrão OMG (UML 1. 1 – 1997) – Contribui para as melhores práticas de engenharia de software, pois é uma linguagem visual.

2. 1. Origens da UML • Definição em Três Partes – Primeiro: a UML funde os conceitos de Grady Booch, James Rumbaugh e Ivar Jacobson.

2. 1. Origens da UML • Definição em Três Partes – Segundo, a UML é genérica e flexível. – Se aplica a uma diversidade de sistemas.

2. 1. Origens da UML • Definição em Três Partes – Terceiro, a UML tem como foco uma linguagem de modelagem padronizada e não se preocupa com a metodologia de desenvolvimento. – Método = Linguagem (UML) + Processo (RUP)

2. 1. Origens da UML • Versionamento da Linguagem – Atualmente na versão 1. 5, em atualização para a 2. 0, novidades: • • • XMI, Comunication Diagram, Composite Structure Diagram, Interaction Overview Diagram, Timming Diagram (http: //www. agilemodeling. com)

2. 1. Origens da UML • Certificação em UML – Provas para UML Professional: • Iniciante (Class Diagrams, Activity diagrams, Interaction Diagrams, Use Case Diagrams, Miscellaneous basic notions) • Intermediária (Composite Structure Diagrams, Component diagrams, Action Model, Activity Diagrams, Interaction Diagrams, State Machines, Deployment diagrams) • Avançada (Class Diagrams, Composite Structure diagrams, Component diagrams, Action Model, Activity Diagrams, Deployment diagrams, State Machine Diagrams, Miscellaneous Advanced Constructs and Diagramming, Language Architecture, Object Constraint Language)

2. 2. Rational Unified Process

2. 2. Rational Unified Process • Processo de Desenvolvimento – O processo de desenvolvimento é composto por diversas fases; – Em cada fase precisamos executar diversas atividades. – Esse esforço tem como alvo principal a construção de um sistema de qualidade.

2. 2. Rational Unified Process • Origens – O RUP foi desenvolvido originalmente na Suécia por Ivar Jacobson, sendo batizado, na ocasião da sua concepção, de Objectory. – Trata-se de um processo iterativo e incremental e indica o uso da UML. – O RUP é um framework.

2. 2. Rational Unified Process • Descrição em Duas Dimensões Levantamento de Dados Concepçã Elaboração Construção o Transiç ão Análise e Projeto Implementação Teste Gerenciamento Suporte ao Desenvolvimento Suporte à Produção Tempo Iterações

2. 2. Rational Unified Process • Descrição em Duas Dimensões As “ondas” representam a carga de trabalho

2. 2. Rational Unified Process • Fase de Concepção – Na fase de concepção é estabelecido o contexto de negócio para o sistema e delimitado o escopo do projeto. – O contexto de negócio inclui também um critério de sucesso, ponderado em função de recursos e tempo. – Devemos elaborar um cronograma básico de execução com as principais fases e datas de entrega. – Nessa fase o sistema é descrito através de um texto sumário, resumindo o que é o sistema, e de um diagrama de Caso de Uso geral, contendo os atores e as suas principais funcionalidades.

2. 2. Rational Unified Process • Fase de Elaboração – Consiste de uma análise mais refinada do sistema a ser construído, juntamente com um plano detalhado de trabalho a ser feito. – Elaboração de um projeto completo, com o detalhamento de interações e estrutura do sistema. – Construir um protótipo que teste a arquitetura escolhida. – Nessa fase os Casos de Uso são completamente detalhados, são elaborados todos os diagramas de classes identificadas, são feitos protótipos das telas e o projeto lógico do banco de dados é elaborado.

2. 2. Rational Unified Process • Fase de Construção – Trabalhamos sobre o protótipo da fase anterior adicionando novas funcionalidades e refinando as funcionalidades pré-existentes. – O gerente do projeto define várias versões que devem ser liberadas a cada ciclo. – A cada ciclo é necessário rever os requisitos de cada parte da aplicação. – Nessa fase os módulos do sistema são implementados e refinados em ciclos (iterações). O projeto físico do banco de dados é implementado.

2. 2. Rational Unified Process • Fase de Transição – Nessa fase o software pode ser instalado em ambiente de produção para que os clientes possam trabalhar com ele - versão beta. – A medida em que testes são executados e melhorias são implementadas é produzida a versão final do produto. – Nessa fase, além da versão beta e do produto final, são produzidos os manuais e componentes de distribuição do software.

2. 2. Rational Unified Process • Exercício – Que documentos e produtos são obtidos a partir de cada fase do RUP? • Concepção: • Elaboração: • Construção: • Transição:

2. 3. Diagramas da UML Bloco de Construção do Aprendizado

2. 3. Diagramas da UML (V 1. 5) Diagrama de Seqüência Diagrama de Objetos Diagrama de Caso de Uso . . . Diagrama de Classe Diagrama de Colaboração Modelos Diagrama de Estado Diagrama de Atividade Diagrama de Componente Diagrama de Implantação

2. 3. Diagramas da UML Captura de Requisitos Análise e Projeto Implementação Estados Casos de Uso Sequência Distribuição Classes Colaboração Atividade (fluxo de trabalho, casos de uso) Componentes Atividade (comportamento objeto, Algoritmo, operação)

2. 3. Diagramas da UML • Cenário de uma Aplicação – Este cenário apresenta os oito tipos de diagramas UML na modelagem de um sistema de software para uma locadora de veículos.

2. 3. Diagramas da UML • Diagrama de Caso de Uso – Especifica uma interação entre um usuário e o sistema, no qual o usuário tem um objetivo muito claro a atingir. • O cliente faz a reserva de um carro; • O cliente retira o carro; • O cliente devolve o veículo.

2. 3. Diagramas da UML • Diagrama de Caso de Uso Sistema de Aluguel de Carro

2. 3. Diagramas da UML • Diagrama de Classe – A próxima tarefa é a classificação dos objetos envolvidos neste processo e a relação de uns com os outros. – Diagramas de classe mostram a estrutura geral do sistema e também as suas propriedades relacionais e de comportamento. • Cliente; • Mecânica; • Locação.

2. 3. Diagramas da UML • Diagrama de Classe Os diagramas são complementares ! Se o sistema controlar todas essas informações teremos alteração no Diag. Caso de Uso anterior

2. 3. Diagramas da UML • Diagrama de Seqüência – Mostra uma interação organizada em forma de uma seqüência, dentro de um determinado período de tempo. – Os participantes são apresentados dentro do contexto das mensagens que transitam entre eles. – O diagrama de seqüência é um diagrama de interação.

2. 3. Diagramas da UML • Diagrama de Seqüência • Reservar Carro • Curso Normal. Mensagem Tempo Objetos

2. 3. Diagramas da UML • Diagrama de Colaboração – Mostra como um grupo de objetos num caso de uso interage com os demais. – Cada mensagem é numerada para documentar a ordem na qual ela ocorre. – O diagrama de colaboração também é um diagrama de interação.

2. 3. Diagramas da UML • Diagrama de Colaboração

2. 3. Diagramas da UML • Diagrama de Estado – Mapeia diferentes estados em que se encontram os objetos, e desencadeia eventos que levam os objetos a se encontrarem em determinado estado em um dado momento.

2. 3. Diagramas da UML Diagrama de Estado – Classe Carro Início Fim Na Garagem Vendido Em manutenção Alugado

2. 3. Diagramas da UML • Diagrama de Atividade – Apresenta a lógica que ocorre em resposta a ações desencadeadas internamente. – Se reporta a uma determinada classe ou caso de uso.

2. 3. Diagramas da UML • Diagrama de Atividade • Reservar Carro O losango mostra o desvio de execução

2. 3. Diagramas da UML • Diagrama de Componentes – Mostra como os diferentes subsistemas de software formam a estrutura total de um sistema.

2. 3. Diagramas da UML • Diagrama de Componentes Linhas tracejadas indicam dependência

2. 3. Diagramas da UML • Diagrama de Implantação – Mostra como estão configurados o hardware e o software dentro de um determinado sistema.

2. 3. Diagramas da UML • Diagrama de Implantação

2. 3. Diagramas da UML • Exercício – Divida os diagramas vistos nessa seção em três grupos: – Visão dos Requisitos do Sistema: – Visão da Estrutura do Sistema: – Visão da Dinâmica do Sistema: – Visão do Funcionamento das “Partes Físicas” do Sistema:

Conclusão da UA 2 – A UML não tem uma metodologia embutida, permitindo que o desenvolvedor use os diagramas como bem entender. – Cada diagrama da UML mostra uma “visão” do sistema. Nenhum diagrama permite ter a idéia do sistema por inteiro. – O RUP é uma proposta de metodologia de desenvolvimento de sistemas que usa a UML como notação.