ENGENHARIA DE SOFTWARE

Tamanho: px
Começar a partir da página:

Download "ENGENHARIA DE SOFTWARE"

Transcrição

1 ENGENHARIA DE SOFTWARE PARTE 2 LINGUAGEM DE MODELAÇÃO UML CAP. 6. UML MODELAÇÃO DA ESTRUTURA - DIAGRAMA DE CLASSES Tópicos Diagrama de Classes Perspetivas dos Diagramas de Classes Associações Atributos Operações Visibilidade dos Atributos e Operações Generalização Restrições Conceitos Avançados Quando Utilizar os Diagramas de Classes 2 Diagrama de Classes 3 Diagrama de Classes 4 Técnica central em qualquer método orientado para objetos virtualmente todos os métodos incluem alguma variação desta técnica. O diagrama de classes É uma descrição formal da estrutura de objetos num sistema. Descreve os tipos de objetos no sistema, e os vários tipos de relacionamentos estáticos entre eles. Expressam, de uma forma geral, a estrutura estática do sistema em termos das classes e relacionamentos entre essas classes. Descrevem as classes - descrições abstratas e condensadas de um conjunto de objetos do domínio da aplicação, caracterizadas pelos seus: nome (ou identificador) deve facilitar a compreensão do que a classe é e não o que faz qualquer classe deve ter um nome (mesmo que genérico e provisório) atributos exemplo:a_ser_definido operações restrições os relacionamentos estáticos entre as classes associações (por ex., um cliente pode alugar vários vídeos) subtipos (por ex., uma enfermeira é um tipo de pessoa)

2 Diagrama de Classes 5 Diagrama de Classes 6 A classe representada no exemplo é: Os atributos das classes: identificada pelo nome Triângulo Triangulo Representam-se por baixo do nome Triangulo tem como atributos base e altura executa a operação area(), a partir dos atributos base altura da classe. Pode apenas ser escrito o nome de um atributo ou pode ser colocada também base: int altura: int está sujeita à restrição area() informação relativa ao seu tipo. area() {area <= 300} que limita a 300 Os nomes dos atributos devem começar o valor máximo da área a calcular por minúsculas e quando são compostos Os nomes das classes devem começar por maiúsculas e quando são compostos por mais de uma palavra, {area <= 300} por mais de uma palavra, a primeira letra de cada palavra deve ser maiúscula (excetuando a primeira). {area <= 300} a primeira letra de cada palavra deve ser maiúscula. restrição restrição Diagrama de Classes 7 Diagrama de Classes 8 As operações das classes: Representam-se por baixo dos atributos. Pode apenas ser escrito o nome da operação ou pode ser colocada também informação relativa ao tipo de dados que devolve, ou pode ainda ser colocada informação relativa aos parâmetros que recebe e seus tipos. Os nomes das operações seguem as mesmas regras dos nomes dos atributos. Triangulo base: int altura: int area(): int {area <= 300} A forma usada para representar as classes depende do seu fim: Numa fase de análise, usar uma Triangulo representação simplificada Na fase de desenho devem ser Triangulo incluídos mais detalhes base: int altura: int area(): int restrição As classes estão relacionadas usando as mesmas relações estudadas para os casos de uso: inclusão, generalização e associação.

3 Diagrama de Classes 9 Diagrama de Classes 0 A relação de inclusão indica que uma classe usa a outra; é normalmente usada quando uma classe é usada como argumento numa operação de outra classe. A generalização É uma relação entre uma classe geral (a superclasse ou pai) e uma ou mais classes mais específicas (subclasses ou filhos); As classes filho herdam todos os atributos e operações da classe pai e podem ter mais atributos e operações que aqueles que herdam. Se uma operação num filho tem o mesmo nome da do pai está a fazer um override (obrepôr-se) à do pai. A associação É uma relação estrutural entre duas classes. Exemplo: Perspectivas dos Diagramas de Classes Perspectivas dos Diagramas de Classes 2 As classes podem ser entendidas sob três perspetivas: Conceptual a classe exprime um conceito abstrato no domínio de estudo De especificação a classe é escrita pensando já em termos de software, mas é encarada de um ponto de vista exterior e não em termos de implementação (i.e., pensa-se nas interfaces, mas não na sua caracterização interna) De implementação a classe é descrita pensando já na forma como vai ser implementada Perspetiva conceptual desenha-se a classe sem pensar no tipo de implementação que vai ter (i.e., é independente da linguagem de programação que vai ser utilizada) Perspetiva de especificação é por vezes usado o conceito de tipo para designar as interfaces, quando ainda não se pensou na sua forma de implementação, que pode ser variada. De um modo geral, há vantagem em pensar mais na perspetiva de especificação do que na perspetiva de implementação, embora a segunda seja hoje mais popular. É fundamental reconhecer sempre em que perspetiva se está a desenhar ou a ler um diagrama de classes

4 Associações 3 Associações 4 As associações Representam relacionamentos entre instâncias de classes. São representadas através de uma linha que une as classes associadas. São caracterizadas por possuir um nome e, quando necessário, incluir o papel que as classes têm na relação. O nome das associações é dado, de preferência, utilizando formas verbais ativas ( trabalha para ) ou passivas ( é empregado por ), embora haja quem defende o uso de substantivos em análise OO, uma vez que assim é salientado o carácter estático da associação. Exemplo: O papel de uma pessoa é ser oempregado, enquanto que o papel de uma empresa é ser oempregador Alguns analistas dão nomes a todas as associações. Outros preferem só atribuir nomes às associações que tenham a ganhar em clareza com a existência de um nome papel Pessoa Empresa Empregado Emprego Empregador nome Associações: Associação Reflexiva 5 Associações: Perspetiva Conceptual - Papéis 6 Uma classe pode ter associações consigo própria, significando que um objeto da classe se relaciona com um ou mais objetos da mesma classe. Este tipo de relação surge, tipicamente, em relações de hierarquia (o chefe de um conjunto de empregados é também um empregado) Exemplo: associação na mesma classe Empregado Subordinado -Nome -Morada Papéis: O papel descreve como uma das classes vê a outra classe na associação. Cada associação binária tem dois papeis ( roles ), que correspondem a cada um dos dois sentidos do relacionamento Um papel pode ser caracterizado explicitamente por uma etiqueta que se coloca, em itálico a meio, entre as duas classes. Se não houver etiquetas, o papel fica caracterizado pela classe de destino. Exemplo: o papel de um professor élecionar disciplina, enquanto que o papel de uma disciplina éserlecionada por professor Chefe Chefiar Professor Lecionar Ser lecionada Disciplina

5 Associações: Perspetiva Conceptual - Multiplicidade 7 Associações: Perspetiva Conceptual - Multiplicidade 8 Multiplicidade ou Cardinalidade: Um papel tem multiplicidade (ou cardinalidade), que indica quantos objetos de uma dada classe podem estar ligados a um objeto da outra classe. No exemplo a seguir o * significa que cada professor pode ensinar várias disciplinas, e que não há nenhuma disciplina que possa ser ensinada por vários professores. Se fosse pretendido indicar ser possível algumas disciplinas não serem lecionadas por algum professor, utilizaríamos 0.. Professor 0.. * Disciplina Lecionar Ser lecionada Professor * Lecionar Ser lecionada As cardinalidades representam limites superiores * significa qualquer coisa entre 0 e vários representa o valor um e só um Disciplina Formas mais comuns de multiplicidade: Opcional.. ou - Obrigatório existir um objeto M..N - Um valor do intervalo estabelecido (de M a N);..0 - de um a dez 0..* ou * - Zero a qualquer inteiro positivo objetos da classe..* - Um a qualquer inteiro positivo objetos da classe Associações: Perspetiva Conceptual - Multiplicidade 9 Associações: Perspetiva Conceptual Classe-associação 20 Exemplos de multiplicidades mais frequente Numa relação de associação entre classes, a associação pode também ter os seus próprios atributos (e eventualmente operações), devendo ser, por conseguinte, modelizada também como uma classe. Este tipo de classes designa-se por classe-associação. Estas são representadas por umalinhaatracejado a ligá-la à linha da associação entre as duas classes.

6 Associações: Perspetiva Conceptual Classe-associação 2 Associações: Perspetiva Conceptual Associações N-árias 22 Exemplo: a associação entre as classes Pessoa e Empresa traduz as tarefas que cada empregado realiza na empresa. Para cada tarefa é mantido um conjunto de atributos. A classe-associação Tarefa é representada visualmente como qualquer outra classe, mas apresenta uma linha a tracejado a ligá-la à linha da associação. A maioria das associações são binárias, pois ligam duas classes. Mas, uma classe pode estar ligada a mais do que uma outra, através das denominadas associações N-árias. Estas podem ser representadas por um losangulo apontado para as várias componentes da associação. Exemplo: Sala a classe Disciplina resulta da associação entre as classes Aluno, Professor e Sala. Aluno Professor Disciplina Data_Início Data_Fim Associações: Perspetiva Conceptual - Multiplicidade 23 Associações: Perspetiva Conceptual - Multiplicidade 24 Exemplo de uma associaçãoternária e de uma classe-associação: A associação Disciplina relaciona as classes Professor, Aluno e Sala. Caso a associação tenha também atributos e/ou operações próprias, cria-se uma classe-associação, a qual é ligada ao losango por uma linha a tracejado. Sala Sala As associações N-árias podem geralmente ser transformadas em várias relações binárias entre a classe-associação e as restantes classes participantes. No entanto, se for esta a estratégia adotada deve ser assinalado esse facto (por exemplo, através de um estereótipo ou de uma anotação) junto à classe-associação. Sala Aluno Disciplina Professor Data_Início Data_Fim Aluno Disciplina Data_Início Data_Fim Professor Aluno Disciplina Disciplina Data_Início Data_Fim Professor

