Análise de Sistemas Resumo

As grandes transforma��es ocorridas nos �ltimos anos, impulsionadas pelo avan�o da
tecnologia provocaram a passagem da antiga sociedade industrial para uma nova

sociedade baseada na informa��o e no conhecimento.
Nos dias de hoje, a empresa que disp�e de mais informa��es sobre seu processo est�
em vantagem em rela��o a suas competidoras.
Um Pouco de Hist�ria:
Evolu��o:
- D�cada de 1950/60: os sistemas de software eram bastante simples e dessa forma as
t�cnicas de modelagem tamb�m;
- Era a �poca dos fluxogramas e diagramas de m�dulos;
- D�cada de 1970: nessa �poca houve uma grande expans�o do mercado computacional.
Sistemas complexos come�avam a surgir e, por consequ�ncia, modelos mais robustos
foram propostos. Nesse per�odo surge a programa��o estruturada e no final da d�cada
a an�lise e o projeto estruturado;
- D�cada de 1980: surge a necessidade de interfaces homem-m�quina mais
sofisticadas, o que originou a produ��o de sistemas de software mais complexos;
- A an�lise estruturada se consolidou na primeira metade dessa d�cada e em 1989
Edward Yourdon lan�a o livro An�lise Estruturada Moderna, tornando-o uma refer�ncia
no assunto;
- D�cada de 1990: nesse per�odo surge um novo paradigma de modelagem, a An�lise
Orientada a Objetos, como resposta a dificuldades encontradas na aplica��o da
An�lise Estruturada a certos dom�nios de aplica��o;
- Final da d�cada de 1990 e momento atual: o paradigma da orienta��o a objetos
atinge a sua maturidade. Os conceitos de padr�es de projetos (design patterns),
frameworks de desenvolvimento, componentes e padr�es de qualidade come�am a ganhar
espa�o;
- Nesse per�odo surge a Linguagem de Modelagem Unificada (UML), que � a ferramenta
de modelagem utilizada no desenvolvimento atual de sistemas.
Mas o que � software?

- Instru��es que quando executadas produzem a fun��o e o desempenho desejados;
- Estruturas de dados que possibilitam que os programas manipulem adequadamente a
informa��o;
- Documentos que descrevem a opera��o e o uso dos programas.
Caracter�sticas do Software:
- Desenvolvido ou projetado por engenharia, n�o manufaturado no sentido cl�ssico;
- N�o se desgasta, mas se deteriora;
- A maioria � feita sob medida em vez de ser montada a partir de componentes
existentes;
Crise de Software:
Refere-se a um conjunto de problemas encontrados no desenvolvimento de software:
- As estimativas de prazo e de custo frequentemente s�o imprecisas;
* "N�o dedicamos tempo para coletar dados sobre o processo de desenvolvimento de
software."
* "Sem nenhuma indica��o s�lida de produtividade, n�o podemos avaliar com precis�o
a efic�cia de novas ferramentas, m�todos ou padr�es."
- A produtividade das pessoas da �rea de software n�o tem acompanhado a demanda por
seus servi�os;
* "Os projetos de desenvolvimento de software normalmente s�o efetuados apenas com
um vago ind�cio das exig�ncias do cliente."
- A qualidade de software �s vezes � menos que adequada;
* S� recentemente come�am a surgir conceitos quantitativos s�lidos de garantia de
qualidade de software;
- O software existente � muito dif�cil de manter;
* A tarefa de manuten��o devora o or�amento destinado ao software;
* A facilidade de manuten��o n�o foi enfatizada como um crit�rio importante.
Crise de Software � Resumindo
- Estimativas de prazo e de custo;
- Produtividade das pessoas
- Qualidade de software
- Software dif�cil de manter
Causas dos Problemas Associados � Crise de Software;

- Pr�prio car�ter do software
* O software � um elemento de sistema l�gico e n�o f�sico;
* Consequentemente o sucesso � medido pela qualidade de uma �nica entidade e n�o
pela qualidade de muitas entidades manufaturadas;
* O software n�o se desgasta, mas se deteriora;
- Falhas das pessoas respons�veis pelo desenvolvimento de software;
* Gerentes sem nenhum background em software;
* Os profissionais da �rea de software t�m recebido pouco treinamento formal em
novas t�cnicas para o desenvolvimento de software;
* Resist�ncia a mudan�as;
- Mitos do software;
* Propagaram desinforma��o e confus�o
*- Administrativos
*- Cliente
*- Profissional
Mitos do Software (Administrativos)

- Mito: J� temos um manual repleto de padr�es e procedimentos para a constru��o de
software. Isso n�o oferecer� ao meu pessoal tudo o que eles precisam saber?
- Realidade:
* Ser� que o manual � usado?
* Os profissionais sabem que ele existe?
* Ele reflete a pr�tica moderna de desenvolvimento de software? Ele � completo?
- Mito: Meu pessoal tem ferramentas de desenvolvimento de software de �ltima

gera��o, afinal compramos os mais novos computadores;
- Realidade: � preciso muito mais do que os mais recentes computadores para se
fazer um desenvolvimento de software de alta qualidade;
- Mito: Se n�s estamos atrasados nos prazos, podemos adicionar mais programadores e
tirar o atraso;
- Realidade: O desenvolvimento de software n�o � um processo mec�nico igual �
manufatura. Acrescentar pessoas em um projeto torna-o ainda mais atrasado;
- Pessoas podem ser acrescentadas, mas com crit�rios. Somente de uma forma
planejada;
Mitos do Software (Cliente)

- Mito: Uma declara��o geral dos objetivos � suficiente para se come�ar a escrever
programas � podemos preencher os detalhes mais tarde;
- Realidade: Uma defini��o inicial ruim � a principal causa de fracassos dos
esfor�os de desenvolvimento de software. � fundamental uma descri��o formal e
detalhada do dom�nio da informa��o, fun��o, desempenho, interfaces, restri��es de
projeto e crit�rios de valida��o;
- Mito: Os requisitos de projeto modificam-se continuamente, mas as mudan�as podem
ser facilmente acomodadas, porque o software � flex�vel;
- Realidade: Uma mudan�a, quando solicitada tardiamente num projeto, pode ser maior
do que a ordem de magnitude mais dispendiosa da mesma mudan�a solicitada nas fases
iniciais;
Mitos do Software (Profissional)

- Mito: Assim que escrevermos o programa e o colocarmos em funcionamento nosso
trabalho estar� completo;
- Realidade: Os dados da ind�stria indicam que entre 50 e 70% de todo esfor�o gasto
num programa ser�o despendidos depois que ele for entregue pela primeira vez ao
cliente;
- Mito: Enquanto n�o tiver o programa "funcionando", eu n�o terei realmente nenhuma
maneira de avaliar sua qualidade;
- Realidade: Um programa funcionando � somente uma parte de uma configura��o de
software que inclui todos os itens de informa��o produzidos durante a constru��o e
manuten��o do software. Ex.: Avi�o;
An�lise de Sistemas
- Estudo da organiza��o e funcionamento de uma ou mais atividades, com o objetivo
de gerar um conjunto de a��es informatizada que solucione, da melhor forma
poss�vel, um problema ou automatize uma a��o manual;
- M�todos: proporcionam os detalhes de como fazer para construir o software;
* Planejamento e estimativa de projeto;
* An�lise de requisitos de software e de sistemas;
* Projeto da estrutura de dados;
* Algoritmo de processamento;
* Codifica��o;
* Teste;
* Manuten��o;
- Ferramentas: d�o suporte automatizado aos m�todos;

- Existem atualmente ferramentas para sustentar cada um dos m�todos;
- Quando as ferramentas s�o integradas � estabelecido um sistema de suporte ao
desenvolvimento de software chamado CASE � Computer Aided Software Engineering;
- Procedimentos: constituem o elo de liga��o entre os m�todos e ferramentas;
- Sequ�ncia em que os m�todos ser�o aplicados;
- Produtos que se exige que sejam entregues;
- Controles que ajudam a assegurar a qualidade e coordenar as altera��es;
- Marcos de refer�ncia que possibilitam administrar o progresso do software;
An�lise de sistemas
- Conjunto de etapas que envolve m�todos, ferramentas e procedimentos;
- Essas etapas s�o conhecidas como componentes de ciclos de vida de software;
- Alguns ciclos de vida mais conhecidos s�o: ciclo de vida cl�ssico, prototipa��o,
modelo espiral;
Ciclo de Vida Cl�ssico (Cascata)

- Modelo mais antigo e o mais amplamente usado da engenharia de software;
- Requer uma abordagem sistem�tica, sequencial ao desenvolvimento de software;
Atividades do Ciclo de Vida Cl�ssico

- An�lise de requisitos de software
* O processo de coleta dos requisitos � intensificado e concentrado especificamente
no software;
* Deve-se compreender o dom�nio da informa��o, a fun��o, desempenho e interfaces
exigidos;
* Os requisitos (para o sistema e para o software) s�o documentados e revistos com
o cliente;
- Projeto;
* Tradu��o dos requisitos do software para um conjunto de representa��es que podem
ser avaliadas quanto � qualidade, antes que a codifica��o se inicie;
- Se concentra em 4 atributos do programa:
*- Estrutura de Dados
*- Arquitetura de Software
*- Detalhes Procedimentais
*- Caracteriza��o de Interfaces
- Codifica��o
* Tradu��o das representa��es do projeto para uma linguagem "artificial" resultando
em instru��es execut�veis pelo computador;
- Concentra-se:
*- nos aspectos l�gicos internos do software, garantindo que todas as instru��es
tenham sido testadas;
*- nos aspectos funcionais externos, para descobrir erros e garantir que a entrada
definida produza resultados que concordem com os esperados;
- Manuten��o:
* Provavelmente o software dever� sofrer mudan�as depois que for entregue ao
cliente;
* Causas das mudan�as: erros, adapta��o do software para acomodar mudan�as em seu
ambiente externo e exig�ncia do cliente para acr�scimos funcionais e de desempenho;
Prototipa��o
- Processo que possibilita que o desenvolvedor crie um modelo do software que deve
ser constru�do;
- Idealmente, o modelo (prot�tipo) serve como um mecanismo para identificar os
requisitos de software;
- Apropriado para quando o cliente definiu um conjunto de objetivos gerais para o
software, mas n�o identificou requisitos de entrada, processamento e sa�da com
detalhes;
Atividades da Prototipa��o
- Obten��o dos requisitos: desenvolvedor e cliente definem os objetivos gerais do
software, identificam quais requisitos s�o conhecidos e as �reas que necessitam de
defini��es adicionais;
- Projeto r�pido: representa��o dos aspectos do software que s�o vis�veis ao
usu�rio (abordagens de entrada e formatos de sa�da);
- Constru��o do prot�tipo: implementa��o do projeto r�pido;
- Avalia��o do prot�tipo: cliente e desenvolvedor avaliam o prot�tipo;
- Refinamento dos requisitos: cliente e desenvolvedor refinam os requisitos do
software a ser desenvolvido;
- Ocorre neste ponto um processo de itera��o que pode conduzir a atividade 1 at�
que as necessidades do cliente sejam satisfeitas e o desenvolvedor compreenda o que
precisa ser feito;
- Constru��o de produto: identificados os requisitos, o prot�tipo deve ser
descartado e a vers�o de produ��o deve ser constru�da considerando os crit�rios de
qualidade;
Ciclo de Vida em Espiral

- Engloba as melhores caracter�sticas do ciclo de vida Cl�ssico e da Prototipa��o,
adicionando um novo elemento: a An�lise de Risco;
- Segue a abordagem de passos sistem�ticos do Ciclo de Vida Cl�ssico incorporando-
os numa estrutura iterativa que reflete mais realisticamente o mundo real;
- Pode usar a Prototipa��o, em qualquer etapa da evolu��o do produto, como
mecanismo de redu��o de riscos;
Atividades do Ciclo de Vida em Espiral

