PDS2

Processo de Desenvolvimento de

Software

UNIVERSIDADE ESTADUAL DE MATO GROSSO DO SUL Curso de Sistemas de Informação

Ementa

• Introdução

• Fases do desenvolvimento de software: • Análise • Projeto • Implementação • Testes • Implantação • Manutenção

• Modelos de Desenvolvimento de Software • Metodologias ágeis: SCRUM e XP

• Conceitos introdutórios de O.O. • Modelagem de Sistemas

• DFD

• UML: Diagramas de classe, objeto, atividades,

sequências, estados, casos de uso.

• Testes de Software

Bibliografia

- SOMMERVILLE, Engenharia de Software, 8. ed. São Paulo: Pearson, 2007.

- PRESSMAN, R. Engenharia de Software. São Paulo: Makron

Books, 1995.

- YOURDON, E. Análise Estruturada Moderna. Rio de Janeiro: Ed.

Campus, 1988

Bibliografia Complementar:

Metodologias Ágeis – SCRUM e

XP

Metodologias Ágeis – SCRUM

• Definição informal:

• Estratégia em um jogo de rugby onde jogadores

colocam uma bola quase perdida novamente em jogo através de trabalho em equipe.

SCRUM - Conceitos

• Uma alternativa de utilizar métodos ágeis na gerência de

projetos;

• Pode ser aplicável a qualquer tipo de projeto; • É simples:

• Processo, artefatos e regras são poucos e fáceis de

SCRUM - Conceitos

• Não é um método prescritivo

• Não define previamente o que deve ser feito em cada

situação;

• Projetos complexos não permitem prever todos os eventos.

• Define um framework e um conjunto de práticas; • Aplica o senso comum

• Combinação de experiência, treinamento, confiança e inteligência de

toda a equipe;

• Senso comum em vez do senso de uma única pessoa é uma das

razões do sucesso do Scrum.

SCRUM - Ênfase

• Comunicação;

• Trabalho em equipe; • Flexibilidade;

• Fornecer software funcionando:

• Incrementalmente.

SCRUM – Principais Padrões

SCRUM – Principais Padrões

SCRUM – Backlog

• Lista de todas as funcionalidades desejadas; • É gerada incrementalmente:

• Começa pelo básico, o extra aparece com o tempo

• Pode conter:

• Tarefas diretas, casos de uso e histórias.

• A lista é priorizada pelo dono do projeto:

• Cliente, departamento de marketing, etc.

SCRUM – Backlog Inicial

• Deve conter características que agreguem algum valor de

negócio ao produto;

• Novos requisitos aparecem quando o cliente vê o

produto;

• A arquitetura do sistema surge enquanto o projeto surge e

SCRUM – Principais Padrões

SCRUM – Equipes

• Sem nível hierárquico nem papéis:

• Mas com várias especialidades.

• Estão todos no mesmo barco;

• Geralmente equipes pequenas (até 10)

• Existem casos com equipes maiores (800); • Usa-se também Scrum hierárquico.

SCRUM – Equipes

SCRUM – Principais Padrões

SCRUM – Sprint

• Unidades básicas de tempo (até 30 dias); • Começa com um encontro Sprint

• Tarefas do Backlog são priorizadas;

• A equipe seleciona tarefas que podem ser completadas

durante o próximo Sprint;

• As mesmas podem ser quebradas para o Backlog do Sprint; • Cada tarefa recebe um responsável na equipe;

• Não há mudança nas tarefas durante o Sprint .

SCRUM – Principais Padrões

SCRUM – Encontro Scrum 1/2

• Pequenos encontros diários da equipe:

• geralmente pela manhã;

• todos da equipe devem participar e falar.

• Questões que aparecem devem ser resolvidas durante o

dia e não na reunião;

• Os encontros iniciais são geralmente mais longos.

SCRUM – Encontro Scrum 2/2

• Questões que devem ser respondidas por cada

membro da equipe:

• 1) O quê você fez ontem? • 2) O quê você vai fazer hoje?

• 3) Quais os problemas encontrados?

• Ajuda a manter as promessas;

SCRUM – Local de Encontro

• Sempre o mesmo local e

hora;

• Pode ser o local de

desenvolvimento;

• Pessoas sentadas ao

redor de uma mesa;

• A sala já deve estar

arrumada antes;

• Punições (atrasos/faltas); • Todos devem participar; • Pode ser em pé;

• Sala bem equipada,

