Fundamentos da Engenharia de Software

https://www.facebook.com/alvarofpinheiroaulas/
br.linkedin.com/in/alvarofpinheiro/
Engenharia de Software
Fundamentos
http://www.alvarofpinheiro.eti.br

Projeto
www.alvarofpinheiro.eti.br

Projetos
Origem dos erros nos softwares
Análise
56%
Programação
7%
Desenho
27%
Outros
10%

Projetos
Custo de correção dos erros
Custo
Incremento de
100 a 1000 vezes
Etapas do ciclo de desenvolvimento

Projetos
Incremento do custo dos erros
Captura de requisitos
Análise e Desenho
Codificação
Teste Unitário
Prova de Aceitação
Manutenção
1
2,5
5
10
25
100
Boehm, 1988

Fatores de êxito dos projetos
• Em 1998 o Standish Group levantou 365 companhias e 8000
projetos e apresentou os resultados em seu informe de 1999
• Melhora no êxito dos projetos: 16% en 1994 vs. 26% em
1998 além de redução de custos e tempos
• Causas: participação dos usuários, suporte executivo, claro
estabelecimento dos objetivos do negócio, administração de
projetos, entregas permanentes, requisitos firmes, menor
tamanho e duração do projeto, etc.

Êxito do projeto segundo seu tamanho
60
50
40
30
20
10
0
até $750m
$750m a $1.5M
$1.5M a $3M
$3M a $6M
$6M a $10M
+ de $10M
Porcentagem de
êxito (%)
Standish Group, 1999
Tamanho do projeto ($)

As seis melhores práticas para
desenvolver Projetos de SW
• Desenvolvimento iterativo
• Administração de requisitos
• Uso de arquitetura de componentes
• Modelo visual (UML)
• Verificação contínua da qualidade
• Administração de Mudanças

Análise

Engenharia
de
Requisitos

Metodologias
Modelos
Processos
Técnicas

Metodologias
O termo Engenharia de Software
surgiu em uma conferência no
final da década de 60. A proposta
inicial era a sistematização do
desenvolvimento de software, que
deveria ser tratado com
engenharia e não como arte.

Metodologias
Desta forma, a idéia foi propor a
utilização de métodos,
ferramentas e técnicas para a
produção de software confiável,
correto e entregue respeitando os
prazos e custos definidos.

Metodologias
As metodologias tradicionais
devem ser aplicadas apenas em
situações em que os requisitos do
software são estáveis e requisitos
futuros são previsíveis.

Metodologias
Dentre os fatores responsáveis
por alterações nos requisitos
estão a dinâmica das
organizações, as alterações nas
leis e as mudanças pedidas pelos
stakeholders, que geralmente têm
dificuldades em definir o escopo
do futuro software.

Metodologias
As metodologias ágeis incentivam
a mudança nos requisitos, pois
desta forma é possível realmente
entregar ao cliente o produto que
ele precisa.

Metodologias
O termo “metodologias ágeis”
tornou-se popular em 2001
quando dezessete especialistas
em processos de desenvolvimento
de software representando os
métodos Extreme Programming
(XP), Scrum, DSDM, Crystal e
outros, estabeleceram princípios
comuns compartilhados por todos
esses métodos.

Metodologias Ágeis
Conceito
Para ser realmente considerada
ágil a metodologia deve aceitar as
mudanças ao invés de tentar
prever o futuro.
O problema é como receber,
avaliar e responder às mudanças.

Metodologias Ágeis
Introdução
Enquanto as metodologias ágeis
variam em termos de práticas e
ênfases, elas compartilham
algumas características, como
desenvolvimento iterativo e
incremental, comunicação e
redução de produtos
intermediários, como
documentação extensiva.

Metodologias Ágeis
Introdução
Desta forma existem maiores
possibilidades de atender aos
requisitos do cliente, que muitas
vezes são mutáveis.

Metodologias Ágeis
Modelos
Dentre as várias metodologias
ágeis existentes, as mais
conhecidas são a eXtreme
Programming e a Scrum.

Metodologias Ágeis
X
Metodologias Tradicionais
Um exemplo de uma metodologia
tradicional ou pesada é o modelo
em Cascata, que é composto
basicamente por atividades
seqüenciais de levantamento de
requisitos, análise, projeto,
implementação, teste,
implantação e manutenção.

Metodologias
Manifesto Ágil
O resultado foi a criação da
Aliança Ágil e o estabelecimento
do “Manifesto Ágil” (Agile
Manifesto).

Metodologias
Manifesto Ágil Conceitos
Indivíduos e interações ao invés de
processos e ferramentas.
Software executável ao invés de
documentação.
Colaboração do cliente ao invés de
negociação de contratos.
Respostas rápidas a mudanças ao
invés de seguir planos.

Metodologias
É uma metodologia ágil para
equipes pequenas e médias que
desenvolvem software baseado
em requisitos vagos e que se
modificam rapidamente.

Modelo Cascata
O modelo em Cascata dominou a
forma de desenvolvimento de
software até o início da década de
90, apesar das advertências dos
pesquisadores da área e dos
desenvolvedores, que
identificaram os problemas
gerados ao se adotar esta visão
seqüencial de tarefas.

Modelo Cascata
O pesquisador, Tom Gilb,
desencoraja o uso do modelo em
Cascata para grandes softwares,
estimulando o desenvolvimento
incremental como um modelo que
apresenta menores riscos e
maiores possibilidades de
sucesso.

Processo

O que é um processo
• Um processo define quem faz o que,
quando e como para se alcançar
um objetivo

Processo
• Servir de guia para todos
• Especificar quais artefatos devem ser
gerados e quando devem ser gerados.
• Direcionar as Atividades individuais e de
equipes.
• Oferecer critérios para o gerenciamento
ISO9000-3

Processo de desenvolvimento
de um software
• Elicitação de requisitos
• Definição da arquitetura
• Análise
• Projeto
• Implementação
• Testes
• Implantação
• Manutenção

Controle dos Processos
• Arquitetura
• CMMI
• Fases
• Software Process Automation
• Fabrica de Software

Metodologias
Tradicionais

Rational
Unified
Process
(RUP)

RUP
RUP é um framework de processo centrado na
arquitetura, baseado em UML, dirigido por casos
de uso e como tal, precisa ser instanciado de
acordo com variáveis de tamanho,
complexidade e domínio do sistema, de acordo
com a organização com seus níveis de
processos e experiências e capacidade das
pessoas

Metodologias
Ágeis

Scrum

Scrum
Fases
• Planejamento
• Sprints
– Ciclos
• Encerramento

Scrum
Outra metodologia ágil que
apresenta uma comunidade
grande de usuários.

Scrum
Objetivo
Seu objetivo é fornecer um
processo conveniente para projeto
e desenvolvimento orientado a
objeto.

Scrum
Outros Objetivos
 Garantir maior flexibilidade e habilidade para
tratamento de sistemas complexos e simples;
 Produzir um sistema susceptível a mudanças de
requisitos iniciais e adicionais durante o projeto:
 Requerimentos dos clientes;
 Necessidades do negócio;
 Pressão relativa ao tempo;
 Competitividade do mercado;
 Qualidade;
 Recursos.

Scrum
Abordagem
A Scrum apresenta uma
abordagem empírica que aplica
algumas idéias da teoria de
controle de processos industriais
para o desenvolvimento de
softwares, reintroduzindo as
idéias de flexibilidade,
adaptabilidade e produtividade.

Scrum
Abordagem
O foco da metodologia é
encontrar uma forma de trabalho
dos membros da equipe para
produzir o software de forma
flexível e em um ambiente em
constante mudança.

Scrum
Idéia
A idéia principal da Scrum é que o
desenvolvimento de softwares envolve
muitas variáveis técnicas e do
ambiente, como requisitos, recursos e
tecnologia, que podem mudar durante
o processo. Isto torna o processo de
desenvolvimento imprevisível e
complexo, requerendo flexibilidade
para acompanhar as mudanças.

Scrum
A metodologia é baseada em
princípios semelhantes aos da XP:
equipes pequenas, requisitos pouco
estáveis ou desconhecidos e
iterações curtas para promover
visibilidade para o desenvolvimento.
No entanto, as dimensões em
Scrum diferem de XP.

Scrum
A Scrum divide o desenvolvimento em
iterações (sprints) de trinta dias.
Equipes pequenas, de até dez pessoas,
são formadas por projetistas,
programadores, engenheiros e
gerentes de qualidade. Estas equipes
trabalham em cima de funcionalidades
(os requisitos, em outras palavras)
definidas no início de cada sprint. A
equipe é responsável pelo
desenvolvimento desta funcionalidade.

Scrum
Na Scrum existem reuniões de
acompanhamento diárias. Nessas
reuniões, que são preferencialmente
de curta duração (aproximadamente
quinze minutos), são discutidos pontos
como o que foi feito desde a última
reunião e o que precisa ser feito até a
próxima. As dificuldades encontradas e
os fatores de impedimento
(bottlenecks) são identificados e
resolvidos.

