SUMRIO

INTRODUO.......................................................................................................3

Pesquisas Sobre:...................................................................................................4

2.1

Processo de Inspeo de Software...................................................................4

2.2

Verificao e Validao......................................................................................5

2.3

Testabilidade de Software..................................................................................6

SGBD (Sistema Gerenciador de banco de dados)................................................7

Linguagem de Programao recomendada..........................................................8

Modelo de processo proposto................................................................................8

Concluso..............................................................................................................9

Referncias..........................................................................................................10

1 INTRODUO
Neste trabalho irei relatar os Processos de Inspeo de Software, Verificao e Validao,
Testabilidade de Software, SGBD, Linguagem de Programao e Modelo de Processo Proposto com
suas finalidades.
Com este trabalho, pretendo aumentar o conhecimento sobre a Informao, realizei pesquisas
atravs de Livros e Sites para obter mais conhecimentos e retirar algumas dvidas.

PMBox
RISCO
Risco a probabilidade de que um fator de risco venha a assumir um valor que
passa a prejudicar, total ou parcialmente as chances de sucesso de um projeto. Um
fator de risco qualquer evento que possa prejudicar total ou parcialmente, as
chances de sucesso do projeto, isto , as chances do projeto realizar o que foi
proposto dentro do prazo e fluxo de caixa que foram estabelecidos.
visto que em gerncia de projetos, o risco est ligado a estas duas palavras:
possibilidade e perigo. No entanto, a viso que temos em gerncia de projetos que
risco qualquer evento potencial que, se concretizado, pode afetar negativamente
ou positivamente o objetivo do projeto.
Escopo
Em processos de desenvolvimento de software o escopo do projeto um dos
principais elementos e o mais difcil de ser estabelecido de forma correta. A partir de
sua definio que o projeto pode ser iniciado, desenvolvido e gerenciado. Porm,
as caractersticas do software fazem do gerenciamento do escopo uma atividade
extremamente dinmica, que inclui alm da definio dos requisitos, o
gerenciamento dos mesmos.
A tarefa de gerenciar os requisitos engloba alm da definio, a rastreabilidade dos
mesmos, a adaptabilidade de mudanas ocorridas nos mesmos, bem como o
gerenciamento dessas mudanas. Um projeto que envolva o desenvolvimento de
software inclui, ainda, dificuldades em se manter os requisitos levantados no incio
do projeto, por isso, a importncia da uma boa coleta de requisitos inicial; realizar o
gerenciamento das diferentes fontes de informao (stakeholders) para a definio
dos mesmos; e gerenciar as constantes adies ou mudanas nos mesmos durante
todo o projeto, medida que novas funcionalidades so entregues.
Por isso, um cuidadoso gerenciamento do escopo parte substancial do
desenvolvimento de um projeto que envolva a construo de softwares. Para tanto,
a tarefa de gerenciar dividida em planejamento (que deve ser detalhado),
verificao e o controle do mesmo.
Fornecedores
Fornecedores, ou contratadas, so empresas externas que assinam um contrato
para fornecimento de componentes ou servios necessrios ao projeto.
Parceiros comerciais so tambm empresas externas, mas tem uma relao
especial com empresa, as vezes obtida atravs de um processo de certificao. Os
parceiros comerciais fornecem consultoria especializada ou preenchem um papel
especfico, com instalao, personalizao, treinamento ou suporte.

