PROJETO DE DESENVOLVIMENTO DE SOFTWARE

Documentos relacionados
IFSC/Florianópolis - CTI - Projeto de Sistemas - prof. Herval Daminelli

Análise de Sistemas 4º Bimestre (material 3)

UML 2. Guia Prático. Gilleanes T.A. Guedes. Novatec. Obra revisada e ampliada a partir do título Guia de Consulta Rápida UML 2

Diagrama de Classes. Régis Patrick Silva Simão. Régis Simão Diagrama de Classes 1/42

Diagrama de Classes Diagrama mais

Prática interdisciplinar em desenvolvimento de software I

Diagrama de Classes. Diagrama mais. IMPORTANTE e UTILIZADO

15/04/2013. Outro Diagrama de Classes. Primeiro Diagrama de Classes. Diagrama de Classes. Atributos. Eduardo Figueiredo

Prática interdisciplinar em desenvolvimento de software I

POO Paradigma Orientado a Objetos. POO Paradigma Orientado a Objetos. POO Paradigma Orientado a Objetos. POO Paradigma Orientado a Objetos

Diagramas de Classes. Diagramas de Classes. Diagramas de Classes. Análise e Projeto de Sistemas OO

Linguagem de Modelagem Unificada UML

Diagrama de Classes 2017

3ª EDIÇÃO Gilleanes T. A. Guedes

MODELAGEM VISUAL DE OBJETOS COM UML DIAGRAMA DE CLASSES.

UML - Diagrama de Classes

Diagramas de Classes. ESII Profª. Andressa Falcade URI Santiago

Project-Based Learning TADS MS Diagrama de Classes

04/11/2016 UML. Prof. Esp. Fabiano Taguchi DIAGRAMAS DE CLASSE

Diagrama de Classes. Classes. Relacionamentos. Atributos Métodos. Associação. Generalização Dependência Realização. Agregação Composição

Modelo Conceitual Parte 1 Banco de Dados I Prof. Luiz Antônio Vivacqua C. Meyer

Especificação de Sistemas de Software e a UML

UML (Linguagem Modelagem Unificada) João Paulo Q. dos Santos

Aula 4 POO 1 Análise OO. Profa. Elaine Faria UFU

UML LINGUAGEM DE MODELAGEM UNIFICADA Diagrama de Classes

MODELAGEM DE SISTEMAS Unidade 4 Modelo de Classes de Projeto. Luiz Leão

Classe Abstrata e Interface

Introdução à UML. Prof. Jesus José de Oliveira Neto

Análise e Projeto de Software Parte I. Marcos Dósea

INSTITUTO FEDERAL DE EDUCAÇÃO, CIÊNCIA E TECNOLOGIA DO RIO GRANDE DO NORTE CAMPUS JOÃO CÂMARA UML UNIFIED MODELING LANGUAGE

Tópicos da Aula. Diretrizes Gerais. Trabalho Prático (TP) Pontuação do TP. Tema do Trabalho. Projeto de Software Diagrama de Classes

Requisitos de sistemas

DIAGRAMAS DE CLASSE UML

UML Diagrama de Classes

Modelagem Orientada a Objeto

Definições (II) Page 3

Definições. Definições (III) Definições (II)

Engenharia de Software Orientada a objetos. Prof. Rogério Celestino dos Santos

INF1013 MODELAGEM DE SOFTWARE

Modelo Conceitual. Análise e Projeto de Sistemas Avançados. Aula 5. Allan Rodrigo Leite

Programação Orientada a Objetos Relacionamentos entre classes

Definição. Em POO, a abstração é o processo de esconder os detalhes de implementação de uma aplicação.

PCS3413 Engenharia de Software e Banco de Dados

MODELAGEM DE SISTEMAS. Introdução a Computação e Engenharia de Software. Profa. Cynthia Pinheiro

Programação Orientada a Objetos 2 Flávio de Oliveira Silva, M.Sc.

S15 - Engenharia de Requisitos continuação cap.6

Os diagramas de use case capturam os requisitos funcionais do sistema.

Engenharia de Software. Prof. Me. Clodoaldo Brasilino

Introdução Diagrama de Classes Diagrama de Seqüência Diagrama de Atividades. Diagramas UML. Classe, Seqüência e Atividades. Marcio E. F.

Modelagem de dados usando o modelo Entidade- Relacionamento (ER)

Notas de Aula 03: Introdução a Orientação a Objetos e a UML

BANCO DE DADOS I. Prof. Luiz Antônio Vivacqua C. Meyer

DS: notação. Falta-nos apenas dar exemplos de DSS que contenham a criação de objectos temporários e sua posterior destruição.

PROGRAMAÇÃO ORIENTADA A OBJETOS II -TÉCNICAS DE OO. Prof. Angelo Augusto Frozza, M.Sc.

POO Paradigma Orientado a Objetos. POO Paradigma Orientado a Objetos. POO Paradigma Orientado a Objetos. POO Paradigma Orientado a Objetos

