You are on page 1of 62

Engenharia de software

Engenharia de software:
 Aplicação de uma abordagem sistemática, disciplinada e quantificável de desenvolvimento,
operação e manutenção de software.
 Criação e a utilização de sólidos princípios de engenharia a fim de obter software de maneira
econômica, que seja confiável e que trabalhe em máquinas reais.
 Ocorre como conseqüência de um processo chamado engenharia de sistemas. Em vez de se
concentrar apenas no software, a engenharia de sistemas focaliza diversos elementos, analisando,
projetando, e os organiza em um sistema que pode ser um produto, um serviço, uma tecnologia.
**** Eng. de processo > Eng. de produto > Eng. de sistemas > Eng. de software
**** A pedra fundamental da engenharia de software é o foco na qualidade.

Software: não é apenas o programa, mas também todos os dados de documentação e configuração
associados, necessários para que o programa opere corretamente.

Princípios da engenharia de software:


 Formalidade: desenvolvido de acordo com passos definidos com precisão e seguidos de maneira
efetiva.
 Abstração: preocupa-se com a identificação de um determinado fenômeno da realidade sem se
preocupar com detalhes, considerando apenas os aspectos mais relevantes.
 Decomposição: divide o problema em partes, de maneira que cada uma possa ser resolvida de
uma forma mais especifica.
 Generalização: resolver o problema de forma genérica, com o intuito de reaproveita a solução em
outras situações.
 Flexibilização: permite que o software seja alterado sem causar problemas para sua execução.

Ciclo de vida de software: é uma representação que descreve todas as atividades que tratam da criação de
um produto de software. Refere-se as fases pelas quais o sistema atravessa desde a sua concepção até sua
retirada de produção.
Modelo de ciclo de vida de software: apresenta não só as fases do ciclo de vida do software, mas também
como essas fases se relacionam.

Processo de software: trata-se de um conjunto de atividades, métodos, práticas e transformações que


guiam pessoas na produção de software.

Modelo de processo de software: trata-se exatamente do mesmo conceito de modelo de ciclo de vida. É
uma representação abstrata de um processo de software.

Ciclo de vida básico (fases):


 Planejamento
 Análise e especificação de requisitos
 Projeto
 Implementação
 Teste
 Entrega e implantação
 Operação
 Manutenção

Atividades fundamentais:
 Especificação de software
 Desenvolvimento (projeto, implementação)
 Validação
 Evolução
Modelo em cascata: uma fase inicia só após o termino e aprovação da fase anterior.
Sommerville Yourdon Pressman 4º ed Pressman 6ºed Royce
Análise e Requisitos de Modelagem e Comunicação Elicitação de
definição de sistema engenharia do requisitos
requisitos sistema/informação
Projeto de sistema Requisitos de Análise de Planejamento Projeto
e software software requisitos de
software
Implementação e Análise Projeto Modelagem Construção
teste de unidade
Integração e teste Projeto Geração de código Construção Integração
de sistema
Operação e Codificação Testes e Implantação Teste de depuração
manutenção manutenção
Teste Instalação
Operação Manutenção de
software

Vantagens Desvantagens
É simplessss de entender e fácil de aplicar, Divisão inflexível do projeto em estágios distintos.
facilitando o planejamento.
Fixa pontos específicos para entrega. Dificuldade em incorporar mudanças de requisitos.
Funciona bem para equipes fracas. Clientes só visualizam resultados próximos ao final
do projeto.
É fácil de gerenciar, devido a sua rigidez. Atrasa a redução de riscos.
Realiza documentação extensa por cada fase. Apenas a fase final produz um artefato de software.
Possibilita boa aderência a outros modelos de O cliente deve saber todos os requisitos no início
processo. do projeto.
Funciona bem com projetos pequenos e requisitos Modelo inicial (royce) não permitia feedback entre
bem conhecidos. as fases do projeto.
Pressupõe que os requisitos ficarão estáveis ao
longo do tempo.
Não funciona bem com projetos complexos e
orientação a objetos, apesar de compatível.
Modelo iterativo x modelo incremental:
 Iterativo: lança-se a versão 1.0, adiciona-se funcionalidades, lança-se a versão 2.0 e assim por
diante.
 Incremental: há várias equipes desenvolvendo uma parte do software a serem integradas no fim.

RAD: modelo iterativo e incremental que enfatiza o ciclo de desenvolvimento curto (60-90 dias).
 Fases:
o Modelagem de negócio:
o Modelagem de dados:
o Modelagem de processo:
o Geração da aplicação:
o Teste e modificação:
Vantagens Desvantagens
Permite o desenvolvimento rápido ou a Exige recursos humanos caros e experientes
prototipagem
Criação e reutilização de componentes O envolvimento com o usuário tem que ser ativo
Desenvolvimento é conduzido em nível mais alto Comprometimento da equipe do projeto
de abstração
Grande redução de codificação manual com Custo alto do conjunto de ferramentas e hardware
wizards para rodar a aplicação
Cada função pode ser direcionada para uma equipe Mais difícil de acompanhar o projeto
separada
Maior flexibilidade Perda de precisão cientifica
Provável custo reduzido Pode levar ao retorno das práticas caóticas
Tempo de desenvolvimento curto Requisitos podem não se encaixar
Protótipos permitem uma visualização mais cedo Padronização
Envolvimento maior do usuário Pode construir funções desnecessárias

Modelos evolucionários: como um tipo de modelo iterativo. Se baseia na idéia de desenvolvimento de


uma implementação inicial, expondo o resultado aos comentários dos usuários e refinando esse resultado
por meio de várias versões até que seja desenvolvido um sistema adequado ou descartando-o. Não vai
necessariamente liberar funcionalidades a cada iteração. As atividades de especificação, desenvolvimento
e validação são intercaladas, com feedback rápido. Implementações mais famosas:
 Prototipagem
 Espiral

Modelos em prototipagem: utilizada quando não se conhece bem os requisitos, é uma forma de entendê-
los. É iterativo e rápido. Custos são controlados e as partes interessadas podem experimentar o protótipo
mais cedo. Prototipagem pode ocorrer de duas maneiras:
 Desenvolvimento exploratório: trabalha com o cliente para explorar os requisitos e entregar um
sistema final.
 Prototipação throway: objetivo é compreender os requisitos do cliente e desenvolver melhor
definição dos requisitos. Protótipo é para entender os requisitos mal compreendidos.
Modelo em espiral: processo de software orientado a riscos. Combina atividades de desenvolvimento com
aspectos gerenciais. Conhecido como prototipagem em etapas, por combinar o modelo em cascata com a
prototipação. Cada loop representa uma fase do processo de software. As fases não são fixas, já as
atividades são fixas, mas não obrigatórias. Não posso criar uma nova atividade. Divide-se em quatro
setores:
 Determinar objetivos, alternativas e restrições
 Avaliar alternativas, identificar e resolver riscos
 Desenvolver e testar
 Planejar próximas fases
Cada espiral é dividida em 5 setores:
 Comunicação
 Planejamento
 Modelagem
 Construção
 Implantação
Modelo baseado em componentes: um componente é um bloco de construção modular, é uma parte do
sistema executável, implantável, independente, padronizada, e reutilizável. Os custos de desenvolvimento
são menores que os custos de integração e teste.

Métodos formais: é utilizado em ambientes extremamente complexos. São lentos e dispendiosos e exigem
treinamento intensivo.

Modelo orientado a aspectos: é uma abordagem que permite a separação das propriedades ortogonais dos
componentes funcionais de uma forma natural e concisa.
RUP
É um framework iterativo e incremental centrado na arquitetura, planejado por riscos, guiado por
casos de uso e orientado a objetos. É adaptável e configurável, não é obrigado a utilizar tudo que
existe nele. Busca controlar, mitigar ou reduzir os riscos já no início do projeto.

Perspectivas do RUP:
 Dinâmica: temporal ou horizontal mostra as fases ao longo do tempo, interações e marcos.
 Estática: funcional ou vertical mostra as atividades realizadas no processo, componentes,
disciplinas, artefatos e papéis.
 Prática: sugere boas práticas a serem usadas no processo.

Fases são seqüenciais e discretas, mas as iterações podem se sobrepor eventualmente. Pode haver
mais de uma iteração por fase.

Papel: não é uma pessoa, pode ser representado por várias pessoas e uma pessoa pode representar
vários papéis. Existem 32 papéis.

Atividades: estão fortemente relacionadas aos artefatos.

Artefato: existem muito mais artefatos que papeis. Geralmente, são a entrada e/ou saída das
atividades. Também é chamado de produto de trabalho ou work product.

Fluxo de trabalho: uma sequencia de atividades encadeadas e relacionadas a uma disciplina de


projeto.

Princípios chaves ou estratégias recomendadas do RUP:


 Adaptar processos
 Balancear prioridades dos interessados
 Colaboração entre times
 Demonstrar o valor da iteratividade
 Elevar o nível de abstração
 Foco contínuo na qualidade
**** Mnemônico: ABCDEF ****
**** qualidade é responsabilidade de todas as fases e disciplinas ****
6 melhores práticas que forma a perspectiva prática:
 Desenvolvimento iterativo
 Gerenciamento de requisitos
 Uso da arquitetura de componentes
 Modelagem visual
 Contínua verificação da qualidade
 Gerenciamento de mudanças

*** existem 3 perspectivas.


*** existem 9 disciplinas, 6 de engenharia e 3 de apoio/infraestrutura.
*** existem 4 fases.
*** uma passagem pelas 4 fases se chama ciclo de desenvolvimento.
*** uma passagem pelas 9 disciplinas se chama iteração.

Fases do RUP: consiste em um intervalo de tempo entre dois marcos. São discretas e sequencias.
 Iniciação (concepção): deve-se identificar as entidades externas, que irão interagir com o
sistema, e definir essas interações.
 Elaboração: desenvolver um entendimento do domínio do problema, estabelecer um
framework de arquitetura para o sistema.
 Construção: este essencialmente relacionada ao projeto, programação e teste do sistema.
 Transição: está relacionada a transferência do sistema da comunidade de desenvolvimento
para comunidade dos usuários.

Principais marcos do RUP:


Fase Marco
Iniciação Escopo ou objetivos do ciclo de vida.
Elaboração Arquitetura estabilizada do ciclo de vida.
Construção Capacidade operacional inicial
Transição Lançamento (ou Release) do produto.

Principais estratégias para gerenciamento de riscos:


 Prevenção de riscos: reorganiza o projeto para que ele não possa ser afetado.
 Transferência de riscos: reorganiza o projeto para que alguém ou algo assuma o risco.
 Aceitação de riscos: aceita a conviver com o risco como uma contingência, monitorando
seus sintomas.

Riscos diretos x riscos indiretos:


 Diretos: aquele que permite um certo grau de controle.
 Indiretos: não pode ser controlado.

Tipos de riscos:
 Riscos de recursos
 Riscos de negócio
 Riscos técnicos
 Riscos de programação

Disciplinas:
 Modelagem de negócios: entender a estrutura e a dinâmica da organização na qual um
sistema deve ser implantado. Entender os problemas atuais da organização e identificar as
possibilidades de melhoria. Assegurar que os clientes e usuários tenham um entendimento
comum da organização. Derivar os requisitos de sistema necessários para organização.
 Requisitos: estabelecer e manter concordância com os clientes e outros envolvidos.
Oferecer aos desenvolvedores uma compreensão melhor dos requisitos. Definir as fronteiras
do sistema. Fornecer uma base para planejar o conteúdo das iterações. Fornecer uma base
para planejar o custo e o tempo. Definir uma interface de usuário para o sistema.
 Análise e Design: transformar os requisitos em um design do sistema. Desenvolver uma
arquitetura sofisticada para o sistema. Adaptar o design par que corresponda ao ambiente de
implantação.
 Implementação: definir a organização do código. Implementar classes e objetos. Testar os
componentes desenvolvidos como unidades. Integrar os resultados produzidos ao sistema
executável.
 Teste: localizar e documentar defeitos. Avisar de forma geral sobre a qualidade no software.
Validar as suposições feitas nas especificações de design e requisito. Validar as funções.
Verificar se os requisitos foram implementados de forma adequada.
 Implantação: coordenar e gerenciar os testes beta e de aceitação. Desenvolver artefatos de
instalação e materiais de treinamento. Liberar o sistema em produção para usuários finais.
 Gerenciamento de configuração e mudança: identificar e controlar itens de configuração.
Restringir as mudanças nesses itens de configuração. Auditar as mudanças nesses itens de
configuração. Evitar confusões de atualização simultânea.
 Gerenciamento de Projeto: fornecer um framework para gerenciar projetos. Fornecer
diretrizes praticas para planejar, montar a equipe, executar e monitorar projetos. Fornecer
framework de gerenciamento de risco. Não é finalidade cobrir gestão de pessoal, gestão de
orçamento e gestão de contratos.
 Ambiente: oferecer processos e ferramentas que darão suporte a equipe de
desenvolvimento.
Metodologias ágeis
Metodologias ágeis: são mais dinâmicos, interativos e colaborativos, eles se adaptam às
necessidades de um projeto e às suas mudanças no decorrer do desenvolvimento.
 Indivíduos e interação > processos e ferramentas
 Software em funcionamento > documentação abrangente
 Colaboração com cliente > negociação de contratos
 Responder a mudanças > seguir um plano
*** Agilidade é a capacidade de responder adequadamente a mudanças ***
*** Agilidade pode ser aplicada a qualquer processo de software ***
* são recomendadas para pequenas e médias empresas, mas hoje grandes também **

Princípios de desenvolvimento ágil:


 Simplicidade.
 Rápida adaptação a mudanças.
 Quaisquer mudanças são bem vindas.
 Software ou partes entregues frequentemente.
 Cooperação constante entre a área de negócio e a área técnica.
 Excelência técnica.

Metodologias e frameworks ágeis:


 Scrum  Crystal  XP
 TDD  ATDD  BDD
 FDD  DDD  MDD
 DSDM  ASO  Kanban
 LEAN  AUP  Agile Modeling
 OSSO  ScrumBan  BADM

Metodologias ágeis x metodologias tradicionais:


Critério Tradicional Ágil
Planejamento Comumente realizado em detalhe Planejamento de alto nível no inicio
para todo o projeto em fase inicial. e os detalhes são realizados durante
o projeto. Apenas possui detalhes
para a próxima iteração.
Riscos Pode exigir um grande esforço e Prioriza os riscos gerais, mas foca
equipe para atuar com os riscos. principalmente nos ricos dás
próximas iterações, atuando em um
escopo bem reduzido.
Equipe Possui profissionais com papeis Equipe multidisciplinar,
bem definidos, qualificada e multifuncional e auto organizada.
mobilizada conforme o Decide como fazer e atua de forma
planejamento do projeto. Guiada colaborativa.
pelo gerente de projetos.
Tempo de entrega Conforme estabelecido no Conforme o tamanho da iteração e o
planejamento. No caso de planejamento das releases para as
mudanças varia conforme o entregas significativas.
impacto das solicitações.
Documentação Detalhada desde o inicio do Abrangente no início e detalhada
projeto. somente o necessário durante o
projeto conforme os objetivos das
iterações e releases.
Atuação do cliente Nas fases iniciais e nas principais Durante todo o projeto, o cliente faz
validações. parte da equipe.
Discussão e Geralmente em prazos longos Em prazos curtos sempre no final
melhorias através da realização de reuniões das iterações.
após uma grande etapa ou grande
entrega do projeto.
Comandante Gerente de projetos. Equipe do projeto.
Papéis Claros e definidos. Conforme a confiança na equipe e
ambiente colaborativo.
Processo Guiado conforme o planejamento Empírico e guiado ao produto e às
do projeto e nos processos pessoas. Orientado à geração de
estabelecidos no plano. valor e conforme priorização dos
riscos.
Resultado Melhor resultado em projetos com Melhor resultado em projetos cujo
escopo muito bem definido e escopo é dinâmico e construído
orientado a planejamento. durante a execução do projeto.

Scrum: é um framework leve, simples de entender e extremamente difícil de dominar, para


desenvolver e manter produtos complexos e adaptativos.
 Papeis:
