Aula 09 Apostila

By @kakashi_copiador
Aula 07
Caixa Econômica Federal (CEF) (Técnico
Bancário-Tecnologia) Passo Estratégico
de Informática - 2023 (Pré-Edital)
Autor:
Thiago Rodrigues Cavalcanti
26 de Janeiro de 2023
https://t.me/kakashi_copiador
. Túlio Lages
Aula 00 Rodrigues Cavalcanti
Thiago
Aula 07
ARQUITETURAS DE SOFTWARE: ARQUITETURA EM

CAMADAS, ARQUITETURA MVC, ARQUITETURA
ORIENTADA A SERVIÇOS; MÉTRICAS E ESTIMATIVAS
DE SOFTWARE; ANÁLISE POR PONTOS DE FUNÇÃO:
CONCEITOS BÁSICOS E APLICAÇÕES; ENGENHARIA
DE REQUISITOS: ELICITAÇÃO DE REQUISITOS,
IDENTIFICAÇÃO DAS FONTES DE INFORMAÇÃO,
TÉCNICAS DE ELICITAÇÃO, TÉCNICAS DE
MODELAGEM, ANÁLISE DE REQUISITOS, VALIDAÇÃO
E VERIFICAÇÃO, GERÊNCIA DE REQUISITOS,
FERRAMENTAS. NUVEM PÚBLICA E PRIVADA.
DEVOPS
Sumário
Análise Estatística ........................................................................................................................................ 2
Roteiro de revisão e pontos do assunto que merecem destaque .................................................................. 4
Arquitetura de Software ........................................................................................................................... 5
Conceitos gerais .................................................................................................................................... 5
Acoplamento e coesão .......................................................................................................................... 5
Arquitetura em camadas....................................................................................................................... 6
Arquitetura Model View Controller (MVC) ............................................................................................ 8
Arquitetura distribuída .......................................................................................................................... 9
Conceitos gerais sobre arquitetura orientada a serviço .......................................................................... 10
Caixa Econômica Federal (CEF) (Técnico Bancário-Tecnologia) Passo Estratégico de Informática - 2023 (Pré-Edital)
www.estrategiaconcursos.com.br
. Túlio Lages
Thiago
Aula 07
UDDI (Universal, Discovery and Integration)....................................................................................... 11
WSDL (Web Services Description Language) ...................................................................................... 12
SOAP (Simple Object Acess Protocol) ................................................................................................ 13
REST (Representational State Transfer) ............................................................................................. 14
Análise de ponto de função IFPUG ......................................................................................................... 18
Contagem de pontos de função IFPUG ............................................................................................... 18
Análise de ponto de função NESMA ....................................................................................................... 22
Contagem de ponto de função NESMA .............................................................................................. 23
Engenharia de Requisitos ....................................................................................................................... 23
Conceitos Básicos ............................................................................................................................... 23
Fases do processo de engenharia de requisitos ................................................................................... 24
Classificação de Requisito Quanto à Funcionalidade .......................................................................... 28
Aposta estratégica ..................................................................................................................................... 29
Questões estratégicas ................................................................................................................................ 31
Questionário de revisão e aperfeiçoamento ............................................................................................... 31
Perguntas ............................................................................................................................................... 32
Perguntas com respostas ........................................................................................................................ 32
ANÁLISE ESTATÍSTICA
Inicialmente, convém destacar os percentuais de incidência de todos os assuntos previstos no nosso curso
– quanto maior o percentual de cobrança de um dado assunto, maior sua importância:
Grau de incidência em
Assunto concursos similares
. Túlio Lages
Thiago
Aula 07
CESGRANRIO
4 - Engenharia de software: Processos de software: Processo Unificado
(UP): conceitos gerais, disciplinas, fases, papéis, atividades e artefatos;
Métodos ágeis (Scrum, XP, FDD, Lean, Kanban, SAFe, UX); Análise e 14,85%
projeto orientados a objetos; A Linguagem UML: modelos e diagramas;
Padrões de projeto;
6 - Linguagens de programação: noções sobre linguagens de programação;
Linguagens Java SE; AngularJS; Angular; TypeScript 4.X; Javascript; Python
13,37%
3.9.X (bibliotecas Pandas, NumPy, SciPy, Matplotlib e Scikit-learn); Scala;
R; Kotlin; Objective-C; .Net; Flutter; Swift.
Linguagem SQL; 10,40%
5 - Estrutura de dados e algoritmos: Busca sequencial e busca binária sobre
arrays; Ordenação (métodos da bolha, ordenação por seleção, ordenação 9,41%
por inserção); Lista encadeada; Pilha; Fila; Noções de árvore binária.
3 - Redes de computadores: Fundamentos de comunicação de dados; Meios
físicos de transmissão; Elementos de interconexão de redes de
computadores (gateways, switches, roteadores); Estações e servidores.
8,91%
Tecnologias de redes locais e de longa distância; Arquiteturas, protocolos e
serviços de redes de comunicação; Arquitetura TCP/IP; Arquitetura cliente
servidor; Conceitos de Internet e Intranet.
1 - Organização e arquitetura de computadores: Arquitetura básica de um
computador: CPU e hierarquia de memória; Armazenamento e
representação de dados: base binária e complemento a dois, ponto
6,93%
flutuante e caracteres; Armazenamento e representação de instruções;
Modos de endereçamento; Conjunto típico de instruções de uma CPU;
Subsistema de entrada/saída e dispositivos de armazenamento secundário.
Arquiteturas de software: arquitetura em camadas, arquitetura MVC,
arquitetura orientada a serviços; Métricas e estimativas de software;
Análise por pontos de função: conceitos básicos e aplicações; Engenharia
de requisitos: elicitação de requisitos, identificação das fontes de 6,44%
informação, técnicas de elicitação, técnicas de modelagem, análise de
requisitos, validação e verificação, gerência de requisitos, ferramentas.
Nuvem pública e privada. DevOps.
10 - Bancos de dados: Modelagem conceitual de dados: a abordagem
entidade-relacionamento; Modelo relacional de dados (conceitos básicos e
5,45%
normalização); Conceitos de banco de dados e sistemas gerenciadores de
bancos de dados (SGBD);
Data Warehouse: modelagem conceitual para data warehouses, dados
5,45%
multidimensionais;
2 - Sistemas Operacionais: Funções e estrutura de um sistema operacional;
Processos: conceitos básicos, comunicação, sincronização e 4,95%
escalonamento; Gerência de memória: partições fixas e variáveis,
. Túlio Lages
Thiago
Aula 07
realocação, memória virtual, swapping, sistemas de arquivos; Windows 10

(32-64 bits).
7 - Desenvolvimento de software para a Web: sistemas distribuídos e
microserviços; Arquitetura e padrões de projeto Java EE8; Servlets; JSF;
2,97%
JSP; Ajax; Interoperabilidade de sistemas; SOA e Web Services; Padrões
HTML 4.01, XHTML 1.0, XML, XSLT, UDDI, WSDL e SOAP.
8 - Teste de software: Controle da qualidade estático: revisão, inspeção,
medição estática, análise estática; Princípios e técnicas de teste de
software: teste de unidade, teste de integração, teste de regressão, teste
alfa, teste beta, teste de segurança, teste de aceitação e de aprovação; 2,48%
Desenvolvimento dirigido por testes. 9 - Gerência de configuração:
Conceitos e práticas; Uso de ferramentas de gerência de configuração;
Controle de defeitos: conceitos e práticas.
13 - Qualidade de software: CMMI/MPS-BR: Conceitos básicos e objetivos;
1,98%
Disciplinas e formas de representação; Níveis de capacidade e maturidade.
11 - Portais corporativos: Arquitetura da informação, portlets e RSS;
Ferramentas de Gestão de Conteúdos; Modelo de Acessibilidade do
1,98%
Governo Eletrônico. 14 - Segurança da Informação: Segurança cibernética:
Resolução CMN nº 4893, de 26 de fevereiro de 2021.
2 - Sistemas Operacionais: Funções e estrutura de um sistema operacional;
Processos: conceitos básicos, comunicação, sincronização e
escalonamento; Gerência de memória: partições fixas e variáveis, 1,49%
realocação, memória virtual, swapping, sistemas de arquivos; ambiente
Linux (SUSE SLES 15 SP2).
COBIT; Noções sobre gestão de segurança da informação: normas NBR
1,49%
ISO/IEC 27001 e 27002.
Big data: Fundamentos, técnicas de preparação e apresentação de dados. 0,99%
12 - Gestão e governança de TI: ITIL; 0,50%
ROTEIRO DE REVISÃO E PONTOS DO ASSUNTO QUE