- Planejamento: determina��o dos objetivos, alternativas e restri��es;
- An�lise de risco: an�lise das alternativas e identifica��o/ resolu��o dos riscos;
- Constru��o: desenvolvimento do produto no n�vel seguinte;
- Avalia��o do cliente: avalia��o do produto e planejamento das novas fases;
Ciclo de Vida Cl�ssico

- Projetos reais raramente seguem o fluxo sequencial que o modelo prop�e;
- Logo no in�cio � dif�cil estabelecer explicitamente todos os requisitos. No
come�o dos projetos sempre existe uma incerteza natural;
- O cliente deve ter paci�ncia. Uma vers�o execut�vel do software s� fica
dispon�vel numa etapa avan�ada do desenvolvimento;
Prototipa��o
- Cliente n�o sabe que o software que ele v� n�o considerou, durante o
desenvolvimento, a qualidade global e a manutenibilidade a longo prazo;
- N�o aceita bem a ideia que a vers�o final do software vai ser constru�da e
"for�a" a utiliza��o do prot�tipo como produto final;
- Desenvolvedor frequentemente faz uma implementa��o comprometida (utilizando o que
est� dispon�vel) com o objetivo de produzir rapidamente um prot�tipo;
- Depois de um tempo ele familiariza com essas escolhas, e esquece que elas n�o s�o
apropriadas para o produto final;
Ciclo de Vida em Espiral

- �, atualmente, a abordagem mais real�stica para o desenvolvimento de software em
grande escala;
- Usa uma abordagem que capacita o desenvolvedor e o cliente a entender e reagir
aos riscos em cada etapa evolutiva;
- Pode ser dif�cil convencer os clientes que uma abordagem "evolutiva" �
control�vel;
- Exige consider�vel experi�ncia na determina��o de riscos e depende dessa
experi�ncia para ter sucesso;
Resumindo:
- Introdu��o � An�lise de Sistemas
- Crise do software
- Ciclo do software
APOL 1 (corrigido)
(1) - Quanto a CRISE DO SOFTWARE � correto afirmar:
A) As estimativas de prazo e custo subiram.
B) A produtividade dos profissionais de desenvolvimento baixou.
C) A qualidade do software caiu.
D) (x) Todas as alternativas anteriores est�o corretas.
(2) - Considere que voc� trabalhe em uma empresa de desenvolvimento de software e

que a empresa tenha decidido desenvolver um novo editor de texto para colocar no
mercado. Esse editor deve ser um software que forne�a recursos adicionais de apoio
� autoria, embasado no estilo de escrita do usu�rio, o que o torna um software de
funcionalidade mais complexa. Considere que a empresa deseje disponibilizar o
produto no mercado em vers�es que agreguem esse suporte de forma gradativa, fazendo
an�lise de risco para avaliar a viabilidade de desenvolvimento de uma nova vers�o.
Tendo de escolher um modelo de processo para desenvolver esse editor, e conhecendo
as caracter�sticas dos modelos existentes, entre os modelos abaixo, qual � o modelo
apropriado para esse caso?
A) Cascata
B) (x) Espiral
C) RAD (rapid application development)
D) Prototipa��o
(3) - Modelo mais antigo e o mais amplamente usado da engenharia de software,

modelado em fun��o do ciclo da engenharia convencional, requer uma abordagem
sistem�tica e seq�encial do desenvolvimento de software. Essas caracter�sticas s�o
de qual modelo?
A) (x) Cascata
B) Espiral
C) RAD (rapid application development)
D) Cleanroom
(4) - Em Projetos de Software h� ferramentas e frameworks que integram todo o

processo de desenvolvimento de software. Dentre estes, um dos mais utilizados hoje
como forma de padroniza��o e qualidade �:
A) (x) UML.
B) Ferramentas RAD.
C) Ferramentas GUI.
D) Todas as alternativas est�o corretas.
(5) - Engloba as melhores caracter�sticas do ciclo de vida Cl�ssico e da

Prototipa��o, adicionando um novo elemento: a An�lise de Risco. Segue a abordagem
de passos sistem�ticos do Ciclo de Vida Cl�ssico incorporando-os numa estrutura
iterativa que reflete mais realisticamente o mundo real e usa a Prototipa��o, em
qualquer etapa da evolu��o do produto, como mecanismo de redu��o de riscos. Este
modelo �:
A) Cascata.
B) (x) Espiral.
C) RAD (rapid application development).
D) Cleanroom.
(6) - O desenvolvimento, opera��o e manuten��o do software abrange um conjunto de

tr�s elementos fundamentais: M�todos, Ferramentas e Procedimentos. A totalidade das
etapas que se constituem destes elemento comp�em o que chamamos de:
A) (x) Ciclo de Vida do Software.
B) Fases da UML.
D) Ciclos de Desenvolvimento �gil.
(7) - Processo que possibilita que o desenvolvedor crie um modelo do software que
deve ser constru�do.
A) Ciclo de Vida do Software.
B) (x) Prototipa��o.
D) Ciclos de Desenvolvimento �gil.
(8) - De acordo com Sommerville, o software compreende tudo o que � necess�rio para
um sistema computacional funcionar: Programa de computador, documenta��o, arquivos
de configura��o, entre outros, e existe por causa das necessidades de clientes.
Como transformar a necessidades em software?
A) Devem ser consideradas as atividades de como entender as necessidades do
cliente.
B) Planejar a solu��o, implementar a solu��o, validar esta solu��o.
C) Garantir a entrega do produto ao cliente.
D) (x) Todas as alterantivas anteriores est�o corretas.
(9) - No per�odo da d�cada de 1990 surge um novo paradigma de modelagem, como

resposta a dificuldades encontradas na aplica��o da An�lise Estruturada a certos
dom�nios de aplica��o. Qual seria esse tipo de modelagem?
A) An�lise Estruturada.
B) An�lise Essencial.
C) (x) Analise Orientada a Objetos.
D) UML.
(10) - No final dos anos 40 at� os anos 60, quando se iniciou a evolu��o dos
sistemas computadorizados, grande parte dos esfor�os - e consequentes custos - se
concentravam em que?
A) Na An�lise Estruturada.
B) No desenvolvimento do software.
C) (x) No desenvolvimento do Hardware.
D) Na documenta��o do software.
APOL 2 (corrigido)
(1) - Em rela��o � metodologia estruturada,
� correto afirmar que:
A) A An�lise Estruturada � uma t�cnica de modelagem da estrutura da organiza��o.
B) O Projeto do Fluxo de Dados (DFDesign) � utilizado no planejamento da
implanta��o.
C) Diagrama de Fluxo de Dados (DFD) n�o tem utilidade para a An�lise de Requisitos.
D) (x) A An�lise Estruturada � uma t�cnica de modelagem do conte�do e do fluxo de
informa��o
(2) - An�lise Essencial � o modelo do que o sistema tem que fazer, de forma a
satisfazer os requisitos do utilizador, com o m�nimo poss�vel de informa��o sobre
como o sistema deve ser implementado.
As alternativas a seguir apresentam as ferramentas que fazem parte do Modelo
Essencial, � exce��o de uma. Assinale-a.
A) Diagrama Entidade Relacionamentos
B) DFD por Eventos
C) (x) Fluxograma
(3) - Num diagrama de fluxo de dados DFD,

assinale a alternativa correta
A) Qualquer fluxo de dados tem sempre uma origem e um destino, sendo sempre um
deles necessariamente um dep�sito de dados
B) Entre dois dep�sitos de dados e entre duas entidades externas deve haver pelo
menos uma liga��o entre um dep�sito de dados e uma entidade externa
C) O dicion�rio de dados, na descri��o de componentes, permite utilizar o s�mbolo
"?" para enquadrar componentes que s�o utilizados alternativamente.
D) (x) O destino de um fluxo de um determinado processo pode ser outro processo, um
dep�sito de dados ou uma entidade externa
(4) - Como se defne a implementa��o de um sistema orientado a objetos?

Assinale a alternativa correta
A) (x) Implementa-se um conjunto de classes que defne os objetos presentes no
sistema
B) O sistema � definido atrav�s de comportamentos estruturais
C) A implementa��o � feita atrav�s de um c�digo estruturado
D) Implementa-se um conjunto de tabelas no banco de dados que define a estrutura do
sistema
(5) - S�o conceitos chaves do paradigma Orientado a Objetos:

A) Classes, objetos, regras e fun��es
B) Casamento de padr�es, heran�a, classes e objetos
C) (x) Classes, objetos, heran�a e polimorfismo
D) Polimorfismo por inclus�o, casamento de padr�es, transpar�ncia referencial e
heran�a.
(6) - Fl�vio pretende desenvolver um software seguindo os est�gios do modelo em

cascata proposto por Sommerville, em raz�o de pondera��es que faz em rela��o a
outros modelos quanto � solu��o de um problema que se apresenta.
Desta forma ele definiu em seu cronograma, na ordem apresentada pelo autor, as
seguintes etapas do ciclo de vida de software:
A) Projeto de sistema e software; Defini��o de requisitos; Implementa��o e teste de
unidade; Integra��o e teste de sistema; Opera��o e manuten��o
B) Projeto de sistema e software; An�lise de requisitos; Engenharia de requisitos;
Implanta��o; Testes de sistemas; Opera��o e manuten��o
C) Defini��o de requisitos; Engenharia de requisitos; Integra��o e teste de
sistema; Projeto de sistema e software; Implementa��o e teste de unidade; Opera��o
e manuten��o; Integra��o e teste de sistema.
D) (x) Defini��o de requisitos; Projeto de sistema e software; Implementa��o e
teste de unidade; Integra��o e teste de sistema; Opera��o e manuten��o
(7) - Na �rea de Engenharia de Software, uma Ferramenta CASE pode ser utilizada
como:
A) (x) apoio automatizado aos processos de software e fornecimento de informa��es
sobre o software que est� sendo desenvolvido
B) apoio ao processo de manuten��o dos reposit�rios de dados que s�o gerados ap�s a
fase de implanta��o do software
C) apoio ao processo de seguran�a de software, a fim de evitar que usu�rios mal-
intencionados acessem indevidamente o software
D) apoio educacional para treinamento automatizado dos usu�rios do software
(8) - Sobre a engenharia de software, considere:

I. Atualmente todos os problemas na constru��o de software de alta qualidade no
prazo e dentro do or�amento foram solucionados.
II. Ao longo dos �ltimos 50 anos, o software evoluiu de um produto de ind�stria
para um ferramental especializado em solu��o de problemas e an�lise de informa��es
espec�ficas.
III. Todo projeto de software � iniciado por alguma necessidade do neg�cio.
IV. O intuito da engenharia de software � fornecer uma estrutura para a constru��o
de software com alta qualidade.
Est� correto o que consta em:
A) (x) III e IV, somente
B) II e III, somente
C) I, II e IV, somente
D) II, III e IV, somente
(9) - A Engenharia de Requisitos tem como objetivo criar e manter um documento de

requisitos. Ela Possui 4 sub-processos. S�o eles:
A) (x) Estudo de viabilidade, elicita��o e an�lise de requisitos, especifica��o e
valida��o de requisitos
B) Caso de Uso, elicita��o e an�lise de requisitos, especifica��o e valida��o de
requisitos
C) Manuten��o, An�lise, Teste, e Casos de Uso
D) Matriz de Rastreabilidade, Casos de Uso, Analise de requisitos e valida��o de
Requisitos
(10) - O desenvolvimento de softwares demanda que seus desenvolvedores tenham a

