Linguagem de Programação II Carlos Oberdan Rolim Ciência da Computação Sistemas de Informação

Um pouco sobre UML

Diferenças de Notação As diferenças de notação são muitas, e a ordem na qual o analista desenvolve o modelo em uma e outra técnica é completamente diferente; Em técnicas Estruturadas, você coloca suas fundações sobre as Funções do sistema - Coisas que mudam a toda hora; Em OO você coloca suas fundações sobre os Dados do sistema - algo que muda e evolui, mas não de forma tão dramática, a toda hora; A UML, em especial, é uma técnica muito flexível, com uma notação estendível, o que possibilita utilizá-la em diversos aspectos de um sistema sem ter de trocar de técnica - Dados, real-time, Interface, etc… .

Diferentes padrões Em fins dos anos 80 e inicio dos anos 90 vários métodos orientados a objetos surgiram entre eles de Grady Booch, Jim Rumbaugh (OMT) e Ivar Jacobson A UML foi uma tentativa de unificar as notações destes três métodos. Foi concebida por esses profissionais A idéia era produzir um padrão com as melhores práticas adotadas pela indústria, levando mais desenvolvedores a modelar seus sistemas de software antes de construí-los

Grady Booch Um dos pioneiros da OO 1980: ênfase em técnicas de projetos para ADA 1992-1994: livros Object-Oriented Design With Applications Projeto de programas em C++ e Ada

Grady Booch 1994: Object-Oriented Analysis and Design with Applications Texto sobre conceitos de OO e modelagem de objetos Projeto de várias aplicações-exemplo com diferentes linguagens da época Base da UML 1998 Fundação da Rational

Booch

Ivar Jacobson Modelagem OO baseada em casos de uso

James Rumbaugh Object Modeling Technique (OMT) Desenvolvida na GE Metodologia baseada em notações pré- existentes (ER, DTE, DFD) Clara distinção entre as três visões do problema

OMT

Visão Geral da UML A UML é uma linguagem para: visualizar especificar construir documentar Artefatos de um sistema intensivamente baseado em software Elementos de modelagem Relacionamentos Mecanismos de extensibilidade Diagramas Orientação a Objetos 13

História da UML Desenvolvimento do UML começou no final de 1994, quando Booch e Rumbaugh passaram a trabalhar em conjunto Versão Preliminar do UML (versão 0.8) outubro de 1995, quando Jacobson se une ao grupo A partir dos esforços de Booch, Rumbaugh e Jacobson versão 0.91 (outubro de 1996), liberada para a comunidade

História da UML Uma RFP (Request for Proposal) foi realizada pela OMG (Object Management Group) buscando contribuições da comunidade para o estabelecimento de uma linguagem unificada diversas contribuições lançaram o UML 1.0 Digital Equipment Corp., HP, i-Logix, IntelliCorp, IBM, ICON Computing, MCI Systemhouse, Microsoft, Oracle, Rational Software, TI e Unisys. Em janeiro 1997, novas contribuições lançaram o UML 1.1 IBM & ObjecTime, Platinum Technology, Ptech, Taskon & Reich Technologies e Softeam

História da UML A Partir da Versão 1.1 Em novembro 1997 Em Junho 1999 comunidade de desenvolvimento de software faz uma aderência maciça ao UML Em novembro 1997 O UML 1.1 foi adotado como norma pela OMG OMG estabeleceu um RTF (Revision Task Force) para aperfeiçoar pequenos detalhes na linguagem Em Junho 1999 O RTF libera a versão UML 1.3 UML 1.4 Liberada em Setembro de 2001 UML 2.0 Liberada em Julho de 2005

Criação da UML UML 2.0 UML 1.5 UML 1.3 UML 1.1 UML 1.0 UML 0.9 Aceitação Final dOMG – Nov 1997 Submissão Final OMG – Set 1997 Primeira submissão OMG – Jan 1997 Parcerias UML Web – Junho 1996 OOPSLA ´95 feedback UML 1.5 UML 1.3 UML 1.1 UML 1.0 UML 0.9 Unified Method 0.8 Outros Métodos Método Booch OMT OOSE Orientação a Objetos 17

“Frameworks” e “patterns”, Contribuições à UML Harel Meyer Pré e Pós Condições Gamma, et al “Frameworks” e “patterns”, Máquinas de Estados HP Fusion Descrições de Operações e Numeração de Menssagens Booch Booch method Embley Classes Singleton e Visão de Alto Nível Rumbaugh OMT Jacobson OOSE Wirfs-Brock Responsabilidades Shlaer - Mellor Odell Classificação Ciclos de Vida de Objetos Orientação a Objetos 18