MERECEM DESTAQUE
A ideia desta seção é apresentar um roteiro para que você realize uma revisão completa do assunto e, ao mesmo
tempo, destacar aspectos do conteúdo que merecem atenção.
Para revisar e ficar bem preparado no assunto, você precisa, basicamente, seguir os passos a seguir:
. Túlio Lages
Thiago
Aula 07
Arquitetura de Software
Conceitos gerais
Basicamente, a arquitetura de software é uma forma estruturada de construir os componentes de um

software de maneira integrada. Logo, uma arquitetura bem projetada deve atender os requisitos funcionais
e os não-funcionais e ser flexível para customizações e alterações.
Como sabemos o passo inicial para elaboração de qualquer arquitetura é entender a abstração do software,
ou seja, para qual finalidade o software está sendo criado. Pensando nisso, os componentes de software
começaram a ser reunidos em camadas, a fim de facilitar a abstração das funcionalidades do software.
A partir dessa abordagem, cada camada agrupa de forma lógica os componentes de baixo nível e os
componentes de alto nível, provendo assim o conceito de coesão. Importante esclarecer nesse momento
que para fins didáticos vamos explorar a concepção das arquiteturas sem abordar uma finalidade específica.
A divisão por camadas foi a abstração pioneira na construção de arquiteturas de software, tendo em vista
que lá atrás, era necessário organizar a casa, ou seja, separar as responsabilidades e os componentes de
software, promovendo assim o reuso, a extensibilidade, o encapsulamento, a decomposição e a separação
de responsabilidades entre camadas.
Acoplamento e coesão
Acoplamento e coesão são dois conceitos fundamentais para a compreensão de qualquer arquitetura de
software. Podemos definir que uma arquitetura de software eficiente deve ter componentes com baixo
acoplamento e alta coesão.
• Acoplamento – O acoplamento diz respeito ao nível de dependência entre os componentes de um

software.
• Coesão – A coesão diz respeito ao nível de responsabilidade de um componente em relação ao
outro.
É importante tem baixo acoplamento porque os componentes vão depender pouco uns dos outros, isso
possibilita que um dado componente seja modificado, por exemplo e outro componente não seja afetado.
Já a alta coesão é fundamental porque indica que os componentes têm funções (responsabilidades)
definidas, o que colabora com o reuso dos componentes de software.
Podemos perceber isso com maior facilidade no paradigma orientado a objeto, onde a coesão de
componentes, faz com que as classes encapsulem os atributos e os métodos que estão relacionados entre
si.
Quando pensamos em sistemas fortemente acoplados, normalmente estamos falando de um alto grau de
ligação entre classes, métodos, etc. Dentro de um sistema fortemente acoplado é difícil realizar
. Túlio Lages
Thiago
Aula 07
customizações, melhorias ou alterações, porque tudo está muito junto (ligado), assim devemos evitar
promover o acoplamento.
Arquitetura em camadas
Por mais estranho que possa parecer, no início do desenvolvimento de software, tudo era desenvolvido em
uma única camada, inclusive o banco de dados e a interface com o usuário, pense nisso: o back-end, o front-
end, o banco de dados, tudo no mesmo lugar.
Foi então que chegou a arquitetura em camadas, com o objetivo de organizar o desenvolvimento de
software. Basicamente surgiram duas camadas básicas (cliente e servidor), que permanecem até hoje e
foram responsáveis por apoiar o surgimento da internet.
A arquitetura de duas camadas (cliente e servidor) é composta por servidores que oferecem serviços e por
clientes, que solicitam e consomem serviços, normalmente através de uma rede que permite o tráfego das
requisições dos clientes para os servidores. Teremos então:
Servidores: que oferecem serviços para outros subsistemas (Ex: Servidores de Impressão, Servidores de
Arquivos, Servidor de Compilação, etc).
Clientes: que solicita os serviços oferecidos pelos servidores. Geralmente são independentes, podendo ser
executados simultaneamente.
Rede: que permite aos clientes acessarem esses serviços. Quando clientes e servidores podem ser
executados em uma única máquina, não são necessários.
Importante: Os clientes talvez precisem saber os nomes dos servidores e os serviços que eles fornecem, mas
os servidores não precisam saber sobre os clientes. Eles acessam os serviços pelo servidor por meio de
chamadas remotas de procedimento usando um protocolo Request-Reply (Ex: HTTP).
Em resumo então: um cliente faz uma requisição a um servidor e espera uma resposta.
Cliente 1 Cliente 2 Cliente 3
Internet
Servidores A, B, C, N
Quando pensamos no desenvolvimento de aplicações web, fica mais fácil entender o funcionamento da
arquitetura cliente/servidor. A vantagem mais importante de um modelo cliente-servidor é que ele é uma
arquitetura distribuída.
. Túlio Lages
Thiago
Aula 07
Temos dois tipos de implementação da arquitetura cliente/servidor: cliente-magro e cliente-gordo. No

Modelo Cliente-Magro, todo processamento da aplicação e o gerenciamento de dados é realizado no
servidor. O cliente é responsável somente por executar o software de apresentação.
No Modelo Cliente-Gordo, o servidor somente é responsável pelo gerenciamento de dados e o software do

cliente implementa a lógica da aplicação e as interações com os usuários.
Se comparamos a arquitetura de camada única, com as arquiteturas de duas camadas, percebemos que
temos a separação da interface do usuário da camada e o gerenciamento de dados. Isso é uma verdade tão
latente que até hoje a maioria das aplicações web se baseiam na arquitetura cliente/servidor de duas
camadas.
Porém tudo na vida evolui, surgiu então a arquitetura em três camadas: apresentação, lógica de negócio e
acesso a dados. Vejamos:
Camada de apresentação: possui classes que contêm funcionalidades para visualização dos dados pelos
usuários. Ela tem o objetivo de exibir informações ao usuário e traduzir ações do usuário em requisições às
demais partes dos sistemas. O amplo uso da internet tornou as interfaces com base na web crescentemente
populares.
Camada de Negócio: também chamada Camada Lógica ou de Aplicação, possui classes que implementam
as regras de negócio no qual o sistema será implantado. Ela realiza cálculos com base nos dados
armazenados ou nos dados de entrada, decidindo que parte da camada de acesso de ser ativada com base
em requisições provenientes da camada de apresentação.
Camada de Dados: possui classes que se comunicam com outros sistemas para realizar tarefas ou adquirir
informações para o sistema. Tipicamente, essa camada é implementada utilizando algum mecanismo de
armazenamento persistente. Pode haver uma subcamada dentro desta camada chamada Camada de
Persistência ou Camada de Acesso.
A utilização da arquitetura em três camadas permite a otimização da transferência de informações entre o