Projeto de Arquitetura
Este capitulo apresenta os conceitos de arquitetura de software e de projeto de
arquiteturas, tendo como como foco compreender o motivo de se utilizar uma
arquitetura e como a utilizar.
Projeto de arquitetura basicamente decompor um sistema grande em subsistemas
que fornecem algum conjunto de servios relacionados, e estabelecer um framework
para controlar estes subsistemas.
Durante este estagio, os projetistas de softwares so induzidos a considerar
aspectos principais do projeto no inicio, este pode servir com um plano de projeto
usado para negociar requisitos de sistema e como meio de estruturao para
discusses com os clientes. Tambm uma ferramenta essencial para o
gerenciamento da complexidade do sistema.
A arquitetura deve ser escolhida a partir dos requisitos no funcionais do sistema.
Se o desempenho for um requisito critico a arquitetura deve ser projetada para
encontrar operaes criticas dentro de alguns subsistemas.
Se a proteo for um requisito critico, deve ser utilizada uma estrutura por camas,
assim protegendo os itens mais crticos.
Se a segurana for um requisito critico, a arquitetura deve ser projetada, fazendo
com que todas as operaes relacionadas a segurana, devem estar localizada em
um subsistema, ou em poucos subsistemas.
Se a disponibilidade for um requisito critico, a arquitetura deve ser projetada
utilizando componentes que podem ser substitudos e atualizados sem dificuldades.
Se a facilidade de manuteno for um requisito critico, a arquitetura deve ser
projetada usando componentes de baixa granularidade e autocontidos que possam
ser prontamente mudados.
Porem existe conflitos entre as arquiteturas adotadas, j que algumas exigem o uso
de componentes opostos, como o caso de componentes de alta e baixa
granularidade, quando existe este conflito, deve ser proposto uma soluo eficaz,
pode-se conseguir isso, algumas vezes, pelo uso de estilos de arquiteturas
diferentes para cada parte do sistema.
O Projeto de um subsistema uma decomposio abstrata de um sistema em
componentes, cada um podendo ser um sistema substancial e independente, para
um projeto de subsistema utilizado o diagrama de blocos. Caixas dentro de caixas
indicam que o subsistema foi ele prprio decomposto em subsistemas. As setas so
utilizadas para indicar fluxo de dados e sinais de controle. Este diagrama deve ser
utilizado de forma que pessoas de reas diferentes envolvidas no mesmo processo
de desenvolvimento do sistema possam entender.
Bass diz que este diagrama de caixas em linhas no so representaes teis de
arquitetura, j que no mostram a natureza dos relacionamentos entre componentes
do sistema. Porem este modelo eficaz para comunicao com os stakeholders do
sistema e para planejamento do sistema, pois ele simples e no tem muitos
detalhes. O diagrama de caixas e linhas no pode ser a nica representao de
arquitetura a ser utilizada em um projeto.
A dificuldade em descompor um sistema em subsistemas que os requisitos do
sistema so um fator principal e o projeto deve ter uma correspondncia estrita entre
os requisitos e os subsistemas, e durante um projeto, os requisitos mudam, porem
os subsistemas no.
Projeto de arquitetura um processo que tenta estabelecer uma organizao de
sistemas que satisfaa os requisitos funcionais e no funcionais do sistema. Para

definir qual arquitetura deve ser utilizada, os arquitetos de sistema tentam responder
as seguintes questes.
1. Existe uma arquitetura genrica de aplicao que possa funcionar como modelo
para o sistema que est sendo projetado?
2. Como o sistema ser distribudo ao longo de vrios processador?
3. Qual ou quais estilos de arquitetura so apropriados para o sistema?
4. Qual ser a abordagem fundamental para estruturar o sistema?
5. Como as unidades estruturais de um sistema sero descompostas em mdulos?
6. Qual estratgia ser usada para controlar a operao das unidades do sistema?
7. Como o projeto de arquitetura ser avaliado?
8. Como a arquitetura deve ser documentada?
Mesmo cada sistema de software seja nico, frequentemente sistemas que de
mesmo domnio de aplicao tem arquitetura similares, assim tornando algumas
arquiteturas bastante genricas.
Dependendo do sistema, seja ele pequeno, somente para um nico processador, ou
para um sistema que vai ser distribudo em vrios processadores, escolha da
arquitetura de distribuio muito importante pois afeta no desempenho e
confiabilidade do sistema.
A arquitetura de um sistema de software pode ser baseada em um modelo ou estilo
de arquitetura, saber os pontos fortes e fracos de cada estilo importante, porem
no obrigatrio que todo o sistema siga somente um estilo, assim podendo utilizar
uma arquitetura composta criada pela combinao de diferentes estilos.
Voc precisa escolher a estrutura mais apropriada para atender os requisitos do
sistema. Para avaliar esta estrutura difcil, pois o verdadeiro teste de arquitetura
recai sobre quo bem elas atendem os requisitos. Contudo voc pode comparar o
seu projeto, como modelos genricos de arquitetura.
A organizao de um sistema a estratgia bsica usada para estrutura-lo, pode
refletir diretamente na estrutura do subsistema. Nessa seo explicada trs esitlos
de organizaes. Estes podem ser utilizados separadamente ou juntos.
Modelo Repositrio
Os subsistemas devem trocara informaes para trabalharem juntos eficientemente.
Pode ser feito de duas maneiras, todos os dados so compartilhados no mesmo
banco de dados para que possam ser acessados de qualquer subsistema, ou os
dados podem ser mantidos em bancos de dados separados, e estes so trocados
entre os subsistemas por meio de mensagens.
A maioria dos sistemas com grande quantidades de dados so organizados em um
nico banco de dados compartilhado. Este modelo adequado para aplicaes que
os dados so gerados por um subsistema, e utilizado por outro.
Modelo Cliente-Servidor
Neste modelo o sistema organizado como um conjunto de serivoes e servidores,
e os clientes acessam os servidores para utilizar os servios. Os clientes talvez
precisam saber os nomes do servidores disponveis e os servios que eles
fornecem, porem os servidores no precisam saber quem , ou quantas so os
clientes que existem. Neste modelo o cliente faz o pedido para o servidor, e aguarda
uma resposta.
Modelo em camadas.
Neste modelo a arquitetura organizada de maneira que cada camada fornece um

