ANÁLISE E

PROJETO DE SISTEMAS
ALEXANDRE DOMINGUES GONÇALVES
 AULA 1
ANÁLISE E
PROJETO DE SISTEMAS
ALEXANDRE DOMINGUES GONÇALVES
Necessidade da metodologia nas
organizações
 Na primeira década do processamento de dados eletrônicos,
acreditava-se que construir sistema era o mesmo que construir
programas.
 Todo o desenvolvimento do sistema era com ênfase na resolução
do problema proposto sem uma análise minuciosa do mesmo. O
resultado disso, era a insatisfação do cliente e uma infinidade de
críticas aos analistas de sistema
EVOLUÇÃO DAS METODOLOGIAS
TÉCNICAS DE ANÁLISE DE SISTEMAS

estados
ANÁLISE TRADICIONAL
Técnica inicial
 Uso de textos descritivos e fluxogramas
ANÁLISE ESTRUTURADA
Enfatiza a perspectiva das funções, com ênfase nos processos
Compostos de modelo funcional e do modelo de dados
 Tem por premissa a representação ordenada por fluxo..
 Mostra uma divisão hierárquica, criando níveis de DFD..
◦ Níveis 0, 1 ..
◦ Mostrado por enumerações, em níveis cada vez menos abstratos
 A análise estrutura clássica não modela o comportamento temporal,
nem complexos relacionamentos de dados
Caiu em desuso com o paradigma OO, mas..
 Diagrama Entidade e Relacionamento ( DER )

Diagramas

Diagrama de fluxo de dados ( DFD ) – nível x

Diagrama de contexto que equivale ao
Diagrama de fluxo de dados ( DFD ) – nível 0
ANÁLISE ESSENCIAL
 Proposta em 1984, por McMenamim ePalmer para a introdução dos novos
conceitos que estavam sendo incorporados à Análise Estruturada Clássica
 propõe o particionamento do sistema por eventos
Compostos de modelo funcional , modelo de dados e modelo de controle
(baseado em eventos)
 Descrever o sistema de maneira independente de restrições tecnológicas
 Diagramas organizados em modelo ambiental (relacionados ao ambiente que está
inserido) e modelo comportamental (como o sistema deve reagir a estímulos do
ambiente)
Modelo ambiental
 Declaração de Objetivos
 Diagrama de Contexto
 Lista de Eventos
 Dicionário de Dados Preliminar (opcional)

Diagrama de contexto
 Diagrama de transição de estados ( DTE )

Modelo comportamental
DFD Particionado
Diagrama ER (DER)
Diagrama de Transição de Estado (DTE)
Dicionário de Dados Preliminar (opcional)
Especificações de processos

Diagrama de fluxo de dados ( DFD )

Diagrama Entidade e Relacionamento ( DER )
ANÁLISE ORIENTADA A OBJETO
O conceito de orientação a objetos surgiu com o intuito de minimizar os problemas
encontrados até então na criação de softwares complexos, projetados por meio de
decomposição funcional e sub-rotinas.
É baseada na decomposição do sistema de acordo com os objetos que serão
manipulados por este.
 Ela oferece os principais benefícios: uma visão do sistema mais próximo do mundo
real;
 ”uma nova maneira de pensar os problemas utilizando modelos organizados a partir
de conceitos do mundo real (...)”; para Rumbaugh
“Orientação a Objetos é um paradigma de análise, projeto e programação de
sistemas de software baseado na composição e interação entre diversas unidades de
software chamadas de objetos.
ANÁLISE ORIENTADA A OBJETO
CLASSIFICAÇÃO: formar grupos de objetos com características e
comportamentos semelhantes
ABSTRAÇÃO: consiste na seleção de alguns aspectos de domínio do problema a
modelar, desconsiderando os irrelevantes para o nível de abstração em questão
OBJETO: é uma entidade real ou abstrata, que modela um conceito presente na
realidade humana, ocupando espaço físico ou lógico. Facilita a compreensão do
mundo real e oferece uma base real para implementação em computador
CLASSE: é a representação de um conjunto de coisas reais ou abstratas que são
reconhecidas como sendo do mesmo tipo
Metodologias de Análise Orientação a
Objeto
 Booch
 Jacobson
 Coad/Yourdon
 Shlaer-Mellor
 Rumbaugh
 Wirfs-Brock