servidor web e o de banco de dados. Se pensarmos por exemplo em um sistema bancário online, teremos
uma arquitetura em três camadas, vejamos:
Temos um banco de dados com os dados dos clientes e um servidor web com serviços das aplicações
bancárias e por fim uma interface do usuário, com a apresentação dos dados para o cliente.
Por fim, surgiu a arquitetura cliente/servidor com quatro camadas. Neste caso, retiramos a apresentação do
cliente e colocamos no servidor web. Assim, não havia necessidade de instalar o aplicativo na máquina do
cliente, o acesso era feito por meio de um navegador. As camadas eram: Dados, Aplicação, Apresentação e
Cliente (Navegador Web).
Exemplo: Um usuário realiza uma requisição através de um navegador web (camada cliente), essa
requisição vai para um servidor web (camada de apresentação), nesse servidor web a requisição é
. Túlio Lages
Thiago
Aula 07
processada conforme a regra de negócio do servidor de aplicação (camada de aplicação), que por fim,
realiza buscas de dados em um banco de dados (camada de dados).
Arquitetura Model View Controller (MVC)
A arquitetura MVC é um padrão arquitetural interativo que serve para implementação de interfaces com o
usuário. No MVC dividimos em três partes ou três camadas a representação das informações que serão
apresentadas para o usuário.
Basicamente, estamos separando responsabilidades nas camadas: Modelo, Visão e Controle. O MVC
promove a estrita separação de responsabilidade entre componentes de uma interface gráfica onde temos
componentes responsáveis pela manutenção do estado da aplicação, denominado de Modelo, pela exibição
de parte deste modelo para o usuário, ao que chamamos de Visão e pela coordenação entre atualizações no
modelo e interações com o usuário, feita através do Controlador. Temos então por definição:
Camada de Modelo: Camada responsável pela representação dos dados, provendo meios de acesso
(leitura/escrita). Ela gerencia não só os dados, mas também os comportamentos fundamentais da
aplicação, representados por regras de negócio.
Camada de Controle: Camada responsável por receber todas as requisições do usuário. Ele é capaz de
enviar comandos para o modelo atualizar o seu estado. Ele também pode enviar comandos para a respectiva
visão para alterar a apresentação da visão do modelo. Um controlador define o comportamento da
aplicação, interpretando as ações do usuário e mapeando-as em chamadas do modelo.
Camada de Visão: Camada responsável pela interação com o usuário, sendo responsável apenas pela
exibição de dados. Trata-se de uma representação visual do modelo. Ela permite apresentar, de diversas
formas diferentes, os dados para o usuário.
Importante: Na Arquitetura em Três-Camadas, a comunicação entre camadas é rigidamente linear, a

Camada de Apresentação e a Camada de Dados só se conversam bidirecionalmente com a Camada de
Lógica, mas nunca entre si. Já no MVC, a comunicação é triangular, ou seja, existem diversas
implementações diferentes dessa arquitetura. Exemplo: no MVC a Visão pode tanto gerar eventos a serem
tratados pelo Controle quanto obter os dados a serem exibidos diretamente do modelo. Observe o
funcionamento da arquitetura MVC na figura abaixo:
. Túlio Lages
Thiago
Aula 07
Arquitetura distribuída
Apesar de parecer complexo, este tópico é bem simples. Desde os anos 80, os sistemas de computação têm
passado por intensas evoluções, principalmente do ponto de vista da escalabilidade.
Neste cenário surge a arquitetura distribuída, que nada mais é que plataformas compostas por um conjunto
de computadores independentes que se apresenta a seus usuários como um sistema único e coerente. Logo,
a arquitetura distribuída simplesmente distribui o poder de processamento de forma descentralizada entre
servidores. Os ganhos são: responsividade, escalabilidade, redundância, disponibilidade,
compartilhamento de recursos computacionais, controle e envolvimento do usuário, entre outros.
Importante: Os computadores em um sistema distribuído podem estar fisicamente próximos e conectados

por uma rede local ou podem estar geograficamente distantes e conectados por uma rede remota.
Um exemplo comum de sistema distribuída é quando temos processos sendo executados

concorrentemente em máquinas diferentes dentro de uma rede. As desvantagens dos sistemas distribuídos
são: controlar o acesso concorrente a dados e a recursos compartilhados; evitar que falhas de máquinas ou
da rede comprometam o funcionamento do sistema; garantir a segurança do sistema e o sigilo dos dados
trocados entre máquinas; lidar com a heterogeneidade do ambiente; entre outros.
No contexto da arquitetura de sistemas distribuídos, vale a pena apresentar o conceito de middleware, que
nada mais é que uma camada de software que permite que elementos de aplicações interoperem através
de uma rede.
. Túlio Lages
Thiago
Aula 07
O middleware oculta do desenvolvedor da aplicação a complexidade do processo de transporte da rede e é

capaz de mascarar diferenças existentes entre sistemas operacionais, plataformas de hardware e
protocolos de rede.
Conceitos gerais sobre arquitetura orientada a serviço
Essa era uma das perguntas que começaram a surgir quando começamos a trabalhar com sistemas
distribuídos que se comunicavam com outros sistemas distribuídos e com outros sistemas distribuídos e
assim por diante, em escala mundial através da internet. Paralelo a isso, surge o conceito de orientação a
serviço. Podemos definir SOA (Service Oriented Architecture) como sendo um paradigma que trabalha com
recursos distribuídos orientados como serviços.
Para ficar mais claro, na prática temos aplicações e suas respectivas funcionalidades, essas funcionalidades
são projetadas como “serviços fracamente acoplados”, ou seja, em SOA trabalhamos com o conceito de
independência entre os serviços.
A razão pela qual SOA se tornou um passo significativo na evolução tecnológica, foi a mudança de
paradigma, ou seja, tivemos um momento em que tudo era pensador de forma estruturada (paradigma
estruturado), depois orientado a objeto (paradigma orientado a objeto), mas estamos agora no momento
de pensar orientado a serviço, exemplo disso é o surgimento de conceitos como a Cloud Computing, com
seus modelos (SaaS, PaaS e IaaS).
Hoje as grandes corporações pensam tecnologia como meio de prover ganhos para o negócio e dentro
desse contexto um dos principais desafios está na integração entre diferentes tecnologias, com diferentes
regras de negócio em diferentes plataformas. Antigamente, conforme as demandas apareciam a área de TI
se portava de forma reativa, o que gerava um forte acoplamento, era um eterno apaga incêndio, e toda vez
que algo novo surgia, um novo desenho arquitetural era criado, no fim tínhamos diversos problemas de
interoperabilidade, integração e muita gambiarra.
Então surgiu a seguinte ideia: Porque não colocamos tudo orientado a serviço, vamos modelar serviços e
tudo será melhor! Porém como SOA é um paradigma não tem como do dia para a noite, colocar tudo que
temos de desenvolvimento de software em orientação a serviço, até porque mudar um paradigma sempre
é muito caro e complicado! Outra informação importante é que SOA é independente de tecnologia, tendo
em vista que se trata de um paradigma.
Um componente fundamental no SOA é o Service Bus ou ESB (Entreprise Service Bus) ou Barramento de
serviço. A comunicação em um barramento de serviço (ESB) é realizada principalmente através de XML
(eXtensible Markup Language) e Web Services. O ESB representa um ponto centralizador da integração
entre as aplicações que necessitam se comunicar.
Para que tudo funcione como deve funcionar, precisamos então orquestrar os serviços, ou seja, coordenar
o acesso e o consumo dos serviços através do barramento, para isso utilizamos o conceito de governança
SOA.
. Túlio Lages
Thiago
Aula 07
No barramento (ESB) para que a orquestação dos serviços ocorra utilizamos uma linguagem chamada BPEL
(Business Process Execution Language) e quando desejamos modelar os serviços, normalmente utilizamos
dotação BPMN (Business Process Model and Notation).
Temos então o seguinte modelo para o funcionamento do paradigma orientado a serviço:
Temos aqui a estrutura (Encontra-Consolida-Regista), onde o provedor de serviço vai publicar os serviços,
gerando registros no padrão UDDI (Universal, Discovery and Integration) através da específicação WSDL
(Web Services Description Language).
O registro funciona como um base da dados de informações sobre os serviços. Quando alguém quer
consumir algum serviço, ele busca o registro do serviço (UDDI) a fim de verificar a especificação do serviço
e localiza-lo e essa comunicação ocorre através do protocolo SOAP (Simple Object Access Protocol).
Atenção pessoal, temos então três colunas principais para entender SOA e que possibilitam seu respectivo
funcionamento:
UDDI Responsável pelo descobrimento que define as informações sobre os serviços.