o Product owner (PO): responsável pela macro-gestão e pela gestão do produto. É
responsável por maximizar o valor do produto e do trabalho da equipe de
desenvolvimento, sendo o único que pode gerenciar o product backlog. Pode delegar
atividades para o time de desenvolvimento, mas ainda será considerado o
responsável. Responsável por priorizar/ordenar os itens do product backlog e
seleciona os que serão implementados. Responsável por garantir o ROI. Responsável
por expressar claramente os itens do product backlog. Responsável por garantir que
o backlog do produto seja visível, transparente, claro para todos e mostrar o que o
time scrum vai trabalhar. É responsável por garantir que o time de desenvolvimento
entenda os itens do product backlog no nível necessário. É uma pessoa e não um
comitê. Aqueles que quiserem uma alteração nas prioridades do product backlog
devem convencê-lo. O time de desenvolvimento só responde a ele e só ele pode
cancelar uma sprint.
o Scrum máster (SM): responsável pela gestão de pessoas e do processo. Deve
garantir que o scrum seja entendido e aplicado. Ele faz isso para garantir que o time
scrum adere à teoria, práticas e regras do scrum. Ele ajuda aqueles que estão fora do
time scrum a entender quais as suas interações com o time scrum são úteis e quais
não são. Ajuda todos a mudarem estas interações para maximizar o valor criado pelo
time scrum. É responsável por orientar o product owner na criação e ordenação do
product backlog. Responsável por garantir que as regras scrum estejam sendo
cumpridas e seus valores estejam sendo seguidos. Responsável por ajudar a remover
impedimentos que o time enfrente, fazendo isso sem o uso de qualquer autoridade.
Utiliza técnicas de facilitação e coaching para que os membros do time consigam
visualizar os problemas e encontrarem a melhor solução. Durante os eventos é
responsável por fazer com que a reunião flua adequadamente, utilizando técnicas de
facilitação, embora não seja o responsável pela condução. Ajuda a treinar o time de
desenvolvimento em autogerenciamento e interdisciplinaridade. Treina o time de
desenvolvimento em ambientes organizacionais nos quais o scrum não é totalmente
adotado e compreendido. Ensina o time scrum a criar itens do product backlog de
forma clara e concisa. Auxiliar o PO na comunicação clara da visão, objetivo e itens
do product backlog para o time de desenvolvimento.
o Development team (DT): responsável pela micro-gestão e pela criação do produto.
São auto organizadas. Ninguém diz ao time de desenvolvimento como transformar o
product backlog em incrementos de funcionalidades potencialmente utilizáveis. São
multifuncionais, possuindo todas as habilidades necessárias, enquanto equipe para
criar o incremento. O scrum não reconhece títulos para integrantes do time de
desenvolvimento que não seja desenvolvedor, independente do trabalho que está
sendo realizado pela pessoa. Os integrantes podem ter habilidades especializadas,
mas a responsabilidade pertence aos desenvolvedor como um todo. Não contém
subtimes dedicados a domínios específicos de conhecimento, tais como teste ou
análise de negócios. São estruturados e autorizados pela organização para organizar e
gerenciar seu próprio trabalho. Deve ter entre 3 e 9 integrantes.
*** Scrum team = PO+ SM +DT ***
*** SM pode ser do DT ***
*** PO pode ser do DT ***
*** SM nunca pode ser o PO ***

 Eventos: eventos oficiais são time-boxed, possuem duração máxima predefinida, para criar
uma rotina e minimizar a necessidade de reuniões não definidas pelo scrum.
o Sprint planning: proporcional de 8 horas.
 1º parte: a equipe de desenvolvimento tenta prever as funcionalidades que
serão desenvolvidas durante a sprint.
 2º parte: a equipe de desenvolvimente decide como irá transformar os itens
selecionados em um incremento durante a sprint e desenvolve o sprint
backlog. O product owner pode estar presente para clarificar os itens.
o Daily meeting: máximo 15 minutos. Busca criar um plano para as próximas 24
horas e inspecionar o trabalho desde a ultima reunião. Ocorre sempre no mesmo
local, mas não precisa ser em pé. Melhoram a comunicação entre os integrantes. É
uma reunião da equipe de desenvolvimento, mas pode contar com outras partes.
o Sprint review: proporcional a 4 horas. Embora seja utilizada para demonstrar as
novas funcionalidades durante a sprint, seu principal objetivo é o de inspecionar o
que a equipe de desenvolvimento produziu e colher opniões dos presentes para caso
necessário adaptar o plano para a sprint seguinte. É o momento em que o product
owner valida a sprint de acordo com a meta.
o Sprint retrospective: proporcional a 3 horas. É uma chance para o scrum team
inspecionar a si próprio e criar um plano de melhorias para a próxima sprint.
*** reunião de visão não é um evento oficial. O PO deve expor os detalhes do produto a
ser construído. ***
*** release planning meeting também é um evento não oficial, serve para planejar como
será o release. ***
*** sprint tem duas a quatro semanas e inicia imediatamente após a conclusão da sprint
anterior. ***

 Artefatos:
o Product backlog: é uma lista ordenada por valor, risco, prioridade, entre outros de
todos os requisitos/funcionalidades de usuário levantados até o momento e mantidas
pelo product owner, que pode alterá-las a qualquer momento. É um artefato
dinâmico que nunca estará completo e existirá enquanto o produto também existir.
Somente o product owner pode inserir, remover ou reorganizar os itens. Em geral
itens mais importantes ficam no topo e são implementados primeiro. Um item deve
ser pequeno o suficiente para caber em uma sprint. Os itens deve ser detalhados até
atender o conceito de definition of ready (DoR), que significa que o requisito tem
informações suficientes para começar a ser desenvolvido.
o Sprint backlog: é um subconjunto do primeiro transformado em uma lista de tarefas
técnicas e mantidas pela equipe de desenvolvimento, que pode alterá-las a qualquer
momento. Deve contem os itens selecionados para serem implementados durante a
sprint mais o plano para transformá-los em um incremento. Um novo sprint backlog
é criado após cada reunião de planejamento. Torna visível todo o trabalho que o time
de desenvolvimento identifica como necessário para atingir a meta da sprint. O time
de desenvolvimento monitora o total de trabalho restante pelo menos a cada reunião
diária.
o Product increment: ao final de cada sprint a equipe de desenvolvimento entrega um
incremento do produto. O incremento deve ser potencialmente entregável, o cliente
pode optar por colocar de imediato em produção ou não. A equipe deve produzir um
código tenha qualidade , definition of Done (DoD) ou definição de pronto.
*** existem outros artefatos que são opcionais e podem ser adicionados ***
 Fluxo:
o Sprint: é proibido realizar mudanças que afetem a sua meta.
 Compostas por:
 Uma reunião de planejamento da sprint.
 Reuniões diárias.
 Uma revisão da sprint.
 Retrospectiva da sprint.
*** sprint tem duração de até um mês ***
*** com o sprint backlog, definide-se a meta da sprint. ***
 Ambiente: é usado em ambientes complexos, onde os requisitos e as prioridades mudam
constantemente.
o Simples: melhores práticas.
o Complicado: boas práticas.
o Complexo: práticas emergentes.
o Caótico: práticas novas.
 Pilares fundamentais (TIA):
o Transparência: aspectos significativos devem estar visíveis aos responsáveis pelos
resultados. Deve haver dentro e fora da equipe, permitindo a qualquer pessoa
compreender o que realmente está ocorrendo. O objetivo é encarar as dificuldades de
forma honesta e chegar a um consenso sobre como estes podem ser ultrapassados.
o Inspeção: também chamado de verificação, os usuários devem freqüentemente
inspecionar os artefatos e o progresso para detectar indesejáveis variações, em busca
de resolver o problema. A idéia é identificar rapidamente qualquer desvio sobre a
meta que deve ser atingida.
o Adaptação: se um inspetor determina que um ou mais aspectos de um processo
desviou para fora dos limites aceitáveis o processo ou o material sendo produzido
deve ser ajustado. O ajuste deve ser o mais breve possível para minimizar mais
desvios. Como mudanças sempre ocorrem, recomenda-se a adaptação em vez de
evitá-las.
 DoR x DoD:
o DoR: é um checklist de critérios acordados para que a equipe de desenvolvimento
possa aceitar um requisito.
o DoD: é um acordo formal que define claramente quais são os passos mínimos para a
conclusão de um item ou funcionalidade potencialmente entregável. É um checklist
de critérios acordados para que o product owner possa aceitar uma funcionalidade.
 Ciclo de vida:
o Pré-planejamento (pré-game phase)
o Desenvolvimento (game phase)
o Pós-planejamento (post-game phase)
 Artefato gráfica burndown: torna visível aevolução diária da equipe de desenvolvimento,
na medida em que mostra a comparação entre o trabalho estimado inicialmente com a
quantidade de trabalho restante estimada. As unidades são de esforço em horas.
 Técnica planning poker: consiste em obter uma estimativa por meio de um jogo de cartas.
Deve permitir que todos os membros da equipe de desenvolvimento participem colocando
sua visão de complexidade. Cada integrante tem a sua disposição 13 cartas com números
que serão atribuídas a um cartão.

Extreme programming (XP): recomenda-se que as boas práticas sejam levadas ao extremo. É uma
metodologia de desenvolvimento de software para equipes pequenas, coesas e multidisciplinares
cujos projetos possuem requisitos vagos e em constante mudança. Código fonte é a melhor
documentação. Codificação é a atividade principal. Requisitos expressos como cenários. Os
programadores trabalham em pares e desenvolvem testes para cada tarefa antes da escrita do
código. A equipe de desenvolvimento divide cada cenário em tarefas. Cada tarefa representa uma
característica discreta e um teste unitário pode então ser projetado para ela. Uma história de usuário
representa uma pequena parte da funcionalidade a ser construída, não se trata de uma especificação
completa da funcionalidade. Os detalhes das histórias de usuários são capturados nos teste
automatizados de aceitação que são posteriormente usados para validar a implementação da
história. As vezes uma história precisa ser decomposta em partes menores para caber em uma
iteração. As histórias que não puderem ser estimadas deverão ser reescritas.
 Processo para desenvolver incremento:
o Planejamento incremental:
o Pequenos releases:
o Projeto simples: código simples não é código fácil.
o Desenvolvimento test-first: primeiro escreve-se o teste e depois a implementação.
o Refactoring:
o Programação em pares: utilizam o mesmo mouse, teclado e monitor.
o Propriedade coletiva: não se formam ilhas de conhecimento.
o Integração contínua: depois da integração todos os testes devem ser realizados.
o Ritmo sustentável: trabalhar por até 40 horas semanais.
o Metáforas: equipe se comunica por meio de metáforas.
o Cliente on-site: um representante do usuário final deve estar disponível em tempo
integral.
o Reuniões em pé:
o Time coeso: pessoas engajadas e multidisciplinares.
o Jogo de planejamento:
 Atividades principais:
o Planejamento
o Projeto
o Codificação
o teste
 Valores fundamentais:
o Comunicação o Coragem
o Simplicidade o Respeito
o Feedback
*** COR SIM COMFERE ***
 Princípios básicos:
o Feedback rápido o Mudanças incrementais
o Abraçar mudanças o Trabalho de qualidade
o Presumir simplicidade
*** as versões de software podem ser compiladas várias vezes por dia e os incrementos são
entregue para os clientes aproximadamente a cada duas semanas. ***
Test-driven Development (TDD): é uma metodologia ágil de desenvolvimento de software que se
baseia na repetição de um ciclo de desenvolvimento curto, focado em testes unitários. Casos de
teste são escritos antes mesmo da própria funcionalidade. O primeiro teste quando executado ele
deve falhar por que a funcionalidade não foi criada. Então adicionamos a funcionalidade para que
ele passe no teste e testa-se denovo. Sempre que uma nova funcionalidade for criada todos os testes
são realizados de novo. Em geral, utilizam-se testes unitários, teste de integração ou teste de
aceitação. É uma abordagem de desenvolvimento e não de testes.

Coesão: é a divisão de responsabilidade.


Acoplamento: é a dependência entre componentes.
*** uma boa arquitetura deve ter componentes de projeto com baixo acoplamento e alta coesão. ***
Engenharia de requisitos
Requisito: uma propriedade ou um comportamento que um produto ou serviço deve atender. É a condição
que deve ser satisfeita para se alcançar um objetivo ou qualidade do sistema.

Classificação dos requisitos quanto ao nível de abstração:


 Requisitos de usuário: tem alto nível de abstração, feitos para serem lidos por pessoas leigas em
linguagem natural e diagramas, podem ser funcionais ou não funcionais.
 Requisitos de sistema: descrições detalhadas, restrições de sistemas, têm baixo nível de
abstração, podem ser funcionais ou não funcionais.

Classificação dos requisitos quanto à qualidade:


 Requisitos normais: refletem objetivos e metas estabelecidas. Se estiverem presentes o cliente
fica satisfeito.
 Requisitos esperados: estão implícitos no produto ou sistema e podem ser tão fundamentais que
o cliente não os declara explicitamente. Sua ausência será causa de grande insatisfação.
 Requisitos fascinantes: vão além da expectativa do cliente e demonstram ser muito satisfatório.

Classificação dos requisitos quanto à evolução e manutenção:


 Requisitos permanentes: requisitos estáveis estão ligados diretamente com a atividade principal
da organização. Mudam mais lentamente que os voláteis. Em geral, são derivados do modelo de
domínio.
 Requisitos voláteis: requisitos instáveis, são específicos para a instanciação de um sistema, são
mais propensos a mudança, se modificam quando o sistema esta em desenvolvimento ou em uso.
o Mutáveis: são os requisitos que se modificam em função de mudanças no ambiente no
qual o sistema opera. Ex: sistema que calcula taxas que se modifica conforme as leis
fiscais se atualizam.
o Emergentes: são os requisitos que não podem ser completamente definidos quando o
sistema é especificado e emergem à medida que a compreensão do cliente sobre o sistema
se desenvolve. Só aparecerão durante o desenvolvimento.
o Conseqüentes: são requisitos baseados em suposições de como o sistema será utilizado,
isto é, são resultado da introdução do sistema no ambiente do usuário. O usuário percebe
as necessidades enquanto utiliza o sistema. Esses requisitos são conseqüência do uso.
o De compatibilidade: são requisitos que dependem de outro equipamento, processo,
componente ou elemento. Conforme outros elementos mudam, esses requisitos também
mudam. Eles são menos comuns.

Classificação dos requisitos quanto à funcionalidade:


 Requisitos funcionais: são declarações de serviços que o sistema deve ter.
 Requisitos não funcionais: são restrições nos serviços ou funções oferecidas pelo sistema.
o De produto: especificam ou restringem o comportamento do software.
o Organizacionais: são os requisitos gerais do sistema derivados das políticas e
procedimentos da organização do cliente e do desenvolvedor.
o Externos: abrange todos os requisitos que derivam de fatores externos ao sistema e seu
processo de desenvolvimento.
 Requisitos de domínio: são requisitos derivados do domínio da aplicação e refletem
características de sua área de negócio.

Classificação dos requisitos quanto à origem:


 Requisitos de produto: especificam o comportamento do produto. Ex: taxa de falhas, velocidade,
memória confiabilidade, portabilidade, usabilidade, etc.
 Requisitos organizacionais: são derivados de políticas e procedimentos da organização. Ex:
padrões de processo, linguagem de programação, requisitos de entrega e documentação.
 Requisitos externos: abrange todos os requisitos derivados de fatores externos ao sistema e
desenvolvimento. Ex: interoperabilidade, requisitos legais, requisitos éticos.

Requisitos Exemplos
Requisitos de confiabilidade Sistema não deve ficar fora do ar por mais de 5 segundos durante o
dia.
Requisitos de proteção Sistema não deve permitir que usuários alterem senhas de acesso
que eles não criarem.
Requisitos de desempenho Sistema deve ser capaz de processar 800 requisições por segundo.
Requisitos de espaço Sistema deve ocupar no máximo 80mb de memória interna do
dispositivo.
Requisitos de usabilidade Os usuários deverão operar todas as funcionalidades do sistema
após 2 horas de treinamento.
Requisitos de segurança Sistema não deve permitir a ativação simultânea de mais de 3 sinais
de alarme.
Requisitos éticos Sistema não apresentará aos usuários quaisquer dados de natureza
confidencial de outrem.
Requisitos de implementação A interface de usuário deve ser implementada em HTML e não deve
utilizar applets Java.

Requisito x Regra de negócio:


 Requisito: tratam do funcionamento de um sistema.
 Regra de negócio: trata do funcionamento de um negócio, sendo independente de um sistema.

Engenharia de requisitos: uma abordagem sistemática para a formulação, análise, documentação e


manutenção dos requisitos de um sistema. É a fase mais critica do desenvolvimento de um sistema. Todos
os requisitos se modificam, pois pessoas envolvidas desenvolvem uma compreensão maior do que
desejam que o software faça.

Fases

 Concepção: Trata-se da concepção inicial do software e busca entender o problema, quem são os
envolvidos, a natureza da solução e iniciar o processo de comunicação entre clientes e
colaboradores.
 Levantamento: etapa crítica utiliza uma abordagem organizada para descobrir o que o cliente
deseja em seu sistema.
 Elaboração: por vezes chamada Análise, informações obtidas do cliente durante a concepção e
levantamento são expandidas e refinadas em um modelo, definindo o domínio do problema.
 Negociação: tem por objetivo chegar a um consenso sobre os conflitos entre clientes e usuários,