quadro branco, etc.

SCRUM – Principais Padrões

SCRUM – Revisão do Sprint

• No final de cada Sprint é feita uma reunião com todos os

interessados;

• Geralmente:

• Na forma de demonstração;

• Informal (preparação rápida, sem projetor,..); • Deve ser o resultado natural de um Sprint.

• O projeto é comparado com os objetivos iniciais do Sprint.

SCRUM – Fases

SCRUM – Fases

SCRUM – Planejamento

• Relativamente curto;

• Projeto da arquitetura do sistema; • Estimativas de datas e custos; • Criação do backlog:

• Participação de clientes e outros departamentos;

• Levantamento dos requisitos e atribuição de

SCRUM – Fases

SCRUM – Sprint

• O equipe recebe uma parte do backlog para

desenvolvimento:

• O backlog não sofrerá modificações durante o Sprint;

• Duração de 1 a 4 semanas;

SCRUM – Fases

SCRUM – Sprint - Reuniões Diárias

• Cerca de 15 minutos de duração; • Todos respondem às perguntas:

• O que você realizou desde a última reunião? • Quais problemas você enfrentou?

• Em que você trabalhará até a próxima reunião? • Benefícios:

SCRUM – Fases

SCRUM – Sprint - Revisão

• Deve obedecer à data de entrega:

• Permitida a diminuição de funcionalidades. • Apresentação do produto ao cliente:

• Sugestões de mudanças são incorporadas ao backlog. • Benefícios:

• Apresentar resultados concretos ao cliente;

Nova

SCRUM – Fases

SCRUM – Encerramento

• Preparação de material de treinamento; • Preparação de material de marketing.

Papéis no Scrum

SCRUM – Papéis no Scrum

• Todas as responsabilidades de gerenciamento são

divididas entre três papéis: • Product Owner;

• Scrum Master; • Team (equipe).

• Para o bom funcionamento do Scrum as pessoas

responsáveis pelo projeto devem ter autoridade para fazer o que for necessário pelo seu sucesso;

• Pessoas não responsáveis não podem interferir no

projeto:

• Gera diminuição de produtividade;

• Evita situações constrangedoras para os envolvidos.

SCRUM – Papéis no Scrum

• Product Owner • Scrum Master • Team (equipe)

SCRUM – Papéis – Product Owner

• Responsável por apresentar os interesses de todos os

stakeholders;

• Define fundamentos iniciais do projeto, objetivos e planos de

release;

• Responsável pela lista de requisitos (Product Backlog);

• Certifica se as atividades com maior valor para o negócio são

desenvolvidas primeiro:

• Priorização frequente das funcionalidades

antes de cada iteração.

SCRUM – Papéis no Scrum

• Product Owner • Scrum Master • Team (equipe)

SCRUM – Papéis – Scrum Master

• Responsável pelo sucesso do Scrum;

• Ensina o Scrum para os envolvidos com o projeto;

• Implementa o Scrum na empresa de forma adaptada a sua

cultura, para continuamente gerar benefícios;

• Certifica se cada pessoa envolvida está seguindo seus papéis

e as regras do Scrum;

• Certifica que pessoas não responsáveis

não interfiram no processo.

SCRUM – Papéis no Scrum

• Product Owner • Scrum Master • Team (equipe)

SCRUM – Papéis – Team

• Responsável por escolher as funcionalidades a serem

desenvolvidas em cada interação e desenvolvê-las;

• A equipe se auto gerencia, se auto organiza;

• Todos os membros da equipe são coletivamente

responsáveis pelo sucesso de cada iteração.

SCRUM – Regras no Scrum

• O ScrumMaster deve se certificar de que cada envolvido

no projeto siga suas regras;

• As regras permitem a execução correta do Scrum;

• Mudanças das regras devem se originar do team

(equipe):

• O ScrumMaster deve ser convencido de que todos envolvidos

entenderam suficientemente as regras do Scrum para o correto discernimento;

• Discussões desnecessárias são perda de tempo de produção da

equipe.

SCRUM – Sprint Planning Meeting

• A reunião de planejamento do Sprint deve ocorrer dentro

de 8 horas com duas partes de 4 horas;

• Primeiro seguimento:

• Product Owner deve preparar o Product Backlog antes da reunião;

• Seleção dos itens do Product Backlog que a equipe se compromete

em torná-los incrementos potencialmente implementáveis;

SCRUM – Sprint Planning Meeting

