Análise de Sistemas resumo

Esta é uma pré-visualização de arquivo. Entre para ver o arquivo original

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.
C) RAD (rapid application development).
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.
C) RAD (rapid application development).
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:
Assinale a alternativa correta
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:
Assinale a alternativa correta
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:
Assinale a alternativa correta
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:
Assinale a alternativa correta
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:
Assinale a alternativa correta
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 de Viabilidade
- 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
Estudo de Viabilidade
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 operação e o desenvolvimento do sistema.
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 operação e o desenvolvimento do sistema.
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
1-O Sistema abre a tela T0015
2-O Cliente observa o extrato semanal e decide selecionar uma das
seguintes opções: A5: Imprimir, A6: Salvar em outros formatos, A7:
Ajuda e A8: Encerrar. (R2, R3)
A3: Extrato Mensal
1-O Sistema abre a tela T0015
2-O Cliente observa o extrato mensal e decide selecionar uma das
seguintes opções: A5: Imprimir, A6: Salvar em outros formatos, A7:
Ajuda e A8: Encerrar. (R2, R3)
A4: Extrato por Período
1-O Sistema abre a tela T0020
2-O Cliente informa a período (E1) e confirma.
3-O Sistema abre a tela T0015
4-O Cliente observa o extrato mensal e decide selecionar uma das
seguintes opções: A5: Imprimir, A6: Salvar em outros formatos, A7:
Ajuda
e A8: Encerrar. (R2, R3)
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”
2-O Sistema abre a tela T0025
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;
UC002 – Manter 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;
O caso de uso retorna em [Iniciar Funcionalidade].
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;
UC002 – Manter Aluno
[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;
O caso de uso retorna em [Iniciar Funcionalidade].
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].
UC002 – Manter Aluno
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.