WSDL Responsável pela interface que representa os serviços.
SOAP Protocolo responsável pela comunicação e troca de dados.
UDDI (Universal, Discovery and Integration)
O UDDI é o local responsável pela descrição e especificação de web services, a fim de disponibiliza-lo para
consulta e acesso. No UDDI temos informação sobre os serviços disponibilizados através do registrios, que
são os repositórios com os documentos que descrevem os dados de negócio.
Temos três categorias principais em um UDDI: Páginas Brancas, Páginas Verdes e Páginas Amarelas.
Páginas Brancas Páginas Verdes Páginas Amarelas
. Túlio Lages
Thiago
Aula 07
Nome Informações técnicas de acesso Categoria
Endereço Interface 1.1 WSDL
Descrição Interface 1.2 URI
Tamanho Diretório Modelos
O UDDI se utiliza bastante de web services, tendo em vista que este é responsável por implementar a
disponibilização dos serviços. Temos então que o cadastro é realizado no UDDI, com informações descritas
em XML.
WSDL (Web Services Description Language)
Como eu sei quais parâmetros devo passar quando um web service é consultado? Isso impacta diretamente
no processo da requisição que é realizado, correto? Para isso temos um documento responsável pela
descrição das funcionalidades de um web service.
Os Web Services são responsáveis por definir as interfaces que serão utilizadas, o formato das mensagens
que serão trocadas, os métodos que serão invocados e para isso utilizamos um documento WSDL que
descreve um XML Schema.
No WSDL temos a parte abstrata do serviço e a parte concreta, a parte abstrata possui as definições dos
tipos usados pelo serviço e a parte concreta possui o local e a maneira pela qual os serviços podem ser
acessados. A parte abstrata é utilizada do lado cliente, enquanto a parte concreta é utilizada do lado
servidor.
Quando eu então desejo utilizar um serviço, primeiro preciso enviar uma mensagem para um web service,
que vai me passar a descrição do serviço (WSDL) localizado no UDDI, a fim de passar os tipos de dados
conforme definido no WSDL. Entre os elementos que compôem um web service, podemos destacar:
Elementos Descrição
. Túlio Lages
Thiago
Aula 07
<definition> Descrição sobre schemas e namespaces

<binding> Protocolos de comunicação que serão utilizados
<message> Informações utilizadas para executar operações
<types> Tipos de dados amparados pelo serviço
<portType> Definição de porta para troca de mensagens
SOAP (Simple Object Acess Protocol)
SOAP é utilizado para troca de mensagens e é construído baseado em XML e HTTP. Como o próprio nome
diz SOAP é um protocolo e foi projetado para invocar aplicações remotas via RPC (Remote Procedure Calls)
e hoje utilizamos ele para envio e recebimento de mensagens em Web Services.
A comunicação então é realizada por SOAP, não necessariamente sempre por SOAP, mas hoje o mais
comum é utilizar SOAP. SOAP utiliza linguagem XML e transporte via HTTP para implementar
comunicação.
SOAP é composto pelos seguintes elementos: Envelope, Header e Body. O Envelope é onde está toda a
mensagem e é obrigatório, também chamado elemento raiz do documento XML.
O Header é o cabeçalho, que é responsável por adicionar informações complementares a mensagem,

todavia este elemento não é obrigatório, por fim temos o Body ou o corpo da mensagem que é de fato o
que será transportado para o destino e é obrigatório.
. Túlio Lages
Thiago
Aula 07
REST (Representational State Transfer)
O estilo arquitetural REST surgiu do trabalho de dissertação de doutorado de Roy Fielding. Roy chamou
esse trabalho de Architectural Styles and the Design of Network-based Software Architectures.
O trabalho surgiu no seguinte contexto: Os estilos arquiteturais são utilizados pelos engenheiros de
software para projetar sistemas complexos. Dentro desses estilos nós teremos padrões que são
estruturados de maneira a fortalecer uma determinada arquitetura.
A arquitetura de um sistema, seja ele um sistema web, desktop ou um sistema distribuído, é a estrutura por
de trás do sistema. Essa estrutura é constituída de componentes de software e de propriedades que tem
relacionamento padrão.
Note que a partir daqui podemos prever que vão existir N tipos de sistemas, que terão X tipos de níveis de
abstração, cada um com a sua própria arquitetura e com diferentes níveis de complexidade. Temos então o
que é conhecido como Estilos Arquiteturais que tem o objetivo de abstrair descrições de diversos aspectos
que constituem um sistema.
Exemplo:
. Túlio Lages
Thiago
Aula 07
No estilo arquitetural cliente-servidor nós temos a composição de um servidor que vai fornecer serviços
através de conexões com os clientes ou com o cliente (arquitetura cliente-servidor dedicada). Do outro lado
temos o cliente que é responsável por definir quais serviços vai requisitar ao servidor.
Então aqui temos o servidor aguardando a requisição do cliente, podendo obviamente servir a mais de um
cliente. Logo, temos a separação de responsabilidades. De forma bem simples o servidor é responsável por
processar a requisição e o cliente é responsável por processar o que foi requerido. Ok?
Para compreender o que é REST, é necessário compreender o modelo Cliente-Servidor e sua razão de
existir, perceba então que a abstração de camadas serve para trazer para cada camada uma distribuição de
função, ou seja:
REST (Transferência de Estado Representacional) é um estilo arquitetural hibrido que surgiu da

representação de sistemas de hipermídia distribuídos derivados de outros modelos arquiteturais. Professor
e quais são esses outros modelos arquiteturais?
• Modelo arquitetural Cache
. Túlio Lages
Thiago
Aula 07
• Modelo arquitetural Cliente-Servidor

• Modelo arquitetural Cliente-Servidor sem estado
• Modelo arquitetural Cliente com Cache-Servidor sem estado
Professor preciso conhecer cada um desses modelos? Não. O REST tem uma visão muito voltada para o
modelo Cliente-Servidor. Por isso nós passamos pelo modelo arquitetural cliente-servidor antes de entrar
no REST.
Quando trabalhamos com o modelo cliente-servidor e com a distribuição em camadas temos a

possibilidade de desenvolver a separação de responsabilidades entre os componentes. É exatamente isso
que ocorre no REST, o que faz com que a arquitetura REST tenha condição de suportar requerimentos de
aplicações de múltiplos domínios organizacionais na escala da internet.
Em REST as comunicações não devem depender dos estados controlados pelo servidor, temos então o
estilo cliente/servidor sem estado. E por que isso? Porque a ideia é fazer com que cada requisição feita pelo
cliente sempre, lembre-se: sempre! Tenha todos os atributos para que ela possa ser processada pelo
servidor. Assim, temos a certeza de que toda a informação será conhecida somente pelo cliente.
Vamos entrar então no modelo Cache + Cliente, ou seja, vamos unir o modelo de arquitetura Cache e o
modelo Cliente/Servidor sem estado.
O que você está vendo aqui é a melhora na eficiência da comunicação entre cliente e servidor, sendo que o
REST vai unir característica do modelo arquitetural cache de forma a incorporar o estilo cliente/servidor sem
. Túlio Lages
Thiago
Aula 07
estado. Nasce então, características que fazem com que exista a necessidade de marcação explícita de uma
resposta no âmbito desta ser ou não passível de cache.
Por exemplo: Se for possível que a resposta seja passível de cache, podemos garantir ao cliente que ele
poderá reusar esta resposta futuramente. Temos então a característica de que o cliente pode inserir em
tempo de execução as funcionalidades que ele desejar, através de scripts ou applets.
É daqui que temos um conceito muito familiar, conhecido como Web Services. Porque a maioria das
aplicações que são voltadas para a utilização de REST são orientadas a serviço, ou seja, a idéia é encapsular
serviços através do sistema de camadas e gerar sua comunicação através do protocolo HTTP.
Mas professor nós estamos voltando a falar de SOA? Isso mesmo, perceba que o conhecimento na área de
desenvolvimento web está muito interligado. Separar os assuntos pode te atrapalhar na hora da prova,
porque a banca não tem questões separadas por tema, ela tem questões que abordam muitas das vezes
vários temas juntos.
REST é muito utilizado para o desenvolvimento de serviços web trabalhando de maneira stateless (sem
estado). A implementação dos serviços web implementados com REST são conhecidos como RESTful Web
Services.
Os serviços no REST por sua vez serão identificados pela sua URI e a implementação dos serviços web com
REST são conhecidos como RESTful Web Services. Dentre as operações para mapeamento dos métodos
HTTP através de REST temos:
A título de curiosidade: Em relação a diferença entre o estilo arquitetura REST e a utilização de WS (Web
Services), o REST é mais simples e tem menos overhead e como desvantagem temos a segurança, REST é
. Túlio Lages
Thiago
Aula 07
tão simplificado que chega a ser menos seguro, mas é claro é possível implementar segurança dentro da
arquitetura REST.
Análise de ponto de função IFPUG
Allan Albrecht em 1979 na IBM trabalhava com o conceito de mensuração em produtividade de