7 Associações: Perspectiva de Especificação 25 Associações: Perspectiva de Implementação 26 As associações representam responsabilidades: No diagrama isso significa que há um ou mais métodos associados a Cliente que definem que Encomenda(s) é que um cliente fez Do mesmo modo haverá métodos em Encomenda que informam de que Cliente fez determinada encomenda, e de que Linha(s) de Encomenda constituem uma Encomenda Estas responsabilidades não implicam, no entanto, estruturas de dados. O diagrama exprime apenas as interfaces e nada mais. As associações representam agora a existência de ponteiros nos dois sentidos, entre as classes ligadas pela associação No diagrama isso significa que Encomenda tem um campo que é uma coleção de ponteiros para Linha(s) de Encomenda, e um ponteiro que aponta para Clientes A este nível não se podem tirar, a partir das associações, quaisquer conclusões acerca das interfaces. As operações sobre as classes é que darão essa informação. Associações: Navegabilidade 27 Associações: Navegabilidade 28 As associações descrevem a rede de relações estruturais que existem entre as classes e que dão origem às ligações entre os objetos, instâncias dessas classes. Essas ligações podem ser vistas como canais de navegabilidade entre os objetos. Por omissão, as associações são navegáveis nos dois sentidos, embora em alguns casos, só interesse um dos sentidos da navegabilidade. Exemplo: as instâncias do objeto A veem as instâncias do objeto B, mas as instâncias do objeto B, não veem as instâncias do objeto A. A B Quando se pretende exprimir a navegabilidade num só sentido, colocase uma seta sobre o papel para o qual a navegabilidade é possível Temos assim responsabilidades assimétricas Exemplo com navegabilidade: Encomenda Cliente significa queencomenda tem a responsabilidade de dizer a quecliente se destina, mascliente não tem a responsabilidade de dizer queencomendas lhe correspondem. Podia-se fazer o mesmo tipo de considerações acerca da navegabilidade entre Linha de Encomenda eproduto Encomenda datarecebida éprepaga número:string preço:money Despacha() Fecha() * Linha de Encomenda quantidade: inteiro preço: money estásatisfeita:booleano * Produto * {se Encomenda.cliente.regimeCrédito é "fraco", então Encomenda.éPrepaga tem de ser verdadeiro} nome Cliente Institucional nomecontacto regimecrédito limitecrédito avisa() endereço facturaparamês(inteiro) * 0.. Empregado Cliente regimecrédito(): string Cliente Individual cartãocrédito# {regimecrédito == "fraco"}

8 Associações: Navegabilidade 29 Associações: Navegabilidade 30 A navegabilidade constitui um aspeto importante dos diagramas de implementação e de especificação, mas não a nível conceptual É frequente ver-se um diagrama conceptual que começa sem navegabilidade e que depois se transforma num diagrama de especificação ou implementação, pela adição das navegabilidade. Tem-se uma associação unidirecional quando só há navegabilidade num sentido; bidirecional quando as navegabilidades são nos dois sentidos. Uma associação que só pode ser navegada num sentido pode ser vista como uma meia associação, mostrando uma assimetria nos requisitos de comunicação. Uma associação sem setas é entendida como bidirecional, ou uma associação cujas navegabilidades não foram ainda definidas: deve definir-se qual das interpretações se adota; no caso dos diagramas a nível de especificação e de implementação é mais frequente adotar-se a segunda Se uma associação for bidirecional, isso significa que os dois papeis são inversos um do outro. Esta propriedade é válida para as três perspetivas (conceptual, de especificação e de implementação) Atributos 3 Operações 32 Os atributos são características das classes No caso mais geral, a notação para um atributo especifica o seu nome, tipo e valor por omissão (default), bem como a sua visibilidade Em UML, teremos: visibility name: type = defaultvalue O conceito de visibilidade (visibility) é descrito mais à frente Os atributos têm um valor único de cada vez Em geral os diagramas não indicam se um atributo é opcional ou obrigatório (embora, em rigor, devesse fazê-lo) As operações correspondem aos métodos da classe. A sintaxe completa em UML para uma operação é a seguinte: visibility name(parameter list): type = return-type-expression {property-string} onde: visibility (visibilidade) será descrita mais à frente name é uma cadeia de caracteres parameter-list contém argumentos (opcionais) cuja sintaxe é a mesma dos atributos return-type-expression é uma especificação opcional, property-string indica valores de uma propriedade que se aplica à operação