conjunto de servios. Este modelo apoia o desenvolvimento incremental de

sistemas, quando uma camada desenvolvida alguns servios desta camada
podem ser disponibilizados para os usurios, este modelo tambm fcil de ser
modificado e tambm porttil, desde que sua interface permanea inalterada, uma
camada poder ser substituda por outra equivalente. Alm disso, quando as
interfaces de camada so alterada, ou novos recursos so adicionados a uma cada,
somente a cama adjacente afetada.
Depois que definido um modelo de organizao, deve se decidir como ser feita a
abordagem a ser usada na decomposio dos subsistemas em mdulos. Em uma
abordagem orientada a objetos, os mdulos so objetos com estado privado e
operaes definidas, j no modelo de pipelining os mdulos so transformaes
funcionais. Em ambos os casos, os mdulos podem ser implementados como
componentes ou processos sequenciais.
Decomposio orientada a objeto
Um modelo de arquitetura orientada a objetos estrutura o sistema em um conjunto
de objetos no firmemente acoplado com interfaces bem definidas. Os objetos
chamam servios oferecidos por outro objeto.
As vantagens da decomposio orientada a objeto, por no serem firmemente
acoplados eles so facilmente modificados sem afetar outro objeto, e Pipelining
orientado a funes
Neste modelo de fluxo de dados, feito o processamento dos dados que entram, e
produzido os dados que saem. Os dados fluem de maneira linear de uma funo,
para a outra, e so transformados neste meio tempo.
Vantagens
Apoia o uso de transformaes.
intuitiva no sentido que muitas pessoas pensam em seu trabalho em termos de
processamento de entrada e sada.
A evoluo do sistema pela adio de novas transformaes geralmente direta.
Simples de ser implementada tanto quanto um sistema concorrente ou sequencial.
Modelos de controle a maneira que os subsistemas devem ser controlados para
formar um sistema completo. Existem dois estilos genricos de controle usados em
sistema de software.
Controle centralizado
Neste modelo, um subsistema designado para controlar o sistema e tem como
responsabilidade o gerenciamento da execuo de outros subsistemas. Existem dois
modelos de controle centralizado.
1. Modelo chamada-retorno, este modelo conhecido como modelo top-down de
sub-rotina em que o controle comea no topo da hierarquia e termina nos nveis
mais baixos.
2. Modelo gerenciador, este modelo aplicvel a sistemas concorrente, um
processo um subsistema ou um modelo que precisa ser executado paralelamente.
Sistema orientado a eventos
Este modelo regido pelos eventos gerados externamente, um evento sempre

chamado dependendo da ao executada na interface. Este modelo muito