SCRUM – Daily Meeting

• Reunião de no máximo 15 minutos, a menos que a equipe seja

grande o suficiente para precisar de mais tempo;

• Deve ser feita no mesmo lugar onde a equipe trabalha;

• Resulta em melhores resultados se realizada no inicio do dia

de trabalho;

SCRUM – Daily Meeting

• ScrumMaster faz as seguintes perguntas para cada

membro do time:

• O que você fez desde a última reunião diária do Scrum relacionada a

este projeto?

• O que você irá fazer desde agora até a próxima reunião diária do

Scrum relacionada a este projeto?

• O que está impedindo você de realizar o seu trabalho o mais

efetivamente possível?

• Os membros devem responder apenas a estas perguntas

para não estender a reunião.

SCRUM – Sprint

• Não deve ser maior do que 30 dias consecutivos;

• Sem considerar outros fatores, este é o tempo necessário

para produzir algo de interesse para o Product Owner e os stakeholders;

• A equipe se compromete com o Product Backlog:

• Não são permitidas modificações nele durante o Sprint.

SCRUM – Sprint

• Responsabilidades da equipe durante o Sprint:

• Participar das reuniões diárias do Scrum;

• Manter o Sprint Backlog atualizado;

• Disponibilizar o Sprint Backlog publicamente.

• A equipe tem o compromisso de implementar todos os

SCRUM – Sprint

SCRUM – Reunião de Revisão do Sprint

• Reunião de no máximo 4 horas sob responsabilidade

do ScrumMaster;

• A equipe não deve gastar mais de 1 hora na

preparação desta reunião;

SCRUM – Reunião de Revisão do Sprint

• No final da reunião:

• Cada stakeholder fala suas impressões e sugere mudanças com suas

respectivas prioridades;

• Possíveis modificações no Product Backlog são discutidas entre o

Product Owner e o team;

• ScrumMaster anuncia a data e o local da próxima reunião de revisão

do Sprint ao Product Owner e a todos stakeholders.

SCRUM – Reunião de Retrospectiva do Sprint

• Não deve ser maior do que 3 horas; • Participam desta reunião:

• Equipe, ScrumMaster e, opcionalmente, Product Owner.

• Os membros da equipe (team) devem responder a duas

questões:

• O que aconteceu de bom durante o último Sprint? • O que pode ser melhorado para o próximo Sprint?

SCRUM – Reunião de Retrospectiva do Sprint

• ScrumMaster escreve as respostas e prioriza na ordem

que deseja discutir as potenciais melhorias;

SCRUM – Reunião de Retrospectiva do Sprint

eXtreme Programming (XP)

O surgimento de XP

• Em meados de 1990, Kent Beck procurou formas

mais simples e eficientes de desenvolver software.

• Identificou o que tornava simples e o que

dificultava o desenvolvimento de software.

O que é eXtreme Programming?

• Metodologia ágil (leve) mais utilizada na

atualidade;

• Desenvolvida para:

• Equipes médias e pequenas (2 a 12 pessoas); • Requisitos vagos e em constante evolução.

• Possui um conjunto de valores e práticas para

nortear o desenvolvimento de software.

Estudo da palavra

Manifesto ágil

• Valorização de:

• Indivíduos e interação MAIS QUE processos e

ferramentas;

• Software em funcionamento MAIS QUE documentação

abrangente;

• Colaboração com o cliente MAIS QUE negociação de

contratos;

• Responder a mudanças MAIS QUE seguir um plano.

Manifesto ágil

• Principais preocupações:

• Entregar funcionalidades para o cliente de forma rápida; • Procuram usar o mínimo de documentação possível;

• Realizam projeto simples sem se preocupar em

Foco na satisfação do cliente

eXtreme

Programming

Princípios básicos

Comunicação

Coragem

Simplicidade

Feedback

Princípios básicos

• Comunicação

• Os membros da equipe (clientes, gerentes,

programadores) devem interagir ao máximo pessoalmente.

• Devem trabalhar na mesma sala, conversar

Princípios básicos

• Simplicidade

• Projeto é simplificado continuamente;

• Processo adaptado, caso algo não esteja funcionando.

Simplicidade

Princípios básicos

• Feedback:

• Cliente está sempre participando do desenvolvimento

do sistema;

• Testes de unidade e de aceitação fornecem feedback

sobre o sistema;

Princípios básicos

• Coragem

• Indicar problemas no projeto, parar quando está