possibilidade de estudar esse sistema a partir de v�rias perspectivas. De acordo
com os autores, um sistema pode ser descrito por meio de tr�s vis�es independentes.
Uma delas descreve o sistema do ponto de vista externo como um conjunto de
intera��es entre o pr�prio sistema e os agentes externos ao sistema.
Essa vis�o � criada inicialmente e direciona o desenvolvimento das demais vis�es do
sistema.
Essa abordagem/documento � conhecida(o) como:
A) Requisitos
B) Viabilidade
C) (x) Caso de Uso
D) Processos
Grandes mudan�as nos �ltimos anos, e o avan�o da tecnologia, levaram a uma passagem
da antiga sociedade industrial para a sociedade baseada em informa��o.
Nos dias de hoje, a empresa que disp�e de mais informa��es sobre seu processo est�
em vantagem em rela��o a suas competidoras.
Evolu��o:
- Anos 60: Textos e fluxogramas para especificar a l�gica dos sistemas;
- Meados de 70: An�lise estruturada: m�todo que utiliza os componentes e conceitos
da programa��o estruturada (Tom DeMarco, Gane & Sarson);
- Anos 80: Surge a abordagem de estrutura de dados como forma de modelar sistemas;
- Anos 90: Surge a abordagem orientada a objetos.
An�lise Estruturada
A an�lise estruturada � uma abordagem sistem�tica para fazer a an�lise de um
sistema de modo a produzir uma especifica��o funcional;
Componentes do Modelo Estruturado

- Diagrama de Fluxo de Dados (DFD): representa��o gr�fica da rede de processos
interligados;
- Dicion�rio de Dados: descri��o das interfaces;
- Especifica��o dos Processos: descri��o do que cada processo faz.
Diagrama de Fluxo de Dados (DFD)

- Forma gr�fica de mostrar:
* a interdepend�ncia dos processos que comp�em um sistema;
* os fluxos de dados entre elas;
* arquivos l�gicos de dados � dep�sito de dados;
* entidades externas
DFDs desenvolvidos em n�veis hier�rquicos

- Um DFD n�o deve ter mais de 7+/�2 processos (A4);
- O DFD de um Sistema de Informa��o � desenvolvido de acordo com uma decomposi��o
hier�rquica nos seguintes n�veis (diagramas);
* Diagrama de contexto: diagrama de vis�o mais elevada. � um �nico processo
representando o sistema inteiro e fluxos de dados que representam as interfaces com
o exterior;
* Diagrama 0 � vis�o global do sistema;
*- Vis�o de alto n�vel dos principais processos do sistema e as liga��es entre
esses processos;
- DFDs de n�vel n-1 � detalhe do sistema;
- Sistema complexidade baixa -> 2 a 3 n�veis;
- Sistema complexidade m�dia -> 3 a 6 n�veis;
- Sistema complexo -> 5 a 8 n�veis;
Processo
- Representa um transformador de informa��es que resida dentro dos limites do
sistema a ser modelado;
Entidade externa
- Representa um produtor ou consumidor de informa��es que resida fora dos limites
do sistema a ser modelado;
Fluxo de dados
- Representa o deslocamento de um item de dado ou cole��o de itens de dados;
Dep�sito de dados
- Representa um reposit�rio de dados que s�o armazenados para serem usados em um ou
mais processos;
O dicion�rio de dados
- Proposto como gram�tica quase formal para descrever o conte�do de objetos
definidos durante a an�lise estruturada;
- A maioria dos DD cont�m as seguintes informa��es;
- Nome: o nome principal do item de dados, do dep�sito de dados ou de uma entidade
externa;
- Alias: outros nomes usados para a primeira entrada;
- Onde � usado/Como � usado: listagem dos processos que usam o item de dados e como
ele � usado;
- Ex.: entrada no processo, sa�da do processo;
- Descri��o de conte�do: nota��o para representar o conte�do;
- Informa��o complementar: outras informa��es sobre tipos de dados, dom�nios,
restri��es ou limita��es;
Diagrama de Transi��o de Estados (DTE)

- O Diagrama de Transi��o de Estados serve para especificar comportamentos do
sistema em rela��o a eventos que ele recebe;
DTE � Elementos
- S�o: estado, transi��o e a��o;
- As setas indicam como o sistema reage a eventos quando eles passam pelos estados
do sistema.
Estados T�picos
- Aguardando o usu�rio introduzir sua senha;
- Aguardando o pr�ximo comando;
- Aguardando dados para instrumento;
- Acelerando o motor;
- Aquecendo uma mistura qu�mica;
- Misturando ingredientes;
- Enchendo o tanque;
- Ocioso.
An�lise Essencial
O Desenvolvimento de um Sistema
Ciclo de vida do desenvolvimento de sistemas
An�lise -> Projeto -> Implementa��o
- A an�lise essencial, prop�e o particionamento do sistema por eventos;
- Um evento pode ser definido informalmente como um acontecimento do mundo externo,
que requer uma resposta do sistema;
- Um est�mulo � um ativador de uma fun��o do sistema. � a forma como o evento age
sobre o sistema;
- Uma resposta � o resultado gerado pelo sistema devido � ocorr�ncia de um evento;
Defini��es
- Processo: conjunto de atividade que produz, modifica ou atribui qualidade �s
informa��es;
- Dep�sito de dados: conjunto de informa��es armazenadas pelo processo que ser�o
utilizadas por algum processo;
- Entidade externa: � algo situado fora do escopo do sistema, que � fonte ou
destino das suas informa��es;
- Fluxo de dados: o nome deve expressar o significado do conjunto de informa��es
que est� fluindo.
Miniespecifica��o
- A miniespecifica��o define a forma pela qual os fluxos de dados de entrada s�o
transformados em fluxos de dados de sa�da, independente do fato da fun��o ser
executada manualmente ou por outra forma de implementa��o;
- Em rela��o ao segundo aspecto, as principais t�cnicas de especifica��o s�o:
* portugu�s estruturado;
* pseudoc�digo;
* tabela de decis�o;
* �rvore de decis�o.
Diagrama Entidade
- O diagrama entidade relacionamento � um modelo diagram�tico que descreve o modelo
de dados de um sistema com alto n�vel de abstra��o. Principal representa��o do
Modelo de Entidades e Relacionamentos.
DER � Componentes
- Composto de poucos s�mbolos gr�ficos que representam relacionamentos do banco;
- Ret�ngulo: � a entidade do BD, que muito provavelmente ser� uma tabela quando o
banco for criado;
- Losango: representa o relacionamento entre as entidades;
- Tri�ngulo: representa as especializa��es;
- Bolinhas: representa os atributos;
- Chaves prim�rias: uma chave prim�ria � um atributo usado como identificador do
item na entidade. Deve ser �nico;
- Entidades: s�o qualquer elemento que possua atributos que ser�o utilizados na
base de dados, exemplo: CPF.
- Chaves estrangeiras: s�o respons�veis pelo relacionamento entre duas entidades;
- Relacionamento: os relacionamentos ocorrem entre as entidades, e esse conjunto
forma a base do banco de dados;
- O relacionamento 1-1 (um para um) ocorre quando uma se relaciona com no m�ximo 1
para com a outra;
- Os relacionamentos 1-N (um para n, um para muitos) ocorrem quando o
relacionamento da entidade A para entidade B � de no m�ximo 1 e de B para A de no
m�ximo N;
- Os relacionamentos N-N (n para n, muitos para muitos) ocorrem quando tanto de A
para B quanto de B para A o m�ximo de N;
- Um exemplo desse tipo de relacionamento � o de compra, onde um cliente pode
comprar v�rios produtos, e um produto pode ser comprado por v�rios clientes;
Diagrama de Transi��o de Estado

- Em engenharia de software, diagrama de transi��o de estados representa estado ou
situa��o que um objeto pode se encontrar durante a execu��o de processos.
An�lise Orientada a Objetos

- Tem como �nfase encontrar e descrever os objetos � ou conceitos � no dom�nio do
problema que � a �rea de conhecimento espec�fica na qual um sistema de software
est� sendo desenvolvido;
- Nos m�todos tradicionais de an�lise, o comportamento do sistema e seus dados eram
considerados separadamente;
- Com orienta��o a objetos, comportamento e dados s�o integrados, assim
encapsulando detalhes internos de um objeto dos demais;
Caracter�sticas
- Concentra-se nos aspectos essenciais do objeto sem detalhamento, focando em suas
caracter�sticas e o que ele faz;
- Impede que um sistema se torne t�o interdependente;
- Combina estrutura (dados) e comportamento (fun��es) em um �nico objeto;
- Compartilha elementos estruturais e de comportamento com objetos de n�veis
inferiores;
- Enfatiza estrutura de objetos ao inv�s da estrutura de procedimentos;
Conceitos
- Objeto: cada conceito � uma ideia que temos do mundo. Essas coisas as quais
nossos conceitos se aplicam s�o denominados objetos. Um objeto pode ser real ou
abstrato, exemplo: avi�o;
- Classe: � a representa��o do objetos com seus atributos e m�todos;
- M�todos ou servi�os: as a��es que um objeto pode executar, exemplos: latir,
comer, sentar, dormir etc.;
- Atributos: s�o caracter�sticas que descrevem o objeto, exemplos: objeto: c�o �
possui nome, idade, peso, cor etc.;
- Abstra��o: s� deve ser representado aquilo que vai ser usado. Nos objetos s�o
representadas somente as caracter�sticas que s�o relevantes para o problema em
quest�o, exemplo: cor dos olhos (toda pessoa tem) � n�o � relevante para um sistema
de folha de pagamento;
- Encapsulamento: os dados e os processos que tratam esses dados est�o
"encapsulados" numa �nica entidade. Os objetos agem como uma �caixa preta�, se
utiliza sem precisar saber como ele funciona;
- Hierarquia de classes: classe que tem caracter�sticas comuns e que podem fazer
parte de uma classe (categoria) maior;
- Classes ancestrais: classes das quais as outras dependem;
- Classes descendentes: as classes originadas a partir de outra;
- Heran�a: significa que todos os atributos e m�todos programados no ancestral j�
estar�o automaticamente presentes em seus descendentes sem necessidade de
reescrev�-los;
- Polimorfismo: � o princ�pio relacionado com as diferentes formas de um objeto;
- O polimorfismo pode ser visto no exemplo abaixo, onde se pode instanciar o objeto
janela de v�rias formas: Janela(), Janela(1 x 2, 2), Janela(1 x 2, 2, azul);
- Agrega��o: � um mecanismo que permite a constru��o de uma classe agregada a
partir de outras classes componentes, exemplo: casa;
- Associa��o: � usada para agrupar objetos que ocorrem em algum ponto no tempo ou
sob circunst�ncias similares. A associa��o � modelada atrav�s de uma conex�o de
ocorr�ncias;
An�lise Estruturada
- Dimens�o exata das necessidades
- Exp�e o que � feito por gr�ficos
- Dirigido para uma ferramenta
- Exige an�lise de cima para baixo atrav�s de refinamentos
An�lise Essencial
- Os eventos s�o a pedra fundamental dos sistemas
- Especifica��o de um sistema deve come�ar pela identifica��o dos eventos
An�lise Orientada a Objetos

- A ess�ncia � enfatizar, considerar um dom�nio de problema e uma solu��o l�gica,
segundo a perspectiva de objetos (coisas, conceitos e entidades);
Por que usar Orienta��o a Objetos?

- Atualmente temos ferramentas para sua utiliza��o (integrando especifica��o e
implementa��o)
- Praticamente todas as ferramentas novas de programa��o permitem suporte a sua
utiliza��o
- Produtividade em fun��o do reuso
- Produ��o de c�digos mais f�ceis de serem entendidos
- Adequada a constru��o de sistemas distribu�dos e para aplica��es voltadas �
Internet
Dificuldade
- Usu�rios n�o pensam em seus problemas de forma orientada a objetos
- Requisitos n�o s�o orientados a objetos
APOL 3 (corrigido)
(1) - A Engenharia de Software se preocupa em sistematizar o desenvolvimento
atrav�s de modelos, t�cnicas e ferramentas para o produto e para o processo.
Com essa afirma��o podemos dizer ent�o que a Engenharia de Software �:
A) � uma metodologia de desenvolvimento de software.
B) � um processo de desenvolvimento de software.
C) (x) � uma disciplina da engenharia dedicada a todos os aspectos da produ��o de
software.
D) � um t�pico de desenvolvimento de software.
(2) - Podemos dividir a Engenharia de Software em algumas categorias.

