Slide 1

Nome: Lucas Alves Martins Rodney Garcia Prof: Flvia Balbino Universidade Castelo Branco

Slide 2

Identificar agregaes As hierarquias de agregao, tambm conhecidas como hierarquias de parte-todo entre duas ou mais classes distintas possibilitam representar uma abstrao a partir das partes em que a compem. Alm disso, o fato de cada parte poder possuir seus prprios componentes, possibilita uma refatorao recursiva.

Slide 3

Identificar agregaes De uma maneira geral, dadas duas classes (A e B), podemos dizer que B agrega A quando: (i) A uma parte fsica ou lgica de B; (ii) A est contida em B; (iii) A um item de uma transao ou relatrio B; (iv) A um membro de B; (v) A uma sub-unidade organizacional de B; e (vi) A possudo por B.

Slide 4

Identificar agregaes Exemplo:

Slide 5

Identificar Herana A identificao de relacionamentos de herana mais simples do que a de associaes. Para encontrar relacionamentos de herana entre as classes de anlise identificadas, basta estud-las e procurar por relaes do tipo -um-tipo-de entre elas.

Slide 6

Identificar Herana Um exemplo claro no sistema de biblioteca o relacionamento entre a classe Usurio e as classes Atendente, Aluno e Professor. Alm disso, as classes Peridico, Livro, Tese e Manual podem ser consideradas como sub-tipos de Publicao. A relao das classes identificadas para o sistema pode ser identificada a partir do domnio do problema ou do dicionrio de dados.

Slide 7

Identificar Herana

Slide 8

Aps a identificao dos relacionamentos de herana, pode ser necessrio refatorar as associaes entre as classes. Essa refatorao tem o objetivo principal de mover as associaes comuns a todas as classes derivadas (filhas) para a classe base (superclasse). Alm disso, a existncia de hierarquias de generalizao e especializao bem estruturada possibilitaro outros benefcios ao modelo.

Slide 9

Identificar Herana A figura a seguir apresenta o diagrama de classes de anlise depois da adio de associaes, agregaes e relacionamentos de herana. Devido ao excesso de agregaes entre a classe Sistema e as demais classes modeladas, essa informao conceitual de composio das partes do sistema pode ser expressada atravs do conceito de mdulo, que pode ser representado por pacotes UML.

Slide 10

Identificar Herana

Slide 11

Identificar Atributos das Classes de Anlise No ltimo estgio da modelagem esttica, so identificados os atributos das classes de anlise. Porm, nem todos os atributos precisam ser encontrados durante a anlise; esperado que uma parte deles pertena soluo e por isso devem ser identificadas durante a fase do projeto.

Slide 12

Identificar Atributos das Classes de Anlise Os atributos que so identificados durante a fase de anlise, ou so inerentes ao domnio da aplicao, ou so aqueles que representam informaes relevantes para a realizao dos casos de uso, isto , aqueles que representam informaes explicitadas na especificao dos casos de uso. Sendo assim, esses atributos quase sempre esto associados a classes de entidade.

Slide 13

Identificar Atributos das Classes de Anlise Essas classes normalmente s precisam ter estado se for necessrio guardar informaes relativas interao com um certo usurio, por exemplo informaes de sees, utilizadas no caso de vrios usurios acessarem o sistema ao mesmo tempo. Mas normalmente esse tipo de informao s levado em considerao e identificado a partir da fase de projeto.

Slide 14

Identificar Atributos das Classes de Anlise A identificao dos atributos feita de maneira anloga identificao das classes, isto , os atributos normalmente so identificados atravs da anlise do domnio e do estudo das especificaes dos casos de uso do sistema, do enunciado do problema e do dicionrio de dados.

Slide 15

Identificar Atributos das Classes de Anlise De uma maneira em geral, eles podem ser identificados a partir das classes candidatas descobertas atravs da anlise textual desses artefatos, mais especificamente, a partir das classes descartadas no refinamento do diagrama de classes de anlise.

Slide 16

Identificar Atributos das Classes de Anlise Esses atributos normalmente representam conceitos simples que podem ser expressados usando-se tipos primitivos, como inteiros e caracteres. Quando no o caso, comum criar novas classes que representam registros de dados, onde cada atributo representa um campo de registro.

Slide 17

Identificar Atributos das Classes de Anlise Para enfatizar a sua importncia, alguns autores do a essas classes o esteretipo >. Exemplos de classes que normalmente definem tipos de dados so Endereo, Cor, Telefone, Ponto cartesiano, etc.