cansado, pedir ajuda quando necessário;

• Simplificar código que está funcionado, dizer ao cliente

que não será possível implementar um requisito no prazo estimado;

• Seguir o XP como deve ser.

Coragem

XP- Práticas e Regras

Práticas e Regras de XP: Planejamento

• Planejamento;

• Projeto;

Práticas e Regras de XP: Planejamento

• Estórias de uso

• Usadas como requisitos do sistema;

• Mesmo propósito dos casos de uso (de UML),

porém menores e mais simples;

• Escritos na linguagem do cliente com o mínimo

de detalhes para a estimativa de custos.

Práticas e Regras de XP: Planejamento

• Iterações:

• Desenvolvimento dividido em iterações; • Possuem duração entre 1 e 3 semanas;

Práticas e Regras de XP: Planejamento

• Medida da velocidade de projeto:

• Indica a produtividade da equipe no projeto;

• Razão entre o que foi produzido e o que foi

estimado a cada iteração;

• Pode ser medido durante uma iteração;

• Variações dramáticas em mais de uma iteração

sugerem renegociação de prazo e escopo das

Práticas e Regras de XP: Planejamento

• Jogo do planejamento:

• Planejamento de versões (Releases);

• No início do projeto especifica-se que estórias de uso

serão implementadas em cada versão;

• Define-se as datas de liberação das versões;

Práticas e Regras de XP: Planejamento

• Jogo do planejamento

• Planejamento das iterações:

• Feito no início de cada iteração

• Estórias de uso são escolhidas de acordo com a importância pro

cliente e o risco pro projeto;

• Estórias são divididas em tarefas de 1 a 3 dias;

• Tarefas são distribuídas entre programadores e estimadas pelos

próprios executores.

• Estimativa preferencialmente baseada no passado; • Leva-se em conta a programação em pares.

• Estórias são adicionadas ou removidas para completar

Práticas e Regras de XP: Planejamento

• Versões frequentes e pequenas:

• Funcionalidades implementadas são

rapidamente entregues ao cliente;

• Permite um feedback mais rápido do cliente

Práticas e Regras de XP: Planejamento

• Reuniões rápidas (stand-up meeting):

• Faz a comunicação entre toda a equipe para

comunicar problemas, soluções, etc;

• Reunião feita em pé com poucos minutos de fala

para cada integrante.

Práticas e Regras de XP: Planejamento

• Planejamento;

• Projeto;

Práticas e Regras de XP: Projeto

• Simplicidade:

• Projetos simples tomam menos tempo que os

complexos;

• Evitar generalizações e abstrações

desnecessárias no momento;

• Um bom projeto deve conter o menor número

possível de classes e métodos;

• É mais rápido e barato;

• Requisitos mudam frequentemente.

Práticas e Regras de XP: Projeto

• Metáfora:

• Tem a intenção de oferecer uma visão geral do

sistema, em um formato simples, que possa ser compartilhada por clientes e programadores;

• Faz-se uma analogia entre o sistema e um outro

Práticas e Regras de XP: Projeto

• Criar spike solutions para reduzir riscos

• Programas muito simples (protótipos) utilizados

para verificar o uso determinadas soluções e tecnologias;

• Utilizados para reduzir os riscos técnicos do

projeto ou validar as estimativas realizadas.

Práticas e Regras de XP: Projeto

• Não adicionar funcionalidades antecipadamente: • Requisitos mudam rapidamente;

• Mantém o código limpo de adivinhações sobre o

Práticas e Regras de XP: Projeto

• O cliente está sempre disponível:

• Não deve só ajudar a equipe de

desenvolvimento;

• Deve ser parte da equipe;

• Comunicação com o cliente é feita em todas as

fases de um projeto XP;

• Estórias de uso, planejamento de versões,

feedback do sistema, testes de aceitação, etc.

Práticas e Regras de XP: Planejamento

• Planejamento; • Projeto;

Práticas e Regras de XP: Codificação

• Programação em pares:

• Duas pessoas programando em um mesmo

computador pensam melhor que uma;

• Revezamento: um programa enquanto o outro

projeta e faz revisão on-line do código digitado.

Práticas e Regras de XP: Codificação

• Programação em pares:

• Ganho de qualidade compensa o uso de duplas; • Auxilia a difusão de conhecimento.

Práticas e Regras de XP: Codificação

• Rotação de pares de programadores

• Ajuda ainda mais a eliminar as pessoas