9 Operações 33 Operações 34 É útil distinguir entre operações que alteram e não alteram o estado de uma classe Uma interrogação (query) é uma operação que obtém o valor de uma classe sem alterar o seu estado observável. As operações que alteram o estado observável são chamadas de modificadores. As interrogações podem ser executadas por qualquer ordem, mas os modificadores exigem cuidados com a sequência de execução. O melhor é não misturar operações dos dois tipos citados. Outras designações: métodos de obtenção (gettingmethods) - devolvem o valor de um campo (e não fazem nada mais) métodos de fixação (settingmethods) - que colocam um valor num campo (e nada mais fazem) Também se deve reconhecer a distinção entre operação e método: Uma operação é algo que se evoca sobre um objecto (a chamada ao procedimento); já o método é o corpo do procedimento. É frequente confundirem-se os dois, mas importa fazer notar que a operação não é mais do que a invocação do método. Havendo polimorfismo, operação e método são distintos. Visibilidade de Atributos e Operações 35 Visibilidade de Atributos e Operações 36 A UML define três tipos de visibilidade para os atributos e operações: Exemplo: pública (simbolizada através do prefixo + ) que torna o elemento visível a todos os clientes da classe; protegida (simbolizada través do prefixo # ) que torna o elemento visível às subclasses da classe (aos respetivos descendentes); privada (simbolizada através prefixo - ) que torna o elemento apenas visível à própria classe Embora a indicação da visibilidade nem sempre figure de forma Privado Público Cliente - BI - Nome - Morada - Telefone # Registar( ) + Alterar Dados( ) + CalcularIdade( ) Protegido explícita nos diagramas de classes, isso não significa que ela não seja definida no modelo.

10 Generalização 37 Generalização 38 A Generalização é um caso especial no diagrama de classes noção de supertipo (superclasse) e subtipo (subclasse) na perspetiva de uma relação pai-filho Especifica o relacionamento entre um elemento geral e um elemento mais específico. O termo generalização especifica uma perspetiva focada numa classificação de hierarquia. Exemplo: um animal é um conceito mais geral do que um gato, um cão ou um guaxim. Inversamente, um gato é um conceito mais específico do que um animal. Em UML preferiu-se utilizar o termo generalização em vez do termo herança, já nosso conhecido. As classes obtidas por herança são denominadas subtipos (exceto no caso dos diagramas de implementação, em que são designadas por subclasses) O elemento mais específico contém informação que lhe é particular, desde que continue completamente consistente com a descrição do elemento mais geral. Generalização 39 Generalização 40 Um relacionamento de generalização significa um é um ou é um tipo de. Exemplo: um gato é um animal. O relacionamento de generalização é representado através de uma seta cuja ponta é um triângulo vazio, que aponta da classe mais especializada para a mais geral. Animal Gato Cão Guaxim No diagrama distinguem-se os clientes institucionais e os clientes individuais, que, tendo algumas diferenças entre si, têm também algumas semelhanças. Essas semelhanças podem ser colocadas na classe cliente (o supertipo) ficando as outras classes (os subtipos) com as características que são diferentes. Cliente Nome Endereço Cliente Institucional nomecontacto regimecrédito limitecrédito avisa() facturaparamês(inteiro) Subtipos regimecredito(): string Cliente Individual cartãocrédito# {regimecrédito()=="fraco"} Supertipo

11 Generalização 4 Generalização: Perspetiva Conceptual e de Especificação 42 As classes podem ter várias superclasses. Quando é esse o caso, a generalização diz-se múltipla e várias setas são desenhadas da subclasse para as várias superclasses. A classetapetesvoadores tem dois antecessores distintos: a classetapetes, e Tapetes Veículos a classeveículos. Terrestres Aéreos Tapetes voadores Na perspetiva conceptual pode-se dizer que cliente institucional será um subtipo de cliente se todas as instâncias de cliente institucional forem também, por definição, instâncias de cliente. A ideia chave é que tudo o que se estabelecer para cliente (associações, atributos, operações) é também válido para cliente institucional. Na perspetiva de especificação, a generalização significa que a interface Cliente Nome Endereço Cliente Institucional nomecontacto regimecrédito limitecrédito avisa() facturaparamês(inteiro) Subtipo regimecredito(): string Cliente Individual cartãocrédito# {regimecrédito()=="fraco"} Supertipo do subtipo tem que incluir todos os elementos da interface do supertipo. Dizse que a interface do subtipo está conforme com a interface do supertipo. Generalização: Perspetiva de Implementação 43 Generalização: Perspetiva de Implementação 44 Na perspetiva de implementação, A generalização está associada ao fenómeno de herança das linguagem de programação orientadas para objetos. Fala-se aqui de subclasse e não de subtipos e considera-se que a subclasse herda todos os métodos e campos da superclasse, podendo os métodos da subclasse sobrepor-se aos métodos herdados. O conceito de herança está presente, pois que as subclasses ( filhos ) herdam da superclasse ( pai ) a estrutura em termos de atributos e operações. Assim, está implícito que As subclasses Cliente Institucional e Cliente Individual possuem um nome, e um endereço. Cliente Nome Endereço Cliente Institucional nomecontacto regimecrédito limitecrédito regimecredito(): string Cliente Individual cartãocrédito# avisa() facturaparamês(inteiro) {regimecrédito()=="fraco"} Subclasse Superclasse

12 Restrições 45 Restrições 46 O próprio facto de se desenhar um diagrama de classes significa que se estão a respeitar restrições. Os conceitos de associação, de atributo ou de generalização são, afinal de contas, formas de especificar restrições. Apesar disto, os conceitos chave dos diagramas de classe não permitem exprimir todas as restrições. Assim, há restrições que têm de ser expressas de forma explícita, porque não caem em nenhuma das categorias previstas nos diagramas de classes. A sintaxe UML para exprimir restrições limita-se a indicar que devem ser colocados entre {}. Tudo o resto é livre, podendo ser expressas em pseudolinguagem, para enfatizar a legibilidade, ou ser traduzidas por instruções em código de programação. Nome Endereço Cliente Institucional nomecontacto regimecrédito limitecrédito avisa() facturaparamês(inteiro) Cliente regimecredito(): string Cliente Individual cartãocrédito# {regimecrédito()=="fraco"} Restrição: neste caso o regime de crédito só pode ser fraco Conceitos Avançados 47 Conceitos Avançados: Classes Associativas 48 Os conceitos até agora descritos, correspondem às notações chaves dos diagramas de classes. Correspondem a cerca de 90% do esforço na criação de diagramas de classes. Há, no entanto, alguns conceitos adicionais, dos quais iremos descrever alguns, os mais relevantes, podendo os restantes ser consultados na bibliografia indicada no início do capítulo. Iremos assim descrever: Classes Associativas Estereótipos Interfaces e desenho do sistema Agregação e Composição Surge da necessidade de obter mais informação de uma associação, permitindo adicionar atributos, operações e outros aspectos. Só existe em resultado da relação entre duas classes; por si só, não terá significado. Normalmente surgem nas relações de Muitos para Muitos e o nome da classe é dado pelo nome da associação.

13 Conceitos Avançados: Classes Associativas 49 Conceitos Avançados: Estereótipos 50 Exemplo: pretende saber-se quando (período de tempo) em que cada empregado trabalhou para a empresa poderíamos adicionar este atributo à classe Pessoa, mas trata-se realmente de um facto acerca do relacionamento da pessoa com a empresa. Pessoa Empregado Emprego Data_Início Data_Fim Empregador * * Classe Associativa Empresa Um estereótipo em UML é parte de um leque de mecanismos de extensibilidade utilizável quando a semântica base do elemento de modelação se revela insuficiente. Cada elemento UML pode ter um ou mais estereótipos. Permite, genericamente, criar novas classes de elementos de modelação por cima do núcleo de elementos pré-definidos pela UML, mantendo um controlo sobre as extensões das classes de metamodelos. É possível criar qualquer tipo de estereótipo, sendo os mais utilizados, para as classes, os de interface e controlo. Os estereótipos são normalmente mostrados entre aspas (por ex:, «control»), mas podem também ser representados por um ícone. Conceitos Avançados: Estereótipos 5 Conceitos Avançados: Interfaces e Desenho do Sistema 52 O estereótipo de «interface» classifica as classes que apenas disponibilizam um conjunto de operações visíveis externamente (públicas). Uma classe com o estereótipo de «control» representa uma classe cujo objetivo é conter um conjunto de regras que controlam determinadas operações do sistema e que coordenam as interações com as outras classes. Estereótipo «control» «interface» Controlo Acesso Gestão Interface: Proporciona uma vista total ou parcial do conjunto dos vários serviços proporcionados por um ou mais elementos. Permite que o impacto das alterações seja limitado, podendo efetuar-se alterações na classe sem afetar as classes restantes, desde que não se altere a interface respetiva. Permite separar o que é fornecido pela abstração da classe da forma como é produzido. É um grupo de operações que são utilizadas para especificar um serviço. + VerificaAcesso() + Criar() + Apagar() + Ver()

14 Conceitos Avançados: Interfaces e Desenho do Sistema 53 Conceitos Avançados: Interfaces e Desenho do Sistema 54 A UML representa as interfaces: Utilizando pequenos círculos ligados por uma linha ao elemento que proporciona os serviços descritos pela interface. Em alternativa a interface pode representar-se por uma classe, com o estereótipo «interface», mas sem atributos, apenas operações. Encomenda uma classe «interface» Gestão + Criar() + Apagar() + Ver() - NumeroE: long - Data: date - TipoEncomenda: string - ValorTotal: long + Criar() + Apagar() + Ver() + AdicionaProduto() + CalculaValorTotal() Conceitos Avançados: Relação de Dependência 55 Conceitos Avançados: Relação de Dependência e Realização 56 Os dependentes da interface podem utilizar todos ou alguns dos serviços descritos na interface. Uma relação de dependência surge quando uma classe recorre aos serviços disponibilizados por outra classe. Quando um funcionário efetua uma consulta a uma encomenda, este terá de aceder aos serviços disponibilizados pela classe Encomenda, através da interface Gestão, que disponibiliza os serviços Criar(), Apagar() e Ver() da classe Encomenda O serviço funciona como um contrato entre a classe e os seus clientes, que, por sua vez, constroem os seus serviços com base na interface estabelecida Funcionário - BI: string - Nome: string - Morada: string «interface» Gestão + Criar() + Apagar() + Ver() Dependência Encomenda - NumeroE: long - Data: date - TipoEncomenda: string - ValorTotal: long + Criar() + Apagar() + Ver() + AdicionaProduto() + CalculaValorTotal() A relação derealização mostra que existe um contrato entre a classe que utiliza o serviço e outra que garante a sua realização. A classe Funcionário, através da interface Gestão, pode Criar, Apagar e Ver encomendas. A classe Cliente apenas pode visualizar as encomendas, uma vez que a respetiva interface só disponibiliza a operação Ver() A classe Encomenda disponibiliza duas interfaces: Gestão e Visualizar. Funcionário - BI: string - Nome: string - Morada: string «interface» Gestão + Criar() + Apagar() + Ver() Encomenda - NumeroE: long - Data: date - TipoEncomenda: string - ValorTotal: long + Criar() + Apagar() + Ver() + AdicionaProduto() + CalculaValorTotal() Cliente - BI: string - Nome: string - Morada: string + Pré-Registo() «interface» Visualizar + Ver() Realização

15 Conceitos Avançados: Interface e Desenho do Sistema 57 Conceitos Avançados: Diagrama de Classe com 3 níveis 58 Podemos construir um diagrama de classes com 3 níveis, dividido em três camadas de serviços:. Serviços de interface - fornece a interface para os utilizadores para apresentação e recolha de dados. 2. Serviços de negócio - engloba as classes que possuem as regras fundamentais de negócio, respondendo aos pedidos da camada ou de outros serviços da própria camada, através da execução de uma operação específica sobre dados relevantes com base em regras de negócio. 3. Serviços de Dados - permite manter, atualizar e aceder aos dados persistentes. Nesta arquitetura, quando os dados residem num servidor de base de dados, os serviços de negócio asseguram o acesso ao serviço de dados, isolando o seu acesso. Como as regras de negócio tendem a ser alteradas com relativa frequência, os serviços de negócio são úteis para encapsular estas regras, separando a tarefa a desempenhar da forma como é desempenhada. Ao isolar os serviços de negócio dos serviços de interface e dados, este diagrama permite ir ao encontro do paradigma de desenvolvimento de aplicações cliente/servidor, promovendo a reutilização, escalabilidade e manutenção dos componentes. Conceitos Avançados: Diagrama de Classe com 3 níveis 59 Conceitos Avançados: Diagrama de Classe com 3 níveis 60 A classe de interface Ecrã Pré- Registo necessita da classe clientes, nos serviços de negócio, para efetuar o registo, invocando para tal a operação pré-registo. Por sua vez, a classe cliente necessita de guardar num suporte físico os dados do cliente que está a efetuar o pré-registo, utilizando os serviços de dados através da classe SD_Cliente. Esquema semelhante se aplica para as classes Ecrã Reservas e Ecrã Encomenda. Dado necessitarem de verificar se o cliente tem permissão, o que é feito invocando a classe Controlo de Acesso (com estereótipo «control»), classe esta que contém as regras de negócio que gerem o acesso ao sistema. Serviços de Interface «user interface» Ecrã Pré-Registo «user interface» Ecrã Reservas «user interface» Ecrã Encomenda Serviços de Negócio Cliente {persistence = Yes} - BI - Nome - Morada + Pré-Registo() {sequencial} «control» Controlo Acesso + VerificaAcesso() efetua 0..* Encomenda {persistence = Yes} - NumeroE - Data - TipoEncomenda + Criar() {sequencial} Serviços de Dados «data connection» SD_Cliente - BI - Nome - Morada + Criar() + Apagar() + Consultar() + Actualizar() efetua 0..* «data connection» Encomenda - NumeroE - Data - TipoEncomenda + Criar() + Apagar() + Consultar() + Actualizar() As classes persistentes Persistence=Yes necessitam que os seus objetos sejam gravados fisicamente numa base de dados ou outro meio. A classe Controlo, neste caso, não necessita de gravar os seus dados, utilizando os serviços da classe Cliente. No entanto, se fosse necessário manter um registo de acessos específicos da classe ou de regras de negócio, esta seria marcada como persistente e teria uma classe correspondente nos serviços de dados. Serviços de Interface «user interface» Ecrã Pré-Registo «user interface» Ecrã Reservas «user interface» Ecrã Encomenda Serviços de Negócio Cliente {persistence = Yes} - BI - Nome - Morada + Pré-Registo() {sequencial} «control» Controlo Acesso + VerificaAcesso() efetua 0..* Encomenda {persistence = Yes} - NumeroE - Data - TipoEncomenda + Criar() {sequencial} Serviços de Dados «data connection» SD_Cliente - BI - Nome - Morada + Criar() + Apagar() + Consultar() + Actualizar() efetua 0..* «data connection» Encomenda - NumeroE - Data - TipoEncomenda + Criar() + Apagar() + Consultar() + Actualizar()

16 Conceitos Avançados: Diagrama de Classe com 3 níveis 6 Conceitos Avançados: Agregação e Composição 62 A parte física dos dados dependerá do tipo de base de dados (relacional ou objeto): Se base de dados relacional, aplicam-se as regras de transposição semelhantes às já tratadas em análise de sistemas, a propósito da transposição do modelo E-R para o modelo relacional. Se B.D. objeto ou relacional-objeto, a transposição será mais direta, e será tratada numa disciplina do plano de estudos do curso Tópicos Avançados de bases de Dados. A agregação num diagrama de classes pretende demonstrar a relação que um todo é composto por partes (part-ofrelationship). Representa uma relação assimétrica, na qual uma das partes desempenha um papel mais importante do que a outra. Restaurante - Nome - Morada..* Mesa - Num_mesa Um restaurante possui um conjunto de mesas (o losângulo sem enchimento pretende representar o conceito de agregação) Conceitos Avançados: Agregação e Composição 63 Conceitos Avançados: Agregação e Composição 64 Os critérios seguintes implicam uma agregação, mas o oposto nem sempre é verdade, ou seja, a agregação não os implica necessariamente: Uma classe é parte de outra classe (o todo é composto por partes) Os valores de um atributo de uma classe propagam-se aos atributos de outra classe. Uma ação numa classe implica uma ação na outra classe. Os objetos de uma classe estão subordinados aos objetos da outra classe. Em casos de dúvida quanto à existência de agregação, a associação simples será preferível: lembremo-nos de que é necessário escolher uma solução que implique o acoplamento mais fraco. A composição: é uma agregação com um significado mais forte existindo uma dependência direta entre as duas classes (se a parte deixar de existir, o todo também desaparece); dito de outra forma, a parte vive e morre com o todo. qualquer remoção do todo implica a eliminação em cascata das partes. Na composição a multiplicidade do lado do todo não ultrapassa o um, ao contrário da agregação. Não faz sentido haver linhas de encomenda (parte) sem a encomenda respetiva (todo). Encomenda - NúmeroE - Data - TipoEncomenda Todo..* Composição ItemEncomenda - Codtem - Quantidade Parte

17 Conceitos Avançados: Agregação e Composição 65 Quando Usar os Diagramas de Classes 66 Exemplo: Um polígono contém uma coleção ordenada de pontos. Esses pontos podem ser alterados com a edição do polígono (agregação) A composição é utilizada para o pacote gráfico do polígono (por ex., cor ou textura); foi separado do polígono porque diversos elementos gráficos podem utilizar o mesmo pacote de atributos gráficos. O relacionamento com o pacote gráfico é composição porque o pacote gráfico será criado ou destruído com o polígono. agregação {ordenado} 3..* Ponto Polígono Classes compostas - classes implementadas por composição. composição Pacote Gráfico Cor Textura Os diagramas de classes são a espinha dorsal de praticamente todos os métodos orientados para objetos, sendo, por isso, os mais usados. São, no entanto, os mais ricos e complexos, pelo que se recomenda o seu uso com alguns cuidados: Não tentar usar todas as notações disponíveis. Usar as mais complexas (aspetos avançados) quando forem estritamente necessárias. Adequar a perspetiva que se está a usar à fase em que o projeto se encontra: fazer diagramas conceptuais, se se está a fazer análise; fazer diagramas de especificação, ao começar a pensar-se em software; e fazer diagramas de implementação, apenas quando se pretender ilustrar uma solução de implementação mais particular. Quando Usar os Diagramas de Classes 67 Não desenhar modelos para tudo; é preferível concentrarmo-nos nas áreas chave. É melhor ter poucos diagramas, que se vão atualizando quando necessário, do que ter muitos diagramas que se vão tornando obsoletos por falta de atualização. Evitar a todo o custo começar a pensar nos pormenores de implementação demasiado cedo. Para o conseguir, concentrar a atenção nas perspetivas de concepção e de especificação.

18 ENGENHARIA DE SOFTWARE PARTE 2 LINGUAGEM DE MODELAÇÃO UML Cap. 6.2 UML - Modelação de Estrutura Diagramas de Objetos [Parte 2] Tópicos Objetivos Transição para os Objetos Diagramas de Objetos Representação das Ligações Objetos Compósitos Quando Utilizar os Diagramas de Objetos 2 CAP. 6.2 UML MODELAÇÃO DA ESTRUTURA - DIAGRAMA DE OBJETOS Cap. 6.2 UML - Modelação de Estrutura Diagramas de Objetos [Parte 2] Objetivos 3 Cap. 6.2 UML - Modelação de Estrutura Diagramas de Objetos [Parte 2] Transição para os Objetos 4 Facilitar a compreensão do processo de transição dos casos de uso para o universo dos objetos. Familiarizar com os conceitos essenciais à utilização dos diagramas de objetos. Esclarecer as relações entre os diagramas de objetos e diagramas de classes. Os diagramas de casos de uso Centram o desenvolvimento sobre as necessidades do utilizador. Têm um objetivo de eficácia: fazer o que deve ser feito. Dizem o que o sistema deve fazer, mas não como deve fazê-lo. Os diagramas de objetos Satisfazem um objetivo complementar, o da eficiência: fazer corretamente; Dizem como deve ser feito. Esta complementaridade é importante porque um bom projeto de software tem de satisfazer, em simultâneo, os objetivos de eficiência e eficácia.

19 Cap. 6.2 UML - Modelação de Estrutura Diagramas de Objetos [Parte 2] Transição para os Objetos 5 Cap. 6.2 UML - Modelação de Estrutura Diagramas de Objetos [Parte 2] Transição para os Objetos 6 Transição de um caso de uso para uma formulação orientada para objetos <<realiza>> Caso de uso Colaboração <<participa>> <<participa>> <<participa>> Objeto Objeto Objeto A realização de um caso de uso é um momento crucial da construção do modelo: é o momento da passagem para objetos. Note-se, contudo, que uma decomposição que siga de forma direta um caso de uso, tal como ele foi criado, corre o risco de conduzir a uma abordagem estruturada clássica, com todos os inconvenientes de uma estruturação em torno de funções. Numa abordagem para objetos, realiza-se o caso de uso através de uma colaboração entre objetos. Veremos que os cenários, instâncias dos casos de uso, serão representados por diagramas de interação de dois tipos: de colaboração, e de sequência. Cap. 6.2 UML - Modelação de Estrutura Diagramas de Objetos [Parte 2] Transição para os Objetos 7 Cap. 6.2 UML - Modelação de Estrutura Diagramas de Objetos [Parte 2] Diagramas de Objetos 8 Os diagramas de objetos ou diagramas de instâncias representam os objetos e as ligações entre eles, exatamente da mesma maneira que os diagramas de classes representam as classes e as associações entre elas. Tal como nos diagramas de classes, os diagramas de objetos, que não são mais do que a instanciação dos diagramas de classes, representam estruturas estáticas. A notação utilizada pelos diagramas de objetos deriva diretamente da dos diagramas de classes, com a diferença que apresenta os nomes dos elementos, que são as instâncias, sublinhados.

20 Cap. 6.2 UML - Modelação de Estrutura Diagramas de Objetos [Parte 2] Diagramas de Objetos 9 Cap. 6.2 UML - Modelação de Estrutura Diagramas de Objetos [Parte 2] Diagramas de Objetos 0 Cada objeto é representado por um retângulo que contém os seguintes elementos: o nome da classe e do objeto, separados por : (diz-se que se tem o modelo completo) o nome da classe à qual o objeto pertence (diz-se que se tem o modelo anónimo) o nome do objeto, sem indicação da classe a que pertence (diz-se que se tem o modelo incompleto) O modelo anónimo é utilizado quando se sabe a que classe pertence o objeto, mas ainda não se atribuiu um nome para ele O modelo incompleto corresponde a situações em que já se escolheu o nome para o objeto, mas não se sabe ao certo a que classe pertence. Exemplo: Modelo completo: Modelo incompleto: Modelo anónimo: Nome do objeto: Classe Nome do objeto : Classe Cap. 6.2 UML - Modelação de Estrutura Diagramas de Objetos [Parte 2] Diagramas de Objetos Cap. 6.2 UML - Modelação de Estrutura Diagramas de Objetos [Parte 2] Representação das Ligações 2 Os retângulos que simbolizam os objetos podem igualmente comportar um segundo compartimento que contém ovalordosatributos. O tipo não será necessário dado que já foi definido no diagrama de classes que engloba o dos objetos. Exemplo para um objeto anónimo da classe Automóvel, com um único atributo,cor, cujo valor évermelha: : Automóvel Os objetos de um diagrama encontram-se ligados por ligações que são instâncias das associações entre as classes às quais pertencem os objetos considerados. Exemplo do diagrama de objetos (simplificado) para um automóvel e do diagrama de classes para o qual representa uma instância: : Automóvel : Motor Automóvel Motor 4 : Roda : Roda : Roda : Roda Roda Cor = Vermelha É uma instancia de

4.2. UML Diagramas de classes

4.2. UML Diagramas de classes Engenharia de Software 4.2. UML Diagramas de classes Nuno Miguel Gil Fonseca nuno.fonseca@estgoh.ipc.pt Um diagrama de classes serve para modelar o vocabulário de um sistema Construído e refinado ao longo

Leia mais

Elsa Cardoso, DCTI - ISCTE

Elsa Cardoso, DCTI - ISCTE Elsa Cardoso, DCTI - ISCTE 25 Maio 2004 elsa.cardoso@iscte.pt Sumário Perspectiva de Desenho do Sistema: Diagrama de classes numa perspectiva de Desenho: Estereótipos Relação de Dependência Relação de

Leia mais

Diagrama de Classes. Viviane Torres da Silva viviane.silva@ic.uff.br. http://www.ic.uff.br/~viviane.silva/2012.1/es1

Diagrama de Classes. Viviane Torres da Silva viviane.silva@ic.uff.br. http://www.ic.uff.br/~viviane.silva/2012.1/es1 Diagrama de Classes Viviane Torres da Silva viviane.silva@ic.uff.br http://www.ic.uff.br/~viviane.silva/2012.1/es1 O que é? Diagrama mais utilizado da UML Representa os tipos (classes) de objetos de um

Leia mais

Diagrama de Classes. Um diagrama de classes descreve a visão estática do sistema em termos de classes e relacionamentos entre as classes.

Diagrama de Classes. Um diagrama de classes descreve a visão estática do sistema em termos de classes e relacionamentos entre as classes. 1 Diagrama de Classes Um diagrama de classes descreve a visão estática do sistema em termos de classes e relacionamentos entre as classes. Um dos objetivos do diagrama de classes é definir a base para

Leia mais

Engenharia de Softwares e Sistema IF682 (2012.1) Bruno Medeiros(bmo@cin.ufpe.br)

Engenharia de Softwares e Sistema IF682 (2012.1) Bruno Medeiros(bmo@cin.ufpe.br) Engenharia de Softwares e Sistema IF682 (2012.1) Bruno Medeiros(bmo@cin.ufpe.br) Algumas definições Engenharia de Software conjunto de tecnologias e práticas usadas para construir software de qualidade

Leia mais

Banco de Dados 1 2º Semestre

Banco de Dados 1 2º Semestre Banco de Dados 1 2º Semestre Aula 07 Prof. Gladimir Ceroni Catarino gladimir@gmail.com SERVIÇO NACIONAL DE APRENDIZAGEM COMERCIAL FACULDADE DE TECNOLOGIA SENAC PELOTAS o Uma coletânea de conceitos que

Leia mais

ENGENHARIA DE SOFTWARE Prof. Ricardo Rodrigues Barcelar http://www.ricardobarcelar.com.br

ENGENHARIA DE SOFTWARE Prof. Ricardo Rodrigues Barcelar http://www.ricardobarcelar.com.br - MÓDULO 3 - MODELAGEM DE SISTEMAS ORIENTADA A OBJETOS COM UML 1. INTRODUÇÃO A partir de 1980, diversos métodos de desenvolvimento de sistemas surgiram para apoiar o paradigma orientado a objetos com uma

Leia mais

Análise Orientada a Objetos

Análise Orientada a Objetos Análise Orientada a Objetos Breve Histórico: Fim da década de 80: amadurecimento da Orientação a Objeto Década de 1990: diversas proposições a partir de diversos autores, como Booch, Rumbaugh e Jacobson.

Leia mais

Engenharia de Software I

Engenharia de Software I Engenharia de Software I Rogério Eduardo Garcia (rogerio@fct.unesp.br) Bacharelado em Ciência da Computação Aula 05 Material preparado por Fernanda Madeiral Delfim Tópicos Aula 5 Contextualização UML Astah

Leia mais

3. PARADIGMA ORIENTADO A OBJETOS

3. PARADIGMA ORIENTADO A OBJETOS Paradigmas de Linguagens I 1 3. PARADIGMA ORIENTADO A OBJETOS Este paradigma é o que mais reflete os problemas atuais. Linguagens orientada a objetos (OO) são projetadas para implementar diretamente a

Leia mais

Modelagem OO com UML. Vítor E. Silva Souza (vitorsouza@inf.ufes.br) http://www.inf.ufes.br/ ~ vitorsouza

Modelagem OO com UML. Vítor E. Silva Souza (vitorsouza@inf.ufes.br) http://www.inf.ufes.br/ ~ vitorsouza Modelagem OO com UML Vítor E. Silva Souza (vitorsouza@inf.ufes.br) http://www.inf.ufes.br/ ~ vitorsouza Departamento de Informática Centro Tecnológico Universidade Federal do Espírito Santo Modelos Maneira

Leia mais

3.1 Definições Uma classe é a descrição de um tipo de objeto.

3.1 Definições Uma classe é a descrição de um tipo de objeto. Unified Modeling Language (UML) Universidade Federal do Maranhão UFMA Pós Graduação de Engenharia de Eletricidade Grupo de Computação Assunto: Diagrama de Classes Autoria:Aristófanes Corrêa Silva Adaptação:

Leia mais

Prof. Claudio Passos Apresentação cedida pela Ceça Moraes

Prof. Claudio Passos Apresentação cedida pela Ceça Moraes Prof. Claudio Passos Apresentação cedida pela Ceça Moraes Programação Orientada a Objetos: os problemas de programação são pensados em termos de objetos Em vez de funções e rotinas Problema = desenvolver

Leia mais

Programa do Módulo 2. Fundações do Modelo Objeto

Programa do Módulo 2. Fundações do Modelo Objeto 2.1 Programa do Módulo 2 Orientação a Objetos Conceitos Básicos Análise Orientada a Objetos (UML) Processo Unificado (RUP) Fundações do Modelo Objeto 2.2 Programação Orientada a Objetos: é um método de

Leia mais

Engenharia de Software

Engenharia de Software Prof. M.Sc. Ronaldo C. de Oliveira ronaldooliveira@facom.ufu.br FACOM - 2011 Exemplo de Diagrama de Caso de Uso Sistema de Locadora de Filmes Sistema de Vídeo Locadora Você foi contratado para desenvolver

Leia mais

1. Introdução 2. Desenvolvimento de Softwares orientado a objetos 3. UML A unificação dos métodos para a criação de um novo padrão 4. Uso da UML 5.

1. Introdução 2. Desenvolvimento de Softwares orientado a objetos 3. UML A unificação dos métodos para a criação de um novo padrão 4. Uso da UML 5. 1. Introdução 2. Desenvolvimento de Softwares orientado a objetos 3. UML A unificação dos métodos para a criação de um novo padrão 4. Uso da UML 5. Fases do Desenvolvimento de um Sistema em UML 1. Análise

Leia mais

4. Exemplo de Levantamento de Classes...26. 3. Levantamento das Classes...24. 1. Conceito de Classe e Objeto... 15. 1. Modelo de Casos de Uso...

4. Exemplo de Levantamento de Classes...26. 3. Levantamento das Classes...24. 1. Conceito de Classe e Objeto... 15. 1. Modelo de Casos de Uso... Projeto de Software usando UML Sumário Capítulo I : Casos de Uso...3 1. Modelo de Casos de Uso... 3 2. Diagramas de Casos de Uso... 3 3. Exemplo... 9 4. Conclusão... 13 Capítulo II : Levantamento de Classes...15

Leia mais

Modelos de Sistema. 2007 by Pearson Education. Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 8 Slide 1.

Modelos de Sistema. 2007 by Pearson Education. Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 8 Slide 1. Modelos de Sistema Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 8 Slide 1 Objetivos Explicar por que o contexto de um sistema deve ser modelado como parte do processo de RE Descrever

Leia mais

MC302A Modelagem de Sistemas com UML. Prof. Fernando Vanini vanini@ic.unicamp.br

MC302A Modelagem de Sistemas com UML. Prof. Fernando Vanini vanini@ic.unicamp.br MC302A Modelagem de Sistemas com UML Prof. Fernando Vanini vanini@ic.unicamp.br Modelamento de Sistemas e Orientação a Objetos O paradigma de Orientação a Objetos oferece um conjunto de características

Leia mais

Modelo Entidade-Relacionamento

Modelo Entidade-Relacionamento Modelo Entidade-Relacionamento Banco de Dados I Fases do Projeto jt de BD Enunciado de requisitos entrevista com o usuário do banco de dados para entender e documentar seus requerimentos de dados. Projeto

Leia mais

Análise e Projeto Orientados por Objetos

Análise e Projeto Orientados por Objetos Análise e Projeto Orientados por Objetos Aula 02 Análise e Projeto OO Edirlei Soares de Lima Análise A análise modela o problema e consiste das atividades necessárias para entender

Leia mais

Unified Modeling Language UML - Notações

Unified Modeling Language UML - Notações Unified Modeling Language UML - Notações Prof. Ms. Elvio Gilberto da Silva elvio@fmr.edu.br UML Ponto de Vista É gerada com propósito geral de uma linguagem de modelagem visual usada para especificar,

Leia mais

Fernando Fonseca Ana Carolina

Fernando Fonseca Ana Carolina Banco de Dados Ciclo de Desenvolvimento de Sistemas de BD Investigação dos Dados Modelagem dos Dados Modelagem Conceitual Projeto do Banco de Dados Fernando Fonseca Ana Carolina Implementação do Banco

Leia mais

Programação com Objectos. Processamento de Dados I. 3. UML (Unified Modeling Language)

Programação com Objectos. Processamento de Dados I. 3. UML (Unified Modeling Language) Programação com Objectos Processamento de Dados I 3. UML (Unified Modeling Language) 1 Modelo UML Diagrama de classes Programação com Objectos / Processamento de Dados I 2 Modelo O desenvolvimento de programas

Leia mais

Modelo conceitual Aula 08

Modelo conceitual Aula 08 Universidade Federal de Mato Grosso do Sul Sistemas de Informação - CPCX Modelo conceitual Aula 08 Prof. Fernando Maia da Mota Slides gentilmente cedidos por Profa. Dra. Maria Istela Cagnin Machado UFMS/FACOM

Leia mais

A linguagem UML. UML e Diagramas de Casos de Uso e Classes. Por que usar UML? O que é modelagem?

A linguagem UML. UML e Diagramas de Casos de Uso e Classes. Por que usar UML? O que é modelagem? UML e Diagramas de Casos de Uso e Classes Prof. Ms. Luiz Alberto Contato: lasf.bel@gmail.com A linguagem UML UML (Unified Modeling Language) Linguagem de Modelagem Unificada É uma linguagem de modelagem

Leia mais

Algumas propriedades dos objetos:

Algumas propriedades dos objetos: Orientação a Objetos Vivemos num mundo de objetos. Esses objetos existem na natureza, nas entidades feitas pelo homem, nos negócios e nos produtos que usamos. Eles podem ser categorizados, descritos, organizados,

Leia mais

UML. Unified Modeling Language

UML. Unified Modeling Language UML Unified Modeling Language 1 1. Introdução O desenvolvimento de sistemas de software de grande porte são suportados por métodos de análise e projeto que modelam esse sistema de modo a fornecer para

Leia mais

UNIVERSIDADE FEDERAL DE SANTA MARIA CENTRO DE TECNOLOGIA AULA 17 PROFª BRUNO CALEGARO

UNIVERSIDADE FEDERAL DE SANTA MARIA CENTRO DE TECNOLOGIA AULA 17 PROFª BRUNO CALEGARO UNIVERSIDADE FEDERAL DE SANTA MARIA CENTRO DE TECNOLOGIA AULA 17 PROFª BRUNO CALEGARO Santa Maria, 19 de Novembro de 2013. Revisão aula anterior Modelagem orientada a objetos com UML Software: Astah Community

Leia mais

UNIVERSIDADE CANDIDO MENDES PRÓ-REITORIA DE PLANEJAMENTO E DESENVOLVIMENTO DIRETORIA DE PROJETOS ESPECIAIS PROJETO A VEZ DO MESTRE

UNIVERSIDADE CANDIDO MENDES PRÓ-REITORIA DE PLANEJAMENTO E DESENVOLVIMENTO DIRETORIA DE PROJETOS ESPECIAIS PROJETO A VEZ DO MESTRE UNIVERSIDADE CANDIDO MENDES PRÓ-REITORIA DE PLANEJAMENTO E DESENVOLVIMENTO DIRETORIA DE PROJETOS ESPECIAIS PROJETO A VEZ DO MESTRE METODOLOGIA RÁPIDA UMA VISÃO ORIENTADA A OBJETO UML - LINGUAGEM DE MODELAGEM

Leia mais

PROJETO DE BANCO DE DADOS -PROJETO CONCEITUAL. Prof. Angelo Augusto Frozza, M.Sc.

PROJETO DE BANCO DE DADOS -PROJETO CONCEITUAL. Prof. Angelo Augusto Frozza, M.Sc. PROJETO DE BANCO DE DADOS -PROJETO CONCEITUAL Prof. Angelo Augusto Frozza, M.Sc. PROJETO CONCEITUAL Levantamento de requisitos Modelagem Conceitual Modelo ER PROJETO CONCEITUAL Parte integrante do Projeto

Leia mais

UML Aspectos de projetos em Diagramas de classes

UML Aspectos de projetos em Diagramas de classes UML Aspectos de projetos em Diagramas de classes Após ser definido o contexto da aplicação a ser gerada. Devemos pensar em detalhar o Diagrama de Classes com informações visando uma implementação Orientada

Leia mais

Análise de Sistemas Orientados a Objetos Prof. Tiago Eugenio de Melo tiago@comunidadesol.org. www.tiagodemelo.info

Análise de Sistemas Orientados a Objetos Prof. Tiago Eugenio de Melo tiago@comunidadesol.org. www.tiagodemelo.info Análise de Sistemas Orientados a Objetos Prof. Tiago Eugenio de Melo tiago@comunidadesol.org www.tiagodemelo.info Roteiro Conceitos de Orientação a Objetos (OO) Visão Geral da UML Diagrama de Classes Diagramas

Leia mais

Notas de Aula 06: Diagrama de classes de domínio

Notas de Aula 06: Diagrama de classes de domínio Notas de Aula 06: Diagrama de classes de domínio Objetivos da aula: Compreender um modelo de negócio pela representação das classes de uma entidade Modelar as entidades e seus relacionamentos de um domínio

Leia mais

Concepção e Elaboração

Concepção e Elaboração UNIVERSIDADE ESTADUAL PAULISTA INSTITUTO DE BIOCIÊNCIAS, LETRAS E CIÊNCIAS EXATAS DEPARTAMENTO DE CIÊNCIAS DE COMPUTAÇÃO E ESTATÍSTICA Análise e Projeto Orientado a Objetos Concepção e Elaboração Estudo

Leia mais

ENGENHARIA DE SOFTWARE

ENGENHARIA DE SOFTWARE ENGENHARIA DE SOFTWARE PARTE 2 LINGUAGEM DE MODELAÇÃO UML CAP. 8 UML MODELAÇÃO DA ARQUITETURA Tópicos Conceito de Diagramas Físicos Fundamentos dos Diagramas de Componentes componentes interface quando

Leia mais

Uma Abordagem usando PU

Uma Abordagem usando PU Uma Abordagem usando PU Curso de Especialização DEINF - UFMA Desenvolvimento Orientado a Objetos Prof. Geraldo Braz Junior Referências: Baseada em: Rational Software Corpotation G. Booch, Ivar Jacobson,

Leia mais

UML Unified Modeling Language

UML Unified Modeling Language UML Unified Modeling Language Linguagem de Modelagem Unificada A linguagem UML UML (Unified Modeling Language) Linguagem de Modelagem Unificada É uma linguagem para especificação, É uma linguagem para

Leia mais

Modelo Entidade-Relacionamento

Modelo Entidade-Relacionamento Modelo Entidade-Relacionamento ome Designação Doc... #Disc... Docente Ensina Disciplina Abordagem proposta por Peter P. Chen (década de 70) para o processo de modelação de dados com ampla aceitação; Trabalho

Leia mais

Ciclo de vida de um banco de dados relacional

Ciclo de vida de um banco de dados relacional Ciclo de vida de um banco de dados relacional 1. Formulação e análise de requisitos: a) Relacionamentos naturais entre os dados (independentes de processo). b) Requisitos de uso (dependentes de processo).