por intermédio de um processo de negociação. Os requisitos são avaliados junto ao cliente e
podem se combinar, excluir ou até mesmo inserir novos requisitos.
 Especificação: por vezes chamada Documentação, produto final do engenheiro de requisitos,
pode ser um documento escrito, um modelo gráfico, cenários de uso, protótipos, etc. Trata-se da
apresentação formal dos dados obtidos até o momento de modo que possa guiar o
desenvolvimento futuro do software.
o Documentos gerados para sistemas complexos:
 Definição de sistema: registra os requisitos do sistema. Define os requisitos de
sistema de alto nível a partir da perspectiva de domínio. Seus leitores incluem
representantes dos usuários, portanto seu conteúdo deve ser expresso em termos do
domínio. Lista os requisitos, informações sobre objetivos gerais do sistema,
ambiente de destino e uma declaração de restrições, suposições e requisitos não
funcionais.
 Requisitos de sistema: desenvolvedores de sistemas com software substanciais e
componentes que não são software geralmente separam a descrição dos requisitos
do sistema da descrição dos requisitos de software. Então, os requisitos de sistema
são especificados e os requisitos de software são derivados deles.
 Requisitos de software: estabelece a base para o acordo entre clientes e
contratados ou fornecedores sobre o que o produto de software deve fazer, bem
como o que não se espera que ele faça.
o Documentos gerados para sistemas simples:
 Requisitos de software
 Validação: os produtos de trabalho resultantes da engenharia de requisitos são avaliados quanto a
sua qualidade por todos os envolvidos (clientes, colaboradores e usuários). Buscam-se erros de
interpretação, ambiguidades e omissões.
o Tipos de verificação:
 De validade: um usuário pode pensar que é necessário um sistema para executar
determinadas funções. No entanto, maior reflexão e análise mais aprofundada
podem identificar funções necessárias, adicionais ou diferentes.
 De consistência: requisitos no documento não devem entrar em conflito. Não deve
haver restrições contraditórias ou descrições diferentes para mesma função.
 De realismo: os requisitos devem ser verificados para assegurar que realmente
podem ser implementados. Devem considerar o orçamento e o cronograma para
desenvolvimento.
 De completude: o documento de requisitos deve incluir requisitos que definam
todas as funções e restrições pretendidas pelo usuário do sistema.
 Verificabilidade: os requisitos do sistema devem ser passiveis de verificação.
Você deve ser capaz de escrever um conjunto de testes que demonstrem que o
sistema atende a cada requisito especificado.
 Gestão: conjunto de atividades que auxiliam a equipe de projeto a identificar, controlar e rastrear
requisitos e mudanças nos requisitos a qualquer momento. Para projetos de grande porte, é uma
fase essencial na medida em que mudanças em um requisito podem afetar diversos outros
requisitos

Fases do Pressman:
CONsegui LEVANTAr ELA, NEm ESPErei VALdívia GESTicular
Concepção, levantamento, elaboração, negociação, especificação, validação, gestão.

Fases do Sommerville:
ESTão VIABILIzando ELIANA ESPECIalmente no VAsco da Gama
Estudo de viabilidade, elicitação e análise de requisitos, especificação, validação, gestão.
Sommerville Pressman
Estudo de viabilidade Concepção
Elicitação de requisitos Levantamento
 Obtenção de requisitos Elaboração
 Classificação de requisitos Negociação
 Priorização e negociação Especificação
 Documentação de requisitos
Especificação
Validação Validação
Gestão Gestão

Técnicas de elicitação de requisitos:


 Entrevistas: formais ou informais, requisitos são derivados das respostas, podem ser abertas ou
fechadas e úteis para obter um entendimento geral sobre o que os stakeholders fazem.
 Etnografia: técnica de observação utilizada para compreender os requisitos organizacionais e
sociais. Descobre requisitos implícitos. Em geral, utilizada em conjunto com outras técnicas.
 Cenários: Elas podem compreender e criticar um cenário de como interagiriam com um sistema
de software. Os engenheiros de requisitos podem usar as informações obtidas nessa discussão para
elaborar os requisitos reais do sistema de software. Os cenários podem ser particularmente úteis
para adicionar detalhes a um esboço da descrição de requisitos. Os cenários podem ser escritos na
forma de textos, complementados por diagramas, imagens de computador etc. Como alternativa,
pode ser adotada uma abordagem mais estruturada, como cenários de eventos ou casos de uso.
 Questionários: formulários distribuídos aos stakeholders com questões pré-definidas. Torna-se
útil quando a quantidade de stakeholders é muito grande. Essa técnica é interessante quando temos
uma grande quantidade de pessoas para extrair as mesmas informações.
 Workshop: reunião estruturada e intensiva entre analistas e usuários com o intuito de obter um
conjunto de requisitos bem definido. Possui um facilitador neutro. Permite utilizar outras técnicas
em conjunto. Realizado por convocação por dia e horário.
 Brainstorming: ocorre em ambiente informal por cerca de 15 minutos. Toda idéia deve ser levada
em consideração, sendo proibida de sofrer critica. Busca-se explorar a potencialidade criativa de
um grupo, um facilitador organiza e prioriza os resultados.
 Prototipação: Técnica de elicitação, independente de tecnologia, utilizada no estágio inicial do
projeto, ajudando stakeholders a desenvolverem uma forte noção sobre a aplicação a ser
implementada. Ela fornece também alto nível de satisfação dos usuários devido a sensação de
segurança ao ver algo próximo do real.
 Histórias de usuários: uma história contada na linguagem do usuário final capaz de capturar
aquilo que o usuário de fato necessita fazer para realizar seu trabalho. Deve ser concisa o
suficiente para caber em um post-it.
 Join application design: Similar à técnica de Workshop de Requisitos e registrada pela IBM, ela
busca reunir os usuários e desenvolvedores em um workshop estruturado para levantar requisitos e
promover a tomada de decisões por meio de dinâmicas de grupo, técnicas visuais, processos
racionais e documentação. É bastante interativa e promove a participação ativa dos envolvidos. O
processo consiste em três fases principais: customização, sessões e agrupamento.
 Leitura de documentos: Coleta informações que são geralmente mais difíceis de obter por meio
de entrevistas, questionários e observações sociais. Estudo e reutilização de documentação de
diferentes naturezas, para a identificação de requisitos a serem implementados no sistema que se
está modelando, podem ser utilizados. Uma grande variedade de documentação pode ser analisada
incluindo estrutura organizacional da empresa, padrões de mercado, leis, manuais de usuário,
relatório de pesquisas de mercado, glossário de termos de negócio, etc.
 Reuso de requisitos: Estudo e reutilização de especificações e glossários referentes a projetos de
sistemas legados ou sistemas de mesma família ou com funcionalidades de negócio similares.
Assim, eles têm chances maiores de serem compreendidos pelos stakeholders. Além disso, reduz
riscos, visto que requisitos reutilizados têm uma chance maior de serem compreendidos pelos
stakeholders.
 Participação ativa de usuários: Técnica que permite a incorporação dos usuários ao grupo de
engenharia de requisitos. Os usuários precisam aprender as linguagens de modelagem utilizadas
para ser capaz de ler as descrições e criticá-las.
 Encenação: É uma abordagem que implica usar uma ferramenta para ilustrar para os usuários
como o sistema se ajustará à organização e também indicar como ele se comportará. Um
facilitador mostra uma encenação para o grupo e este último faz comentários. Ajuda a restringir
requisitos, estimula soluções mais criativas
 Interpretação de papeis: É uma abordagem que atribui a cada membro do grupo um papel de
interesse para o sistema. O grupo inspecionará então como o sistema é usado. Ao longo do
caminho, haverá discussões sobre quem é responsável por o quê.
 Grupo focal: Trata-se de um grupo de discussão informal e de tamanho reduzido (até 12 pessoas),
com o propósito de obter informação qualitativa em profundidade. pessoas são convidadas para
participar da discussão sobre determinado assunto. Ele é muito eficiente para esclarecer questões
complexas no desenvolvimento de projetos. No entanto, exige facilitador/moderador com
experiência para conduzir o grupo. Além disso, ele não garante total anonimato – que é relevante
em algumas ocasiões.
 Análise de protocolos: Essa técnica consiste em analisar o trabalho de determinada pessoa por
meio de verbalização, estabelecendo a racionalidade utilizada na execução de tarefas. É feita por
meio da pergunta “O que você faria se...?” e, assim, possibilita elicitar fatos não facilmente
observáveis e permite melhor entendimento dos fatos.
 Pontos de vista: Essa técnica considera as perspectivas de diversas partes interessadas sobre os
requisitos do sistema de software. Ela reconhece os pontos de vista dos stakeholders e fornece um
framework para se tentar descobrir conflitos nos requisitos propostos por cada um deles.

Verificação x Validação:
 Verificação: tem o objetivo de descobrir se os requisitos são claros, precisos, completos e
consistentes, e tem por objetivo analisar se os modelos construídos estão de acordo com os
requisitos definidos. Esta sendo construído de forma correta.
 Validação: se ocupa de mostrar que os requisitos realmente definem o sistema que o cliente
deseja. Esta sendo feito aquilo que o cliente deseja.

Verificações nos requisitos que devem ser realizadas:


 Verificações de validade  Verificações de realismo
 Verificações de consistência  Facilidade de verificação
 Verificações de completeza

Gerenciamento de requisitos: envolve todas as fases, é o processo responsável por compreender,


acompanhar e controlar as mudanças dos requisitos de sistema, identificando inconsistências. Quando
mudanças são propostas deve rastrear seu impacto em outros requisitos e no projeto do sistema.
Rastreabilidade é a propriedade de uma especificação de requisitos que reflete a facilidade de encontrar os
requisitos relacionados.
UML
Uml: é uma linguagem gráfica para especificar, visualizar, construir e documentar artefatos
primariamente de um sistema de software. Ela não esta limitada a modelagem de software. Ela é
independente de processos, ferramentas, linguagem de programação e outros. Nela existe a
definição de uma linguagem formal utilizada para especificar as restrições sobre os elementos de
um modelo, chama-se OCL.
 Especificações:
o Infraestrutura da UML: contém o core da arquitetura, perfis e estereótipos.
o Superestrutura da UML: contém os elementos de modelagem estáticos e
dinâmicos.
o Object constraint language (OCL): contém a linguagem forma usada para
descrever expressões em modelos UML.
o Intercâmbio: contém formatos de intercâmbio de diagramas.
 Mecanismos de uso geral muito importantes:
o Estereótipo: mecanismo utilizado para estender o significado de determinado
elemento em um diagrama. Podem ser classificados como estereótipos textuais ou
gráficos. Ex: << interface >>.
o Notas explicativas: mecanismo utilizado para definir informação que comenta ou
esclarece alguma parte de um diagrama. Podem ser descritas em texto livre ou
corresponder uma expressão formal utilizando a linguagem de restrição ocl. São
representadas por um retângulo com uma orelinha.
o Tagged values: mecanismo utilizado para predefinir propriedades para determinados
elementos. A partir da uml 2.0 só é possível utilizá-las junto com esteriótipos.
o Restrições: mecanismo utilizado para especificar restrições sobre um ou mais
valores de um ou mais elementos de um modelo.
o Pacotes: mecanismo utilizado para agrupar elementos semanticamente relacionados.

*** todo elemento esta associado a alguma semântica, isso quer dizer que cada elemento gráfico
possui um significado bem definido. ***
*** restrições permitem estender ou alterar a semântica natural de um elemento. Elas podem ser
tanto formal quanto informal. ***

Visões ou perspectivas principais:


 Lógica (de projeto): é a visão da arquitetura do sistema sob o ponto de vista dos usuários
finais, apresentando os requisitos funcionais do software que suportam a arquitetura e
fornecem serviços. Os principais diagramas são: classe, objetos e pacotes.
 De desenvolvimento (ou implementação): é a visão da arquitetura do sistema sob o ponto
de vista do programador, apresentando a organização estática dos módulos que forma o
software. Principais diagramas utilizados: componentes.
 De processo: é a visão da arquitetura do sistema sob o ponto de vista do integrador,
apresentando requisitos não funcionais. Principais diagramas utilizados: seqüência, estrutura
composta, maquina de estados e atividades.
 Física (ou implantação): é a visão da arquitetura do sistema sob o ponto de vista do
engenheiro de sistemas, apresentando a topologia ou distribuição física dos componentes.
Principais diagramas: implantação e componentes.
 De casos de uso (cenários): é a visão da arquitetura do sistema sob o ponto de vista de
todos os usuários das outras visões e avaliadores, apresentando a consistência e validade do
sistema. Principais diagramas: casos de uso.
Diagramas: são 14 diagramas UML.

 Estruturais: representam aspectos estáticos do sistema sob diversas visões. Esses


diagramas apresentam a estrutura do sistema inalterado há qualquer momento por não
levarem em consideração o tempo. São eles: componente, classes, implantação, perfil,
objetos, estrutura composta e pacotes.
 Comportamentais: representam aspectos dinâmicos do sistema como um conjunto de
mudanças. Esses diagramas apresentam como os processos e funcionalidades do programa
se relacionam. São eles: máquinas de estado, casos de uso, atividade, sequência,
comunicação, interação geral e tempo.
 De interação: são diagramas comportamentais que consideram o relacionamento dinâmico
e colaborativo entre os objetos do sistema e suas trocas de informações. Enfatizam o
controle de fluxo e dados entre as coisas do sistema que estão sendo modeladas. São eles:
sequência, comunicação, interação geral e tempo.
Diagrama de classes: descreve as classes e interfaces presentes no sistema, suas características,
restrições e os vários tipos de relacionamentos estáticos entre seus objetos. Representam-se também
as propriedades e operações de uma classe, assim como as restrições que se aplicam à maneira
como os objetos estão conectados. O nome de uma classe pode ser apenas seu nome ou nome após
o pacote ao qual pertence separado por duplo dois-pontos.

*** um atributo estático deve ter seu nome sublinhado. ***


*** uma operação abstrata deve ter seu nome escrito em itálico. ***
*** uma operação estática deve ter seu nome sublinhado. ***

 Relacionamentos:
o De dependência: é uma relação semântica entre dois ou mais elementos que ocorre
se mudanças na definição de um elemento (independente) causarem mudanças ao
outro elemento (dependente). É quando a classe cliente é dependente de um serviço
da classe fornecedora. Pode ocorrer entre duas classes ou uma classe e uma interface.
o De generalização/especialização: indica que a subclasse é uma especialização da
superclasse ou que a superclasse é uma generalização da subclasse. Qualquer
instância da subclasse é também uma instância da superclasse.
o De realização: relacionamento entre dois elementos em que um elemento realiza
(implementa/executa) o comportamento que o outro especifica.
o De associação: relacionamento estrutural entre objetos e especifica os objetos de
uma classe que estão ligados a objetos de outra classe.
 Simples: mais forte que o relacionamento de dependência indica que uma
instância de um elemento esta ligada à instância de outro elemento.
Representado por uma linha sólida com ou sem setas de navegabilidade
unidirecionais ou bidirecionais. Pode haver nomes para a associação e
indicação de multiplicidade.
 Qualificada: similar a associação simples, contudo possui um qualificador,
que é um atributo de elemento-alvo capaz de identificar uma instância entre
as demais. Ocorre em associações um-para-muitos ou muitos-para-muitos em
que se deseja encontrar um elemento específico dada uma chave. O retângulo
fica ao lado da classe de cardinalidade 1 contendo o qualificador.
 Agregação: é um tipo de associação, porém mais forte, em que o todo esta
relacionado às suas partes de forma independente. As partes tem existência
própria. Diamante vazio na classe agregadora.
 Composição: é um tipo de agregação, porém mais forte, em que o
todo esta relacionado às partes de forma dependente. As partes não
tem existência própria. Diamante cheio na extremidade referente ao
todo.

*** Associação: mostra que os passageiros e o avião possuem uma ligação. ***
*** Dependência: mostra que o avião depende dos passageiros. ***
*** Associação reflexiva: mostra que a equipe do avião se relaciona entre si. ***
*** Multiplicidade: mostra que o avião possui zero ou mais passageiros. ***
*** Agregação: mostra que uma biblioteca tem um ou mais livros (independentes). ***
*** Composição: mostra que uma biblioteca tem livros (necessariamente). ***
*** Herança: mostra que uma conta bancária é filha de uma conta fixa. ***
*** Realização: setup da impressora implementa funcionalidades da impressora.***

Diagrama de objetos: é uma variação do diagrama de classes, personaliza-se cada instância com
seus valores. Representa uma fotografia estática do sistema em um dado momento de execução.
Pode ser usado para mostrar um exemplo de configuração de um objeto.Os elementos são
especificações de instâncias, em vez de instâncias verdadeiras. Útil para ilustrar relacionamentos
complexos.