consideradas “ilhas de conhecimento”;

• Cada um da equipe passa a conhecer todas as

partes do sistema;

• Os pares devem sempre ser encorajados a

trabalhar em partes do sistema desconhecidas por eles.

Práticas e Regras de XP: Codificação

• Propriedade coletiva do código:

• Todos são responsáveis por todo código;

• Permite que pessoas forneçam ideias para toda

parte do sistema;

• Diminui o risco de possuir pessoas

Práticas e Regras de XP: Codificação

• Código tem sempre que seguir um padrão: • Mantém o código consistente e uniforme;

• Facilita a leitura e entendimento por outros

programadores.

Práticas e Regras de XP: Codificação

• 40 horas semanais:

• Não se deve trabalhar mais de 60 h por 2 ou

mais semanas consecutivas;

• Horas extras não remuneradas prejudicam

motivação da equipe;

• A insatisfação de se trabalhar horas extras pode

Práticas e Regras de XP: Codificação

• Integração contínua:

• Módulos do sistema são integrados diversas

vezes ao dia;

• Todos os testes de unidade definidos são

executados;

• Identificação rápida de bugs inseridos;

• Programador sabe que trechos de código foram

alterados nas últimas horas.

Práticas e Regras de XP: Codificação

• Fazer refactoring sempre que possível

• Reestruturação sem acrescentar funcionalidade; • Remove redundâncias e melhora a qualidade do

projeto;

• Retira códigos não utilizados;

Práticas e Regras de XP: Planejamento

Práticas e Regras de XP: Testes

• Testes unitários:

• Teste das menores unidades (classes, métodos,

etc) ;

• Identifica bugs no código;

• Protege o código de manutenções indevidas;

Práticas e Regras de XP: Testes

• Testes unitários são escritos para detectar bugs

identificados:

• Criação do teste unitário que identifique o bug

antes de corrigi-lo;

• Bugs têm tendência de ressurgir

posteriormente.

Práticas e Regras de XP: Testes

• Testes antes da codificação:

• Limita o escopo da solução a ser implementada; • Serve de especificação do código testado;

Práticas e Regras de XP: Testes

• Execução periódica de testes de aceitação (testes

funcionais):

• Procuram testar uma funcionalidade como um

todo (Ex: Venda);

• Criados a partir das estórias de uso a serem

implementadas na iteração;

• Clientes verificam a corretude dos testes

escritos;

• Devem ser automatizados e regressivos.

Ciclo de Vida em XP

• Um projeto XP passa por algumas fases durante

seu ciclo de vida:

• Fase de exploração: Anterior à construção do

sistema. Visa verificar a viabilidade do sistema e experimentar possíveis soluções;

• Fase de planejamento inicial: Visa definir as

estórias e fechar com cliente o escopo e data do primeiro Release.

Ciclo de Vida XP

• Fase de iterações do release: Em uma iteração

algumas estórias são implementadas. Atividades de uma iteração: escrita dos casos de testes  projeto e refatoramento  codificação  realização dos testes  integração;

Ciclo de Vida XP

• Fase de manutenção: XP considera que

manutenção faz parte da sua natureza e suas práticas consideram um ambiente onde alterações são constantes;

• Fase de morte: Término de um projeto XP.

Papéis envolvidos em XP

• Treinador: Preocupa-se com a execução técnica e

evolução do processo. Possui conhecimentos de XP e orienta a equipe;

• Rastreador: Coleta dados sobre o andamento do

projeto e a sua conformidade com o planejamento feito para as iterações e release;

• Programador: Escreve o código e os casos de teste

unitários sempre em pares. É responsável por estimar o tempo para a implementação das estórias.

Papéis envolvidos em XP

• Cliente: Responsável por escrever as estórias junto com os

programadores e priorizá-las. Também ajuda na escrita dos casos de teste funcionais;

• Testador: Ajuda o cliente na definição e escrita dos testes

funcionais. Ele não precisa ser uma pessoa com apenas essa função, pode desempenhar também o papel de

Quando não se deve usar XP

• Possíveis barreiras para o sucesso de um projeto

XP:

• Cultura: Quando a empresa possui uma cultura

fortemente tradicional com ênfase em muita documentação, modelagem, etc;

• Tamanho da equipe: Beck considera que a equipe deve

ser pequena (até 12 pessoas);

• Espaço físico: O local de trabalho deve servir para