Leia mais

Tópicos em Engenharia de Computação

Tópicos em Engenharia de Computação Tópicos em Engenharia de Computação Introdução / Revisão UML e POO (JAVA) Prof. Ivan Prof. Zagari UML Linguagem Unificada. Não é metodologia, processo ou método. Versão atual 2.0 3 categorias de Diagramas

Leia mais

Persistência e Banco de Dados em Jogos Digitais

Persistência e Banco de Dados em Jogos Digitais Persistência e Banco de Dados em Jogos Digitais Prof. Marcos Francisco Pereira da Silva Especialista em Engenharia de Software Jogos Digitais - Computação Gráfica 1 Agenda Vantagens de usar a abordagem

Leia mais

Processo de análise estruturada - Abordagem clássica

Processo de análise estruturada - Abordagem clássica Processo de análise estruturada - Abordagem clássica Desenvolver modelo físico actual Modelo físico actual Modelos a desenvolver tendo em conta a abordagem clássica Desenvolver modelo lógico actual Modelo

Leia mais

Modelagem de Dados Usando o Modelo Entidade-Relacionamento

Modelagem de Dados Usando o Modelo Entidade-Relacionamento Usando o Modelo Entidade-Relacionamento MER 1 MER Levantamento e Análise de requisitos Entrevista Entender e documentar seus requisitos de dados Requisitos funcionais da aplicação empregadas ao banco de