Slide 18

Identificar Atributos das Classes de Anlise De um modo em geral, se um atributo de uma classe muito complexo, provavelmente ele deveria ser definido como uma classe parte. Depois, se for necessrio, as classes de atributos podem ser facilmente transformadas em atributos na fase de projeto do sistema.

Slide 19

Atributos das Classes de Anlise no Estudo de Caso Olhando rapidamente a lista de classes eliminadas a seguir, percebemos que vrias delas no se tornaram classes de anlise por representarem, na verdade, atributos de outras classes. Alm dessas informaes, possvel extrair algumas outras examinando a especificao do dicionrio de dados e os atributos inerentes ao domnio da aplicao.

Slide 20

Atributos das Classes de Anlise no Estudo de Caso *Categorias e Entidades identificadas para o sistema da biblioteca. Classes eliminadas: Exemplar,Bibliotecria, Sistema de cadastro de publicaes e usurios, Devoluo com atraso, Bloqueio e Desbloqueio.

Slide 21

Atributos das Classes de Anlise no Estudo de Caso A tabela a seguir associa os atributos identificados s classes correspondentes:

Slide 22

Atributos das Classes de Anlise no Estudo de Caso *Atributos identificados para o sistema de bibliotecas.

Slide 23

Atributos das Classes de Anlise no Estudo de Caso Algumas informaes foram modificadas para se tornarem mais simples e de acordo com as orientaes descritas na imagem anterior. Por exemplo, o perodo de um emprstimo foi definido atravs de dois atributos: a data em que o emprstimo foi realizado (data emprstimo) e a data esperada para a devoluo data de devoluo.

Slide 24

Atributos das Classes de Anlise no Estudo de Caso Tambm podem ser adicionados ao modelo de anlise atributos bvios, relativos ao domnio e que no apareceram na descrio dos casos de uso analisados. Deve-se ter cuidado, porm, com a definio do que ou no inerente ao domnio. Por exemplo, no nosso estudo de caso, perfeitamente coerente adicionar o atributo Ttulo classe Publicao, j que qualquer publicao tem um ttulo.

Slide 25

Atributos das Classes de Anlise no Estudo de Caso Por outro lado, apesar de tentador, no adequado adicionar um atributo Autor a essa classe, j que, entre as publicaes com as quais o sistema deve lidar, esto peridicos, publicaes para as quais o conceito de autor normalmente no faz sentido.

Slide 26

Atributos das Classes de Anlise no Estudo de Caso A figura a seguir apresenta o diagrama de classes de anlise depois de adicionados os atributos identificados anteriormente:

Slide 27

Atributos das Classes de Anlise no Estudo de Caso

Slide 28

Identificar Classes de Anlise O processo RUP sugere que classes de anlise sejam dividas em trs grupos, a fim de classificar os elementos de acordo com o seu papel no modelo. O principal objetivo dessa classificao e simplificar a transio da anlise para o projeto. Os trs grupos definidos so: Classes de entidade Classes de controle Classes de fronteira

Slide 29

Classe de Entidade Representao dos conceitos do domnio do problema Informaes e regras de negcio que direcionam a manipulao dessas informaes Tambm chamadas de classes de negcio A maioria j descoberta na fase de anlise Aspecto importante a analisar: quais geram objetos que devam ser persistentes Definir o mecanismo de persistncia Prtica interessante: Para ajudar na identificao nica de objetos de uma classe, sugere-se a criao de um atributo identificador de implementao (identificador ou id) do tipo Inteiro id) do tipo inteiro Muito teis em caso de mapeamento para mecanismos de armazenamento persistente

Slide 30

Classes de Fronteira Interao com os elementos externos Apresentao de informaes Captao de informao Classes de fronteira NO devem ter responsabilidades relativas as regras de negcio da Aplicao Exemplo: uma classe para representar um formulrio de inscrio em uma escola Tipos de fronteira: Classes de interface com o usurio Classes de interface com equipamentos Classes de interface com outros sistemas As formas de interao do sistema com o ambiente influenciam no projeto arquitetural do mesmo

Slide 31

Classes de Fronteira Clientes WEB clssicos Representao na forma de classes de pginas WEB estticas e dinmicas Clientes mveis Classes de fronteira em protocolos especficos Clientes stand-alone Janelas, menus, formulrios, botes, etc. Servios WEB (WEBservices) Servios da aplicao disponveis pela Internet

