Apostila analise de sistemas by Marcelo Pereira Silveira

Z91a

Zoucas, Alessandra Casses Análise de Sistemas / Alessandra Casses Zoucas. – Florianópolis : Publicações do IF-SC, 2010. 74 p. Inclui Bibliografia. 1. Análise de sistemas. 2. Diagrama de casos de uso. 3. Diagrama de sequência. 4. Diagrama de Fluxo de Dados. 5. Ciclo de vida. II. Título.

CDD: 001.61

Catalogado por: Augiza Karla Boso CRB 14/1092 Rose Mari Lobo Goulart CBR 14/277

Organização de conteúdo: Andrino Fernandes Elaine Luz Barth

Comissão Editorial: Hamilcar Boing Andrino Fernandes Elaine Luz Barth

Produção e design instrucional: Andrino Fernandes Elaine Luz Barth

Projeto gráfico: Paulo Ricardo Rodrigues de Lima

Capa: Lucio Baggio

Revisão ortográfica: Marcos Pessoa

Editoração Eletrônica: Hudson Ricardo Borges

Sumário Capítulo 1 - Introdução a Análise de Sistemas 1.1Conceitos Básicos...........................................................................................................11 1.2 Linha do Tempo............................................................................................................12 1.3.1 Análise Estruturada...................................................................................................14 1.4 Revendo a história........................................................................................................15 1.5 Análise Essencial...........................................................................................................16 1.6 Análise Orientada a objeto............................................................................................18 1.6.1 Abstração de Dados:..................................................................................................19 1.6.2 Atributos:....................................................................................................................19 1.6.3 Relacionamentos:.......................................................................................................20 1.7 Problema X Solução......................................................................................................21

Capítulo 2 - Levantamento de Requisitos 2.1 Requisitos Funcionais....................................................................................................27 2.3 Rastreabilidade..............................................................................................................29 2.4 Processo de Engenharia de Requisitos...........................................................................30 2.5 Técnicas para Levantamento de requisitos....................................................................31 2.7 Gerência de Requisitos..................................................................................................33 2.8 Quais são as pricipais atividades da Gerência de Requisitos? .......................................34 2.9 Regra de Negócio (RNE) ..............................................................................................34

Capítulo 3 - Diagrama de casos de uso 3.1 Sistema.........................................................................................................................3 8 3.2 Ator...............................................................................................................................3 8 3.3 Casos de uso.................................................................................................................39 3.4 Documentação de casos de uso.....................................................................................4 0 3.6 Relacionamentos..........................................................................................................43

Capítulo 4 - Diagrama de Sequência 4.1 Alguns elementos de um diagrama de sequência...........................................................50 4.2 Diagrama de Classe.......................................................................................................51 4.3 Exercícios de Aprendizagem..........................................................................................52

Capítulo 5 - Diagrama de Fluxo de Dados - DFD 5.1 Como elaborar um DFD................................................................................................56 5.2 Níveis do DFD...............................................................................................................58 5.3 Vantagem do uso de DFD´s em níveis ........................................................................5 9 5.4 Exercícios de aprendizagem...........................................................................................60

Capítulo 6 - Ciclo de Vida 6.2 Os componentes do desenvolvimento de um ciclo de vida............................................64 6.3 Modelos de ciclo de vida...............................................................................................64 6.3.1 MODELO SEQUENCIAL.....................................................................................64 6.3.2 MODELO CASCATA............................................................................................64 6.3.2 MODELO V..........................................................................................................6 6 6.3.4 MODELOS INCREMENTAIS................................................................................66 6.3.5 RUP (Rational Unified Process)............................................................................67 6.3.6 MODELO EVOLUTIVO ��71

Apresentação

Caro estudante, Você já pensou que um dos fatores de sucesso na construção de um software tem relação direta com a comunicação entre o fornecedor do sistema e os seus clientes? Sabe por que isso acontece? Porque o fornecedor do sistema deve procurar compreender os problemas do seu cliente para propor soluções de software que se aproximem das expectativas destes clientes. Para isto, é necessário que se obtenha e se documente informações sempre coletadas junto ao cliente. Elas servem de suporte na construção do software que deve estar alinhado a essas expectativas. Existem outros fatores importantes. Por exemplo, o sucesso de um software tem relação direta com a comunicação do fornecedor do sistema e sua equipe de desenvolvimento de software. Isto acontece por que o fornecedor do sistema deve procurar transmitir claramente para sua equipe de desenvolvimento de software as características da solução proposta e aprovada pelo cliente. Assim, ele poderá ter uma garantia inicial de que o software que será construído atenderá às expectativas do seu cliente. Entretanto, as coisas não são tão simples como podem parecer. Estabelecer estas comunicações de forma eficiente não é uma tarefa fácil. Tipicamente, pode ocorrer ruído nesta comunicação, e isto pode acarretar na construção de um software com problemas do ponto de vista do usuário. Sendo assim, nesta disciplina você estudará os elementos que auxiliam na geração de uma comunicação eficiente (com a menor interferência de ruídos possível) visando sempre a garantia de que o produto criado atenderá as expectativas do cliente. Para atingir este objetivo iremos estudar técnicas de levantamento e documentação das necessidades dos nossos clientes, tanto do ponto de vista do usuário quanto do ponto de vista do desenvolvedor de software. Seja bem-vindo(a) a disciplina Análise de sistemas. É um prazer acompanhá-lo (a) em mais uma jornada no mundo virtual. Realize todas as atividades recomendadas e planeje os seus estudos. Sucesso e boas aulas! Um abraço, Profa. Alessandra Zoucas

CAPÍTULO

1 Introdução a Análise de Sistemas

Objetivo Apresentar alguns conceitos básicos que estão relacionados à análise de sistemas. Verificar as principais metodologias de desenvolvimento. Estudar a diferença entre domínio do problema e solução.

Introdução a Análise de Sistemas A seguir são apresentados conceitos que estão presentes no conteúdo desta apostila. Logo, para maior aproveitamento da leitura é importante que o leitor saiba onde encontrar as definições apropriadas para os conceitos tratados neste material de modo a familiarizar-se com eles.

1.1Conceitos Básicos Análise: derivado do grego analýein - desatar, soltar, significa dissolução de um conjunto em suas partes. Em sentido amplo, empregam-se os termos “análise” e “analisar” como sinônimo de exame e examinar, pesquisa e pesquisar, verificação e verificar [1].

Análise de Sistemas: representa o estudo detalhado de uma área de trabalho (processo), que antecede uma ação que, quase sempre, implica no desenvolvimento de um conjunto de programas integrados (sistemas) destinados à execução, controle acompanhamento do processo [1].

Analista de Sistemas: é o profissional que atua na área de desenvolvimento, manutenção e produção de sistemas e na customização de sistemas.

Características (Features): permite definir um escopo mais refinado do trabalho a ser feito. É uma abstração intermediária entre as necessidades dos stakeholders e os requisitos do sistema [12].

Necessidades: está ligada diretamente com o real problema de negócio que será resolvido, ou seja, o objetivo é resolver o problema. Deve orientar todo o processo de identificação de requisitos [12].

Processo: conjunto de atividades inter-relacionadas, que transforma entradas em saídas (ABNT, 1998).

Produto de Software: é a entidade de software disponível para liberação do usuário [12].

Qualidade de Software: é a totalidade das características de um produto de software que lhe concede a capacidade de satis-

Análise de Sistemas fazer às necessidades explícitas e implícitas, ou seja, é a capacidade em atender aos requisitos [12].

Sistema: conjunto de elementos (subsistemas) independentes entre si, com vistas a atingir um objetivo [1].

1.2 Linha do Tempo Inicialmente falaremos sobre a linha do tempo relacionada ao desenvolvimento de software [2]:

Introdução a Análise de Sistemas

1970 - Crise do Software Entre outros, foram atribuídos como principais fatores dessa crise: o desenvolvimento de softwares de forma “artesanal”, con-

Análise de Sistemas

tínuos erros de execução, tempo da coleta de dados, descumprimento de prazos, problemas relacionados aos custos, inexistência de documentação ou elegibilidade da mesma, falta de comunicação durante do desenvolvimento do software, falta de testes e a insatisfação dos usuários [2].

1.3 Metodologias de desenvolvimento de Softwares A partir de 1970 surgiram metodologias para o desenvolvimento de Softwares identificadas como: Análise Estruturada, Análise Essencial, e Análise Orientada a Objetos.

1.3.1 Análise Estruturada Esta análise é utilizada para auxiliar na comunicação entre as pessoas envolvidas no processo de desenvolvimento do software, assim como no gerenciamento da complexidade, entendimento do problema e na redução dos custos [2]. A metodologia de Análise Estruturada é baseada na decomposição funcional e na utilização de diagramas de fluxos de dados (DFD). Suas principais fases são [3]: Figura 1. Fonte: http://www.zsc.com.br/images/ANALISAR.gif

Fase 1- Estudo Inicial O ponto inicial desta metodologia é dado pelo esforço de garantir que os sistemas escolhidos para serem desenvolvidos são aqueles que se garantem em ambientes competitivos. A relação custo benefício (do ponto de vista financeiro) é considerada como o critério mais importante no processo de seleção, quando então, os sistemas são apontados como responsáveis pela contribuição crescente do faturamento, crescentes custos ou a melhoria dos serviços oferecidos [3].