Leia mais

UML Aula I Diagramas de Caso de Uso, Sequência e Colaboração

UML Aula I Diagramas de Caso de Uso, Sequência e Colaboração UML Aula I Diagramas de Caso de Uso, Sequência e Colaboração Ricardo Argenton Ramos Engenharia de Software II 2013.1 Um Exercício Como você pode representar? Uma casa de 2 andares, 4 quartos, 2 banheiros,

Leia mais

Conteúdo. Disciplina: INF 02810 Engenharia de Software. Monalessa Perini Barcellos. Centro Tecnológico. Universidade Federal do Espírito Santo

Conteúdo. Disciplina: INF 02810 Engenharia de Software. Monalessa Perini Barcellos. Centro Tecnológico. Universidade Federal do Espírito Santo Universidade Federal do Espírito Santo Centro Tecnológico Departamento de Informática Disciplina: INF 02810 Prof.: (monalessa@inf.ufes.br) Conteúdo 1. Introdução 2. Processo de Software 3. Gerência de

Leia mais

Sumário. Uma visão mais clara da UML

Sumário. Uma visão mais clara da UML Instituto Federal de Santa Catarina Câmpus Chapecó Ensino Médio Integrado em Informática Módulo V Unidade Curricular: Engenharia de Software Professora: Lara P. Z. B. Oberderfer Uma visão mais clara da