ENGENHARIA DE SOFTWARE
Concentra-se nos aspectos práticos da produção de um sistema
de software, enquanto a ciência da computação estuda os fundamentos
teóricos dos aspectos computacionais
• Processo de software, ou processo de engenharia de software, é uma
sequência coerente de práticas que objetiva o desenvolvimento ou
evolução de sistemas de software
• Um MODELO de processo de desenvolvimento de software, ou
simplesmente modelo de processo, pode ser visto como uma
representação, ou abstração dos objetos e atividades envolvidas no
processo de software.
MODELO CASCATA
Levantamento e análise de
requisitos

Análise e Projeto de
Sistemas

Implementação

Testes

Implantação

Manutenção
PROTOTIPAÇÃO
MODELO ESPIRAL
MODELO ÁGIL
 TRADICIONAL
Processos definidos
Planejamento rígido
Maior foco em processos do que no produto
Feedbacks não são essenciais
Documentação extensa
Inibe a comunicação entre as pessoas
Planejamento prevê um trabalho extenso, com a entrega do
produto somente nos estágios finais do cronograma (não
evita conflitos com cliente)
Conceito de que “entradas iguais sempre geram saídas iguais” Conceito de que “entradas iguais geram saídas diferentes”
Atividades realizadas sequencialmente. Testes executados
somente no final, quando “tudo” estiver pronto
Baseado na definição de todas as etapas do trabalho
Resistência a mudanças
Decisões tomadas em uma abordagem top-down
AGIL
Processos empíricos
Maior liberdade no planejamento das ações
Menos formalidade e maior ênfase no produto
Feedbacks são essenciais
Documentação necessária
Estimula a comunicação entre as pessoas
Entregas de partes do projeto de forma contínua e
incremental (iterações) com o objetivo de obter um
rápido feedback do cliente sobre o andamento do projeto
Atividades realizadas paralelamente. Testes executados
durante todo o processo, equipe de testes mais presente
em todo os pontos de desenvolvimento
Baseado na experiência e controlado através de inspeção
e adaptação contínua
Flexibilidade e postura positiva diante da necessidade de
mudanças (mesmo em fases finais do projeto)
Liberdade para o time tomar decisões em conjunto
 AGIL x Tradicional :
VANTAGENS
Torna o processo de desenvolvimento estruturado.
Tem uma ordem sequencial de fases
Atividades identificadas nas fases do modelo são
fundamentais e estão na ordem certa
Fases bem definidas
Maior foco no planejamento
A fase seguinte só se inicia, geralmente, caso o cliente É excessivamente sincronizado
aceite os artefatos produzidos na fase anterior
(para o Cascata)
DESVANTAGENS
Não fornece feedback entre as fases e não permite a
atualização ou redefinição das fases anteriores
Não suporta modificações nos requisitos
Não prevê manutenção
Não permite reutilização
Se ocorrer um atraso, todo o processo é afetado
Exigência de que o cliente estabeleça todos os requisitos
no início do projeto
Entrega para o cliente somente no final do projeto. Não
existe entregas parciais
 AGIL x Tradicional : (para o Ágil)
VANTAGENS
Diminuição da expectativa dos clientes por entregas
Rápida adaptação a mudanças
Maior satisfação dos clientes
Entregas menores, porém com alto valor de negócio para os
clientes
Maior comunicação entre os membros do time
Status de cada membro da equipe é transparente aos outros.
Todos sabem quais as atividades do outro
Defeitos, erros ou falhas, sejam críticos ou não, são encontrados
durante todo o ciclo
Todos podem e devem contribuir para o todo. Trabalho em
equipe.
DESVANTAGENS
Pouca documentação
Custo conhecido somente ao longo do projeto. Esse
fato exige que o gestor do projeto dedique mais
tempo no controle dos custos envolvidos
Manutenção de requisitos requer atenção especial,
já que mudanças devem ser acordadas e
documentadas
Inadequada para projetos com equipes muito
grandes. Limita-se o número de membros no time
para melhor organização, planejamento e
gerenciamento
SISTEMAS DE INFORMAÇÃO BASEADOS
EM COMPUTADOR (informatizados)
SISTEMAS DE INFORMAÇÃO BASEADOS
EM COMPUTADOR (informatizados)
Um sistema de informação baseado em computador é um
conjunto único de hardware, softwares, bancos de dados,
telecomunicações, pessoas e procedimentos, que são
configurados para coletar, manipular, armazenar e processar
dados em informações
Fases de desenvolvimento de um sistema
de informação
Levantamento de requisitos