Assinale a alternativa que contempla a separa��o correta:
A) Ferramentas Case, Procedimentos e Testes.
B) (x) M�todos, Ferramentas e Procedimentos.
C) M�todo Cl�ssico, Ferramentas e Prototipa��o.
D) Testes, M�todos, Procedimentos e Ferramentas.
(3) - Dentro dos princ�pios da Engenharia de Software podemos destacar fases que
completam o ciclo de vida do sistema.
Estas fases s�o apresentadas em qual das alternativas a seguir?
A) (x) Defini��o, Desenvolvimento, Opera��o e Retirada.
B) Levantamento, Defini��o, Codifica��o, Testes e Manuten��o.
C) Distribui��o, Instala��o, Utiliza��o e Manuten��o.
D) Migra��o, Defini��o, Opera��o e Retirada.
(4) - O estudo de viabilidade � o que indica se o esfor�o em desenvolver a ideia

vale a pena.
Dentre as afirma��es a respeito do estudo de viabilidade abaixo, assinale a que � a
correta.
A) (x) Visa tanto a tomada de decis�o e tamb�m a sugest�o de poss�veis alternativas
de solu��o.
B) Estabelece quais fun��es s�o requeridas pelo sistema e as restri��es sobre a
opera��o e o desenvolvimento do sistema.
C) D� suporte automatizado aos m�todos.
D) � um processo que envolve todas as atividades exigidas para criar e manter o
documento de requisitos de sistema.
(5) - Requisito � uma senten�a identificando uma capacidade, uma caracter�stica

f�sica ou um fator de qualidade que limita um produto ou um processo.
Com rela��o aos Requisitos Funcionais � correto afirmar:
A) (x) Correspondem � lista de todas as coisas que o sistema deve fazer.
B) S�o restri��es e qualidades que se coloca sobre como o sistema deve funcionar.
C) Representam condi��es cuja exig�ncia deve ser satisfeita.
D) Oferecem informa��es para ajudar na decis�o sobre se o projeto pode ou n�o ser
feito.
(6) - Requisito � uma senten�a identificando uma capacidade, uma caracter�stica

f�sica ou um fator de qualidade que limita um produto ou um processo.
Sobre Requisitos podemos afirmar:
A) Objetivam fornecer m�todos para compreender a natureza de um problema.
B) (x) S�o descri��es dos principais recursos de um produto de software, seu fluxo
de informa��es, comportamento e atributos.
C) Visam tanto a tomada de decis�o como a sugest�o de poss�veis alternativas de
solu��o.
D) S�o respons�veis por depend�ncias entre as origens do sistema e o projeto do
sistema.
(7) - Estabelece quais fun��es s�o requeridas pelo sistema e as restri��es sobre a
opera��o e o desenvolvimento do sistema. Objetiva fornecer m�todos para compreender
a natureza de um problema e estabelecer com exatid�o o que um sistema deve fazer.
Estamos falando do:
A) Estudo de Viabilidade.
B) Levantamento de Requisitos.
C) (x) Gerenciamento de Requisitos.
D) Requisito.
(8) - Rastreamento de Requisitos � respons�vel por depend�ncias entre requisitos,

suas origens e projeto do sistema.
S�o tipos corretos Rastreamento de Requisitos:
A) Rastreamento de Origem.
B) Associa��o entre requisitos dependentes.
C) Associa��o dos requisitos com o projeto.
D) (x) Todas as alternativas apresentadas.
(9) - Em um ambiente real de desenvolvimento de software mudan�as s�o inevit�veis.

Em muitos dos casos os requisitos do sistema mudam enquanto o sistema ainda est�
sendo desenvolvido.
Uma forma de ger�ncia dessa situa��o � termos em nosso ambiente de desenvolvimento
um:
A) (x) Controle de Mudan�a.
B) Controle de Requisitos.
C) Controle de Entradas e Sa�das.
D) Controle da Informa��o.
(10) - A maior parte dos requisitos de software para sistemas de informa��o s�o
escritos utilizando-se linguagem natural. Esta falta de formalidade na captura dos
requisitos implica em uma s�rie de potenciais problemas.
Dentre os problemas que podemos encontrar temos a Ambiguidade, que ocorre nas
seguintes situa��es:
A) Requisitos que deixam de fora parte da informa��o necess�ria � sua compreens�o.
B) (x) Falta de clareza ou duplo sentido de frases ou express�es na descri��o o do
requisito. Este tipo de requisito leva a interpreta��es erradas ou inconsistentes
das necessidades reais dos usu�rios.
C) Requisitos que n�o estabelecem claramente qual deve ser a a��o do sistema frente
a uma dada situa��o. De modo geral cont�m palavras do tipo: mas, com exce��o,
apesar e quando.
D) Requisitos que concatenam v�rios requisitos em um s�. Estes requisitos devem ser
separados para facilitar a tarefa de prioriza��o e ger�ncia de mudan�as.
Software
INSTRU��ES: que quando executadas produzem a fun��o e o desempenho desejados.
DOCUMENTOS: que descrevem a opera��o e o uso dos programas.
ESTRUTURAS DE DADOS: que possibilitam que os programas manipulem adequadamente a
informa��o.
Caracter�sticas do Software
- Desenvolvido ou projetado por engenharia, n�o manufaturado no sentido cl�ssico.
- N�o se desgasta mas se deteriora.
- A maioria � feita sob medida em vez de ser montada a partir de componentes
existentes.
Aplica��es do software
- B�SICO cole��o de programas escritos para dar apoio a outros programas.
- DE TEMPO REAL que monitora, analisa e controla eventos do mundo real
- COMERCIAL sistemas de opera��es comerciais e tomadas de decis�es.
- CIENT�FICO E DE ENGENHARIA caracterizado por algoritmos de processamento de
n�meros.
Engenharia de Software
O termo Engenharia de Software surgiu em uma confer�ncia no final da d�cada de 60.
A proposta inicial era a sistematiza��o do desenvolvimento de software, que deveria
ser tratado com engenharia e n�o como arte. Desta forma, a ideia foi propor a
utiliza��o de m�todos, ferramentas e t�cnicas para a produ��o de software
confi�vel, correto e entregue respeitando os prazos e custos definidos.
Metodologias
Instrumentos
- representa��o do software durante seu desenvolvimento;
- Nota��es
- Linguagens
- Crit�rios de Qualidade: Como avaliar o desenvolvimento;
- Exemplos: UML, An�lise estruturada, Analise Essencial;
Ferramentas
Suporte autom�tico aos m�todos
- CASE - Computer Aided Software Engineering;
Ambientes de desenvolvimento:
- ferramentas integradas
- hardware + Software (de suporte) + Banco de Dados
E a evolu��o se baseou nos chamados Ciclos de Vida de Sistemas. Dentro desse

contexto temos as seguintes fases:
Fase de defini��o
- An�lise e Especifica��o
� Estudo de Viabilidade
� Estimativas Planejamento
Fase de desenvolvimento
- Design
� Implementa��o e integra��o
� Verifica��o e Valida��o
Fase de opera��o
- Distribui��o
� Instala��o
� Configura��o
� Utiliza��o
� Administra��o
� Manuten��o
Fase de retirada
- Migra��o
� Reengenharia
� Rengenharia reversa
Conjunto coerente de atividades para especificar, projetar, implementar e testar

sistemas de software.
Objetivos:
- Apresentar os modelos de processo de software.
- Descrever os diferentes modelos de Processos e quando eles s�o utilizados.
- Descrever em formas gerais os modelos de processo para engenharia de requisitos,
desenvolvimento de software, testes e evolu��o.
- Apresentar a tecnologia CASE para apoiar atividades do processo de software.
Engenharia de Requisitos
"Estabelecer quais fun��es s�o requeridas pelo sistema e as restri��es sobre a
opera��o e o desenvolvimento do sistema". Sommerville p. 46.
Objetivos
- Descrever as principais atividades da engenharia de requisitos;
- Descrever Documento de Vis�o;
- Estrutura do Documento de Vis�o;
- Criar e manter um documento de requisitos.
Possui 4 subprocessos
- Estudo de viabilidade;
- Elicita��o e an�lise de requisitos;
- Especifica��o;
- Valida��o de requisitos.
Estudo de viabilidade
- Atividade breve para responder:
* Em que o sistema contribui?
* Pode ser implementado na tecnologia atual?
* Restri��es de prazo e custos
* Pode ser integrado com outros sistemas?
- Atividade da fase de concep��o: Elicita��o e an�lise.

* Obten��o de requisitos
* Abordagem de pontos de vista
* Entrevistas
* Valida��o de Requisitos
Tipos de Requisitos
O que s�o requisitos?
Uma senten�a identificando uma capacidade, uma caracter�stica f�sica ou um fator de
qualidade que limita um produto ou um processo (IEEE 1220-1994).
Requisitos do usu�rios
� algum comportamento ou caracter�stica que o usu�rio deseja do software ou o
sistema como um todo.
S�o escritos pelo pr�prio usu�rio ou levantados por analistas de sistemas.
Divis�o dos Requisitos

Requisito funcional:
- Representa algo que o sistema deve fazer, ou seja, uma fun��o esperada do sistema
que agregue algum valor a seus usu�rios.
Requisito da informa��o:
- Representa a informa��o que o cliente deseja obter do sistema. S�o as respostas
fundamentais do sistema.
Requisitos n�o funcionais:

- S�o a forma como os requisitos funcionais devem ser alcan�ados. Eles definem
propriedades e restri��es do sistema.
Organiza��o dos Requisitos

- Casos de Uso;
- "Manuten��o" de Conceitos;
- Consultas/Relat�rios.
Em Casos de Uso
- O objetivo de listar os casos de uso � ter informa��es de como o sistema interage
e quais consultas e transforma��es s�o necess�rias.
Estudo de Viabilidade
- Estudo que indica se o esfor�o em desenvolver a id�ia vale a pena e visa tanto a
tomada de decis�o como a sugest�o de poss�veis alternativas de solu��o.
- Deve oferecer informa��es para ajudar na decis�o.
- Se o projeto pode ou n�o ser feito.
- Se o produto final ir� ou n�o beneficiar os usu�rios interessados.
- Escolha das poss�veis solu��es
- Deve oferecer informa��es para ajudar na decis�o.
- Se o projeto pode ou n�o ser feito.
- Se o produto final ir� ou n�o beneficiar os usu�rios interessados.
- Poss�veis solu��es.
Elicita��o de Requisitos
- Tamb�m denominada de descoberta de requisitos.
- Envolve pessoal para descobrir o dom�nio da aplica��o, servi�os que devem ser
fornecidos bem como restri��es.
- Deve envolver usu�rios finais, gerentes, pessoal envolvido na manuten��o,
especialistas no dom�nio, etc...(Stakeholders).
Casos de Uso
- Discuta com o cliente o que o sistema far�;
- Identique quem interage com o sistema;
- Identique que interfaces o sistema ter�.
Resumindo:
- Sistemas de software s�o reconhecidamente importantes ativos estrat�gicos para
diversas organiza��es.
- Os sistemas t�m papel vital no apoio aos processos de neg�cio, ent�o �
fundamental que os sistemas funcionem de acordo com os requisitos estabelecidos.
- Neste contexto, uma importante tarefa no desenvolvimento de software � a
identifica��o e o entendimento dos requisitos dos neg�cios que os sistemas v�o
apoiar.
O Sucesso
Clientes satisfeitos
Eles est�o satisfeitos quando voc�:
- atende �s expectativas
- entrega no prazo
- entrega tudo dentro do or�amento
O sucesso come�a com a Ger�ncia de Requisitos.