Diagrama de componentes: representa o sistema sob uma perspectiva funcional, expondo a


organização de seus módulos e as relações entre seus componentes por meio de interfaces. Os
componentes podem ser tabelas, documentos, etc. Freqüentemente, vem com estereótipos para
definir seus tipos e relacionamentos. Deve ser utilizado quando tiver dividindo o sistema em
componentes e quiser representar seus relacionamentos por intermédio de interfaces ou quando
quiser mostrar a decomposição de componentes.
 Os principais estereótipos:
o Arquivo
o Tabela:
o Biblioteca
o Documento
o Executável:

Diagrama de pacotes: representa os pacotes e suas dependências. Pacotes ilustram a arquitetura de


um sistema como agrupamento de classes em um alto nível de abstração. São úteis em diagramas de
grande porte, para obter uma visão de dependências entre os elementos. Representa um mecanismo
de agrupamento em tempo de compilação.

Diagrama de implantação (instalação): apresenta layout físico de um sistema, revelando quais


partes do software são executadas em quais partes do hardware. Os itens principais são nós
conectados por caminhos de comunicação. Um nó é algo que pode conter algum software. Os nós
contem artefatos que são manifestações físicas do software, normalmente, arquivos. A listagem de
um artefato dentro de um nó mostra que ele esta instalado nesse nó do sistema. Você pode mostrar
artefatos como caixas de classe ou listando o nome dentro de um nó. Muitas vezes, os artefatos são
a implementação de um componente. Os caminhos de comunicação podem ser rotulados com
informação sobre protocolos de comunicação utilizados. Os nós e artefatos são responsabilidade de
equipe de implantação. Este diagrama é útil para mostrar o que é instalado e onde.
Diagrama de perfil: um perfil trata-se de uma UML com um conjunto de estereótipos
predefinidos, valores atribuídos, restrições e classes de base. O diagrama de perfil permite
representar esses novos elementos, operando no nível de metamodelos.

Diagrama de estrutura composta: utilizado para modelar colaborações internas de classes,


interfaces e componentes para especificar uma funcionalidade. Este diagrama fornece meio de
definir a estrutura de um elemento e de focalizá-lo no detalhe, na construção e em relacionamentos
internos. Este diagrama entrou na UML 2.0, mas já existiam métodos antigos que tinham idéias
semelhantes.

Diagrama de casos de uso: são uma técnica para captar os requisitos funcionais de um sistema.
Descreve as interações do usuário com o sistema. Cenário é uma instância de caso de uso, uma
seqüência de passos que descreve uma interação entre o usuário e o sistema. Descreve um conjunto
de funcionalidades do sistema e interações com elementos externos e entre si. Os atores são os
elementos externos que interagem com o sistema e são representados por um boneco stickman.
Um ator pode ser um humano, uma máquina ou outro sistema cuja interação executa uma ação
significativa.
 Caso de uso concreto: é iniciado por um ator e constitui um fluxo completo de eventos.
Quando é iniciado, uma instância do caso de uso é criada. Também exibe o comportamento
especificado por seus casos de uso abstratos.
 Caso de uso abstrato: jamais é instanciado diretamente, são incluídos, estendidos ou
generalizados por outros casos de uso e representa-se com o nome em itálico.
 Caso de uso primário: representa os objetivos dos atores. Representam os processos da
empresa que estão sendo automatizados.
 Caso de uso secundário: não traz beneficio direto para os atores, mas é necessário para que
o sistema funcione adequadamente.

 Relacionamento de comunicação: também chamado de relacionamento de associação, o


ator se comunica com o sistema por meio do envio e recebimento de mensagens.

 Relacionamento de inclusão: utilizado quando um mesmo comportamento se repete em


mais de um caso de uso. É um relacionamento obrigatório. Quando o caso de uso A inclui o
caso de uso B, significa que sempre que o caso de uso A for executado o caso de uso B
também será executado. A direção do relacionamento é do caso de uso que está incluído
para o que esta incluído.

 Relacionamento de extensão: utilizado quando se deseja modelar um relacionamento


alternativo. É um relacionamento opcional. Quando o caso de uso A estende o caso de uso
B, significa que quando o caso de uso A for executado o caso de uso B poderá ser executado
também. A direção do relacionamento é do caso de uso extensor para o caso de uso
estendido.
 Relacionamento de herança: é um relacionamento entre atores, utilizado quando o ator
filho é uma especificação do ator genérico. Útil para definir sobreposição de papéis entre
atores. Tem um triangulo no ator genérico.

Diagrama de atividades: descreve a lógica de procedimento, processo de negócio e fluxos de


trabalho. Desempenham papel semelhante a fluxogramas. Ele não se preocupa com interações entre
objetos, mas entre processos de negócio de mais alto nível. Os estados mudam quando uma ação é
executada e podem ser representadas por swimlanes. As swimlanes agrupa as atividades e as
organizam de acordo com suas respectivas responsabilidades, com o auxilio de ações, bifurcações,
fluxos e ramificações. É uma execelente ferramenta para modelagem de fluxos de trabalho e de
processos.
 Ramificações: especificam caminhos alternativos baseados em expressões booleanas,
representada por um diamante.
 Bifurcação: é a divisão de um mesmo fluxo de controle em dois ou mais fluxos
concorrentes.
 União: é a sincronização de dois ou mais fluxos de controle concorrentes.

Diagrama de máquina de estados: conhecido como diagrama de transições de estado, apresenta


diversos estados possíveis de um objeto no decorrer da execução de processos de um sistema. Um
objeto pode passar de um estado inicial para um estado final por meio de uma transição quando
ocorre algum evento ou estimulo interno ou externo ao sistema. Ele não mostra a interação entre
objetos, ele mostra estados possíveis de um objeto específico. Permite representar o ciclo de vida de
objetos e como eles são afetados por eventos como erros, mensagens e condições. São muito bons
para descrever um comportamento que envolva vários objetos em colaboração. Recomenda-se usar
apenas nas classes que exibam comportamento interessante para ajudar a entender o problema.

Diagrama de sequência: é uma diagrama de interação que captura o comportamento de um único


cenário, mostrando vários exemplos de objetos e mensagens que são trocadas dentro de um caso de
uso. Ele modela a interação entre objetos, permitindo a visualização da execução. Ele possui eixo
horizontal e vertical. O horizontal representa os objetos envolvidos e o vertical representa o tempo
em que a ação ocorre e é representado por uma linha tracejada (linha de vida). Mostra a sequencia
temporal de mensagens trocadas. Eles são bons para mostrar a colaboração entre os objetos, mas
não são tão bons para uma definição precisa do comportamento.

Diagrama de comunicação: é um diagrama de interação semelhante ao diagrama de seqüência,


mas com ênfase na ordem estrutural e, não temporal. Em versões anteriores era conhecido como
diagrama de colaboração. Ele possui números que identificam a seqüência. Geralmente, utiliza-se o
diagrama de seqüência para cenários mais complexos e o diagrama de comunicação para cenários
mais simples. Mostra as mensagens trocadas entre objetos. Eles são bons quando se quer salientar
os vínculos.

Diagrama de tempo: é um diagrama de interação e descreve o comportamento dos objetos no


decorrer do tempo e a duração na qual eles permanecem em determinado estado. Há um foco no
tempo e na transição de estados. Eles são conhecidos dos engenheiros de hardware há um longo
tempo. É tipicamente utilizado para demonstrar a mudança no estado de um objeto no tempo em
resposta a eventos externos. Úteis para mostrar restrições de temporização entre mudanças de
estado em diferentes objetos.

Diagrama de interação geral: é um diagrama de interação que mistura o diagrama de atividades e


o diagrama de seqüência. Fornece uma visão geral do controle de fluxo entre objetos e engloba
diversos tipos de diagramas de interação para demonstrar um processo geral. Mostra a troca de
mensagens entre objetos e o estado de atividades. Tem o objetivo de dar uma visão geral dos
diversos cenários de um caso de uso. Pode-se considerar como diagramas de atividades com nos
quais as atividades são substituídas por pequenos diagramas de seqüência ou um diagrama de
seqüência fragmentado, com a notação de diagrama de atividades usada para mostrar o fluxo de
controle.
Paradigma orientado a objetos
Princípios básicos ou pilares fundamentais:
 Encapsulamento
 Herança
 Composição
 Polimorfismo
*** alguns autores afirma que são todos simplesmente a aplicação da abstração. ***

Classes e objetos: objetos são coisas e classes são um agrupamento de coisas.


 Classe: é um modelo a partir do qual objetos são construídos. É como um projeto, formato
ou descrição geral de um objeto.
 Objeto: são instâncias de classes.
o Componentes:
 Identidade
 Estado (propriedades)
 Comportamento (operações)

Atributos: consiste em uma informação de estado, para o qual cada objeto de uma classe tem seu
próprio valor. Há dois tipos:
 Atributos de classe: similar a uma variável global, cujo valor é comum a todos os objetos
membros de uma mesma classe.
 Atributos de instância: variável cujo valor é especifico ao objeto e, não, à classe.

Métodos: similares a procedimentos e funções, consistem em descrições das operações que um


objeto executa quando recebe uma mensagem.
 Tipos de métodos:
 Construtor: são métodos especiais, que são chamados automaticamente quando
instâncias são criadas. Tem o mesmo nome da classe e seu objetivo é garantir que o
objeto seja instanciado corretamente.
 De classe: similar a um método global, é o método que realiza operações genéricas.
 De instância: realiza operações especificas para um objeto.
 Associação entre classe e método é chamado de ligação (binding). Tipos de ligações:
 Early binding (ligação prematura): ou ligação estática, ocorre quando o método a ser
invocado é definido em tempo de compilação.
 Late binding (ligação tardia): ou ligação dinâmica, ocorre quando o método a ser
invocado é definido em tempo de execução.

Mensagens: é como os objetos se comunicam e enviam ordens para executarem métodos.


 Componentes:
o Objeto a quem a mensagem é endereçada.
o Nome do método ou serviço que se deseja executar.
o Parâmetros necessários ao método se existirem.

Classes Abstratas: desenvolvida para representar entidades e conceitos abstratos. É sempre uma
superclasse e não possui instâncias. Ela define um modelo para uma funcionalidade e fornece uma
implementação incompleta que é compartilhada por um grupo de classes derivadas.
 Possibilidades:
o Se ela tem pelo menos um método abstrato, obrigatoriamente é abstrata.
o Se ela tem todos os métodos abstratos, obrigatoriamente é abstrata.
o Se ela tem todos os métodos concretos, poderá ser abstrata ou concreta.
Interface: similar a uma classe abstrata, todos os seus métodos são abstratos. Uma classe concreta
ao implementar uma interface deverá escrever o corpo de todos os métodos. Uma classe abstrata
pode também implementar uma interface.

Classes abstratas x Interfaces:


Características Interfaces Classes abstratas
Herança múltipla Suporta herança múltipla. Pode Não suporta herança múltipla.
implementar diversas interfaces. Não pode estender várias
classes abstratas.
Implementação Não pode conter qualquer Pode conter métodos
método concreto, apenas concretos ou abstratos.
abstratos.
Constantes Suporta somente constantes Suporta constantes estáticas e
estáticas. de instância.
Encapsulamento Métodos e membros devem Métodos e membros podem
sempre ser públicos por padrão. ter qualquer visibilidade.
Membros de dados Não contém atributos, apenas Pode conter atributos.
assinatura de métodos.
Construtores Não contém construtores. Contém construtores.
Velocidade Em geral, são mais lentas que Em geral, são mais rápidas
classes abstratas. que interfaces.

Encapsulamento: é uma forma de restringir o acesso ao comportamento interno de um objeto. A


única coisa que um objeto precisa conhecer para pedir a colaboração de outro objeto é conhecer a
sua interface.

Polimorfismo: indica a capacidade abstrair várias implementações diferentes em uma única


interface. Ele diz respeito à capacidade de duas ou mais classes de objetos responderem a mesma
mensagem, cada qual de seu próprio modo.
 Tipos:
o Estático (sobrecarga ou overloading): representado por nome do método igual e
parâmetros diferentes. Decisão do método a ser chamado é em tempo de compilação.
o Dinâmico (sobrescrita ou overriding): é representado por nome e parâmetros do
método iguais. A decisão do método a ser chamado é tomada em tempo de execução.
 Universal: é todo aquele que ocorre em tempo de execução.
o Paramétrico: é aquele que permite que se escreva um código genérico para Server
os subtipos.
o Sobrescrita:

 Ad-hoc: é todo aquele que ocorre em tempo de compilação.


o Sobrecarga:
o Coerção: é suportado através da sobrecarga de operadores, ou seja, ocorre quando se
converte um elemento de um tipo no tipo apropriado para o método, é o famoso
casting implícito.
Herança: classes são grupadas em uma hierarquia. A classe que herda é chamada subclasse, classe-
filha, classe secundária ou classe derivada. A classe que é herdada é chamada superclase, classe-
pai/mãe, classe primária ou classe base. Ela facilita o compartilhamento de comportamento comum
entre classes. Quando uma subclasse herda de duas ou mais superclasses, trata-se de herança
múltipla.

Relacionamento:
 De dependência: é uma relação semântica entre dois ou mais elementos que ocorre se
mudanças na definição de um elemento (independente) causarem mudanças ao outro
elemento (dependente).
 De realização: relacionamento entre dois elementos em que um elemento realiza
(implementa/executa) o comportamento que o outro especifica.
 De associação: relacionamento estrutural entre objetos e especifica os objetos de uma classe
que estão ligados a objetos de outra classe.
o Simples: mais forte que o relacionamento de dependência indica que uma instância
de um elemento esta ligada à instância de outro elemento. Representado por uma
linha sólida com ou sem setas de navegabilidade. Pode haver nomes para a
associação e indicação de multiplicidade.
o Qualificada: similar a associação simples, contudo possui um qualificador, que é
um atributo de elemento-alvo capaz de identificar uma instância entre as demais.
Ocorre em associações um-para-muitos ou muitos-para-muitos em que se deseja
encontrar um elemento específico dada uma chave.
o Agregação: é um tipo de associação, porém mais forte, em que o todo esta
relacionado às suas partes de forma independente. As partes de existência própria.
 Composição: é um tipo de agregação, porém mais forte, em que o todo esta
relacionado às partes de forma dependente. As partes não tem existência
própria.
Métricas de software
Uma métrica de software é uma medição que se refere a um software, processo ou documentação.

Métricas de software de controle ou predição:


 Métricas de controle/processo: estão relacionados a processos de software. Utilizadas para
tomada de decisões sobre alterações no processo de desenvolvimento de software.
 Métricas de predição/produto: estão relacionadas a produtos de software. Utilizadas para
estimar o esforço necessário para construção ou alteração de software e auxiliam a prever
características dele.

Métricas de predição/produto:
 Métricas estáticas ou internas: são aquelas coletadas em representações do sistema como
projeto, programa ou documentação. Sem necessidade da execução de programas. Ajuda a
mensurar a complexidade e a facilidade de compreensão e manutenção de um sistema de
software.
 Métricas dinâmicas ou externas: são aquelas coletadas durante a execução de um
programa, a partir do comportamento do sistema. Ajudam a avaliar a eficiência e a
confiabilidade de um programa.

Métricas de software diretas ou indiretas:


 Métricas diretas: conhecidas como básicas, quantitativas ou primitivas, são aquelas que
não dependem da medição de outros atributos.
 Métricas indiretas: conhecidas como qualitativas ou derivadas, são aquelas que dependem
da medição de outros atributos.

Métricas de software orientadas as tamanho, função ou pessoas:


 Métricas orientadas a tamanho: aquelas baseadas em número de linhas de código
produzidas, também conhecidas como Lines Of Code (LOC).
 Métricas orientadas a função: aquelas baseadas na funcionalidade do software, tais como
análise de pontos de função.
 Métricas orientadas a pessoas: aquelas que indicam a forma como as pessoas devem
desenvolver programas de computador.

Métricas de software objetivas ou subjetivas:


 Métricas objetivas: aquelas que independem do autor da medição ou julgamento humano.
 Métricas subjetivas: aquelas que dependem do autor da medição ou julgamento humano.

Outras métricas diversas:


 Métricas de produtividade: concentra-se na saída do processo de engenharia de software
(ex: KLOC/pessoa-mês).
 Métricas de qualidade: indicam o quanto o software atende os requisitos definidos pelo
usuário.
 Métricas técnicas: concentra-se nas características do software (ex: complexidade,
modularidade, manutenibilidade, funcionalidade, etc).
 Métricas para o modelo de análise: tratam de vários aspectos do modelo de análise e
incluem funcionalidade entregue, tamanho do sistema e qualidade da especificação.
 Métricas para o modelo de projeto: quantificam atributos do projeto, de modo que
permitam ao engenheiro de software avaliar a qualidade do projeto de software.