Análise e projeto de sistemas

Implementação

Testes

Manutenção
 LEVANTAMENTOS DE REQUISITOS
Em todo desenvolvimento de software, um aspecto fundamental é a captura dos
requisitos dos usuários. Diversas técnicas podem ser utilizadas:

• Amostragem : Determinar os dados a serem coletados ou descritos

• Investigação :
• Análise de Documentos : (relatórios, formulários, fichas de registros, legislação,
memorandos, quadros de avisos)
• Entrevistas : opiniões, estado atual SI, apuração de detalhes dos procedimentos,
inclusive os informais

• Observação : comportamento e o ambiente da instituição/indivíduo, relação

entre tarefas e entre indivíduos
Levantamento de Requisitos
Requisitos funcionais: definem as funcionalidades e o comportamento do
sistema, mediante a cada entrada, ou seja, é aquilo que descreve o que o sistema
tem que fazer a cada ação de um usuário ou outro sistema.
 o sistema deverá realizar um cadastro de clientes
 Efetuar vendas de produtos
 Emitir relatório de contas a pagar e receber
Levantamento de Requisitos
Requisitos não-funcionais: dizem respeito às características e padrões de
qualidade que o sistema deve oferecer, como por exemplo, desempenho,
confiabilidade, segurança, robustez, portabilidade, usabilidade, entre outra.
Exemplos:
 O software deverá ser uma aplicação Web;
 Somente usuários autorizados deverão ter acessos a essas informações;
 O tempo de resposta das funcionalidades do sistema não deverá ultrapassar 40
segundos;
 A usabilidade do sistema deve ser de fácil aprendizagem.
ANÁLISE DE SISTEMAS
Análise de sistemas propriamente dito tomando como base os
levantamentos da etapa anterior

OBJETO DA DISCIPLINA
Projeto
Domínio da solução procurando estabelecer “como” o sistema fará o
que foi determinado na fase de análise
 Produzida a arquitetura do sistema (maior parte da modelagem do
software)
 Com o as funcionalidades deverão realizar o que foi solicitado
 Seleção de artefatos:
◦ Linguagem de programação, SGBD, interface final do sistema,
distribuição física do software n a empresa, especificação de
hardware.
IMPLEMENTAÇÃO
Etapa de programação do sistema com base nos diagramas e
descrições da etapa de análise, seguindo escolhas, etapas,
ferramentas, modulação, linguagem definidas na etapa de projeto.
 TESTES
Atributos a avaliar
Funcionalidade : Capacidade de um sistema de fornecer as funcionalidades que
satisfazem as necessidades do utilizador;
Confiabilidade : Capacidade do sistema de manter o grau de desempenho esperado;
Usabilidade : Capacidade do sistema de ser compreendido e usado pelos utilizadores;
Eficiência : Capacidade do sistema de utilizar os recursos de forma adequada ao
desempenho
Manutenibilidade : Capacidade do sistema de ser modificado por melhorias, extensões,
correções de erros, etc.
Portabilidade: Capacidade do sistema de ser modificado por melhorias, extensões,
correções de erros, etc.
 TESTES
 Caixa Branca : Esta técnica assenta diretamente sobre o código fonte do software, por
forma a avaliar aspetos tais como:
 teste de condição; teste de fluxo de dados; teste de ciclos; teste de caminhos lógicos;