Introdução a Análise de Sistemas Fase 2 – Estudo Detalhado Nesta fase procura-se entender o sistema de forma detalhada e o usuário pode participar de forma informal para sanar algumas dúvidas que o analista do sistema possa ter sobre o processo [3]. Neste estudo detalhado os seguintes elementos deverão estar presentes [3]: • A definição dos usuários do novo sistema, com suas responsabilidades e funções. • Um modelo lógico do sistema atual que é um diagrama de fluxo de dados geral, os sistemas de interfaces e um DFD detalhado de cada processo considerado importante. • Uma declaração com os ganhos que são esperados com o sistema; • Um orçamento dos gastos necessários para finalização das próximas fases.

Fase 3 – Definição e Projeto de Soluções Alternativas Nesta fase busca-se definir as soluções para os problemas do sistema atual. Os objetivos da organização, definidos da fase inicial, são convertidos em um conjunto de objetivos do sistema [3].

Fase 4 – Projeto Físico O grupo do projeto refina a alternativa escolhida em um projeto físico específico que envolverá o detalhamento do DFD, projeto do banco de dados e a racionalização e normalização [3].

1.4 Revendo a história No final da década de 60, com a introdução da programação estruturada, apareceram as técnicas estruturadas. Foi na década de 70 que Steven Myers e Constantine propuseram os conceitos de projeto estruturado.

Figura 2. Fonte: http://www.exkola.com.br/site/files/carreira/carreira-818.jpg

Análise de Sistemas

Neste sentido buscou-se aplicar os conceitos de projeto estruturado à análise de sistemas com o intuito de desenvolver um método de especificação de requisitos adequado ao projeto estruturado [3]. Em 1979, Gane e Sarson, descrevem em seu trabalho a metodologia de desenvolvimento de sistemas denominada STRADIS (Structured Analysis, Design and Implementation of Information Systems) que incorpora a análise, projeto e implementação estruturada de sistemas de informação. Gane e Sarson salientam em seu trabalho que para completar o desenvolvimento do sistema é necessário definir um planejamento que contenha os planos de testes e aceitabilidade do sistema [3]. De modo geral, na Análise Estruturada são enfatizadas as funções do sistema e os processos. Ela não modela o comportamento temporal, bem como os relacionamentos complexos de dados. Nesta análise são utilizadas as seguintes ferramentas [2]: • Diagrama de Fluxo de Dados; • Dicionário de Dados • Especificação da Lógica de Processos.

1.5 Análise Essencial A Análise Essencial é considerada uma evolução da Análise Estrutura em função de preocupar-se com o controle e utilizar ferramentas para representação dos requisitos do sistema. Na etapa de análise procura-se detalhar o propósito do sistema (definição do problema) e identificar os requisitos do software. Onde os requisitos correspondem ao conjunto de características que o sistema deve possuir para alcançar o propósito do sistema [5]. No decorrer do processo de análise, o analista precisa encarar a complexidade das situações reais, entendê-las e representá-las de uma forma simplificada que permita a compreensão do sistema que será desenvolvido. Para tal, é necessário limitar o escopo, subdividindo o todo complexo em partes simples e gerenciáveis, obtendo as características essenciais da realidade e modelar o relacionamento destas características criando um modelo [5].

Introdução a Análise de Sistemas O modelo é uma representação da abstração da realidade, ou seja, ele representa o conjunto de características de uma situação real. Os modelos possuem níveis de abstração que representam o grau de detalhes das características do sistema. De um modo geral, os sistemas de informação são considerados em três níveis [5]: • Conceitual: as características do sistema são consideradas independentes do ambiente computacional (hardware e software) onde o sistema será implementado. • Lógico: as características são consideradas como dependentes de um dado tipo de sistema computacional e independentes dos produtos. • Físico: as características são consideradas como dependentes de um dado sistema computacional, ou seja, dependem da linguagem de programação, do compilador, do sistema gerenciador de banco de dados etc. Nas etapas iniciais do processo de desenvolvimento, o analista de sistemas representa o sistema através de modelos conceituais. Em seguida, as características lógicas e físicas são representadas por outros modelos. O método de Análise Essencial de Sistemas indica que um sistema deve ser modelado por meio de três dimensões [5]: • Dados: refere-se aos aspectos estáticos e estruturais do sistema; • Controle: considera os aspectos temporais e comportamentais do sistema; e • Funções: considera a transformação de valores. A Análise Essencial considera dois níveis relacionados ao grau de abstração, são eles [5]: • Modelo Essencial: representa o sistema em um grau de abstração totalmente independente das restrições de tecnologias; e • Modelo de Implementação: leva em consideração as restrições tecnológicas relacionadas ao hardware e software que serão utilizados na implementação (desenvolvimento) do sistema.

Análise de Sistemas De um modo geral a Análise Essencial foi considerada uma evolução da Análise Estruturada de Sistemas. No entanto, a Análise Essencial procurou determinar um novo ponto de partida para a especificação de um sistema: a identificação dos eventos que o afetam. Passando a abranger também o levantamento de requisitos, uma vez que a análise estruturada focava somente na análise de requisitos [5]. A análise essencial depurava os sistemas em subsistemas para tornálos mais leves e operacionais, percebendo-se então a proximidade entre funções e dados, pois cada subsistema era provido de dados através de banco de dados particionado e conhecido como memória essencial. Pode-se dizer que esta metodologia foi o limite para o estudo mais sólido dos métodos orientados a objetos [6].

1.6 Análise Orientada a objeto A Análise Orientada ao Objeto tem como característica a intercalação de métodos e atributos em um único plano, na especificação de “encapsulamento”, o banco de dados orientado ao objeto é visto como um modelo de dados munido de inteligência. Para entendermos melhor o conceito da análise orientada a objetos utilizaremos o exemplo do corpo humano. A menor unidade do nosso corpo é a célula, ela possui métodos e funções integradas [6]. No entanto, não temos apenas uma, mas um conjunto de células que formam os tecidos e respectivamente um órgão, e os órgãos formam sistemas (Digestivo, Nervoso, etc ...). Em uma visão geral, o conjunto de todos esses sistemas forma o nosso corpo. Sendo assim, analogamente definimos: a) célula como Objeto, b) Órgão como Classe, c) Sistema como pacote e d) nosso corpo como um componente [6]. Por meio destas relações temos a capacidade de nos comunicarmos com as pessoas, e do ponto de vista da orientação ao objeto, podemos concluir que os componentes devem ser compatíveis entre si e para interpretar a comunicação existem ferramentas que suportam as linguagens unificadas de modelagem, como a UML (Unified Modeling Language) [6]. As características fundamentais de uma metodologia orientada a objetos são: abstração de dados, atributos e relacionamentos.

Introdução a Análise de Sistemas

1.6.1 Abstração de Dados: Ao invés de decompor em funções e procedimentos, características predominantes das técnicas estruturadas, a metodologia orientada a objetos reforça a abstração. A abstração dos dados inclui o conceito de superclasse e subclasse [3]. A partir da abstração surge o conceito de objeto, que é uma abstração de um conjunto de coisas do mundo real, de tal forma que [3]: a) todas as coisas do mundo real do conjunto devem ter as mesmas características; b) todas as instâncias estão sujeitas (e conforme) as mesmas normas. Todo objeto tem uma descrição que é uma declaração formal que permite afirmar se um dado elemento do mundo real é ou não uma instância do objeto [3]. Os objetos podem se enquadrar em cincos categorias, são elas [3]: • Tangíveis (exemplos: carro, casa, computador, etc.); • Funções (exemplos: analista de sistemas, advogado, cliente, etc.); • Interações (exemplos: venda casamento, ensinamento, etc.); • Incidentes (exemplos: evento, acidente, abrir, etc.); • Especificações (exemplos: modelo 123, codigo23, etc.);

1.6.2 Atributos: Um atributo é a abstração de uma única característica possuída pelo objeto (entidade) [3], por exemplo, um objeto “Livro” possui como atributo o “ISBN”. Um atributo pode ser classificado como: [3] • Completo: possui todas as informações pertinentes ao objeto; • Fatorado: Cada atributo deve captar um aspecto separado da abstração do objeto; • Mutuamente independente: os atributos possuem valores independentes uns do outros. • A classificação dos atributos é dada por elementos [3]: • Descritivos: são as características são intrínsecas do objeto; • Nominativos: os nomes e rótulos arbitrários; e • Referenciais: há fatos que ligam uma instância de um deter-

Análise de Sistemas minado objeto a instância de outro objeto.

1.6.3 Relacionamentos: Eles representam a abstração do conjunto de associações existentes no mundo real. Eles são classificados conforme a sua multiplicidade [3], em três tipos, tais como: 1:1 – Uma dada instância de um objeto do tipo X é associada a uma, e somente uma, instância de um objeto do tipo Y [3]. 1:M – Um objeto do tipo X é associado com um ou mais instâncias de um objeto do tipo Y [3]. M:M – Para cada instância de um objeto do tipo X é associada com uma ou mais instâncias de um objeto do tipo Y. IMPORTANTE LEMBRAR QUE... • A essência da abordagem orientada a objetos está voltada ao conceito de encapsular os dados e as funções de tal maneira que o único meio de obter acesso ou atualizar os dados é através das funções associativas [3]. • De um modo geral a análise de sistemas consiste em métodos e técnicas de investigação e especificação da solução de problemas, a partir dos requisitos levantados para criação e implementação de um software [7]. Ou seja, é uma atividade cujo objetivo é entender o problema e definir a solução mais adequada. • Esse processo de análise não é trivial, uma vez que é preciso entender o problema de tal forma que o sistema desenvolvido atenda a necessidade do cliente. • A falta de análise de sistemas pode comprometer futuras ampliações no sistema, comprometer a tomada de decisões, dificultar a manutenção, tornar o sistema desconhecido de todos os usuários fazendo que apenas uma pessoa conheça o sistema entre outros pontos negativos [7]. Neste sentido percebemos a importância em estudar a análise de sistemas e para entendermos melhor sobre este tema falaremos na próxima seção sobre o problema versus a solução, uma vez que, o foco da análise de sistemas gira em torno deles (autora).