Sócios da UML Rational Software Corporation Hewlett-Packard I-Logix IBM ICON Computing Intellicorp MCI Systemhouse Microsoft ObjecTime Oracle Platinum Technology Taskon Sterling Software Unisys Orientação a Objetos 19

Unified Modeling Language UML significa Linguagem de Modelagem Unificada A UML combina o melhor do melhor de: Conceitos de Modelagem de Dados (Diagramas Entidade-Relacionamento) Modelagem de Negócios (Fluxo de trabalhos) Modelagem de Objetos Modelagem de Componentes A UML é a linguagem padrão para visualizar, especificar, construir e documentar os artefatos de um sistema intensamente baseado em software Pode ser usada com todos os processos, durante todo o ciclo de desenvolvimento, e com diferentes tecnologias de implementação

Modelos, Visões, Diagramas State Diagramas Classes Iteração Use Case Diagramas Caso de Uso State Diagramas Objetos Use Case Diagramas Sequência Scenario Diagramas Colaboração State Diagramas Componentes Modelos Scenario Diagramas Estado Component Diagramas Distribuição Atividade Visões dinâmicas Visões estáticas Orientação a Objetos 21

Modelos, Visões, Diagramas Visão estrutural Visão de implementação Objetos Componentes Classes Visão do usuário Caso de Uso Iteração Sequência Colaboração Distribuição Estado Atividade Visão de ambiente Visão comportamental Orientação a Objetos 22

Atenção Como o foco da disciplina é orientação a objetos não iremos nos aprofundar demais em diagramas e sim trabalharmos de forma mais intensa os conceitos envolvidos na orientação a objetos ao longo semestre. A cadeira de Engenharia de Software proporciona o conhecimento necessário e aprofundado...

O Modelo de Objetos Um modelo de objetos busca capturar a estrutura estática de um sistema mostrando os objetos existentes, seus relacionamentos, e atributos e operações que caracterizam cada classe de objetos. É através do uso deste modelo que se enfatiza o desenvolvimento em termos de objetos ao invés de mecanismos tradicionais de desenvolvimento baseado em funcionalidades, permitindo uma representação mais próxima do mundo real.

Objeto Objeto é definido como um conceito, abstração ou coisa com limites e significados bem definidos para a aplicação em questão. Objetos têm dois propósitos: promover o entendimento do mundo real e suportar uma base prática para uma implementação computacional. Não existe uma maneira “correta” de decompor um problema em objetos; esta decomposição depende do julgamento do projetista e da natureza do problema. Todos objetos têm identidade própria e são distinguíveis.

Objeto Objetos são a chave para se compreender a tecnologia orientada a objetos. Você olha ao seu redor e tudo o que vê são objetos: carro, mesa, janela, livro, pessoa, etc. Os objetos do mundo real têm duas carecterísticas em comum: ESTADO e COMPORTAMENTO. Estado O estado de um objeto revela seus dados importantes. Por exemplo, uma pessoa tem: idade, peso, altura, cor de cabelo, cor da pele. Comportamento O comportamento são as ações que aquele objeto pode exercer ou executar. Por exemplo, uma pessoa pode: andar, falar, ouvir, pular.

Objeto Esses objetos podem ser tanto objetos concretos (carro, livro, nota fiscal), quanto conceitos abstratos (conta corrente, venda, pessoa jurídica). Na Orientação a Objetos, os objetos do mundo real são modelados e representados no mundo computacional, ou seja, dentro do sistema, por meio de objetos de sotware. Cada objeto deve ser conhecido, bem definido e ter seu limite e um significado dentro do sistema. Os objetos de software, assim como os objetos do mundo real, também possuem estado e comportamento.

Classe Uma classe é um “modelo” que define as variáveis (estado) e os métodos (comportamento) comuns a todos os objetos do mesmo tipo. Um objeto nada mais é que uma instância de uma classe Ex.: Grupo de pessoas. Cada pessoa pode ser vista como um objeto mas todas elas pertencem a classe Pessoa

Representação de classes e objetos

Identificador - Nome (obrigatório) Classe Nome da classe podem ser simples ou pode ser precedido pelo nome do pacote em que a classe está contida (Exceções::ClienteCadastrado) Representação Curso Identificador - Nome (obrigatório) nome Atributos (opcional) créditos abrir() Operações (opcional) incluir()