aproximar a equipe e facilitar a comunicação;

• Cliente: Em XP o cliente ou alguém que o represente

deve trabalhar junto à equipe.

XP

Conteúdo da Aula

• Paradigma da Orientação a Objetos • Conceitos da OO • Classes • Atributos • Métodos • Objetos • Herança • Polimorfismo • Encapsulamento 118

Paradigma da Orientação a Objetos

• Conjunto de regras que estabelecem fronteiras e

descrevem como resolver problemas dentro desta fronteira;

• Ajuda-nos a organizar a e coordenar a maneira como

olhamos o mundo.

Paradigma OO: Paradigma para o desenvolvimento de software que baseia-se na utilização de componentes individuais (objetos) que colaboram para construir sistemas

Paradigma Estruturado x Orientação a Objetos

Objeto

Objeto

Conceitos da Orientação a Objetos

conceitos: • Classes; • Objetos; • Herança; • Polimorfismo; • Encapsulamento. 122

Classe

• Definição

• Ao comparar diferentes objetos, notamos que eles

possuem atributos e comportamentos semelhantes, dependendo da finalidade para qual são observados.

Classe: é a definição dos atributos e das ações de um tipo de objeto; ela descreve um conjunto de objetos individuais em qualquer contexto. É obtida pela classificação de objetos com a mesma estrutura de dados e o mesmo comportamento.

Classe - Atributo

• Características importantes como visibilidade, nome,

tipo de dado e valor inicial;

• As visibilidades podem ser:

• Pública: é acessível (pode ser enxergado) por outras classes (+);

• Privada: é acessível somente pela própria classe (-);

• Protegida: é acessível somente pela sua classe e por suas