Introdução a Análise de Sistemas

1.7 Problema X Solução O processo de desenvolvimento de software pode ser dividido, em geral, em quatro grandes fases: análise, projeto, implementação (codificação/ programação) e testes [7]. Na fase de análise destaca-se a investigação do problema, onde o analista de sistemas precisa identificá-lo e entendê-lo de maneira eficiente e clara. Para que se possa definir o problema Figura 3. Fonte: http://4. é preciso entender a situação atual. O bp.blogspot.com/_TelWejOUjJ8/ resultado dessa análise é o enunciado SxE5CLX8y4I/AAAAAAAAALo/oambNw9AffM/s320/ do problema e o projeto é consideInterroga%C3%A7%C3%A3o.jpg rado como a solução. Sendo que, os problemas mal elaborados podem, eventualmente, ser resolvidos, no entanto, a solução não atenderá à expectativa do cliente [7]. Qual é a melhor forma de entender o problema é interagindo com o usuário, questionando o mesmo, criando um canal de comunicação direto com ele, presencial ou não [6]. É muito importante que o processo de análise tenha qualidade, Figura 4. Fonte: http://www.rev.vagner- pois a correção dos problemas de queiroz.nom.br/FigSemAE_NT_D.jpg entendimento durante essa fase implica em determinado custo. Na fase de projeto os custos aumentam. Entretanto, é bom destacar que na fase de implementação este cenário piora, porque os custos continuam a crescer, e ao final, na fase de implantação os custos são ainda bem maiores. Para entender o domínio do problema alguns questionamentos devem ser feitos, são eles [8]: • Por que é necessário desenvolver um projeto? • Quais são os objetivos de negócio? • O que o cliente precisa resolver?

Análise de Sistemas

• O que incomoda o cliente? • Modelar o negócio proporciona uma visão geral do domínio do problema. Outro ponto importante! Neste processo é necessário identificar quem são os usuários do sistema e os representantes dos grupos de usuários, negociar as responsabilidades de cada representante, definir como será a comunicação com os fornecedores e os representantes dos usuários [8]. É importante entender quais são as necessidades destes usuários, aquilo que realmente eles precisam para atender o real problema do cliente [8]. A seguir, alguns exemplos de necessidade que os usuários costumam descrever: • “Eu preciso diminuir o tempo de atendimento do cliente no balcão”; • “Eu necessito que as informações pessoais do cadastro de clientes sejam emitidas de forma rápida”. Este tipo de necessidade, descrita em alto nível, representa o que o usuário espera que o sistema faça [8]. Para “traduzir” as necessidades do usuário o analista de sistemas precisa realizar uma boa análise, sem ter pressa de implementar o sistema. De nada adianta um sistema ser eficiente, ter uma interface bonita se não atende as expectativas do cliente. O conjunto de necessidades que devem ser atendidas é denominada de requisitos do sistema [10].Este tema será explorado no próximo capítulo.

Atividades de Aprendizagem 1) Com relação às metodologias de desenvolvimento de software, classifique as alternativas abaixo como: A – Análise Estruturada; B – Análise Essencial; C – Análise Orientada a Objetos ( ) É uma evolução da análise estruturada, ela preocupa-se com o

Introdução a Análise de Sistemas controle e utiliza ferramentas para representar os requisitos, bem como, a elicitação dos requisitos. ( ) Sua análise baseia-se na decomposição funcional e na utilização de diagramas de fluxo de dados. ( ) Sua principal característica é a intercalação de métodos e atributos em um único plano, na especificação de “encapsulamento”, onde o banco de dados orientado é visto como um modelo de dados munido de inteligência. ( ) Foi o limite para os estudos mais sólidos dos métodos orientados a objetos. ( ) Suas principais fases são: estudo inicial; estudo detalhado; definição e projeto de soluções alternativas; e o projeto físico; ( ) As características principais deste metodologia é abstração de dados, atributos e relacionamentos. ( ) Indica que um sistema deve ser modelado em três (3) dimensões: dados; controle; e funções. 2) A partir da descrição abaixo de uma dada situação, analise a lacuna da direita e identifique de afirmação pertence ao domínio do problema ou da solução. Situação: Uma clínica médica contratou a sua empresa para desenvolver um sistema web para que seus pacientes possam verificar a disponibilidade de datas e marcar consultas com seu médico. Você foi selecionado como o analista de sistemas deste projeto. Após o levantamento inicial de requisitos desse sistema, e você obteve as seguintes informações: ( P ) Domínio do Problema ( ) A secretária verifica na sua agenda de papel a disponibilidade de data para uma consulta com um determinado médico. ( S ) Domínio da Solução

( ) A secretária marca em sua agenda de papel a consulta de um paciente com um determinado médico ( ) Um paciente entra em contato com a clínica, via telefone, para marcar uma consulta com um determinado médico.

Análise de Sistemas ( ) Um paciente entra em contato com a clínica, via telefone, para identificar quais são os especialidades médicas que a clínica oferece. (exemplos: Pediatra, Cardiologista, Clínica Geral etc.) ( ) Um paciente deve verificar em um página web a disponibilidade de data para uma consulta com um determinado médico. ( ) A secretária pode marcar a consulta para um paciente acessando o sistema web da clínica. ( ) Um paciente pode marcar sua consulta com um determinado médico acessando o sistema web da clínica. ( ) Um paciente pode acessar o sistema web da clínica para identificar quais são os especialidades médicas que a clínica oferece. (exemplos: Pediatra, Cardiologista, Clínica Geral etc.)

CAPĂ?TULO

2 Levantamento de Requisitos

Objetivo Neste momento iniciaremos nossos estudos sobre requisitos do sistema. Veremos formas de levantamento dos requisitos junto aos clientes e estaremos estudando tambĂŠm os processos de engenharia e gerĂŞncia de requisitos.

Levantamento de Requisitos O levantamento de requisitos, também denominado de elicitação de requisitos, refere-se à etapa de compreensão do problema voltada ao desenvolvimento do software, isto é, serão identificadas as necessidades do usuário para resolver um problema ou atingir um objeto [11]. Qual é o foco desta etapa? É alinhar a visão do problema entre o usuário e os desenvolvedores. É neste momento que o analista de sistemas e o cliente, juntos, tentam levantar e definir as necessidades. Essas necessidades são chamadas de requisitos [11]. O resultado do levantamento de requisitos é o documento de requisitos. Ele contém todos os tipos de requisitos identificados, normalmente, escritos em linguagem natural. Os requisitos podem ser classificados como: • Requisito Funcional: • Requisito Não-Funcional.

2.1 Requisitos Funcionais O requisito funcional descreve as funcionalidades do sistema, isto é, ele representa o que o sistema deve fazer. Exemplos: Requisito Funcional 01 (REF.01): O sistema deve listar todos os alunos cadastrados em uma turma. Requisito Funcional 02 (REF.02): O sistema deve calcular a média dos alunos de uma turma. Requisito Funcional 03 (REF.03): O sistema deve permitir o CRUD (Create, Read, Delete, Up date) de alunos. Requisito Funcional 04 (REF.04): O sistema deve gerar um relatório com a média dos alunos de uma turma. No entanto, após a redação dos requisitos é necessário verificar se realmente foi entendida a necessidade do cliente, ou seja, a partir dos requisitos elicitados é possível modelar a solução para o problema. A Tabela 1 apresenta alguns resultados onde, provavelmente, houve falhas na identificação dos requisitos.

Análise de Sistemas

Tabela 1. Resultado da falha na análise de requisitos Fonte: [19]

2.2 Requisitos não-funcionais Requisitos Não Funcionais (RNF) são requisitos que expressam restrições que o software deve atender ou qualidades específicas que o sistema deve possuir. Eles não associados diretamente com as funções presentes no sistema. Os requisitos não funcionais podem ser classificados sob os seguintes aspectos: • Usabilidade; • Desempenho; • Robustez; • Critérios de Segurança; • Portabilidade; • Restrições de Hardware e Software; • Questões sobre padronização e normatização; • Questões sobre a distribuição e instalação. Alguns exemplos de RNF:

Requisito Não Funcional 01 (RNF.01): O sistema deve emitir o relatório da média dos alunos em 5 segundos (desempenho). Requisito Não Funcional 02 (RNF.02): O sistema deve ser executado no sistema operacional Windows Vista e Linus nas distribuições Ubuntu e Famelix (restrições de software). Requisito Não Funcional 03 (RNF.03): A especificação do servidor de banco de dados é SGBD MySql, com processador Core 2 Duo da Intel, 4GB de memória RAM ... (restrições de harware).