utilizado em ferramentas de edio, sistemas de I.A, entre outros.
Diferente de aguardar por um comando completo que processa a informao, o
sistema em tal paradigma programado em sua base em um lao de repetio de
eventos, que recebem repetidamente informao para processar e disparam uma
funo de resposta de acordo com o evento.
O mtodo pelo qual a informao adquirida por camadas mais baixas do sistema
irrelevante. As entradas podem ser enfileiradas ou uma interrupo pode ser
registrada para reagir, ou ainda ambos.
Programas orientados a evento geralmente consistem em vrios pequenos
tratadores, programas que processam os eventos para produzir respostas, e um
disparador, que invoca os pequenos tratadores. Uma alternativa consiste em
disparar os tratadores por eles prprios, criando um efeito de evento em cascata.
Esse mtodo bastante flexvel e permite um sistema assncrono. Programas com
interface com o usurio geralmente utilizam tal paradigma. Sistemas operacionais
tambm so outro exemplo de programas que utilizam programao orientada a
eventos, este em dois nveis. No nvel mais baixo encontram-se o tratamento de
interrupes como tratadores de eventos de hardware, com a CPU realizando o
papel de disparador. No nvel mais alto encontram-se os processos sendo
disparados novamente pelo sistema operacional.
Um interpretador de comandos pode ser visto como um caso especial de modelo
orientado a eventos, no qual o sistema, at ento inativo, espera um comando para
ser disparado atravs das instrues do usurio.
Uma arquitetura de referncia um ponto de incio. uma representao, bem
genrica e abstrata, que ajuda o time (e o arquiteto) na definio de elementos
concretos do sistema. Elas apontam para os principais componentes a serem
definidos orientando indiretamente seus papis, comportamentos e
relacionamentos.
Arquiteturas de referncia surgem da observao de determinados tipos de
software. Definem e explicitam elementos comuns aplicados por vrios profissionais
de arquitetura no projeto de vrios software de um determinado tipo. So
representaes em alto-nvel das similaridades identificadas nessas diversas
instncias.
Considerar uma arquitetura de referncia, ao conceber um novo sistema, poupa ao
arquiteto um volume considervel de anlise e ponderao na identificao de
componentes seus comportamentos, papis e relacionamentos.
Arquiteturas de referncia no foram criadas para atender conjuntos especficos de
requisitos. Isso significa que no podemos pegar uma arquitetura de referncia e
apont-la como sendo a arquitetura de um novo sistema sem a avaliao e ajustes
indispensveis. Elas so projetadas para servir como uma indicao de caminho a
seguir. Uma arquitetura concreta surge da adaptao de uma referncia para as
necessidades e propsitos de um sistema especfico.

2. Arquitetura de Sistemas Distribudos

Um sistema distribudo e um sistema na qual as informaes so distribudas para
vrios computadores, em vez de ficarem armazenadas e uma nica maquina. Com
desenvolver um software utilizando este tipo de arquitetura, as sua vantagens e
desvantagens, alm de alguns modelos genricos sero abordados.
Um sistema distribudo e um sistema na qual as informaes em fase de
processamento so distribudas pra vrios computadores, em vez de ficarem
confinados e nica maquina.
Este tipo de sistema tem vantagens e desvantagens:
Vantagens:
a) Compartilhamento de Recursos: permite o compartilhamento de recursos pela
rede como impressoras, softawares, processamentos, discos, etc;
b) Concorrncia: possibilidade de se ter vrios processos ao mesmo tempo em
diferentes computadores;
c) Tolerncia a defeitos: pode suportar at algumas determinadas falhas de
software ou de hardware;
d) Escalabilidade: possibilidade de aumentar a capacidade do sistema, seja de
recursos fsicos(hardware) como virtuais(software) para atender novas
demandas;
e) Abertura: utilizao de equipamentos e software de diferentes fabricantes em
conjunto.
Desvantagens:
a) a) Complexidade Difcil entendimento das propriedades do sistemas, e com
isso, dificuldade para realizar testes no sistema com um todo;
b) Proteo o sistema acessado por vrios computadores, e com isso
todo o trafego est sujeito a interceptao, e consequentemente a alterao
dos dados, alm de violao de leis de privacidade;
c) - Gerenciamento Dificuldade no gerenciamento pelos mais variados
motivos, como por exemplo, verses de S.O. ou do softwares diferentes,
diferenas de hardware entre os usurios, e etc;
d) Imprevisibilidade A alta demanda de usurios, solicitando informaes
podem causar respostas fora do padro ou fora de um tempo aceitvel. Estes
erros podem ter inmeras causas, e em muitas vezes fica impossvel saber as
suas causas num perodo de tempo curto.
O grande paradigma projetar um software e o hardware para fornecer os recursos
de sistemas distribudos, desejveis e, ao mesmo tempo, minimizar os problemas
deste
tipo
de
arquitetura.
Pensando em como projetar o software, podemos partir de dois tipos de arquitetura:
Arquiteturas
cliente-servidor
2.1 Arquitetura cliente-servidor
um modelo que separa os clientes e os servidores. Neste modelo, as parte so
interligadas entre si, geralmente utilizando-se uma rede de computadores.

