UML & Padrões Aula 1 Apresentação Profª Kelly Christine C. Silva
Sistemas para Internet Módulo I - Construção de sites informativos Módulo II - Construção de sites dinâmicos Módulo III - Aplicações para a Internet Módulo IV - Aplicações para a Internet Módulo V - Integração de aplicações WEB Unidade Curricular: UML e Padrões de Projeto 2
Sistemas para Internet UML & Padrões de Projeto Ao final do Curso, o aluno deverá ser capaz de: UML Utilizar os diagramas UML para modelar sistemas orientados a objetos; Utilizar ferramentas CASE no processo de modelagem; DESIGN PATTERNS Identificar e classificar padrões de software; Aplicar padrões na busca de soluções na fase de projeto de software. Bases Tecnológicas, científicas e instrumentais: Notação UML; Ferramentas CASE; Diferenças entre arquitetura e design; Design Patterns. 3
Aulas: Dia da Semana: 2ª feira Horário: 18:15 h às 22:30 h 1º Parte -18:15 às 20:15 Aula Teórica Slides ou Quadro branco 2ª Parte 20:30 às 22:30 Laboratório Listas de exercícios 4
Avaliação: 1º Bimestre - UML Acompanhamento diário e participação nas aulas Listas de exercícios semanais Prova 2º Bimestre Padrões de Projeto Acompanhamento diário e participação nas aulas? Trabalho Entrega e Apresentação Prova Prova Extra para quem não conseguiu média 5
Cronograma: AULA DATA CONTEÙDO 1 30/07/12 Apresentação do professor, conteúdo, avaliação e bibliografia Aula 1: s 2 06/08/12 Aula 2: s Diagrama de Objetos Lista de Exercícios 1 3 13/08/12 Aula 3: Diagrama de Caso de Uso Lista de Exercícios 2 4 20/08/12 Aula 4: Diagramas UML Estruturais ( Estáticos ): Diagrama de Pacotes, Componentes e de Instalação Lista de Exercícios 3 5 27/08/12 Aula 5: Diagramas Comportamentais (Dinâmicos): Atividades, Máquina de Estado Lista de Exercícios 4 6 03/09/12 Aula 6: Diagramas Comportamentais (Dinâmicos): Diagrama de Sequência Diagrama de Colaboração o u Comunicação 7 10/09/12 Correção das Listas Dúvidas e Exercícios Extras 8 17/09/12 Avaliação 1: Prova Escrita 9 24/09/12 Aula 7: Introdução a Padrões de Projeto Padrão GRASP 6
Cronograma: AULA DATA CONTEÙDO 10 01/10/12 Aula 8: Padrões de Projeto Padrões GoF 11 08/10/12 Aula 9: GoF Padrões de Interface Implementação 12 15/10/12 Aula 9: GoF Padrões de Responsabilidade Implementação 13 22/10/12 Aula 9: GoF Padrões de Construção Implementação 14 29/10/12 Aula 10: Padrao MVC e Padrão DAO 15 05/11/12 Apresentação em grupo dos Padrões 16 12/11/12 Avaliação 2: Prova Escrita 17 19/11/12 Correção e entrega da Prova Últimas dúvidas 18 26/11/12 Avaliação 3: Prova Escrita 19 03/12/12 Correção e entrega das provas 20 10/12/12 Encerramento do Período 7
Bibliografia: Bibliografia utilizada: 1. Slides das aulas Bibliografia: 1. The Unified Modeling Language User Guide. Booch G., Rumbaugh J., Jabobson I.. Ed. Addison-Wesley. 2. Utilizando UML e Padrões. Larman C.. Ed. Bookman. 3. UML Essencial Um breve guia para a linguagem padrão de modelagem de objetos. Fowler M., Scott K. Ed. Bookman. 4. Design Patterns Elements of Reusable Object-Orientated Software. Gamma, E., Helm R., Johnsan R., Vlissides J.. Addison-Wesley, 1995. 8
Softwares para Modelagem: Software Proprietário - Poseidon (livre) Gentleware - Rational Rose IBM-Rational - Argo-UML Tigris - Eclipse UML Omondo - JDeveloper Oracle - JVISION Object Insight - Jude Astah 9
Softwares para Modelagem: 10
PARTE I : UML 11
UML UML Unified Modeling Language UML é uma Linguagem de modelagem que consiste em uma notação, principalmente gráfica, utilizada por métodos para expressar projetos. Não é um método. A maioria dos métodos consiste em uma linguagem de modelagem (LM) e um processo. Entenda-se por processo a sugestão de passos a serem seguidos para a elaboração de um projeto. UML = LM Método = LM + Processo 12
UML A UML tem origem na compilação das "melhores práticas de engenharia" que provaram ter sucesso na modelagem de sistemas grandes e complexos. Sucedeu aos conceitos de OOD (Booch), OMT (Rumbaugh) e OOSE (Jacobson) fundindo-os numa única linguagem de modelagem comum e largamente utilizada. Jacobson (OOSE) Booch (OOD) Rumbaugh (OMT) OOSE OOD OMT : Oriented Object Software Engeneering : Oriented Object Design : Object Modeling Technic 13
História 1994: Início do Projeto 1995: o esboço da versão 0.8 do Unified Process - Processo Unificado (como era conhecido). Expansão do projeto para incorporar OOSE (Jacobson) Versão 0.9 da UML Em 1997, a UML foi aprovada como padrão pelo OMG (Object Management Group), um consórcio internacional de empresas que define e ratifica padrões na área de Orientação a Objetos. 1999: UML 1.3 2001 : UML 1.4 2002 : UML 2.0 14
Evolução da UML Após alcançar essa versão, a OMG passou a adotá-la como padrão e a se responsabilizar pelas revisões, que são controladas a não provocar uma grande mudança no escopo original, para não haver grande impacto, o que facilitou sua disseminação pelo mundo. 15
Diagramas Os diagramas utilizados pela UML 1 (9 diagramas) se dividem em dois grupos: - Diagramas Estruturais - Diagramas Comportamentais de classes de objetos de componentes * de implantação * de casos de uso (requisitos) de sequência de colaboração de estados de casos de uso (de contexto) * de atividades * Diagramas Funcionais 16
Diagramas Os diagramas utilizados pela UML 1 (9 diagramas) se dividem em dois grupos: 17
Diagramas Representação gráfica parcial ou total de um modelo. A UML 2 define 13 tipos de diagramas divididos em 2 categorias: - Diagramas Estruturais Pacotes Classes Objetos Estrutura Composta Componentes Instalação - Diagramas Comportamentais Casos de uso Atividades Máquina de estado Colaboração ou Comunicação Sequência Tempo Interatividade 18
Diagramas Representação gráfica parcial ou total de um modelo. A UML 2 define 13 tipos de diagramas divididos em 2 categorias: novo 19
Diagramas Representação gráfica parcial ou total de um modelo. A UML 2 define 13 tipos de diagramas divididos em 2 categorias: novo 20
Diagramas estáticos ou estruturais definem estaticamente a arquitetura de um modelo. São usados para modelar classes, objetos, relações e componentes físicos que compõem um modelo. Além disso, também são usados para modelar os relacionamentos e as dependências entre elementos. 21
MODELAGEM DINÂMICA OU COMPORTAMENTAL Os diagramas dinâmicos ou de comportamento apresentam as variedades da interação e do estado instantâneo dentro de um modelo enquanto é executado. 22
MODELAGEM ESTÁTICA Diagrama de Objetos 23
Conceitos: Classe Objeto Relacionamentos: Os relacionamentos ligam as classes/objetos entre si criando relações lógicas entre estas entidades. Os relacionamentos podem ser dos seguintes tipos: - Associação - Generalização - Agregação - Composição - Dependência - Refinamento 24
Conceitos: Representação de uma classe Cliente Nome : String Idade : Num Criar () Destruir () Nome da Classe Atributos Operações Representação de um objeto Marcia Moita:Cliente Nome : Marcia Moita Idade : 20 Criar () Destruir () Nome do Objeto Atributos Operações 25
Conceitos: Atributos : características que uma dada classe possui. visibilidade <nome do atributo> : tipo Visibilidade: # protected (protegido) somente a classe e suas sub-classes têm acesso + public ( público ) outros objetos podem ter acesso - private ( privado ) visível apenas dentro da classe Nome do atributo : palavra que define o atributo (normalmente um substantivo) Tipo: primitivo ou estrutura de dados ou classe (do Java ou criada pelo programador ) String, hora, numero, booleano, data int[ ], String[ ] Pessoa Obs.: se o atributo se tornou muito complexo (possuindo seus próprios dados), ele deixa de ser um atributo e torna-se uma outra classe. 26
Conceitos: Exemplo: Em uma loja, um cliente possui nome, cpf, telefone e endereço. Cliente - nome : String - cpf : String - telefone: num Em um sistema bancário, uma conta possui um número, um saldo. Conta - endereço: String - numero : num - saldo : num 27
Conceitos: Métodos: comportamento de uma dada classe. visibilidade <nome do método> (lista_parametros) : tipo_retorno Visibilidade: # protected (protegido) somente a classe e suas sub-classes têm acesso + public ( público ) outros objetos podem ter acesso - private ( privado ) visível apenas dentro da classe Nome do método: é uma String (normalmente um verbo) Lista_parametros: contém parâmetros separados por vírgulas. Tipo_retorno: é uma lista de tipos de retorno separados por vírgulas. Em Java há somente um tipo de retorno. 28
Conceitos: Exemplo: No sistema bancário do exemplo anterior, a classe Conta tem os métodos: sacar um dado valor do seu saldo; depositar um dado valor e imprimir seu saldo. Conta - numero : double -saldo : double + sacar(double valor) : booleano Verificar se a operação teve sucesso + depositar(double valor) + imprimirsaldo() 29
Conceitos: Ainda sobre métodos: {query} : métodos que obtém um valor da classe, mas não modificam o estado do sistema Modificadores : operações que mudam o estado do sistema Métodos de leitura (getters) : lê um atributo e não faz mais nada Métodos de modificação (setters ) : altera um atributo e não faz mais nada 30
Métodos x Operação Operação: é executado em um objeto (o procedimento de chamada ) Método: corpo de um procedimento. Obs.: Fácil de observar quando se tem polimorfismo. Ponto - coordx : int - coordy : int 31
Relacionamentos: Associação Generalização Navegabilidade Agregação Composição Realização Dependência 32
Relacionamentos: Associação : - Normal - Ordenada - Recursiva - de Classe - Qualificada - Ternária - Exclusiva 33
Associação Normal Tipo mais comum de associação, representada por uma linha sólida entre 2 classes. Possui um nome (junto à linha que representa a associação), normalmente um verbo, mas substantivos também são permitidos. Pode-se também colocar uma seta no final da associação, indicando que esta só pode ser usada para o lado onde a seta aponta. Associações também podem possuir 2 nomes, um para cada sentido da associação. Cliente possui écontrolada Conta Corrente 34
Associação Normal Para expressar a multiplicidade entre os relacionamentos, um intervalo indica quantos objetos estão relacionados no link. O intervalo pode ser de zero para um (0..1), zero para vários (0..* ou apenas *), um para vários (1..*), e assim por diante. Se não for descrita nenhuma multiplicidade, então é considerado o padrão de um para um (1..1 ou apenas 1). Cliente possui 1 1..3 Conta Corrente 35
Associação Recursiva É possível conectar uma classe a ela mesma através de uma associação que ainda representa semanticamente a conexão entre dois objetos, mas os objetos conectados são da mesma classe. Esposa Pessoa Marido é casado com 36
Associação Qualificada Usada com associações de um para vários (1..*) ou vários para vários (*). O "qualificador" (identificador da associação qualificada) especifica como um determinado objeto no final da associação "n" é identificado, e pode ser visto como um tipo de chave para separar todos os objetos na associação. O identificador é desenhado como uma pequena caixa no final da associação junto à classe de onde a navegação deve ser feita. Cliente Cód_CC * Conta Corrente 37
Associação Exclusiva Em alguns modelos nem todas as combinações são válidas, e isto pode causar problemas que devem ser tratados. Uma associação exclusiva é uma restrição em duas ou mais associações. Ela especifica que objetos de uma classe podem participar de no máximo uma das associações em um dado momento. Uma associação exclusiva é representada por uma linha tracejada entre as associações que são parte da associação exclusiva, com a especificação "{ou}" sobre a linha tracejada. Contrato 1..* Pessoa {ou} 1..* Empresa Um contrato não pode se referir a uma pessoa e a uma empresa ao mesmo tempo, significando que o relacionamento é exclusivo a somente uma das duas classes 38
Associação Ordenada As associações entre objetos podem ter uma ordem implícita. O padrão para uma associação é ser desordenada (ou sem nenhuma ordem específica). Mas uma ordem pode ser especificada através da associação ordenada. Este tipo de associação pode ser muito útil, por exemplo, em casos como janelas de um sistema que têm que ser ordenadas na tela (a ordem de abertura e fechamento). A associação ordenada pode ser escrita apenas colocando a restrição "{ordenada}" junto à linha de associação entre as duas classes. {ordenada} Cliente * Pedido 39
Associação de Classe (ou Classe Associativa) Uma classe pode ser associada a uma outra associação. Este tipo de associação não é conectada a nenhuma das extremidades da associação já existente, mas na própria linha da associação. Esta associação serve para se adicionar informações extra a associação já existente. Trata-se da entidade associativa. Cliente * * Processo Fila 40
Associação Ternária Mais de duas classes podem ser associadas entre si e a associação ternária associa três classes. Ela é mostrada como um grade losango e ainda suporta uma associação de classe ligada a ela, onde se traçaria uma linha tracejada a partir do losango para a classe associativa. Contrato 0..* 1..* Cliente 1..* Regras Contratuais 41
Agregação Caso particular da associação que indica que uma das classes do relacionamento é uma parte, ou está contida em outra classe. As palavras chaves usadas para identificar uma agregação são: "consiste em", "contém", "é parte de". Existem tipos especiais de agregação: - Agregação Compartilhada - Agregação Composta 42
Agregação Quando uma das classes é uma parte, ou está contida na outra. Marinha 1 contém * Navios A Marinha contém navios. Navios são parte da Marinha. 43
Agregação Compartilhada Quando uma das classes é uma parte, ou está contida em outra classe, mas também é parte de outras. Time * Membros * Pessoa Uma pessoa pode ser membro de um ou vários times em determinado momento 44
Agregação Composta ou Composição É uma agregação com uma ligação mais forte entre partes e todo. Uma classe que está contida na outra "vive" e constitui a outra. Se o objeto da classe que contém for destruído, as classes de composição serão destruídas também, já que as mesmas fazem parte da outra. * Texto DEBRET * Botão DEBRET Sítio DEBRET * * ListBox DEBRET Menu DEBRET 45
Generalização É um relacionamento entre um elemento geral e um outro mais específico. O elemento mais específico possui todas as características do elemento geral e contém ainda mais particularidades. Um objeto mais específico pode ser usado como uma instância do elemento mais geral, ou seja, pode ser usado onde o elemento mais geral seja permitido. A generalização, também chamada de herança, permite a criação de elementos especializados em outros. 46
Generalização Existem alguns tipos de generalizações que variam em sua utilização a partir da situação. São elas: generalização normal ou restrita. Generalização Normal Generalização Restrita Sobreposta ou Disjuntiva Completa ou Incompleta 47
Generalização Normal A classe mais específica, chamada de subclasse, herda tudo da classe mais geral, chamada de superclasse. Os atributos, operações e todas as associações são herdados. A generalização normal é representada por uma linha entre as duas classes que fazem o relacionamento, sendo que coloca-se um seta no lado da linha onde encontra-se a superclasse indicando a generalização. Conta Poupança 48
Generalização Restrita Uma restrição aplicada a uma generalização especifica informações mais precisas sobre como a generalização deve ser usada e estendida no futuro. As restrições a seguir definem as generalizações restritas com mais de uma subclasse: - Sobreposta ou Disjuntiva - Completa ou Incompleta 49
Generalização de Sobreposição Quando subclasses herdam de uma superclasse por sobreposição, o elemento pode pertencer ao mesmo tempo as duas subclasses. A {sobreposição} Animal {sobreposição} B C... N {sobreposição}: B, C,... N podem ocorrer simultaneamente AnimalCarnívoro AnimalHerbívoro Pode haver um animal onívoro 50
Generalização de Disjunção Uma restrição simbolizando uma disjunção, é a utilizada como padrão e significa que um elemento pertence a somente uma subclasse. A Funcionário {disjunção} {disjunção} B C... N Gerente NãoGerente {disjunção}: B, C,..., N são mutuamente exclusivos 51
Generalização Completa Uma restrição simbolizando uma generalização completa, significa que todas as subclasses já foram especificadas, e não existe mais possibilidade de outra generalização a partir daquele ponto. A Pessoa {completa} {completa} B C... N Homem Mulher {completo}: N é conhecido 52
Generalização Incompleta É exatamente o contrário da completa e é assumida como padrão da linguagem. A Veículo {incompleta} {incompleta} B C... N Carro Caminhão {incompleto}: N não é conhecido 53
Dependência O relacionamento de dependência é uma conexão semântica entre dois modelos de elementos, um independente e outro dependente. Uma mudança no elemento independente irá afetar o modelo dependente. Os modelos de elementos podem ser uma classe, um pacote, um use-case e assim por diante. As classes "Amigas" provenientes do C++ são um exemplo de um relacionamento de dependência. Classe A <<friend>> Classe B 54
Refinamento Relacionamento entre duas descrições de uma mesma entidade, mas em níveis diferentes de abstração. Os refinamentos são um tipo de relacionamento entre duas descrições de uma mesma coisa, mas em níveis de abstração diferentes e podem ser usados para modelar diferentes implementações de um mesmo elemento (uma implementação simples e outra mais complexa, mas também mais eficiente). Classe de Análise Classe de Design 55