Levantamento de Requisitos Requisito Não Funcional 04 (RNF.04): A interface do módulo de relatórios deve ser orientada ao uso de atalhos do teclado (usabilidade). Requisito Não Funcional 05 (RNF.05): O sistema deve estar em conformidade com a norma XXXX (normatização). ATENÇÃO: Há alguns requisitos que podem ser considerados como híbridos, ou seja, eles apresentam características de requisitos funcionais e não funcionais. Um exemplo deste tipo de requisito seria: “O sistema deve emitir uma nota fiscal para um cliente, em um tempo máximo de 5 segundos” [9]. NOTE QUE: No exemplo acima, você deve observar que além do requisito funcional (emitir uma nota fiscal), há também um requisito não funcional, de desempenho, associado. O que é mais importante na elicitação de requisitos: encontrá-los ou classificá-los corretamente? Com certeza o mais importante é encontrá-los [9].

2.3 Rastreabilidade Para garantir que todas as características foram endereçadas por requisitos de software e todas as necessidades foram endereçadas por características tem-se a rastreabilidade que é a base para avaliação de impacto [12]. A Tabela 2 apresenta uma rastreabilidade bidirecional entre as necessidades de características. Característica 1

Característica 2

...

Necessidade 1 Necessidade 2

...

Necessidade N

...

Tabela 2. Rastreabilidade Bidirecional - Fonte: Adaptado de [12]

Requisito 1 Requisito 1 Requisito 2

...

Requisito N

Característica M

Requisito 2

...

Requisito M

... ...

...

Tabela 3. Rastreabilidade entre Requisitos - Fonte: Adaptado de [12]

Análise de Sistemas A seguir são apresentadas 10 práticas para requisitos eficazes (Young, 1999):

Figura 5. Fonte: http://www.inf.ufes.br/~labes/resources/images/imgPalm.jpg

1. 2. 3. 4. 5.

Compromisso com abordagem. Estabelecer e utilizar uma equipe responsável para os requisitos. Definir as necessidades reais do cliente. Utilizar e melhorar continuamente o processo de requisitos. Manter iterações sobre os requisitos do sistema e os requisitos da arquitetura. 6. Usar um mecanismo para manter a comunicação no projeto. 7. Selecionar métodos familiares e manter um conjunto de produtos de trabalho. 8. Executar verificação e validação de requisitos. 9. Fornecer um mecanismo efetivo para acomodar as mudanças nos requisitos. 10. Executar o desenvolvimento com práticas bem conhecidas e provadas pela indústria, na organização e no projeto.

2.4 Processo de Engenharia de Requisitos Todo processo deve definir quem irá fazer o que, como e quando será atingido o objetivo. O processo de engenharia de requisitos possui as seguintes fases: elicitação, análise e modelagem, Verificação e Validação e gerência [12]. • Na elicitação (levantamento) de requisitos os requisitos são identificados e entendidos, aplicando técnicas como: entrevistas, observação, análise de documentos, questionários, etc.... • Na análise e modelagem é representado o entendimento do problema, aplicando técnicas como: casos de uso (USC), diagrama de

Levantamento de Requisitos fluxo de dados (DFD), Tabelas de decisão, modelo entidade relacionamento (MER), etc... • A verificação e validação dos requisitos é realizada utilizando as técnicas de checklist, inspeções, revisões, etc... • Na gerência são estabelecidos e mantidos um entendimento comum entre o cliente e a equipe de projeto relacionadas às mudanças dos requisitos no sistema. Na fase de elicitação de requisitos é preciso identificar quais são as fontes de informação para coletar os dados. As fontes de informação são os clientes, usuários, desenvolvedores, especialistas de domínio, documentos, os sistemas legados e a literatura [12]. Para encontrar estas fontes é preciso responder alguns questionamentos, tais como: • • • • • •

Quem utiliza ou utilizará o sistema? Existe alguma solução em uso? Existem produtos similares? Qual a documentação utilizada hoje? Há normas ou legislações a serem seguidas? Quais são os livros, teses, artigos relacionados com a aplicação que está sendo analisada?

2.5 Técnicas para Levantamento de requisitos Para levantar os requisitos funcionais e não funcionais há diversas técnicas, dentre elas as mais aplicadas são as entrevistas, a observação e a prototipação de telas. A entrevista - é uma das técnicas mais empregadas para identificar e entender os requisitos definidos pelo usuário. Pode ser utilizada em qualquer situação, pois é uma técnica muito simples e direta. Para se ter sucesso com esta técnica é preciso que o conhecimento do entrevistador não Figura 6. Fonte: http://suachance. interfira na troca de informações que files.wordpress.com/2009/06/entre- se movimentam durante a etapa de vsita.jpg levantamento de requisitos.

Análise de Sistemas A observação - é um método científico, aplicado no desenvolvimento de uma investigação. É caracterizada por perceber, visualizar e não interpretar, apenas observar. Seu resultado é uma descrição do que foi visualizado, sem que haja qualquer juízo de valor. O moderador desta observação deverá acompanhar a realização das tarefas. O contato com um utilizador inexFigura 7. Fonte: http://3.bp.blogspot. com/_Hrnl06uDEmE/SUA5RxV9qDI/ periente quando este interage com o sisteAAAAAAAAAEE/t1JhthJc0mc/s320/ ma, permite uma percepção facilitada do observar.jpg ponto de vista das dificuldades encontradas na navegação ou no uso de uma interface. Prototipação de telas - Ela permite identificar as expectativas do cliente principalmente nos aspectos de usabilidade. De um modo geral ela envolve programação. Neste momento é apresentando ao cliente um esboço da interface do sistema que será desenvolvido [9]. Figura 8. Fonte: [9]

Dentre os requisitos levantados, esperam-se como atributos destes requisitos que eles sejam [12]: • • • • • • •

Claros; Bem escritos; Sem ambigüidades; Implementáveis; Com baixa abstração; Verificável; e Rastreáveis.

2.6 Análise e Modelagem de Requisitos Esta etapa consiste na documentação formal, por meio de uma determinada ferramenta, dos dados coletados na etapa de elicitação de requisitos. Seu objetivo é abstrair o requisito de tal forma que seja possível identificar todos os detalhes e suas dependências com outros

Levantamento de Requisitos requisitos. As técnicas de Modelagem são: • • • • • •

Casos de uso; Diagrama de Fluxo de Dados (DFD) Tabelas de decisão: Diagramas de Estado; Dicionário de dados; Modelo Entidade-Relação (ER).

O caso de uso é um meio para especificar as exigências requeridas por um sistema, ou seja, ele representa um padrão de comportamento do sistema. O diagrama de fluxo de dados (DFD) é uma notação gráfica utilizada para representar os fluxos de informação e as transformações ocorridas pela passagem dos dados das entradas para as saídas. A Tabela de decisão é uma forma organizada em Tabela para expressar qual o conjunto de condições que é necessário acontecer para que um dado conjunto de ações seja realizado. O diagrama de estados é uma técnica que descreve o comportamento do sistema, ela permite descrever todos estados possíveis que um objeto pode estar e como o seu estado é comprometido por eventos que o atingem. O DFD especifica a informação por meio de rótulos, no entanto, não descreve o seu significado. Já o dicionário de dados descreve o conteúdo dos itens de informação.

2.7 Gerência de Requisitos

Figura 9. Fonte: http://www.pirelliclubtruck.com.br/ revistaclubtruck/revista/truck13/imagens/gestao_01. jpg

Na etapa de desenvolvimento é normal que novos requisitos sejam definidos e/ou que requisitos já definidos sejam alterados. Estas mudanças são consideradas na etapa de desenvolvimento e devem ser acompanhadas

Análise de Sistemas para garantir que todos os artefatos afetados por uma alteração de requisitos sejam alterados.

2.8 Quais são as pricipais atividades da Gerência de Requisitos? São elas: controle das solicitações de mudanças, gerenciamento do escopo, gerenciamento das inconsistências entre requisitos e o projeto, e manutenção da rastreabilidade entre os requisitos. A solicitação da mudança inicia por meio de uma solicitação formal. Em seguida avalia-se o seu impacto, para tal é preciso ter uma rastreabilidade consistente. Logo após, determina-se a viabilidade, aprovação, revisa-se o planejamento e executam-se as ações corretivas para as inconsistências (caso existam). Para manter o escopo do projeto os requisitos devem ser mantidos dentro do escopo que foi definido para o projeto, ou seja, não devem ser realizadas atividade que vão além do solicitado, uma vez que, este tipo de ação pode impactar no prazo e custo do projeto.

2.9 Regras de Negócio (RNE) Além dos requisitos funcionais e não funcionais, existem as regras de negócio que descrevem como uma dada funcionalidade deve ser realizada. Vejamos alguns exemplos de regras de negócio:

Regra de Negócio 01 (RNE. 01): A senha deve ter no mínimo 6 e no máximo 10 caracteres, alfanuméricos e não deve aparecer durante a digitação. Regra de Negócio 02 (RNE. 02): A média final deve ser calculada através da somatório das notas dos quatro bimestres e dividida por quatro. Regra de Negócio 03 (RNE. 03): A forma do registro no log de operações deve ser dd-mm-aaaa (exemplo: 01-01-2010), hora hh:mm (exemplo: 12:12). No próximo capítulo vamos focalizar os casos de uso.

CAPĂ?TULO

3 Diagrama de casos de uso

Objetivo Neste capítulo estudaremos formas de especificar sistemas orientados a objetos com foco na visão do usuário. Veremos a definição e documentação dos casos de uso e seus tipos de relacionamentos.