códigos nunca executados
 Caixa Preta : Ao contrário do que acontece com o teste caixa branca, o teste caixa preta
ignora o comportamento interno do sistema e foca-se, antes, na avaliação do
comportamento externo. Neste caso, dados de entrada são fornecidos ao sistema para
processamento e o resultado obtido é comparado com o resultado esperado.
 Caixa Cinzenta : Combina os métodos dos dois testes anteriores. através do uso desta
técnica é possível aceder ao código fonte e aos algoritmos do software de forma a definir
os casos de teste a ser aplicados, posteriormente, ao teste do comportamento externo do
sistema
 TESTES
 Regressão: Esta técnica é aplicada a novas versões de software. A regressão consiste na aplicação
de todos os testes já aplicados a versões ou ciclos de teste anteriores de um sistema, a uma nova
versão ou a um novo ciclo. Para garantir a produtividade e a viabilidade dos testes, é recomendado
que se faça a automação dos mesmos
Técnicas não funcionais : Ao contrário do que acontece com todas as técnicas anteriores, as
técnicas não funcionais permitem avaliar aspetos não funcionais
• Teste de desempenho - procura encontrar o limite de processamento de dados no melhor
desempenho do sistema;
• Teste de carga - procura encontrar o limite de processamento de dados até que o sistema não
consiga mais;
• Teste de usabilidade - testa a capacidade do sistema de ser compreendido e utilizado;
• Teste de confiabilidade - testa se o sistema é capaz de recolher, processar e apresentar os dados
de forma correta (de acordo com as especificações iniciais);
• Teste de recuperação - testa a capacidade de recuperação de um sistema após uma falha.
IMPLANTAÇÃO
Em resumo, as etapas:
Parametrização e customização
 Instalação do código
 Migração de dados
 Testes da integração
 Teste de operação
 Validação (homologação) e liberação do sistema
MANUTENÇÃO
A manutenção permite resolver problemas como:
 Bugs no sistema;
 Mudanças nos processos;
 Alterações nos requisitos dos stakeholders/utilizadores;
 Problemas técnicos com hardware e/ou software;
 Mudanças no ambiente.
MANUTENÇÃO
Tipos manutenção
Manutenção evolutiva (para melhoria) - o foco é o aperfeiçoamento do
desempenho de funções;
 Manutenção para adaptação - o foco é modificação de funções existentes ou o
acréscimo de novas funcionalidades que decorrem de mudanças no ambiente
ou do aparecimento de novas necessidades (eg. novas leis);
 Manutenção corretiva - o foco é a correção de bugs e erros lógicos que não
foram detetados nos testes;
 Manutenção preventiva - o foco é reduzir as oportunidades para falha do
sistema ou, ainda, aumentar a sua vida útil
 AULA 2
ANÁLISE E
PROJETO DE SISTEMAS
ALEXANDRE DOMINGUES GONÇALVES
UML
Surgiu da união de três métodos de modelagem (meados da década de 90):
• Método de Booch
• Método OMT (Object Mod eling Technique) de Jacobson
• Método OOSE (Object -Oriented Software Engineering) de Rumbaugh
 Amplo apoio da Rational Software
 Os Três Amigos: surgimento da primeira versão da UML (1996)
 Várias empresas atuantes na área de modelagem e desenvolvimento de
software passaram a contribuir para o projeto
 1997: UML é adotada pela OMG (Object Management Group)
 2005: versão 2.0 da linguagem (www.uml.org)
UML
UML – Unified Modeling Language (Linguagem de Modelagem Unificada)
 Linguagem visual utilizada para modelar softwares baseados no paradigma da
orientação a objetos
 Aplicada a todos os domínios de aplicação
 Linguagem padrão de modelagem adotada internacionalmente pela indústria
de engenharia de software
 Auxilia os engenheiros de software a definirem as características do sistema
(requisitos, comportamento, estrutura lógica etc.) antes de seu desenvolvimento
Por que tantos diagramas?
 Oferecer múltiplas visões do sistema a ser modelado, analisando-o e
modelando-o sob diversos aspectos
 Cada diagrama da UML analisa o sistema, ou parte dele, sob uma determinada