Como os projetos podem ter sucesso?
1- An�lise do problema
- Entenda o problema
- Obtenha concord�ncia dos envolvidos
2- Levantamento dos requisitos

- Identifique quem usar� o sistema (atores)
- Descubra como o sistema ser� usado (casos de uso)
3- Ger�ncia de requisitos
- Especifique os requisitos completamente
- Gerencie expectativas, mudan�as e erros
- Controle o aumento do escopo
- Defina a equipe e a mantenha informada
Gerenciamento de Requisitos
- � o processo de controlar as mudan�as dos requisitos durante o processo da
engenharia de requisitos e do desenvolvimento do sistema;
- Estudo que indica se o esfor�o em desenvolver a ideia vale a pena e que visa
tanto � tomada de decis�o quanto � sugest�o de poss�veis alternativas de solu��o;
- Deve oferecer informa��es para ajudar na decis�o;
*- Se o projeto pode ou n�o ser feito
*- Se o produto final pode ou n�o beneficiar usu�rios
*- Escolher poss�veis solu��es
- Requisitos s�o inevitavelmente incompletos e inconsistentes
Rastreamento
- Respons�vel por depend�ncias entre requisitos, suas origens e o projeto do
sistema
Rastreamento � Tipos
Rastreamento de origem
- Associa��o entre requisitos e stakeholders que propuseram tais requisitos
Rastreamento de requisitos
- Associa��o entre requisitos dependentes
Rastreamento de projeto
- Associa��o dos requisitos com o projeto
Levantamento e An�lise
- �s vezes conhecidos como levantamento de requisitos ou descoberta de requisitos
- A equipe t�cnica trabalha com o cliente e com os usu�rios para descobrir mais
informa��es sobre o dom�nio da aplica��o, servi�os do novo sistema, desempenho e
restri��es operacionais
- Pode envolver usu�rios finais, gerentes, engenheiros envolvidos em manuten��o,
especialistas no dom�nio etc. (chamados stakeholders do sistema)
Problemas de An�lise de Requisitos

- As pessoas n�o sabem o que realmente querem
- Stakeholders expressam requisitos em seus pr�prios termos
- Stakeholders diferentes podem ter requisitos conflitantes
- Fatores organizacionais e pol�ticos podem influenciar os requisitos do sistema
- Os requisitos mudam durante o processo de an�lise. Novos stakeholders podem
surgir e o ambiente de neg�cio mudar
Atividades do Processo
- Entendimento do dom�nio
- Coleta dos requisitos
- Classifica��o
- Resolver conflitos
- Definir prioridades
- Verificar os requisitos
Revis�o de Requisitos
- Revis�es regulares devem ocorrer durante a formula��o da defini��o dos requisitos
- Cliente e equipe devem estar envolvidos nas revis�es
- As revis�es podem ser formais (com documentos completos) ou informais
- Boa comunica��o entre os clientes, os usu�rios e a equipe pode resolver problemas
em est�gios iniciais
Valida��o dos Requisitos

- Ser� que realmente entendi o que o cliente deseja?
- Devo me certificar de que n�o houve falha em nossa intera��o (comunica��o)
- H� diversas t�cnicas de valida��o
*- Demonstrar que os requisitos definem o sistema que o cliente realmente deseja
*- Custos com erros de requisitos s�o altos. Consertar erros de requisitos ap�s
entrega do sistema pode custar mais de 100 vezes o custo de um erro de
implementa��o
T�cnicas de Valida��o de Requisitos

Revis�es de requisitos
- An�lise manual sistem�tica dos requisitos
Prototipa��o
- Uso de modelo execut�vel do sistema para avaliar requisitos
Gera��o de casos de testes
- Desenvolver testes espec�ficos para os requisitos para avali�-los
An�lise de consist�ncia autom�tica
- Avaliar uma especifica��o dos requisitos
Rastreamento de Requisitos
- O rastreamento de requisitos � um item de qualidade na produ��o de software
- � utilizado para prover relacionamentos entre requisitos, arquitetura e
implementa��o final do sistema
- A rastreabilidade pode ser vista como a habilidade de acompanhare de descrever a
vida de um requisito
T�cnicas e Ferramentas
Poss�vel classifica��o para t�cnicas de rastreabilidade mais comuns
- Podemos relacionar a refer�ncia cruzada de documentos
- Uma das ferramentas mais comuns que podemos utilizar � a matriz de
rastreabilidade
Engenharia de Requisitos
Algumas possibilidades de se fazer engenharia de requisitos em projetos de software
- Usar t�cnica de Casos de Uso
- Usar t�cnicas de An�lise Essencial:
*- Diagrama de Contexto, DFD, DER, pseudoc�digo
*- entrevistas
O que estudar?
- Sistema organizacional apresentado
- Problemas com o sistema apresentado
- Objetivos e outros requisitos para o novo sistema
- Restri��es
- Alternativas poss�veis
- Sistema atual � geralmente uma das alternativas
- Vantagens e desvantagens das alternativas
Casos de Uso
- Discuta com o cliente o que o sistema far�
- Identifique quem interage com o sistema
- Identifique que interfaces o sistema ter�
Pontos-Chaves
O processo de engenharia de requisitos inclui diversos itens
- Estudo de viabilidade
- Levantamento e a an�lise de requisitos
- Especifica��o de requisitos
- Valida��o de requisitos
- Gerenciamento de requisitos
Diferentes usu�rios do sistema possuem diferentes requisitos.
Resumindo
- O processo de engenharia de requisitos agrega qualidade ao processo de
desenvolvimento e manuten��o de software
E para isso acontecer precisamos estar auxiliados por uma boa metodologia e
ferramentas CASE!!
Hist�rico de Orienta��o a Objetos

A OO surgiu no final da d�cada de 60, quando dois cientistas dinamarqueses criaram
a linguagem Simula (Simulation Language).
1967 - Linguagem de Programa��o Simula - 67 - conceitos de classe e heran�a.
Inicio dos anos 90 -> Paradigma de Orienta��o a Objetos.
Abordagem poderosa e pr�tica para o desenvolvimento de software.
An�lise Orientado a Objetos

O modelo de casos de uso fornece uma perspectiva do sistema a partir de um ponto de
vista externo.
De posse da vis�o de casos de uso, os desenvolvedores prosseguem no com o sistema.
A funcionalidade externa de um sistema orientado a objetos � fornecida atrav�s de
colabora��es entre objetos.
Externamente, os atores visualizam resultados de c�lculos, relat�rios produzidos,
confirma��es de requisi��es realizadas, etc...
Internamente, os objetos colaboram uns com os outros para produzir os resultados.
O diagrama da UML utilizado para representar o aspecto MAIOR da orienta��o a
objetos � o diagrama de classes.
An�lise Orientado a Objetos - Conceitos

Criou o conceito de objeto, que � um tipo de dado com uma estrutura e opera��es
para manipular esta estrutura.
Classes: � um tipo definido pelo usu�rio que cont�m o molde, a especifica��o para
os objetos.
- Todo objeto � uma inst�ncia de uma Classe.
- Possuem propriedades (ATRIBUTOS) e comportamento (M�TODOS).
UML
UML (Unified Modeling Language) � Linguagem de Modelagem Unificada
� uma linguagem de modelagem (visual), n�o uma linguagem de programa��o.
Permite a utiliza��o de diagramas padronizados para especifica��o e visualiza��o de
um sistema.
� uma linguagem de modelagem n�o propriet�ria.
UML - Historico
Surgiu da uni�o de tr�s metodologias de modelagem:
- M�todo de Booch, de Grady Booch;
- M�todo OMT (Object Modeling Technique) de Ivar Jacobson.
- M�todo OOSE (Object Oriented Software Engineering) de James Rumbaugh.
A primeira vers�o foi lan�ada em 1996 e em 1997 a UML foi adotada pela a OMG
(Object Management Group � Grupo de gerenciamento de Objetos) como padr�o em
modelagem.
UML � Por que?

Bons modelos s�o essenciais para a comunica��o entre os times de projetos e para
assegurar a beleza arquitetural.
- Facilita a programa��o.
Todo o time entende a modelagem, facilitando assim a manuten��o.
Ter um rigoroso padr�o de modelagem � fator essencial para o sucesso do projeto.
UML � Modelagem
Modelos Proporcionam:
- Visualiza��o do sistema.
- Especifica��o da estrutura ou comportamento do sistema.
Guia para a constru��o do sistema.
Documenta��o das decis�es tomadas.
UML � Modelagem - Tipos

Tipos de Modelagens
- Estrutural.
- Comportamental.
UML � Diagramas
Representa��o Gr�fica de um conjunto de e lementos.
A UML conforme a modelagem possuem alguns diagramas.
Estrutural (Est�tica):
- Diagrama de Classes.
- Diagramas de Objetos.
- Diagrama de Caso de Uso.
- Diagrama de Componentes.
Din�mico (Comportamental):
- Diagrama de Estados.
- Diagrama de Atividades.
- Diagrama de Colabora��o.
- Diagrama de Seq��ncia.
Diagramas
Os documentos gerados em um processo de desenvolvimento s�o chamados de artefatos
na UML.
Os artefatos comp�e as vis�es do sistema.
A UML define 15 diagramas.
Esta quantidade de diagramas � justificada pela necessidade de analisar o sistema
por meio de diferentes perspectivas.
Cada diagrama fornece uma perspectiva parcial do sistema.
Ferramentas CASE auxiliam na constru��o e gerenciamento dos diagramas UML.
Ferramentas CASE
Ferramenta que oferece conjunto de servi�os, relacionados, para apoiar uma ou mais
atividades do processo de desenvolvimento de software.
Estudar ferramentas CASE � estudar:
Como construir:
- Defini��o de requisitos e arquitetura.
Como usar:
- processo de ado��o, avaliar e sele��o.
Ferramentas CASE - Conceitos

As ferramentas CASE podem ser:
- Horizontais: oferecem servi�os utilizados durante todo o processo de software.
- Verticais: utilizadas em fases espec�ficas do processo de software.
Tamb�m podem ser classificadas de acordo com os servi�os que oferecem, dentre as
quais, cita-se:
- Gerenciamento de configura��o.
- Controle de Qualidade.
- Programa��o.
- Documenta��o.
- An�lise e Projeto.
Ferramentas CASE - Arquitetura

A defini��o da arquitetura est� intimamente relacionada ao contexto no qual a
ferramenta atuar�.
Uma ferramenta CASE deve ser flex�vel, com arquitetura modular para facilitar sua
configura��o para diferentes prop�sitos.
Ferramentas CASE - Exemplos

Ger�ncia de projetos: Microsoft Project.
Teste: Junit, Quality Center
Ferramentas de M�tricas: USC-COCOMO.
Controle de Vers�o: Git, Endevor
Diagrama Use Cases:

