Análise e Projeto de Sistemas para a Internet Centro Federal de Educação Tecnológica da Paraíba...

Análise e Projeto de Sistemas Análise e Projeto de Sistemas para a Internetpara a Internet

Centro Federal de Educação Tecnológica da ParaíbaCentro Federal de Educação Tecnológica da Paraíba

Coordenação de InformáticaCoordenação de Informática

Desenvolvimento de Software para a InternetDesenvolvimento de Software para a Internet

ConteúdoConteúdo

Apresentação e Conceitos fundamentais de Análise e Projeto de SistemasApresentação e Conceitos fundamentais de Análise e Projeto de Sistemas

1.1. Noções de Engenharia de SoftwareNoções de Engenharia de Software

2.2. Modelos de ciclo de vida e métodos de desenvolvimentoModelos de ciclo de vida e métodos de desenvolvimento

3.3. Análise de requisitos de sistema e de softwareAnálise de requisitos de sistema e de software

4.4. Levantamento de dadosLevantamento de dados

5.5. Gerenciamento de softwareGerenciamento de software

6.6. Análise estruturada, DFD e dicionário de dadosAnálise estruturada, DFD e dicionário de dados

7.7. Análise essencial, DFD, DER, DTE e dicionário de dadosAnálise essencial, DFD, DER, DTE e dicionário de dados

8.8. Análise orientada a objetosAnálise orientada a objetos

9.9. Detalhamento do RUP e de outros métodos de desenvolvimentoDetalhamento do RUP e de outros métodos de desenvolvimento

10.10. Análise e projeto orientados a objetos e UMLAnálise e projeto orientados a objetos e UML

11.11. Requisitos e diagramas de caso de usoRequisitos e diagramas de caso de uso

12.12. Aplicações de casos de usoAplicações de casos de uso

13.13. Diagramas de classe e de objetosDiagramas de classe e de objetos

14.14. Aplicações de diagramas de classe e de objetosAplicações de diagramas de classe e de objetos

15.15. Diagramas de estadosDiagramas de estados

16.16. Aplicação de diagramas de estadosAplicação de diagramas de estados

17.17. Diagramas de sequência e colaboração (comunicação)Diagramas de sequência e colaboração (comunicação)

18.18. Aplicação de diagramas de sequência e colaboraçào (comunicação)Aplicação de diagramas de sequência e colaboraçào (comunicação)

19.19. Diagramas de atividades, componentes e aplicação e suas aplicaçõesDiagramas de atividades, componentes e aplicação e suas aplicações

20.20. Extensões UML para a InternetExtensões UML para a Internet

21.21. Aplicação de extensões UML para a InternetAplicação de extensões UML para a Internet

22.22. Especificidades de Análise e Projeto de Sistemas para a InternetEspecificidades de Análise e Projeto de Sistemas para a Internet

ApresentaçãoApresentaçãoee

Conceitos fundamentais de Conceitos fundamentais de Análise e Projeto de SistemasAnálise e Projeto de Sistemas

Objetivo: mostrar a proposta do curso, Objetivo: mostrar a proposta do curso, suas vantagens e limitações e as suas vantagens e limitações e as

questões e os termos básicos que hoje questões e os termos básicos que hoje estão a ele vinculadosestão a ele vinculados

44 - Lafayette B. Melo – Análise e Projeto de Sistemas para a Internet – COINFO – CEFET-PB - Lafayette B. Melo – Análise e Projeto de Sistemas para a Internet – COINFO – CEFET-PB

• Bom, o curso é de ANÁLISE e PROJETO de SISTEMAS…– O que é análise?– O que é projeto?– O que é um sistema?

• A compreensão de um sistema implica os seguintes eventos:– Interdependência– Importação / exportação– Feedback– Homeostasia– Morfogênese– Entropia– Redundância

ApresentaçãoApresentação


• Falhas no entendimento de um sistema ocorrem devido a falhas nos seus eventos– A história do desenvolvimento de um sistema de balanço

Falha no entendimento do sistema devido a uma provável falta de feedback


• Desvantagens da disciplina ANÁLISE E PROJETO DE SISTEMAS PARA A INTERNET– Relativamente nova no curso– Nova para a Internet– Falta de experiência acadêmica da disciplina– Falta de experiência empresarial, prática (sic), real ou outro

termo melhor

• Alguma sugestão para melhorar de cara?

• Alguma orientação também para que “o curso sirva para algo”?

• Alguma motivação de vocês para fazer o curso?



• Minhas motivações…– Estudar e trabalhar com novos paradigmas científicos em

computação• A computação e o desenvolvimento de sistemas deram uma

guinada científica em função, entre outras coisas, da convergência do mundo acadêmico com as atividades de desenvolvimento “reais”

– Estudar a tecnologia e o desenvolvimento em uma atividade prática e próxima do dia-a-dia do profissional à luz de novos paradigmas científicos

• Isso só é possível sabendo antes o que é:– CiênciaCiência– TecnologiaTecnologia– ProdutoProduto– ModeloModelo– MétodoMétodo– E até mesmo escolher um tema de projetoE até mesmo escolher um tema de projeto



• Dicas para escolher um tema para o projeto– 1) identificar as “necessidades” antes de tudo– 2) propor soluções ADEQUADAS para as necessidades

• Grandes fracassos em desenvolvimento de software começaram por não atender o que foi dito anteriormente!

• … mas há outra motivação mais SÉRIA:– Entender o que tem a ver ciência, tecnologia, desenvolvimento,

empregabilidade, mercado (sic)? OU SEJA, como dar sentido ao fato de estudar aqui no CEFET e exatamente esta disciplina?



• Possíveis respostas– Ter um diferencial para o que tem hoje no mercado– Entender que um sistema bem especificado, com uma

elaboração rigorosa e formal, e bons testes e controles PODE NÃO DAR CERTO!

• Cuidado com quem sempre despreza isso e também com quem acha que assim sempre dará certo!

– Ter uma visão conjunta dos fatores críticos de sucesso do futuro

• 1) do profissional• 2) do ferramental• 3) do desenvolvimento integrado• 4) da prototipação• 5) da orientação a objeto• 6) e principalmente do que é um trabalho com contrato