Diagrama de casos de uso Um diagrama de casos de uso visa permitir a compreensão do comportamento de um sistema por qualquer pessoa, buscando apresentar o sistema visto pela perspectiva do usuário. Dentre todos os diagramas da UML (Unified Modeling Language) é o mais abstrato e informal, sendo muito utilizado no início da modelagem do sistema, principalmente nas etapas de elicitação e análise de requisitos. No entanto, nada impede que ele possa ser consultado e modificado em outras fases [13]. Este tipo de diagrama é muito útil para o entendimento dos requisitos do sistema, facilitando a especificação, visualização e documentação das características, funções e serviços do sistema almejado pelo usuário [13]. A Tabela 4 apresenta os elementos básicos, que compõem um caso de uso, e sua representação gráfica. Elemento

Descrição

Caso de uso

Representa um diálogo entre um ator e sistema

uc use case model

Representa um papel que pode ser assumido por um usuário

uc use case model

Ator

Sintaxe

Nome do caso de uso

Nome do ator Sistema

Representa o limite entre o sistema e os atores do sistema

Associação

Representa a participação de um ator em um caso de uso

Tabela 4. Sobre um Caso de Uso Fonte: Adaptado de [12]

Análise de Sistemas A seguir, você estudará em detalhes cada elemento do caso de uso.

3.1 Sistema Entende-se como sistema todo e qualquer tipo sistema. Ele identifica a funcionalidade básica do escopo inicial, bem como, os termos e definições no início do trabalho, tais como: glossário e catálogo. Sua notação é uma caixa, como o nome do sistema exposto em cima ou dentro da caixa.

3.2 Ator O ator é alguém ou alguma coisa que interage, de alguma forma, com o sistema. Ele representa um papel, não um usuário individual do sistema, onde uma pessoa pode assumir diferentes atores dentro de um sistema [12]. A figura 10 representa alguns exemplos de atores.

Figura 10. Fonte Própria

Atenção!! O ator é uma classe e não uma instância. Ele deve ter um nome que represente o seu papel dentro do sistema e sua interação com o sistema é dada através da troca de mensagens. Algumas dicas para identificar os atores [12]: • Quem utilizará a funcionalidade principal do sistema? • Quem necessita administrar e manter o sistema funcionando?

Diagrama de casos de uso • Quais dispositivos de hardware o sistema precisará manipular? • Com quais outros sistemas, o sistema precisará interagir? • Quem tem interesse nos resultados que o sistema produzirá? Assim como uma classe o ator pode ser generalizado/ especializado, ou seja, há herança entre atores. Exemplo: Um ator “pessoa física” pode herdar as características de um ator “Pessoa”.

3.3 Casos de uso Os casos de usos referem-se às funcionalidades que podem ser utilizadas pelos atores, eles descrevem e validam o que o sistema irá fazer. A Figura 11 apresenta um exemplo da notação de um caso de uso.

Figura 11. Exemplo de Caso de Uso Fonte: Própria

Os casos de uso podem ser classificados como primários ou secundários. Um caso de uso primário refere-se a um determinado processo focalizado nos requisitos funcionais do software, como por exemplo: cadastrar uma turma ou gerar um relatório das médias dos alunos. Enquanto que um caso de uso secundário se refere a um processo periférico, como a manutenção de um cadastro [13]. Para identificar os casos de usos de um sistema é preciso verificar quais são as necessidades dos atores, como por exemplo: • Funcionário: cadastra DVD’s; • Cliente: loca DVD’s; e • Sistema Financeiro: valida situação do cliente. Outros questionamentos que podem ser realizados para encontrar os casos de uso de um sistema:

Análise de Sistemas • Quais são as funções que os atores esperam do sistema? • O que cada ator precisa fazer? • O ator precisa realizar as operações de cadastro, exclusão, alteração e busca sobre alguma coisa no sistema? • Quais são as entradas e saídas do sistema? Qual a origem e destino dos dados? Assim como nos requisitos, nos casos de uso também deverá haver rastreabilidade bidirecional, conforme a Tabela 5. Requisito 1

Requisito 2

...

Caso de Uso 1 Caso de Uso 2

...

Caso de Uso N

Requisito M

... ...

...

Tabela 5. Matriz de Rastreabilidade Bidirecional Fonte: Adatpado [12]

Para cada requisito funcional deve haver, pelo menos, um caso de uso. Assim como, para cada caso de uso, pelo menos, um requisito funcional. Em ambos os casos pode ser 1 para 1..n. Os casos de uso devem ser documentados, eles fornecem instruções em linhas gerais sobre o funcionamento do sistema, das atividades que deverão ser executadas, dos atores envolvidos, das possíveis restrições entre outras [13]. A documentação produzida, além de ser utilizada no momento da implementação do sistema, é utilizada como base para a construção de outros diagramas, como o de sequência, por exemplo, e ela fornece um relatório ao cliente sobre o comportamento esperado de um dado caso de uso [13].

3.4 Documentação de casos de uso A documentação de um caso de uso descreve, por meio de uma linguagem simples, a função do caso de uso, quais atores interagem com ele, quais fases serão executadas pelo ator e pelo sistema para que o caso de uso execute sua função [13]. Um caso de uso deve, sempre, ser iniciado por um ator [12]. Não há um formato específico, definido pela UML, para documentar casos de uso de tal forma que represente as características do próprio

Diagrama de casos de uso diagrama. Isto permite uma flexibilidade no formato da documentação que permite até pseudocódigo, no entanto, o objetivo da documentação do caso de uso é permitir que até mesmo os usuários mais leigos entendam o que o caso de uso faz [13]. A seguir é apresentada uma sugestão de documentação para um caso de uso na Tabela 6. Nome do Caso de Uso

Abrir Conta

Caso de Uso Geral Ator Principal

Cliente

Atores Secundários

Funcionário

Resumo

Este caso de uso descreve as fases para abrir uma conta corrente

Pré-Condições

1. A solicitação da abertura da conta deve ter sido aprovada anteriormente

Pós-Condições

É necessário fazer um depósito inicial

Fluxo Principal Ações do Ator

Ações do Sistema

1. Solicitar a abertura da conta 2. Consultar o cliente pelo CPF (Pessoa Física) ou CNPJ (Pessoa Jurídica) 3. Informar a senha da conta 4. Abrir a conta 5. Informar o valor a ser depositado 6. Registrar o depósito 7. Emitir o cartão da conta

Restrições/Validações

1. Para abrir uma conta a idade do cliente deve ser maior ou igual a 18 anos 2. O valor mínimo de depósito é R$ 50,00 3. O cliente precisa fornecer um comprovante de residência no seu nome (conta de água, luz ou telefone fixo)

Análise de Sistemas Fluxo Alternativo – Manutenção do Castrado do Cliente Ações do Ator

Ações do Sistema 1. Se for necessário, Executar o Caso de Uso Manter Cliente, para gravar ou atualizar o cadastro do cliente

Fluxo Exceção – Cliente Menor de Idade Ações do Ator

Ações do Sistema 1. Emitir uma mensagem para cliente informando que ele não possui a idade mínima para abertura da conta 2. Recusar a solicitação da abertura da conta

Tabela 6. Documentação do Caso de Uso - Abertura de Conta Fonte: Adaptado de [13]

Comentário: • De acordo com o modelo apresentado, primeiramente é preciso apresentar uma descrição sobre o caso de uso. • O campo “Caso de Uso de Geral” é utilizado quando há casos de usos especializados, como por exemplo uma conta especial, caso estivéssemos documentando o caso de uso de uma conta especial ele estaria derivando do caso de uso “Abrir Conta”. Como no exemplo da Tabela 6 trata-se do caso de uso geral, o campo “Caso de Uso Geral” ficou em branco [13]. • Já o campo “ator principal” identifica o ator que mais interage com o caso de uso, onde os atores secundários são aqueles que menos interagem com o caso de uso. • No exemplo foram identificados dois atores: o Cliente e o Funcionário. O cliente é considerado como ator principal porque é ele quem solicita o serviço. No entanto, quem interage realmente com o serviço a funcionalidade de abertura da conta é o ator Funcionário, e na documentação deste caso de uso, as ações tomadas pelo Funcionário são representadas pelas ações do sistema. • Em seguida tem-se o campo “Resumo” que apresenta o objetivo do caso de uso. Logo após, vem as pré e pós-condições que representam determinadas condições que precisam ser satisfeitas para que o caso de uso seja executado (pré-condições) e concluído (pós-condições). • O fluxo principal representa a sequência das ações que devem ser realizadas. Onde o fluxo alternativo representa uma situação que

Diagrama de casos de uso não está compreendida no fluxo principal, ou seja, é uma situação que foge da situação ideal do caso de uso. • Já o fluxo de exceção trata as situações que precisam ser tratadas para dar continuidade ao fluxo da execução da tarefa quando uma determinada regra de negócio não foi atendida, como neste exemplo, é esperado que a idade mínima do cliente seja igual ou superior a 18 anos. • Por fim, têm-se as restrições e validações do sistema a fim de torná-lo mais robusto, elas representam as regras de negócio da empresa.

3.5 Associações Uma associação representa a participação de um ator em um caso de uso, ela é o único relacionamento entre atores e casos de uso [12]. Também podem ocorrer associações entre casos de usos, neste caso, este tipo de relacionamento recebe os seguintes nomes: inclusão, exclusão ou generalização [13]. A associação entre um ator e o caso de uso representa que este ator se relaciona com a função que está sendo representada pelo caso de uso, conforme apresentado na Figura 12.