10

Cada objeto de um cliente pode enviar requisies de dado para algum dos
servidores conectados e esperar pela resposta. Por sua vez, os servidores
disponveis pode aceitar tais requisies, process-las e retornar o resultado para o
cliente. Apesar do conceito ser aplicado em diversos usos e aplicaes, a arquitetura

praticamente
a
mesma.
Muitas vezes os clientes e servidores se comunicam atravs de uma rede de
computador com hardwares separados, como no caso de um sistema web, mas
tambm o cliente e servidor podem residir no mesmo local. Um cliente no
compartilha de seus recursos, mas solicita o contedo de um servidor ou funo de
servio. Os clientes, portanto, iniciam sesses de comunicao com os servidores
que
esperam
as
solicitaes
de
entrada.
A caracterstica de cliente-servidor, descreve a relao de programas em um
aplicativo. O componente de servidor fornece uma funo ou servio a um ou muitos
clientes,
que
iniciam
os
pedidos
de
servios.
Por exemplo, um navegador da web um programa cliente em execuo no
computador de um usurio que pode acessar informaes armazenadas em um
servidor web na Internet. Um outro exemplo seria algum usurio de servios
bancrios de algum banco, como o Ita ou Caixa Econmica Federal, acessando de
seu computador via um navegador da Web(aplicativo cliente), como o Firefox ou
Google Chrome para enviar uma solicitao para um servidor web do
banco(servidor).
Cada instncia de software do cliente pode enviar requisies de dados a um ou
mais servidores ligados. Por sua vez, os servidores podem aceitar esses pedidos,
process-los e retornar as informaes solicitadas para o cliente. Embora este
conceito possa ser aplicado para uma variedade de razes para diversos tipos de
aplicaes, a arquitetura permanece fundamentalmente a mesma.
2.2 Arquitetura de objetos distribudos.
Na arquitetura de objetos distribudos os componentes do sistema so objetos que
fornecem uma interface para um conjunto de servios fornecidos. Outros objetos
chamam esses servios sem distino logica entre um cliente(receptor de um
servio)
e
um
servidor(provedor
de
um
servio).
Os objetos podem ser distribudos entre uma serie de computadores na rede e se
comunicam atravs de um middleware. Esse middleware chamado de requisitor de
objetos. Seu papel fornecer uma interface transparente continua entre os objetos.
2.3 Arquiteturas de multiprocessadores.
um dos modelos de sistemas distribudos mais simples, que consiste em uma
serie de processos que podem ou no ser processados por processadores
diferentes.
2.4 Computao Inter-organizacional distribuda.
Por motivos de proteo e interoperabilidade, a computao foi implementada
inicialmente em nvel organizacional. Uma organizao tem uma serie de servidores
e
distribui
a
sua
carga
computacional
entre
eles.
Devido ao fato de eles estarem todos localizados dentro da mesma organizao,
podem ser aplicados padres e processos operacionais locais. Embora, para

11

sistemas baseados na Web, os computadores clientes estejam muitas vezes fora