– Mesmo sem contrato, faça “APLICATIVOS MATADORES Mesmo sem contrato, faça “APLICATIVOS MATADORES PARA A INTERNET” (Yourdon)PARA A INTERNET” (Yourdon)



• O mercado não está tão bom mas questões como o estudo dos modelos de desenvolvimento e a avaliação deles têm sido cruciais para as reais mudanças na pesquisa e no mercado…

• OPS! É aí que entra a ANÁLISE E O PROJETO DE SISTEMAS PARA A INTERNET

• E as especificidades para se pensar em APS para a Internet podem começar com os seguintes fatores:– Sempre houve medo de controle, mas a tecnologia evoluiu e

precisou de novas formas de desenvolvimento para efetivar melhor o controle, além das ferramentas e linguagens

– Há um Tsunami de empregos na Internet• É importante definir os trabalhos da ciência da informática e

suas especificidades na Internet e como mudam em função do conhecimento



• EXERCÍCIO DA APRESENTAÇÃO– Identifique necessidades de informatização na Internet para um

determinado problema e proponha soluções adequadas para este problema. Você pode imaginar uma situação, mas não pode prescindir de pensar na “adequabilidade” em relação a sua função profissional, ao ferramental que você imagina utilizar e com a forma como você pensa desenvolver.


1.1. Noções de Engenharia de SoftwareNoções de Engenharia de Software1.1 O problema do software1.1 O problema do software1.2 A velha crise do software!1.2 A velha crise do software!1.3 Os velhos mitos do software!1.3 Os velhos mitos do software!

Objetivo: mostrar o que é a Engenharia Objetivo: mostrar o que é a Engenharia de Software e a sua importância na de Software e a sua importância na

análise e projeto de sistemasanálise e projeto de sistemas


1.1 O PROBLEMA DO SOFTWARE1.1 O PROBLEMA DO SOFTWARE

• O software é um produto diferencial em vários aspectos…– Evolutivo– Feedback, interacional

• …e faz a diferença hoje até mais do que o hardware

• Evolução do software:

Noções de Engenharia de Software Noções de Engenharia de Software

Primeiros anos:Primeiros anos:• Batch• Distribuição limitada• Customizado

Segunda era:Segunda era:• Multiusuário• Tempo real• Produto de software

Terceira era:Terceira era:• Sistemas distribuídos• IA• Baixo custo de hardware

Quarta era:Quarta era:• Desk-top poderoso• Orientação a objeto• Sistemas especialistas / redes neurais

1950 1960 1970 1980 1990 2000

Adaptado de Pressman (1995)


• Em direção a uma quinta era novos problemas surgem– A sofisticação do software ultrapassou a capacidade de

construir um software que tirasse potencial do hardware– A capacidade de construir programas não acompanha a

demanda– A capacidade de construir programas é ameaçada por projetos

ruins e recursos inadequados

• Em resposta a esses problemas estão sendo adotadas práticas da engenharia

• Especificamente, em relação ao desenvolvimento para a Internet, há alguma mudança?



• Voltando às práticas de engenharia, um dos primeiros problemas encontrados foi a própria definição de software– Instruções que quando executadas produzem a função e o

desempenho desejados (Pressman)– Estruturas de dados que possibilitam que os programas

manipulem adequadamente a informação– Documentos que descrevem a operação e o uso dos programas– Fairley diferencia produto de software de software para uso

pessoal – Há definições do ponto de vista de outros profisionais que não

são de informática, mas participam do desenvolvimento do software

– Há definições do ponto de vista do usuário

• E software para a Internet?



• Talvez o melhor seja descobrir as características do “software” para os interesses da disciplina em relação ao desenvolvimento. Nesse caso:– 1) O software é desenvolvido ou projetado por engenharia, não

manufaturado no sentido clássico• Problema para a engenharia de hoje: a visão do software

nem como produto de engenharia nem como produto de manufatura

– 2) O software não se desgasta• Há uma diferença básica em relação ao HARDWARE!

Curvas de falhas - Pressman (1995)


– 3) A maioria dos softwares é feita sob medida em vez de ser montada a partir de componentes existentes

• A visão de hoje no desenvolvimento radicalizou mais

• Mas em relação ao desenvolvimento existem hoje novas formas de concebê-lo que subvertem muito a concepção tradicional– XP (eXtreme Programming) por exemplo:

• se baseia em quatro valores– FeedbackFeedback– ComunicaçãoComunicação– Simplicidade Simplicidade – CoragemCoragem

• De uma forma que nem vê o software como um produto de manufatura nem como uma adaptação da engenharia, mas como “a construção de um livro”


• Além das características, é importante também

compreender os componentes de software– Há os componentes executáveis e os não executáveis

Exigências do cliente

Conversões que mapeiam as exigências

Projeto

Conversão em uma linguagem que especifica as

estruturas de dados, os atributos procedimentais e

os requisitos

Tradutor

Conversão em instruções que são executadas em uma

máquina


• O software ainda possui aplicações que têm como fatores importantes o conteúdo e a determinância– Software básico– Software de tempo real– Software comercial– Software científico e de engenharia– Software embutido– Software de computador pessoal– Software de IA– …


1.2 A VELHA CRISE DO SOFTWARE!1.2 A VELHA CRISE DO SOFTWARE!

• Problemas associados– Não dedicamos tempo para coletar dados sobre o processo de

desenvolvimento de software– A insatisfação do cliente é frequente– A qualidade de software é questionada– O software é difícil de manter

• As causas podem ser atacadas pela ES– Projeto– Comunicação– Gerência– Enfrentamento de mudanças

– Bom, XP subverte esta idéia, que seria nova!Bom, XP subverte esta idéia, que seria nova!


1.3 OS VELHOS MITOS DO SOFTWARE!1.3 OS VELHOS MITOS DO SOFTWARE!

• Administrativos• Mito1: Já tenho um manual com padrões e procedimentos.

Isso já não oferece o que o pessoal precisa saber?• Realidade: O manual é usado? Os profissionais têm

conhecimento? Reflete uma prática moderna? É completo?