AVALIAÇÃO UNIFICADA 2015/2 SISTEMAS DE INFORMAÇÃO/4º PERÍODO NÚCLEO I CADERNO DE QUESTÕES

UML - Linguagem de Modelagem Unificada

PROJETO DE DADOS PROJETO ARQUITETURAL BÁSICO. Projeto de Programas PPR0001

Abordagem ER. Capítulo 2

Campus Capivari Análise e Desenvolvimento de Sistemas (ADS) Prof. André Luís Belini /

Diagramas de Classes e O Paradigma da Orientação a Objetos usando UML. Prof. Ricardo A. Ramos

Panorama da notação UML

Diagrama de Sequência

Programação Orientada a Objetos. Vagner Luz do Carmo - Vluzrmos

Análise e Projeto de Software Parte II. Marcos Dósea

Diagramas de Use Case Resumo

Modelagem de Sistemas

UNIVERSIDADE PAULISTA - UNIP ICET INSTITUTO DE CIÊNCIAS EXATAS E TECNOLÓGIA

UML - Unified Modeling Language

12/03/16. Generalização. Associação. Agregação UML Relações. entre Classes. Composição. Prof.Dr. Enzo Seraphim. Dependência

Programação para Games II. Professor Ariel da Silva Dias Orientação a Objetos

Análise e projeto de sistemas

Engenharia de Software. Aula 10 Representação dos Conceitos de Orientação a Objetos. Prof. Me. Rogério Ferreira

SISTEMA DE INFORMAÇÃO Modelo Conceitual. Prof. Luiz Fernando Laguardia Campos FMS

INF1404 MODELAGEM DE SISTEMAS

Linguagem de Programação III

Introdução. à UML. Histórico (cont.) Histórico Definição Benefícios Notação Diagrama de Classes Diagramas de Interação Conclusões Revisão

Tópicos da Aula. Desenvolvimento Dirigido por Modelos (MDD) Reusar cada vez mais... Reusar cada vez mais... O que é modelagem? Reuso: Código x Modelos

Linguagem de Programação. Diagrama de classes

IF685 Gerenciamento de Dados e Informação - Prof. Robson Fidalgo 1/64

MER e DER Entidades Relacionamentos Atributos Ferramentas CASE Exemplos de DERs Exemplo de Minimundo. Banco de Dados. Aula 1.

Introdução a UML (Unified Modeling Language)

Orientação a Objetos e UML

Classes e Objetos. Sintaxe de classe em Java

Realizando a Análise e Projeto

Revisão Diagrama de classes Elementos do diagrama de classes Exemplo: Sistema de matrícula

Introdução ao POO (Projeto Orientado a Objetos)

Introdução a UML e seus diagramas

Programação Orientada a Objetos. Prof. Diemesleno Souza Carvalho

INTRODUÇÃO À ENGENHARIA DE SOFTWARE. Prof.: Tiago Alves

Programação Java. Marco Fagundes. - Herança, Classes Abstratas e Interfaces Marco Fagundes -

Diagrama de Classes (Notação) - Aula 11 (parte 2)

UML. Modelando um sistema

UML Diagramas de Pacotes (Packages) e Modelação da Arquitectura Lógica. UML Diagramas de Pacotes v.1.1, João Pascoal Faria, 2001

PROGRAMAÇÃO ORIENTADA A

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

POO29004 Programação Orientada a Objetos

Aula 15 Modelagem de Classes de Análise. Análise de Sistemas Prof. Filipe Arantes Fernandes

Transcrição:

PROJETO DE DESENVOLVIMENTO DE SOFTWARE Professor: Diego Oliveira Aula 12: Diagrama de Classes

Diagrama de Classes Seu principal objetivo é permitir a visualização das classes que vão compor o sistema, seus atributos, métodos e como essas classes se relacionam entre si O Processo Unificado recomenda a utilização deste diagrama ainda na fase de Análise: nesta fase ainda não são representados os métodos, que são identificados na fase de Projeto, nos diagramas de interação (Seqüência) 2

Diagrama de Classes A representação de uma classe é feita assim: Nome da Classe Atributos Métodos 3

EXEMPLO DE DIAGRAMA DE CLASSES 4