Leia mais

Iteração 2 Design inicial

Iteração 2 Design inicial Universidade de Aveiro Departamento de Electrónica, Telecomunicações e Informática Engenharia de Software Iteração 2 Design inicial Projecto: FX-Center Grupo: BEDS David Pacheco (nº 32665) Cesário Lucas

Leia mais

Orientação a Objetos

Orientação a Objetos Orientação a Objetos Daniel Destro do Carmo Softech Network Informática daniel@danieldestro.com.br Histórico A orientação a objetos (OO) foi concebida na década de 70. Origem na linguagem SIMULA-67 (década

Leia mais

Projeto de Banco de Dados

Projeto de Banco de Dados Projeto de Banco de Dados Atividade de modelagem de dados em diversos níveis de abstração Modelagem conceitual (projeto conceitual) abstração de mais alto nível objetivo: representação dos requisitos de

Leia mais

Introdução! 1. Modelos de Domínio! 1. Identificação de classes conceituais! 2. Estratégia para identificar classes conceituais! 2

Introdução! 1. Modelos de Domínio! 1. Identificação de classes conceituais! 2. Estratégia para identificar classes conceituais! 2 Modelo de domínio Introdução! 1 Modelos de Domínio! 1 Identificação de classes conceituais! 2 Estratégia para identificar classes conceituais! 2 Passos para a elaboração do modelo de domínio! 2 Passo 1

Leia mais

Estudo de Caso Sistema de Caixa Automático

Estudo de Caso Sistema de Caixa Automático Estudo de Caso Sistema de Caixa Automático Curso de Especialização DEINF - UFMA Desenvolvimento Orientado a Objetos Prof. Geraldo Braz Junior Referências: Notas de Aula Ulrich Schiel Notas de Aula Ariadne

Leia mais

Programa do Módulo 2

Programa do Módulo 2 4.1 Programa do Módulo 2 Orientação a Objetos Conceitos Básicos Análise Orientada a Objetos (UML) Diagrama de Classes Processo Unificado (RUP) Métodos Orientados a Objetos - UML 4.2 Diagrama de Classes

Leia mais

Conteúdo. Disciplina: INF 02810 Engenharia de Software. Monalessa Perini Barcellos. Centro Tecnológico. Universidade Federal do Espírito Santo

Conteúdo. Disciplina: INF 02810 Engenharia de Software. Monalessa Perini Barcellos. Centro Tecnológico. Universidade Federal do Espírito Santo Universidade Federal do Espírito Santo Centro Tecnológico Departamento de Informática Disciplina: INF 02810 Prof.: (monalessa@inf.ufes.br) Conteúdo 1. Introdução 2. Processo de Software 3. Gerência de

Leia mais

Programação Orientada a Objetos Prof. Rone Ilídio UFSJ/CAP

Programação Orientada a Objetos Prof. Rone Ilídio UFSJ/CAP Programação Orientada a Objetos Prof. Rone Ilídio UFSJ/CAP 1) Introdução Programação Orientada a Objetos é um paradigma de programação bastante antigo. Entretanto somente nos últimos anos foi aceito realmente