dos limites da organizao, sua funcionalidade limitada a executar um software de
interface com o usurio.
2.5 Arquiteturas ponto a ponto
So sistemas descentralizados em que as computaes podem ser realizadas por
qualquer n da rede e, em principio pelos menos nenhuma distino feita entre
clientes e servidores.
O sistema e projetado para beneficiar-se da capacidade computacional e
armazenamento disponveis em uma rede potencialmente grande.
6 Arquitetura de sistema orientada a servios
Desenvolvidas para tonar acessveis informaes de um programa para outros para
fazer isso com a definio de publicao de uma interface de Web servisse.
Genericamente, um web service uma representao padronizada de alguns
recursos computacionais e de informaes que podem ser usadas por outros
programas.

3 FRAMEWORKS PARA PLATAFORMA WEB

Neste trabalho e realizado uma breve apresentao de frameworks para a

12

plataforma Web. Na apresentao contm descrio, caractersticas e vantagens de

cada framework.
.
Contextualizao
Devido ao crescimento acelerado da Internet e, consequentemente, as facilidades
que a mesma oferece, muitas empresas decidiram migrar de seus sistemas Desktop
para sistemas Web. Esta migrao em grande escala fez com que o
desenvolvimento Web tambm crescesse para atender essa demanda e, com isto,
as empresas que decidiram investir nessa migrao tiveram vantagens como:
Disponibilizar servios a um maior nmero de pessoas;
Expandir o horizonte da empresa graas ao maior alcance da Internet.
Porm, era necessrio que as formas de desenvolvimento Web tambm evolussem,
pois ainda eram usadas tcnicas que no proporcionavam a produtividade esperada,
e um sistema Web era considerado muito complexo de desenvolver, afinal, as
ferramentas de programao para essa plataforma no eram muito eficazes em
relao s seguintes caractersticas: confiabilidade, produtividade, facilidade de
desenvolvimento e o principal, reusabilidade. Em paralelo a essa necessidade, um
padro usado em smalltalk nos anos 80 voltou a ser utilizado, o MVC (Modelo-ViewController ou Modelo-Viso-Controle), onde os programadores criam interfaces e 15
telas, acesso dados e lgica de negcios de forma independente, o que notou-se
uma forma eficiente de se desenvolver aplicativos Web.
A importncia de usar frameworks tambm notada ao seguir o modelo
MVC, porque, sem frameworks fica praticamente impossvel utilizar corretamente
esse modelo, usando Java EE (Enterprise Edition) como exemplo, possvel seguir
esse modelo usando Java Server Pages para a criao do layout de pginas na
camada de viso; usar um banco de dados conectado ao JDBC para a camada de
modelo. No entanto, a camada de controle no possvel cri-la independentemente
das outras camadas, ou seja, para desenvolver a camada de controle puramente em
Java EE seria necessrio usar cdigo correspondente a lgica de negcios em todas
as pginas JSP (Java Server Pages) o que no torna a aplicao independente
entre camadas, pois assim a camada de viso estaria sobre a camada de controle o
que em manutenes futuras seria um agravante, pois para uma simples alterao
no layout da pgina poderia afetar o cdigo referente a camada de controle
justamente por eles encontrarem-se no mesmo arquivo.
Com a criao de novas ferramentas e padres de desenvolvimento tornou-se mais
fcil desenvolver sistemas, pois atualmente, as ferramentas tambm evoluem na
mesma proporo que a demanda por esse tipo de sistema.
Seguindo esta evoluo, estruturas que apoiam a reutilizao foram propostas para
facilitar o desenvolvimento de projetos voltados a Web, conhecidos como
frameworks. Dentre os frameworks desenvolvidos para aplicaes Web destacam-se
os tipos: framework de suporte, framework de aplicao, framework de domnio.
Principais Frameworks Java para desenvolvimento WEB
Alguns dos principais Frameworks Java para desenvolvimento WEB so:
1. JSF (Java Server Faces) [Jacobi 2007];
2. Spring MVC [Walls 2006];
3. Struts 2 [Apache 2006];
4. Tapestry [Sam-Bodden 2006].

13

2 REFERNCIAS

Sistemas Operacionais Modernos Tanenbaum (livro)

Sistemas de Banco de Dados Ramez Elmasri e Shamkant B. Navathe (livro)
InfoEscola.com (site)
Inf.puc-rio (site)