*** Geralmente, é impossível medir os atributos de qualidade de software diretamente. ***


*** Os atributos de qualidade são atributos externos que se relacionam a como os desenvolvedores
e os usuários vêem o software. ***
*** Métricas dinâmicas, geralmente, possuem uma relação mais estreita com os atributos de
qualidade de software do que as métricas estáticas. ***

 Fan-in/Fan-out: um valor alto para fan-in significa que o x está firmemente acoplado com o
resto d projeto, e mudanças em x terão um grande impacto.
o Fan-in: é uma medida do número de funções ou métodos que chamam alguma outra
função ou método (digamos x).
o Fan-out: é o numero de funções chamadas pela função x.
 Extensão de código: é uma medida do tamanho de um programa. Geralmente, quanto maior
for o tamanho do código de um componente, mais complexo e propenso a erros esse
componente será.
 Complexidade ciclomática: é uma medida da complexidade de controle de um programa.
Pode estar relacionada a facilidade de compreensão do programa.
 Extensão de identificadores: medida de extensão média dos identificadores distintos de um
programa. Geralmente, quanto maiores forem os identificadores, mais eles serão
significativos e, por isso, mais compreensível será o programa.
 Profundidade de aninhamento de declarações condicionais: declarações IF
profundamente aninhadas são difíceis de compreender e são potencialmente propensas a
erros.
 Índices de fog: medida de extensão média das palavras e das sentenças em documentos.
Quanto maior for o valor para o índice de fog, mais difícil será a compreensão de
documentos.

Métricas de qualidade de software: são um subconjunto de métricas de software que se focam em


aspectos de qualidade do produto, processo e projeto. A qualidade intrínseca do produto é medida
pelo número de bugs no software ou tempo que o software pode rodar sem falhar.
 Mean time to failure (MTTF): é a métrica de robustez mais utilizada em sistemas críticos.
Mede o tempo entre falhas.
 Densidade de defeitos: é muito utilizada em sistemas comerciais. Mede os defeitos em
relação ao tamanho do software e o tempo. Mede a quantidade de defeitos durante um
período pelo tamanho do software. O número de defeitos pode ser relativo a um
determinado período ou a uma determinada fase do ciclo de vida do software, ou ao ciclo de
vida como um todo.
 Mean time between failure (MTBF): trata-se o tempo médio entre falhas, e é uma métrica
chave para sistemas que podem ser reparados ou restaurados.

Métricas de qualidade de processo: utilizadas para melhorar o desenvolvimento do software e sua


manutenção. Tornam-se muito importantes em um processo de desenvolvimento, pois medem
vários parâmetros nas várias fases do processo. Exemplos:
 Efetividade de remoção de defeitos
 Índice de manutenção de erros
 Cobertura de testes modulares/funcionais.

Métricas de qualidade de código: são mecanismos fundamentais, geralmente, para avaliação de


sistema open-source. Principais características para aceitação de um software a partir do código
fonte:
 Legibilidade: o código deve declarar sua intenção ao leitor.
 Testabilidade: o código deve ser organizado de uma forma que facilite o teste de unidade.
 Flexibilidade: dependência em relação a outros códigos devem ser minimizadas.
 Compatibilidade: o código deve cumprir com seus requisitos, funcionais ou não.
 Economicidade: o código deve fazer uso razoável dos requisitos do sistema, como
memória, processamento, etc.
Análise pontos de função
Análise de pontos de função: é uma medida baseada na visão do usuário independente da linguagem
de programação ou de qualquer outro aspecto relacionado à implementação do software. Permite
medir as funcionalidades ou tamanho funcional de um software, independente de tecnologia e sob o
ponto de vista dos requisitos funcionais do usuário. A produtividade é expressa como o número de
pontos de função implementados por pessoa-mês. Os pontos de função são mais voltados aos
sistemas de processamento de dados denominados por operações de entrada e saída. Há quem diga
que a estimativa do tamanho de software é subjetiva por conta do julgamento da complexidade, mas
há quem diga que é objetiva.
 Benefícios da análise de pontos de função:
o Uma ferramenta para determinar o tamanho de um pacote adquirido.
o Provê auxilio aos usuários na determinação dos benefícios de um pacote para sua
organização, é possível determinar se vale a pena comprar ou fabricar.
o Apóia o gerenciamento do escopo de projetos. Ao realizar estimativas ou medições é
possível determinar se os requisitos funcionais cresceram ou diminuíram e se essa
variação corresponde a novos requisitos.
o Complementa o gerenciamento dos requisitos ao auxiliar na verificação da solidez e
completeza dos requisitos especificados.
o Um meio de estimar custo e recursos para o desenvolvimento e manutenção de
software.
o Uma ferramenta para fundamentar a negociação de contratos para gerar diversos
indicadores de níveis de serviço.
o Um fator de normalização para comparação de software ou para a comparação de
produtividade na utilização de diferentes técncias.
*** Não mede diretamente esforço, produtividade, custo, qualidade, escopo, etc. ***
 Componentes:
o Arquivo lógico interno (ALI): grupo de dados logicamente relacionados ou
informações de controle cuja manutenção é feita pela própria aplicação. Sua função é
armazenar dados mantidos dentro da fronteira da aplicação através dos processos da
aplicação. Baseia-se em requisitos lógicos dos usuários e são independentes da
implementação ou meio de armazenamento.
 Exemplos: dados da aplicação; arquivos e dados de segurança da aplicação;
arquivos de dados de auditoria; arquivos de mensagem de auxílio; arquivo de
mensagens de erro; arquivo de cópia de segurança; arquivo que sofra
manutenção por mais de uma aplicação.
 Não exemplos: arquivos temporários; arquivo de trabalho; arquivos de
classificação; arquivos de cópia de segurança requerido pelo CPD; arquivos
introduzidos somente por causa da tecnologia usada; operações de junção e
projeção; índices alternativos.
o Arquivo de interface externa (AIE): grupo de dados logicamente relacionados ou
informações de controle, referenciados na aplicação para fins de recuperação de
dados cuja manutenção é feita por outra aplicação. Os dados são armazenados fora
da fronteira da aplicação. Um AIE de uma aplicação será sempre contado como um
ALI na aplicação de origem.
 Exemplos: arquivos de mensagem de auxílio; arquivos de mensagens de
erro.
 Não exemplos: dados recebidos de outra aplicação usados para adicionar,
alterar ou remover dados em um ALI; dados cuja manutenção é feita pela
aplicação que esta sendo avaliada, mas que são acessados e utilizados por
outra aplicação; dados formatados e processados para uso por outra
aplicação.
o Entrada externa (EE): processo elementar que processa dados ou informações de
controle recebidos de fora da fronteira da aplicação e cujo objetivo é manter um ou
mais ALIs e/ou alterar o comportamento do sistema. Provoca uma inclusão, exclusão
e/ou alteração nos dados do ALI. Cada entrada externa se origina de um usuário ou é
transmitida de outra aplicação e fornece dados distintos orientados à aplicação do
software ou informação de controle.
 Exemplos: operações de inclusões ou alteração de registros em arquivos de
aplicação; janelas que permitem adicionar, excluir e alterar registros em
arquivos de dados.
 Não exemplos: menus; telas de login; telas de filtro de relatórios e consultas;
múltiplos métodos de se executar uma mesma lógica de entrada; outros.
o Saída externa (SE): processo elementar que envia dados ou informações de controle
para fora da fronteira da aplicação. Seu objetivo é exibir informações recuperadas
através de processamento lógico, que envolva cálculos ou criação de dados derivados
e não apenas uma simples recuperação de dados. Uma saída externa pode manter um
ALI ou alterar o comportamento do sistema. Representam atividades do sistema que
transforma dados dos ALI e geram resultados ao usuário.
 Exemplos: dados transferidos para outra aplicação; relatórios; relatórios
online; formatos gráficos; gerador de relatórios.
 Não exemplos: telas de ajuda; literais; data, hora, controles de paginação,
etc; relatórios múltiplos com a mesma lógica e formato; relatórios criados
pelo usuário de forma dinâmica usando uma linguagem como SQL.
o Consulta externa (CE): representa a necessidade de processamento de consultas da
aplicação sendo uma combinação de entrada/saída de dados onde uma entrada de
dados causa uma recuperação e uma saída correspondente. A lógica de
processamento não deve conter cálculos matemáticos ou conter dados derivados ou
atualizar nenhum ALI.
 Exemplos: telas de logon; telas de ajuda; telas de alteração/remoção que
mostram o que será alterado ou removido antes da sua efetivação; tela de
menus que permitem informar parâmetros para a consulta na tela escolhida.
 Não exemplos: dados derivados; documentação online; sistema de teste;
sistema de tutoriais; relatórios e consultas com cálculo.
 Classificação das funções:
o Do tipo dado: representam requisitos de armazenamento do usuário. ALI e AIE.
o Do tipo transação: representam requisitos de processamento do usuário. EE, CE e
SE.
 Etapas do procedimento de contagem:
o Determinar o tipo de contagem: o procedimento de contagem de pontos de função
de um aplicativo que ainda será desenvolvido é diferente do procedimento de
contagem de um aplicativo pronto.
 Projeto de desenvolvimento: mede a funcionalidade fornecida aos usuários
finais do software para a primeira instalação da aplicação. Inclui
funcionalidades de contagem inicial da aplicação e as funcionalidades
requeridas para conversão de dados.
 Projeto de melhoria: mede as modificações realizadas para aplicações
existentes. Referenciada também como projeto de manutenção e inclui as
funcionalidades fornecidas aos usuários através de adições, alterações,
exclusões e conversões de funções na aplicação. Manutenções podem ser
somente evolutivas e, não, corretivas e preventivas.
 Projeto de aplicação: mede uma aplicação instalada e em pleno
funcionamento, Também referenciada como contagem de baseline ou
contagem instalada e avalia funcionalidades correntes providas aos usuários
finais da aplicação. Ela não é estimativa, é bastante precisa.
o Determinar o escopo e fronteira: indica a separação entre o projeto que esta sendo
medido e as aplicações externas ao domínio do usuário. Se torna possível definir
quais funcionalidades serão incluídas no processo de contagem de pontos de função.
Quem decide o que incluir na contagem é o usuário. Ele pode escolher todas as
funcionalidades disponíveis ou apenas parte delas. Requisitos não funcionais serão
ignorados.
o Calcular pontos de função não-ajustados: os ALI/AIE têm complexidades
diferentes que são medidos pela quantidade de dados elementares referenciados
(DER) e registros lógicos referenciados (RLR). DER é um atributo único,
reconhecido pelo usuário e não repetido, são campos de uma tabela ou atributos de
um objeto. RLR é um subconjunto de dados elementares referenciados, reconhecido
pelo usuário dentro de um ALI/AIE, número, rua, CEP, bairro. Toda função de dados
tem pelo menos um RLR, ela mesma. ALI/AIE são medidos por meio de DER/RLR.
CE/SE/EE são medidos por meio de dados elementares referenciados (DER) e
arquivos lógicos referenciados (ALR). ALR é um ALI/AIE que foi acessado por uma
função de transação, quanto mais ALI/AIE acessados por uma função de transação
maior a complexidade do ALR.
Complexidade funcional
Funções de Simples Média Complexa
dados / CE 3 4 6
transações EE 3 4 6
SE 4 5 7
AIE 5 7 10
ALI 7 10 15
o Projetos de desenvolvimento: é o tamanho das funções de desenvolvimento
é a soma das funções a serem entregue pelo projeto com as funções de
conversão.
o DFP = ADD + CFP
o Projeto de aplicação: o tamanho total das funções de aplicação é igual a
quantidade no momento da contagem sem funções de conversão.
o AFP = ADD
o Projeto de melhoria: pontos de função de melhoria é equivalente ao
tamanho das funções adicionadas, mais o tamanho das funções alteradas,
mais o tamanho das funções de conversão, mais o tamanho das funções
excluídas.
o EFP = ADD + CHGA + CFP + DEL

o Calcular fator de ajuste: há certas características em um software que devem ser


consideradas para se obter maior precisão sobre o cálculo do tamanho funcional.
Essas características são quantificadas para obter o fator de ajuste. Características
que influenciam:
 Comunicação de dados
 Processamento distribuído
 Volume de transações
 Entrada de dados online
 Performance
 Configuração do equipamento
 Interface com o usuário
 Atualização online
 Processamento complexo
 Reusabilidade
 Facilidade de implantação
 Facilidade operacional
 Múltiplos locais
 Facilidade de mudanças
Com base nos requisitos do usuário, cada característica geral do sistema deve ter
seu nível de influência numa escala de 0 a 5.

Calcula-se o fator de ajuste a partir da soma dos pontos obtidos de cada


característica pela formula: FA=(SNI*0,01)+0,65. Se o sistema estudado, todas
as 14 características tiverem nível de influência 5, basta fazer SNI=14*5. As
características podem influenciar no seu tamanho variando no intervalo de -35%
a +35%.
o Calcular os pontos de função ajustados: é extremamente simples, basta calcular
PFA=PFNA * FA. Os pontos de função ajustados equivalem aos pontos de função
não ajustados multiplicado pelo fator de ajuste calculado na etapa anterior.

*** Se um ALI é um AIE de outra aplicação conta-se os dados elementares apenas uma vez. ***
*** Informações de controle, tratam-se dos dados que influenciam um processo elementar da
aplicação. Especifica o que, quando ou como os dados devem ser processados e são utilizados pela
aplicação para garantir aderência aos requisitos funcionais. ***
*** Identificável pelo usuário, trata-se de requisito definidos para processos e/ou grupos de dados
que foram acordados e entendidos pelos usuários e desenvolvedores. ***
*** Mantido, trata-se da habilidade de incluir, modificar ou excluir dados a partir de um processo
elementar. ***
*** Processo elementar, trata-se da menor atividade capaz de produzir resultados significativos para
o usuário. ***
*** Registro lógico referenciado pode ser chamado de item de registro. ***
*** Dados elementares referenciados pode ser chamado de item de dados. ***

NESMA: é uma nova abordagem de pontos de função praticamente idêntica ao IFPUG em projetos
de desenvolvimento e aplicação, mas não de melhoria. Utiliza o conceito de deflatores para reduzir
distorções na contagem de projetos de melhoria. Abrange três tipos de contagem:
 Indicativa (baixa precisão): oferece um cálculo estimado da quantidade de pontos de
função sem a necessidade de conhecer detalhes do modelo de negócios do sistema. Utilizada
em fase inicial da proposta de desenvolvimento. Útil na viabilidade de um projeto.
o Elementos utilizados:
 Arquivos lógicos internos (ALI)= 35 pontos.
 Arquivos de interface externa (AIE)= 15 pontos.
o PFNA =35*ALI + 15*AIE
 Estimativa (média precisão): utilizada em sistema quando não há uma precisão do nível de
complexidade das funções existentes. Utilizada nas fases inicias do ciclo de vida do sistema
quando não existem dados detalhados do negócio. Determina que todos os tipos de dados
possuem complexidade baixa e que todos os tipos de transação possuem complexidade
média. É mais rápida e imprecisa. Elementos utilizados: ALI, AIE, CE, SE, EE.
 Detalhada (alta precisão): é necessário obter dados detalhados dos processos e modelos de
dados, como descrição de telas e relatórios ou mesmo um protótipo do sistema.
Qualidade e Teste de software
Para sistemas de grande porte, o gerenciamento da qualidade pode ser estruturado em 3 atividades:
 Garantia da qualidade: framework de procedimentos organizacionais e padrões.
 Planejamento de qualidade: seleção de procedimentos e padrões apropriados deste
framework, adaptados para o projeto.
 Controle de qualidade: definição e aprovação de processos que assegurem que a equipe de
desenvolvimento tenha seguido os procedimentos.

Características de qualidade:
 Interoperabilidade: capacidade do produto de software interagir com um ou mais sistemas
específicos. Habilidade de dois ou mais sistemas de interagir e cambiar dados.
 Conformidade: capacidade do software de estar de acordo com normas, convenções, ou
regulamentações previstas em leis e prescrições similares relacionadas à funcionalidade.
 Tolerância a falhas: capacidade de um software de manter um nível de desempenho
especificado em caso de defeitos ou de violação de sua interface especificada. Capacidade
de satisfazer requisitos apesar de suas falhas.
 Usabilidade: capacidade do software de ser compreendido, aprendido, operado e atraente ao
usuário, quando usado sob condições especificadas. Ser fácil de aprender e de usar.

Garantia da qualidade x Controle da qualidade:


 Garantia: esta focada no processo de desenvolvimento e prevenção de defeitos. Ocorre no
inicio das fases do ciclo de vida. Estabelece a infraestrutura que suporta métodos sólidos de
engenharia de software, gerenciamento de projeto e ações de controle de qualidade.
 Controle: esta focada no produto entregue ao usuário e a detecção e correção de defeitos.