Figura 12. Associação entre Ator e Caso de Uso Fonte: Adatpado [13]

3.6 Relacionamentos Generalização /Especialização Quando um caso de uso é uma especialização de outro caso de uso [12], ou seja, é uma forma de associação entre os casos de uso que possuem características semelhantes e algumas particularidades exclusivas [13].

Análise de Sistemas O exemplo da Figura 13 representa o relacionamento entre a função de abertura de conta que difere em umas características quando se classifica como conta especial e poupança. No entanto, elas possuem algumas características que são comuns a elas, enquanto contas bancárias, independentes de seu tipo.

Figura 13. Exemplo de Generalização Fonte: Adaptado de [13]

Quando um caso de uso é uma especialização de outro caso de uso [12], ou seja, é uma forma de associação entre os casos de uso que possuem características semelhantes e algumas particularidades exclusivas [13]. Este tipo de relacionamento também pode ocorrer entre atores, conforme apresentado na Figura 14.

Figura 14. Exemplo de Generalização entre Atores - Fonte: Adaptado de [13]

Diagrama de casos de uso Include (Inclusão) A associação de inclusão é utilizada quando há uma situação comum entre dois ou mais casos de uso. Este tipo de relacionamento indica obrigatoriedade, isto é, quando um dado caso de uso possui uma inclusão com outro, a execução do primeiro implica também na execução do segundo [13].

Figura 15. Exemplo de Inclusão Fonte: Adaptado de [13]

No exemplo apresentado na Figura 15 nota-se que, toda vez que for realizado um saque ou um depósito, obrigatoriamente, devese registrar essas operações.

Extend (Extensão) Este tipo de relacionamento permite adicionar novos comportamentos ao caso de uso sem prejudicar o seu entendimento [12]. Esta associação de extensão é utilizada para descrever situações opcionais de um dado caso de uso, ou seja, ela representa cenários que somente ocorrerão em situações específicas. Para facilitar o entendimento, será apresentado um exemplo de login onde é necessário o usuário de registrar quando não possui cadastro, conforme a Figura 16.

Figura 16. Formulário de Login - Fonte: Desenvolvido a partir do exemplo de [13]

Análise de Sistemas A Figura 17 representa um exemplo onde há uma associação por extensão.

Figura 17. Exemplo de Extensão Fonte: Adaptado de [13]

Este exemplo representa uma situação do formulário de login apresentado na Figura 17 onde um usuário precisa logar-se para acessá-lo. No caso do usuário não possuir login/senha ele pode clicar na opção “Auto-registrar”, para se cadastrar no sistema, sendo que essa situação ocorrerá apenas uma vez, depois, o usuário terá acesso ao sistema e não passará novamente por esta situação [13]. No próximo capítulo apresentaremos os diagramas de sequência e classe.

CAPÍTULO

4 Diagrama de Sequência

Objetivo Neste capítulo estudaremos outras formas de especificar sistemas orientados a objetos, entretanto neste momento o foco é a visão do desenvolvedor. Sendo assim, veremos a definição e a documentação dos diagramas de sequencia e de classe.

Diagrama de sequência O diagrama de sequência é um diagrama de comportamento que preocupa-se com a ordem temporal em que as mensagens são trocadas entre os objetos envolvidos em dado processo [13], isto é, ele apresenta a interação dos objetos organizados no tempo. A utilização deste tipo de diagrama pode ser empregada para detalhar a colaboração na realização de um caso de uso [18]. Um diagrama de sequência identifica o evento gerador do processo modelado e o ator envolvido, bem como ele determina como o processo deve ser implementado. A Figura 18 apresenta um diagrama de sequência para a função Buscar Imóvel.

Figura 18. Diagrama de Sequência da Função Buscar Imóvel Fonte: Própria

Análise de Sistemas

4.1 Alguns elementos de um diagrama de sequência • Atores: são os mesmos descritos nos diagramas de casos de uso • Linha de Vida: representa o tempo de vida em que o objeto existe durante um processo. • Mensagem Síncrona: demonstra a ocorrência de eventos, envolvendo métodos. • Retorno: é um tipo de mensagem que indica a resposta para o objeto ou ator que a chamou.

Figura 19. Elementos do Diagrama de Sequência Fonte: [18]

Diagrama de sequência

4.2 Diagrama de Classe O diagrama de classe é um dos mais utilizados da UML. Ele serve de apoio para a maioria dos demais diagramas. Ele define a estrutura das classes que serão utilizadas no sistema, determinando os seus métodos e atributos de cada classe, bem como, o relacionamento entre as classes [13]. A Figura 20 apresenta um exemplo de diagrama de classes.

Figura 20. Diagrama de Classes Fonte: Própria

Análise de Sistemas

Atividades de Aprendizagem 1) Com relação aos diagramas de sequência leia as afirmativas e assinale V para as alternativas Verdadeiras e F para as alternativas Falsas. ( ) O diagrama de sequência é um diagrama comportamental que se preocupa em demonstrar a ordem espacial em que as mensagens são trocadas entre os objetos envolvidos em um determinado processo. ( ) A construção do diagrama de sequência geralmente considera um único caso de uso. ( ) Um diagrama de sequência costuma identificar o ator responsável pelo evento gerador do processo que está sendo modelado. ( ) Em um diagrama de sequência as mensagens enviadas por cada objeto são representadas por setas entre os objetos que se relacionam. ( ) Diagramas de sequência possuem dois eixos: o eixo vertical, que mostra o tempo e o eixo horizontal, que mostra os objetos envolvidos na sequência de uma certa atividade. ( ) Os diagramas de sequência mostram apenas os objetos que são criados como parte do cenário documentado pelo diagrama.

CAPĂ?TULO

5 Diagrama de Fluxo de dados - DFD

Objetivo Neste capítulo estudaremos formas de especificar sistemas estruturados. Estudaremos também a definição e a documentação dos diagramas de fluxo de dados (DFD).

Diagrama de Fluxo de dados - DFD Um Diagrama de Fluxo de Dados (DFD) é uma das mais utilizadas ferramentas que, em forma de notação gráfica, nos auxilia na modelagem de sistemas operativos mais complexos do que apenas a manipulação dos dados. Ele apresenta uma visão estruturada dos dados, ou seja, um fluxo de dados que nos permite representar várias visões do sistema, analisado assim em diferentes níveis de detalhamento [12] Estes níveis de detalhamento variam de acordo com a clareza dos processos do projeto, onde o Diagrama de Contexto representa uma visão macro do sistema, e em seguida temos os diagramas de níveis. O nível mais alto é conhecido como DFD de nível 0, que está logo abaixo do diagrama de contexto, onde neste nível serão mostradas as funções mais importantes do sistema. Caso não esteja claro o processo, o mesmo é aperfeiçoado a cada nível [12]. Este ponto de vista do projeto, visando o fluxo de dados nos permite uma visão mais ampla do sistema, pois no ponto vista das pessoas, máquinas e da empresa, só é possível visualizar apenas partes do que acontece com o sistema. Isto significa uma grande mudança em relação às formas clássicas de analise de sistemas, que costumavam primeiramente abordar a visão do usuário em relação ao sistema [12]. De forma resumida um DFD representa (como acontece com a transformação dos dados que se movimentam pelo sistema) e apresenta as funções e sub-funções que modificam o fluxo de dados.

Análise de Sistemas Elementos que compõe um Diagrama de Fluxo de Dados: Notação Gane e Sarson Processo

Um processo mostra uma parte do sistema que altera as entradas e saídas, e tem no mínimo eu fluxo de dados de entrada e outro de saída.

Repositório de Dados

É utilizado para representar os dados armazenados de alguma forma.

Entidade Externa

Ilustra um agente esterno ao sistema que está sendo modelado, e interage com ele.

Fluxo de Dados

Mostra um dado ou uma coleção deles, e sempre inicia ou termina em um processo.

Notação DeMarco e Yourdan

Nome

Tabela 7. Elementos de um DFD Fonte:Adaptado de [12]

5.1 Como elaborar um DFD 1) Eleger nome expressivos: • Evitar nomes de pessoas ou grupos; • Nomear o processo a fim de identificar as suas funções; • Os nomes devem ser familiares ao usuário.

2) Numerar os processos: • A numeração não depende da ordenação entre os processos, ele apenas ajuda a identificá-los.

Diagrama de Fluxo de dados - DFD Exemplo:

Figura 21. Numeração de Processos Fonte: [12]

3) Redesenhar o DFD quantas vezes forem precisas para ter uma aparência legível: • No mínimo 3 e no máximo 7 bolhas. Exceto no caso do diagrama de contexto:

Figura 22 - Diagrama de contexto Fonte: [12]

4) Assegure-se de que o DFD possua uma relação lógica: • Cuide para que não desenhe um processo com entradas e sem saídas; • Tenha cuidado também para que o processo não tenha geração espontânea de dados, processo com saída, mas sem entrada. Com exceção da geração de números aleatórios.

Análise de Sistemas 5) Verifique se todos os processos e fluxos tenham rótulos: • Falta de Atenção, erros, ou não soube nomear? • Fluxo: itens importantes de dados não foram relacionados ou foram reunidos; • Processo: desordem do analista. “Desenhou em fluxograma disfarçado”.