desenvolvimento de software por unidade de serviço, dentre um dos principais desafios enfrentados estava
a padronização de uma linguagem de programação adequada para a mensuração, todavia como temos
vários tipos de linguagem de programação, padronizar por linguagem não era um bom caminho a ser
tomado. Foi então que Allan decidiu mensurar o desenvolvimento de software por aspecto funcional
(funcionalidades).
Pensando em funcionalidade, podemos mensurar o desenvolvimento de software através da visão do

usuário sem depender da linguagem de programação que será utilizada, nasceu então os pontos por função
ou pontos de função. De acordo com a difusão da mensuração através de pontos de função, nasceu o grupo
IFPUG (International Fuction Point Users Group) que visa manter o CPM (Counting Practices Manual), que
é o manual utilizado para contagem de pontos de função.
Temos então que a análise de pontos de função (APF) é uma técnica utilizada para analisar e mensurar as
funcionalidades de um software sob o ponto de vista dos requisitos funcionais de usuário, independente de
tecnologia. Sabendo disso, precisamos basicamente entender como medimos funcionalidades através da
métrica de pontos de função (PF). Primeiro precisamos compreender que quando estamos tratando de
desenvolvimento de software no contexto de análise de pontos de função, não estamos querendo mensurar
a complexidade do desenvolvimento, mas sim a complexidade do software.
Contagem de pontos de função IFPUG
Quando mensuramos então a complexidade do software nós utilizamos alguns componentes para medir as
funcionalidades a fim de quantificar funcionalidades do software por complexidade. Utilizamos então:
Componentes Tipo
ALI Arquivo Lógico Interno
AIE Arquivo de Interface Externa
EE Entrada Externa
SE Saída Externa
CE Consulta Externa
Vejamos a conceituação de cada um desses componentes:
Arquivo Lógico Interno (ALI): O ALI representa dados logicamente relacionados que tem a função de
armazenar dados de dentro da fronteira da aplicação.
. Túlio Lages
Thiago
Aula 07
Arquivo de Interface Externa (AIE): O AIE representa dados logicamente relacionados, utilizados para
retorno ou recuperação de dados de uma aplicação, sendo que os dados são armazenados fora da fronteira
da aplicação. Importante destacar que um AIE de uma aplicação é contado como um ALI em uma aplicação
de origem.
Entrada Externa (EE): O EE representa o processamento de um dado de controle recebido de fora da

fronteira da aplicação a fim de manter ALIs ou alterar algum comportamento da aplicação, podendo
provocar uma inclusão, alteração ou exclusão de dados no ALI.
Saída Externa (SE): O SE representa o processamento do envio de dados para fora da fronteira da aplicação
com o objetivo de exibir informações ou criar dados, podendo manter um ALI ou alterar o comportamento
da aplicação, gerando por exemplo resultados ao usuário.
Consulta Externa (CE): A CE representa o processamento de consultas da aplicação através de entradas e

saídas de dados, onde uma entrada causa uma recuperação e respectivamente uma saída do dado
recuperado não havendo processamento derivado, como criação de dados ou alteração do ALI. Temos
então duas classificações, as funções de dados (ALI e AIE) que representam requisitos de armazenamento
do usuário e as funções de transação (EE, SE e CE) que representam os requisitos de processamento do
usuário.
Temos três etapas para a contagem de pontos de função:
1. Determinar o tipo de contagem

2. Determinar a fronteira da aplicação
3. Calculamos os pontos de função não-ajustados
Determinar o tipo de contagem: Temos três tipos de contagem (Projeto de desenvolvimento, Projeto de
melhoria e Projeto de aplicação).
Passo 1) Projeto de desenvolvimento: No projeto de desenvolvimento mediamos a funcionalidade de

acordo com o que é fornecido pelo usuário final do software para a primeira instalação do software,
podendo haver outras estimativas conforme o software vai sendo desenvolvido.
Passo 2) Projeto de melhoria: No projeto de melhoria medimos as modificações que serão realizadas no
software, logo temos aqui um software que já existe e que mudanças serão implementadas. Temos aqui
mudanças evolutivas e mudanças preventivas.
Passo 3) Projeto de aplicação: No projeto de aplicação medimos um software em funcionamento, também

é conhecida como contagem de baseline por avaliar as funcionalidades já entregues ao usuário do software.
Determinar a fronteira da aplicação: Depois que escolhemos o tipo de contagem, nós devemos determinar
a fronteira da aplicação, o objetivo aqui é indicar a separação entre o escopo da aplicação e o domínio
externo. Nesse momento determinamos através dos requisitos funcionais do usuário, o que será ALI
(Arquivo Lógico Interno) e o que será AIE (Arquivo de Interface Externa).
. Túlio Lages
Thiago
Aula 07
Calculamos os pontos de função não-ajustados: Nesse momento, medimos as funções de dados (ALI e AIE)
e as funções de transação (EE, SE e CE). Calculamos então quantos ALI e AIE e suas respectivas transações
(EE, SE e CE).
Lembrando que o ALI representa dados logicamente relacionados que tem a função de armazenar dados
de dentro da fronteira da aplicação e o AIE que representa dados logicamente relacionados, utilizados para
retorno ou recuperação de dados de uma aplicação, sendo que os dados são armazenados fora da fronteira
da aplicação. A EE representa o processamento de um dado de controle recebido de fora da fronteira da
aplicação a fim de manter ALIs ou altera um comportamento da aplicação, podendo provocar uma inclusão,
alteração ou exclusão de dados no ALI.
A SE representa o processamento do envio de dados para fora da fronteira da aplicação com o objetivo de
exibir informações ou criar dados, podendo manter um ALI ou alterar o comportamento da aplicação,
gerando por exemplo resultados ao usuário. A CE representa o processamento de consultas da aplicação
através de entradas e saídas de dados, onde uma entrada causa uma recuperação e respectivamente uma
saída do dado recuperado não havendo processamento derivado, como criação de dados ou alteração do
ALI.
Entendendo quem é quem dentro da fronteira da aplicação e fora dela, podemos verificar a complexidade
através do DER (Dados Elementares Referenciados) e do RLR (Registros Lógicos Referenciados). O DER
(Dados Elementares Referenciados) ou itens de dados são atributos únicos, que não se repetem e são
reconhecido pelo usuário.
O RLR (Registros Lógicos Referenciados) ou simplesmente itens de registro que são um grupo de dados
elementares referenciados, reconhecido pelos usuários dentro de um ALI ou dentro de um AIE. Lembrando
que vamos identificar o que será um DER ou um RLR através da descrição do requisito funcional do usuário.
Feito isso utilizamos a seguinte tabela para mensurar a complexidade:
E agora o que nós fazemos com essa tabela de DER e RLR? Nós utilizamos a tabela, por exemplo: Se
tivermos: 2 RLRs e 5 DERs, temos uma complexidade baixa, se tivermos 6 RLRs e 18 DERs, temos uma
. Túlio Lages
Thiago
Aula 07
complexidade média. Ok? Depois de avaliar essa complexidade, eu vou usar a complexidade verificada para
avaliar o tamanho funcional dos ALIs e AIEs, usando outra tabela:
Verificados os ALIs e os AIEs, agora eu vou analisar as funções de transação (EE, SE e CE). Para medir a
complexidade utilizamos o DER (Dados Elementares Referenciados) e o ALR (Arquivos Lógicos
Referenciados). Nesse ponto o DER considera o dado que atravessa a fronteira durante uma transação e o
ALR é um ALI ou AIE que é acessado por uma função de transação, conforme um ALI ou um AIE é acessado
por uma função de transação, maior será a complexidade do ALR e para determinar isso, utilizamos outras
tabelas:
Vamos lá! Se um arquivo lógico acessar 1 ALRs e tiver 2 DERs, temos uma complexidade baixa. De posse da
complexidade nós utilizamos mais uma tabela, para mensurar o tamanho funcional do EE, SE ou CE.
. Túlio Lages
Thiago
Aula 07
Unindo tudo em uma só tabela, temos:
Não precisa lembrar todas as tabelas que vimos, desde que lembre dessa última. Ok? Após esse momento
podemos calcular o fator de ajuste, mas acredito que não seja o caso ensina-los sobre como calcular o fator
de ajuste, porque as questões em prova falam qual o fator de ajuste, após conhecer então o fator de ajuste,
basta multiplicar os PF pelos fatores de ajuste e para finalizar, temos que: PF = CP (Contagem dos Pontos)
* FA (Fator de Ajuste).
Análise de ponto de função NESMA
Agora que estão cientes do que é a contagem por pontos de função, vou apresentar os três tipos de
contagem de pontos de função:
• Contagem de pontos de função detalhada