Diagrama de Classes Visibilidade no Diagrama de Classes: (-) Privado: Somente a classe pode ver o valor do atributo (+) Público: Qualquer classe pode ver o valor do atributo (~) Pacote: Somente as classes do mesmo pacote podem ver o valor do atributo (#) Protegido: Somente a própria classe ou suas filhas por herança podem ver o valor do atributo 5

Diagrama de Classes Métodos podem retornar um valor de um tipo e também podem receber valores como parâmetros, cada um com um tipo O nome + tipo de retorno + parâmetros é a assinatura do método Lembrando que para fazer override (sobrescrita) ou overload (sobrecarga) é preciso atentar para isso! 6

Diagrama de Classes Exemplo de representação de métodos em um Diagrama de Classes: Não é preciso colocar o nome do parâmetro, apenas o tipo A visibilidade também aparece como nos atributos O tipo de retorno aparece no final, após os dois pontos 7

Diagrama de Classes Representação dos atributos e métodos dos exemplos anteriores em uma classe Java: 8

Continuação: Diagrama de Classes 9

Diagrama de Classes Adicionando Detalhes: A / antes dos atributos dt_abertura e dt_encerramento significa que os valores desses atributos sofrem algum tipo de cálculo A multiplicidade [0..1] depois de dt_encerramento significa que uma conta pode ou não ter essa data 10

Diagrama de Classes Relacionamentos ou Associações: Descrevem um vínculo que permite a troca de informações e colaboração para execução de processos dentro do sistema São representadas por linhas que podem ter nomes informando o tipo de associação Podem ser: Unárias, Binárias, Ternárias, Agregação, Composição, Generalização/Especialização, Classes Associativas, Realização ou Dependência 11

Associação Unária (ou Reflexiva) Ocorre quando existe um relacionamento de um objeto da classe com objetos da mesma classe: Um funcionário pode ser chefe de nenhum ou vários outros funcionários 12

Associação Binária É um relacionamento entre objetos de duas classes distintas: Um sócio pode possuir zero ou vários dependentes Um depentente obrigatoriamente estará vinculado a um sócio (implícito = 1..1) 13

Associação Ternária (ou N-ária) São associações que conectam objetos de três o mais classes São representadas por um losango que recebe todas as ligações da associação: 14

Agregação Por vezes as informações de um objetotodo precisam ser complementadas por informações contidas em outros objetos-parte Para isso utiliza-se a Agregação É representada por um losango (objeto-todo): 15

Composição É uma associação mais forte que a Agregação onde os objetos-parte precisam estar associados a um único objeto-todo e só podem ser destruídos por ele: Nesse caso os artigos só podem ser inéditos, ou seja, estão vinculados a uma única edição! 16

Generalização/Especialização Objetiva representar as relações de herança e possível polimorfismo Similar ao que foi visto no Diagrama de Casos de Uso 17

Classe Associativa Ocorrem em associações com multiplicidade muitos em ambos os lados Nesse caso há também uma informação importante na associação em si: o papel 18

Dependência Representa o grau de dependência de uma classe em relação a outra Nesse caso a placa-mãe depende da interface imonitor, provavelmente para seguir um padrão da indústria, pois interfaces possuem só as assinaturas dos 19 métodos

Realização Esta associação é utilizada para identificar classes responsáveis por executar funções para outras classes Nesse tipo de relacionamento se herda o comportamento de uma classe mas não sua estrutura (seria o implements do Java) 20

Portas Representam um ponto de comunicação entre um classificador e o ambiente São representadas por pequenos quadrados nas bordas da classe São mais utilizadas nos diagramas de estrutura composta e de componentes 21

Interfaces Podem ser fornecidas ou requeridas: Fornecidas: descrevem um serviço implementado por uma classe: Requeridas: descrevem um serviço que outras classes devem fornecer à classe em questão: 22

Restrições São condições a serem validadas durante a implementação dos métodos de uma classe, suas associações ou atributos São representadas por textos entre chaves Podem ser utilizadas para detalhar requisitos não-funcionais 23

Restrições Podem indicar também a forma de organização de alguns dados: Também podem indicar outras restrições à coleções (unique, bag, sequence): 24

Atributos Static São atributos cujo valor é o mesmo para todos os objetos de uma determinada classe São representados de maneira sublinhada 25

Estereótipos São representações que permitem destacar alguns componentes no diagrama que têm uma função especial É possível a criação de outros estereótipos Os principais são: <<entity>> <<boundary>> <<control>> 26

<<entity>> Explicitam que uma classe é persistente, ou seja, tem informações que serão armazenadas pelo sistema, provavelmente em um Banco de Dados <<persistente>>, porém podem ser transientes também São classes relacionadas com o contexto do software Representação: 27

<<boundary>> Representa uma classe que tem comunicação com o meio externo, um ator Muitas vezes é associada à própria interface do sistema Desnecessária em sistemas muito simples Sua representação: 28

<<control>> Identifica as classes que servem de intermediárias entre as classes <<boundary>> e as demais classes do sistema Interpretam os eventos ocorridos sobre os objetos <<boundary>> Sua representação: 29

Projeto Navigacional Alguns estereótipos podem ser utilizados para identificar certas telas possibilitando a representação da navegabilidade do sistema: <<server page>> <<client page>> <<form>> 30

Projeto Navigacional Exemplo de projeto navegacional: Observe que há outros estereótipos! 31

Exercício A partir do Diagrama de Casos de Uso feito para o SUAP na aula passada, faça o Diagrama de Classes Identifique o máximo de classes, associações (de todos os tipos), estereótipos e restrições Identifique as classes <<entity>>, <<control>> e <<boundary>>, as colocando nos locais corretos dentro do diagrama Faça também o Projeto Navigacional 32

Referências UML2: Uma Abordagem Prática 3ª Ed. 2018 Gilleanes T. A. Guedes 33

Perguntas? 34