Scrum
Introdução
ORIGEM:
ADM (Advanced
Development Methods)
+
VMARK Software
METODOLOGIA:
Gerenciamento, manutenção
e desenvolvimento de softwares:
simples e pequenos
grandes e complexos
PROCESSO:
Ágil
Empírico
Incremental
BASE P/ SCRUM:
Técnicas e tools OO

Scrum
Características
 Deliverable flexível;
 Cronograma flexível;
 Times de desenvolvimento pequenos (por volta de 6);
 Revisões frequentes;
 Colaboração;
 Orientação a Objeto.

Scrum
Fases
Planejamento
• Processo definido
• Relativamente curta
• Design 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 prioridades
• Definição de equipes e seus líderes
• Definição de pacotes a serem desenvolvidos
Backlog

Scrum
Fases
Sprint
• Processo Empírico
• Cada time recebe uma parte do backlog para
desenvolvimento
– O backlog não sofrerá modificações durante o Sprint
• Duração de 1 a 4 semanas
• Sempre apresentam um executável ao final
Fonte: Mountain Goat Software

Scrum
Fases – Sprint
Reuniões Diárias
• Cerca de 15 minutos de duração
• Gerenciada pelo líder de cada equipe
• 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:
– Maior integração entre os membros da equipe
– Rápida solução de problemas
• Promovem o compartilhamento de conhecimento
– Progresso medido continuamente
• Minimização de riscos

Scrum
Fases – Sprint
Revisão
• Deve obedecer à data de entrega
– Permitida a diminuição de funcionalidades
• Apresentação do produto à clientes e/ou diretores de marketing
– Sugestões de mudanças são incorporadas ao backlog
• Produto pode até ser lançado no mercado
• Benefícios:
– Apresentar resultados concretos ao cliente
– Integrar e testar uma boa parte do software
– Motivação da equipe

Scrum
Fases
Encerramento
• Iniciada quando todos os aspectos são
satisfatórios (tempo, competitividade, requisitos,
qualidade, custo)
• Atividades:
– Testes de integração
– Testes de sistema
– Documentação do usuário
– Preparação de material de treinamento
– Preparação de material de marketing

Qualidade, Gerenciamento e Testes
 Passos e papéis bem definidos
 Gerenciamento de riscos
 Revisões frequentes / diárias
 Definição de padrões
 Realização de testes
 Elaboração de documentação
 Grupo QA
Controles
Backlog
Release/Melhoria
Mudanças
Problemas
Soluções
Issues
Scrum

Conclusões
 Divisão de responsabilidades
 papéis bem definidos
 Processo ágil e flexível
 inúmeras mudanças no decorrer do
projeto
 Foco em controle/gerenciamento
 minimiza risco
 maximiza qualidade
 Times pequenos
 Colaboração
 Ausência de práticas de
(técnicas e notações) e
tools
 Necessidade de
associação com outras
metodologias e tools
(XP, GNATS)
 Dificuldade na
implementação de
mudanças
Scrum

XP – eXtreme
Programming

Introdução
Não se pode comparar XP com
UML, já que UML se presta apenas
como linguagem de modelagem,
não define processos e XP define
processo e não modelagem.
Conclusão, se você quiser pode
usar UML com XP.

Introdução
Entretanto, diferente dos processos
tradicionais, em XP a modelagem tem
duas utilidades:
1. O problema a ser tratado é
complexo e precisa ser melhor
entendido.
2. Uma parte do sistema ficou
"estável" (sem muitas modificações), e
pode ser documentada.

Metodologia
XP – eXtreme Programming
Dentre as principais diferenças da
XP em relação às outras
metodologias estão:
· Feedback constante;
· Abordagem incremental;
· A comunicação entre as pessoas
é encorajada.

Conceito
Em XP a modelagem não deve ser
usada para definir o design do
sistema.
Em XP assume-se que o sistema
está em constante mudança, ou
seja, seu design vai mudar, e sua
modelagem vai estar furada.

Teste Primeiro o Desenvolvimento
Se quiser modelar para ter um
melhor entendimento, sem
problemas, mas tenha em mente
que é uma modelagem que pode
não servir assim que o sistema
sofrer alterações, ao invés, XP
prega que se use Test First Design
(ou Test Driven Development,
outro nome pra mesma coisa).

Vantagem
Qual a vantagem em usar XP em
relação às metodologias tradicionais?
XP é baseado em sistemas que sofrem
constante mudança de requisitos, para
esse tipo de sistema, a vantagem é
poder mudar os requisitos sem o
impacto no desenvolvimento caso
fosse utilizada uma metodologia
tradicional.

Primeiro Projeto
O primeiro projeto a usar XP foi o
C3, da Chrysler. Após anos de
fracasso utilizando metodologias
tradicionais, com o uso da XP o
projeto ficou pronto em pouco
mais de um ano.

Paradigma
A maioria das regras da XP causa
polêmica à primeira vista e muitas
não fazem sentido se aplicadas
isoladamente.

Paradigma
A XP enfatiza o desenvolvimento
rápido do projeto e visa garantir a
satisfação do cliente, além de
favorecer o cumprimento das
estimativas.

Paradigma
As regras, práticas e valores da
XP proporcionam um agradável
ambiente de desenvolvimento de
software para os seus seguidores,
que são conduzidos por quatro
valores: comunicação,
simplicidade, feedback e coragem.

Regra: Comunicação
A finalidade do princípio de
comunicação é manter o melhor
relacionamento possível entre
clientes e desenvolvedores,
preferindo conversas pessoais a
outros meios de comunicação. A
comunicação entre os
desenvolvedores e o gerente do
projeto também é encorajada.

Regra: Simplicidade
A simplicidade visa permitir a criação de código
simples que não deve possuir funções
desnecessárias. Por código simples entende-se
implementar o software com o menor número
possível de classes e métodos. Outra idéia
importante da simplicidade é procurar
implementar apenas requisitos atuais, evitando-se
adicionar funcionalidades que podem ser
importantes no futuro. A aposta da XP é que é
melhor fazer algo simples hoje e pagar um pouco
mais amanhã para fazer modificações necessárias
do que implementar algo complicado hoje que
talvez não venha a ser usado, sempre
considerando que requisitos são mutáveis.

Regra: Feedback
A prática do feedback constante significa
que o programador terá informações constantes do
código e do cliente. A informação do código é dada
pelos testes constantes, que indicam os erros tanto
individuais quanto do software integrado. Em relação
ao cliente, o feedback constante significa que ele terá
freqüentemente uma parte do software totalmente
funcional para avaliar. O cliente então constantemente
sugere novas características e informações aos
desenvolvedores. Eventuais erros e não conformidades
são rapidamente identificados e corrigidos nas
próximas versões. Desta forma, a tendência é que o
produto final esteja de acordo com as expectativas
reais do cliente.

Regra: Coragem
É necessário coragem para implantar
os três valores anteriores. Por
exemplo, não são todas as pessoas
que possuem facilidade de
comunicação e têm bom
relacionamento. A coragem também dá
suporte à simplicidade, pois assim que
a oportunidade de simplificar o
software é percebida, a equipe pode
experimentar. Além disso, é preciso
coragem para obter feedback
constante do cliente.

Práticas
A XP baseia-se nas 12 práticas.

Práticas
· Planejamento
· Entregas freqüentes
· Metáfora
· Projeto simples
· Testes
· Refatoração
· Programação em pares
· Propriedade coletiva
· Integração contínua
· 40 horas de trabalho semanal
· Cliente presente
· Código padrão

Prática 1: Planejamento
Consiste em decidir o que é necessário ser feito e o
que pode ser adiado no projeto. A XP baseia-se em
requisitos atuais para desenvolvimento de software,
não em requisitos futuros. Além disso, a XP procura
evitar os problemas de relacionamento entre a área de
negócios (clientes) e a área de desenvolvimento. As
duas áreas devem cooperar para o sucesso do projeto,
e cada uma deve focar em partes específicas do
projeto. Desta forma, enquanto a área de negócios
deve decidir sobre o escopo, a composição das versões
e as datas de entrega, os desenvolvedores devem
decidir sobre as estimativas de prazo, o processo de
desenvolvimento e o cronograma detalhado para que o
software seja entregue nas datas especificadas.

Prática 2: Entregas Freqüêntes
Visa à construção de um software simples, e
conforme os requisitos surgem, há a atualização
do software. Cada versão entregue deve ter
o menor tamanho possível, contendo os
requisitos de maior valor para o negócio.
Idealmente devem ser entregues versões a cada
mês, ou no máximo a cada dois meses,
aumentando a possibilidade de feedback rápido
do cliente. Isto evita surpresas caso o software
seja entregue após muito tempo, melhora as
avaliações e o feedback do cliente, aumentando a
probabilidade do software final estar de acordo
com os requisitos do cliente.

Prática 3: Metáfora
São as descrições de um software
sem a utilização de termos
técnicos, com o intuito de guiar o
desenvolvimento do software.

Prática 4: Projeto Simples
O programa desenvolvido pelo método
XP deve ser o mais simples possível e
satisfazer os requisitos atuais, sem a
preocupação de requisitos futuros.
Eventuais requisitos futuros devem ser
adicionados assim que eles realmente
existirem. Esta forma de raciocínio se
opõe ao “implemente para hoje e
projete para amanhã”.