Ocorre no final das fases do ciclo de vida. Engloba um conjunto de ações de engenharia de
software que ajudam a garantir que cada produto resultante atinja suas metas de qualidade.
Engloba verificação e validação.

Garantia da qualidade Controle da qualidade


Garante que o processo é definido e apropriado. As atividades focam na descoberta de defeitos
em específicos.
Metodologia e padrões de desenvolvimento são Um exemplo poderia ser. Os requisitos
exemplos de garantia da qualidade. definidos são os requisitos certos?
Orientada a processo. Orientado a produto.
Orientada a prevenção. Orientado a detecção.
Foco em monitoração e melhoria de processo. Inspeções e garantia de que o produto de
trabalho atenda aos requisitos especificados.
As atividades são focadas no início das fases no As atividades são focadas no final das fases no
ciclo de vida de desenvolvimento de software. ciclo de vida de desenvolvimento de software.
Garante que você esta fazendo certo as coisas e Garante que os resultados do seu trabalho são os
da maneira correta. esperados conforme os requisitos.

Definição de falha, defeito e erro por IEEE 610:


 Defeito: ato cometido por um individuo ao tentar entender uma informação, resolver um
problema ou utilizar um método ou uma ferramenta. Pode ocasionar a manifestação de
erros.
 Erro: manifestação concreta de um defeito. Diferença entre valor obtido e valor esperado.
 Falha: comportamento operacional do software diferente do esperado pelo usuário. Pode ter
sido causado por diversos erros e alguns erros podem nunca causar uma falha. Afetam
diretamente o usuário final.
Definição de falha, defeito e erro por Maldonado:
 Defeito: incapacidade de algum componente em realizar a função à qual foi projetado.
 Erro: manifestação de uma falha no sistema, causando diferenças das respostas
apresentadas com as esperadas.Nem todas falhas causarão erros.
 Falha: incapacidade de o sistema executar suas funções requeridas dentro das exigências
especificadas. Não existe falha se não tem defeito.

Definição de falha, defeito e erro por Pressman:


 Defeito: problema de qualidade descoberto após o software ser lançado aos usuários finais
ou após outra atividade de um processo de software.
 Erro: problema de qualidade descoberto antes de o software ser lançado aos usuários finais
ou após outra atividade de um processo de software.
 Falha: incapacidade de o sistema executar suas funções requeridas dentro das exigências
especificadas. Não existe falha sem defeito.

Definição de falha, defeito e erro por Sommerville:


 Defeito: uma característica do sistema que pode levar a um erro de sistema.
 Erro: um estado errôneo de sistema que pode levá-lo a um comportamento inesperado pelos
usuários.
 Falha: um evento que ocorre em algum momento, quando o sistema não fornece um serviço
conforme esperado por seus usuários.

Defeitos: fazem parte do universo físico, são causados por pessoas e podem ocasionar a
manifestação de erros. Observados sob uma perspectiva interna, o código está incorreto, a lógica
está inconsistente, funções estão ausentes. Defeitos causam erros que podem causar falhas.
Falhas: são observadas sob uma perspectiva externa, sob o ponto de vista da percepção do usuário,
travamento do sistema, terminação anormal, tela azul. Quando há uma diferença entre
comportamento esperado e o comportamento observado.
Erros: fazem parte do universo do usuário e podem gerar falhas como comportamentos
inesperados. São observados sob a perspectiva intermediária. Erros nem sempre causarão falhas,
pois se o usuário não utilizar a parte lógica defeituosa não haverá conseqüência observável. Quando
há uma diferença entre o resultado observado e o resultado esperado.
*** IEEE 610: testes de software revelam falhas e a depuração descobre defeitos. ***
*** Pressman: teste de software revelam defeitos e a depuração descobre erros. ***

Verificação x Validação:
 Verificação: ocorre em ambiente de desenvolvimento e envolve a certificação de que o
software construído esteja de acordo com as especificações de requisitos. Depende da
especificação. Estamos construindo o produto corretamente?
o Estática (inspeção): trata da documentação. Examina requisitos, diagramas, código.
o Dinâmica (teste): trata da execução em si. Examina o comportamento.
 Validação: ocorre em ambiente de produção e se certifica que o software construído está de
acordo com as expectativas do cliente. Depende dos usuários. Estamos construindo o
produto correto?
*** Não garante que o software seja completamente livre de defeitos. ***

Teste de software: é o processo de executar um software com dois objetivos principais, demonstrar
ao desenvolvedor e ao cliente que o software atende aos requisitos especificados; e descobrir falhas
ou defeitos no software que apresente comportamento incorreto. Não pode demonstrar que o
software esta livre de defeitos.
Princípios que guiam testes de software:
 Testes demonstram a presença de defeitos:
 Testes exaustivos são impossíveis:
 Teste o mais breve possível:
 Agrupem os defeitos mais sensíveis:
 Paradoxo do pesticida:
 Testes dependem do contexto: testes devem ser elaborados de acordo com o contexto em
que são executados.
 Ausência de defeitos é uma ilusão:

Pressman menciona características que leva a um software testável:


 Operabilidade: quanto melhor funciona, mais eficientemente pode ser testado.
 Observabilidade: o que você é o que você testa.
 Controlabilidade: quanto melhor você pode controlar o software, mais o teste pode ser
automatizado e otimizado.
 Decomponibilidade: controlando o escopo, podemos isolar problemas mais rapidamente e
realizar testes mais inteligentes.
 Simplicidade: quanto menos houver a testar, mais rapidamente podemos testá-lo.
 Estabilidade: quanto menos modificações, menos interrupções no teste.
 Compreensibilidade: quanto mais informações temos, mais inteligentemente vamos testar.

Processo de teste: pode produzir diversos artefatos, dois muito importantes:


 Plano de testes: apresente planejamento para execução do teste, incluindo abrangência,
abordagem, recursos e cronograma de atividades de teste, etc. Identifica os itens as
funcionalidades a serem testados, as tarefas realizas e os riscos associados com a atividade
de teste. Possui, identificador, referências, introdução, itens de teste, riscos de software,
características a serem testadas, abordagem (estratégia), critérios de aceite e falha, critérios
de suspensão e requisitos de retomada, etc. Principal objetivo é ganhar a aceitação e
aprovação dos envolvidos. Responsabilidade do gerente de testes.
 Casos de testes: é um artefato que contém um conjunto de condições/entradas usadas para
testar o software. Elaborado para identificar defeitos na estrutura interna do software ou
garantir que os requisitos do software sejam plenamente atendidos. Possui campos de
descrição, pré-condições, entradas, ações, pontos de observação, pontos de controle,
resultados esperados e pós-condições. Responsabilidade do analista de testes.
*** Testador é quem desenha os scripts e faz o trabalho operacional. ***
Ciclo de vida de testes:
 Planejamento: elabora-se o projeto e testes e o plano de testes.
 Preparação: organiza-se o ambiente de testes, com infraestrutura adequada e pessoal
capacitado, registrando e controlando as versões do produto.
 Especificação: elaboram-se e revisam-se os casos de teste e os scripts de teste.
 Execução: preparam-se os dados de testes, executam-nos, solucionam-se ocorrências,
acompanha-se a execução de casos de teste e elaboração de um relatório final.
 Entrega: avalia-se e arquiva-se a documentação, gerando um relatório com as
conformidades e não-conformidades.

Estratégia de testes: uma estratégia deverá fornecer diretrizes para o profissional e uma serie de
metas para o gerente. Elas são agrupadas de acordo com o momento em que eles são executados ou
pelo nível de especificidade do teste.
 Esperar que o sistema esteja totalmente construído: simplesmente não funciona, resultará em
um software defeituoso que desagrada todos os que investiram nele.
 Executar testes diariamente: sempre que uma parte seja construída. Menos atraente, mas
pode ser muito eficaz.
 Baixo nível x alto nível:
o Baixo nível: testes unitários e teste de integração. É necessário conhecimento da
estrutura interna.
o Alto nível: testes de validação e teste de sistema. Não é necessário o conhecimento
da estrutura interna.

Ordem dos testes: Teste de unidade, teste de integração, teste de sistema, teste alpha, teste beta.

Teste de unidade (componente ou módulo): focaliza o esforço de verificação na menor unidade de


projeto de software. Caminhos de controle importantes são testados. Pode ser conduzido em
paralelo para diversos componentes. Todos os caminhos são usados para assegurar que todas as
instruções em um módulo tenham sido executadas pelo menos uma vez. São testados todos os
caminhos de manipulação de erro. As funções ou métodos individuais são os tipos mais simples de
componentes e seus testes são um conjunto de chamadas dessas rotinas com diferentes parâmetros
de entrada. Geralmente são feitos pelos próprios desenvolvedores. Em geral teste de caixa branca.

Teste de integração: é uma técnica para construir a arquitetura de software ao mesmo tempo que
conduz testes para descobrir erros associados com as interfaces. O objetivo é construir uma
estrutura de programa determinada pelo projeto a partir de componentes testados e unidade. O
programa inteiro é testado como um todo. É um esforço de verificação para testar se os
componentes funciona juntos. Teste de caixa branca ou teste de caixa preta.
*** Sommerville: teste de integração e teste de release fazem parte do teste de sistema. ***
Teste de validação (aceitação): focaliza simplesmente ações visíveis ao usuário e saídas do sistema
reconhecíveis pelo usuário. A validação tem sucesso quando o software funciona de uma maneira
que pode ser razoavelmente esperada pelo cliente. Na especificação dos requisitos tem um seção
denominada critérios de validação usado nos testes de validação. Teste de caixa preta. Existem 3
estratégias:
 Formal: é um processo altamente gerenciado e constuma ser uma extensão do teste de
sistema, sendo planejado e projetados com o mesmo nível de detalhe.
 Alfa (informal): é um conjunto de procedimentos em que são identificados e documentados
diversas funções e tarefas de negócio, mas não exigem casos de teste específicos para serem
seguidos. Realiza com mais freqüência pela organização do usuário final.
 Beta: são os menos controlados das três estratégias. A quantidade de detalhes, os dados e a
abordagem são de inteira responsabilidade do testador. Implementados por usuários finais,
geralmente com pouco ou nenhum gerenciamento por parte da desenvolvedora.
*** Beta e Alfa são executados por usuários finais, mas Alfa ocorre em ambiente controlado e
Beta em ambiente não controlado. ***
*** Alfa é conduzido no ambiente do desenvolvedor por um grupo representativo de usuários
finais. ***
*** Beta é conduzido nas instalações de um ou mais usuários finais e o desenvolvedor
geralmente não esta presente. ***

Teste de sistema: estão fora do escopo do processo de software e não são executados somente por
engenheiros de software. É na realidade uma série de diferentes teste cuja finalidade primária é
exercitar totalmente o sistema. Envolve a integração de dois ou mais componentes que
implementam funções ou características do sistema e depois o teste desse sistema integrado. Teste
de caixa preta.
*** Sommerville divide em duas fases para sistemas complexos: teste de integração e teste de
release. ***
*** Teste de release a equipe de testes concentra-se em validar se o sistema atende aos requisitos e
em assegurar que o sistema é confiável. É normalmente um teste de caixa preta.***

*** 4 estágios bem definidos ***

*** 3 estágios pouco definidos ***


*** Teste de desenvolvimento são aqueles que a equipe testa durante o desenvolvimento. ***
*** Teste de release são aqueles em que a equipe de testes separada testa uma versão completa do
sistema antes de ser liberado para os usuários. ***
*** Teste de usuários são aqueles em que usuários de um sistema testam o sistema em seu próprio
ambiente. ***
*** Teste de aceitação é um tipo de teste de usuário em que o cliente testa formalmente. ***
*** Teste de release é feito por uma equipe não envolvida no desenvolvimento e não busca
defeitos, ele checa se o sistema esta de acordo com os requisitos e bom para uso. ***

Técnicas (como testar):


 Caixa preta  Caixa branca  Caixa cinza
 Principais técnicas caixa branca:
o Caminho básico
o Estruturas de controle
o Complexidade ciclomática
 Principais técnicas caixa preta:
o Baseado em grafos
o Partição de equivalência
o Análise de valor limite
o Matriz ortogonal

Níveis (quando testar):


 Teste de unidade  Teste de sistema
 Teste de integração  Teste de aceitação
Tipos de teste (o que testar):
 Usabilidade  Configuração
 Segurança  Regressão
 Estresse  Carga

Definições do teste de desempenho/performance:


 Testes de desempenho se concentram na capacidade de um componente/sistema reagir a
entradas de usuários/sistema dentro de um período/condições especificas.
 Ele é projetado para testar o desempenho em tempo de execução de um software dentro de
um contexto de um sistema integrado.
 Existem 3 tipos de teste de desempenho: teste de carga, teste de estresse, teste de
escalabilidade.
 Teste de desempenho ocorre durante todos os passos de um processo de software.
 Para Sommerville, eles precisam ser projetados para assegurar que o sistema possa processar
a carga a que se destina.
 Normalmente envolve a execução de uma serie de testes em que você aumenta a carga até
que o desempenho se torne inaceitável.

Definições de teste de carga/estresse/volume:


 Concentram-se na capacidade de um sistema lidar com níveis cada vez maiores de carga
realistas antecipadas em decorrência de solicitações de transações geradas por usuários ou
processos simultâneos.
 Os tempos médios de resposta referentes a usuários em cenários diferentes de uso típico
(perfis operacionais) podem ser medidos e analisados.

Definições de teste de usabilidade: demonstra falhas na facilidade de uso do software pelos usuários
finais.

Definições de teste de cenários: utiliza cenários para ajudar o testador a resolver um problema
complexo ou testar o sistema.

Definições do teste de regressão:


 Teste de regressão é um teste de software que procura descobrir erros por meio da
reaplicação parcial dos testes a um programa modificado.
 Teste de regressão consiste em tipicamente na aplicação de versões mais recentes do
sotware para garantir que não surgiram novos defeitos em componentes já analisados.
 O teste de regressão consiste em aplicar em cada nova versão de um software todos os testes
que já foram aplicados nas versões anteriores possibilitando a identificação dos impactos das
implementações da nova versão em funcionalidades que já foram testadas anteriormente e
não foram modificadas.
 Teste de regressão se refere ao reteste de uma unidade, integração ou sistema após uma
modificação a fim de verificar se a mudança não introduziu novas falhas.
 Teste de regressão retesta um sistema ou componente para verificar se alguma modificação
recente causou algum defeito indesejado e para certificar que o sistema ainda atende os
requisitos.
 Teste de regressão garante que as novas implementações não tenham quebrado as
funcionalidades já existentes.
 Teste de regressão visa garantir a integridade de um software já testado que tenha recebido
uma nova implentação.
Definições de teste de fumaça:
 Trata-se de um teste preliminar para revelar falhas graves o suficiente para rejeitar um
lançamento de software.
 São um subconjunto de casos de teste que cobrem a funcionalidade mais importante de um
componente ou sistema.
 Conjunto de testes executado a cada nova compilação de um produto para verificar se a
compilação é testável antes da compilação ser liberada na mãos da equipe de teste.
 Realizado pelo desenvolvedor.

Definições do teste de portabilidade:


 É o processo de teste em que um software ou produto pode ser movido de um ambiente para
outro.
 Ele é medido em termos da quantidade máxima de esforço necessário para transferir de um
sistema para outro.
 Incluem os teste de instalabilidade, compatibilidade, adaptabilidade e substitutibilidade.

Definições de teste de recuperação: validam a capacidade e qualidade da recuperação do software


após crashes, falhas de hardware ou outros problemas. Forçam o software a falhar de várias formas
e verifica se a recuperação foi adequada.

Definições de teste de compatibilidade: validam a capacidade de um software ser executado em um


ambiente particular de hardware, software, sistema operacional, rede, etc.

Definições de teste de vulnerabilidade: um teste que procura por vulnerabilidades em um sistema e


documenta em relatórios.

Definições de teste de segurança: chamado de teste de ameaça, trata-se de um teste que verifica se
os mecanismos de proteção incorporados a um sistema vão, de fato, protegê-lo de invasão indevida.
Ocorrem durante os testes de integração e testes de sistema.

Depuração: descobre e conserta defeitos e geralmente é feita por uma equipe de desenvolvimento.
Testes: descobrem falhas. Geralmente por uma equipe de testes.
Arquitetura de software
Arquitetura de software: é a organização ou a estrutura dos componentes significativos
do sistema de software que interagem por meio de interfaces. A separação em camadas
fornece um nível de abstração através do agrupamento lógico de sistemas relacionados
entre si. Camadas de abstração mais altas devem depender das camadas de abstração
mais baixas. Mudanças em camadas mais baixas que não afetem sua interface, não
implicarão mudanças nas camadas superiores.

Arquitetura em camadas: permite melhor separação de responsabilidades, decomposição