• Contagem de pontos de função estimativa
• Contagem de pontos de função indicativa
Os métodos estimativos e indicativo para a contagem de pontos de função foram desenvolvidos pela
NESMA para permitir que uma contagem de pontos de função seja feita nos momentos iniciais do ciclo de
vida de um sistema. A contagem indicativa da NESMA é também conhecida no mundo como "método
holandês".
. Túlio Lages
Thiago
Aula 07
Contagem de ponto de função NESMA
A contagem detalhada é a contagem usual de pontos de função e é realizada da seguinte forma:
• determina-se todas as funções de todos os tipos (ALI, AIE, EE, SE, CE)
• determina-se a complexidade de cada função (Baixa, Média, Alta)
• calcula-se o total de pontos de função não ajustados
A contagem estimativa é realizada da seguinte forma:
• determina-se todas as funções de todos os tipos (ALI, AIE, EE, SE, CE)
• toda função do tipo dado (ALI, AIE) tem sua complexidade funcional avaliada como Baixa, e toda
função transacional (EE, SE, CE) é avaliada como de complexidade média
• calcula-se o total de pontos de função não ajustados
Logo, a única diferença em relação à contagem usual de pontos de função é que a complexidade funcional
não é determinada individualmente para cada função, mas pré-definida para todas elas.
A contagem indicativa é realizada da seguinte forma:
• determina-se a quantidade das funções do tipo dado (ALIs e AIEs)

• calcula-se o total de pontos de função não ajustados da aplicação da seguinte forma: tamanho
indicativo (pf) = 35 x número de ALIs + 15 x número de AIEs
Portanto esta estimativa é baseada somente na quantidade de arquivos lógicos existentes (ALIs e AIEs)
A contagem indicativa é baseada na premissa de que existem aproximadamente três EEs (para adicionar,
alterar, e excluir dados do ALI), duas SEs, e uma CE na média para cada ALI, e aproximadamente uma SE e
uma CE para cada AIE.
Engenharia de Requisitos
Conceitos Básicos
Começando do começo, requisitos não necessidades que um cliente tem em relação a uma funcionalidade.
Podemos comparar com uma receita por exemplo! A Valentina pediu pra você, progenitor, um bolo. Por ser
uma criança muito esperta e antenada, ela já te explica qual bolo deseja e as restrições e exigências
envolvidas:
• O bolo deve ser de cenoura (seu preferido!), orgânicas colhidas na semana atual;
• A massa precisa ser sem glúten pois ela é celíaca;
• Também precisa ser sem lactose (será que todas as crianças no mundo nascem com essa restrição ou
é impressão minha???);
. Túlio Lages
Thiago
Aula 07
• A cobertura tem de ser de chocolate; e

• O formato precisa ser de coração.
A lista de desejos da pequena Valentina pode ser considera como a lista de requisitos para o projeto bolo! É
comum que na execução desse projeto ocorra um refinamento nesses requisitos de forma a se ajustar ao
orçamento e realidade ao qual o projeto está inserido. No bolo da Valentina podemos negociar a utilização
de cenouras não orgânicas, porém com higienização criteriosa. Sabemos que para o bolo de cenoura não há
necessidade de leite e alinhamos com ela isso. Por fim, adquirir uma forma de coração também pode ser
um desafio, impactando no prazo e custo necessitando uma adequação/alinhamento de expectativas.
Esses tratamentos que fizemos no projeto do bolo da Valentina são atividades que, considerando as devidas
proporções, aplicamos na engenharia de requisitos.
A engenharia de requisitos é um processo para análise, geração e manutenção de documentos de requisitos

de para softwares. Também pode ser denominado como uma abordagem sistêmica, então as duas
definições são válidas na sua prova!
A engenharia de requisitos é primordial em qualquer projeto pois é a partir dos requisitos que conseguimos
entender, dimensionar e propor as funcionalidades do software a ser desenvolvido. O levantamento dos
requisitos exige interação com o cliente então demanda cautela nas tratativas de forma a atender as
necessidades de todos os envolvidos, por isso existem técnicas definidas no processo de engenharia de
requisitos que podem ajudar nisso.
Com a aplicação do processo existe a expectativa de mitigar falhas de comunicação que levam a grandes
erros e perdas financeiras em projetos de software. Infelizmente não há bala de prata então ainda assim
existe a chance de erros nesse processo prejudicarem o projeto.
Fases do processo de engenharia de requisitos
Em relação as fases do processo de requisitos temos duas visões de dois autores conceituados, que você já
deve estar careca de saber: Pressman e Sommerville.
. Túlio Lages
Thiago
Aula 07
A visão do Pressman não é muito cobrada, mas é importante estar com ela em mente para evitar surpresas.
Veja:
Concepção: Fase em que ocorre a identificação da necessidade do cliente, e também são identificados os
envolvidos.
Levantamento: Ocorre o descobrimento do que o cliente deseja para o software com participação dos
envolvidos.
Elaboração: Aqui ocorre a transformação das informações levantadas nas fases anteriores em modelagens
de negócio e sistema gerando os requisitos.
Negociação: existe para que sejam alinhadas as expectativas entre clientes e usuários e tratados possíveis
conflitos. Essa negociação tanto pode gerar novos requisitos como alterar ou excluir os existentes.
Especificação: Momento em que são geradas as documentações do processo, geralmente o produto de

entrega do engenheiro de software.
Validação: O produto gerado na fase anterior é avaliado em relação a sua qualidade e poder de descrição
da necessidade do projeto. Essa avaliação é feita pelos envolvidos.
Gestão: atividades de controle e identificação de mudanças nos requisitos durante as fases.
Agora vejamos a visão do Sommerville que costuma ser mais cobrada, ok?
Para Sommerville a engenharia de requisitos começa com o estudo de viabilidade, seguindo para a
elicitação e análise requisitos, especificação de requisitos, validação de requisitos e por fim a gestão que
engloba todas as fases.
Estudo de viabilidade: O autor entende ser o início do desenvolvimento de software. Nela ocorre o contato
entre o cliente e o analista que começa a avaliar o projeto a ser criado. A partir desse estudo é que é possível
perceber se o sistema a ser construído atenderá os objetivos da organização ou não.
. Túlio Lages
Thiago
Aula 07
Elicitação e análise requisitos: Cai muito!! Mas não tem segredo, essa é a fase em que são identificados os
requisitos os quais originará o projeto. É uma fase crítica e de difícil execução já que obter os requisitos pode
ser bastante desafiador. Explico parafraseando a segurança da informação, o ser humano é o elo mais fraco
dentro da tecnologia da informação. Falha de comunicação é um dos principais problemas dessa fase.
Considerando as complicações da fase, autor define quatro atividades que considera importantes nessa fase
para a entrega dos requisitos:
a) Obtenção de requisitos: atividade em que ocorre a interação com os envolvidos para descoberta
dos requisitos.
b) Classificação e organização de requisitos: O intuito dessa atividade de organizar os requisitos
agrupando-os em conjuntos coerentes.
c) Priorização e negociação de requisitos: Para priorizar os requisitos em sua ordem de execução a
palavra chave é negociação entre os envolvidos.
d) Documentação de requisitos: criação dos documentos que podem ser formais ou informais focado
nos engenheiros de requisitos do processo.
Quando se fala em elicitação é importante registrar as principais técnicas para obtenção dos requisitos, é
um dos assuntos que vive caindo, então vamos ver:
✓ Brainstorming: Em português, tempestade de ideias, essa técnica é muito comum e simples.