S�o especialmente importantes na organiza��o e modelagem das principais
funcionalidades de um sistema.
Diagrama de Classes:
- Os diagramas de classes s�o os principais diagramas estruturais da UML.
- Diagramas de classe mostram classes, interfaces e seus relacionamentos.
Diagrama de Objetos:
- Representam inst�ncias est�ticas de elementos dos diagramas de classes.
- Os diagramas de objetos s�o �teis para a modelagem de estruturas de dados
complexas.
Diagrama de Sequencia:
- Mostra um conjunto de objetos, seus relacionamentos e as mensagens que podem ser
enviadas entre eles.
Diagrama de Colabora��o:
- Mostra conjuntos de objetos, seus relacionamentos e as mensagens que enfatizam a
organiza��o dos objetos que trocam mensagens.
Diagrama de Estados:
- Mostra uma m�quina contendo estados, transi��es, eventos e atividades.
- Estes diagramas s�o usados para modelar o comportamento de objetos (com
comportamento complexo).
Diagrama de Atividades:
- Destaca a l�gica de realiza��o de uma tarefa.
- Mostra o fluxo entre atividades.
Diagrama de Componentes:
- Mostra os componentes de hardware e software de uma aplica��o e os
relacionamentos entre eles.
- � usado para modelar o aspecto f�sico de um sistema.
Ferramentas CASE
O processo de ado��o:
- Prover um n�vel apropriado de suporte tecnol�gico para os processos de
desenvolvimento e manuten��o de software.
- Impactar positivamente sobre: produtividade, qualidade, padroniza��o,
documenta��o.
- Induzir o uso geral e cont�nuo de ferramentas na organiza��o e seus grupos.
Passos:
- Defini��o da necessidade.
- Avalia��o e sele��o de ferramentas.
- Condu��o de um esfor�o piloto.
- Tornar rotineiro o uso das ferramentas.
Pontos chaves
- Orienta��o a objetos apesar de antiga n�o era utilizada por falta de pessoas
treinadas e ferramentas adequadas.
- Mas hoje tal modelagem tornou-se uma abordagem poderosa e pr�tica para o
desenvolvimento de software.
- A UML � uma linguagem de modelagem (visual) que permite a padroniza��o de
especifica��o e visualiza��o de um sistema.
- E temos as Ferramentas CASE, que apoiam a Modelagem em todas as suas fases
trazendo mais qualidade ao desenvolvimento de software.
APOL 4 (corrigido)
(1) - Uma das atividades primordiais do processo de desenvolvimento de software em
geral - e da An�lise de Sistemas em particular - diz respeito � especifica��o de
Requisitos do software, conforme apresentado na aula 04.
Com rela��o a requisistos � correto afirmar que:
A) S�o descri��es dos principais recursos de um produto de software, seu fluxo de
informa��es, comportamento e atributos.
B) Fornecem uma estrutura b�sica para o desenvolvimento de um produto de software.
C) Estabelecem quais fun��es s�o requeridas pelo sistema e as restri��es sobre a
D) (x) As alternativas A e B est�o corretas
(2) - O Gerenciamento de Requisitos � uma importante atividade do processo de

desenvolvimento de software.
Quanto ao objetivo do gerencimento de requisitos � correto afirmar que:
A) (x) Estabelece quais fun��es s�o requeridas pelo sistema e as restri��es sobre a
B) Apresenta as descri��es dos principais recursos de um produto de software, seu
fluxo de informa��es, comportamento e atributos.
C) Fornece uma estrutura b�sica para o desenvolvimento de um produto de software.
D) As alternativas A e B est�o corretas.
(3) - O Gerenciamento de Requisitos estabelece quais fun��es s�o requeridas pelo

sistema e as restri��es sobre a opera��o e o desenvolvimento do sistema.
Para implementar uma ger�ncia de requisitos eficaz � necess�rio:
A) Definir um conjunto de pol�ticas.
B) Definir um conjunto de objetivos para o processo de ger�ncia.
C) Que todos os artefatos (documentos) produzidos durante o desenvolvimento do
software tornem a ger�ncia dos requisitos vis�vel e transparente.
D) (x) Todas as alternativas est�o corretas.
(4) - O rastreamento de requisitos � indispens�vel para o processo de revis�o dos

requisitos e dos documentos da An�lise de Sistemas.
Quais s�o os tipos de Rastreamento geralmente utilizados na Ger�ncia de Requisitos?
A) (x) Rastreamento de origem, Associa��o entre requisitos dependentes e Associa��o
dos requisitos com o projeto.
B) Associa��o entre requisitos dependentes e Associa��o dos requisitos com o
projeto.
C) Associa��o entre requisitos de processos e Associa��o dos requisitos com o
projeto.
D) Associa��o entre requisitos de processos e Rastreamento de Origem.
(5) - A Ger�ncia de Configura��o est� comumente associada a dois tipos de tarefas

de grande import�ncia.
S�o estas tarefas:
A) Controle de vers�es e controle de mudan�as.
B) (x) Controle de vers�es e controle de configura��o.
C) Controle de vers�es e controle de requisitos.
D) Nenhuma das alternativas anteriores apresenta a resposta correta.
(6) - A evolu��o do processo de an�lise de sistemas resultou no surgimeno de v�rios

modelos. Um destes modelos criou o conceito de um tipo de dado com uma estrutura e
opera��es para manipular esta estrutura.
Este modelo de an�lise de sistemas � conhecido como:
A) An�lise Essencial.
B) Unified Modeling Language - UML.
C) An�lise Estruturada.
D) (x) An�lise Orientada a Objetos.
(7) - Representam um conjunto de informa��es, ou seja, elementos de dados que

caracterizam um objeto.
Na an�lise orientada a objetos esta descri��o correspode a:
A) (x) Atributos.
B) Objetos.
C) Classes.
D) M�todos.
(8) - Foi apresentada em 1996 como a melhor candidata para ser a linguagem
unificadora de nota��es. Foi aprovada como padr�o pela OMG e desde ent�o tem tido
grande aceita��o. Atualmente est� na vers�o 2.0.
Trata-se da:
A) An�lise Essencial.
B) (x) Unified Modeling Language - UML.
C) An�lise Estruturada.
D) An�lise Orientada a Objeto.
(9) - A complexidade dos requisitos dos softwares/sistemas exige um desenvolvimento

sistem�tico apoiado por t�cnicas eficazes que possibilitem mensurar os riscos de
uso e provar para a comunidade que o uso do software � seguro.
O conjunto de ferramentas que podem auxiliar nesse processo � denominado:
A) Ferramentas RAD.
B) (x) Ferramentas CASE.
C) GUI Estruturado.
D) Ferramentas CAD.
(10) - A Unified Modeling Language - UML faz uso de diversos tipos de diagramas,
gr�ficos com o objetivo de apresentar e facilitar a compreens�o do software.
S�o tipos de diagramas da UML:
A) DFD, Fluxogramas e Diagrama de Caso de Uso.
B) DFD, Diagrama de Caso de Uso ,Fluxogramas e Diagrama de Sequencia.
C) (x) Diagrama de Caso de Uso, Diagrama de Objetos e Diagrama de Classe.
D) Diagrama de Caso de Uso, Diagrama de Objetos, Diagrama de Classe e DFD.
APOL 5 (corrigido)
(1) - Uma ferramenta CASE deve ser flex�vel, com arquitetura modular para facilitar
sua configura��o para diferentes prop�sitos.
A arquitetura deve ser baseada em:
A) Componentes Distribu�dos.
B) Componentes: que representam os subsistemas principais e objetos da ferramenta.
C) Mecanismos de intera��o (tecnologia de integra��o) que representam a forma como
os componentes interagem, trocam informa��es e afetam uns aos outros.
D) (x) As alternativas B e C est�o corretas.
(2) - Uma ferramenta CASE deve ser flex�vel, com arquitetura modular para facilitar
sua configura��o para diferentes prop�sitos.
Quanto � sua composi��o as ferramentas CASE podem ser:
A) Horizontais: oferecem servi�os utilizados durante todo o processo de software.
B) Verticais: utilizadas em fases espec�ficas do processo de software.
C) Candidatas: quando n�o identificadas em um processo de avalia��o pr�vio.
D) (x) As alternativas A e B est�o corretas.
(3) - Em Projetos de Software h� ferramentas que integram todo um sistema de

suporte ao desenvolvimento de software.
A essas ferramentas damos o nome de:
A) (x) Ferramentas CASE.
B) Ferramentas RAD.
C) Ferramentas GUI.
D) Todas as alternativas est�o corretas.
(4) - Uma das caracter�sticas importantes da Orienta��o a Objeto � a Heran�a.

Sobre Heran�a � correto afirmar que:
A) � a capacidade de compartilhar estruturas comuns entre diversas classes
derivadas.
B) Dependendo das caracter�sticas necess�rias � obrigat�rio o uso do fator de
ajuste.
C) H� um reaproveitamento de c�digo da classe pai por parte da classe filha. Onde
esse recebe todos os m�todos e atributos.
D) (x) As alternativas A e C est�o corretas.
(5) - � uma linguagem gr�fica para visualiza��o, especifica��o, constru��o e

documenta��o de artefatos de sistemas complexos de software. De seu ponto de vista,
um requisito � uma caracter�stica de projeto, uma propriedade ou um comportamento
de um sistema. E um diagrama de sequ�ncia enfatiza a ordena��o temporal de
mensagens.
Avaliando as afirma��es apresentadas do ponto de vista da UML podemos concluir que:
A) (x) Tratam-se de afirma��es corretas do ponto de vista da UML.
B) S�o afirma��es incorretas, pois tratam-se de defini��es aplic�veis somente �
orienta��o a objetos.
C) S�o afirma��es incorretas, pois tratam da defini��o de An�lise Estruturada.
D) S�o afirma��es incorretas, pois um requisito n�o � uma caracteristica do
projeto.
(6) - Uso obrigat�rio: Toda vez que o caso de uso A for executado, obrigatoriamente
o caso de uso B tamb�m deve ser executado.
Esta afirma��o, no que tange a casos de uso, refere-se a:
A) Extends.
B) Associa��o e Extends.
C) Associa��o e Include.
D) (x) Include.
(7) - Analise a figura abaixo e responda.

Qual o tipo de relacionamento existente entre os atores?
A) Associa��o e Extends.
B) Associa��o e Include.
C) Associa��o e Generaliza��o.
D) (x) Generaliza��o.
(8) - Sobre o diagrama apresentado pode-se afirmar que:

I - b � um objeto ativo da classe B.
II - a mensagem 1.2 representa uma itera��o.
III - a mensagem 1 � uma found message.
IV - a mensagem 1.3 � ass�ncrona.
Est� correto o que se afirma:
A) Apenas em I.
B) Apenas em IV.
C) Em I e II.
D) (x) Em I, II e III.
(9) - Considere as seguintes informa��es sobre diagramas de classes e diagramas de

objetos da UML, utilizados na modelagem orientada a objetos:
I - Um diagrama de objetos possui apenas dois compartimentos (nome e atributos).
II - Um diagrama de classes possui tr�s compartimentos (nome, atributos e
opera��es).
III. O formato para o nome de um objeto � nome-objeto:nome-classe.
Sobre as afirma��es, est� correto o contido em:
A) I, apenas.
B) I e II, apenas.
C) I e III, apenas.
D) (x) I, II e III.
(10) - O projeto orientado a objetos preocupa-se com a defini��o de objetos e

softwares e suas responsabilidades e colabora��es.
Uma nota��o comum para ilustrar essas colabora��es � denominada:
A) (x) Diagrama de sequ�ncia.
B) Diagrama de classes.
C) Casos de uso.
D) Diagrama de estados.
Diagrama de Casos de Uso