Leia mais

Ciclo de Desenvolvimento de Sistemas de BD

Ciclo de Desenvolvimento de Sistemas de BD Gerenciamento de Dados e Informação Fernando Fonseca Ana Carolina Valeria Times Bernadette Loscio Robson Nascimento Ciclo de Desenvolvimento de Sistemas de BD Investigação dos Dados Modelagem dos Dados

Leia mais

A Linguagem de Modelagem Unificada

A Linguagem de Modelagem Unificada A Linguagem de Modelagem Unificada Modelagem de Dados 1 A linguagem de Modelagem Unificada (UML Unified Modeling Language) é uma linguagem gráfica para comunicar especificações de projeto para software.

Leia mais

UNIVERSIDADE FEDERAL DO PARANÁ UFPR Bacharelado em Ciência da Computação

UNIVERSIDADE FEDERAL DO PARANÁ UFPR Bacharelado em Ciência da Computação SOFT DISCIPLINA: Engenharia de software AULA NÚMERO: 08 DATA: / / PROFESSOR: Andrey APRESENTAÇÃO O objetivo desta aula é apresentar e discutir conceitos relacionados a modelos e especificações. Nesta aula

Leia mais

ENGENHARIA DE SOFTWARE

ENGENHARIA DE SOFTWARE ENGENHARIA DE SOFTWARE PARTE 2 LINGUAGEM DE MODELAÇÃO UML CAP. 4 UML VISÃO GERAL Tópicos Introdução Visão Histórica Tipos de Elementos Básicos Tipos de Relações Tipos de Diagramas Mecanismos Comuns TiposdeDados

Leia mais

Capítulo 22. Associações entre Classes. Rui Rossi dos Santos Programação de Computadores em Java Editora NovaTerra

Capítulo 22. Associações entre Classes. Rui Rossi dos Santos Programação de Computadores em Java Editora NovaTerra Capítulo 22 Associações entre Classes Objetivos do Capítulo Indicar os diferentes aspectos de um relacionamento entre classes que podem ser expressos através de uma associação. Descrever o significado

Leia mais

Bibliografia. Desenvolvimento Orientado a Objetos. Introdução. Bibliografia. O que você vê?

Bibliografia. Desenvolvimento Orientado a Objetos. Introdução. Bibliografia. O que você vê? Bibliografia Desenvolvimento Orientado a Objetos Prof.: Edson dos Santos Cordeiro LARMAN, Graig. Utilizando UML e padrões. Porto Alegre: Bookman, 2000. STAA, Arndt von. Programação modular. Rio de Janeiro:

Leia mais

Análise e Projeto Orientado a Objetos. Modelagem de Domínio

Análise e Projeto Orientado a Objetos. Modelagem de Domínio + Análise e Projeto Orientado a Objetos Modelagem de Domínio Introdução 2 n A modelagem do domínio está relacionada à descoberta das informações que são gerenciadas pelo sistema. O resultado dessa investigação

Leia mais

Diagrama de entidades relacionamentos (abordado anteriormente) Diagrama de Fluxo de Dados (DFD)

Diagrama de entidades relacionamentos (abordado anteriormente) Diagrama de Fluxo de Dados (DFD) Diagrama de entidades relacionamentos (abordado anteriormente) Prod_Forn N N 1 Stock 1 1 N Prod_Enc N 1 N 1 Fornecedor Movimento Encomenda Diagrama de Fluxo de Dados (DFD) Ferramenta de modelação gráfica,

Leia mais

Banco de Dados - Senado

Banco de Dados - Senado Banco de Dados - Senado Introdução Ilka Kawashita Material preparado :Prof. Marcio Vitorino Ementa do Curso n Banco de Dados n Sistemas de Apoio à Decisão (SAD) n ORACLE BANCO DE DADOS (BD) n Modelo Entidade

Leia mais

Modelagem de Casos de Uso (Parte 1)

Modelagem de Casos de Uso (Parte 1) Modelagem de Casos de Uso (Parte 1) Roteiro Introdução Descrição: Sistema de Ponto de Vendas Casos de Usos Atores Fluxo de Eventos Cenários Formato de Documentação de Casos de Uso Diagramas de Casos de

Leia mais

Requisitos de Software

Requisitos de Software Requisitos de Software Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 6 Slide 1 Objetivos Apresentar os conceitos de requisitos de usuário e de sistema Descrever requisitos funcionais

Leia mais

O que é a UML? Introdução a UML. Objetivos da Modelagem. Modelos. A UML não é. Princípios da Modelagem. O que é um modelo?

O que é a UML? Introdução a UML. Objetivos da Modelagem. Modelos. A UML não é. Princípios da Modelagem. O que é um modelo? O que é a UML? Introdução a UML Linguagem Gráfica de Modelagem para: Visualizar Especificar Construir Documentar Comunicar Artefatos de sistemas complexos Linguagem: vocabulário + regras de combinação

Leia mais

Introduçãoa Engenhariade. Prof. Anderson Cavalcanti UFRN-CT-DCA

Introduçãoa Engenhariade. Prof. Anderson Cavalcanti UFRN-CT-DCA Introduçãoa Engenhariade Software Prof. Anderson Cavalcanti UFRN-CT-DCA O que é Software? O que é software? São programas de computadores, em suas diversas formas, e a documentação associada. Um programa

Leia mais

Ferramentas Estruturadas de Análise. Dicionário de Dados Diagramas Entidade-Relacionamento. Resumo. Elementos da Análise Estruturada

Ferramentas Estruturadas de Análise. Dicionário de Dados Diagramas Entidade-Relacionamento. Resumo. Elementos da Análise Estruturada Ferramentas Estruturadas de Análise Dicionário de Dados Diagramas Entidade-Relacionamento Profa iriam Sayão Diagrama de Fluxo de Dados - Rede de processos inter-relacionados. Dicionário de Dados e - Detalham

Leia mais

Análise e Projeto Orientado a Objetos

Análise e Projeto Orientado a Objetos Análise e Projeto Orientado a Objetos Linguagem UML Modelagem Estrutural Modelagem Estrutural Anderson Belgamo Classes Definição: uma classe é uma descrição de um conjunto de objetos que compartilham os

Leia mais

Especificação de Sistemas de Tempo-Real utilizando Orientação a Objetos

Especificação de Sistemas de Tempo-Real utilizando Orientação a Objetos Especificação de Sistemas de Tempo-Real utilizando Orientação a Objetos Marco Aurélio Wehrmeister mawehrmeister@inf.ufrgs.br Roteiro Introdução Orientação a Objetos UML Real-Time UML Estudo de Caso: Automação

Leia mais

Princípios de Análise e Projeto de Sistemas com UML

Princípios de Análise e Projeto de Sistemas com UML Princípios de Análise e Projeto de Sistemas com UML 2ª edição Eduardo Bezerra Editora Campus/Elsevier Capítulo 9 Modelagem de estados Todos os adultos um dia foram crianças, mas poucos se lembram disso.

Leia mais

USE CASES: continuação

USE CASES: continuação USE CASES: continuação Balcão de Companhia Aérea Fazer Check-in de Passageiro Funcionário Inserir Reserva de Voo Cancelar Reserva de Voo Os primeiros diagramas de Use Case (DUC) de um Sistema, descrevem

Leia mais

UML Diagramas de Classes

UML Diagramas de Classes UML Diagramas de Classes (versão reduzida) João Pascoal Faria UML Diagramas de Classes v.1.2, João Pascoal Faria, Outubro de 2002 1 Índice Objectivo dos diagramas de classes Objectos, classes, atributos

Leia mais

Engenharia de Software I

Engenharia de Software I Engenharia de Software I Curso de Desenvolvimento de Software Prof. Alessandro J de Souza ajdsouza@cefetrn.br 1 Rational Unified Process RUP Fase Elaboração 2 VISÃO GERAL Fase Elaboração. Visão Geral 3

Leia mais

MedEl: Uma solução de E-Learning utilizando tecnologia Microsoft ASP.NET

MedEl: Uma solução de E-Learning utilizando tecnologia Microsoft ASP.NET MedEl: Uma solução de E-Learning utilizando tecnologia Microsoft ASP.NET Átila Correia Cunha 1, 2, Glaucon Henrique Mauricio Maia 1, 2, Waner Ferreira Tavares 1, 2, Jorge Bergson¹, Rui Gomes Patrício 3

Leia mais

Programação Orientada a Objetos em Java. Herança

Programação Orientada a Objetos em Java. Herança Universidade Federal do Amazonas Departamento de Ciência da Computação IEC481 Projeto de Programas Programação Orientada a Objetos em Java Herança Professor: César Melo Slides baseados em materiais preparados

Leia mais

modelagem do negócio (processos e objetos do negócio) modelagem de requisitos alocados ao software modelagem da solução de software