Classe Nome da Classe Visibilidade atributo: Tipo = ValorInicial Visibilidade operação (lista arg): Tipo retorno

Atributos Representa alguma propriedade do que está sendo modelado - identifica as características próprias da classe Descrevem os dados contidos nas instâncias de uma classe Podem ser identificados apenas com nomes Podem ter seus tipos (Classes) especificados e terem valores padrão definidos

Atributos Parede altura : real largura : real espessura : real viga : boolean = false

Visibilidade Usar marcações de acesso para especificar o tipo de acesso permitido aos atributos e operações Visibilidade: + público : visível em qualquer classe # protegido : qualquer descendente poderá usar - privado : visível somente dentro da classe + saldoEM (date: Date): Money

Operações/Métodos Uma operação é uma função ou transformação que pode ser aplicada a/ou por objetos em uma classe. Por exemplo, abrir, salvar e imprimir são operações que podem ser aplicadas a objetos da classe Arquivo. Todos objetos em uma classe compartilham as mesmas operações Operação é algo que é executado em um objeto (procedimento de chamada)

Operações/Métodos Um método é a implementação de uma operação para uma classe. Descreve o comportamento da classe e por consequencia todos os objetos daquela classe

Operações/Métodos Visibilidade +público #protegido -privado

Diagrama de Classes Objetivo Descrever os vários tipos de objetos no sistema e o relacionamento entre eles. São os principais diagramas estruturais da UML As classes especificam a estrutura e o comportamento (operações) dos objetos, que são instâncias das classes

Exemplo de diagrama

Diagrama de classes Um diagrama de classes contém Entidades Representação de cada uma das pequenas partes daquilo que está se querendo representar Classes Interface  vamos ver mais adiante o que é isso Relacionamentos Representa a forma como ocorrerá o relacionamento entre as partes Associações Generalização (herança) Dependências

Atenção Novamente falando, não iremos nos deter nos vários aspectos do diagrama o qual será detalhado nas disciplinas de engenharia de software. Vamos somente ver o essencial para prosseguimento do conteúdo....

Relacionamentos **** Poucas classes vivem sozinhas **** Comunicação entre classes - definem responsabilidades Construir uma casa casa, parede, porta, janela, cômodo, luz Casa tem janelas, que têm vários tipos! Janelas podem ser abertas no sentido vertical e/ou horizontal Existem semelhanças entre as janelas e diferenças....

Relacionamentos 3 Tipos: Associações Generalização (herança) Agregação Composição Generalização (herança) Dependências

Associação Agregação Composição Herança Dependência

Associação Define um relacionamento entre duas entidades conceituais do sistema Especifica que objetos de uma classe estão conectados a objetos de outras Ex: as salas são formadas por paredes É o tipo de ligação de classe mais utilizado nos diagramas de classe

Dependência Cliente Servidor Dependência - relacionamentos de utilização, no qual uma mudança na especificação de um elemento pode alterar a especificação do elemento dependente Ex: os canos dependem do aquecedor para fornecerem água quente Indica que mudanças em um elemento (o servidor) podem afetar outro elemento (o cliente) Dependência entre classes indica que os objetos de uma classe usam serviços dos objetos de outra classe Cliente Servidor

Generalização Generalização (herança simples e múltipla) - relacionamento entre um elemento mais geral e um mais específico Herda de alguém alguma coisa ou características é um relacionamento de taxonomia entre um elemento mais geral e um mais específico, que é totalmente consistente com o primeiro, somando-o informação especializada O comportamento da classe ou característica da classe muda com relação as outras associações existentes A classe sendo refinada é chamada de superclasse ou classe base, enquanto que a versão refinada da classe é chamada uma subclasse ou classe derivada As vezes é chamada de relacionamento is-a (é-um), porque cada instância de uma classe derivada é também uma instância da classe base. Ex: Veículo terrestre pode ser do tipo automóvel ou caminhão (TIPO DE), Tipos de Animal (mamífero, ave, peixe)

Generalização

Clube Associado Dependente Exemplo de associação e dependencia

Applet HelloWorld Graphics paint() Import java.awt.Graphics; class HelloWorld extends java.applet.Applet { public void paint (Graphics g) g.drawString(“Hello, world!”, 10, 10); } HelloWorld paint() Graphics Applet