6) Cuidado com o armazenamento de apenas leitura ou de apenas escrita: • Equivalente a diretriz de processos com apenas entradas ou apenas saídas; • Um bom armazenamento deve ter entradas e saídas.

5.2 Níveis do DFD Em uma modelagem de diagramas mais complexos, é aconselhável que eles sejam criados em níveis, e que cada um apresente de forma sucessiva, os detalhes de uma parte do nível anterior. O DFD do mais alto nível consiste numa visão do sistema inteiro; os fluxos de dados representam as interfaces entre o sistema e as entidades externas. Ele é conhecido como Diagrama de Contexto e é opcional.

Sistema

E2 Diagrama de Contexto

Figura 23 Fonte: [12]

Diagrama de Fluxo de dados - DFD O diagrama que vem logo em seguida do Diagrama de contexto é conhecido como FIGURA 0, ou de nível 0. Esta é a versão de mais alto nível que representa as principais funções do sistema e também as principais interfaces entre as funções.

5.3 Vantagem do uso de DFD´s em níveis • Com DFD’s em níveis é possível adotar a abordagem TOPDOWN. Com isso é possível que o gerente faça a leitura dos níveis mais altos, para um melhor entendimento, ou ainda ter uma visão geral do sistema. Programadores e usuários podem ler do mais resumido ao mais detalhado, limitandose as áreas do seu interesse. • Não existem ligações entre a continuação em outra página. Fluxos de Dados que antecedem somem da próxima página, ele fica no contexto do pai, ou seja, cada página é referente a uma área de trabalho destinada a ele, você nunca terá que procurar em outra página e continuar sua leitura para ter uma descrição total. • Todos os diagramas devem ocupar apenas uma página. Exemplo de um Diagrama de Fluxo de Dados (DFD):

Figura 24. Exemplo de DFD Fonte: [12]

Análise de Sistemas

Atividades de aprendizagem 1) Correlacione os termos apresentados com as definições descritas abaixo: ( A ) Processo ( B ) Repositório de Dados ( C ) Entidade Externa ( D ) Fluxo de Dados ( ) Mostra um agente externo ao sistema que está sendo modelado, e interage com ele. ( ) Mostra um dado ou uma coleção deles, e sempre inicia ou termina em um processo. ( ) É utilizado para representar os dados armazenados de alguma forma. ( ) Mostra uma parte do sistema que altera as entradas e saídas, e tem no mínimo eu fluxo de dados de entrada e outro de saída.

CAPÍTULO

6 Ciclo de vida

Objetivo Inicialmente, vamos descobrir juntos que existem diferentes ciclos de vida de software, Isto ĂŠ, formas distintas de se desenvolver um software. Em seguida, iremos estudar os modelos de ciclo de vida de software mais tradicionais na literatura e no mercado.

Ciclo de vida Um processo de software é utilizado para construir sistemas de qualquer natureza com o objetivo de favorecer a produção de sistemas com qualidade, que atenda as necessidades dos usuários, dentro do cronograma e orçamento planejado [15]. Ele não pode ser definido de forma universal, para que seja eficaz e produza um produto de qualidade, é necessário que o processo esteja alinhado com as especificações do projeto, ou seja, os processos devem ser definidos caso a caso, levando em consideração o domínio do problema, complexidade, tecnologia a ser adotada etc [15]. Dentro deste contexto, a escolha do modelo de ciclo de vida, ou modelo de processo, é o ponto de partida para definir o processo de desenvolvimento do software. De um modo geral, o modelo de ciclo de vida organiza as atividades do processo, definindo a sequência e as dependências das mesmas.

6.1 Algumas definições de ciclo de vida de software • Um framework que contém os processos, atividades e tarefas envolvidas na implementação, operação e manutenção de um produto de software, levando em consideração toda a vida do software, desde a definição de seus requisitos até o encerramento de seu uso (apud [16], ISO/IEC 12207); • É dividir a vida de um produto ou projeto em fases (apud [16], SEI, Glossário do CMMI); • É uma passagem completa por quatro fases: concepção, elaboração, construção e transição. É o intervalo de tempo entre o início de concepção e o final da fase de transição (apud [16], IBM/ Rational, Glossário do RUP).

Análise de Sistemas

6.2 Os componentes do desenvolvimento de um ciclo de vida Fases: indicam o progresso do projeto; Atividades: requerem ações para criar e entregar o projeto; Artefatos: são produtos palpáveis elaborados durante o projeto; e Marcos: são eventos importantes no projeto. Em geral, os modelos de processos possuem as fases de Análise e Especificação de Requisitos, Projeto, Implementação, Testes e Entrega e Implantação [15]. Há uma variedade de modelos com componentes diversos que podem ser aplicados a diferentes projetos. Não há um modelo mais correto que outro. É de responsabilidade do gerente de projeto definir o modelo mais indicado para o seu projeto [16].

6.3 Modelos de ciclo de vida Os principais modelos de ciclo de vida são classificados como [15]: Modelos Seqüenciais, Modelos Incrementais e Modelos Evolutivos.

6.3.1 MODELO SEQUENCIAL Este modelo organiza o processo em uma sequência de fases. O modelo cascata é considerado o principal modelo desta categoria e ele serviu como base para outros modelos, como os modelos incrementais e evolutivos [15].

6.3.2 MODELO CASCATA O modelo cascata, também conhecido como modelo clássico, organiza as atividades do processo de desenvolvimento de uma maneira seqüencial, conforme apresentado na Figura 25 [15].

Figura 25. Modelo Clássico/Cascata Fonte: Adatptado [16]

Ciclo de vida O Modelo Cascata é baseado nos processos convencionais de outras engenharias; possui uma abordagem sistemática e seqüencial cujos marcos e entregáveis são de fáceis de identificar; é fortemente documental e pouco iterativo; implica em uma especificação completa e é difícil introduzir mudanças depois de ter iniciado o processo [16]. As fases deste modelo são [16]: 1. Especificação (Requisitos): identificação e análise dos requisitos do sistema de acordo com as necessidades dos usuários; 2. Projeto (Design): é o detalhamento da solução para o sistema ser construído, ele incluiu padrões de projetos, algoritmos, definição da arquitetura etc. 3. Implementação: é a programação da solução na fase de projeto. Ela inclui os testes realizados sobre os módulos implementados (os testes de unidade). 4. Verificação e Validação: verificar se o que foi implementado está conforme a especificação e validar se o que foi implementado atende as necessidades do usuário. Esta fase também inclui os testes de integração. 5. Manutenção: evolução contínua do sistema trata os erros e as adaptações do sistema. A manutenção deve ser considerada em todos os ciclos de vida, ela não deve ser encarada como uma fase isolada e sim como uma aplicação contínua das atividades envolvidas nas fases anteriores [16]. Há quatro tipos de manutenção: • Manutenção Corretiva: corrigir os erros encontrados; • Manutenção Adaptativa: adaptar o software em relação a uma mudança externa. Exemplo: Atualização do sistema operacional; • Manutenção Evolutiva: é melhoria contínua do software. Exemplo: Inclusão de uma nova funcionalidade. • Manutenção Preventiva: é uma melhoria interna do sistema para otimizar um recurso. Exemplo: Otimizar um determinado algoritmo no código.

Análise de Sistemas O modelo Cascata possui algumas críticas relacionadas à sua eficiência, sendo destacados, a seguir, alguns dos problemas identificados: • Projetos reais não seguem o fluxo na sequência definida pelo modelo; • Os requisitos precisam ser definidos claramente já no início do projeto, o que na prática é difícil ocorrer. • O usuário terá uma versão operacional do sistema apenas no final do projeto; • O atraso em uma fase impacta na outra na fase.

6.3.2 MODELO V Este modelo é uma variação do modelo em cascata, que destaca a relação entre as atividades de teste e as demais fases do processo, conforma apresentado na Figura 26 [15].

Figura 26. Modelo V Fonte: [15]

Este modelo sugere que os testes de unidade são utilizados para verificar a implementação e o projeto detalhado. A conexão entre os lados direito e esquerda do modelo implica que, para os problemas identificados em uma atividade de teste, na fase correspondente do lado esquerdo e as fases subseqüentes podem ser executadas novamente para corrigir os problemas.

6.3.4 MODELOS INCREMENTAIS Nos casos onde é possível utilizar o modelo seqüencial em função do tamanho do sistema e/ou quando é preciso disponibilizar uma versão de forma mais rápida para o cliente, indica-se o modelo incremental [15].

Ciclo de vida No modelo incremental o sistema é dividido em módulos ou subsistemas, cujas versões são definidas, inicialmente com um pequeno subsistema funcional, que a cada ciclo insere novas funções [15]. O princípio do modelo é que, a cada iteração, é liberada uma versão operacional do sistema para o cliente utilizar e validar [15]. Destacam-se como as principais vantagens do modelo incremental [15]: • Economia no tempo e custo para se entregar a primeira versão; • Redução dos riscos no desenvolvimento de cada iteração em função do tamanho; • O número de mudanças nos requisitos pode diminuir devido ao curto tempo de desenvolvimento de um incremento. Com relação as desvantagens [15]: • Quando os requisitos são instáveis ou incompletos, alguns incrementos podem ter de ser muito alterados; • A gerência do projeto é complexa;