Slide 32

Classes de Fronteira

Slide 33

Classes de Controle Responsveis por coordenar a interao entre os demais objetos Normalmente podem haver vrias classes de controle em uma aplicao Uma para cada aspecto da soluo Responsabilidades: Preenchimento de controles da interface grfica Autenticao de usurios Controle de acesso s funcionalidades do sistema Tipo comum de classe de controle o controlador de caso de uso Coordenar a realizao de um caso de uso Servir de canal de comunicao entre os objetos de Fronteira e os objetos de entidade

Slide 34

Classes de Controle Mapeando aes dos atores em mensagens para objetos de entidade Comunicar-se com outros controladores, quando for necessrio Estar apto a manipular excees Em uma aplicao WEB comum o uso de um front controller (FC) Receber as requisies de um cliente Identificar o controlador adequado para processar a Redirecionar para o controlador adequado Caractersticas a serem evitadas Acoplamento excessivo Repetio de cdigo

Slide 35

Relacionamento entre Classes Os objetos tem relaes entre eles: um professor ministra uma disciplina para alunos numa sala, um cliente faz uma reserva de alguns lugares para uma data, etc. Essas relaes so representadas tambm no diagrama de classe. Geralmente as classes no esto ss e se relacionam entre si. O relacionamento e a comunicao entre as classes definem responsabilidades E um dos principais diagramas da UML define o esqueleto do sistema Ha tres tipos de relacionamientos entre classes: associao, agregao e generalizao

Slide 36

Associao E o tipo de relacionamento mais comum e mais importante em um sistema orientado a objetos E um relacionamento ou ligacao entre duas classes permitindo que objetos destas possam se comunicar Objetivo essencial da associacao: possibilitar a comunicacao entre objetos de duas classes A comunicacao pode ser uni ou bidirecional Segmento de reta ligando as duas classes Associacao unidirecional: inclui-se uma seta na extremidade de destino Pode-se incluir um nome na associacao Indica a natureza ou finalidade da comunicacao

Slide 37

Associao

Slide 38

Papeis das classes Pode-se incluir uma indicacao dos papeis das classes nas associacoes Nao e comum indicar o nome da associacao e os papeis das classes para uma mesma associacao opta-se por uma ou outra

Slide 39

Associao

Slide 40

Cardinalidade Especifica o numero de objetos de cada classe envolvidos com a associacao Quando nao ha especificacao, entende-se que a cardinalidade e 1

Slide 41

Associao

Slide 42

A leitura da cardinalidade exige cuidados: Deve-se fazer a leitura de forma distinta para os dois sentidos da associao Para cada um dos sentidos: Deve-se esquecer a cardinalidade no extremo de inicio Deve-se considerar que existe a associao de um objeto da classe de inicio com vrios objetos da classe de destino

Slide 43

Agregaco Relacionamento de pertinncia entre classes Permite a incluso de objetos de uma classe no interior de objetos de outra classe Relao 'parte-de', 'tem-um', 'todo-parte' Objeto que agrega conhece o agregado mas este no conhece aquele comunicao unidirecional Notao UML: segmento de reta ligando a classe dos objetos que agregam a classe dos objetos agregados

Slide 44

Agregaco Na extremidade da classe dos objetos que agregam inclui-se um losango:

Slide 45

Agregaco

Slide 46

Cardinalidade Numero de objetos envolvidos na relacao Um objeto pode incluir varios outros mas nao pode estar contido em mais de um objeto i.e. cardinalidade no lado da classe dos objetos que agregam sera sempre 1

Slide 47

Associao A leitura da cardinalidade exige cuidados: Deve-se fazer a leitura de forma distinta para os dois sentidos da associacao Para cada um dos sentidos: Deve-se esquecer a cardinalidade no extremo de inicio Deve-se considerar que existe a associacao de um objeto da classe de inicio com varios objetos da classe de destino

Slide 48

Associao Relacionamento de pertinncia entre classes Permite a incluso de objetos de uma classe no interior de objetos de outra classe Relao 'parte-de', 'tem-um', 'todo-parte' Objeto que agrega conhece o agregado mas este no conhece aquele comunicao unidirecional Notao UML: segmento de reta ligando a classe dos objetos que agregam a classe dos objetos agregados

Slide 49