óptica
 O uso de vários diagramas permite que falhas sejam descobertas, diminuindo
a possibilidade da ocorrência de erros futuros
UML
Diagrama de Casos de Uso
Diagrama de Classes
Diagrama de Objetos
Diagrama de Pacotes
Diagrama de Sequência
Diagrama de Comunicação
Diagrama de Máquina de Estados
Diagrama de Atividade
Diagrama de Visão Geral de Interação
Diagrama de Componentes
Diagrama de Implantação
Diagrama de Estrutura Composta
Diagrama de Tempo ou de Temporização
DIAGRAMA DE CASOS DE USO
DIAGRAMA DE CASOS DE USO
DIAGRAMA DE CASOS DE USO

CASOS DE USO
DIAGRAMA DE CASOS DE USO

CASOS DE USO
DIAGRAMA DE CASOS DE USO
DIAGRAMA DE CASOS DE USO
DIAGRAMA DE CASOS DE USO
DIAGRAMA DE CASOS DE USO
DIAGRAMA DE CASOS DE USO
DIAGRAMA DE CASOS DE USO
DIAGRAMA DE CASOS DE USO
DIAGRAMA DE CASOS DE USO
DIAGRAMA DE CASOS DE USO
DIAGRAMA DE CASOS DE USO
DIAGRAMA DE CASOS DE USO
DIAGRAMA DE CASOS DE USO
DIAGRAMA DE CASOS DE USO
DIAGRAMA DE CASOS DE USO
DIAGRAMA DE CASOS DE USO
DIAGRAMA DE CASOS DE USO
CASOS DE USO – ENCONTRANDO OS
ATORES
Exemplo:
◦ Loja de CDs Identificando os atores – Uma loja de CDs possui discos para venda. Um cliente pode
comprar uma quantidade ilimitada de discos para isto ele deve se dirigir à loja. A loja possui um
atendente cuja função é atender os clientes durante a venda dos discos. A loja também possui um
gerente cuja função é administrar o estoque para que não faltem discos. Além disso é ele quem dá folga
ao atendente, ou seja, ele também atende os clientes durante a venda dos discos
CASOS DE USO – ENCONTRANDO OS
ATORES
Exemplo:
◦ Loja de CDs Identificando os atores – Uma loja de CDs possui discos para venda. Um cliente pode
comprar uma quantidade ilimitada de discos para isto ele deve se dirigir à loja. A loja possui um
atendente cuja função é atender os clientes durante a venda dos discos. A loja também possui um
gerente cuja função é administrar o estoque para que não faltem discos. Além disso é ele quem dá folga
ao atendente, ou seja, ele também atende os clientes durante a venda dos discos
CASOS DE USO – ENCONTRANDO OS
ATORES
EXEMPLO – ENCONTRANDO OS CASOS DE
USO
Exemplo:
◦ Loja de CDs Identificando os atores – Uma loja de CDs possui discos para venda. Um cliente pode
comprar uma quantidade ilimitada de discos para isto ele deve se dirigir à loja. A loja possui um
atendente cuja função é atender os clientes durante a venda dos discos. A loja também possui um
gerente cuja função é administrar o estoque para que não faltem discos. Além disso é ele quem dá folga
ao atendente, ou seja, ele também atende os clientes durante a venda dos discos
EXEMPLO – ENCONTRANDO OS CASOS DE
USO
Exemplo:
◦ Loja de CDs Identificando os atores – Uma loja de CDs possui discos para venda. Um cliente pode
comprar uma quantidade ilimitada de discos para isto ele deve se dirigir à loja. A loja possui um
atendente cuja função é atender os clientes durante a venda dos discos. A loja também possui um
gerente cuja função é administrar o estoque para que não faltem discos. Além disso é ele quem dá
folga ao atendente, ou seja, ele também atende os clientes durante a venda dos discos
EXEMPLO – ENCONTRANDO OS CASOS DE
USO
EXEMPLO – RELACIONAMENTOS
EXEMPLO – RELACIONAMENTOS
EXEMPLO – EXTENSÃO