Prática 5: Testes
A XP focaliza a validação do
projeto durante todo o processo
de desenvolvimento. Os
programadores desenvolvem o
software criando primeiramente
os testes.

Prática 6: Refatoração
Focaliza o aperfeiçoamento do
projeto do software e está presente
em todo o desenvolvimento. A
refatoração deve ser feita apenas
quando é necessário, ou seja,
quando um desenvolvedor da dupla,
ou os dois, percebe que é possível
simplificar o módulo atual sem
perder nenhuma funcionalidade.

Prática 7: Programação em Pares
A implementação do código é feita em dupla, ou
seja, dois desenvolvedores trabalham em um único
computador. O desenvolvedor que está com o
controle do teclado e do mouse implementa o
código, enquanto o outro observa continuamente o
trabalho que está sendo feito, procurando identificar
erros sintáticos e semânticos e pensando
estrategicamente em como melhorar o código que
está sendo implementado. Esses papéis podem e
devem ser alterados continuamente. Uma grande
vantagem da programação em dupla é a
possibilidade dos desenvolvedores estarem
continuamente aprendendo um com o outro.

Prática 8: Propriedade Coletiva
O código do projeto pertence a todos os membros
da equipe. Isto significa que qualquer pessoa que
percebe que pode adicionar valor a um código,
mesmo que ele próprio não o tenha desenvolvido,
pode fazê-lo, desde que faça a bateria de testes
necessária. Isto é possível porque na XP todos
são responsáveis pelo software inteiro. Uma
grande vantagem desta prática é que, caso um
membro da equipe deixe o projeto antes do fim, a
equipe consegue continuar o projeto com poucas
dificuldades, pois todos conhecem todas as partes
do software, mesmo que não seja de forma
detalhada.

Prática 9: Integração Contínua
Interagir e construir o sistema de software
várias vezes por dia, mantendo os
programadores em sintonia, além de
possibilitar processos rápidos. Integrar
apenas um conjunto de modificações de cada
vez é uma prática que funciona bem porque
fica óbvio quem deve fazer as correções
quando os testes falham: a última equipe que
integrou código novo ao software. Esta
prática é facilitada com o uso de apenas uma
máquina de integração, que deve ter livre
acesso a todos os membros da equipe.

Prática 10: 40 hs de trabalho
semanal
A XP assume que não se deve fazer horas
extras constantemente. Caso seja necessário
trabalhar mais de 40 horas pela segunda
semana consecutiva, existe um problema
sério no projeto que deve ser resolvido não
com aumento de horas trabalhadas, mas com
melhor planejamento, por exemplo. Esta
prática procura ratificar o foco nas pessoas e
não em processos e planejamentos. Caso
seja necessário, os planos devem ser
alterados, ao invés de sobrecarregar as
pessoas.

Prática 11: Cliente Presente
É fundamental a participação do cliente
durante todo o desenvolvimento do
projeto. O cliente deve estar sempre
disponível para sanar todas as dúvidas
de requisitos, evitando atrasos e até
mesmo construções erradas. Uma idéia
interessante é manter o cliente como
parte integrante da equipe de
desenvolvimento.

Prática 12: Código Padrão
Padronização na arquitetura do
código, para que este possa ser
compartilhado entre todos os
programadores.

Crystal
Processo de
Desenvolvimento
de Software

• Crystal/Clear faz parte, na realidade, de
um conjunto de metodologias criado por
Cockburn. As premissas apresentadas para
a existência deste conjunto são:

• Todo projeto tem necessidades,
convenções e uma metodologia
diferentes.
• O funcionamento do projeto é
influenciado por fatores humanos, e há
melhora neste quando os indivíduos
produzem melhor.
• Comunicação melhor e lançamentos
freqüentes reduzem a necessidade de
construir produtos intermediários do
processo

• Crystal/Clear é uma metodologia
direcionada a projetos pequenos,
com equipes de até 6
desenvolvedores. Assim como com
SCRUM, os membros da equipe
tem especialidades distintas. Existe
uma forte ênfase na comunicação
entre os membros do grupo.
Existem outras metodologias
Crystal para grupos maiores.

• Toda a especificação e projeto são
feitos informalmente, utilizando
quadros publicamente visíveis. Os
requisitos são elaborados utilizando
casos de uso, um conceito similar às
estórias de usuário em XP, onde
são enunciados os requisitos como
tarefas e um processo para sua
execução.

• As entregas das novas versões de
software são feitos em incrementos
regulares de um mês, e existem
alguns subprodutos do processo
que são responsabilidade de
membros específicos do projeto.

• Grande parte da metodologia é
pouco definida, e segundo o autor,
isto é proposital; a idéia de
Crystal/Clear é permitir que cada
organização implemente as
atividades que lhe parecem
adequadas, fornecendo um mínimo
de suporte útil do ponto de vista de
comunicação e documentos

A família Crystal de Métodos
• Criada por Alistair Cockburn
• http://alistair.cockburn.us/crystal
• Editor da série Agile Software Development
da Addison-Wesley.

Feature Driven
Development
Desenvolvimento
orientado a
funcionalidades

FDD - Características
 Método ágil e adaptativo;
 Foco nas fases de desenho e construção
 Interage com outras metodologias
 Não exige nenhum processo específico de modelagem
 Possui desenvolvimento iterativo
 Enfatiza aspectos de qualidade durante o processo e
inclui entregas freqüentes e tangíveis
 Suporta desenvolvimento ágil com rápidas adaptações às
mudanças de requisitos e necessidades do mercado

FDD - Processos
 O FDD consiste de 5 processos principais:

FDD – Processos (Cont.)
 Desenvolver um modelo compreensível (Develop
an overall model)
 Construir uma lista de funcionalidades (Build a
features list)
 Planejar por funcionalidade (Plan By Feature)
 Projetar por funcionalidade (Design by feature)
 Construir por funcionalidade (Build by feature)

FDD - Cargos e Responsabilidades
 Principais
 Gerente de projeto (Project Manager)
 Arquiteto líder (Chief architect)
 Gerente de desenvolvimento (Development Manager)
 Programador líder (Chief programmer)
 Proprietário de classe (Class owner)
 Especialísta do domínio (Domain experts)
 Gerente do domínio (Domain manager)

FDD - Cargos e Responsabilidades
(Cont.)
 De apoio
 Gerente de versão (Release manager)
 Guru de linguagem (Language lawyer/language guru)
 Engenheiro de construção (Build engineer)
 “Ferramenteiro” (Toolsmith)
 Administrador de sistemas (System Administrator)
 Adicionais
 Testadores (Testers)
 Instaladores (Deployers)
 Escritores técnicos (Technical writes)

FDD - Boas Práticas
 Modelagem de objetos de domínio (Domain Object Modeling)
 Exploração e explicação do problema do domínio
 Resulta em um arcabouço
 Desenvolver por funcionalidade (Developing by feature)
 Desenvolvimento e acompanhamento do progresso através de da lista de
funcionalidades.
 Proprietários de classes individuais (Individual class ownership)
 Cada classe possui um único desenvolvedor responsável

FDD - Boas Práticas (Cont.)
 Equipe de funcionalidades (Feature teams)
 Formação de equipes pequenas e dinâmicas.
 Inspeção (Inspection)
 Uso dos melhores métodos conhecidos de detecção de erros.
 Construções freqüentes (Regular Builds)
 Garantir que existe um sistema sempre disponível e de-monstrável.
 Administração de Configuração (Configuration Manager)
 Habilita acompanhamento do histórico do código-fonte..

Dynamic Systems
Development
Method (DSDM)
Método dinâmico de
desenvolvimento de
sistemas

DSDM - Características
 Progenitor do XP
 Arcabouço para desenvolvimento rápido de
aplicações (RAD)
 Fixa tempo e recursos ajustando a quantia de
funcio-nalidades
 Pequenas equipes
 Suporta mudanças nos requisitos durante o ciclo
de vida

DSDM - Fases
 O DSDM consiste de 5 fases:
Feasibility
Review Study

DSDM – Fases (Cont.)
Estudo das possibilidades (Feasibility
study)
Estudo dos negócios (Business study)
Iteração do modelo funcional (Functional
model iteration)
Iteração de projeto e construção (Design
and build iteration)
Implementação final (Final implementation)