de complexidade, encapsulamento de implementação, maior reuso e extensibilidade.
Pode penalizar o desempenho do sistema e aumentar o esforço ou complexidade.
 Uma camada: beneficio de ser mantido por um administrador central. Interfaces
gráficas exigem muito mais poder computacional. Não consegue suportar
milhares de usuários.
 Duas camadas: ou cliente-servidor. Organizada como um conjunto de serviços.
Clientes iniciam e terminam a comunicação com servidores. Servidores realizam
uma execução contínua, recebem e respondem solicitações. É uma arquitetura
distribuída.
o Principais componentes:
 Servidores
 Clientes
 Rede
o Cliente magro: todo o processamento da aplicação e o gerenciamento de
dados é realizado no servidor.
 Vantagens: baixo custo de administração, facilidade de proteção,
baixo custo de hardware, menor custo de licenciamento de
software, etc.
 Desvantagens: se o servidor der problema e não tiver
redundância os clientes ficarão inoperantes. Necessita de maior
largura de banda, em geral possui um pior tempo de resposta, etc.
o Cliente gordo: servidor somente é responsável pelo gerenciamento de
dados e o software cliente implementa a lógica da aplicação.
 Vantagens: apresenta performance melhor, possui maior
flexibilidade, etc.
 Desvantagens: não há um local central para atualizar a lógica,
não suporta bem o crescimento do número de clientes, etc.
 Três camadas: esse sistema é escalonável, pois é relativamente fácil adicionar
novos servidores web quando o número de clientes aumenta.
o Apresentação: possui classes que funcionam para visualização dos
dados. Tem o objetivo de exibir informações e traduzir ações do usuário
em requisições para as demais partes do sistema.
o Negócio: possui classes que implementam regras de negócio no qual o
sistema será implementado. Realiza cálculos com base nos dados
armazenados ou nos dados de entrada.
o Dados: possui classes que comunicam-se com outros sistemas para
realizar tarefas ou adquirir informações para o sistema. É implementada
utilizando algum mecanismo de armazenamento persistente. Pode haver
uma subcamada dentro dessa camada chamada camada de persistência
ou camada de acesso.
 4 camadas cliente-servidor: surgiu com a idéia de retirar a apresentação do
cliente e centralizá-la em um servidor web. Não havia necessidade de instalar o
aplicativo na máquina do cliente. As camadas eram, dados, aplicação,
apresentação e cliente.

Arquitetura MVC: divide uma aplicação em três partes interconectadas, de modo a


separar representações internas de informação das formas em que a informação é
apresentada para o usuário. A manutenção fica mais fácil. Promove a estrita separação
de responsabilidade entre componentes de uma interface gráfica.
 Modelo: responsável pela representação dos dados, provendo meios de
leitura/escrita. Gerencia não só dados, mas também os comportamentos
fundamentais da aplicação. Encapsula as principais funcionalidades e dados do
sistema. Notifica suas visões e respectivos controladores quando surge alguma
mudança em seu estado. Responsável pela manutenção do estado da aplicação.
 Controle: responsável por receber todas as requisições do usuário. Capaz de
enviar comandos para o modelo atualizar o seu estado. Também pode enviar
comandos para a respectiva visão para alterar a apresentação. Define o
comportamento da aplicação, interpretando as ações do usuário e mapeando-as
em chamadas do modelo. Controla o fluxo da aplicação.
 Visão: responsável pela interação com o usuário, sendo responsável apenas pela
exibição de dados. Uma representação visual do modelo. Recebe instruções do
controle, notifica o controle e recebe informações do modelo. Existem diversas
visões para cada modelo.

Arquitetura distribuída: há ganhos de responsividade, escalabilidade, redundância,


disponibilidade, compartilhamento de recursos, controle e envolvimento do usuário, etc.
É como se tudo estivesse sendo executado como um único sistema.

Arquitetura hub (hub-and-spoke): é um modelo, um paradigma e um sistema de


conexões dispostas como uma roda de uma bicicleta, em que o tráfego se move com os
raios conectados ao hub em seu centro. Componentes:
 Hub/broker(concentrador): concentra todas as mensagens das aplicações,
além de funcionar como um gerenciador de integração. Cuidam da
transformação e da tradução do conteúdo das mensagens recebidas de forma que
a aplicação destinatária as compreenda.
 Spoke (adaptador)
 Application (aplicação)

Arquitetura de microserviços: é uma abordagem para desenvolvimento de uma


aplicação como um conjunto de pequenos serviços, cada um executando o seu próprio
processo e se comunicando por meio de mecanismos leves. Implantados por máquinas
de implantação totalmente automatizadas. Há um mínimo de gerenciamento
centralizado. Serviços são independentes, implantáveis, escaláveis, sendo que cada um
fornece um escopo bem definido. Podem ser escritos em linguagens diferentes e serem
gerenciados por equipes diferentes. Equipes multidisciplinares agregam muito valor na
construção de um serviço. A equipe é totalmente responsável pelo produto e não só pelo
projeto. A equipe deve ser dona do produto por todo seu ciclo de vida.

Arquitetura mainframe: só um servidor de grande porte possui recursos suficientes para


processar uma enorme quantidade de tarefas em lote ou transações concorrente online.
Oferece alta disponibilidade, segurança, performance, escalabilidade, compatibilidade,
integridade, etc. Alto custo de aquisição, alto consumo de energia, alto custo de
refrigeração. Podem executar diversos sistemas operacionais e virtualizar seus recursos.
Arquitetura orientada a serviços (SOA)

Serviço: é um mecanismo que permite acessar um conjunto de recursos. Ele é oferecido por uma
entidade (provedor de serviços) para uso de terceiros (consumidor de serviços). Não há necessidade
de esses terceiros conhecerem o provedor de serviços. Os serviços são agnósticos, o que permite
maior potencial de reuso. A lógica de um serviço não depende de outras partes.

O que é SOA:
 Um paradigma para organização e utilização de recursos distribuídos que estão sob o
controle de diferentes domínios proprietários.
 Um conjunto de princípios e melhores práticas para implementação e execução de processos
de negócio automatizados em ambientes de tecnologia da informação heterogêneos.
 Uma forma de aproximar a linguagem do negócio e da tecnologia da informação, facilitando
a integração de ambientes corporativos por meio de serviços.
 Um meio de organizar as soluções que promove o reuso, o crescimento e a
interoperabilidade.
 Uma abordagem (não monolítica) para integração de arquiteturas baseadas no conceito de
serviço.
 Uma abordagem arquitetural corporativa que permite a criação de serviços de negócios
interoperáveis, que podem ser reutilizados e compartilhados entre aplicações e empresas.

** é um modelo de arquitetura que é agnóstico a qualquer plataforma de tecnologia **


** plataforma de tecnologia mais associada são os webservices **

O que não é SOA:


 Uma tecnologia  Um software  Um framework
 Um projeto de TI  Uma solução de  Um middleware
 Uma metodologia negócio
 Um serviço  Uma ferramenta
 Um produto  Um WebService

Conceitos chaves SOA:


 Visibilidade: é o relacionamento entre consumidores e provedores que é satisfeito quando
eles estão aptos há interagirem entre si. É a capacidade de o provedor e o consumidor se
verem de forma consciente, concordante e acessível.
o Pré-condições:
 Consciência
 Concordância
 Acessibilidade
 Interação: envolve a execução de ações na direção do serviço. Refere-se a troca de
mensagens.
 Efeitos no mundo real: é o resultado do uso de um serviço por um cliente que gera a
alteração no estado compartilhado entre este e seu consumidor e outras entidades que
pertençam ao mesmo domínio. Sempre há de ter um efeito real.

Conceitos que se referem aos serviços:


 Descrição do serviço: a informação necessária para utilizar um serviço. O propósito é
facilita a interação e visibilidade.
 Contexto de execução: é o conjunto de elementos de infraestrutura, entidades de processo,
afirmações de acordos de políticas que são identificados como parte de uma interação de
serviço.
 Contratos: representa um acordo de duas ou mais partes. São sobre as condições de uso de
um serviço.
 Políticas: representa alguma restrição ou condição sobre o uso.

Objetivos e benefícios SOA:


 Maior interoperabilidade intrínseca: trata de estabelecer a interoperabilidade nativa
dentro dos serviços, a fim de reduzir a necessidade de integração. Pois já que são
nativamente interoperáveis, reduz a necessidade de integração.
 Maior federação: um ambiente federado é aquele em que os recursos e aplicativos são
unidos, entretanto, cada um mantém sua autonomia e autogestão.
 Maior diversificação de fornecedores: trata da capacidade que o cliente tem de analisar
diversos fornecedores e serviços, invocando o melhor serviço ou aquele que seja mais
condizente com sua demanda.

Vantagens SOA:
 Reutilização: serviço pode ser reutilizado para outras aplicações.
 Produtividade: com o reuso diminui o tempo de desenvolvimento.
 Flexibilidade: isolando a estrutura de um serviço as mudanças são feitas com maior
facilidade.
 Manutenibilidade: com baixo acoplamento, facilita a manutenção dos serviços.
 Alinhamento com o negócio:
 Interoperabilidade: disponibilizar serviços independentemente da plataforma e tecnologia.
 Integração: integração com outros serviços, aplicativos e sistemas legados.
 Governança: gerenciamento dos processamentos do negócio.
 Padronização: é baseado no uso de padrões.
 Abstração: serviço totalmente abstraído da sua implementação.
 Riscos: auxilia a mitigação de riscos.

Desvantagens SOA:
 Performance: depende do servidor onde o serviço está publicado.
 Complexidade: uma grande quantidade de serviços precisa ser gerenciada.
 Robustez: caso uma exceção acontecer não tem como reverter o processo.
 Disponibilidade: uma queda na rede ou servidor deixa todos os serviços indisponíveis.
 Testabilidade: o debug no serviço é um problema para os desenvolvedores.
 Governança: exige-se que haja governança na organização.
 Design: grande aumento da complexidade do design dos serviços.
 Segurança: os serviços estão disponíveis na rede e os dados são trafegados na rede podendo
ser interceptados.

Modelos arquitetônicos:
 End-to-End: os prestadores de serviço notificam os solicitantes de serviços sobre os
serviços disponíveis. Os solicitantes de serviços, então invocam os serviços.
 Triangular: três papéis são identificados:
o Prestadores de serviço: publica serviços em um registro de serviços.
o Registro de serviços: registra e organiza os serviços publicados e fornece um
serviço de busca. Geralmente contém um repositório de serviços associado a duas
interfaces de acesso.
o Solicitantes de serviços: se conecta ao prestador de serviço e remotamente invoca o
serviço do prestador. Se ele esta ciente de um prestador de serviço apropriado ele
pode conectar diretamente sem sequer consultar o registro de serviços.
 Implementam o modelo triangular:
o Publish-Find-Bind:
 Prestador de serviços:
 Solicitante de serviços:
 Registro (Broker) de serviços:
o Find-Bind-Execute:
 Prestador de serviços: publicam serviços no registro de serviço. Determina
o comportamento do serviço que esta disponibilizando. É o dono do serviço.
 Solicitante de serviços: realizam uma busca por algum serviço de interesse.
Caso encontre algum serviço desejado, um contrato é criado e devolve-se um
endereço (endpoint) para utilização do serviço. Pode ser representado por
uma pessoa ou empresa.
 Registro de serviços: preocupa-se em catalogar estes serviços dentro de uma
estrutura organizada e disponível por um mecanismo de busca.

Papéis ou atores que compõe o ciclo de vida SOA:


 Consultor de negócios: responsável pelo mapeamento dos processos de negócio da
organização.
 Arquiteto SOA: responsável pela modelagem dos serviços, além da construção, instalação
e manutenção.
 Provedor:
 Consumidor:

Modelagem de serviço SOA: é a primeira etapa na implantação de uma solução orientada a


serviços. São responsáveis por identificar os recursos necessários para construção, o
recondicionamento ou reuso de serviços existentes e a integração da solução final.
 Abordagem top-down: determina que a organização identifique primeiramente os
processos que considerar prioritários.
 Abordagem Bottom-up: determina que a organização identifique primeiramente os
processos menos prioritários.

Princípios de design: são 8 princípios que norteiam toda modelagem lógica de serviços e aplicações.
 Contrato de serviço padronizado (Service contract): trata-se de um documento que
descreve o que o serviço faz, dentre outras coisas. Trazem detalhes da funcionalidade
provida por um serviço. Pode conter outros documentos, como service level agreement.
 Baixo acoplamento de serviços (Service loose coupling): esta relacionado com sua
capacidade de ser independente de outros serviços para realizar sua tarefa. Uma possível
conseqüência é alta coesão. Um serviço nunca será 100% desacoplado, mas o desafio é
achar o grau de desacoplamento que torne o serviço flexível para compor outros serviços e
com custo não tão elevado. Para diminuir a dependência com o mundo exterior utiliza-se a
tecnologia chamada ESB(Enterprise Service Bus), implementação conceitual que abstrai a
forma de troca de mensagens feitas pelos sistemas.
 Abstrações de serviços (Service abstraction): são realizados sem entender a forma de
implementação. Os serviços devem ser vistos como um caixa preta que compõe um sistema.
Se eu quiser mudar a implementação, refatorar, manuteir, não há nenhum problema desde
que eu mantenha os padrões de entrada e saída definidos no contrato.
 Reusabilidade de serviços (Service reusability): um serviço reutilizável é aquele que não
carrega particularidades técnicas de uma implementação ou regra de negócio específica e é
genérico o suficiente para atender outros projetos. É necessário mais esforço para construir
um serviço mais genérico.
 Autonomia de serviços (Service autonomy): um serviço autônomo é aquele que independe
de um elemento externo para executar sua lógica. É um principio que visa fornecer serviços
com independência de seu ambiente de execução. A conseqüência disso é uma maior
confiabilidade. O ato de autonomia pode trazer um melhor desempenho. Essa autonomia é
medida e disponibilizada nos contratos formais, tendo como finalidade esclarecer o nível de
independência aos seus consumidores.
 Independência de estados de serviços (Service statelessness): serviços são explicitamente
projetados para minimizar o período durante o qual eles existem em uma condição de
independência de informações de estado. A independência de estado é quando um serviço
não precisa reter nenhum dado do estado para que outro serviço processe sua lógica. Os
serviços devem evitar a alocação de recursos por muito tempo. Recomenda-se a construção
de serviços sem estado.
 Visibilidade de serviços (Service discoverability): os serviços devem ser reutilizáveis, mas
para que você possa reutilizá-lo, você deve ser capaz de encontrá-lo. Serviços são projetados
para serem efetivamente descobertos e interpretados para que, na descoberta, seu propósito e
capacidades sejam claramente entendidos. O principal objetivo é fazer com que o serviço se
torne visível a todos, aumentando assim a agilidade, produtividade e confiabilidade dos
consumidores. O mecanismo de descoberta é necessário para evitar o desenvolvimento
redundante de uma solução que já esta contida em um serviço existente.
 Composição de serviços (Service composability): serviços são projetados para que atuem
como participantes eficazes de uma composição, independente do tamanho e da
complexidade de composição. A composição de serviços permite que as capacidades de um
serviço sejam combinadas várias vezes com as de outros serviços em novas configurações a
fim de resolver problemas diferentes.

Composição de serviços: uma das principais características de um serviço é a sua capacidade de se


compor com outros serviços para a elaboração de um novo serviço de mais alto nível de abstração.
Os serviços individualmente devem ser projetados com independência de estados. No entanto,
quando eles estão compostos, trabalhando em conjunto, geralmente é necessário que eles sejam
capazes de manter seus estados.
 Workflows de coordenação para implementar a composição de serviços:
o Orquestração: processo em que vários recursos dentro de uma organização podem
ser coordenados para executar um conjunto de lógicas de processo de negócio. Essa
tecnologia é mais comumente associada a uma plataforma central de gerenciamento
de atividades que fornecem benefícios como transformação de dados e
gerenciamento de transações. É o cara que vai invocar e combinar os serviços
isolados em serviços compostos.
o Coreografia: não há um coordenador central. Cada serviço sabe exatamente quando
executar suas operações e com quem interagir. É um esforço colaborativo,
distribuído e descentralizado com foco na troca de mensagens em processos de
negócios públicos. Todos os participantes precisam estar cientes do processo de
negócio, das operações a serem executadas, das mensagens a serem trocadas, e do
momento da troca de mensagens.
o Service component architecture (SCA): trata-se de uma tentativa de simplificar a
construção de uma arquitetura orientada a serviços. Baseado na idéia de que funções
de negócio são providas como uma serie de serviços, os quais são combinados a fim
de criar soluções que sirvam a uma necessidade particular. Ela prove um modelo
para composição de serviços e para criação de componentes de serviços, incluindo o
reuso de funções de aplicações existentes dentro da composição SCA.
Manifesto SOA prioriza:
 Valor de negócio > estratégia técnica.
 Objetivos estratégicos > benefícios específicos de projetos.
 Interoperabilidade intrínseca > integração personalizada.
 Serviços compartilhados > implementações de propósito específico.
 Flexibilidade > otimização.
 Refinamento evolutivo > busca da perfeição inicial.