subclasses (#);

Classe - Métodos

• Os métodos implementam as operações de uma determinada

Classes - Métodos

• Um método possui:

• Visibilidade (representada pelos mesmos símbolos

utilizados pelos atributos);

• Nome;

• Lista de Argumentos; • Tipo de Retorno.

Objeto

• Segundo o dicionário Michaellis:

Objeto: tudo que é aprendido pelo conhecimento; tudo que

é manipulável e/ou manufaturável; tudo que é perceptível por qualquer dos sentidos; coisa, peça, artigo de compra e venda; o que é conhecido, pensado ou representado.

Objeto

• Definição

• Além de objetos animados, esta observação inclui

“São coisas do mundo real, como pessoas, animais, etc., que descobrimos estudando suas características (atributos), como altura, tamanho, cor e seu comportamento (ações), como falar, dormir, andar. “

Objeto

Objeto

Objeto - Identidade

• Cada objeto deve ter uma identidade própria

(identificador único) que o distingue entre outros objetos mesmo que seu estado seja idêntico ao de outro objeto:

• Dado 2 objetos:

Marca: Ferrari Marca: Ferrari Modelo: F50 GT Modelo: F50 GT

Chassi: 001002003 Chassi: 009008007

Objeto - Atributos

• Definem as características de um objeto;

• Atributos possuem valores que qualificam,

quantificam (ou identificam) um objeto;

• Compõe a estrutura de dados que vai representar

a classe que o objeto pertence.

Objetos - Métodos

• Definem as habilidades (comportamento) de um

objeto;

• Representam as ações que um objeto pode

Objeto - Mensagens

• É uma chamada a um objeto para invocar um de seus

métodos, ativando um comportamento específico de acordo com a especificação do próprio método;

• Uma mensagem é composta por 3 componentes básicos:

objeto, método e parâmetros (se existirem).

Objeto A

(Jogador) _Mensagem Objeto B(Bola)

Herança

• Entre diferentes classes podem existir diversas

semelhanças, ou seja, duas ou mais classes

poderão compartilhar os mesmos atributos e/ou os mesmos métodos.

Herança: É o ato de permitir uma classe de herdar o estado (atributos) e o comportamento (métodos) de outra classe.

Herança

Veículo de Transporte

Polimorfismo

Polimorfismo

Polimorfismo: É a capacidade de um objeto se

comportar de maneiras diferentes mediante à invocação de um mesmo método.

Polimorfismo

Carro

Trocar Marcha

Encapsulamento

• Isolamento de dados;

• Os atributos que estão encapsulados são envolvidos

por código de forma que só são visíveis no método em que foram criados.

Encapsulamento: Técnica que consiste em separar

aspectos externos dos internos da implementação de um objeto, isto é, determinados detalhes ficam ocultos aos demais .

Encapsulamento

Revisão

• O paradigma de objetos baseia-se nos seguintes

conceitos: • Classes; • Objetos; • Herança; • Polimorfismo; • Encapsulamento. 148

Relacionamentos entre

Objetos

Relacionamentos OO

• Qualquer programa geralmente é composto por diversos

objetos:

• Se relacionam entre si para executar o propósito do programa;

• Suponha que temos uma classe Livro e uma classe Biblioteca. As

classes Livro e Biblioteca relacionam-se entre si:

• Uma biblioteca possui um acervo de livros;

• De outra forma, uma biblioteca é composta por um conjunto de 0

(zero) ou mais livros.

Relacionamentos OO

• Como demonstrar os relacionamentos no diagrama de classes? • Tipos de relacionamento:

• Associação; • Agregação; • Composição; • Herança.

Associação

Relacionamentos OO

• Uma associação indica algum relacionamento significativo e de

interesse entre objetos;

• É representado por uma linha conectando os dois objetos:

• Pode existir uma seta no fim da linha, apontando para o objeto que

está sendo usado.

• A associação pode também receber um nome e uma

Relacionamentos OO

Relacionamentos OO

Relacionamentos OO

• Agregação:

• A relação é de: “é parte de”:

• Relaciona um objeto (o todo) com sua(as) parte(s) . Parte só é

criada quando o todo é criado;

• É representado por um losango vazio junto ao objeto

representando o todo.

Relacionamentos OO

Relacionamentos OO

• Agregação:

Relacionamentos OO

• Composição:

• A composição é uma agregação mais forte; • Um objeto “é parte essencial” de outro;

• Na composição, o objeto composto não existe sem os seus

componentes

• É representado por um losango preenchido em preto;

• Obs.: Em geral, na prática, é mais comum usar agregação mesmo

quando o relacionamento é mais forte.

Relacionamentos OO

Relacionamentos OO

• Composição:

Relacionamentos OO

• Herança:

• Relacionamento pelo qual uma classe, chamada de subclasse,

herda todos comportamentos e estados possíveis de outra classe, chamada de superclasse ou classe base. 

Relacionamentos OO

Relacionamentos OO

• Herança:

Relacionamentos OO

Exercícios

Modelagens de Sistemas

Paradigma Estruturado x Orientação a Objetos

Objeto

Objeto

Modelagem UML

UML

• O que é UML?

• UML é um acrônimo para a expressão Unified Modeling

Language;

• UML é uma linguagem que define uma série de artefatos que

nos ajuda na tarefa de modelar e documentar os sistemas orientados a objetos que desenvolvemos.

UML

• UML é uma linguagem (notação com semântica associada) para:

• Visualizar; • especificar; • construir e

• Documentar os artefatos de um sistema

• UML não é uma metodologia;

• Não diz quem deve fazer o quê, quando e como;

• UML pode ser usado segundo diferentes metodologias, tais

como RUP (Rational Unified Process), FDD (Feature Driven Development), etc;

• UML não é uma linguagem de programação.

Diagramas da UML

• Representações em pequena escala de um sistema sob um

ponto de vista particular;

• A UML possui diagramas divididos em dois grupos:

• Diagramas Estruturais: descrevem elementos estruturais que

compõem o sistema, representando suas partes e seus relacionamentos;

• Diagramas de Comportamento: descrevem o comportamento dos

elementos e suas interações.

Diagramas UML – Use Case

Diagramas UML – Use Case

• Descreve a funcionalidade proposta para um sistema que será

projetado. Excelente ferramenta para o levantamento dos

Diagramas UML – Use Case

182

Diagramas UML – Use Case

184

Diagramas UML – Classes

• Usado para visualizar as relações entre as classes que

envolvem o sistema, o que pode ser associativo, herança, uso e agregação.

186

Diagramas UML – Classes

Diagramas UML – Classes

• .

188

Diagramas UML

190

Cardinalidade

l Cardinalidade define o graus de relação entre duas classes ou

tabelas.

l Podemos ter os seguintes níveis de relacionamento: 0:1, 0: N,

1:N, N:N, 1:1 e N:1;

l Pode ser usado o * no lugar do N, exemplo: 0:1, 0: *,1:*, *:*,

1:1 e *:1

Cardinalidade

Cardinalidade

196

0.* 0.1

Exercícios Classes e Casos

de Uso

Exercícios - Classes

200 200