modelagem do negócio (processos e objetos do negócio) modelagem de requisitos alocados ao software modelagem da solução de software POO com UML Java Uso da linguagem UML(Unified Modeling Language) A UML, ou Linguagem de Modelagem Unificada, é a junção das três mais conceituadas linguagens de modelagem orientados a objectos (Booch de

Leia mais

Unified Modeling Language UML

Unified Modeling Language UML Unified Modeling Language UML Classe e Objeto Atributo Operação Associações (Delegações [SANTOS, 2003]) Dependência Simples: multiplicidade, papel, navegabilidade Com valor semântico adicional: agregação

Leia mais

TRABALHO DE DIPLOMAÇÃO Regime Modular ORIENTAÇÕES SOBRE O ROTEIRO DO PROJETO FINAL DE SISTEMAS DE INFORMAÇÕES

TRABALHO DE DIPLOMAÇÃO Regime Modular ORIENTAÇÕES SOBRE O ROTEIRO DO PROJETO FINAL DE SISTEMAS DE INFORMAÇÕES TRABALHO DE DIPLOMAÇÃO Regime Modular ORIENTAÇÕES SOBRE O ROTEIRO DO PROJETO FINAL DE SISTEMAS DE INFORMAÇÕES [Observação: O template a seguir é utilizado como roteiro para projeto de sistemas orientado

Leia mais

COLÉGIO ESTADUAL ULYSSES GUIMARÃES CURSO TÉCNICO PROFISSIONALIZANTE EM INFORMÁTICA ERINALDO SANCHES NASCIMENTO

COLÉGIO ESTADUAL ULYSSES GUIMARÃES CURSO TÉCNICO PROFISSIONALIZANTE EM INFORMÁTICA ERINALDO SANCHES NASCIMENTO COLÉGIO ESTADUAL ULYSSES GUIMARÃES CURSO TÉCNICO PROFISSIONALIZANTE EM INFORMÁTICA ERINALDO SANCHES NASCIMENTO MODELAGEM DA ESTRUTURA LÓGICA DE UM SISTEMA: CLASSES E DIAGRAMAS DE CLASSE FOZ DO IGUAÇU 2013

Leia mais

Tutorial de Programação Orientada a Objeto

Tutorial de Programação Orientada a Objeto Universidade Federal Fluminense Centro Tecnológico Escola de Engenharia Curso de Engenharia de Telecomunicações Programa de Educação Tutorial Grupo PET-Tele Tutorial de Programação Orientada a Objeto (Versão:

Leia mais

Manual do Umbrello UML Modeller

Manual do Umbrello UML Modeller 2 Conteúdo 1 Introdução 7 2 Bases de UML 8 2.1 Acerca do UML....................................... 8 2.2 Elementos de UML..................................... 9 2.2.1 Diagrama de Casos de Utilização.........................

Leia mais

Após a leitura desse capítulo, o leitor saberá:

Após a leitura desse capítulo, o leitor saberá: Estudo Dirigido Disciplina: Modelagem de sistemas Diagrama de Classe - Modelo de domínio Após a leitura desse capítulo, o leitor saberá: - identificar uma classe e objetos - definir os tipos de classes

Leia mais

Disciplina: Unidade II: Prof.: E-mail: Período:

Disciplina: Unidade II: Prof.: E-mail: Período: Encontro 03 Disciplina: Sistemas de Banco de Dados Unidade II: Modelagem Conceitual de Dados Prof.: Mario Filho E-mail: pro@mariofilho.com.br Período: 5º. SIG - ADM 2. Modelagem Conceitual de Dados (Modelo

Leia mais

TECNOLOGIAS DA INFORMAÇÃO E COMUNICAÇÃO. SISTEMAS DE GESTÃO DE BASE DE DADOS Microsoft Access TECNOLOGIAS DA INFORMAÇÃO E COMUNICAÇÃO

TECNOLOGIAS DA INFORMAÇÃO E COMUNICAÇÃO. SISTEMAS DE GESTÃO DE BASE DE DADOS Microsoft Access TECNOLOGIAS DA INFORMAÇÃO E COMUNICAÇÃO TECNOLOGIAS DA INFORMAÇÃO E COMUNICAÇÃO Microsoft Access TECNOLOGIAS DA INFORMAÇÃO E COMUNICAÇÃO CONCEITOS BÁSICOS 1 Necessidade das base de dados Permite guardar dados dos mais variados tipos; Permite

Leia mais

Uma visão mais clara da UML Sumário

Uma visão mais clara da UML Sumário Uma visão mais clara da UML Sumário 1 Método...2 2 Análise de requisitos...2 2.1 Diagramas de Casos de Uso...3 2.1.1 Ator...3 2.1.2 Casos de Uso (Use Case)...4 2.1.3 Cenário...4 2.1.4 Relacionamentos...6

Leia mais

Diagrama de Classes. Diagrama de Classes. Diagramas de Classe. POST Criando Diagramas de Classe. Como construir (2)

Diagrama de Classes. Diagrama de Classes. Diagramas de Classe. POST Criando Diagramas de Classe. Como construir (2) Diagrama de Classes Diagrama de Classes Modelo de classes de especificação Perspectiva de Projeto Ilustra as especificações de software para as classes e interfaces do sistema. É obtido através da adição

Leia mais

Frameworks. Pasteur Ottoni de Miranda Junior

Frameworks. Pasteur Ottoni de Miranda Junior Frameworks Pasteur Ottoni de Miranda Junior 1-Definição Apesar do avanço das técnicas de desenvolvimento de software, a construção de software ainda é um processo extremamente complexo.a reutilização tem

Leia mais

Modelagemde Software Orientadaa Objetos com UML

Modelagemde Software Orientadaa Objetos com UML Modelagemde Software Orientadaa Objetos com UML André Maués Brabo Pereira Departamento de Engenharia Civil Universidade Federal Fluminense Colaborando para a disciplina CIV 2802 Sistemas Gráficos para

Leia mais

ENGENHARIA DE SOFTWARE

ENGENHARIA DE SOFTWARE ENGENHARIA DE SOFTWARE PARTE 2 LINGUAGEM DE MODELAÇÃO UML Tópicos Introdução Casos de Uso/Utilização Diagramas de Casos de Uso Proposta de Metodologia 2 CAP. 5 UML CASOS DE USO/UTILIZAÇÃO Introdução 3

Leia mais

BANCO DE DADOS PROFESSOR MAURÍCIO - MAURICIO.MELLO@PUCPR.BR AULA 02. O Modelo Entidade-Relacionamento ( MER )

BANCO DE DADOS PROFESSOR MAURÍCIO - MAURICIO.MELLO@PUCPR.BR AULA 02. O Modelo Entidade-Relacionamento ( MER ) AULA 02 BANCO DE DADOS PROFESSOR MAURÍCIO - MAURICIO.MELLO@PUCPR.BR O Modelo Entidade-Relacionamento ( MER ) Fases do Projeto de Bases de Dados (EN94)- O Modelo Entidade- Relacionamento Definição : modelo

Leia mais

Orientação à Objetos. Aécio Costa

Orientação à Objetos. Aécio Costa Aécio Costa O paradigma da orientação à objetos Paradigma? Um paradigma é uma forma de abordar um problema. No contexto da modelagem de um sistema de software, um paradigma tem a ver com a forma pela qual

Leia mais

CIn/UFPE Projeto Conceitual de BD - Prof. Robson Fidalgo 1

CIn/UFPE Projeto Conceitual de BD - Prof. Robson Fidalgo 1 CIn/UFPE Projeto Conceitual de BD - Prof. Robson Fidalgo 1 Projeto Conceitual de BD Transformação ER/Relacional Por: Robson do Nascimento Fidalgo rdnf@cin.ufpe.br CIn/UFPE Projeto Conceitual de BD - Prof.

Leia mais

Sumário. Capítulo 1 Introdução à UML... 17. Capítulo 2 Orientação a Objetos... 37. Agradecimentos... 6 Sobre o Autor... 6 Prefácio...

Sumário. Capítulo 1 Introdução à UML... 17. Capítulo 2 Orientação a Objetos... 37. Agradecimentos... 6 Sobre o Autor... 6 Prefácio... 7 Agradecimentos... 6 Sobre o Autor... 6 Prefácio... 15 Capítulo 1 Introdução à UML... 17 1.1 Breve Histórico da UML... 17 1.2 Por Que Modelar Software?... 18 1.2.1 Levantamento e Análise de Requisitos...

Leia mais

UML: Diagrama de Classes

UML: Diagrama de Classes UML: Diagrama de Classes UML Diagrama de Classes Introdução Diagrama de classes Elementos do diagrama de classes Exemplo: Sistema de matrícula Introdução - Diagrama de Classes Mostra um conjunto de classes

Leia mais

Analisar através de Casos de Uso,

Analisar através de Casos de Uso, 5.1 Programa do Módulo 2 Orientação a Objetos Conceitos Básicos Análise Orientada a Objetos (UML) Diagramas de Interação: Seqüência, Comunicação Processo Unificado (RUP) Métodos Orientados a Objetos UML

Leia mais

Conceitos, tabelas e consultas

Conceitos, tabelas e consultas MICROSOFT ACCESS Conceitos, tabelas e consultas 1. CONCEITOS Base de Dados é um conjunto de dados organizados SGBD (Sistema de Gestão de Base de Dados) programa que permite fazer a gestão da base de dados.

Leia mais

Padrão Básico de Projeto: Herança versus Composição

Padrão Básico de Projeto: Herança versus Composição Padrão Básico de Projeto: Herança versus Composição Composição e Herança Composição e herança são dois mecanismos para reutilizar funcionalidade Alguns anos atrás (e na cabeça de alguns programadores ainda!),

Leia mais

Bancos de Dados não Convencionais

Bancos de Dados não Convencionais Bancos de Dados não Convencionais Profa. Valéria Gonçalves Soares DI/UFPB Conteúdo 1. Introdução Integração de BDs com outras áreas Visão dos sistemas Visão das aplicações Limitações dos BDs Relacionais

Leia mais