Durante um tempo específico os participantes, que são geralmente os envolvidos no projeto
(stakeholders) colocam em pauta suas ideias que não podem ser criticadas. Na verdade os
participantes são encorajados a ser bastante criativos! Ideias inovadores. Essa técnica é
entendida como democrática ao mesmo tempo em que possui como dificuldade a
disponibilidade em reunir os envolvidos.
✓ Cenários: Utilizada para permitir que as pessoas vislumbrem os cenários permitindo um

melhor entendimento dos requisitos do que um registro subjetivo em um documento. Essa
técnica é parte integrante do método XP que vocês estudaram no passo de metodologias
ágeis.
✓ Entrevistas: Bastante comum, na técnica de entrevista são feitos questionamentos sobre os

softwares atuais, caso existam, permitindo a derivação de requisitos a partir dessa conversa.
Também é possível que ocorram conversas abertas em que não há um roteiro pronto. Essa
técnica funciona bem para entender a ideia geral do sistema, interações e as dores que os
envolvidos possam ter nos sistemas atuais.
. Túlio Lages
Thiago
Aula 07
✓ Etnografia: Técnica que costuma ser algo de muitas questões, mas sem segredos! É o ato de
observar para compreender e partir daí gerar os requisitos. Mas observar o que professor? O
trabalho dos envolvidos, as atividades que eles executam permitindo identificar problemas
implícitos. Ela sozinha não ganha jogo, então é geralmente utilizada com outras técnicas,
beleza?
✓ Histórias de usuário: Também originário do famosinho XP essa técnica é consiste em contar

a história mesmo, de forma simplista e pequena o suficiente para um post-it. Ficou com
dúvida? Corre no passo de metodologias ágeis!
✓ Prototipação: Técnica que geralmente é utilizada no estágio final do projeto para que os
envolvidos têm materializa a ideia do software. Esse protótipo é uma montagem que trará a
ideia do software. Por ser algo papável, ajuda na percepção do software permitindo a
redução de tempo e custo no processo de desenvolvimento.
Especificação de requisitos: Aqui acontece a transformação do que foi elicitado em requisito de fato. Esse
conjunto de requisitos gerado deve atender tanto ao cliente quanto ao usuário. Para os requisitos de
usuários deve ser utilizada linguagem natural permitindo a fácil interpretação por parte do usuário. Também
devem ter características como completude e consistência e não-ambiguidade. Isso tudo para mitigar falhas
na comunicação. A documentação gerada pode ser em texto ou gráficos, ok?!
Validação de requisitos: Na validação é feita a análise crítica dos requisitos gerados em relação as
características que citei no tópico acima! Isso pois o cliente é o principal envolvido que precisa entender e
estar de acordo com os requisitos gerados, logo a validação para que haja uma boa interpretação por ele é
muito importante!
Gestão ou Gerenciamento de Requisitos: Fase que está envolvida com todas as anteriores por ser o meio
de controle e acompanhamento dos requisitos e suas mudanças. Por isso é importante que haja
rastreabilidade entre os requisitos para permitir o mapeamento das possíveis mudanças e seus impactos.
Caso tenha dúvidas sobre o conceito de rastreabilidade sugiro que consulta o material da aula regular,
fechado?!
. Túlio Lages
Thiago
Aula 07
Classificação de Requisito Quanto à Funcionalidade
Essa classificação também é uma definição do Sommerville, quando falamos em funcionalidade no

contexto de requisitos, a ideia é distinguir o requisito entre funcional, não funcional e de domínio. Ou seja,
o que o sistema deve fazer e características que o sistema deve possuir. Professor pode explicar mais? Claro,
vamos as definições:
Requisitos funcionais: representam o que o sistema deve ou não fazer. São requisitos que demonstram
ações ou até funcionalidades que o sistema irá fornecer. Além disso, também descreve ações que o sistema
não deve fazer, afinal estamos falando de comportamento.
Exemplos:
Deve - O sistema deve permitir o cadastro de usuário.
Não deve - O sistema não deve permitir que o usuário se autentique sem informar a senha.
Requisitos não funcionais: representam comportamentos que o sistema precisa ter que não incluem as
funcionalidades em si. Como assim, professor? Os requisitos não funcionais referem-se a definições de
arquitetura, restrições de tempo e volume.
Um exemplo é: O sistema deve executar a transação em 1 milissegundo.
. Túlio Lages
Thiago
Aula 07
Como esse é o mais complexo, vamos ver algumas características dos sistemas para as quais se criam
requisitos não funcionais:
▪ Segurança
▪ Desempenho
▪ Confiabilidade
▪ Adequações a padrões de projeto
▪ Restrições de software e hardware
▪ Escalabilidade
Requisitos de domínio: esses são os requisitos advindos do domínio da aplicação do sistema. Eles podem
ser tanto requisitos não funcionais como funcionais, podem refletir fundamentos do domínio da aplicação
como por exemplo cálculos (fórmula fictícia): O sistema deverá calcular a tarifa de comissão de vendas
aplicada ao valor da transação segundo fórmula: TarComissão = (Valortransação) * 4.57+Txvariável)
APOSTA ESTRATÉGICA
A ideia desta seção é apresentar os pontos do conteúdo que mais possuem chances de serem cobrados em
prova, considerando o histórico de questões da banca em provas de nível semelhante à nossa, bem como as
inovações no conteúdo, na legislação e nos entendimentos doutrinários e jurisprudenciais1.
Arquitetura MVC
1
Vale deixar claro que nem sempre será possível realizar uma aposta estratégica para um determinado
assunto, considerando que às vezes não é viável identificar os pontos mais prováveis de serem cobrados
a partir de critérios objetivos ou minimamente razoáveis.
. Túlio Lages
Thiago
Aula 07
Imprima o capítulo Aposta Estratégica separadamente e dedique um tempo para absolver tudo o que está
destacado nessas duas páginas. Caso tenha alguma dúvida, volte ao Roteiro de Revisão e Pontos do Assunto
que Merecem Destaque. Se ainda assim restar alguma dúvida, não hesite em me perguntar no fórum.
. Túlio Lages
Thiago
Aula 07
QUESTÕES ESTRATÉGICAS
Nesta seção, apresentamos e comentamos uma amostra de questões objetivas selecionadas estrategicamente:
são questões com nível de dificuldade semelhante ao que você deve esperar para a sua prova e que, em
conjunto, abordam os principais pontos do assunto.
A ideia, aqui, não é que você fixe o conteúdo por meio de uma bateria extensa de questões, mas que você faça
uma boa revisão global do assunto a partir de, relativamente, poucas questões.
==d8eaf==
QUESTIONÁRIO DE REVISÃO E APERFEIÇOAMENTO

