1.

Introduo a Anlise de Sistemas

a. Crise de Software

Problemas Iniciais no Desenvolvimento de Sistemas: contnuos erros de execuo,

descumprimento de prazos, problemas relacionados aos custos, inexistncia de documentao
ou elegibilidade da mesma, falta de comunicao durante do desenvolvimento do software,
falta de testes e a insatisfao dos usurios.
b. Metodologias de Desenvolvimento de Sistemas
i. Diferena entre mtodo e metodologia
Mtodo: o caminho pelo qual se atinge um objetivo.
Metodologia: estudo dos mtodos pelos quais se pode atingir um objetivo.
Exemplos:
Metodologia Estruturada (Anlise e Projeto Estruturado, Programao
Estruturada)
Metodologia Orientada a Objetos (Anlise e Projeto O.O, Programao O.O

ii. Fases de um Processo de Desenvolvimento de Software (Viso Geral)

Outros modelos de processos de desenvolvimento de software (ou modelos

de ciclo de vida) que sero estudados adiante:
Sequencial
Cascata
V
Incremental
RUP
Evolutivo
Espiral
Dentre outros.

iii. Tcnicas de Anlise de Sistemas

Na etapa de anlise procura-se detalhar o propsito do sistema (problema) e
identificar os requisitos (caractersticas e funcionalidades) do sistema.
O papel do Analista de Sistemas entender as situaes reais e representa-las de
uma forma que o cliente e a equipe entendam. Desta forma, a partir desta
representao (ou modelagem), o sistema poder ser desenvolvido.
Tcnicas

Ferramentas

Anlise Tradicional

Textos
Fluxogramas

Anlise Estruturada

DFD
Normalizao
Dicionrio de Dados

Anlise Essencial

Anlise Orientada a
Objetos

Tabela de Eventos
DFD
DER
Diagrama de Transio
de estados
Diagrama de estrutura
de Dados
Normalizao
Dicionrio de Dados
Diagrama de Casos de
Uso
Diagrama de Classes
Diagrama de Interao
Diagrama de Atividades
Diagrama de
Implementao

Observaes
Foco nas funes do sistema.
Um simples documento.
Voltada para as funes do sistema.
Foco nas funes e nos dados.
Foca nas funes, mas considera os
processos ou seja, os fluxos de
informaes.
Utiliza diversas ferramentas.
Relaciona-se ao desenvolvimento de
sistemas em linguagens estruturadas:
C, PHP estruturado, por exemplo.

Foco nas funes, dados e controle.

Evoluo da Anlise Estruturada.

Relaciona-se com o desenvolvimento

de linguagens de programao
orientadas a objetos: Java, PHP O.O,
dentre outros.
A mais nova abordagem de anlise de
sistemas.
Sistema mais prximo do mundo real.
Classes, objetos, atributos e mtodos.

Figura Erro! Nenhum texto com o estilo especificado foi encontrado no documento.1 - Diagrama de
Entidade Relacionamento (Anlise Estruturada/Essencial)

Relacionamentos:
1:1 Uma dada instncia de um objeto do tipo X associada a uma, e somente uma, instncia de um
objeto do tipo Y
1:M Um objeto do tipo X associado com um ou mais instncias de um objeto do tipo Y
M:M Para cada instncia de um objeto do tipo X associada com uma ou mais instncias de um
objeto do tipo Y

Usurio
1 usurio pode fazer
0 ou 1 usurio
Mnimo entre 0, 1 e 1? 0
Mximo entre, 0, 1 e 1: 1
Resultado (0,1) mnimo - mximo

Compra
0 ou mais (n) compras
1 compra relaciona-se com
Mnimo entre 0, n e 1 : 0
Mximo entre 0, n e 1: n
Resultado (0,n) mnimo - mximo

Figura 2 - Diagrama de Classes (Anlise O.O)

Figura 3 - Diagrama de Casos de Uso (Anlise O.O.)

2. Levantamento de Requisitos
Visualize a seguinte situao:

O levantamento de requisitos, tambm denominado de elicitao de requisitos, refere-se

etapa de compreenso do problema voltada ao desenvolvimento do software, isto , sero
identificadas as necessidades do usurio para resolver um problema ou atingir um objeto.
Analista de Sistemas e Cliente devem levantar e definir as necessidades e caractersticas do
futuro sistema. Estas necessidades so chamadas de requisitos.
Podemos entender requisito como uma funo, restrio ou propriedade que deve ser
fornecida, encontrada ou atendida para satisfazer s necessidades do usurio do
sistema.
ATENO: Est comprovado : a maior parte dos problemas, os de maior impacto negativo e os
mais onerosos tem origem nas etapas iniciais do desenvolvimento de software. Justamente
nas etapas de especificao dos requisitos onde as principais atividades so definidas e onde
os requisitos do produto devem ser identificados e mapeados com objetividade e clareza.

CLASSIFICAO DOS REQUISITOS: FUNCIONAIS E NO FUNCIONAIS

REQUISITOS NO FUNCIONAIS (requisitos
REQUISITOS FUNCIONAIS
de qualidade ou comportamento ou
restries)
Descrevem, explicitamente, as funcionalidades Definem propriedades e restries do sistema
Exemplos: segurana, desempenho, espao em
do sistema.
disco
Todas as funes devem estar definidas
Podem ser de todo o sistema
Os requisitos no devem ter definies ou de partes do mesmo
contraditrias
Exemplos

Exemplos

Cada pedido deve ser associado a um

identificador nico (PID), o qual o usurio
pode
copiar
para
a
rea
de
armazenamento permanente da conta.
O
sistema
deve
possibilitar
o
cadastramento dos dados pessoais dos
clientes;
sistema deve emitir relatrios gerenciais;
O sistema deve permitir a baixa
automtica do estoque quando da venda
de um produto;

O software deve ser multiplataforma.

A soluo deve ter escabilidade para
atender 10000 usurios (escalabidade)
Cada transao deve ser processada em 5s
(performance)
Devem existir servidores redundantes
para banco de dados (confiabilidade)
tempo de resposta do sistema no deve
ultrapassar 10 segundos;
o software deve ser operacionalizado no
sistema Windows;
O banco de dados usado dever ser o
Oracle;

Figura 1 - Algumas Classificaes dos Requisitos No Funcionais

Mais sobre Requisitos no funcionais

A Norma ISO / IEC 9126 define seis caractersticas de qualidade de software que devem ser avaliadas:

Funcionalidade (finalidade do produto);

Usabilidade (esforo para utilizar, aprender o produto);
Confiabilidade (frequncia de falhas, recuperabilidade);
Eficincia (caracterstica relacionada ao desempenho);
o
o

o
o

Para o estudioso Peter Drucker, a eficincia consiste em fazer certo as coisas e a eficcia em fazer
as coisas certas.
imagine que haja um vazamento de gua no escritrio da diretoria. O primeiro funcionrio,
imediatamente corre atrs de um pano, de um balde e de um rodo para retirar toda a gua do
ambiente. Ele foi eficiente, pois fez de maneira certa o que deveria ser feito. O segundo funcionrio
procurou observar toda a sala e tentar encontrar a origem para o surgimento de tanta gua,
concluiu que vinha exclusivamente do banheiro instalado dentro sala. Uma vez l dentro, percebeu
que a torneira estava aberta e simplesmente a desligou, eliminando todo o problema de vazamento.
Este funcionrio foi eficaz, pois fez o que era certo fazer para solucionar o caso.
A eficincia significa realizar um trabalho correto, sem muitos erros, por outro lado a eficcia
consiste em realizar um trabalho que atinja totalmente o resultado, concluindo o que se props a
fazer com um bom almejo do resultado.
Eficincia: quantidade de recursos de computao e de cdigo exigida para que o programa execute
a sua funo.
Desempenho: medido avaliando-se a velocidade de processamento, o tempo de resposta, o
consumo de recursos e a eficincia

Manutenibilidade (esforo necessrio para modificar);

Portabilidade (capacidade de transferir o produto para outros ambientes).

Usabilidade
Esta seo descreve os requisitos no funcionais associados facilidade de uso da interface com o
usurio, documentao de suporte ao uso e documentao do sistema.
[NF001] <Interface simplificada>
O sistema ser apresentado com uma interface simples, para facilitar ao mximo o uso do mesmo. A
navegao dever ser intuitiva e, sempre que possvel, fornecer ao usurio as opes possveis,
evitando desta forma escolhas que possam apresentar conflitos.
Prioridade: Importante
[NF002] <Agrupamento lgico de relatrios>
Como j foi apresentado, os relatrios e grficos foram divididos em grupos lgicos de forma a facilitar
a navegabilidade do sistema como o entendimento geral do mesmo.
Prioridade: Importante
Caso(s) de uso associado(s): Todos os Casos de Uso descritos na sesso de requisitos funcionais.
[NF003] <Documentao de Suporte para Usurio>
Por ser um extrator de relatrios, o Sistema de Mtricas no requer um manual de usurio. Porm
interessante a elaborao de um documento que explique os relatrios e seus objetivos, auxiliando os
usurios sempre que necessrio obter tais dados. Inicialmente o Sistema de Mtricas ser apresentado
com poucos relatrios, o que talvez no justifique tal documentao. Contudo, em verses futuras o
nmero de relatrios e grficos tender a crescer, tornando a documentao necessria.
Prioridade: Desejvel
[NF004] <Manuteno da Documentao Atualizada>
Como em todo desenvolvimento de software de qualidade, imprescindvel que a documentao seja
periodicamente atualizada, no surgimento de mudanas. O que facilita o desenvolvimento e
manuteno do software, garantindo o entendimento do mesmo por qualquer desenvolvedor que
venha a fazer parte da equipe.
Prioridade: Importante
Confiabilidade
Esta seo descreve os requisitos no funcionais associados corretude do sistema.
[NF005] <Corretude>
Os dados reportados atravs dos relatrios e grficos gerados pelo Sistema de Mtricas, devero ter
total veracidade em suas informaes.
Prioridade: Essencial
Caso(s) de uso associado(s): Todos os Casos de Uso descritos na sesso de requisitos funcionais.
Desempenho
Esta seo descreve os requisitos no funcionais associados eficincia, uso de recursos e tempo de
resposta do sistema.
[NF006] <Comunicao com Sistemas Externos>
Devido a comunicao direta que o Sistema de Mtricas ir ter com outros softwares, como o
MSProject e o TimeSheet, ser importante que durante o desenvolvimento exista uma preocupao
para conseguir a melhor interface com esses sistemas, pois problemas nesta caracterstica poder
comprometer a performance do sistema.
Prioridade: Importante
Caso(s) de uso associado(s): Todos os Casos de Uso descritos na sesso de requisitos funcionais. Pois
todos os relatrios possui seus dados buscados de outros sistemas.
[NF007] <Acesso a Base de Dados>
Dever ser estudado a melhor implementao de acesso a base de dados, de forma que isto no se

torne um gargalo no Sistema de Mtricas. Como o sistema basicamente um extrator de relatrios

atravs de dados buscados em outros sistemas, o acesso a base de dados ser muito intenso, sendo
importante dispensar grande ateno a comunicao com o banco de dados.
Prioridade: Importante
Caso(s) de uso associado(s): Todos os Casos de Uso descritos na sesso de requisitos funcionais.
Todos os relatrios e grficos iro acessar a base de dados.
Segurana
Esta seo descreve os requisitos no funcionais associados integridade, privacidade e autenticidade
dos dados do sistema.
[NF008] <Acesso ao Sistema>
O acesso ao sistema ser controlado por meio de login/senha e nveis de acesso de acordo com as
permisses que os diferentes usurios possuem dentro do sistema.
Prioridade: Essencial
Caso(s) de uso associado(s): Todos os Casos de Uso descritos na sesso de requisitos funcionais. Pois
todos os relatrios s sero acessados de acordo com as permisses dos usurios.
Padres
Esta seo descreve os requisitos no funcionais associados a padres ou normas que devem ser
seguidos pelo sistema ou pelo seu processo de desenvolvimento.
[NF009] <Padres e Normas>
O setor de TI com o objetivo da implantao de qualidade, est desenvolvendo uma srie de padres e
normas a serem seguidos no processo de desenvolvimento de software. Uma metodologia nica de
desenvolvimento de software est sendo implantada na empresa, e esta dever ser seguida no
decorrer do desenvolvimento do Sistema de Mtricas. Alm da metodologia existem as ferramentas
padres que devero ser usadas, padres de codificao a serem seguidos, entre outras caractersticas
de qualidade ainda em anlise.
Prioridade: Importante
Hardware e software
Os requisitos de software necessrios para o desenvolvimento do projeto sero:
[NF010] <Ambiente de desenvolvimento Java>
Como o sistema ser desenvolvido em Java, que a linguagem de programao padro adotada pelo
departamento de TI, sero necessrias trs licenas do Ambiente de. desenvolvimento JAVA: Jbuilder
ou Jdeveloper.
Prioridade: Essencial

Processo de Engenharia de Requisitos

3. Diagramas de Casos de Uso

A Unified Modeling Language (UML) uma linguagem de modelagem. A UML no uma
metodologia de desenvolvimento, o que significa que ela no diz para voc o que fazer primeiro
ou como projetar seu sistema, mas ela lhe auxilia a visualizar seu desenho e a comunicao
entre objetos.
Basicamente, a UML permite que desenvolvedores visualizem os produtos de seus trabalhos
em diagramas padronizados.
O desenvolvimento da UML foi baseado em tcnicas antigas e marcantes da orientao a
objetos
A UML 2.2 possui 14 tipos de diagramas, divididos em duas grandes categorias: Estruturais e
Comportamentais.

RESUMINDO: A UML um modo de padronizar as formas de modelagem.

FOCANDO NO DIAGRAMA DE CASOS DE USO:
Os requisitos podem ser modelados e validados atravs de casos de uso que incluem o
diagrama de casos de uso e a especificao do caso de uso.
Um caso de uso definido como "um conjunto de sequncias de aes que um sistema executa
que produzem um resultado observvel por um particular ator".

Principais Componentes do Modelo de Casos de Uso:

Caso de uso:
o Especifica uma funcionalidade completa do sistema.
o Processos ou funes que o sistema deve realizar de forma automtica ou mesmo
manual
o Geralmente associadas a descries textuais
o sempre iniciado por um ator (direta ou indiretamente ordena ao sistema a execuo
de um caso de uso);
o So descritos com verbos no infinitivo (ex.: emitir relatrio, logar no sistema, realizar
cadastro,...)
Ator:
o Pessoas que desempenham algum papel no sistema
o Entidades externas, como outros sistemas, que interagem com o sistema sendo
projetado
Relacionamentos:
o Atores x Casos de Uso
o Casos de Uso x Casos de Uso

Uma proposta de sequncia que pode ser usada para construir o modelo de casos de uso:

Como identificar um ator ?

As respostas s seguintes perguntas podem auxiliar na identificao dos atores:
1.
2.
3.
4.
5.
6.

Quem utiliza a principal funcionalidade do sistema?

Quem vai precisar de suporte do sistema para realizar suas tarefas dirias?
Quem precisa manter, administrar e deixar o sistema "rodando"?
Quais dispositivos de hardware o sistema precisa manipular?
Com quais outros sistemas o sistema precisa interagir?
Quem ou o qu tem interesse nos resultados produzidos pelo sistema?

Como identificar um caso de uso ?

As respostas s perguntas abaixo podem auxiliar a identificar os Casos de Uso.
1. Quais funes o ator requer do sistema? O que o ator precisa fazer?
2. Ator precisa criar, ler, destruir, modificar ou armazenar algum tipo de informao dentro do
sistema?
3. Ator precisa ser notificado de eventos do sistema? O ator precisa notificar o sistema sobre
algum evento?
4. Trabalho dirio do ator poderia ser simplificado ou tornado mais eficiente por meio de novas
funcionalidades do sistema?
5. Quais entradas e sadas o sistema precisa?
6. Quais os principais problemas com o atual sistema?

Relaes entre atores e casos de uso

Associao

Relaes entre casos de usos

Generalizao/Especializao
Quando um caso de uso uma especializao de outro caso de uso.

Include
Uma das formas de interao, um dado caso de uso pode incluir outro. Incluir uma relao direta
entre dois casos de usos, implicando que o comportamento do caso de uso includo inserido no
comportamento do caso de uso inclusor. Esta relao indica uma obrigatoriedade do caso de uso
incluir a funcionalidade do caso de uso includo. Assim, sempre que o primeiro ocorrer, o includo
ocorrer obrigatoriamente.
A notao uma seta pontilhada para o caso de uso includo com o esteretipo <<include>>.

Extend
Outra forma de interao, um caso de uso pode estender outro. Esta relao indica que o
comportamento do caso de uso estendido pode ser ou no inserida no caso de uso extensor.
Notas ou restries podem ser associadas ao relacionamento para ilustrar as condies em que este
comportamento ser executado.

A notao uma seta pontilhada da extenso para o caso de uso estendido com a etiqueta <<extend>>.

Existem diversas ferramentas para que voc consiga criar um diagrama de casos de uso:
Astah (Jude)
StarUML
Enterprise Architect
Umbrello: (http://uml.sourceforge.net/)
ArgoUML

4. Diagrama de Sequncia
Pode ser utilizado como produto da Anlise Orientada a Objetos.
Seu foco no comportamento do sistema.
Apresenta a ordem temporal das mensagens enviadas e recebidas pelos objetos.
Ajuda a descobrir onde colocar a chamada dos mtodos dentro do sistema.
Ajuda a verificar se a comunicao entre as classes est coerente!
Elementos
o Atores
o Objetos (instncias de classes)
o Linha de Vida (tempo de vida do objeto dentro do sistema)
o Mensagem Sncrona (chamada de mtodos)
o Retorno (indica a resposta para o objeto ou para o ator que o chamou)

5. Diagrama de Classe
Representao de uma classe

Relacionamentos entre classes:

 Existem outros relacionamentos entre classes, mas eles no sero abordados neste
contedo.

Referncias:
http://www.olharcientifico.kinghost.net/index.php/olhar/article/viewFile/55/39
http://www.macoratti.net/07/12/net_fer.htm