Associao Na extremidade da classe dos objetos que agregam inclui-se um losango:

Slide 50

Associao Exemplo: um objeto da classe CCarro contem 4 objetos da classe CRoda e 5 objetos da classe Cporta:

Slide 51

Associao

Slide 52

No existe uma tcnica precisa para de se definir as agregaes em um sistema Sugestes: definio das agregaes a partir de decomposies quando uma classe tem muitas responsabilidades, tende-se a dividi-la. Tal diviso pode fazer com que a classe perca sua identidade neste contexto, as agregaes so muitos uteis porque dividem uma classe grande em outras menores, sem que a grande perca a identidade definio das agregaes a partir de composies raciocinio e o inverso ao da decomposicao procura-se identificar conjuntos de objetos que juntos compoem objetos maiores

Slide 53

Associao definio de agregaes a partir de partes comuns quando se percebe dentro de duas ou mais classes um conjunto de atributos e/ou mtodos semelhantes se estes juntos possuem uma identidade, ento poderia ser criada uma nova classe:

Slide 54

Agregao Definicao de agregacoes a partir de partes comuns

Slide 55

Generalizao/Especializao de classes Relacionamento estrutural entre duas classes classe base (superclasse) classe base (subclasse) Herana (relacionamento 'e um' a derivada herda as propriedades da base

Slide 56

Generalizao/Especializao de classes

Slide 57

Padres de Modelagem Desenvolvedores experientes de sistemas orientados a objetos construram ao longo dos anos um repertrio de solues para problemas comuns encontrados durante o desenvolvimento. Para serem consideradas como padres, essas solues, devem ser validadas atravs do uso em diversas circunstncias distintas, especificadas de uma maneira estruturada que descreve tanto a soluo quanto o problema que ela se prope a resolver.

Slide 58

Padres de Modelagem Inicialmente, os padres surgiram no contexto do projeto arquitetnico, na construo ao civil [1]. Segundo Christopher Alexander, cada padro descreve um problema que ocorre recorrentemente em nosso ambiente e uma soluo para ele, de tal maneira que se pode usar essa soluo vrias vezes e de diversas maneiras [1]. No desenvolvimento de software, padres podem ser encontrados em diversas circunstncias diferentes. Padres de projeto foram os primeiros a aparecer [19] e no demorou muito para que uma mirade de outros, como padres arquiteturais [10], anlise [18] e de implementao [29] surgissem. Atualmente, padres de variados tipos so empregados em projetos de desenvolvimento

Slide 59

Padres de Modelagem para tornar os sistemas construdos mais fceis de entender e manter, alm de facilitar a reutilizao de suas partes Em geral, um padro tem quatro elementos fundamentais: 1. Nome do padro: um identificador que podem ser utilizados para descrever um problema, sua soluo e suas consequncias em uma ou duas palavras. 2. Problema: uma descrio de quando aplicar o padro. Ele explica o problema que o padro Um exemplo de padro de anlise que discutimos neste captulo foi o padro

Slide 60

Padres de Modelagem Controlador [29], apresentado como parte do padro de anlise MVC (Seo 3.10.1). Este padro consiste em atribuir a uma classe a responsabilidade de tratar os eventos do sistema, sendo responsvel por implementar a lgica do negcio. Esse padro de anlise descrito resumidamente a seguir: Nome: Controlador Problema : definir qual classe implementa as regras do negcio e e responsvel por lidar com os eventos do sistema. Soluo : atribuir essa responsabilidade a uma classe cujo propsito justamente lidar com esses eventos e implementar as regras de negcios. Essa classe representa a inteligncia do sistema. Consequncias: (i) aumenta o potencial para reutilizao, j que separa o controle de outras caractersticas do sistema, como a interface com o usurio e a representao dos dados; e (ii) melhorar a manutenibilidade do sistema, uma vez que a rpida localizao do controle facilita evoluo das regras de negcio

Slide 61

Bibliografia www.macoratti.net/net_uml1.htm www.devmedia.com.br/artigo-engenharia-de- software-2-analise-orientada-a-objetos/9150 www.plleon.wordpress.com/2009/02/22/associacoes- entre-classes-de-objetos-uml/ http://www.linhadecodigo.com.br/artigo/776/uml- unified-modeling-language-requisitos-classes-e- objetos.aspx

Slide 62

Bibliografia www.ic.unicamp.br/~emrubira www.ic.unicamp.br/~pbbrito