Descreve o que o sistema faz do ponto de vista do observador externo. Ajuda a
esclarecer os requisitos do sistema e a dividir o desenvolvimento do sistema em
tarefas.
Componentes
a) Caso de uso: Representa as diferentes funcionalidades que o sistema
disponibiliza aos usu�rios.
b) Atores: Diferentes usu�rios que operam o sistema. Sistemas externos que
interagem com o sistema.
c) Associa��o: Representa a comunica��o entre o ator e o caso de uso. Tamb�m
existem associa��es entre casos de usos.
d) Relacionamento entre Casos de Uso: Include, Extend, Generalization.
Diagrama de Classe
Diagramas de Classe mostram as diferentes classes que fazem um sistema e como elas
se relacionam. Os Diagramas de Classe s�o chamados diagramas "est�ticos" porque
mostram as classes, com seus m�todos e atributos bem como os relacionamentos
est�ticos entre elas: quais classes �conhecem� ou quais classes "s�o parte" de
outras classes, mas n�o mostram a troca de mensagens entre elas.
Componentes
a) Classe
b) Relacionamentos
- Associa��o : S�o relacionamentos estruturais entre inst�ncias e especificam que
objetos de uma classe est�o ligados a objetos de outras classes.
- Generaliza��o (heran�a: simples ou composta) - Relacionamento entre um elemento
mais geral e um mais espec�fico. Onde o elemento mais espec�fico herda as
propriedades e m�todos do elemento mais geral.
- Depend�ncia - S�o relacionamentos de utiliza��o no qual uma mudan�a na
especifica��o de um elemento pode alterar a especifica��o do elemento dependente. A
depend�ncia entre classes indica que os objetos de uma classe usam servi�os dos
objetos de outra classe.
- Agrega��o Regular - tipo de associa��o (� parte de, todo/parte) onde o objeto
parte � um atributo do todo; onde os objetos partes somente s�o criados se o todo
ao qual est�o agregados seja criado. Pedidos � composto por itens de pedidos.
- Composi��o - Relacionamento entre um elemento (o todo) e outros elementos (as
partes) onde as partes s� podem pertencer ao todo e s�o criadas e destru�das com
ele.
c) Atributos
Na UML, atributos s�o mostrados com pelo menos seu nome, e podem tamb�m mostrar seu
tipo, valor inicial e outras propriedades. Atributos podem tamb�m ser exibidos com
sua visibilidade:
+ indica atributos p�blicos
# indica atributos protegidos
- indica atributos privados
d) Opera��es
Opera��es (m�todos) tamb�m s�o exibidos com pelo menos seu nome, e podem tamb�m
mostrar seus par�metros e valores de retorno. Opera��es podem, como os Atributos,
mostras sua visibilidade:
+ indica opera��es p�blicas
# indica opera��es protegidas
- indica opera��es privadas
Diagrama de Sequencia
Descreve as intera��es entre as classes atrav�s das trocas de mensagens ao logo do
tempo. Mostra um conjunto de objetos, seus relacionamentos e as mensagens que podem
ser enviadas entre eles. Diagrama de sequ�ncia d� �nfase � sequ�ncia de mensagens.
Componentes
a) Objetos: Representa uma inst�ncia de uma determinada classe.
b) Mensagens: Representa troca de mensagens entre os objetos.
c) Tipos de mensagens: Quando um objeto envia uma mensagem para outro objeto, o
objeto que recebe a mensagem pode enviar outras mensagens e assim por diante,
formando uma sequ�ncia de mensagens. O sequenciamento pode ser procedural, com
aninhamento (mensagens s�ncronas) ou plano, sem aninhamento (mensagens
ass�ncronas).
Diagrama de Estados
Mostra uma m�quina contendo estados, transi��es, eventos e atividades. Estes
diagramas s�o usados para modelar o comportamento de objetos (com comportamento
complexo). Nestes diagramas s�o modelados os estados em que um objeto pode estar e
os eventos que fazem o objeto passar de um estado para outro.
Componentes
- Estado inicial.
- Estado final.
- Estado intermedi�rio.
S�ntese
O surgimento de sistemas de software complexos resultou na necessidade de reavaliar
a forma de desenvolver sistemas. As t�cnicas t�m evolu�do de forma impressionante,
notavelmente no que tange � modelagem de sistemas. Um modelo pode ser visto como
uma representa��o idealizada de um sistema a ser constru�do. Maquetes de edif�cios
e de avi�es e plantas de circuitos eletr�nicos s�o apenas alguns exemplos de
modelos. Uma simplifica��o da realidade que nos ajuda a entender um problema
complexo.
Ent�o a modelagem de sistemas de software consiste na utiliza��o de nota��es
gr�ficas e textuais com o objetivo de construir modelos que representam as partes
essenciais de um sistema, considerando-se diversas perspectivas diferentes e
complementares. E a UML nos fornece v�rios diagramas entre os quais os vistos nessa
aula onde podemos de forma segura, com qualidade e padronizada documentar e modelar
os sistemas e softwares que iremos desenvolver.
*******************************************************************
Use Case <<Extrato de Conta Corrente na Internet>> (titulo)
Scope (escopo)
Abrange a solicita��o de extrato de conta corrente atrav�s da Internet, com op��o
para extrato di�rio,
semanal, mensal e por per�odo.
Brief Description (descri��o)

Este use case serve para solicitar extrato de Conta Corrente atrav�s da Internet.
Preconditions (pr�-condi��es)
Este use case pode iniciar somente se:
1 Cliente for autorizado no Internet Banking.
2 Tela T0010 Menu Principal aberta.
Success post-condition (executado com sucesso)

Ap�s o fim normal deste use case o sistema deve ter
registrado os dados da transa��o.
Failure post-conditions (executado com insucesso)

E1: Ap�s o fim deste use case nesta condi��o,
a tela Extrato por Per�odo deve ficar aberta.
Primary Actor (primeiro ator)

Cliente
Secondary Actor(s) (segundo ator)
N�o h�.
Trigger (gatilho)
Este use case deve come�ar quando o Cliente posicionar o cursor na
op��o Conta Corrente, na tela T0010 Menu Principal e selecionar.
Main Flow of Events (passos principais)

1-O Sistema abre o submenu do item Conta Corrente
2-O Cliente seleciona uma das seguintes op��es: Extrato Di�rio
(A1), Extrato Semanal (A2), Extrato Mensal (A3), Extrato por Per�odo (A4).
3-O use case � encerrado (R4).
Alternatives (fluxo alternativo)

A1: Extrato Di�rio
1-O Sistema abre a tela T0015
2-O Cliente observa o extrato di�rio e decide selecionar uma das
seguintes op��es: A5: Imprimir, A6: Salvar em outros formatos, A7:
Ajuda e A8: Encerrar. (R2, R3)
A2: Extrato Semanal

2-O Cliente observa o extrato semanal e decide selecionar uma das
A3: Extrato Mensal

2-O Cliente observa o extrato mensal e decide selecionar uma das
A4: Extrato por Per�odo

2-O Cliente informa a per�odo (E1) e confirma.
4-O Cliente observa o extrato mensal e decide selecionar uma das
A5: Imprimir
1-O Sistema abre a tela correspondente ao servi�o de impress�o do
Sistema Operacional.
2-O Cliente solicita a impress�o.
A6: Salvar em outros formatos

1-O Cliente seleciona a op��o �Salvar em outros formatos�
3-O Cliente escolhe o tipo de formato para salvar as informa��es do extrato (A9:
Fechar).
4-O Sistema abre uma tela, conforme o formato escolhido, que cont�m as informa��es
do extrato.
5-O-Cliente salva as informa��es do extrato na sua m�quina
6-O caso de uso � encerrado.
A7: Ajuda
1-O sistema reutiliza o servi�o de Ajuda Online.
A8: Encerrar Extrato

1- O sistema abre a tela padr�o de agradecimento e, segundos depois,
a tela principal do site.
2- O caso de uso � encerrado.
A9: Fechar
1- O Sistema fecha a tela T0025
2- O Sistema retorna para a tela anterior, que cont�m as
informa��es do extrato.
pelo sistema.
E1: Data final fora do per�odo dispon�vel (R1)

1-O usu�rio deve digitar um per�odo igual ou contido no per�odo informado pelo
sistema.
Related information
Non Functional Requirements:

1O sistema deve ter capacidade de atender usu�rios localizados em qualquer lugar
com acesso � Internet.
2O sistema deve ter capacidade de processar, em m�dia, 1 extrato, por semana, por
cliente.
Business Rules: (regras de neg�cios)

R1: O per�odo dispon�vel para emiss�o de extrato de
conta corrente na Intranet deve ser igual a 35 dias a
partir da data atual.
R2: O Saldo Indispon�vel deve ser calculado como o

somat�rio dos cheques depositados que ainda est�o em
compensa��o, no per�odo.
R3: O Saldo Dispon�vel deve ser calculado como o saldo

no in�cio do per�odo, mais o somat�rio dos cr�ditos
menos o somat�rio dos d�bitos, no per�odo.
R4: O sistema deve encerrar a sess�o ap�s cinco

minutos sem a intera��o do usu�rio.
Data Views ()
Os seguintes conjuntos de dados s�o utilizados neste use case:
Hist�rico de Lan�amentos dos �ltimos 30 dias
Cadastro de Clientes
Scenarios
Scenario 1: Impress�o de Extrato Di�rio
Scenario 2: Impress�o de Extrato Semanal
************************************************
UC002 � Manter Aluno

Descri��o
Este caso de uso descreve as opera��es de inclus�o, exclus�o, altera��o e consulta
de Alunos.
Pr�-condi��o
O ator dever� estar autenticado no sistema com o perfil de Funcion�rio;
P�s-condi��o
Novo aluno cadastrado;
Dados de aluno alterados;
Aluno exclu�do;
Sistema permanece inalterado.
Trigger
Esse caso de uso se inicia quando o ator Funcion�rio acessa a op��o Cadastramento
de Alunos a partir do menu do
sistema.
Fluxo B�sico � Incluir Aluno
[Iniciar Funcionalidade]
O sistema exibe o agrupamento de campos Dados do Aluno, em branco e habilitados
para edi��o;
O sistema apresenta as op��es de �Salvar�, �Consultar� e �Voltar�.
O ator preenche o agrupamento de campos Dados do Aluno;
[Selecionar Opera��o]
Executa o Sub-Fluxo Salvar Aluno;
O caso de uso � encerrado.
Fluxo Alternativo Consultar Aluno

Em [Selecionar Opera��o], quando o ator selecionar a op��o �Consultar�:
O sistema recupera as ocorr�ncias de �Aluno� que corresponderem total ou
parcialmente �s informa��es preenchidas no
agrupamento de campos Dados do Aluno;

[Apresentar Lista]
O sistema exibe uma lista de agrupamento de campos Lista de Alunos;
O ator seleciona o �Aluno� a partir da lista.
O sistema recupera as informa��es do agrupamento de campos Dados do Aluno que
corresponde ao �Aluno�
selecionado a partir da lista. Caso nenhuma informa��o do agrupamento de campos
Dados do Aluno tenha sido
preenchida o sistema deve recuperar todas as ocorr�ncias de Aluno cadastradas.
O sistema exibe o agrupamento de campos Dados do Aluno, preenchido com os dados
recuperados e desabilitados para
edi��o;
O sistema apresenta as op��es de �Alterar�, �Excluir� e �Voltar�;
[Selecionar Opera��o 2]
O ator seleciona a op��o �Voltar�;
O caso de uso retorna em [Iniciar Funcionalidade].
Fluxo Alternativo Alterar Aluno
Em [Selecionar Opera��o 2], quando o ator selecionar a op��o �Alterar�:
O sistema habilita a edi��o do agrupamento de campos Dados do Aluno;
O ator preenche o agrupamento de campos Dados do Aluno;
Executa o Sub-Fluxo Salvar Aluno;
Fluxo Alternativo Excluir Aluno
Em [Selecionar Opera��o 2], quando o ator selecionar a op��o �Excluir�:
O sistema solicita a confirma��o da exclus�o do Aluno;
O ator confirma a exclus�o;