DSDM - Cargos e
Responsabilidades
 Desenvolvedores (Developers)
 Desenvolvedores Sêniores (Senior Developers)
 Coordenador Técnico (Technical Coordinator
 Usuário Embaixador (Ambassador User)
 Usuário Consultor (Adviser User)
 Visionário (Visionary)
 Executivo responsável (Executive Sponsor)
 Especialísta do domínio (Domain experts)
 Gerente do domínio (Domain manager)

DSDM - Práticas
 Usuário sempre envolvido
 Equipe do DSDM autorizada a tomar decisões
 Foco na frequente entrega de produtos
 Adaptação ao negócio é o critério para entregas
“Construa o produto certo antes de você construí-lo corretamente”
 Desenvolvimento iterativo e incremental
 Mudanças são reversíveis utilizando pequenas iterações
 Requisitos são acompanhados em alto nível
 Testes integrados ao ciclo de vida

Adaptive Software
Development
Desenvolvimento
Adaptável de
Software

ASD - Características
Iterativo e incremental
Sistemas grandes e complexos
Arcabouço para evitar o caos
Cliente sempre presente
Desenvolvimento de aplicações em
conjunto (Joint Application development –
JAD)

ASD - Fases
 O ASD possui ciclos de 3 fases:

ASD – Fases (Cont.)
 Especular (Speculate)
 Fixa prazos e objetivos
 Define um plano baseado em componentes
 Colaborar (Collaborate)
 Construção concorrente de vários componentes
 Aprender (Learn)
 Repetitivas revisões de qualidade e foco na demostranção das
funcionalidades desenvolvidas (Learning loop)
 Presença do cliente e especialistas do domínio
 Os ciclos duram de 4 a 8 semanas

ASD - Propriedades
 Orientado a missões (Misson-driven)
 Atividades são justificadas através de uma missão, que pode mudar ao
longo do projeto
 Baseado em componentes (Component-based)
 Construir o sistema em pequenos pedaços
 Iterativo (Iterative)
 Desenvolvimento em cascata (Waterfall) só funciona em ambientes bem
definidos e compreendidos. O ASD possui foco em refazer do que fazer
corretamente já na primeira vez

ASD – Propriedades (Cont.)
 Prazos pré-fixados (Time-boxed)
 Força os participantes do projeto a definir severamente decisões do projeto
logo cedo.
 Tolerância a mudanças (Change-tolerant)
 As mudanças são freqüentes
 É sempre melhor estar pronto a adaptá-las do que controlá-las
 Constante avaliação de quais componentes podem mudar
 Orientado a riscos (Risk driver)
 Itens de alto risco são desenvolvidos primeiro

ASD - Cargos e Responsabilidades
 Este método não descreve cargos em detalhes
 Executivo responsável (Executive Sponsor)
 Participantes de uma sessão (workshop) do desenvolvimento de aplicações em
conjunto (JAD)
 Facilitador (Facilitator)
 Liderar e planejar as sessões
 Escriba (Scribe)
 Efetuar anotações
 Cliente (Customer)
 Sempre presente
 Gerente de Projetos (Project Manager)
 Desenvolvedores (Developers)

Paradigma
Orientada a
Objetos

Desenvolvimento de Software
Programas
Processos
Dados

Enfoque a Programas
• Visão tradicional usa perspectiva de algoritmo
• O principal bloco de construção é o
procedimento ou função
• Conduz o foco de atenção para questões
referentes ao controle e a decomposição de
algoritmos maiores em outros menores
• Modelagem de dados quebrando os objetos em
tabelas, e criando mecanismos para junção
posterior

Objetos
Visualiza e representa o mundo real
como um conjunto de objetos que
interagem entre si para que determinadas
operações sejam realizadas.
Motorista Carro
Parar

Enfoque a Objetos
• Visão contemporânea adota perspectiva OO
• Forma de construir software que difere bastante
dos enfoques tradicionais
• Programação orientada a objetos é
freqüentemente referenciada como um “novo”
paradigma de programação.
• A palavra paradigma, neste contexto, significa
um conjunto de teorias, padrões e métodos que
juntos representam uma forma de organizar o
conhecimento

Enfoque a Objetos
• Ela é definida, no mais puro senso, como a
programação implementada pelo envio de
mensagens. A solução de um problema consiste
em identificar os objetos, mensagens e
seqüências de mensagens para efetuar a solução
• Um software desenvolvido com essa tecnologia
guarda muita semelhança com os objetos do
mundo real
• Cada objeto do mundo real transforma-se em um
“objeto” de software
• Conduz o foco de atenção para a montagem de
sistemas a partir de componentes

Exemplo
• Você resolve jantar numa pizzaria
• Existem vários objetos na pizzaria:
– Prédio
– Mesa
– Garçom, etc....
• Cada Objeto tem características que o
descrevem
– Mesa redonda ou quadrada
– Mesa desocupada ou não

Objetos (o domínio da aplicação)
pilha de entrada
pilha de saída
chefe
docs
secretária
doc
doc
arquivo
docs

Representando o mundo real
• Temos a representação do mundo real
• A aplicação de Entrada e Saída de
documentos nas caixas de entrada e saída
de uma secretária
• Transformando em representação de objetos
observamos que eles executam apenas
trocas de mensagens para se comunicar
entre si

Objetos (o modelo de objetos)
Chefe
Pilha de saída
Próximo
Secretária
Arquivo
Pilha de
entrada
doc
doc
doc
doc
doc
Cópia
Anotação
Edição
Próximo
Instrução
Interrupção
Instrução
Empilhamento Registro/Status

Abstração
eliminação
do
irrelevante
e
amplificação
do
essencial

Abstração
• É o mecanismo que nos permite
representar uma realidade complexa em
termos de um modelo simplificado, de
modo que detalhes irrelevantes possam
ser suprimidos.
• Processo de filtragem de detalhes sem
importância do objeto, para que apenas as
características apropriadas que o
descrevem permaneçam.

Três abstrações de um carro
Placa, conserto,
pagamento,
etc...
Km/l,
manutenção,
etc...
Identificação,
impostos, placa,
etc...
Registros
de oficina
Registros
em casa
Registros
Detran

Extraindo o essencial...
• Para processar algo do mundo real em
computador, temos que extrair as
características essenciais. Os dados que
representam estas características são
maneira como representam tal coisa em um
sistema
• Um mesmo objeto, por exemplo um carro
pode dependendo do contexto ser
visualizado de formas diferentes. Os dados
relevantes do carro para uma oficina, são
diferentes dos dados relevantes para o
Detran, por exemplo www.alvarofpinheiro.eti.br

Objetos
Conta corrente
deposito()
saldo

Objetos
• Um objeto é qualquer coisa, real ou abstrata, sobre a
qual armazenamos dados e operações que manipulam
tais dados
• Unidade básica de modularização do sistema na
abordagem OO
• Um objeto é um ente independente, composto por:
– atributos, isto é, características ou propriedades que definem o
objeto
– comportamento, isto é, um conjunto de ações pré-definidas
(denominada métodos), através das quais o objeto responderá
à demanda de processamento por parte de outros objetos

Objetos
• Validação de um Objeto
– É aplicável ao contexto ?
– Existe independente de outros Objetos ?
– Possui atributos e operações ?
– Exemplos
• Cor
• Exercício: Defina um computador PC segundo os
princípios de Orientação a Objetos

Simplificando...
• Sob o ponto de vista superficial , a expressão
orientada a objetos significa que o aplicativo é
organizado como uma coleção de objetos que
incorporam tanto a estrutura como o
comportamento dos dados
• Reflita alguns minutos como poderíamos montar
este ambiente em termos de objetos!!!.
• A seguir um exemplo de um controle de
Pizzaria (imagine como seria modelar este
ambiente em OO para calcular uma conta)

Controle de Pizzarias
• Sistema que informatiza os pedidos de pizza em um
restaurante
• Poderia ser modelado pelos objetos, Pedido, Cardápio,
Pizza, Caixa, Cliente, Garçom, Cozinheiro, etc.
• O Cardápio teria como responsabilidade, armazenar os
preços, mantendo-os atualizados
• Pedido seria responsável pelo processamento dos
pedidos feitos pelos clientes

Controle de Pizzarias
• Caixa calcularia a conta a ser paga.
• Caso houvesse alteração no sistema para atender a
necessidade de atualização de preços, esta seria
uma responsabilidade do Cardápio. Os demais
Objetos não sofreriam qualquer espécie de
alteração
• Caso a forma de calcular a conta fosse modificada
(por exemplo a gorjeta), o Caixa seria refeito.
• Enfim cada Objeto com sua respectiva função

Funcionário
Cozinheiro Garçom Serviços
Cardápio
Tipo
Prato
Preço
+AlteraPreço
+GetPreço
Caixa
Comanda
+CalculaConta
Pedido Cliente

Classes - Fabrica de Objetos
Definição da classe
Objetos

Classes
• Podemos fazer uma analogia dizendo que as
classes são “fábricas” de objetos.
• Exemplificando, temos que Pessoa é uma
classe e João é um objeto (instância) da
classe Pessoa
• Um carro é uma classe; “meu carro” é um
objeto
• Objetos similares são agrupados em classes

Programas x Classes
Programas Classes
processos atributos
dados operações

Notação para Classes
class Fruta
{
int gramas;
int cals_por_gramas;
int total_calorias ()
{ return gramas * cals_por_grama; }
}

Mensagem
• A POO identifica uma abordagem em que o
programador visualiza seu programa em
execução em termos de objetos que se
comunicam através de trocas de mensagens
• Mensagem - composta por um seletor e por
parâmetros (opcional)
Cliente Conta
debite(50R$) debite

Mensagem
• Objetos interagem enviando mensagens uns para
os outros.
• O objeto que receber a mensagem responderá
através da seleção e execução de um método que
fará parte de seu comportamento
• Após a execução, o controle volta para o objeto
que enviou a mensagem
• Uma mesma mensagem pode gerar ações
diferentes (alguma forma de polimorfismo)
• Em geral, classes bem projetadas escondem seus
dados de maneira que eles só possam ser
modificados por métodos daquela classe

Classe Exemplo
class Exemplo
{
public static void Main (string args[])
{
Fruta AlgumaFruta = new Fruta();
Citros Laranja = new Citros();
AlgumaFruta.Descascar();
Laranja.Descascar();
Laranja.Espremer();
}
}

Encapsulamento
separa os
aspectos
externos de um
objeto dos
detalhes de
implementação

Encapsulamento
• Encapsulamento separa os aspectos externos de um
objeto dos detalhes de implementação internos do
objeto
• É a propriedade dos objetos de agregarem, em seu
interior, dados e as operações que atuam sobre estes
dados.
• O encapsulamento possibilita que os objetos
escondam parte de seus componentes do mundo
exterior, de modo que o acesso às suas informações
seja controlado
• Você não precisa saber como um telefone realmente
funciona, para poder usar-lo. Só precisamos saber
para que ele serve, e conhecer sua interface, ou seja a
forma de nos comunicarmos com ele.

Encapsulamento
• Se a companhia telefônica mudar seus
processos, você vai continuar usando o
aparelho normalmente
• A implementação de uma classe, pode ser
alterada sem afetar a sua interface. Se um novo
telefone for criado, como um telefone digital, a
implementação foi alterada, mas a interface
permanece a mesma
• Reflita associando as idéias com um
liquidificador

Implementando o encapsulamento
• Telefone
– interface pública - que você usa para
interagir com o objeto
– implementação - as operações internas,
o propósito do objeto
• Carro
– interfaces públicas - pedais, direção,
câmbio
– implementação - o propósito do carro

Implementando o encapsulamento
• Em sistemas puramente orientado a
objetos, todos os atributos são privados e
apenas podem ser acessados ou
alterados através de operações na
interface pública
Exercício
• Descreva as interfaces disponíveis num
Sistema de Som
Baixar,Aumentar,Gravar,Adiantar,Voltar

Interfaces Públicas
Os detalhes de como são os métodos internamente, ou de
como eles são implementados não são visíveis através da
interface
Cliente Conta
nc debite
a1
b1
a2
b2
nc é o número da conta do cliente (do tipo Conta) e enxerga os métodos
debite, mb2 e mb3.
Um objeto do tipo Cliente não precisa saber detalhes de implementação
do método debite para chamá-lo, ele só precisa saber que a operação faz
um débito na Conta e conhecer a sua assinatura.

class Conta
{
private double saldo;
private long numero;
public void credite(double val)
{
saldo = saldo + val;
}
public void debite(double val)
{
saldo = saldo - val;
}
public void imprimaSaldo()
{
System.Out.Println(“Conta:“+numero+“Saldo:R$“ + saldo);
}
}

Generalização
• Generalização identifica e define coisas
comuns em uma coleção de objetos
Moveis
Cadeiras Mesas Biros
Quadrada Redonda

Generalização/Especialização
• Generalização é um processo que ajuda
a identificar as classes principais do
sistema. Ao identificar as partes comuns
dos objetos, a generalização ajuda a
reduzir as redundâncias, e promove
reutilização
• O processo inverso a generalização, e a
Especialização, que foca a criação de
classes mais individuais

Herança
Conta
ContaCorrente Poupança
ContaEspecial
Sobremesa
Bolo Sorvete
BoloDeChocolate

Herança
• É o mecanismo para definir uma nova
classe em termos de uma já existente
• É o relacionamento entre classes de
objetos que permite a uma classe incluir
atributos e operações definidas por outra
classe mais genérica.
• A classe mais genérica é chamada de
superclasse e as classe mais específicas
de subclasse.

Herança
• A forma de validar herança é usar a
frase “é um”.
• Exemplo da bicicleta e o avião, que
ambos tem rodas, assento, capacidade
de bagagem.
• Bicicleta é um avião
• Avião é uma bicicleta.

Herança
Figura
Polígono
Círculo
Cor
posição central
Num de lados
vértices
raio

Herança (Java)
class Fruta
{
int gramas;
}
class Citros extends Fruta
{
void espremer () {/*............*/}
}
Todas as cítricas são frutas

Polimorfismo
• Significa que a mesma operação pode ter
implementações diferentes.
• Uma subclasse pode sobrepor a
implementação de uma operação que ela
herda de uma superclasse.
• Somente pode ser usado com a herança

Polimorfismo de Sobreposição
Fruta
Descasca()
Cítrica Não Cítrica
Descasca()

Polimorfismo
• O polimorfismo de sobreposição é
resolvido dinamicamente
• Ocorre quando uma classe possui um
método com o mesmo nome e assinatura
(número, tipo e ordem dos parâmetros) de
um método da superclasse. Quando isso
acontece, dizemos que a subclasse
sobrepõe (overrides) o método da
superclasse

Polimorfismo
Ícone
origem: Ponto
exibir()
Botão
exibir()
O tratamento do exibir() em
Botão irá “overridar”
o exibir() do Ícone,
Apesar de herdar o método
dele e poder reutilizá-lo, ele
implementará de outra
maneira este método

Polimorfismo
• No exemplo do Sistema de Controle de Pizzaria
• Na pizzaria, a mensagem PRINT para Pedido
produz a conta
• Enviada para Cardápio, imprime a lista de
preços

Polimorfismo (Java)
class Fruta
{
int gramas;
void descascar () {System.Out.Println (descasca uma fruta); }
}
class Citros extends Fruta
{
void espremer () {/*............*/}
void descascar () {System.Out.Println (descasca uma citro); }
}

Polimorfismo (Java)
class Exemplo
{
public static void Main (string args [ ] )
{
Fruta AlgumaFruta = new Fruta ();
Citros Laranja = new Citros ();
AlgumaFruta.Descascar ();
Laranja.Descascar ();
Laranja.Espremer ();
}
}

Associação e Composição
• Objetos são associados quando um usa os
serviços do outro, e eles existem
independentemente
– A pessoa usa o computador
• A composição ocorre quando um objeto
esta contido no outro (tem).
– Lápis - grafite , receptáculo de madeira

Associação – Agregação – Composição
Associação – Agregação – Composição
Notação: ------- <>------ <>---------
Empresa (todo) <> --------------- Depto. (parte)

Custodia de um objeto
• Propriedade de um objeto e a
responsabilidade posterior de destruí-lo
• Exemplo:
• biblioteca e livros (custodia da biblioteca)
– se a biblioteca for destruída, os livros serão
destruídos, a menos dos livros emprestados que
a custodia esta com os usuários

Interfaces - Definições
• Uma interface é um esqueleto de uma
classe (a forma que a classe deve ter),
mostrando os métodos que a classe terá
quando alguém a implementar.
• É uma coleção de operações usadas para
especificar um serviço de uma classe ou
componente.

Interfaces
– Características
– Interfaces formalizam o polimorfismo
– Aumentam o nível de reusabilidade
– Viabilizam o uso de componentes
– Reduzem o esforço de evolução da
aplicação

Interfaces
– Características
– Definem um tipo especificando apenas a
assinatura de seus métodos
– Não podem ser instanciadas
– Não possuem atributos e seus métodos não tem
corpo
– Classes implementam interfaces, ou seja,
provêem implementação para os métodos
especificados em uma interface

Interfaces
– Utilidades e capacidades
– Garantir independência entre componentes de
software
– Garantir substituição de um serviço sem
necessidade de alterar quem está usando este
serviço
– Usada para generalizar conceitos
– Em JAVA, interface tem uma conotação muito
forte e poderosa e “emula”, de forma bastante
eficiente, herança múltipla

Herança Múltipla
Máquina Voadora Máquina Flutuadora
Hidroavião

interface MaquinaVoadora
{
int Navegar (ponto de, ponto para);
void Pousar ();
void Decolar (double combustivel);
}
class Helicoptero implements MaquinaVoadora
{
double Tanque_Combust;
int Rotac_motor;
int Rotores;
int Navegar (ponto de, ponto para) { */ o codigo aqui */ }
void Decolar (double combustivel)
{
Tanque_Combust + = combustivel;
for (; Rotac_motor < 6000; Rotac_motor ++);
}
void Pousar () {/*..................*/}
}

MaquinaFlutuadora
Navio
interface
implementação
Lancha Veleiro etc.....
Windsurf

interface MaquinaFlutuadora
{
int Navegar (ponto de, ponto para);
void LancarAncora ();
void LevantarAncora (double combustivel);
}
class Navio implements MaquinaFlutuadora
class Veleiro implements MaquinaFlutuadora
class Veleiro extends Navio

class HidroAviao implements Navio, MaquinaVoadora
{
double Tanque_Combust;
int Rotac_motor;
int Cabo_ancora;
void LancarAncora () { Cabo_ancora = 200; }
void LevantarAncora () { Cabo_ancora = 0; }
int Navegar (ponto de, ponto para) {/*................*/};
void Pousar ()
{
for ( ; Rotac_motor > 0; Rotac_motor --);
LancarAncora ();
}
void Decolar (double combustivel)
{
LevantarAncora ();
Tanque_Combust + = combustivel;
for ( ; Rotac_motor < 6000; Rotac_motor ++);
}
} www.alvarofpinheiro.eti.br

Negócio
Acesso
GUI Interface Interface Dados
CLIENTE BD

Interfaces
– Estudo de Caso
– Arquitetura do software para Java
Interface
Gráfica
Camada de
Aplicação
Camada de
Acesso a Dados
Comandos
SQL
insert
delete
update
Interface
Implementação
BD

Interface
Gráfica
Camada de
Aplicação
Camada de
Acesso a Dados
Chamada stored
procedure
insert
delete
update
Interface
mantida
Implementação muda
BD
Interfaces
– Estudo de Caso
– Arquitetura do software para Java

Abordagem Orientada a Objetos
INTERFACE
Dados
+
Operações
INTERFACE
Dados
+
Operações
solicita serviço
responde a
solicitação

Abordagem Orientada a Objetos
• Analogia com o LEGO (montar os componentes)
– Javabeans, EJB, ActiveX
• Em Java temos poucos tipos primitivos
(int, long, short, double, float, char, boolean)
Tudo são classes.
Exceções: Linhas de codigo, Guis, Strings, etc...
• Pacotes de bibliotecas de classes da plataforma Java
– java.lang - nucleo da linguagem
– java.awt - interface gráfica
– java.net - operações na rede
– java.io - lidar com arquivos
– java.util - utilitários

Unified
Modeling
Language
(UML)

Esquema da evolução
da
análise de sistemas
Métodos orientados a processos
simples e notação simples
Métodos orientados a dados
simples e notação simples
Métodos orientados a objetos
Simples e notação complexa
Processos de desenvolvimento
1994
Complexo (RUP)
Notação complexa
(UML)

Evolução
da
Análise Orientada a Objetos
• No princípio encontramos recomendações de desenho
(Booch, 1986)
• Se impõe o modelo orientado as características dos objetos
(Shlaer & Mellor, 1988)
• Surgem muitos métodos, mas de autores provenientes das bases de
dados relacionais
(Coad & Yourdon, Martin & Odell, Rumbaugh, Embley, etc., 1990)
• Se impõe os métodos orientados ao comportamento dos objetos
(Wirfs-Brock, Jacobson, Rubin & Goldberg, 1994)
• Começa a iniciar-se a UML (1994) www.alvarofpinheiro.eti.br

Evolução
da
Análise Orientada a Objetos
1980 1985 1990 1995 2000
Características
UML
Comportamentos

O caminho até a unificação
• Grady Booch manifiesta a necessidade de unificar critérios
• James Rumbaugh se une a Booch em outubro de 1994
• Ambos elaboram a versão 0.8 do Unified Method
• Em 1995 Ivar Jacobson completa o trio de “amigos”

O caminho até o padrão
• Se elabora a versão 0.9 do Unified Modeling Language
• Durante 1996 se realizam sucessivas modificações na base e
um acréscimo de novos participantes (versões 0.91 e 1.0)
• Se realiza a versão 1.1 em conjunto com outras importantes
empresas, que é apresentada a OMG (Object Management
Group)
• A OMG adota a UML versão 1.1 como standard no final de
1997
• Atualmente se encontra vigente a versão 1.4 e se está gerando
as bases da versão 2.0, que se espera seja mais estável

UML
Web - June ´96 UML 0.9
OOPSLA ´95 Unified Method 0.8
Other methods Booch method OMT
OOSE
public
feedback
Final submission to OMG, Sep ‘97
First submission to OMG, Jan ´97
UML 1.1
OMG Acceptance, Nov 1997
UML 1.3
UML partners UML 1.0
UML 1.4

UML
• Linguagem para visualizar,
especificar, construir e documentar
software
• Padrão aberto
• Suporta o ciclo completo do
desenvolvimento de sofware
• Suportada por várias ferramentas

Objetivos da UML
• Estabelecer uma linguagem visual de modelo,
expressivo e sensível em seu uso
• Manter uma independência dos processos de
modelagem das linguagens de programação
• Estabelecer bases formais
• Integrar as melhores práticas
• Impor um padrão mundial

Modelos, Visões e Diagramas
A model is a complete
description of a system
from a particular
perspective Use Case
DiUasgera Cmasse
DiUagsera Cmasse
Diagrams
Use Case
DiUasgera Cmasse
DiSaegqraumensce
Diagrams
Scenario
DiSagcreanmarsio
CDoiallgarbaomrastion
Diagrams
State
DiagSrtaamtes
DCiaogmrpamonsent
Diagrams
Component
DCiaogmrapmonsent
DDeiapglroamyms ent
Diagrams
Scenario
DiSagcreanmarsio
DSiatgarteacmhsart
Diagrams
State
DiagSrtaamtes
DiagCrlaamsss
Diagrams
Models

Desenvolvimento centrado em Modelos
Necessidade
dos Usuários
Processo 1
Processo de Desenvolvimento de SW
Modelo 1
Processo 2
Processo n
Modelo 2
Desenvolver Software é transformar modelos
SW Novo/
Modificado

Uso de Modelos
• Representações simplificadas de coisas reais
• Usados há muitos anos em outros ramos da
Engenharia,mais maduras que a nossa
• Se constroem para melhorar o entendimento
• Exemplos:
Maquetes, Planos, Equações, Protótipos,
Simulação por Computador,
Gráficos informais

Modelar não é um fim
• É um meio para construir melhor
• Se é mais barato construir e corrigir os erros sobre o
produto, Modelar não tem sentido
• É muito melhor ver o produto do software do que o
modelo, porém terminar o SW e ver que ele não atende
as Necessidades é muito mais caro
• A Correção é muito mais eficiente nas etapas iniciais do
Processo, e os modelos servirão de base para antecipá-los
• É conveniente conhecer vários tipos de Modelos. Distintos
problemas ou partes deles, requerem distintas técnicas de
modelagem

Estrutural: modela aspectos estáticos do
software focando nas entidades participantes
e seus relacionamentos. Os diagramas deste
conjunto são: diagrama de classes, objetos,
componentes e implementação.
Comportamental: modela aspectos dinâmicos
do software focando, na maioria das vezes,
como as entidades interagem para prover
uma determinada funcionalidade para o
usuário. Os diagramas deste conjunto são:
diagrama de casos de uso, seqüência,
colaboração, estados e atividades.

Arquitetura dos Modelos
Visão de
implementação
Visão de
Distribuição
Visão de
desenho
Visão de
processos
Visão de
casos de uso
Estrutura
(UC,Classes,Relações)
Estrutura
Componentes
Física (Topologia,
Implantação,comunicação)
Escalabilidade
(threads)

Ferramentas da UML
– O porquê das ferramentas da UML
– Administração de requisitos com casos de uso
– Modelos de interação
– Modelos de comportamento
– Modelos de desenhos

Ferramentas da UML
• Modelo de requisito
• Modelo de estrutura
• Modelo de interação
• Modelo de comportamento
• Ferramentas de desenho
• Organização de modelo
• Diagrama de casos de uso
• Diagrama de clases
• Diagrama de objetos
• Diagrama de sequências
• Diagrama de colaboracionais
• Diagrama de estados
• Diagrama de atividades
• Diagrama de componentes
• Diagrama de distribuição
• Diagrama de pacotes

O Porquê destas ferramentas
Classe Classe
Levantamento
Modelo de
casos de uso
Modelo de classes
Modelo de comportamento
Modelo de interação

Modelo de Requisitos
• Nos primeiros estágios da programação praticamente
se construía a aplicação dos requisitos em linguagem
natural
• Com o advento dos métodos de análise, se supunha
que os requisitos estavam completamente definidos
antes da modelagem
• Com os métodos orientados a objetos começam a
aparecer técnicas de modelagem de requerimentos,
baseados na criação de “cenários”

Construção dos Diagramas
• Passos recomendados:
• elaborar uma lista de atores e definir suas funções
• eleger o ator mais representativo do sistema para começar o diagrama
• esgotar todas necessidades funcionais do ator incorporando casos de uso da
funcionalidade base
• para cada caso de uso, buscar os atores que devam colaborar com ele
• repetir os dois passos anteriores para cada ator
• incorporar a funcionalidade necessária para exceções e erros
• fatorizar os casos de uso
• obter os atores abstratos mediante generalização
• descrever cada caso de uso a medida que se inclue no modelo
• validar e verificar o modelo junto com os usuarios

Estratégia de Levantamento
Erros
Exceções
Caminho
Base
Funcionalidade
desejada
Funcionalidade
não desejada

Casos de Uso
• Introduzido formalmente por Ivar Jacobson
• Aceitado pela comunidade usuária de OO e por muitos
metodologistas
• É empregado na etapa de levantamento para captar os
requerimentos dos usuários
• De fácil compreensão por parte dos usuários dos
sistemas
• Ferramenta que precisa de outros complementos para
ser utilizado em processos de modelagem OO

Casos de Uso
• São empregados para capturar o comportamento
que se espera do sistema, sem ter de especificar
como este comportamento é implementado (caixa
preta);
• Possibilitam que desenvolvedores obtenham uma
compreensão comum do sistema , junto aos
usuários e especialistas do domínio

Ainda sobre Casos de Uso
• Cada caso de uso descreve uma forma possível
de utilização do sistema por representar uma
porção de sua funcionalidade;
• Um caso de uso é uma descrição de um conjunto
de seqüência de ações, incluindo variações que
um sistema executa a partir das interações
externas ao sistema

Casos de Uso
Usuário
Emprestar
título
Devolver título
Reservar título
Ator

Cadastrar anamnese
Atendente de
1º nível
<<extend>>
<<extend>>
Consultar base de
conhecimento
Cadastrar satisfação do
solicitante
Abrir o.s.
Fechar o.s.
Realizar atendimento de 1º
nível
<<uses>>
Atendente de
1º nível
Diagrama de Casos de Uso

USE CASE: ABRIR O.S.
Fluxo de dados principal:
O use case inicia quando o solicitante telefona para o ramal do Call Center para a
resolução de um problema. O atendente de 1o nível informa a matrícula do
solicitante. O sistema verifica se o solicitante está cadastrado. Se o mesmo estiver
cadastrado, o atendente informa o equipamento e então o sistema verifica se o
mesmo está em manutenção. Se o equipamento não estiver em manutenção, o
sistema verifica se o equipamento está em garantia. Se não estiver em garantia, o
sistema busca os softwares associados àquele equipamento e o atendente verifica
a necessidade de execução do processo de anamnese. O sistema sugere a
prioridade do atendimento a partir do nível do solicitante e o atendente de 1o nível
confirma a prioridade do atendimento. Em seguida, informa a ocorrência do
problema. O atendente de 1o nível usa (consultar base de conhecimento). A
seguir, o atendente de 1o nível registra data, hora, tipo e dados obrigatórios da
O.S.
Fluxo de dados excepcional:
1. Se o solicitante não estiver cadastrado, o sistema não permite que o
atendimento seja realizado.
2. Se após a abertura da O.S., o atendente de 1o nível encontrou a solução do
problema, estende (fechar O.S).
3. Se o equipamento estiver em manutenção, o sistema não permite que o
atendimento seja realizado.
4. Caso o equipamento esteja em garantia e o tipo da O.S. não for de software, o
atendente de 1o nível registra data, hora, tipo, dados obrigatórios da O.S e
número do contrato, encaminhando-a para o coordenador de 2o nível.

Diagrama de Classes
Aluno
Curso Disciplina
Professor
1
1..*
0..6
0..*
0..*
1
1..* 1..*
matricula-se
ensina
pertence a
Aspectos estáticos

Diagrama de Classes
• Diagrama utilizado para representar os aspectos
estáticos do Sistema
• Exibe um conjunto de classes e seus
relacionamentos

Diagrama de Seqüência
: Atendente de 1º
nível
: Form
AbrirOS
: Solicitante
Abrir( )
Informar Matrícula Usuário( )
Finalizar
Validar Usuário( )
Usuário Não Cadastrado
Aspectos
Dinâmicos

Diagrama de Seqüência
• Usados para modelar os aspectos dinâmicos
do Sistema
• É um diagrama de interação que enfatiza a
ordenação de mensagens com relação ao tempo

Diagrama de Componentes
Aplicação Específica
Aplicação Geral
MiddleWare
System Software
Software
Gerencial Atendimento
Contratos Equipamento
Manutenção
Preventiva
Hardware
MTS
Windows NT
OS Ambiente de
Conhecimento
Software Func_Help_Desk Defeito
Oracle
Relacionamento
entre os
Componentes

Componentes
 • Os componentes são um importante bloco de
construção na modelagem dos aspectos físicos do
sistema;
 • Um componente é uma parte física e substituível
do sistema que realiza uma interface ou usa os
serviços da mesma;
 • Um componente tipicamente representa o
empacotamento físico dos elementos lógicos como
classes, interfaces e colaborações

Componentes
 Uma interface é uma coleção de operações que são
usadas para especificar um serviço de uma classe
ou um componente;
 O Diagrama de Componentes exibe as organizações
e dependências entre componentes, com o
propósito de modelar a visão de implementação dos
módulos de software executáveis de um sistema;

Diagrama de Componentes
 • Um nodo (nó) é um elemento físico que existe em tempo de
execução e representa um recurso computacional, geralmente
tendo pelo menos alguma memória e, freqüentemente,
capacidade de processamento
Nodos e Componentes
 • Componente são as “coisas” que participam na execução de
um sistema; os nodos são as “coisas” que executam os
componentes;
 • Os componentes representam o empacotamento físico dos
elementos lógicos; os nodos representam a distribuição física
dos componentes.

Diagrama de Distribuição
SERVIDOR DE DADOS SERVIDOR DE OBJETOS
Gerencial.DLL
Contrato.DLL
OS.DLL
Manutenção
Preventiva.DLL
Defeito.DLL
Software.DLL
Atendimento.DLL
Equipamento.DLL
Ambiente de
Conhecimento
.DLL
Func_Help_
Desk.DLL
Hardware.DLL
WINDOWS NT
ORACLE
Associação
dos componentes
ao Hardware
Micros Atendimento
1º Nível
HD.EXE
Micros Coordenação
HD.EXE
Micros Atendimento
2º Nível
HD.EXE
Micros Gerência
HD.EXE
REDE

Arquitetura

Acabamento
Instalações
Estrutura
Reboco
Base
Ambientação

Definição de Arquitetura
•A Arquitetura é uma série de abstrações que
permitem lidar com a complexidade das
soluções
• A Arquitetura forma a espinha dorsal para se
construir sistemas de software com sucesso

O que é Arquitetura de Software?
• É a visão do software a nível de funções
(subsistemas) e as interconexões entre
estas funções
• A arquitetura do software reflete como este
software irá funcionar
• Aspectos cruciais de um software são
determinados na definição da arquitetura do
mesmo
• A definição da arquitetura está baseada nos
requisitos funcionais e não-funcionais do
software em questão

O que é Arquitetura de SW?
“Uma arquitetura é composta de:
• Uma coleção de componentes,conexões e
restrições
• Uma coleção de declarações de stakeholders
sobre suas necessidades
• As razões que justifiquem que os
componentes,suas conexões e restrições
satisfaçam as necessidades dos stakeholders”
Barry Boehm

Relaciona-se com.....
 A organização de sistemas em termos de componentes
 Estruturas globais de controle
 Protocolos de Comunicação
 Sincronização e acesso a dados
 Alocação de funcionalidades aos elementos de projeto
 Composição dos elementos de Projeto
 Distribuição Física
 Escalabilidade e Desempenho
 Evolução do Sistema
 Seleção entre alternativas sobre decisões de projetos

Definição de Arquitetura
A atividade em Contexto:
Requisitos de
Qualidade Arquitetura de HW
Modificações
Arquitetura de SW
Modificações
Restrições
Análise de Domínio
Análise de Requisitos
Análise de Riscos
Desenho de
Arquitetura de
Software
Desenho
de Arquitetura
de Hardware
Desenho Detalhado,
Codificação,
Integração e Testes

Estilo de Arquitetura
Um estilo define uma família de sistemas em termos
de seus padrões de organização estrutural
Descrição do Estilo
• Componentes: unidades de software
• Conectores: comunicação entre componentes
• Estruturas de Controle e Comunicação de Dados
• Interação entre Dados e Controle, Regras e Restrições

Exemplos de Estilo - Arquitetura
 Sistemas em Camadas
 Baseado em Eventos
 Repositório Compartilhado
 Interpretadores
 Processamento Distribuído
 Programa Principal/Subrotinas
 Orientados a um domínio específico
 Pipe & Filter

Arquitetura de Software
• Modelos de Arquitetura
• O projeto de arquitetura pode ser
expresso através de diagramas de bloco
apresentando uma visão geral da
estrutura do sistema
• Modelos mais específicos mostram
• Compartilhamento de dados
• Distribuição
• Interfaces entre os sistemas
• Relacionamentos entre subsistemas

Modelos de Arquitetura
• Estrutura, controle e decomposição
modular podem ser baseados num
modelo ou estilo de arquitetura particular
• Como a maioria dos sistemas são
heterogêneos, filosofias de vários
modelos são utilizadas em um projeto
real de arquitetura

Modelos de Arquitetura
• O modelo de arquitetura usado afeta
– Desempenho
– Robustez
– Distributividade
– Manutenibilidade
• Alguns domínios de aplicação possuem
modelos específicos
–Compiladores
–Sistemas de acesso a redes locais

As 4 Visões
Visão Conceitual
Visão de Módulo
Visão de Código
Visão de
Execução
Componentes
Conectores
Configuração
Componentes
Conectores
Configuração
Restrições
de Execução
Módulos
Nova partição de módulos
Módulos
Subsistemas
Camadas
Construção de Código
Arquitetura de
Hardware
Restrições de Módulos
Nova partição
de módulos
Entidades de
tempo de
execução
Mudanças nas entidades

4 Visões
Visão Conceitual
• A funcionalidade do sistema se mapeia através de
componentes conceituais, e a coordenação
(fluxo lógico de controle) e a comunicação se resolve
com conectores
• É uma visão mais abstrata do domínio da aplicação
• Integração de Pacotes

Arquitetura:Visão Conceitual -Perguntas
• Os requisitos funcionais estão sendo atendidos?
• Como se integram os COTS (pacotes)?
• Como se incorporam SW/HW específico do
domínio?
• Como ela suportará a linha de produtos?.
• Como minimizar as mudanças de requisitos ou
domínio?

4 Visões
Visão de Módulos
• Aplicar abstração,encapsulamento e interfaces
• Decomposição do sistema em módulos e divisão
em camadas

Arquitetura:Visão de Módulos - Perguntas
• Como se mapeia o produto na plataforma de SW?
• Que serviços suporta/usa o sistema e exatamente onde?
• Como se pode testar?
• Como minimizar dependências e maximizar reuso de
módulos?
• Como podemos isolar as mudanças nos COTS
(commercial of the shelf), na plataforma de SW/HW?

4 Visões
Visão de Execução
• Distribuição de funcionalidades em entidades de tempo
de execução
• Resolução, Coordenação e Comunicação
• Assinalar os Hardwares

Arquitetura:Visão de Execução -
Perguntas
• Como se mapeia o produto em elementos de tempo
de execução?
• Como cumprimos os requisitos de performance,
recuperação e reconfiguração?
• Como se consegue concorrência, distribuição e
replicação sem fazer complexos algoritmos de
controle?
• Como se minimiza o impacto de mudanças na
plataforma de execução?

4 Visões
Visão de Código
• O código está dividido em muitos arquivos de distintos
tipos(bibliotecas, executáveis,etc.)
• Organizado em estruturas de armazenamento
• Depende da linguagem de programação
• Em versão e com implementações complexas

Arquitetura:Visão de Código -Perguntas
• Como se mapeiam as entidades de execução em
componentes de distribuição, como os módulos são
mapeados em código origem?
• Como se constroem os componentes de distribuição?
• Como se pode administrar versões?
• Como reduzir tempo e esforço na construção do
produto e suas melhoras?.
• Que ferramentas de desenvolvimenro seriam úteis e
como se suportam a integração e os testes?

Diferentes visões de uma Arquitetura
• Cada Projeto vai possuir uma visão dominante
 Por exemplo, frequentemente a visão de módulos
é dominante
 As demais visões são moldadas ou adaptadas
para se enquadrarem na visão dominante

Propriedades
• Arquiteturas definem componentes, porém omitem
seus detalhes privados( informações não arquiteturais)
• Explicita informações de como um componente
(USA, É USADO, SE RELACIONA COM, INTERAGE COM
OUTRO COMPONENTE)
• Comporta várias visões mais nenhuma visão
isoladamente pode ser considerada uma arquitetura
• Todo sistema tem Arquitetura
• O comportamento dos componentes é parte da
Arquitetura

Propriedades
Relembrando
O papel dos componentes, relacionamentos e até
mesmo o contexto mudam em cada visão
Exemplos:
Componentes podem ser : Módulos,Processos,etc.
Relacionamentos : É-Sub-Módulo,
Sincroniza-com,etc.
Contexto: Em tempo de desenvolvimento,
Em tempo de execução,etc.

Importância do projeto de
arquitetura
–Um mau projeto de arquitetura não
pode ser salvo por uma boa
implementação
– Existem modelos e estilos diferentes de
arquitetura
–Normalmente, vários modelos são
utilizados em um mesmo projeto de
software

Importância da Arquitetura
• A arquitetura abstrai informações detalhadas do
sistema mas consegue prover informação suficiente
para:
– Análise do sistema como um todo
– Tomada de Decisões (técnicas ou gerenciais)
– Redução de Riscos
• Se o projeto ainda não definiu a Arquitetura do
Sistema, incluindo sua justificativa, ele não deve
prosseguir com o desenvolvimento em larga escala

A Arquitetura auxilia a...
• Comunicação com os stakeholders
– Abstração de Alto nível comum a todos
– Cria um entendimento mútuo e consensual
• Decisões iniciais de projeto
– São críticas ( infra-estrutura, espinha dorsal do
sistema) e com impacto em todo ciclo de vida
• Reusabilidade de Abstrações
– A arquitetura é um artefato relativamente pequeno,
fácil de entender e que pode ser reusado em
outros projetos

Recomendações(Arquitetura)
• Trabalhar com grupo pequeno de liderados(+experientes)
• Partir dos requisitos e da lista priorizada dos atributos
de qualidade
•Deixar tudo sempre documentado
•Descrever como os requisitos são cumpridos
•Revisada por usuários e analisada formalmente
•Criar incrementalmente o sistema ao redor dela
•Seguir princípios de desenho

Arquitetura do Comércio Eletrônico
Camada Apresentação
(Cliente)
HTML Browser
Internet Explorer
Netscape
HotJava
HTTP
(web)
Servidor Internet
Windows
2000
Server
JSERV
Midware p/ interação
com Servelets
SERVLET Camada
Aplicação
Acesso
Dados
SGDB
Oracle
Servlet Interface Java
Request e Response
do Browser
Formata HTML de
Resposta
SGBD
Inteligência
da
Aplicação
Infra-Estrutura

• Passos do projeto de arquitetura
• Estruturação do sistema
• Modelagem de controle
• Decomposição modular

Tipos de Modelos
– Modelos Estruturais
• Modelo de Repositório -Case
• Modelo Cliente-Servidor
• Modelo de Camada - Modelo OSI
– Modelos de Controle
• Controle Centralizado
–Modelo de Retorno de Chamada
– Modelo de Gerente
• Controle Baseado em Eventos
–Modelo Broadcasting
– Modelo Baseado em Interrupções

Estruturação do Sistema
• O sistema é decomposto em vários
subsistemas principais e as comunicações
entre eles são identificadas
• Nesta etapa, os subsistemas são
determinados através de critérios gerais e
comuns a todos os softwares existentes
Exemplos:
• Acesso a banco de dados
• Regra de negócios e processamento
• Interface gráfica
• Comunicação

Estruturação do sistema
– Nesta fase, uma visão MACRO das
partes componentes do sistema e
suas respectivas interconexões são
obtidas
– Os requisitos do sistema têm que
estar estabelecidos para que critérios
de definição de arquitetura sejam
aplicados

• Modelagem de controle
• Um modelo do relacionamento de controle
entre as diferentes partes do sistema é
estabelecido
• Controle Centralizado
• Modelo de Retorno de Chamada
• Modelo de Gerente
• Controle baseado em Eventos
• Modelo Broadcasting
• Modelo de Interrupções

• Os subsistemas identificados são
decompostos em módulos
• Nesta fase, ocorre o detalhamento da
visão macro estabelecida na fase de
estruturação do sistema
• Exemplos:
• Subsistema Caixa
• Modulo de Recebimento
• Modulo de Abertura/Fechamento

• Subsistema
• Um subsistema é também um sistema,
cuja operação é independente dos
serviços providos por outros
subsistemas
• Módulo
• Um módulo é um componente do
sistema que provê serviços a outros
componentes mas que normalmente
não seria considerado um sistema
separado

Decomposição modular
• Diferença entre subsistemas e
módulos
• Não há uma definição clara
• Nomenclatura normalmente usada
indistintamente por projetistas e
analistas
• Engenharia de software moderna usa
estes termos para designar elementos
diferentes em um projeto de software

• Exemplo de Arquitetura
Interface
Gráfica
Comunicação
Processamento de
Pedidos
Cadastramento de
Informações
Acesso a Dados

• Modelo de arquitetura que mostra como
dados e processamento são distribuídos
entre processadores
• Componentes:
• Conjunto de servidores separados que
realizam serviços específicos
• Conjunto de clientes que usam estes
serviços
• Rede que permite que clientes acessem
os servidores
• Modelo largamente aplicado em sistemas
modernos

Cliente 1 Cliente 2 Cliente N
Rede (LAN, WAN ou Internet)
Servidor 1 Servidor 2 Servidor N

–Exemplo: Sistema de Vendas de Livros
–Sistema cliente-servidor 3 camadas
–Manutenção de livros e autores
–Processamento de pedidos de livros
–Exportação de pedidos (automática)
–Importação de cadastro de clientes
(automática)

–Exemplo: Sistema de Vendas de Livros
–Visão client-server da arquitetura (visão
mais física dos componentes de software)
Rede Local TCP/IP
Servidor de
Dados
Servidor de
Aplicação
GUI

Fundamentos da Engenharia de Software

Fundamentos da Engenharia de Software

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Destaque

Destaque (10)

Semelhante a Fundamentos da Engenharia de Software

Semelhante a Fundamentos da Engenharia de Software (20)

Mais de Álvaro Farias Pinheiro

Mais de Álvaro Farias Pinheiro (18)

Último

Último (8)

Fundamentos da Engenharia de Software