Princípios orientadores:
 Respeitar a estrutura social e de poder da organização.
 Reconhecer que SOA, em ultima instância, requer mudanças em múltiplos níveis.
 O escopo de adoção de SOA pode variar.
 Manter os esforços gerenciáveis e dentro de limites significativos.
 Produtos e padrões, por si só, não proverão uma SOA nem aplicarão os paradigmas de
orientação a serviços por você.
 SOA pode ser realizada através de uma variedade de tecnologias e padrões.
 Estabelecer um conjunto uniforme de padrões e políticas corporativas embasado em padrões
da indústria, de fato e da comunidade.
 Buscar uniformidade no exterior e permitir diversidade no interior.
 Identificar serviços através da colaboração entre partes interessadas no negócio e na
tecnologia.
 Maximizar o uso de serviços considerando o escopo de utilização atual e futuro.
 Verificar que os serviços satisfaçam os requisitos e objetivos de negócio.
 Evoluir os serviços e sua organização em resposta ao uso real.
 Separar os diferentes aspectos de um sistema que mudam com diferentes freqüências.
 Reduzir dependências implícitas e publicar todas as dependências externas para aumentar a
robustez e diminuir o impacto de mudanças.
 A cada nível de abstração, organizar cada serviço em torno de uma unidade de
funcionalidade coesa e gerenciável.

Mensageria: em um sistema distribuído, as partes têm que conversar entre si e essa comunicação é
realizada, em geral, por meio de trocas de mensagens. Mensageria trata-se de uma maneira de
resolver problemas complexos de integração de sistemas por meio da comunicação indireta entre as
partes. Indireta por que temos dois ou mais sistemas que precisam conversar, entretanto eles não
possuem uma linguagem comum para tal. Ela reduz o grau de acoplamento entre os componentes,
permite o processamento de requisições de forma assíncrona e integra sistemas desenvolvidos em
tecnologias diferentes. Existem duas famosas abordagens de comunicação:
 Síncrona
 Assíncrona

Common Object Request Broker Architeture (CORBA): é uma arquitetura padrão proposta pela
OMG para estabelecer e simplificar a troca de dados entre sistemas distribuídos heterogêneos. É
independente de linguagem e tecnologia.
 Object Manager Architeture (OMA): uma estrutura comum para gerenciamento de
objetos distribuídos.
 Object Request Broker (ORB): responsável pela interoperabilidade entre objetos. Por
meio do IOR, ele consegue localizar os objetos e transmitir as informações. É um módulo
intermediário entre cliente/objeto, sendo responsável por aceitar requisições, enviá-las ao
objeto correto e entregar a resposta ao cliente.
 Interoperable Object Reference (IOR):
 Interface Definition Language (IDL): é uma linguagem utilizada para descrever as
interfaces das implementações dos objetos na rede (similar ao WSDL).
Webservices: são componentes de aplicativos baseados em xml, autocontidos e autodescritivos, que
se comunicam usando protocolos abertos. Podem ser descobertos com UDDI e ser utilizados por
outras aplicações. São autocontidos por que não necessitam de outros componentes para existir. São
autodescritivos por que não necessitam informações externas para expor suas funcionalidades. É
uma interface que descreve uma coleção de operações que são acessíveis pela rede através de
mensagens XML padronizadas. Respostas podem ser síncronas ou assíncronas. É essencialmente a
interoperabilidade entre programas e aplicações. São componentes de software com baixo fator de
acoplamento. A disponibilização de um serviço ocorre por meio de um contrato, que é uma
interface que disponibiliza suas funcionalidades. Possuem granularidade grossa, provendo uma
maneira natural de definir serviços que acessam a quantidade correta de lógica de negócio.
 Primeira geração: composta por um núcleo de tecnologias e especificações abertas:
WSDL, XSD, SOAP, UDDI e o WS-I.
 Segurança geração: uma das maiores lacunas da primeira geração residia na segurança em
nível de mensagem, transações entre serviços e mensageria confiável, surgiram, então,
diversas extensões e especificações para fornecer um conjunto sofisticado de componentes
construídos sobre os web services de primeira geração. Foram chamados de WS-, que é
composto por diversas especificações:
o WS-Security: define como anexar uma assinatura digital, usar criptografia e usar
tokens de segurança em mensagens soap.
o WS-Policy: define o idioma utilizado para descrever limitações de segurança e a
política de intermediários ou nós de extremidade.
o WS-Trust: define uma estrutura para modelos confiáveis para estabelecer a
confiança entre serviços web.
o WS-Privacy: define um modelo de como expressar um política de privacidade para
um serviço web e um solicitante.
o WS-SecureConversation: define como trocar e estabelecer um contexto
assegurado, que deriva de chaves de sessão entre os serviços web.
o WS-Authorization: define as políticas de autorização para um serviço web.

Webservices envolve basicamente três participantes: provedor de serviço, solicitante de


serviço e agente de serviço (broker), basta lembrar do modelo arquitetônico find-bind-
execute.

Vantagens de utilizar web services:


 Permite utilizar as regras de negócio através da rede.
 Baixo custo de comunicação.
 Conecta aplicações de diferentes fornecedores.
 Protocolo padronizado (SOAP, WSDL, UDDI).
 Permite publicação automática (UDDI).
SOAP x WSDL x UDDI:
 SOAP: baseado em XML, define uma organização para troca estruturada de dados entre
web services.
 WSDL: baseado em XML, define como as interfaces dos web services podem ser
representadas.
 UDDI: baseado em XML, trata-se de um padrão de descobrimento que define como as
informações podem ser organizadas.

Simple object accesss protocol (SOAP): é um protocolo projetado para invocar aplicações remotas
em um ambiente independente de plataforma, linguagem de programação, entre outros. É um
padrão aceito para se utilizar com web services, mas não o único. Pretende garantir a
interoperabilidade e intercomunicação entre diferentes sistemas, através de uma linguagem (XML)
e de um mecanismo de transporte (HTTP). HTTP é o protocolo mais utilizado, mas não é
obrigatório utilizar ele. SOAP foi desenhado para encapsular e transportar chamadas RPC.
Elementos filhos imediatos do cabeçalho são chamados blocos de cabeçalho. Os blocos de
cabeçalhos podem ser processados por nós intermediários SOAP e pelo nó final SOAP. Cada nó
geralmente é projetado para processar determinados blocos e cada bloco é processado por nós
específicos. SOAP é um protocolo stateless.
 O que é:
o Uma das formas de comunicação para encapsular dados transferidos no formato
XML para web services.
o Um formato baseado em XML para intercambio de mensagens.
o Um formato para envio e recebimento de mensagens independentemente de
plataforma e tecnologia.
o Um protocolo que define uma organização para a troca estruturada de dados entre
web services.
 Elementos:
o Envelope (Envelope): elemento raiz do documento XML, identifica o documento
XML como uma mensagem SOAP. Funciona como um recipiente que contem os
demais elementos. Possui dois atributos:
 namespace: define o envelope como um envelope SOAP.
 encodingStyle: define os tipos de dados utilizados em um documento.
Obrigatório.
o Cabeçalho (Header): carrega informações adicionais especificas para a aplicação,
como autentição, autorização, pagamento, etc. Pode especificar assinatura digital e
podem ser definidos vários cabeçalhos. Ele é opcional, mas caso seja utilizado deve
ser o primeiro elemento do envelope. Ele possui três atributos:
 mustUnderstand
 actor
 encodinStyle
o Corpo (Body): contém o payload, a mensagem SOAP. Trata-se de um elemento
obrigatório que é capaz de empacotar chamadas RPC, reportar erros, enviar
operações UDDI, entre outros. Pode conter um elemento opcional fault, usado para
carregar mensagens de status e mensagens de erros retornadas pelos nós.

Web services description language (WSDL): linguagem baseada em XML para descrever um web
service e deve definir todas as suas interfaces, operações, métodos, esquemas de codificação, portas
de comunicação, protocolos, formatos de mensagens, entre outros. Um documento WSDL define
um XML Schema (XSD) para descrever um web service. O web service, quando recebe esta
mensagem, valida-a conforme as informações contidas no documento WSDL.
 WSDL possui um elemento raiz chamado:
 Description: trata-se de um contêiner de duas categorias de alto nível:
o WSDL 2.0: formado pelos componentes:
 Interface: descreve sequencias de mensagens que um serviço envia e/ou
recebe. Ele o faz agrupando mensagens em operações. É o antigo
portType.
 Binding: descreve o formato de mensagens e protocolos de transmissão
que podem ser usados para definir um endpoint. Define detalhes de
implementação necessários para acessar um serviço.
 Service: descreve um conjuntode endpoints em uma implementação
particular do serviço que é fornecido. Endpoints são lugares alternativos
em que serviços são fornecidos.

Esses três componentes são de alto nível e também são elementos. Há outros
dois elementos:
 <types>: define tipos de dados que serão utilizados nas
mensagens e operações.
 <operations>: se encontra dentro do elemento interface e
descreve as ações suportadas por um serviço.
o Type System: formado pelos componentes:
 Element declaration: é um conjunto de declarações de elementos, como
definido por um XML Schema.
 Type definition: é um conjunto de definições de tipos de dados, ele é
obrigatório.
 Perspectivas WSDL:
o Abstrata: trata da interface do serviço. Descreve o que o serviço faz, suas
operações, suas entradas, suas saídas, suas mensagens fault, entre outros. Mas,
não diz como o serviço faz o seu trabalho nem mesmo como acessar esse serviço.
o Concreta: trata da implementação do serviço. Ela descreve como realizará o
serviço, protocolos de comunicação, codificação de dados, localização, portas,
endereço d rede, etc. Contém a perspectiva abstrata e adiciona informações sobre
como o serviço se comunicará e quem pode alcançá-lo.
 Tipos de operações:
o One-way: pode receber uma mensagem, mas não retornará uma resposta.
o Request-response: pode receber uma requisição e retornará uma resposta.
o Solicit-response: pode enviar uma requisição e esperará por uma resposta.
o Notification: pode enviar uma mensagem, mas não esperara uma resposta.

Universal description discovery and integration (UDDI): é uma especificação técnica para
descrever, descobrir e integrar web services. Ele contém informações genéricas sobre a organização
que o detém e informações básicas sobre os serviços. Ele descobre serviços por meio de registros,
que são repositórios logicamente centralizados e fisicamente distribuídos que contém documentos
descritores dos dados do negócio. As informações capturadas no contexto UDDI são classificadas
em três categorias principais:
 Páginas brancas: contém informações gerais sobre a organização que está oferecendo o
serviço. Utilizando essas informações, é possível encontrar algum serviço sobre o qual já se
pode conhecer algumas informações. Há também informações de contato de negócio.
 Páginas amarelas: contém uma classificação do serviço ou negócio disponíveis baseado em
taxonomias padronizadas. Dessa forma pode haver várias páginas amarelas associadas a
uma página branca. Elas fornecem mais detalhes sobre a empresa.
 Páginas verdes: contém informações técnicas sobre como acessar um web service. São
utilizadas para indicar os serviços por cada negócio incluindo todas as informações técnicas
envolvidas na interação com o serviço.
UDDI fornece duas interfaces importantes:
 Publisher interface: define 16 operações para que um provedor de serviços possa gerenciar
e publicar informações sobre um determinado serviço web.
 Inquiry interface: define 10 operações de busca de registro e informações especificas de
registros.
UDDI é composto por uma estrutura hierárquica formada por:
 Entidade de negócio (Business entity): representa o provedor de web services. Contém
informações sobre a organização, incluindo informações de contato, categorias de indústria,
identificadores de negócio e uma lista de serviços fornecidos.
 Serviço de negócio (Business service): representa um web service individual fornecido por
uma entidade de negócio, define tipo de serviço, conexão, categorias, entre outros.
 Template de ligação (Bindng template): é um conjunto de descrições técnicas dos web
services representados por uma estrutura de serviços de negócio. Ele indica, por exemplo,
como se conecta ao serviço.
 tModel: representa um modelo técnico, uma maneira de descrever os vários negócios,
serviços, estruturas de template e informações externas armazenados dentro de um registro
UDDI.
** não confunda WSDL não fica efetivamente no UDDI, mas lá existem referências para ele. **

WS-Secutiry (WSS): utiliza diversos padrões de segurança pré existentes. Ele agrupa um conjunto
de especificações em um framework a ser embutido em uma mensagem SOAP. É utilizado para
estender os mecanismos do protocolo SOAP para fornecer segurança (confidencialidade,
integridade e não repudio) fim-a-fim. O motivo de porque não utilizar HTTPS é que não garante
segurança fim-a-fim. WSS define um header SOAP para carregar dados relacionados a segurança.
o WS-Privacy: determinará de que forma os web services serão adotados e implementados.
o WS-Policty: define como os recursos e restrições das normas de segurança poderão ser
expressos.
o WS-Trust: descreve um modelo para que se obtenha um relacionamento de confiança, tanto
direto, quanto por meio de agentes.

Representational State Transfer (REST): REST é diferente de SOA, SOA é uma arquitetura e REST
é um estilo arqutetural. REST é um estilo arquitetural para construir sistemas fracamente acoplados.
É possível que uma aplicação RESTful seja construída utilizando qualquer infraestrutura de rede ou
protocolo de transporte. Um recurso é qualquer coisa que pode ser acessada ou manipulada. Os
recursos são tipicamente relacionados com outros recursos. É também possível que recursos sejam
agrupados em conjuntos. URI trata-se do Uniform Resource Identifier, que nada mais é do que uma
string de caracteres utilizada para identificar unicamente um recurso. URL trata-se de uma URI que,
além de identificar um recurso da web, também é capaz de localizá-lo. No REST todo recurso
contém um identificador. Os recursos devolvidos aos clientes podem ter diversas representações,
tais como: HTML, JSON, XML, YAML, TXT, ou outros formatos dependendo da requisição do
cliente. Em sua implementação tradicional, desenvolvem-se web services utilizando protocolo
SOAP e, em geral, com a linguagem XML, no Java essa especificação foi denominada JAX-WS.
Em sua implementação alternativa, desenvolvem-se web services utilizando os métodos do
protocolo HTTP e, em geral, com linguagem JSON, no Java essa especificação foi denominada
JAX-RS.

Restrições ou princípios REST: aplicações que sigam essas restrições são consideradas aplicações
RESTful.
Restrição ou Descrição
principio
Cliente/servidor Responsabilidade devem ser separadas entre clientes e servidores. Isso
permite que os componentes do cliente e do servidor evoluam de forma
independente e permite que o sistema seja escapável.
Stateless A comunicação entre cliente e servidor deve ser stateless. O servidor na
precisa lembrar o estado do cliente. Os clientes devem incluir todas as
informações necessárias na requisição para que o servidor possa entende-
la e processá-la.
Sistema em camadas Múltiplas camadas como firewall, gateways e proxies podem existir entre
o cliente e o servidor. As camadas podem ser adicionas, modificadas,
removidas ou reordenadas de forma transparente. Para melhorar a
escalabilidade deve ser fácil manipular as camadas.
Cachê Respostas do servidor devem ser declaradas como cachable ou
noncachable. Isso permite que o cliente ou seus componentes
intermediários armazenem em cachê respostas e reutilizem-nas para
pedidos posteriores.
Interface uniforme Todas as interações entre cliente, servidor e componentes intermediários
são baseadas na uniformidade de suas interfaces. É basicamente um
contrato entre cliente e servidor. São regras para fazer um componente o
mais genérico possível, tornando-o muito mais fácil de ser refatorado e
melhorado.
Código sob demanda Esse principio é opcional, na medida que não faz parte da arquitetura em
si. Ele trata da possibilidade de clientes poderem estender suas
funcionalidades através do download e execução do código sob demanda.
Exemplo é scripts javascript.
SOAP x REST:
SOAP REST
É um protocolo de comunicação. É um estilo arquitetural ou uma técnica de
engenharia de software.
Utiliza um envelope (cabeçalho+corpo) enviado Utiliza recursos oferecidos nativamente pelo
por http para transmitir dados. http, mas pode usar outros protocolos.
Suporta somente o formato XML. Suporta XML, JSON, YAML, TXT, etc.
Apresenta desempenho e escalabilidade menor, Apresenta desempenho e escalabilidade maior,
devido ao alto overhead. devido ao baixo overhead.
Permite fazer caching. Não permite fazer caching.
Javascript pode chamar SOAP, mas é difícil de Javascript pode facilmente chamar REST.
implementar.

You might also like