• Mito2: Meu pessoal tem as ferramentas de desenvolvimento de última geração e os melhores computadores

• Realidfade: As ferramentas de ES são mais importantes do que o hardware, mas a maioria ainda não usa

• Mito3: Se estamos atrasados, podemos adicionar mais programadores e tirar o atraso (horda de mongóis)

• Realidade: O desenvolvimento de software não é mecânico igual à manufatura


• Mitos do cliente• Mito1: 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 do fracasso. É fundamental uma descrição mais formal.

• Mito2: 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, pode ser muito mais dispendiosa do que se fosse solicitada no início


• Mitos do profissional• Mito1: assim que escrevermos o programa e o colocarmos

em funcionamento, nosso trabalho estará completo• Realidade: “quanto mais cedo se escreve o código, mais

tempo se demora para terminá-lo”

• Mito2: enquanto não tiver o programa “funcionando”, eu não terei como avaliar sua qualidade

• Realidade: as revisões técnicas formais têm sido mais eficientes do que os testes para a descoberta de certa classe de problemas de software

• Mito3: a única coisa a ser entregue em um projeto bem sucedido é o programa funcionando

• Realidade: esta afirmação desconhece a figura adiante e a documentação


Programa Programa funcionandofuncionando

Especificação Especificação de testesde testes

Estrutura de Estrutura de dadosdados

ListagemListagemProjetoProjetoEspecificação Especificação de requisitosde requisitos

PlanoPlano


• Além de acabar com os mitos, é essencial– Oferecer assistência para as práticas– Melhorar a qualidade– Permitir que o software acompanhe o desenvolvimento do

hardware

• Quando combinamos…– Métodos abrangentes para todas as fases de desenvolvimento– Melhores ferramentas para automatizar o processso– Blocos de construção mais sólidos– Melhores técnicas para a qualidade de software– e uma filosofia de coordenação predominante, controle e

administração

• … fazemos uso da ENGENHARIA DE SOFTWARE


• Definições de Engenharia de Software

– “É a ciência e a arte de com economia, em tempo útil e de forma elegante, especificar, projetar, implementar e manter atualizados e corretos, programas, documentação e procedimentos operacionais para sistemas computacionais de utilidade para a humanidade” (Alan Brown, Anthony Earl e John McDermid)

– “Aplicação prática do conhecimento científico no projeto e construção de programas e da documentação requerida para desenvolver, operar e manter esses programas” (Boehm)

– etc


• Definição de ES de Fritz Bauer– “Estabelecimento e uso de sólidos princípios de engenharia

para que se possa obter economicamente um software que seja confiável e que funcione eficientemente em máquinas reais”

• A ES engloba:– 1) Métodos – “como fazer”

• Planejamento e estimativa de projeto• Análise de requisitos de software e de sistemas• Projeto da estrutura de dados• Arquitetura de programa e algoritmo de processamento• Codificação, teste e manutenção

– Os métodos muitas vezes introduzem notações gráficas Os métodos muitas vezes introduzem notações gráficas ou orientadas a uma linguagem especial e conjuntos de ou orientadas a uma linguagem especial e conjuntos de critérios para a qualidade de softwarecritérios para a qualidade de software


– 2) Ferramentas – apoio automatizado ou semi-automatizado aos métodos

• Sustentam cada um dos métodos ou os métodos de forma integrada (CASE – computer-aided software engineering)

• Combina hardware, software e banco de dados de ES

– 3) Procedimentos – elo que liga métodos a ferramentas• Sequência dos métodos• Produtos a serem entregues (deliverables)• Controles de qualidade e mudança

• A ES compreende conjuntos de etapas que envolvem métodos, ferramentas e procedimetos em modelos ou paradigmas de ES


• Na Internet, onde antes as informações eram usadas mais estaticamente, os métodos, ferramentas e procedimentos devem ser combinados para dar suporte a aplicações a serem usadas de diversas maneiras para os mais diversos usos



• EXERCÍCIO DE NOÇÕES DE ENGENHARIA DE SOFTWARE– Descreva como construir uma determinada aplicação para a

Web levando em consideração como o conteúdo e a determinância estão relacionados com os métodos, as ferramentas e os procedimentos.

3131 - Lafayette B. Melo – Análise e Projeto de Sistemas para a Internet – COINFO – CEFET-PB - Lafayette B. Melo – Análise e Projeto de Sistemas para a Internet – COINFO – CEFET-PB Noções de Engenharia de Software Noções de Engenharia de Software

2.2. Ciclos de vida do softwareCiclos de vida do software2.1 O ciclo de vida em cascata2.1 O ciclo de vida em cascata2.2 O ciclo de vida evolucionário2.2 O ciclo de vida evolucionário2.3 Prototipagem2.3 Prototipagem2.4 Modelo espiral2.4 Modelo espiral2.5 Métodos de desenvolvimento2.5 Métodos de desenvolvimento

• Objetivo: mostrar os modelos de desenvolvimento de software e os métodos de desenvolvimeto para que se esclareça a forma como os projetos eram e são desenvolvidos


• O estudo e a sistematização do processo de desenvolvimento de software, ou seja, a ES, requer que se conheçam as características do produto desejado e da tecnologia que será utilizada

• A partir dela, surgiram questões relacionadas às práticaspráticas e ao perfilperfil do profissional de informática e à visibilidadevisibilidade do projeto

• Práticas– Pergunta: Como vocês estão realizando o trabalho de

construção do sistema? (Yourdon)• Respostas: sobre uma ferramenta ou uma marca

– Tais respostas refletem o fracasso de construção do sistema que não leva em consideração melhores práticas:


• Gerenciamento de risco• Especificação• Inspeção e revisão de pares• Cronogramento e rastreamento com métricas• Rastreamento de defeitos e controle de qualidade• Especificações de hardware e software• Responsabilidade gerencial• Visibilidade

• Perfil do profissional de informática envolve habilidades• Comunicação• Capacidade de análise• Conhecimento da atividade do usuário• Capacidade de negociação• Administração de projetos• Conhecimento técnico

funções específicas para analistaanalista, projetistaprojetista, programadorprogramador


• Visibilidade– Como um modelo de ciclo de vidamodelo de ciclo de vida contempla o gerencimento