Tipos des associação (agregação ou composição) Agregação - tipo especial de associação - relacionamento “é parte de, todo/parte” (diamante aberto) O objeto que contém a referência a outros objetos (todo) PODE EXISTIR independentemente da existência dos objetos referenciados (parte). Todo Parte Agregação Estudante Disciplina

Agregação Objeto TODO mantém um ponteiro ou uma referência para Ex.: Temos o objeto Carro que por sua vez faz referência ao objeto Rodas, porém o objeto "Carro" pode existir mesmo que vc destrua "Rodas", ou seja "faz sentido a existência do carro mesmo sem seus pneus". Objeto TODO mantém um ponteiro ou uma referência para suas partes

 Composição Composição - relacionamento entre um elemento (o todo) e outros elementos (as partes) indica que as partes só podem pertencer ao “todo” e são criadas e destruídas com ele A parte não vive sem o todo O objeto que contém a referência a outros objetos NÃO FAZ SENTIDO EM EXISTIR sem a existência dos objetos referenciados. É semanticamente esquivalente a um ATRIBUTO, mas pode ser mais atraente quando a parte tem uma estrutura interna Todo Parte Composição Estudante Disciplina

Composição Ex.: Objeto Pedido que por sua vez faz referência ao objeto Itens, portanto o objeto "Itens" não faz sentido sem o objeto "Pedido". Qual o principal "conteúdo" do pedido ? São seus itens certo ?

Computador Monitor Teclado Mouse Janela Menu Botão Título

Associação x Agregação x Composição Como você modelaria: Dependente e Funcionário? Pedido e Item do pedido? Funcionário e Cartão de ponto? Carro, Roda, Direção e Carburador? Na dúvida, use agregação! Na dúvida, use associação!

Multiplicidade Multiplicidade define quantos objetos participam do relacionamento O número de instâncias de uma classe relacionada a uma instância de outra classe Especificado em cada uma das pontas da associação A multiplicidade em uma das extremidades da associação especifica para cada objeto da classe encontrada na extremidade oposta deve haver a determinada quantidade de objetos na extremidade próxima

Tipos de Multiplicidade Não especificada Exatamente um Zero ou mais Muitos (mesmo que 0..*) Um ou mais Zero ou um Intervalo determinado Valores múltiplos 1 0..* * 1..* 0..1 2..4 2, 4..6

Exemplo: Multiplicidade Disciplina Estudante 1 1..* Uma instância de Disciplina pode conter 1 ou mais Estudantes Uma instância de Estudante pode 1 Disciplina

Navegação Especifica a direção da associação Associações e agregações são bidirecionais por default Disciplina Estudante 1 1..* Navegação Nesse caso Disciplina não sabe o vinculo de multiplicidade com Estudante

1..* Trabalha para * Pessoa Empresa  funcionário empregador 1 * Departamento

Notações Diagrama de classe Nome das classes sõa substantivos Primeiro caractere maiúsculo (Customer, java::awt::Rectangle) Atributo: substantivo, aparece como maiúsculo o primeiro caractere de cada palavra existente no nome do atributo, exceto a primeira letra: nomeProfessor Operação verbo ou locução verbal, aparece como maiúsculo o primeiro caractere de cada palavra existente no nome da operação, exceto a primeira letra: isEmpty

Sugestões de desenvolvimento Não comece a construir um modelo de objetos simplesmente definindo classes, associações e heranças. A primeira coisa a se fazer é entender o problema a ser resolvido. Tente manter seu modelo simples. Evite complicações desnecessárias. Escolha nomes cuidadosamente. Nomes são importantes e carregam conotações poderosas. Nomes devem ser descritivos, claros e não deixar ambiguidades. A escolha de bons nomes é um dos aspectos mais difíceis da modelagem. Não ”enterre” apontadores ou outras referências a objetos dentro de objetos como atributos. Ao invés disto, modele estas referências como associações. Isto torna o modelo mais claro e independente da implementação.

Sugestões de desenvolvimento Tente evitar associações que envolvam três ou mais classes de objetos. Muitas vezes, estes tipos de associações podem ser decompostos em termos de associações binárias, tornando o modelo mais claro. Não transfira os atributos de ligação para dentro de uma das classes. Tente evitar hierarquias de generalização muito profundas. Não se surpreenda se o seu modelo necessitar várias revisões; isto é o normal. Nem sempre todos os símbolos são necessárias para descrever uma aplicação. Use apenas aquelas que forem adequadas para o problema analisado.