A ideia do questionário é elevar o nível da sua compreensão no assunto e, ao mesmo tempo, proporcionar uma
outra forma de revisão de pontos importantes do conteúdo, a partir de perguntas que exigem respostas
subjetivas.
São questões um pouco mais desafiadoras, porque a redação de seu enunciado não ajuda na sua resolução,
como ocorre nas clássicas questões objetivas.
O objetivo é que você realize uma autoexplicação mental de alguns pontos do conteúdo, para consolidar melhor
o que aprendeu ;)
Além disso, as questões objetivas, em regra, abordam pontos isolados de um dado assunto. Assim, ao resolver
várias questões objetivas, o candidato acaba memorizando pontos isolados do conteúdo, mas muitas vezes
acaba não entendendo como esses pontos se conectam.
Assim, no questionário, buscaremos trazer também situações que ajudem você a conectar melhor os diversos
pontos do conteúdo, na medida do possível.
É importante frisar que não estamos adentrando em um nível de profundidade maior que o exigido na sua prova,
mas apenas permitindo que você compreenda melhor o assunto de modo a facilitar a resolução de questões
objetivas típicas de concursos, ok?
. Túlio Lages
Thiago
Aula 07
Nosso compromisso é proporcionar a você uma revisão de alto nível!
Vamos ao nosso questionário:
Perguntas
1. Defina o que é arquitetura de software.
2. Qual a função da camada Model da arquitetura MVC?
3. Qual a função da camada View da arquitetura MVC?
4. Qual a função da camada Controller da arquitetura MVC?
5. Defina o que é arquitetura orientada a serviço.
6. Defina o que é análise de ponto de função.
7. Explique a engenharia de requisitos.
8. Como a elicitação é dividida na visão de Sommerville? Explique.
Perguntas com respostas
1. Defina o que é arquitetura de software.
A arquitetura de software é uma forma estruturada de construir os componentes de um software de

maneira integrada.
2. Qual a função da camada Model da arquitetura MVC?
Camada de Modelo: Camada responsável pela representação dos dados, provendo meios de acesso
(leitura/escrita). Ela gerencia não só os dados, mas também os comportamentos fundamentais da
aplicação, representados por regras de negócio.
3. Qual a função da camada View da arquitetura MVC?
Camada de Visão: Camada responsável pela interação com o usuário, sendo responsável apenas pela
exibição de dados. Trata-se de uma representação visual do modelo. Ela permite apresentar, de diversas
formas diferentes, os dados para o usuário.
4. Qual a função da camada Controller da arquitetura MVC?
. Túlio Lages
Thiago
Aula 07
Camada de Controle: Camada responsável por receber todas as requisições do usuário. Ele é capaz de
enviar comandos para o modelo atualizar o seu estado. Ele também pode enviar comandos para a respectiva
visão para alterar a apresentação da visão do modelo. Um controlador define o comportamento da
aplicação, interpretando as ações do usuário e mapeando-as em chamadas do modelo.
5. Defina o que é arquitetura orientada a serviço.
Podemos definir SOA (Service Oriented Architecture) como sendo um paradigma que trabalha com recursos
distribuídos orientados como serviços.
Para ficar mais claro, na prática temos aplicações e suas respectivas funcionalidades, essas funcionalidades
são projetadas como “serviços fracamente acoplados”, ou seja, em SOA trabalhamos com o conceito de
independência entre os serviços.
6. Defina o que é análise de ponto de função.
A análise de pontos de função (APF) é uma técnica utilizada para analisar e mensurar as funcionalidades de
um software sob o ponto de vista dos requisitos funcionais de usuário, independentemente de tecnologia.
7. Explique a engenharia de requisitos.
A engenharia de requisitos é um processo, que também pode ser denominada como uma abordagem
sistêmica, para análise, geração e manutenção de documentos de requisitos de para softwares.
8. Como a elicitação é dividida na visão de Sommerville? Explique.
Sommerville entende que a elicitação de requisitos ocorre em 4 atividades:
a) Obtenção de requisitos: atividade em que ocorre a interação com os envolvidos para descoberta dos
requisitos.
b) Classificação e organização de requisitos: O intuito dessa atividade de organizar os requisitos
agrupando-os em conjuntos coerentes.
c) Priorização e negociação de requisitos: Para priorizar os requisitos em sua ordem de execução a
palavra-chave é negociação entre os envolvidos.
d) Documentação de requisitos: criação dos documentos que podem ser formais ou informais focado nos
engenheiros de requisitos do processo.
...
Forte abraço e bons estudos!
"Hoje, o 'Eu não sei', se tornou o 'Eu ainda não sei'"
(Bill Gates)
. Túlio Lages
Thiago
Aula 07
Thiago Cavalcanti
Face: www.facebook.com/profthiagocavalcanti
Insta: www.instagram.com/prof.thiago.cavalcanti
YouTube: youtube.com/profthiagocavalcanti

Aula 09 Apostila

Enviado por

Direitos autorais:

Formatos disponíveis

Aula 09 Apostila

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Aula 09 Apostila

Enviado por

Direitos autorais:

Formatos disponíveis

By @kakashi_copiador

ARQUITETURAS DE SOFTWARE: ARQUITETURA EM

Análise Estatística ........................................................................................................................................ 2

Roteiro de revisão e pontos do assunto que merecem destaque .................................................................. 4

Arquitetura de Software ........................................................................................................................... 5

Conceitos gerais .................................................................................................................................... 5

Acoplamento e coesão .......................................................................................................................... 5

Arquitetura Model View Controller (MVC) ............................................................................................ 8

Arquitetura distribuída .......................................................................................................................... 9

Conceitos gerais sobre arquitetura orientada a serviço .......................................................................... 10

UDDI (Universal, Discovery and Integration)....................................................................................... 11

WSDL (Web Services Description Language) ...................................................................................... 12

SOAP (Simple Object Acess Protocol) ................................................................................................ 13

REST (Representational State Transfer) ............................................................................................. 14

Análise de ponto de função IFPUG ......................................................................................................... 18

Contagem de pontos de função IFPUG ............................................................................................... 18

Análise de ponto de função NESMA ....................................................................................................... 22

Contagem de ponto de função NESMA .............................................................................................. 23

Engenharia de Requisitos ....................................................................................................................... 23

Conceitos Básicos ............................................................................................................................... 23

Fases do processo de engenharia de requisitos ................................................................................... 24

Classificação de Requisito Quanto à Funcionalidade .......................................................................... 28

Aposta estratégica ..................................................................................................................................... 29

Questões estratégicas ................................................................................................................................ 31

Questionário de revisão e aperfeiçoamento ............................................................................................... 31

Perguntas com respostas ........................................................................................................................ 32

realocação, memória virtual, swapping, sistemas de arquivos; Windows 10

ROTEIRO DE REVISÃO E PONTOS DO ASSUNTO QUE

Basicamente, a arquitetura de software é uma forma estruturada de construir os componentes de um

• Acoplamento – O acoplamento diz respeito ao nível de dependência entre os componentes de um

Cliente 1 Cliente 2 Cliente 3

Temos dois tipos de implementação da arquitetura cliente/servidor: cliente-magro e cliente-gordo. No

No Modelo Cliente-Gordo, o servidor somente é responsável pelo gerenciamento de dados e o software do

A utilização da arquitetura em três camadas permite a otimização da transferência de informações entre o

Arquitetura Model View Controller (MVC)

Importante: Na Arquitetura em Três-Camadas, a comunicação entre camadas é rigidamente linear, a

Importante: Os computadores em um sistema distribuído podem estar fisicamente próximos e conectados

Um exemplo comum de sistema distribuída é quando temos processos sendo executados

O middleware oculta do desenvolvedor da aplicação a complexidade do processo de transporte da rede e é

Conceitos gerais sobre arquitetura orientada a serviço

Temos então o seguinte modelo para o funcionamento do paradigma orientado a serviço:

UDDI Responsável pelo descobrimento que define as informações sobre os serviços.

UDDI (Universal, Discovery and Integration)

Páginas Brancas Páginas Verdes Páginas Amarelas

Nome Informações técnicas de acesso Categoria

Endereço Interface 1.1 WSDL

Descrição Interface 1.2 URI

Tamanho Diretório Modelos

WSDL (Web Services Description Language)

<definition> Descrição sobre schemas e namespaces

SOAP (Simple Object Acess Protocol)

O Header é o cabeçalho, que é responsável por adicionar informações complementares a mensagem,

REST (Representational State Transfer)

REST (Transferência de Estado Representacional) é um estilo arquitetural hibrido que surgiu da

• Modelo arquitetural Cache

• Modelo arquitetural Cliente-Servidor

Quando trabalhamos com o modelo cliente-servidor e com a distribuição em camadas temos a

Análise de ponto de função IFPUG

Allan Albrecht em 1979 na IBM trabalhava com o conceito de mensuração em produtividade de

Pensando em funcionalidade, podemos mensurar o desenvolvimento de software através da visão do