de software?• Através de um método que permita ver o progresso ou a

falta de progresso em um projeto

• Precisamos então entender esses modelos


• O processo de desenvolvimento é orientado por modelos de ciclo de vida– As funções primárias são:

• Determinar as fases• Determinar a ordem das atividades e a atividade de cada

etapa• Estabelecer critérios para a transição das fases

• O estudo do desenvolvimento trouxe novas sugestões– O mais primitivo foi o “caótico”, artesanal, “se colar colou”,

codificar e consertar, com foco na programação


• 2.1 O CICLO DE VIDA EM CASCATA2.1 O CICLO DE VIDA EM CASCATA

– A complexidade e o tamanho dos sistemas ocasionou sugestões mais focadas em sistemas do que em programas

– A primeira dessas sugestões foi baseada na engenharia de sistemas: o modelo em cascata

Análise

Projeto

Construção

Avaliação

Manutenção


• Análise– Requisitos do sistema– Domínio do problema– Requisitos e modelagem conceitual documentados para o

usuário

• Projeto– Vários passos com quatro atributos:

• Estrutura de dados• Arquitetura de software• Detalhe procedural• Projeto da interface• O documento especificação de projeto é baseado na

especificação de requisitos


• Construção– Codificação

• Avaliação• Inspeção• Walkthrough• Prova formal• Testes

– Os testes devem ser devidamente planejadosOs testes devem ser devidamente planejados• PERGUNTA: Quando o sistema é entregue ao usuário?PERGUNTA: Quando o sistema é entregue ao usuário?o após resultado satisfatório dos testes, mas pode haver erros

– Observados pelo usuário– De adaptação ao ambiente– De desempenho

• Manutenção– Modificações devido a erros, adaptação e desempenho


• O ciclo de vida em cascata ou “clássico” é o paradigma mais antigo e o que mostrou maior evolução até então

• Desvantagens

– Os projetos reais raramente seguem o fluxo sequencial do modelo

• Há necessidade de iterações

– É difícil declarar todas as exigências no início• Há incerteza natural nos projetos

– O cliente precisa de muita paciência• Há problemas terríveis em erros não previstos


Viabilidade – é viável?

• 2.2 CICLO DE VIDA EVOLUCIONÁRIO2.2 CICLO DE VIDA EVOLUCIONÁRIO

– Expansão gradativa com comportamentos do software

– É variante do “cascata” e o projeto foi decomposto em físico e lógico

Requisitos – ok?

projeto – concluído?

codificação – testado?

implantação – viável

manutenção – problemas?

lógico

físico


• 2.3 PROTOTIPAGEM2.3 PROTOTIPAGEM– Forma de desenvolvimento incremental com quatro tipos

• Ilustrativo (telas)• Simulado (acesso a banco de dados)• Funcional (subconjunto limitado)• Evolucionário (começa pequeno e cresce) – não descartável


• O que fazer com um protótipo quando ele identificar os requisitos de software?

• Desvantagens

– O cliente pode ver qualquer protótipo como uma versão de trabalho do software

– O desenvolvedor se familiariza com algumas opções de implementação e faz concessões para entregar o produto rapidamente

• A questão é se se deve planejar antecipadamente a construção de algo que se vai jogar for ou prometer entregar isso ao cliente

– Vale a pena defender a honestidade com o cliente?Vale a pena defender a honestidade com o cliente?


• Após o modelo evolucionário e de prototipação surgiram outros variantes

– Ciclo de vida com reutilização

– Ciclo de vida com síntese automática

– Modelos de fusão…

– … até o surgimento do que hoje se considera um metamodelo


• 2.4 MODELO ESPIRAL2.4 MODELO ESPIRAL

– Baseado em processos e níveis de risco

– Cíclico

– Pode ser considerado incremental

– Os riscos levam em conta “prosseguir” / “não prosseguir”

– O fluxo ao redor da trajetória em espiral leva ao desenvolvimento mais completo distribuído em quatro quadrantes


• 2.5 MÉTODOS DE DESENVOLVIMENTO2.5 MÉTODOS DE DESENVOLVIMENTO

• vários serão discutidos durante o curso, mas a tabela abaixo resume alguns

TÉCNICAS ABORDAGENS FERRAMENTAS

ANÁLISE

TRADICIONAL

*FUNCIONAL

*TEXTOS*FLUXOGRAMAS

ANÁLISEESTRUTURADA

*FUNCIONAL *DADOS

*DIAGRAMA DE FLUXO DE DADOS *DIAGRAMA DE ESTRUTURA DE DADOS*MINIESPECIFICAÇÕES*NORMALIZAÇÃO *DICIONÁRIO DE DADOS

ANÁLISE ESSENCIAL

*FUNCIONAL *DADOS

*CONTROLE

*TABELA DE EVENTOS *DIAGRAMA DE FLUXO DE DADOS *DIAGRAMA DE ENTIDADE-RELACIONAMENTO*DIAGRAMA DE TRANSIÇÃO DE ESTADOS*DIAGRAMA DE ESTRUTURA DE DADOS*NORMALIZAÇÃO *MINIESPECIFICAÇÕES*DICIONÁRIO DE DADOS

4747 - Lafayette B. Melo – Análise e Projeto de Sistemas para a Internet – COINFO – CEFET-PB - Lafayette B. Melo – Análise e Projeto de Sistemas para a Internet – COINFO – CEFET-PB Noções de Engenharia de Software Noções de Engenharia de Software

3.3. Análise de requisitos de sistema e Análise de requisitos de sistema e de softwarede software3.1 Análise de requisitos de sistema3.1 Análise de requisitos de sistema3.2 Análise de requisitos de software3.2 Análise de requisitos de software

• Objetivo: mostrar o papel da análise de requisitos de sistema e sua aplicacação na análise de requisitos de software, bem como as principais atividades e documentos associados


3.1 ANÁLISE DE REQUISITOS DE SISTEMA3.1 ANÁLISE DE REQUISITOS DE SISTEMA

• A análise de requisitos de sistema surgiu para solucionar problemas e o engenheiro de sistemas começa a sua resolução com metas e restrições definidas pelo cliente e deriva uma representação da função, desempenho, interfaces, restrições de projeto e estrutura

• Deve-se começar com a idéia de função desejada – demarcar o sistema ao identificar o escopo da função e desempenho requeridos (as restrições e as interfaces)

• Depois, deve-se passar para a tarefa de alocação – designar funções a um ou mais elementos do sistema


• Exemplo: sistema de classificação por correia transportadora (CLSS)


• O engenheiro de sistemas recebe uma declaraçaõ “nebulosa” dos objetivos do CLSS quanto ao movimento da linha, classificação, identificação, impressão, ordem e espaçamento

• Para demarcar, o engenheiro deve identificar o escopo da função e desempenho desejados– Não basta dizer que o robô reagirá rapidamente quando a

bandeja estiver vazia mas• 1) indicar o que é uma bandeja vazia para o robô• 2) saber os limites precisos de tempo• 3) qual forma uma resposta deve assumir


• Uma série de perguntas pode ser feita

– Quantos números de identificação?– Qual a velocidade da correia?– Qual a distância da estação para os depósitos?– E entre os depósitos?– O que aconteceria se uma caixa não tivesse o número de

identificação?– E se o depósito fica cheio?– As informações devem ser repassadas para outro canto?– Que erro é aceitável?– Que peças existem atualmente?– Que restrições de orçamento e prazo?


• FUNDAMENTAL!– Note que o engenheiro não pergunta como a tarefa deve ser

feita, mas o que é exigido

• Então, o engenheiro demarca as funções principais– Ler a entrada do código de barras– Ler o tacômetro de impulsos– Decodificar os dados dos códigos de peças– Executar busca em banco de dados– Determinar a localização do depósito– Produzir sinais de controle para o mecanismo de desvio


• ... E faz alocações alternativas– 1) treina e aloca operador de linha– 2) um leitor de código e um controlador com um desvio

mecânico– 3) um leitor de código e um controlador com um braço

mecânico

• Critérios para configuração do sistema– Consideraçôes de projeto– Considerações de negócio– Análise técnica– Avaliação da manufatura– Questões humanas– Interfaces ambientais– Consideraçôes jurídicas– Também deve se pensar em soluções não convencionais!!!


• As informações reunidas durante a etapa de identificação das necessidades deve ser reunida num Documento Conceitual do Sistema com algumas funções


• A modelagem é feita em um documento de especificaçao e pode ser feita em um diagrama de contexto da arquitetura e em um diagrama de fluxo da arquitetura

• Outras ferramentas como descrições e dicionários podem ser utilizados

Diagrama geral de contexto da arquitetura


Diagrama do CLSS do contexto da arquitetura


Diagrama do CLSS do fluxo da arquitetura


3.2 ANÁLISE DE REQUISITOS DE SOFTWARE3.2 ANÁLISE DE REQUISITOS DE SOFTWARE

• Qualquer que seja o projeto ou a boa codificação de um programa, a sua má análise frustará o usuário

• Esforços de uma análise de requisitos de software– Reconhecimento do problema– Avaliação e síntese– Modelagem– Especificação – Revisão

• No final, estar preparado para as ambiguidades– “sei que você acredita que entendeu o que acha que eu disse, mas

não estou certo de que percebe que aquilo que ouviu não é o que eu pretendia dizer…”


• Cada uma das tarefas descreve o problema de forma que uma solução global possa ser sintetizada

• Exemplo:– Um sistema de controle de estoques é exigido por um grande

fornecedor de autopeças– QUE PROBLEMAS NO ATUAL SISTEMA PODEM SER

IDENTIFICADOS?

• Como nos requisitos de sistema, o foco da síntese e avaliação deve cair sobre “o que” e não “como”

• Um manual do usuáriomanual do usuário pode ser rascunhado para o caso em que um protótipo não esteja sendo desenvolvido


• Um analista deve exibir nos seus esforços traços característicos…– Compreensão de conceitos abstratos– Absorver fatos pertinentes– Entender o ambiente do usuário– Aplicar elementos do sistema aos elementos do usuário– Comunicar-se bem nas formas escrita e verbal– Capacidade de “ver as florestas entre as árvores”

• … e coordenar cada uma das tarefas associadas à análise de requisitos de software


• Problemas durante a análise de requisitos de software

– Dificuldade para obter informações pertinentes– Complexidade– Mudanças durante e após a análise

• O crescimento do sistema aumenta os problemas e as mudanças começam a ser vistas em termos de mudanças de exigência– Primeira lei da engenharia de sistemas:

• “Não importa onde se esteja no ciclo de vida do sistema, o sistema se modificará, e o desejo de mudá-lo persistirá ao longo de todo o ciclo” (Bersoff)


• Técnicas de comunicação e facilitação para especificação de aplicações

• Um encontro pode estabelecer desconcerto entre as partes, mas algumas etapas podem ser iniciadas:– Perguntas livres do contexto (direcionadas ao cliente)

• Quem está por trás do pedido deste trabalho?• Quem usará a solução?• Qual é o benefício econômico de uma solução?• Há outra fonte para a solução exigida?

– Compreensão do problema (verbalização do cliente sobre uma percepção da solução)

• Como você caracterizaria um bom resultado?• Qual problema essa solução resolverá?• Você pode mostrar o ambiente?• Existem questões de desempenho ou restrições especiais?


– Metaperguntas (efetividade do encontro)• Você é a pessoa certa? Suas respostas são oficiais?• Minhas perguntas são pertinentes ao problema que você

tem?• Estou fazendo perguntas demais?• Há mais alguém que possa fornecer informações adicionais?• Existe algo mais que devo perguntar-lhe?

• A técnica FAST (facilitated application specification techniques) estimula a criação de uma equipe conjunta de clientes e desenvolvedores e tem algumas diretrizes– Encontros em locais neutros– Regras para participação– Agenda formal para cobrir os pontos importantes e informal

para encorajar o fluxo de idéias– Um moderador– Mecanismos de definição


• Após o encontro, desenvolvedores e clientes escrevem a requisição do produto com uma lista de objetos, suas restrições e desempenho, podendo ser feitas miniespecificações


• Exemplo para uma empresa de produtos de consumo:– Nossa pesquisa indica que o mercado para sistemas de

segurança domésticos cresce 40% ao ano. Gostaríamos de entrar no mercado construindo um sistema de segurança doméstico baseado em microprocessador que oferecesse proteção contra e/ou reconhecesse uma variedade de “situações” indesejáveis, tais como entrada ilegal, incêndio, alagamento e outros. O produto, experimentalmente chamado de SafeHOme, usará sensores apropriados para detectar cada situação, poderá ser programado pelo dono e telefonará automaticamente para uma agência de monitoração assim que uma situação for detectada


• Princípios de análise– 1) o domínio de informação deve ser representado e

compreendido– 2) modelos que desenvolvam a informação, função e

comportamento do sistema devem ser desenvolvidos– 3) os modelos e o problema devem ser divididos em partições– 4) o processo de análise deve mover-se da informação

essencial para os detalhes de implementação

• É importante saber ainda que:– O software processa dados e eventos– O modelo do software é diferente do software– O modelo tem partições com as funções mais importantes e os

detalhes crescentes


• Princípios da especificação

– 1) separar funcionalidade da implementação– 2) linguagens de especificação orientadas a processos são

exigidas– 3) a especificação abrange o sistema do qual o software faz

parte– 4) a especificação deve abranger o ambiente– 5) a especificação é um modelo cognitivo e obedece a algumas

leis físicas– 6) deve ser operacional– 7) tolerante com a não inteireza– 8) localizada e fracamente acoplada


• Princípios da representação

– 1) pertinência ao problema– 2) colocada em níveis– 3) diagramas e outras notações restritas quanto ao número e

consistente quanto ao uso– O QUE SIGNIFICA ESTA NOTAÇÃO?

– 4) revisável

• Há também uma série de princípios para uma revisão detalhada de toda a especificação do software mais específica do que a do sistema


• Revisão da especificação– Nível macroscópico

• Metas e objetivos permanecem consistentes?• Interfaces foram descritas?• O fluxo e a estruura são adequados?• Os diagramas são claros?• As funções estão no escopo?• O comportamento é consistente com informação e funções?• As restrições são realísticas?• Qual é o risco tecnológico?• Requisitos foram considerados?• Critérios de validação foram detalhados?• Há inconsistência, omissão, redundância?• Contato com o cliente é completo?• Protótipo ou manual foram revisados?• Estimativas foram afetadas?


• Revisão detalhada– Enunciados da especificação

• Olhar o porquê de conectivos persuasivos– Por exemplo, certamente, obviamente, claramentePor exemplo, certamente, obviamente, claramente

• Procurar termos vagos– Algum, às vezes, usualmente, o mais, na maior parteAlgum, às vezes, usualmente, o mais, na maior parte

• Identificar listas incompletas– Etc, assim po diante, daí pra frente, tal comoEtc, assim po diante, daí pra frente, tal como

• Limites declarados com pressuposições não declaradas– ““códigos variam de 0 a 100” (inteiro, real…)códigos variam de 0 a 100” (inteiro, real…)

• Cuidado com pronomes pendentes• Pedir prova das declarações com certeza• Evitar outras definições para um mesmo termo• Estrutura descrita em parágrafos (gráfico? Figura?)• Quando houver cálculo, criar 2 exemplos


4. Análise estruturada4. Análise estruturada 4.1 DFD 4.1 DFD 4.2 Dicionário de dados 4.2 Dicionário de dados

Objetivo: introduzir a análise Objetivo: introduzir a análise estruturada e suas ferramentas para estruturada e suas ferramentas para

uma compreensão geral de seu uma compreensão geral de seu funcionamentofuncionamento


• A análise estruturada é uma atividade de construção de modelos (modela o fluxo e o conteúdo)

– Já foi muito utilizada – Muito criticada– Ainda existe em muitos documentos– Muitas adaptações– E foi a primeira– Não teve um documento original único– É associada ao projeto estruturado


• 4.1 DFD4.1 DFD

• A idéia é de que um modelo de fluxo pode ser feito por qualquer tamanho e complexidade com representações– Transformação– Entrada– Saída– Entidade externa

• DFD ou gráfico de bolha mais primitivo

S ie tem ab as ead o emc o m p u tad o r

E n tid ad eex ter n a






• O exemplo do Safehome

– O software SafeHome possibilita que o dono da casa configure o sistema de segurança quando ele for instalado, monitora todos os sensores ligados ao sistema e interage com o dono da casa por meio de um teclado e teclas de função…


• Exemplos de diagramas de DFD para o SafeHome


• Notações básicas

1

1

Produtor ou consumidor de informações fora dos limites do sistema a ser modelado

Transformador de informações que resida dentro dos limites a ser modelado

Repositório de dados que são armazenados para serem usados em um ou mais processos

Item de dados ou coleção de itens (fluxo)

5. Gerenciamento de Software5. Gerenciamento de Software

Objetivo: entender a idéia de Objetivo: entender a idéia de gerenciamento aplicada ao processo de gerenciamento aplicada ao processo de

desenvolvimento de sotware e obter desenvolvimento de sotware e obter uma noção de como são usadas as uma noção de como são usadas as

métricas de desempenhométricas de desempenho


• Software como produto de um projeto– Pistas para o problema:

• Primeiro a sobrevivência, depois a organização• Não há pessoas para enxergar a importância• Optar um método para as condições é custoso

Conhecimento e prática

administrativa

Conhecimento da área de aplicação

Gerência de projetos


• A gerência de projeto se constitui de um conjunto de ações que geram um resultado

– Executadas por pessoas…

– que devem ser informadas do que estão fazendo, porque, quanto tempo dispõem, onde e como devem fazer

• Pessoas com alguma vivência ajudam nas estimativas

– Dos riscos

– Das incertezas


• Atividade de gerência de projetos de software


• Também existem algumas etapas para a gerência de projetos– No entanto não devem ser seguidas como solução definitiva– Devem ser adaptadas de acordo com o projeto


• ESCOPO DE SOFTWARE

– Objetivos e requisitos iniciais

– Conveniência de se realizar ou não o projeto

– São realizadas estimativas quanto a recursos, prazos e custos

– São definidas viabilidades técnicas, operacionais e econômicas:

• Quantidade de pessoas, ambiente, exigências de hardware e software etc

– TÉCNICAS:

• Estimativa de linha de código e ponto por função

• Modelo de custo construtivo (COCOMO)

• Estimativa de Putnam

• Modelo de pontos por função


– As informações inciais da definição de escopo resultam em um contrato de desesenvolvimento ou “proposta de desenvolvimento do sistema”

• Há funções e pré-requisitos que dependem do comprometimento do cliente

• Deve ser;– ClaroClaro– Não tendenciosoNão tendencioso– Realista e viávelRealista e viável


• PLANEJAMENTO

– Comece bem: defina QUAIS atividades devem ser realizadas

– Definição das atividades

• O QUE

• POR QUE

• QUEM

• QUNADO

• COMO

• ONDE

– Os cronogramas são importantes e definem ordem e sequência


• ORGANIZAÇÃO E COORDENAÇÃO– Formação humana (administrativa) com alguns cuidados

• Combinar conhecimentos técnicos de cada pessoa com uma tarefa apropriada

• Não colocar tarefas para quem não pode• 1 tarefa de cada vez• Obter comprometimento, não só envolvimento

– Depois das pessoas, o que é mais importante?

– Ao combinar as pessoas com outros fatores, considerar aspectos fundamentais

• Trabalhar com pequenos grupos• Liderança técnica por competência• Local de trabalho adequado


– Benefícios:• Redução de problemas de comunicação• Padrão de qualidade• Aprendizado mútuo• Sociabilização do trabalho


• ORGANIZAÇÃO E COORDENAÇÃO– Milestones (pontos de controle específicos)

• Andamento• Atraso

– Controle• Informal

– Interação casual (intencional ou não)Interação casual (intencional ou não)– Diminui a frequência e a burocraciaDiminui a frequência e a burocracia

• Formal (periódico)

• Revisão gerencial (com narrativa do ponto atual e justificativa)

• Revisão técnica (aspectos mais específicos)


• Revisões

– Revisar é fazer mudanças

– Reconstrução, reordenação ou inclusão de outras atividade

– Rastreabilidade

– Razões:• Perda de prazo• Tarefa mal feita ou não realizada• Mudança imprevisível• Corte de recursos• Novos elementos no escopo inicial


• COMPLEMENTOCOMPLEMENTO da primeira parte da primeira parte antes da provaantes da prova

• Métodos de quarta geração em engenharia de software e novos paradigmas

• Métodos de entrevista e abordagem com o usuário / cliente

• Dicionário de dados

• Exemplo de tabela simples de orçamento


• Métodos de quarta geração em engenharia Métodos de quarta geração em engenharia de software e novos paradigmasde software e novos paradigmas

• O modelo do ciclo de espiral é considerado um modelo que engloba os demais e os seus quadrantes envolvem os outros paradigmas– Planejamento– Análise / Avaliação das alternativas / riscos– Desenvolvimento / Engenharia de software– Avaliação do cliente

• Apesar disso tudo, ainda há técnicas de quarta geração e outras formas de combinação de paradigmas que podem não ser contempladas no ciclo de espiral…


• Técnicas de quarta geração (4GT)– Abrangem um amplo conjunto de ferramentas de software que

possibilitam que o desenvolvedor especifique alguma característica do software em um nível elevado

• Têm desenvolvido bastante mas continuam dependentes do diálogo cliente-desenvolvedor

• Para pequenas aplicações é possível passar diretamente da etapa da coleta de exigências para a implementação usando um linguagem de quarta geração (4GL)

• O uso de 4GL sem planejamento ocasiona os mesmos problemas que ocorrem nos enfoques convencionais

Coleta de requisitos

Estratégia de projeto

Implementação 4GL

Teste


• Prós– Redução no tempo de desenvolvimento– Produtividade aumentada

• Contras– Não são fáceis quanto se imagina– O código produzido é ineficiente– A manutenibilidade é questionável

• Situação atual– São mais voltadas para aplicações comerciais, mas já há uso

para aplicações de engenharia e de tempo real– Tempo reduzido para aplicações pequenas e intermediárias– Para grandes projetos, necessita-se tanto ou mais análise,

planejamento e teste


• Combinação de paradigmas– Além do espiral, qualquer paradigma pode constituir uma base

sobre a qual outros paradigmas são integrados, incluindo o uso de 4GT

– Não há necessidade de ser dogmático em relação a paradigmas para a engenharia de software – a natureza da aplicação deve ditar a abordagem a ser tomada

– Contudo, para uma prototipagem evolutiva, algumas eventos podem ser priorizados

• O usuário é incapaz ou não deseja examinar modelos abstratos em papel, como os diagramas e fluxos de dados.

• O usuário é incapaz ou não deseja articular seus requisitos de alguma forma e só pode determinar seus requisitos por meio de um processo de tentativa e erro.

• O sistema deverá ser em-linha, com atividades com tela completa em terminal, ao contrário dos sistemas de edição, atualização e relatório em lote.

• O sistema não requer a especificação de muitos detalhes em algoritmos.


• Métodos de entrevistaMétodos de entrevista

• Na maioria das vezes, os elementos de que o analista precisa não estão a sua disposição de forma clara

• Métodos para coleta de informações– Entrevistas– Pesquisas em arquivos, manuais de procedimentos

operacionais, administrativos e outros, bem como a verificação de todos os tipos de registros de informações existentes

• A entrevista deve ser planejada, desenvolvida sem divergência e com controle da arrogância


• Planejamento (todos os pontos devem ser obedecidos)

– 1) Marcação de data e horário

– 2) Preparação do entrevistador – com preparação dos itens e sua sequênca, com alguma documentação e registro

– 3) Comportamento do entrevistador – adequação ao local, atenção ao entrevistado, interesse em resolver os problemas que lhe atingem, sem desviar a atenção para outros assuntos

– 4) Linguagem – evitar termos técnicos e só expressar elogios de forma honesta

– 5) Distinção entre fatos e opiniões

– 6) Necessidades do usuário – cuidado com o raciocínio em termos pessoais e o pedido antecipado de relatórios ou inclusão de recursos não necessários


• Considerações gerais

– A entrevista pode ser dividida em três partes de forma que seja imperceptível para o usuário

– Perguntas abertas são bem vindas

– Princípios: não criticar a empresa, o trabalho do entrevistado, o sistema existente ou qualquer funcionário

– Relatório após deve ser feito com máxima urgência, para não esquecer os detalhes, mesmo que tenha gravado ou filmado

– Alguns princípios não tradicionais, sociais e situados podem ser observados para se fazer uma entrevista proveitosa


• Dicionário de dados na análise estruturadaDicionário de dados na análise estruturada

• O dicionário de dados ou “dicionário de requisitos” surgiu para suprir a pouca definição que tem cada item

• Definição– Listagem organizada de todos os elementos de dados que são

pertinentes ao sistema, com definições precisas e rigorosas, de forma que tanto o usuário quanto o analista de sistemas tenham uma compreensão comum das entradas, das saídas, dos componentes dos depósitos de dados e até mesmo dos cálculos intermediários (Yourdon)


• A maioria dos dicionários de dados têm as seguintes informações, compreendendo elementos de dados e estrutura de dados– Nome: o nome principal do elemento

– Alias / pseudônimo: outros nomes usados para a primeira entrada

– Descrição: representação do conteúdo (deve ser curta!)

– Formato: se o dado é numérico, alfabético, alfanumérico, além de informações como comprimento e casas decimais, se houver

– Validade: o que é aceito pelo sistema. Ex.: data de emissão de duplicata igual ou inferior ao seu pagamento

– Controle: para garantir a integridade: data de origem, origem da informação, programas que utilizam o item e autorização de mudanças

– Grupos: estruturas e localização física (banco de dados, registros, arquivos) e os programas que utilizam o item


– Considerações sobre as informações

Os três primeiros itens podem ser agrupados em informações geraisOs três primeiros itens podem ser agrupados em informações gerais

Os dicionários podem ter as mais diversas adequações e é Os dicionários podem ter as mais diversas adequações e é recomendável que ferramentas de engenharia de software auxiliadas recomendável que ferramentas de engenharia de software auxiliadas por computador sejam utilizadaspor computador sejam utilizadas

O item descrição de conteúdo pode se comportar como sequência, O item descrição de conteúdo pode se comportar como sequência, seleção ou agrupamentoseleção ou agrupamento

Construção de dados

Notação Significado

= é composto de

sequência + e

seleção [ | ] ou…ou

repetição { }n n repetições de

( ) dados opcionais

* * comentário


• Exemplo com o SafeHome

– No DFD de nível 2 do SafeHome o item de dados número telefônico é especificado

• Nome: número telefônico

• Pseudônimo: não tem

• Onde / como é usado: avaliar com planejamento (saída), discar número telefônico (entrada)

• Descrição:– Número telefônico = [extensão local | número externo]Número telefônico = [extensão local | número externo]

– Extensão local = [2001 | 2002 | … | 2999]Extensão local = [2001 | 2002 | … | 2999]

– Número externo = 9 + [número local | número de longa Número externo = 9 + [número local | número de longa distância]distância]

– Número local = prefixo + número de acessoNúmero local = prefixo + número de acesso

– Número de longa distância = (1) + código de área + número Número de longa distância = (1) + código de área + número locallocal

– Prefixo = [795 | 799 | 874 | 877]Prefixo = [795 | 799 | 874 | 877]

– Número de acesso = *qualquer série de quatro números*Número de acesso = *qualquer série de quatro números*


• Exemplo com o de reposição de peças (exemplo em doc)

Nome: Número de peçaPseudônimo:Descrição: campo-chave que identifica singularmente uma peça específica no estoqueFormato: Alfanumérico, 8 caracteresLocalização: Relatório de estoque por execeção

EstoqueReposição

Nome: Reposição - quantidadePseudônimo:Descrição: o número de unidades de uma determinada parte deverá ser reposto de uma só vezFormato: Numérico, 5 dígitosLocalização: Relatório de estoque por execeção

EstoqueReposição


• Importância do dicionário de dados

– Documentação oficial e comunicação

– Evitar redundância

– Padronização

– Grande fonte de consulta


• Exemplo de tabela simples de orcamentoExemplo de tabela simples de orcamentoItem Descrição Período Pessoas Unid Qtde Valor Unit. Valor Total1 Recursos Humanos1.1 Treinamento

Pessoal PróprioConsultoresDeslocamentoAssessoria

1.2 ProjetoPessoal PróprioConsultoresAssessoriaDeslocamento

1.3 ImplantaçãoPessoal PróprioConsultoresDeslocamento

1.4 Manutenção

2 Infra-Estrutura2.1 Hardware

Microcomputadores - EstaçõesServidoresImpressorasRede

2.2 SoftwareFerramentasLinguagensSGBD

2.3 Instalações físicasMobiliárioSuprimentos

TOTAL XXXXXXX


6. Análise essencial6. Análise essencial

6.1 DFD6.1 DFD6.2 DER6.2 DER6.3 DTD6.3 DTD6.4 Dicionário de dados6.4 Dicionário de dados

Objetivo: entender a noção de análise Objetivo: entender a noção de análise essencial e suas ferramentasessencial e suas ferramentas


• O modelo essencial surgiu como uma revisão do modelo estruturado

• O modelo essencial critica a abordagem clássica de modelos de sistemas no seu desenvolvimento e como são abordados– Modelo físico atual

– Modelo lógico atual

– Novo modelo lógico

– Novo modelo físico


• Críticas do modelo essencial à abordagem clássica– O analista pode não conhecer a aplicação ou o ramo de

atividade– O usuário não querer ou não poder trabalhar com um novo

modelo lógico– Um menor esforço para transformação de um modelo lógico

atual em um modelo físico

Análise e Projeto de Sistemas para a Internet Centro Federal de Educação Tecnológica da Paraíba...

Documents

Transcript of Análise e Projeto de Sistemas para a Internet Centro Federal de Educação Tecnológica da Paraíba...