Professional Documents
Culture Documents
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.
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.
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.
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 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.
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.
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.
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 **
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.
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.
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
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.
*** 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. ***
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 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.
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.
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.
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 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.
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.
*** 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.
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:
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 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.***
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 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.
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.
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.
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.
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.
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.