6.3.5 RUP (Rational Unified Process) “O RUP é um framework de processo de desenvolvimento de software que fornece uma abordagem disciplinada para associar tarefas e responsabilidades dentro de uma organização de desenvolvimento” [16]. Ele foi criado pela Rational e hoje é um produto da IBM. O RUP foi um projeto criado para suportar a implementação de melhores práticas que adotam o ciclo de vida iterativo incremental.

Análise de Sistemas Os princípios do RUP são [16]: • • • • •

Tratar os riscos desde o começo e continuamente; Garantir que algo de valor vai ser entregue ao cliente; É focado no executável do software; Tratar das mudanças desde o começo do projeto; Definir uma linha de base da arquitetura desde o começo do projeto; • Trabalhar em equipe; • Qualidade é inerente a tudo; As 6 melhores práticas [16]: • • • • • •

Desenvolvimento realizado de modo iterativo; Gerenciar requisitos; Utilizar arquitetura de componentes; Modelagem visual (utilizando UML); Verificar a qualidade continuamente; Gerenciar configuração e mudanças.

A Figura 27 ilustra o modelo iterativo.

Figura 27. Modelo Iterativo: Tempo e Conteúdo Fonte: [16]

No modelo iterativo uma iteração é uma sequência distinta com duração fixa de atividades, cujo resultado é uma release do produto executável. Onde um release refere-se ao software que já foi testado e ele é baseado em um build (ou em vários deles). Já um build refere-se ao software

Ciclo de vida que ainda está em teste, ele é gerado com maior frequência que o release. A Figura 28 ilustra o ciclo de vida iterativo.

Figura 28. Ciclo de Vida Iterativo Fonte: [16]

As fases fornecem marcos bem definidos, cujos objetivos de cada fase são atingidos com a execução de uma ou mais iterações dentro de cada fase. • Fase de Concepção - o foco está voltado no conceito, visão, identificação dos riscos, orçamento e requisitos, bem como, o objetivo do projeto de software precisa ser definido. • Fase de Elaboração - o foco está em prover a arquitetura do software. • Fase de Construção - o foco está voltado na construção do software. • Fase de Transição - o foco está na implementação e na liberação do produto final [16]. Exemplos de objetivos e critérios da Fase de Concepção [16]: Objetivos Primários

Critério de Avaliação do Marco

Estabelecer o escopo do projeto

Os stakeholders concordam sobre o escopo

Estabelecer os critérios de aceita- Os stakeholders concordam ção do projeto sobre os critérios Identificar as funcionalidades do Os stakeholders concordam com sistema e selecionar aquelas que os requisitos elicitados e que são críticas há um entendimento sobre os mesmos

Análise de Sistemas Estimar o custo e cronograma total do projeto

Os stakeholders concordam que as estimativas de custo/cronograma, prioridades, riscos e processo são apropriadas.

Estimar riscos em potencial

Todos os riscos foram registrados e avaliados e uma estratégia de mitigação foi definida

Configurar o ambiente de supor- O ambiente de suporte está te para o projeto pronto. Tabela 8. Fonte: Adaptado de [16]

Exemplos de objetivos e critérios da Fase de Elaboração [16]: Objetivos Primários

Critério de Avaliação do Marco

Garantir que a arquitetura, requisitos e planos são estáveis; estabelecer uma arquitetura controlada por baselines

A visão do produto, requisitos e arquitetura são estáveis.

Assegurar que os riscos são mitigados de forma eficiente para atender o custo/cronograma

Os riscos mais significantes foram destinados e estão sendo resolvidos de uma forma adequada

Demonstram que a arquitetura suportará os requisitos do sistema dentro do custo/ cronograma

Todos os aspectos de arquitetura do sistema e algumas funções estão sendo avaliadas em um protótipo.

Tabela 9. Fonte: Adaptado de [16]

Exemplos de objetivos e critérios da Fase de Construção [16]: Objetivos Primários

Critério de Avaliação do Marco

Alcançar versões úteis

O sistema foi desenvolvido conforme as expectativas especificadas

Completar a análise, design, implementação e teste de toda a funcionalidade requerida

Toda funcionalidade requerida foi incorporada no sistema.

Certificar que o sistema está pronto para ser posto no ambiente do cliente.

O sistema atendeu todos os critérios de aceitação quando testado no ambiente do cliente.

Tabela 10. Fonte: Adaptado de [16]

Ciclo de vida Exemplos de objetivos e critérios da Fase de Transição [16]: Objetivos Primários

Critério de Avaliação do Marco

Repassar o sistema para os canais adequados de liberação

O sistema passou nos critérios formais de aceitação no ambiente do usuário final

Tabela 11. Fonte: Adaptado de [16]

A figura abaixo representa o percentual de tempo gasto por fase. nota-se que a fase de construção consome mais tempo.

Figura 30. Distribuição do Tempo

6.3.6 MODELO EVOLUTIVO Há alguns sistemas em que é difícil estabelecer os seus requisitos, dada complexidade do mesmo, assim como estes requisitos são bastante instáveis. Dentro deste contexto é importante haver ciclos de vida que atendam este perfil de sistema, no entanto, de um modo geral, nem todo modelo incremental pode ser aplicado neste tipo de cenário. Para tal existem os modelos evolucionários ou evolutivos que buscam preencher esse espaço [16].

Análise de Sistemas 6.3.7 MODELO ESPIRAL O modelo espiral, apresentado na Figura 31, é um dos modelos evolutivos mais difundidos [15].

Figura 31. Modelo Espiral Fonte: [15]

Principais aspectos deste modelo [16]: • Melhorias do modelo em cascata; • Ele permite o envolvimento com o usuário; • É iterativo com releases incrementais e extremamente focado na análise de riscos; • Sua adoção não é trivial e envolve elevados custos; • Pode não convergir para uma solução; e • Não é muito utilizado.

Atividades de aprendizagem Selecione a opção que representa a sequência correta das fases do ciclo de vida iterativo e incremental: ( ( ( (

) Concepção, Elaboração, Construção, Transição ) Transição, Concepção, Elaboração, Construção ) Concepção, Transição, Construção, Elaboração ) Transição, Concepção, Elaboração, Construção

REFERÊNCIA BIBLIOGRÁFICA [1] http://www.csgnet.org/informatica/conteudo.aspx?id_area=1&id_tema=13 Apostila: Introdução à Análise de Sistemas (2003) [2]http://www.lcs.poli.usp.br/~jra/PROMINP/disciplina_OO_pdf/aula_I_Historia_ Abordagens_EstxOO.pdf

[3] Nascimento, Luciano Prado Reis. O usuário e o Desenvolvimento de Sistemas, Visual Books, Florianópolis, 2003. [5] Falbo, Ricardo de Almeida. Análise de Sistemas Notas de Aula, UFPES, 2002. Disponível em < http://www.ceunes.ufes.br/downloads/2/mariateixeira-Notas%20 de%20Aula.An%C3%A1lise%20de%20Sistemas.Prof%20Falbo.UFES.pdf> [6] Pessoa, André. Projetos de Sistemas de Informação, Book Express , 2000. [7] http://www.eteavare.com.br/arquivos/43_38.pdf [8] Wazlawick, Raul Sidnei. Análise e Projeto se Sistemas de Informação Orientados a Objetos. Rio de Janeiro: Elsevier, 2004. [9] Thiry, Marcello. Gerência de Requisitos (GRE), Incremental Tecnologia, 2009. [10] Professor Luis Angelo. SISTEMAS DE INFORMAÇÃO Componente Curricular Análise e Projeto de Sistemas I. Cidade de Avaré, 2008. Disponível em: <http://www.eteavare.com.br/arquivos/43_38.pdf> [11] Bezerra, Eduardo. Princípios de Análise e Projetos de Sistemas com UML. Rio de Janeiro: Elsevier, 2007. [12] Thiry, Marcello. Engenharia de Software: Requisitos, UNIVALI, 2007. [13] Guedes, Gilleanes T. A. UML 2: uma abordagem prática. São Paulo: Novatec Editora, 2009. [14] Professor Luis Angelo. Ciclo de Vida de Sistemas de Informação Componente Curricular Análise e Projeto de Sistemas I. Cidade de Avaré, 2009. Disponível em: <http://www.eteavare.com.br/arquivos/43_37.pdf> [15] Falbo, Ricardo de Almeida. Engenharia de Software Notas de Aula. Espírito

Santo, 2005.Disponível em: < http://www.inf.ufes.br/~falbo/download/aulas/esg/2005-1/NotasDeAula.pdf > [16] Thiry, Marcello. Engenharia de Software: Introdução, UNIVALI, 2007. [17] Thiry, Marcello. Engenharia de Software: Modelagem de Negócio, UNIVALI, 2007. [18] Thiry, Marcello. Engenharia de Software: Projeto (Design), UNIVALI, 2007. [19] http://www.google.com.br/imgres?imgurl=http://1.bp.blogspot.com/_gib0rD3V3Gg/SP5LdGVEw_I/AAAAAAAAAFU/mTuh0eAwmRU/s320/mictorio. jpg&imgrefurl=http://armariodearquivos.blogspot.com/2008_10_01_archive. html&usg=__FlpAuBDqkrkGY5nKBmSWQtmmMNY=&h=240&w=320&sz= 13&hl=pt-BR&start=14&um=1&itbs=1&tbnid=h9vKPZu3hIVT1M:&tbnh=8 9&tbnw=118&prev=/images%3Fq%3Dfalha%2Bno%2Bmict%25C3%25B3rio %26um%3D1%26hl%3Dpt-BR%26tbs%3Disch:1