[Validar Exclus�o]
O sistema valida se a exclus�o � poss�vel;
O sistema exclui o Aluno;
O sistema apresenta uma mensagem informando que o Aluno foi exclu�do;
Sub-Fluxo Salvar Aluno
[Preencher Campos]
O ator seleciona a op��o de �Salvar�;
O sistema valida as informa��es do agrupamento de campos Dados do Aluno;
[Validar Campos]
O sistema salva as informa��es do agrupamento de campos Dados do Aluno;
O sistema apresenta uma mensagem informando que os dados foram salvos;
O fluxo de eventos retorna ao ponto de origem.
Fluxo de Exce��o Campo Obrigat�rio N�o Preenchido
Em [Validar Campos], caso algum campo obrigat�rio n�o tenha sido fornecido:
O sistema apresenta a mensagem �Campo (nome do campo) obrigat�rio�;
Retorna em [Preencher Campos].
Fluxo de Exce��o Exclus�o de Aluno em Uso
Em [Validar Exclus�o], caso o Aluno a ser exclu�do esteja matriculado:
O sistema apresenta a mensagem �O registro n�o pode ser exclu�do, pois o aluno
encontra-se matriculado�;
Retorna em [Iniciar Funcionalidade].

Fluxo de Exce��o Lista sem Ocorr�ncias
Em [Apresentar Lista], caso nenhuma ocorr�ncia de Aluno tenha sido encontrada com
base nos dados informados, ou
n�o existam Alunos cadastrados:
O sistema apresenta a mensagem �Nenhuma ocorr�ncia foi encontrada.�;
Retorna em [Iniciar Funcionalidade].
Regras de Neg�cio
N�o se aplica
Agrupamento de Campos
Cen�rios de Sucesso
Incluir um Aluno e encerrar o caso de uso com sucesso;
Consultar um Aluno fornecendo dados de pesquisa e encerrar o caso de uso com
sucesso;
Consultar um Aluno n�o fornecendo nenhum dado de pesquisa, observar que a lista de
Alunos cont�m todas as
ocorr�ncias cadastradas e encerrar o caso de uso com sucesso;
Alterar um Aluno e encerrar o caso de uso com sucesso;
Excluir um Aluno e encerrar o caso de uso com sucesso;
Cen�rios de Insucesso
Tentar incluir um Aluno deixando campos obrigat�rios n�o informados, observar
mensagem de erro e encerrar o caso de
uso sem sucesso. Repetir para todos os campos que possuem valida��o.
Tentar consultar um Aluno fornecendo dados de pesquisa que n�o retornam nenhuma
ocorr�ncia, observar mensagem de
erro e encerrar o caso de uso sem sucesso.
Tentar realizar uma consulta sem que haja Alunos cadastrados no sistema, observar
mensagem de erro e encerrar o caso
de uso sem sucesso.
Tentar excluir um Aluno que esteja matriculado, observar a mensagem de erro e
encerrar o caso de uso sem sucesso.
*************************************
O Dicion�rio de Dados
Proposto como gram�tica quase formal
para descrever o conte�do de objetos
definidos durante a
an�lise estruturada.
Geralmente implementado como parte

de uma "ferramenta de projeto e
an�lise estruturada"
CASE.
A maioria dos DD cont�m as seguintes

informa��es:
Nome: o nome principal do item de
dados, do dep�sito de
dados ou de uma entidade
externa.
Alias: outros nomes usados para a

primeira entrada.
Onde � usado / Como � usado: lista dos
processos que usam o item de dados e
como ele � usado.
Ex: entrada ao
processo, sa�da do processo.
Descri��o de Conte�do: nota��o para

representar o conte�do.
Inf. Complementar: outras informa��es
sobre tipos de dados,
Valores previamente
estabelecidos, restri��es
ou limita��es.
********************************************************
O cliente poder�: Sacar,

Depositar, Transferir e
Tirar Extrato.
Para cada opera��o o cliente

deve se autenticar.
Qualquer funcion�rio
poder�:
Tirar Extrato do cliente.

Solicitar Cart�o de cr�dito para
cliente.
O Gerente pode fazer qualquer

opera��o dos funcion�rios.
Somente o Gerente
pode cadastrar
ou descadastrar conta.
******************************************************
Um sistema de controle de
hospital. A atendente pode
acionar a emerg�ncia.
Existem dois tipos de
emerg�ncia:
card�aca e pulmonar.
A atendente pode cadastrar,

procurar e atualizar uma
emerg�ncia.
O gerente pode fazer
tudo que a atendente
faz.
O gerente pode remover uma

emerg�ncia.
Para cada tarefa, o usu�rio

(qualquer que seja)
deve se
autenticar
no sistema.
********************************************
Diagrama de Atividades
Ilustram a natureza din�mica
de um sistema modelando o
fluxo de controle de uma
atividade para outra.
*****************************************
Diagrama de Classes
Diagrama mais utilizado da UML.
Serve de apoio para a maioria
dos outros diagramas.
Define a estrutura de classes do

sistema. Estabelece como as
classes se relacionam.
*****************************************
A arte de coordenar o
desenvolvimento de
software
para minimizar a
confus�o �
denominada
Gerenciamento de
Configura��o.
O Gerenciamento de
Configura��o do Software � um
importante elemento
da garantia da
qualidade de
software.
*****************************************
Prova discursiva
1 - Dentro dos princ�pios da Engenharia de Software, temoas as seguintes fases:

Defini��o, Desenvolvimento, Opera��o e Retirada. Com base nessa afirma��o quais s�o
as atividades
elaboradas dentro da Fase de Defini��o?
- An�lise e Especifica��o
� Estudo de Viabilidade
� Estimativas Planejamento
2 - Considere-se o melhor cen�rio para o caso de utiliza��o "Enviar Fax" (o cen�rio

em que tudo ocorre bem). Considere um sistema composto pelos seguintes objetos:
m�quina que envia; m�quina que recebe; uma central que encaminha faxes e chamadas
telef�nicas. Desenhe o diagrama de sequ�ncias respectivo.
ME CE MR
|enviar --> |
| |eFax ----> |
| | |
| |<---- msgOk|
|<---- msgOk|
|
X
3 - Tendo em conta as descri��es abaixo, defina o diagrama de classes e o diagrama

de objetos que suportem as afirma��es:
1) A empresa XPTO possui um Audi A6 TDi vermelho, com matricula "99-99-AA", que tem
um motor 1900cc, com n�mero "9999".
2) a Marta � dona de um Ferrari F40 vermelho, com matricula "66-66-FF", mas sem
motor.
3) o Rui n�o t�m qualquer carro.
|Automovel |
|Marca |
|Modelo |
|Cor |
|Matricula |
|Motor |
|Numero |
|XPTO |
|Audi |
|A6 TDi |
|Vermelho |
|99-99-AA |
|1900cc |
|9999 |
|Marta |
|Ferrari |
|F40 |
|Vermelho |
|66-66-FF |
|null |
|null |
4 - Qual a diferen�a entre classe e objeto?

Classe: Uma classe � o agrupamento de objetos com a mesma estrutura de dados e
comportamento, ou seja, classe s�o as descri��es dos objetos!
Objeto: � uma classe sendo estanciada. De maneira mais Conceitual, um objeto � algo
distingu�vel que cont�m atributos (ou propriedades) e possui um comportamento. Cada
objeto tem uma identidade e � distingu�vel de outro mesmo que seus atributos sejam
id�nticos.
5 - Na imagem abaixo que mostra um diagrama de atividades, qual o nome dos simbolos
indicados pelas setas em vermelho?
Fork, join
***********************************************************************
1 - O que se define na matriz de rastreabilidade de requisitos?

A matriz de rastreabilidade dos requisitos liga os requisitos �s suas origens e os
rastreia durante todo o ciclo de vida do projeto.
2 - No diagrama de sequencia representado pela imagem abaixo, qual � a fun��o do

"X"?
Quando um objeto desaparece.
3 - Modelize atrav�s de um diagrama de classes o seguinte discurso: "Uma mesa de

caf� � constitu�da por um tampo e por quatro pernas...":
|Mesa|<--------1|Tampo|
^
|
|
4
|Pernas|
4 - Qual � a nota��o da UML para um caso de uso? Qual � a nota��o da UML para um
ator? Qual a nota��o utilizada na UML para o relacionamento de generaliza��o entre
casos de uso?
5 - O que s�o ferramentas CASE (Computer-Aided Software Engineering)?

Ferramentas CASE � um sistema de suporte ao desenvolvimento de software que auxilia
nas atividades de engenharia de software, desde an�lise de requisitos e modelagem
at� programa��o e testes.

Análise de Sistemas Resumo

Enviado por

Dados do documento

Título original

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

Análise de Sistemas Resumo

Enviado por

Direitos autorais:

Formatos disponíveis

As grandes transforma��es ocorridas nos �ltimos anos, impulsionadas pelo avan�o da

tecnologia provocaram a passagem da antiga sociedade industrial para uma nova

Mas o que � software?

Causas dos Problemas Associados � Crise de Software;

Mitos do Software (Administrativos)

- Mito: Meu pessoal tem ferramentas de desenvolvimento de software de �ltima

Mitos do Software (Cliente)

Mitos do Software (Profissional)

- Ferramentas: d�o suporte automatizado aos m�todos;

Ciclo de Vida Cl�ssico (Cascata)

Atividades do Ciclo de Vida Cl�ssico

Ciclo de Vida em Espiral

Atividades do Ciclo de Vida em Espiral

Ciclo de Vida Cl�ssico

Ciclo de Vida em Espiral

(2) - Considere que voc� trabalhe em uma empresa de desenvolvimento de software e

(3) - Modelo mais antigo e o mais amplamente usado da engenharia de software,

(4) - Em Projetos de Software h� ferramentas e frameworks que integram todo o

(5) - Engloba as melhores caracter�sticas do ciclo de vida Cl�ssico e da

(6) - O desenvolvimento, opera��o e manuten��o do software abrange um conjunto de

(9) - No per�odo da d�cada de 1990 surge um novo paradigma de modelagem, como

(3) - Num diagrama de fluxo de dados DFD,

(4) - Como se defne a implementa��o de um sistema orientado a objetos?

(5) - S�o conceitos chaves do paradigma Orientado a Objetos:

(6) - Fl�vio pretende desenvolver um software seguindo os est�gios do modelo em

(8) - Sobre a engenharia de software, considere:

(9) - A Engenharia de Requisitos tem como objetivo criar e manter um documento de

(10) - O desenvolvimento de softwares demanda que seus desenvolvedores tenham a

Componentes do Modelo Estruturado

Diagrama de Fluxo de Dados (DFD)

DFDs desenvolvidos em n�veis hier�rquicos

Diagrama de Transi��o de Estados (DTE)

Diagrama de Transi��o de Estado

An�lise Orientada a Objetos

An�lise Orientada a Objetos

Por que usar Orienta��o a Objetos?

(2) - Podemos dividir a Engenharia de Software em algumas categorias.

(4) - O estudo de viabilidade � o que indica se o esfor�o em desenvolver a ideia

(5) - Requisito � uma senten�a identificando uma capacidade, uma caracter�stica

(6) - Requisito � uma senten�a identificando uma capacidade, uma caracter�stica

(8) - Rastreamento de Requisitos � respons�vel por depend�ncias entre requisitos,

(9) - Em um ambiente real de desenvolvimento de software mudan�as s�o inevit�veis.

E a evolu��o se baseou nos chamados Ciclos de Vida de Sistemas. Dentro desse

Conjunto coerente de atividades para especificar, projetar, implementar e testar

- Atividade da fase de concep��o: Elicita��o e an�lise.

Divis�o dos Requisitos

Requisitos n�o funcionais:

Organiza��o dos Requisitos

O sucesso come�a com a Ger�ncia de Requisitos.

2- Levantamento dos requisitos

Problemas de An�lise de Requisitos

Valida��o dos Requisitos

T�cnicas de Valida��o de Requisitos

Diferentes usu�rios do sistema possuem diferentes requisitos.

Hist�rico de Orienta��o a Objetos

An�lise Orientado a Objetos

An�lise Orientado a Objetos - Conceitos

UML � Por que?

UML � Modelagem - Tipos

Ferramentas CASE - Conceitos

Ferramentas CASE - Arquitetura

Ferramentas CASE - Exemplos

Diagrama Use Cases: