Baixe o app para aproveitar ainda mais
Prévia do material em texto
MANUAL DO CURSO DE LICENCIATURA EM GSI 2º Ano Disciplina: Métodos de Analise, Desenho e Implementação de SI Código: Total Horas/1o Semestre: Créditos (SNATCA): Número de Temas: INSTITUTO SUPER INSTITUTO SUPERIOR DE CIÊNCIAS E EDUCAÇÃO A DISTÂNCIA - ISCED ISCED Curso de Gestão de Sistema de Informação; 20 Ano Disciplina/Módulo: ADISI i Direitos de autor (copyright) Este manual é propriedade do Instituto Superior de Ciências e Educação a Distância (ISCED), e contém reservados todos os direitos. É proibida a duplicação ou reprodução parcial ou total deste manual, sob quaisquer formas ou por quaisquer meios (electrónicos, mecânico, gravação, fotocópia ou outros), sem permissão expressa de entidade editora (Instituto Superior de Ciências e Educação a Distância (ISCED). A não observância do acima estipulado o infractor é passível a aplicação de processos judiciais em vigor no País. Instituto Superior de Ciências e Educação a Distância (ISCED) Direcção Académica Rua Dr. Almeida Lacerda, No 212 Ponta - Gêa Beira - Moçambique Telefone: +258 23 323501 Cel: +258 82 3055839 Fax: 23323501 E-mail: isced@isced.ac.mz Website: www.isced.ac.mz http://www.isced.ac.mz/ ISCED Curso de Gestão de Sistema de Informação; 20 Ano Disciplina/Módulo: ADISI ii Agradecimentos O Instituto Superior de Ciências e Educação a Distância (ISCED) agradece a colaboração dos seguintes indivíduos e instituições na elaboração deste manual: Autor Msc.Solomone Rumhungwe Coordenação Design Financiamento e Logística Revisão Científica e Linguística Ano de Publicação Local de Publicação Direcção Académica do ISCED Instituto Superior de Ciências e Educação a Distância (ISCED) Instituto Africano de Promoção da Educação a Distancia (IAPED) Português 2018 ISCED – BEIRA ISCED Curso de Gestão de Sistema de Informação; 20 Ano Disciplina/Módulo: ADISI iii Índice ISCED Curso de Gestão de Sistema de Informação; 20 Ano Disciplina/Módulo: ADISI iv Visão geral 1 Benvindo à Disciplina/Módulo de Analise, Desenho e Implementação de Sistema de Informação......................................................................................................................... 1 Objectivos do Módulo ....................................................................................................... 1 Quem deveria estudar este módulo .................................................................................. 2 Como está estruturado este módulo .................................................................................. 2 Ícones de actividade .......................................................................................................... 4 Habilidades de estudo ...................................................................................................... 4 Precisa de apoio? .............................................................................................................. 6 Tarefas (avaliação e auto-avaliação) ............................................................................... 6 Avaliação .......................................................................................................................... 7 TEMA – I: CONCEITOS GERAIS DE PROCESSO DE DESENVOLVIMENTO DE SOFTWARE 9 UNIDADE Temática 1.1. Introdução, Conceitos Gerais e Ciclo da vida e atividade de um processo. ............................................................................................................................ 9 Introdução .......................................................................................................................... 9 Sumário ............................................................................................................................ 15 Exercícios de AUTO-AVALIAÇÃO .................................................................................... 15 Exercícios para AVALIAÇÃO ........................................................................................... 15 Unidade Temático1.2: Análise: Elicitação e especificação de requisitos ......................... 15 TEMA -II: MODELAGEM DE SISTEMA DE INFORMAÇÃO 25 UNIDADE Temática 2.1. Introdução, Diagramas de UML, Historia, Diagrama de Caso de Uso, Aplicação Pratica e Estudo de Caso ........................................................................ 25 Introdução ........................................................................................................................ 25 UNIDADE temático 2.2: Os Modelos- Diagrama de Classe, Descrição de caso de uso, Diagramas de Interação, diagrama de Atividade e Aplicação Prática ......................... 33 UNIDADE Temática 2.3. Diagrama de Implementação - Componente e Implantação .... 60 Sumário ............................................................................................................................ 65 Exercícios de AUTO-AVALIAÇÃO .................................................................................... 65 Exercícios para AVALIAÇÃO ........................................................................................... 69 Exercícios do TEMA .......................................................................................................... 71 TEMA – III: IMPLEMENTACAO 71 UNIDADE Temática 3.1. Introdução, Atividades relacionadas ao código-fonte do Sistema ........................................................................................................................................ 71 Introdução ........................................................................................................................ 71 UNIDADE Tematico 3.2. Modelagem de Processo Desenvolvimento de Software – Introdução, Modelo Cascada, em fonte , Espiral , Iterativo/Incremental e Ágeis ........... 73 UNIDADE Temático 3.3. Processo Unificado .................................................................... 87 UNIDADE Temático 3.4. Padrões de Implementação ...................................................... 93 Sumário .......................................................................................................................... 101 Exercícios de AUTO-AVALIAÇÃO .................................................................................. 102 Exercícios para AVALIAÇÃO ......................................................................................... 107 ISCED Curso de Gestão de Sistema de Informação; 20 Ano Disciplina/Módulo: ADISI v TEMA -IV: TESTE DE SOFTWARE 107 UNIDADE Temática 4.1. Importância do teste de software ........................................... 108 Introdução ...................................................................................................................... 108 UNIDADE Temático 4.2 – Teste no projeto de sistema .................................................. 114 UNIDADE Temático 4.3 – Teste no Programa ................................................................ 117 UNIDADE Temático 4.4 – Teste na implantação do sistema .......................................... 124 UNIDADE Temático 4.5 – Teste de software em sistema em produção ......................... 126 Unidade Temático 4.6 – Ferramentas de teste de software ......................................... 132 ISCED Curso de Gestão de Sistema de Informação; 20 Ano Disciplina/Módulo:ADISI 1 Visão geral Benvindo à Disciplina/Módulo de Analise, Desenho e Implementação de Sistema de Informação Objectivos do Módulo Ao terminar o estudo deste módulo de Analise, Desenho e Implementação de Sistema de Informação deverá ser capaz de: apresentar o processo de desenvolvimento de uma aplicação desde os requerimentos do sistema até o desenho da aplicação usando conceitos de modelado UML para produzir diagramas detalhados. Pretende-se que o estudante seja capaz de identificar e definir os requisitos de um sistema e proceda ao desenho de Software centrado em objectos que satisfaça estes requisitos. Além disso, pretende-se que o estudante aplique metodologias padrão durante o processo de análise, desenho e desenvolvimento de Software com ênfase nos padrões de desenho Objectivos Específicos ▪ Demonstrar uma compreensão do processo de desenvolvimento de Literatura Fundamental Analise, Desenho Orientada ao Objecto (ADOO); ▪ Apreciar UML como um modelo para o sistema de Software Orientada a objecto (OO) típico; ▪ Apresentar conceitos ligados ao processo como a própria definição e o encadeamento das fases. ▪ Introduzidos conceitos de modelagem de sistemas e da linguagem de modelagem UML ▪ Familiarizar os leitores com o uso de ferramenta case para capaz de modelar aplicações utilizando UML. ▪ Novo programa de classes OO e pacotes usando os conceitos de herança e polimorfismo; ▪ Demonstrar uma compreensão básica do uso de padrões de desenho na conceção de sistemas de Software OO; ▪ Programa de interfaces gráficas usando alguns dos pacotes OO padrão. ▪ Desenvolver aplicativos autônomos usando desenho e implementação de abordagens reutilizáveis ISCED Curso de Gestão de Sistema de Informação; 20 Ano Disciplina/Módulo: ADISI 2 ▪ Investigar requisitos do usuário ▪ Definir, claramente, as necessidades do sistema ▪ Criar (ou adaptar) uma solução adequada ▪ Definição de tecnologias e arquitetura a serem adotadas ▪ Desenvolver a solução Proposta ▪ Garantir que a solução resolverá o problema em questão ▪ Modificar a solução sempre que novos requisitos forem identificados Quem deveria estudar este módulo Este Módulo foi concebido para estudantes do 2º ano do curso de licenciatura em GSI do ISCED. Poderá ocorrer, contudo, que haja leitores que queiram se actualizar e consolidar seus conhecimentos nessa disciplina, esses serão bem-vindos, não sendo necessário para tal se inscrever. Mas poderá adquirir o manual. Como está estruturado este módulo Este módulo de ADISI, para estudantes do 2º ano do curso de licenciatura em GSI, à semelhança dos restantes do ISCED, está estruturado como se segue: Páginas introdutórias ▪ Um índice completo. ▪ Uma visão geral detalhada dos conteúdos do módulo, resumindo os aspectos-chave que você precisa conhecer para melhor estudar. Recomendamos vivamente que leia esta secção com atenção antes de começar o seu estudo, como componente de habilidades de estudos. ISCED Curso de Gestão de Sistema de Informação; 20 Ano Disciplina/Módulo: ADISI 3 Conteúdo desta Disciplina / módulo Este módulo está estruturado em Temas. Cada tema, por sua vez comporta certo número de unidades temáticas ou simplesmente unidades. Cada unidade temática se caracteriza por conter uma introdução, objectivos, conteúdos. No final de cada unidade temática ou do próprio tema, são incorporados antes o sumário, exercícios de auto-avaliação, só depois é que aparecem os exercícios de avaliação. Os exercícios de avaliação têm as seguintes características: Puros exercícios teóricos/Práticos, Problemas não resolvidos e actividades práticas, incluído estudo de caso. Outros recursos A equipa dos académicos e pedagogos do ISCED, pensando em si, num cantinho, recôndito deste nosso vasto Moçambique e cheio de dúvidas e limitações no seu processo de aprendizagem, apresenta uma lista de recursos didácticos adicionais ao seu módulo para você explorar. Para tal o ISCED disponibiliza na biblioteca do seu centro de recursos mais material de estudos relacionado com o seu curso como: Livros e/ou módulos, CD, CD-ROOM, DVD. Para além deste material físico ou electrónico disponível na biblioteca, pode ter acesso a Plataforma digital moodle para alargar mais ainda as possibilidades dos seus estudos. Auto-avaliação e Tarefas de avaliação Tarefas de auto-avaliação para este módulo encontram-se no final de cada unidade temática e de cada tema. As tarefas dos exercícios de auto-avaliação apresentam duas características: primeiro apresentam exercícios resolvidos com detalhes. Segundo, exercícios que mostram apenas respostas. Tarefas de avaliação devem ser semelhantes às de auto-avaliação mas sem mostrar os passos e devem obedecer o grau crescente de dificuldades do processo de aprendizagem, umas a seguir a outras. Parte das terefas de avaliação será objecto dos trabalhos de campo a serem entregues aos tutores/docentes para efeitos de correcção e subsequentemente nota. Também constará do exame do fim do módulo. Pelo que, caro estudante, fazer todos os exercícios de avaliação é uma grande vantagem. ISCED Curso de Gestão de Sistema de Informação; 20 Ano Disciplina/Módulo: ADISI 4 Comentários e sugestões Use este espaço para dar sugestões valiosas, sobre determinados aspectos, quer de natureza científica, quer de natureza didáctico- Pedagógica, etc, sobre como deveriam ser ou estar apresentadas. Pode ser que graças as suas observações que, em gozo de confiança, classificamo-las de úteis, o próximo módulo venha a ser melhorado. Ícones de actividade Ao longo deste manual irá encontrar uma série de ícones nas margens das folhas. Estes ícones servem para identificar diferentes partes do processo de aprendizagem. Podem indicar uma parcela específica de texto, uma nova actividade ou tarefa, uma mudança de actividade, etc. Habilidades de estudo O principal objectivo deste campo é o de ensinar aprender a aprender. Aprender aprende-se. Durante a formação e desenvolvimento de competências, para facilitar a aprendizagem e alcançar melhores resultados, implicará empenho, dedicação e disciplina no estudo. Isto é, os bons resultados apenas se conseguem com estratégias eficientes e eficazes. Por isso é importante saber como, onde e quando estudar. Apresentamos algumas sugestões com as quais esperamos que caro estudante possa rentabilizar o tempo dedicado aos estudos, procedendo como se segue: 1º Praticar a leitura. Aprender a Distância exige alto domínio de leitura. 2º Fazer leitura diagonal aos conteúdos (leitura corrida). 3º Voltar a fazer leitura, desta vez para a compreensão e assimilação crítica dos conteúdos (ESTUDAR). 4º Fazer seminário (debate em grupos), para comprovar se a sua aprendizagem confere ou não com a dos colegas e com o padrão. 5º Fazer TC (Trabalho de Campo), algumas actividades práticas ou as de estudo de caso se existirem. IMPORTANTE: Em observância ao triângulo modo-espaço-tempo, respectivamente como, onde e quando...estudar, como foi referido no início deste item, antes de organizar os seus momentos de estudo reflicta sobre o ambiente de estudo que seria ideal para si: Estudo ISCED Curso de Gestão de Sistema de Informação; 20 Ano Disciplina/Módulo: ADISI 5 melhor em casa/biblioteca/café/outro lugar? Estudo melhor à noite/de manhã/de tarde/fins-de-semana/ao longo da semana? Estudo melhor com música/num sítio sossegado/num sítio barulhento!? Preciso de intervalo em cada 30 minutos, em cada hora, etc. É impossível estudar numanoite tudo o que devia ter sido estudado durante um determinado período de tempo; Deve estudar cada ponto da matéria em profundidade e passar só ao seguinte quando achar que já domina bem o anterior. Privilegia-se saber bem (com profundidade) o pouco que puder ler e estudar, que saber tudo superficialmente! Mas a melhor opção é juntar o útil ao agradável: Saber com profundidade todos conteúdos de cada tema, no módulo. Dica importante: não recomendamos estudar seguidamente por tempo superior a uma hora. Estudar por tempo de uma hora intercalado por 10 (dez) a 15 (quinze) minutos de descanso (chama- se descanso à mudança de actividades). Ou seja que durante o intervalo não se continuar a tratar dos mesmos assuntos das actividades obrigatórias. Uma longa exposição aos estudos ou ao trabalho intelectual obrigatório pode conduzir ao efeito contrário: baixar o rendimento da aprendizagem. Por que o estudante acumula um elevado volume de trabalho, em termos de estudos, em pouco tempo, criando interferência entre os conhecimentos, perde sequência lógica, por fim ao perceber que estuda tanto mas não aprende, cai em insegurança, depressão e desespero, por se achar injustamente incapaz! Não estude na última da hora; quando se trate de fazer alguma avaliação. Aprenda a ser estudante de facto (aquele que estuda sistematicamente), não estudar apenas para responder a questões de alguma avaliação, mas sim estude para a vida, sobre tudo, estude pensando na sua utilidade como futuro profissional, na área em que está a se formar. Organize na sua agenda um horário onde define a que horas e que matérias deve estudar durante a semana; Face ao tempo livre que resta, deve decidir como o utilizar produtivamente, decidindo quanto tempo será dedicado ao estudo e a outras actividades. É importante identificar as ideias principais de um texto, pois será uma necessidade para o estudo das diversas matérias que compõem o curso: A colocação de notas nas margens pode ajudar a estruturar a matéria de modo que seja mais fácil identificar as partes que está a estudar e Pode escrever conclusões, exemplos, vantagens, definições, datas, nomes, pode também utilizar a margem para ISCED Curso de Gestão de Sistema de Informação; 20 Ano Disciplina/Módulo: ADISI 6 colocar comentários seus relacionados com o que está a ler; a melhor altura para sublinhar é imediatamente a seguir à compreensão do texto e não depois de uma primeira leitura; Utilizar o dicionário sempre que surja um conceito cujo significado não conhece ou não lhe é familiar; Precisa de apoio? Caro estudante, temos a certeza que por uma ou por outra razão, o material de estudos impresso, lhe pode suscitar algumas dúvidas como falta de clareza, alguns erros de concordância, prováveis erros ortográficos, falta de clareza, fraca visibilidade, página trocada ou invertidas, etc). Nestes casos, contacte os serviços de atendimento e apoio ao estudante do seu Centro de Recursos (CR), via telefone, sms, E-mail, se tiver tempo, escreva mesmo uma carta participando a preocupação. Uma das atribuições dos Gestores dos CR e seus assistentes (Pedagógico e Administrativo), é a de monitorar e garantir a sua aprendizagem com qualidade e sucesso. Dai a relevância da comunicação no Ensino a Distância (EAD), onde o recurso as TIC se torna incontornável: entre estudantes, estudante – Tutor, estudante – CR, etc. As sessões presenciais são um momento em que você caro estudante, tem a oportunidade de interagir fisicamente com staff do seu CR, com tutores ou com parte da equipa central do ISCED indigitada para acompanhar as sua sessões presenciais. Neste período pode apresentar dúvidas, tratar assuntos de natureza pedagógica e/ou administrativa. O estudo em grupo, que está estimado para ocupar cerca de 30% do tempo de estudos a distância, é muita importância, na medida em que lhe permite situar, em termos do grau de aprendizagem com relação aos outros colegas. Desta maneira ficará a saber se precisa de apoio ou precisa de apoiar aos colegas. Desenvolver hábito de debater assuntos relacionados com os conteúdos programáticos, constantes nos diferentes temas e unidade temática, no módulo. Tarefas (avaliação e auto-avaliação) O estudante deve realizar todas as tarefas (exercícios, actividades e auto−avaliação), contudo nem todas deverão ser entregues, mas é importante que sejam realizadas. As tarefas devem ser entregues duas semanas antes das sessões presenciais seguintes. Para cada tarefa serão estabelecidos prazos de entrega, e o não cumprimento dos prazos de entrega, implica a não classificação do estudante. Tenha sempre presente que a nota dos trabalhos de campo conta e é decisiva para ser admitido ao exame final da disciplina/módulo. ISCED Curso de Gestão de Sistema de Informação; 20 Ano Disciplina/Módulo: ADISI 7 Os trabalhos devem ser entregues ao Centro de Recursos (CR) e os mesmos devem ser dirigidos ao tutor/docente. Podem ser utilizadas diferentes fontes e materiais de pesquisa, contudo os mesmos devem ser devidamente referenciados, respeitando os direitos do autor. O plágio1 é uma violação do direito intelectual do(s) autor(es). Uma transcrição à letra de mais de 8 (oito) palavras do testo de um autor, sem o citar é considerado plágio. A honestidade, humildade científica e o respeito pelos direitos autorais devem caracterizar a realização dos trabalhos e seu autor (estudante do ISCED). Avaliação Muitos perguntam: Com é possível avaliar estudantes à distância, estando eles fisicamente separados e muito distantes do docente/tutor! Nós dissemos: Sim é muito possível, talvez seja uma avaliação mais fiável e consistente. Você será avaliado durante os estudos à distância que contam com um mínimo de 90% do total de tempo que precisa de estudar os conteúdos do seu módulo. Quando o tempo de contacto presencial conta com um máximo de 10%) do total de tempo do módulo. A avaliação do estudante consta detalhada do regulamentado de avaliação. Os trabalhos de campo por si realizados, durante estudos e aprendizagem no campo, pesam 25% e servem para a nota de frequência para ir aos exames. Os exames são realizados no final da cadeira disciplina ou modulo e decorrem durante as sessões presenciais. Os exames pesam no mínimo 75%, o que adicionado aos 25% da média de frequência, determinam a nota final com a qual o estudante conclui a cadeira. A nota de 10 (dez) valores é a nota mínima de conclusão da cadeira. Nesta cadeira o estudante deverá realizar pelo menos 2 (dois) trabalhos e 1 (um) (exame). Algumas actividades práticas, relatórios e reflexões serão utilizados como ferramentas de avaliação formativa. Durante a realização das avaliações, os estudantes devem ter em consideração a apresentação, a coerência textual, o grau de cientificidade, a forma de conclusão dos assuntos, as recomendações, a identificação das referências bibliográficas utilizadas, o respeito pelos direitos do autor, entre outros. Os objectivos e critérios de avaliação constam do Regulamento de Avaliação. 1 Plágio - copiar ou assinar parcial ou totalmente uma obra literária, propriedade intelectual de outras pessoas, sem prévia autorização. ISCED Curso de Gestão de Sistema de Informação; 20 Ano Disciplina/Módulo: ADISI 9 TEMA – I: CONCEITOS GERAIS DE PROCESSO DE DESENVOLVIMENTO DE SOFTWARE UNIDADE Temática 1.1. Introdução, Conceitos Gerais: objectivos e Ciclo da vida e atividades de um processo. UNIDADE Temática 1.2. Análise: Elicitação e especificação de requisitos UNIDADE Temática 1.4. EXERCÍCIOS deste tema UNIDADE Temática 1.1. Introdução, Conceitos Gerais eCiclo da vida e atividade de um processo. Introdução O ciclo de vida de um sistema Software incluem análises e especificação de requisitos, desenho, implementação, testagem, instalação e manutenção. Engenharia de Software é a disciplina que se ocupa de todas as fases do ciclo de vida, tentando conseguir a construção de sistemas, que satisfaçam os requisitos dos usuários e dos clientes, duma forma eficiente. Para atingir este objetivo se utilizam metodologias para definir o processo completo da vida de um sistema. Entre estas metodologias destaca por sua madureza e uso na indústria do Software a metodologia UP /RUP, baseada no uso de iterações para construir Software de forma incremental e que utiliza UML como forma de expressar numa linguagem comum, o conhecimento relativo ao problema e a solução do sistema a construir. Objectivos específicos ▪ As fases de elicitação e especificação de requisitos, análise e projeto têm uma importância enorme no contexto de um rocesso de desenvolvimento de software devido ao fato de identificarem o que deve ser desenvolvido (requisitos e análise) e estabelecer como desenvolver (projeto). Portanto, os conceitos de eliciação e especificação de requisitos, análise e projeto de sistemas são, de modo a fornecer uma visão geral destas atividades no contexto do desenvolvimento de software Sistema ISCED Curso de Gestão de Sistema de Informação; 20 Ano Disciplina/Módulo: ADISI 10 É um conjunto de procedimentos que estabelecem o funcionamento do fluxo de trabalho (Workflow) das organizações. Ex: Secretária que organiza o agendamento dos pacientes de um consultório médico. É um conjunto de instruções que, orquestradas entre si, manipulam um conjunto de dados afim de produzir informação e eventos. Ex1: Sistema Web de agendamento de consultas médicas (Informação) Ex2: Sistema de Monitoramento de alerta de tempestades (Evento) Sistema vs Software O software é a automatização de um sistema. Nem todo sistema é automatizado. Ex: Agendamento manual de consultas médicas. O software é tanto o produto quanto o veículo para entregar o produto (PRESSMAN, 2002) Ex: Um relatório gerencial em PDF é o produto, assim como o sistema usado na sua geração. Software O software é o conjunto de vários artefatos e não apenas o código fonte (SOMMERVILLE, 2003). Realizando uma comparação entre o software e hardware. Chegamos a seguinte conclusão. O software apenas pode ser desenvolvido e realizar a manutenção (mudança) no software é uma tarefa omplicada, exige grande esforço da equipe de engenheiro de software. Ao passar do tempo o software fica deteriorado. Já para o hardware apenas pode ser fabricado e realizar a manutenção no hardware é implesmente trocar à peça que esta em desgaste. Ao passar do tempo o hardware desgasta por vários motivos (PRESSMAN, 2006). O software é caro porque torna se uma atividade difícil e trabalhosa de ser realizado pelo engenheiro de software (JALOTE, 2005). De acordo Pressman (2006) o software estão categorizados em seguintes tipos, tais como: Software de sistema. São programas que apóiam outros programas, como o software que realiza a comunicação com o hardware (sistema ISCED Curso de Gestão de Sistema de Informação; 20 Ano Disciplina/Módulo: ADISI 11 operacional) e software que ajuda na construção de outro software (compiladores). Software de aplicação. São programas que são desenvolvidos para executar no negócio de uma empresa determinada. Software científico e de engenharia. São algoritmos que processam números. Software embutido. São programas construídos para executarem dentro de um produto específico como a teclas digitais de um forno micro ondas. Software para linhas de produtos. São os softwares conhecidos como software de prateleiras. Software de web. São aplicativos que são executados via Internet. Software de inteligência artificial. São softwares que fazem os usos de algoritmos não numéricos. Estes tipos software se encaixam na robótica. Computação ubíqua. São softwares que realiza a verdadeira computação distribuída. Software aberto. São software que disponibiliza a visualização do código fonte da aplicação para o engenheiro de software modifica da maneira que deseja. Software Legado O nome de software legado é dado quando refere se num programa de computador que foi desenvolvido por há muito tempo. A reocupação do engenheiro de software com os softwares legados esta na baixa qualidade do software. Muitas vezes não existem documentações e se existem são pobres de detalhes, os casos de teste são pobres quando tem e sem um controle de mudanças. E muitas vezes não mexem no software legado quando eles atentem as necessidades do cliente (PRESSMAN, 2006). Engenharia de Software Engenharia de software é uma abordagem sistemática e disciplinada para o desenvolvimento de software (PRESSMAN, 2006). Uma das grandes dificuldades da engenharia do software é resolver o problema e deixar o cliente satisfeito com o software (JALOTE, 2005). ISCED Curso de Gestão de Sistema de Informação; 20 Ano Disciplina/Módulo: ADISI 12 Na demonstração da figura 1 representa uma visão do engenheiro de software em desenvolver o software que traz uma grande satisfação para o usuário quando ele próprio utiliza o software. A engenharia de software foca no software como produto. Não entra neste escopo o softwares construídos apenas para passarem o tempo dos programadores (PAULA FILHO, 2009). No desenvolvimento de um projeto de software quanto mais complexo é o software, maior é o empenho que o engenheiro de software deve fazer para desenvolver e tem que ter maior gerenciamento (JALOTE, 2005). Na demonstração da figura 2 representa uma comparação entre projetos de software grande e pequeno. Verificar que quanto maior é a complexidade do software mais atenção deve ter para a construção do software. A base da engenharia de software são conjuntos de atividades para o processo de desenvolvimento de software. A existência de vários tipos de processo de desenvolvimento de software e podemos dizer para resolver o problema do software usam estas atividades tais como: analise de requisito, design do software, código e teste (JALOTE, 2005). Analise de requisito. Através da analise de requisito é o momento onde efetua o conhecimento do problema para desenvolve o software (JALOTE, 2005). Design do software. Pelo design do software é o momento que o engenheiro de software realiza o planejamento da solução do problema que foi levantado no documento de requisito (JALOTE, 2005). Codificação. A codificação é o momento que pega o problema resolvido no design do software e transformará em uma linguagem de programação (JALOTE, 2005). ISCED Curso de Gestão de Sistema de Informação; 20 Ano Disciplina/Módulo: ADISI 13 Teste. O teste de software é o processo tem a intenção de encontrar defeitos nos artefatos de software (MYERS, 2004). O teste é uma maneira de medir o controle da qualidade do software durante o desenvolvimento de software (JALOTE, 2005). Engenharia de Software “É a criação e a utilização de sólidos princípios de engenharia a fim de obter software de maneira econômica, que seja confiável e que trabalhe eficientemente em máquinas reais.” (Fritz Bauer) Evolução do Software No início, os softwares eram muito pequenos, dadas as limitações de hardware. Com o crescimento do poder computacional, cresce também o tamanho e a complexidadedo software . Várias técnicas surgiram para ajudar na administração dessa complexidade: • Técnicas ligadas à linguagens de programação; • Aprofundamento dos estudos na Engenharia de Software; • Arquitetura de Software; • Ferramentas CASE. Tava tudo bonito até que... Crise do Software “A maioria dos especialistas concorda que o modo mais provável de o mundo ser destruído é por acidente. É onde nós entramos. Somos profissionais de computação. Nós causamos acidentes” (Nathaniel Borenstein) Anos 60, mas se arrasta até hoje segundo pesquisa do Standish Group (2009) • 18% dos projetos são cancelados por atrasos e orçamentos estourados; • 52% dos projetos estouram o orçamento e/ou prazo; • 30% de todos os projetos de TI atingem seus objetivos dentro de prazo e custo estimados. Outros motivos: ISCED Curso de Gestão de Sistema de Informação; 20 Ano Disciplina/Módulo: ADISI 14 • Taxa de rotatividade de pessoal elevada – Entre 20% e 30% ao ano • Grandes sistemas levando de 3 a 5 anos para serem desenvolvidos. Muitos deles se tornando obsoletos antes de serem entregues – Natimortos • Manutenção de software responsável pelo maior custo relacionado a computação para a maioria das empresas da área • Segundo Sommerville (2007), os problemas a seguir foram definidos como desafios-chave a serem superados: • Heterogeneidade - Técnicas de desenvolvimento para construção de software que possam lidar com ambientes heterogêneos. • Entrega - Técnicas de desenvolvimento para conduzir a entrega mais rápida de software . • Confiança - Técnicas de desenvolvimento que mostram que o software pode ter a confiança dos seus usuários. • Crise, mas nem tanto... • Apesar dos problemas relatados persistirem de alguma forma, até hoje, vivenciamos muito mais casos de sucessos que insucessos. • Alguns autores defendem que nunca existiu crise de software . Apenas uma Aflição Crônica (TEICHROW, 1989) • Aflição: “Qualquer coisa que causa dor ou desconforto”. • Crônica: “de longa duração ou que volta frequentemente” • Processo de Desenvolvimento de Software (PDS) • É a estrutura comum, composta por um pequeno número de atividades, que são utilizadas em todos os projetos de software (PRESSMAN, 2002). • Há muitos modelos para esses processos, cada um descrevendo abordagens diferentes para uma variedade de tarefas a serem executadas durante o processo. Ciclo de Vida e atividade de um processo Todo ciclo de desenvolvimento tem início, meio e fim. ISCED Curso de Gestão de Sistema de Informação; 20 Ano Disciplina/Módulo: ADISI 15 A variável temporal desse processo é chamada de Ciclo de Vida Todo processo é composto de atividades executadas, coordenadamente, num encadeamento de fases. Compreende todas das atividades relacionadas à definição, desenvolvimento, teste e manutenção do software. Existem vários processos. Cada um com a sua aplicabilidade. Sumário Nesta Unidade temática 1.1 estudamos e discutimos conceitos gerais de Processo de desenvolvimento de Software, tipos de software, engenharia do software e Ciclo de vida e actividade de um preocesso Exercícios de AUTO-AVALIAÇÃO Perguntas Respostas: 1A, 2C, 3V… Exercícios para AVALIAÇÃO Perguntas Respostas: 1A, 2C, 3V… Unidade Temático1.2: Análise: Elicitação e especificação de requisitos Análise De Sistemas Processo de reunir e interpretar factos, diagnosticar problemas, utilizar estes factos para melhorar o sistema. Na maior parte dos casos, o desenvolvimento de SI´s corresponde a projectos de grande dimensão, envolve a participação de vários grupos de stakeholders (técnicos e não técnicos), agrega várias componentes e tecnologias na sua estrutura (dados, ISCED Curso de Gestão de Sistema de Informação; 20 Ano Disciplina/Módulo: ADISI 16 processo e interfaces) e faz uso de várias técnicas e metodologias para apoiar o desenvolvimento das etapas que compõem o processo. De acordo com Whitten [5], hoje em dia grande parte dos SI’s suportam uma estrutura em torno de três componentes diferentes (Fig. 1): Processo de análise da situação de negócio, com o propósito de o melhorar através de procedimentos e métodos mais adequados. (i) Dados - componente que corresponde à camada mais profunda de um SI e é nela que se armazena todo o material potencialmente informativo (em bruto); (ii) Processo - componente que corresponde à camada intermédia onde é colocada toda a lógica aplicacional de modo a permitir uma correcta passagem de dados/informação com a máxima garantia de segurança; (iii) Interface - componente que corresponde à camada onde são estabelecidos os principais pontos de contacto entre o sistema e o exterior, quer para inputs de dados, quer para outputs de informação. Ainda que estas componentes se encontrem em todos os tipos de SI’s, a sua identificação vai sendo cada vez mais fácil à medida que passamos de uma filosofia de SI’s tradicionais (ex: aplicações locais) para SI’s distribuídos (ex: aplicações Web), uma vez que nestes, as três componentes encontram-se logicamente e fisicamente separadas, necessitando de uma quarta (rede) para integrar as três anteriores. Por este motivo (dispersão das componentes), o tratamento que cada componente em particular requer na construção do SI torna-se mais especial no caso dos SI’s distribuídos. ISCED Curso de Gestão de Sistema de Informação; 20 Ano Disciplina/Módulo: ADISI 17 Estrutura de construção de um SI – adaptado de [Whitten et al. 2001]. Hoje em dia a maior parte dos projectos de SI’s desenvolvidos têm características que os permitem classificar como SI’s distribuídos. A descrição feita ao longo deste manual irá considerar essa tendência, fazendo uma abordagem ao PDSI para o caso dos SI’s distribuídos na Web (aplicações Web) e, confrontando essa abordagem com o caso dos SI’s tradicionais. O desenvolvimento de SI’s é efectuado ao longo de várias etapas, contando com a participação de vários stakeholders. Os stakeholders técnicos que colaboram directamente no desenvolvimento da solução, tais como: (i) Analista de sistemas - tem como função principal coordenar os esforços dos restantes elementos participantes, desempenhando o papel de facilitador ao longo do processo. Geralmente está presente em todas as fases de desenvolvimento com importância especial nas fases inicias. Nestas, estuda o problema conjuntamente com o proprietário do sistema e determina as necessidades conjuntamente com os potenciais utilizadores, elaborando um relatório (denominado habitualmente como ‘especificação’) para posteriormente ser trabalhado pelos projectistas; (ii) Projectistas - geralmente especialistas tecnológicos que traduzem os requisitos descritos na especificação para soluções técnicas utilizando, para tal, uma linguagem de modelização adequada. Neste ISCED Curso de Gestão de Sistema de Informação; 20 Ano Disciplina/Módulo: ADISI 18 grupo podemos ainda encontrar os especialistas de usabilidade responsáveis pelo projecto de interfaces. (iii) Programadores - os especialistas tecnológicos, que trabalham no último elo da cadeia de desenvolvimento, com a responsabilidade de converter todo o trabalho resultante da etapa anterior para uma linguagem interpretável e executável pelo computador, assim como instalar e acompanhar a fase de arranque do novo sistema. Neste grupo podemos ainda encontrar os especialistas de usabilidade responsáveis pelo projecto de interfaces.Os stakeholders não técnicos, embora não integrando directamente a equipa de projecto, contribuam (de forma muito importante) param o sucesso do resultado final, através das suas propostas e sugestões a nível de requisitos funcionais e não-funcionais; sendo assim: (iv) Utilizadores – são todas as pessoas que irão interagir com o sistema, tendo um papel fundamental na identificação dos requisitos (funcionais e alguns requisitos não-funcionais); (v) Proprietários do sistema - um dos principais beneficiários com a integração do novo sistema, são também o principal responsável pelo financiamento do projecto, podendo tratar-se do proprietário da organização do qual o sistema irá fazer parte ou, simplesmente, de sócios ou administradores da mesma. O seu contributo para o desenvolvimento do sistema é muito importante, uma vez que se trata do principal detentor do conhecimento do negócio, missão da organização e consequente alinhamento dos objectivos pretendidos com o sistema. Para além destes, é necessário auscultar os consultores e vendedores das tecnologias de informação, uma vez que também estes são detentores do conhecimento tecnológico que irá constituir a base de suporte do sistema a desenvolver. Análise do problema Nesta etapa, primeira do ADISI, o analista reúne com o proprietário (ou outro responsável da organização) para clarificar o problema e discutir propostas de resolução. As técnicas utilizadas para a recolha de dados ISCED Curso de Gestão de Sistema de Informação; 20 Ano Disciplina/Módulo: ADISI 19 são, basicamente, reuniões, técnicas de observação directa e análise da documentação existente. Como resultado desta etapa, tem-se um relatório (Especificação 1 – Fig. 2) com a descrição da resolução do problema devidamente contextualizada no sistema organizacional e alinhada com o modelo de negócios da organização. Passa-se, então, à etapa seguinte, ou seja, à validação da proposta junto dos potenciais utilizadores. Etapas, técnicas e métodos no ADISI. Elicitação e especificação de requisitos Para que um projeto de desenvolvimento de software seja considerado de sucesso, uma das premissas é que o produto gerado atenda o que o cliente deseja. Na grande maioria dos casos o cliente não sabe ao certo o que deseja e por este motivo a descrição das funcionalidades esperadas por parte do cliente pode mudar no decorrer do projeto. Portanto, há a necessidade de documentação das necessidades do cliente. Quando estas descrições não são escritas ou são escritas e não são validadas com o cliente, é comum que no momento da entrega o cliente expresse que o produto não é o que ele havia solicitado anteriormente. ISCED Curso de Gestão de Sistema de Informação; 20 Ano Disciplina/Módulo: ADISI 20 Este é um dos grandes erros que os desenvolvedores individuais ou micro empresas de desenvolvimento de software que não se preocupam com requisitos estão sujeitas. Veja a seguinte imagem (Figura 3) que explicita de forma lúdica o que a ausência do uso das técnicas de Engenharia de software causa nas fases iniciais do desenvolvimento de software Fases Iniciais do Desenvolvimento sem Técnicas de Engenharia de Software. Como comprovar que o produto desenvolvido está em conformidade com o que foi solicitado? A solução para esta situação é utilizar descrições do sistema, onde as necessidades são documentadas e validadas pelo cliente. Deste modo o escopo do software é delimitado, alinhado e acordado entre o cliente e fornece -dor (equipe de desenvolvimento) do software. ISCED Curso de Gestão de Sistema de Informação; 20 Ano Disciplina/Módulo: ADISI 21 Requisito é o nome dado a este conjunto de documentos que descrevem os serviços a serem oferecidos pelo sistema e restrições operacionais de modo a satisfazer as necessidades do cliente. Requisito é o nome dado a este conjunto de documentos que descrevem os serviços a serem oferecidos pelo sistema e restrições operacionais de modo a satisfazer as necessidades do cliente. Outro fator que demonstra a importância de requisitos é a necessidade de manter rastreabilidade entre os artefatos, tendo em vista que os demais artefatos são evoluções do documento de requisitos no decorrer do projeto. Especificação • Última fase da tarefa de análise • É necessário que seja escrito de forma não ambígua qual é o comportamento requerido ✓ Notações formais ✓ Documentos estruturados ✓ Exemplos • Artefatos de Entrega (Saída) Especificação de requisitos que comunique ao projetista as características requeridas para o sistema, usando Casos de Uso Descritivos • Diagramas de Casos de Uso Possíveis Falhas ✓ Documentação insuficiente para o entendimento do problema ✓ Retrabalho ✓ Ocasiona atraso na execução das fases posteriores • Desenhar uma solução que seja fiel aos requisitos ✓ Com base na experiência acumulada (e técnicas padronizadas) • Geralmente precisam inovar em um certo nível ISCED Curso de Gestão de Sistema de Informação; 20 Ano Disciplina/Módulo: ADISI 22 • É possível que surjam várias soluções • Recomenda-se o uso de alguma métrica para a escolha da melhor solução para o projeto • Fase de definição de diversas tecnologias: ✓ Linguagem de Programação ✓ Padrões de Projetos ✓ Materializados na adoção de frameworks ✓ IDE ✓ Banco de Dados ✓ Etc. • Artefatos de Entrega (Saída) ✓ Um documento de projeto que, de forma não ambígua e clara, comunica o projeto com a equipe que irá implementar o software. ✓ Recomenda-se que contenha: ▪ Concepção arquitetural ▪ Ferramentas a serem adotadas ▪ Frameworks ▪ Etc. • Artefatos de Entrega (Saída) (cont.) ✓ Diagramas Estruturais ▪ Diagrama de Classes ▪ Diagrama de Componentes ▪ Etc. ✓ Diagramas Comportamentais ▪ Diagrama de Atividades ▪ Diagrama de Sequência ▪ Diagrama de Máquina de Estados ▪ Etc. ✓ Modelagem de dados Possíveis Falhas: ✓ Arquitetura do software difícil de ser replicada para a equipe ISCED Curso de Gestão de Sistema de Informação; 20 Ano Disciplina/Módulo: ADISI 23 ✓ Curva de aprendizagem desfavorável Em linhas gerais, o desenvolvimento dos artefatos ocorre da seguinte forma no decorrer do projeto. 1. O documento de requisitos é criado a partir do levantamento realizado; 2. Especificações de casos de uso a partir do documento de requisitos; 3. Diagramas da UML são criados para cada especificação de caso de uso; 4. O código é desenvolvido a partir dos diagramas gerados e da especificação de caso de uso (ou história do usuário); 5. As planilhas de teste são criadas tendo como base a especificação de caso de uso (ou história do usuário); 6. Quando o cliente vai realizar a validação do software desenvolvido, os requisitos que foram aceitos por ele são utilizados como parâmetro para validar o sistema; 7. Finalmente, quando o software será evoluído, o documento de requisitos é a raiz das mudanças a serem implementadas. Ferramentas de modelagem Na atividade de desenvolvimento, as ferramentas auxiliam a criação de có -digo com mais qualidade e menor esforço, aumentando a produtividade de programadores. Geralmente estas ferramentas são desenvolvidas para en -contrar erros à medida que o desenvolvedor digita os comandos de seu pro - grama e possuem depuradores que facilitam a descoberta do trecho que causou a falha. Eclipse e Dev são exemplos de ferramentas de desenvol -vimento, conhecidas como IDE ( Integrated DevelopmentEnvironment – Ambiente de Desenvolvimento Integrado). Paralelamente, as ferramentas de modelagem têm um papel central nesta atividade. A sua importância advém do fato de que ferramentas projeta -das tomando como base os princípios estabelecidos na linguagem propiciam a boa formação dos ISCED Curso de Gestão de Sistema de Informação; 20 Ano Disciplina/Módulo: ADISI 24 modelos gerados, reduzindo erros e aumentando a pro - dutividade na execução das atividades de análise e projeto. Várias ferramentas de modelagem têm sido propostas tomando por base a UML, podemos citar: • astah - http://astah.net/ •Rational Rose- http://www-01.ibm.com/software/awdtools/developer/rose •Jude- http://jude.change-vision.com/jude-web/product/index.html (Ver -são anterior do astah) • ArgoUML - http://argouml.tigris.org/ • DIA - http://projects.gnome.org/dia/ • Fujaba - http://www.fujaba.de/ • StarUML - http://staruml.sourceforge.net/en/ • Umbrello - http://uml.sourceforge.net/ •VisualParadigm- http://www.visual-paradigm.com/download/ Muitas vezes o software de modelagem disponibiliza duas versões: uma gratuita e outra paga. Este é o caso do astah, que disponibiliza uma versão gratuita: o astah community e outras versões astah Professional e astah UML que são do tipo Trial (gratuitas apenas para teste). A diferença entre elas encontra-se nas funcionalidades disponíveis, com o a versão Professional é pos -sível gerar código a partir dos diagramas e realizar engenharia reversa (Gerar diagramas a partir do código Java, C++ ou C#), o que não é possível com a versão Community. A ferramenta é de fácil uso e o instalador está disponível para down load em http://members.change-vision.com/files/astah_community Sumário Nesta Unidade temática 1.2 estudamos e discutimos Análise de sistema que inclui Elicitação e especificação de requisitos Exercícios de AUTO-AVALIAÇÃO Perguntas Respostas: 1A, 2C, 3V… http://astah.net/ http://www-01.ibm.com/software/awdtools/developer/rose http://jude.change-vision.com/jude-web/product/index.html http://argouml.tigris.org/ http://projects.gnome.org/dia/ http://www.fujaba.de/ http://staruml.sourceforge.net/en/ http://uml.sourceforge.net/ http://www.visual-paradigm.com/download/ http://members.change-vision.com/files/astah_community ISCED Curso de Gestão de Sistema de Informação; 20 Ano Disciplina/Módulo: ADISI 25 Exercícios para AVALIAÇÃO Perguntas Respostas: 1A, 2C, 3V… TEMA -II: MODELAGEM DE SISTEMA DE INFORMAÇÃO UNIDADE Temática 2.1. Introdução, Diagrama de UML: Diagrama de Caso de Uso, Aplicação pratica e estudo de caso. UNIDADE Temática 2.2. Os Modelos: Diagrama de Classe, Descrição de caso de uso, Diagramas de Interação, diagrama de Atividade e Aplicação Prática UNIDADE Temática 2.3. Diagrama de Implementação: Componente e Implantação UNIDADE Temática 2.4. EXERCÍCIOS deste tema UNIDADE Temática 2.1. Introdução, Diagramas de UML, Historia, Diagrama de Caso de Uso, Aplicação Pratica e Estudo de Caso Introdução A modelação do sistema representa a etapa onde toda a informação textual descrita na especificação é convertida para uma linguagem gráfica, de maneira a facilitar a comunicação entre os diferentes membros da equipa de projecto, nomeadamente os programadores que irão trabalhar sobre os modelos. Ainda que o analista esteja envolvido nesta etapa, a sua participação é menos activa, uma vez que esta tarefa é da responsabilidade directa do projectista. É nesta fase que se faz a ‘ponte’ entre a solução descrita na especificação e a implementação dessa solução, fazendo uso de uma determinada linguagem gráfica (metodologia). O trabalho efectuado nesta fase não acrescenta informação, apenas converte para modelos, existindo alguma propensão para se perder informação, quando não se utilizam os métodos adequados. Por esta razão, é precisamente neste ponto que se deve ter cuidado, para que nenhum trabalho efectuado anteriormente tenha aqui o seu fim. Desta forma, é muito importante utilizar um método adequado ao tipo de SI, de forma a garantir uma correcta passagem de informação entre a fase anterior e a fase da implementação. ISCED Curso de Gestão de Sistema de Informação; 20 Ano Disciplina/Módulo: ADISI 26 Análise específica o que é que o sistema deve fazer. Desenho apresenta como é que o sistema deve ser desenvolvido. Objetivo Solucionar problemas do mundo real, fazendo uso da linguagem UML na representação de modelos. Diagramas de UML • Por que surgiu? – Para instituir padronização na forma de desenvolvimento de softwares, pois era desenvolvido de forma imediatista, baseado no conhecimento dos técnicos, sem garantia de continuidade. • O que é? ISCED Curso de Gestão de Sistema de Informação; 20 Ano Disciplina/Módulo: ADISI 27 – É a definição de métodos, técnicas e ferramentas que devem ser aplicados para ordenar o desenvolvimento e se obter maior qualidade. A Importância da Modelagem É comum ouvir dizer que “Uma imagem vale mais que mil palavras”. Em desenvolvimento de sistemas não podia ser diferente. Um modelo representa melhor o negócio do que vários escritos de especificação. Um modelo oferece facilidade de comunicação entre as partes (usuário e técnico), documentação para garantir a continuidade e apoio na implementação. Princípios de Modelagem Todo modelo possui um propósito e simbologia própria para representação do negócio. Deve-se conhecer a forma de expressão do modelo para que a comunicação seja estabelecida corretamente e a leitura seja fiel ao contexto apresentado. Unified Modelling Language: Linguagem de modelagem que irá se associar ao processo para formar método. Representação desenvolvida a partir da aplicação de técnicas com características próprias para atender a natureza da aplicação em estudo. Técnicas possuem uma comunicação direta e se completam. Para utilizar a UML deve-se quebrar paradigmas e ter uma visão sistêmica e funcional abrangente. Histórico A UML tem origem na compilação das "melhores práticas de engenharia" que provaram ter sucesso na modelagem de sistemas grandes e complexos. Sucedeu aos conceitos de Booch, OMT (Rumbaugh) e OOSE (Jacobson) fundindo-os numa única linguagem de modelagem comum e largamente utilizada. A UML pretende ser a linguagem de modelagem padrão para modelar sistemas concorrentes e distribuídos. ISCED Curso de Gestão de Sistema de Informação; 20 Ano Disciplina/Módulo: ADISI 28 Os esforços para a criação da UML tiveram início em outubro de 1994, quando Rumbaugh se juntou a Booch na Rational. Com o objetivo de unificar os métodos Booch e OMT, decorrido um ano de trabalho, foi lançado, em outubro de 1995, o esboço da versão 0.8 do Unified Process - Processo Unificado (como era conhecido). Nesta mesma época, Jacobson se associou à Rational e o escopo do projeto da UML foi expandido para incorporar o método OOSE. Nasceu então, em junho de 1996, a versão 0.9 da UML. Finalmente em 1997, a UML foi aprovada como padrão pelo OMG (Object Management Group), um consórcio internacional de empresas que define e ratifica padrões na área de Orientação a Objetos. Atualmente encontra-se na versão 2.2 Aplicação – A UML foi definida para ser utilizada na Metodologia Orientada a Objetos, o que significa que ela possui recursos para representação dos conceitos propostos pela metodologia. • É possível utilizar em outras metodologias!!!! Objetivo– Ser independente da linguagem de programação e processo de desenvolvimento. ISCED Curso de Gestão de Sistema de Informação; 20 Ano Disciplina/Módulo: ADISI 29 Não se utiliza obrigatoriamente todos os modelos em todos os projetos. Deve-se utilizar o que melhor representar o contexto do negócio. Diagrama de Casos de Uso • Modelo aplicado para representar os requisitos de sistema. • O que são requisitos? – São as necessidades dos usuários, as funcionalidades necessárias para realizar o negócio. • Quais são os tipos? – Funcionais: Ligados a produção da aplicação. – Não-funcionais: Necessidades de ambiente e estrutura operacional (operacionalidade, ambiente operacional, etc.); Caso de Uso: Simbologia ISCED Curso de Gestão de Sistema de Informação; 20 Ano Disciplina/Módulo: ADISI 30 • Simbologia – Interação de Casos de Uso <<include>> Estabelece a ligação obrigatória entre os casos de uso. SEMPRE o caso de uso será executado <<extend>> estabelece a ligação opcional entre os casos de uso. O caso de uso será executado em atendimento a uma regra de negócio. ISCED Curso de Gestão de Sistema de Informação; 20 Ano Disciplina/Módulo: ADISI 31 Simbologia – Generalização de Ator Representa a classificação de um determinado ator Deve ser usada quando: Temos mais de um ator realizando a mesma tarefa e, algumas tarefas diferenciadas. Concentra em um caso de uso um conjunto de procedimentos que serão utilizados por vários outros casos de uso que possuem outras particularidades. ISCED Curso de Gestão de Sistema de Informação; 20 Ano Disciplina/Módulo: ADISI 32 Aplicação Prática • Passos para construção: 1.Leia atentamente o estudo de caso e identifique os requisitos e os responsáveis por realizar os requisitos; 2.Crie uma lista de atores e requisitos; 3.Inicie a construção do modelo verificando quem é o responsável por .realizá-lo: ator ou outro caso de uso. 4.Sendo o ator: represente o modelo. 5.Sendo outro caso de uso verifique se essa interação é de <<include>> ou <<extend>>. 6.Verifique se existe generalização. Estudo de Caso • Estacionamento “Parque de Estacionamento” • Diariamente o estacionamento “Parque da Estácio” recebe vários clientes para aluguel de suas vagas e possui uma rotina destinada ao bom atendimento. • O gerente do estacionamento cadastra todas as vagas com sua devida localização e situação. No caso de algum impedimento, goteira e obra, por exemplo, as vagas são interditadas para uso. • O veículo é identificado (Placa, Cor e modelo) na entrada e registrado pelo atendente/recepcionista, que emite um comprovante e cadastra o cliente que for recebido pela 1ª vez. A locação da vaga registra data e hora de entrada, identifica o motorista e atendente/ recepcionista e, bloqueia a vaga. ISCED Curso de Gestão de Sistema de Informação; 20 Ano Disciplina/Módulo: ADISI 33 • A liberação é efetivada a partir da solicitação do cliente, que entrega ao atendente/recepcionista o seu comprovante de locação, realiza o pagamento e recebe uma autorização de saída. São registradas data e hora de saída e a vaga é liberada para um próximo cliente. • O motorista retira o carro da vaga e entrega-o ao cliente. Sumário Nesta Unidade temática 2.1 estudamos e discutimos fundamentalmente …… Exercícios de AUTO-AVALIAÇÃO Perguntas Respostas: 1A, 2C, 3V… Exercícios para AVALIAÇÃO Perguntas Respostas: 1A, 2C, 3V… UNIDADE temático 2.2: Os Modelos- Diagrama de Classe, Descrição de caso de uso, Diagramas de Interação, diagrama de Atividade e Aplicação Prática Diagrama de Classe Modelo aplicado para representar as informações necessárias para realização das funcionalidades do sistema em estudo a partir do conceito de CLASSE. Exemplo: ISCED Curso de Gestão de Sistema de Informação; 20 Ano Disciplina/Módulo: ADISI 34 • O que é CLASSE? • Antes é preciso saber o que OBJETO. • Exemplo: Em um negócio de vendas, quais os elementos movimentam a execução do negócio? SIM!!! SÃO OBJETOS DO NEGÓCIO • OBJETO: Todo elemento que representa ou compõe algum conceito dentro de nosso projeto. • CLASSE: Conjunto de objetos com atributos e comportamentos representados por métodos. Ex.: Classe CLIENTES representa todos os clientes da empresa. • ATRIBUTO: Característica ou identificação do objeto. Ex.: nome, cpf, email, • MÉTODOS: Operações realizadas param um objeto. Ex.: lerNome () Diagrama de Classe – Simbologia ISCED Curso de Gestão de Sistema de Informação; 20 Ano Disciplina/Módulo: ADISI 35 Para identificar uma classe devemos analisar se o objeto: • Possui vida própria; • Possui mais de um atributo; • Deseja-se acompanhar existência; • ASSOCIAÇÃO ligação estabelecida entre as classes, por necessidade de comportamentos do negócio analisado. ISCED Curso de Gestão de Sistema de Informação; 20 Ano Disciplina/Módulo: ADISI 36 • PAPEL nome da associação, tornando claro no diagrama o ligação estabelecida. • MULTIPLICIDADE define o número de vezes em que o objeto participa da associação. MULTIPLICIDADE – Deve ser representada utilizando os dois sentidos de leitura, sempre associado a um objeto com o resultado na outra classe e levando em consideração os comportamentos desejados do negócio que está sendo analisado. – A representação de multiplicidade possui o seguinte esquema: – Li ... Ls, onde: Li define o Limite inferior – Ls define o Limite superior – Li e Ls poderão ter valores numéricos de 0 a n e – Ls poderá também ter a representação * que tem como significado infinito/muitos. CLASSE ASSOCIATIVA – Classe que representa os objetos resultados de uma associação, com atributos, características e operações próprias. ISCED Curso de Gestão de Sistema de Informação; 20 Ano Disciplina/Módulo: ADISI 37 RESTRIÇÕES – Complementam o modelo com informações não representadas. • AGREGAÇÃO POR REFERÊNCIA – Define o conceito <compõe> e associa os objetos indicando que existe referência para várias participações. ISCED Curso de Gestão de Sistema de Informação; 20 Ano Disciplina/Módulo: ADISI 38 AGREGAÇÃO POR VALOR – Define o conceito <estar inserido> associando os objetos indicando que existe referência para apenas uma participação e estabelece uma dependência entre as classes associadas. Passos para desenvolvimento 1. Identificar no diagrama de caso de uso os objetos que possuem identificação própria e precisam ter essas informações guardadas para atendimento dos requisitos de sistema: Essas são as classes. 2. Identificar a ligação que existe entre os objetos. 3. Estabelecer as associações na melhor forma de representação da natureza do negócio. Diagrama de Classe • Estacionamento “Parque de Estacionamento” ▪ Diariamente o estacionamento “Parque de Estacionamento” recebe vários clientes para aluguel de suas vagas e possui uma rotina destinada ao bom atendimento. ISCED Curso de Gestão de Sistema de Informação; 20 Ano Disciplina/Módulo: ADISI39 ▪ O gerente do estacionamento cadastra todas as vagas com sua devida localização e situação. No caso de algum impedimento, goteira e obra, por exemplo, as vagas são interditadas para uso. ▪ O veículo é identificado (Placa, Cor e modelo) na entrada e registrado pelo atendente/recepcionista, que emite um comprovante e cadastra o cliente que for recebido pela 1ª vez. A locação da vaga registra data e hora de entrada, identifica o motorista e atendente/recepcionista e, bloqueia a vaga. ▪ A liberação é efetivada a partir da solicitação do cliente, que entrega ao atendente/recepcionista o seu comprovante de locação, realiza o pagamento e recebe uma autorização de saída. São registradas data e hora de saída e a vaga é liberada para um próximo cliente. ▪ O motorista retira o carro da vaga e entrega-o ao cliente. Estudo de Caso – Caso de Uso • AUTO ASSOCIAÇÃO – Define quando um objeto de uma classe está relacionado com outro objeto da mesma classe para atender a algum comportamento. A multiplicidade é estabelecida normalmente. ISCED Curso de Gestão de Sistema de Informação; 20 Ano Disciplina/Módulo: ADISI 40 • GENERALIZAÇÃO / ESPECIALIZAÇÃO – Generalização: Representa os vários tipos de um objeto em uma única classe. – Especialização: Representa os vários tipos de um objeto em uma classe distinta relacionando seus próprios atributos e comportamentos. – Atributos e comportamentos comuns são relacionados na classe mãe. ISCED Curso de Gestão de Sistema de Informação; 20 Ano Disciplina/Módulo: ADISI 41 Passos para desenvolvimento • 1º Passo - Buscar no escopo do projeto os conjuntos de objetos que tenham identificação própria. (Analisaros casos de uso de cadastro, por exemplo); • 2º Passo - Analisar os atributos das classes para identificar aqueles que indicam outras classes. Esta identificação gera a associação entre as classes; • 3º Passo - Buscar conjuntos de objetos inseridos no contexto do estudo que servem para controlar e acompanhar as atividades do projeto; • 4º Passo - Relacionar atributos destas classes; • 5º Passo – Criar novas classes e associações considerando as formas normais: Primeira Forma Normal: Uma relação está na primeira forma normal se todos os seus atributos são monovalorados. Segunda Forma Normal: a relação estiver na primeira forma normal; e todos os atributos primos dependerem funcionalmente de toda a chave primária. Terceira Forma Normal: a relação estiver na segunda forma normal; e todos os atributos primos dependerem não transitivamente de toda a chave primária. • 6º Passo – Criar novas classes e associações identificando atributos que definem vários objetos da classe. • 7º Passo - Definir as multiplicidades; • 8º Passo - É sabido que o diagrama de classe deve dar suporte à realização dos casos de uso. Verificar se o diagrama de classe possui atributos para atender a todos os procedimentos. Se não estiver, complementar o diagrama de classe. • 9º Passo - O caso de uso também deverá criar e manter as informações do diagrama de classe. Verificar se todas as classes e atributos estão sendo contemplados na realização dos casos de uso. Se não estiver, complementar o diagrama de caso de uso. Aplicação Prática • Sistema de Gestão de Hotel Estacio • O cadastro do hóspede (nome, procedência, endereço, contato, previsão de permanência) é realizado pelo setor de recepção que também controla a alocação de quarto/apartamento (número do quarto ou apartamento) e abertura de uma conta corrente para o hóspede (senha, número da conta, nome do hospede). ISCED Curso de Gestão de Sistema de Informação; 20 Ano Disciplina/Módulo: ADISI 42 • Ao setor de serviço de copa cabe a responsabilidade pelos lançamentos, na conta do hospede, das despesas que o mesmo efetuar com bebidas e comidas (data, tipo da despesa e valor). • A atendente/recepcionista de telefonia é responsável pelo lançamento, na conta do cliente, das chamadas interurbanas que o mesmo venha a fazer (data, local chamado, duração e tarifa). • As chamadas locais não são computadas. • O setor de lavanderia é responsável pelos lançamentos, na conta do hóspede, dos serviços que o mesmo venha a solicitar àquele setor (data, tipo de serviço, valor). • A gerência pode, a qualquer instante, ter acesso às informações de cadastro e gastos realizados pelo hóspede. • A gerência é responsável pelo cadastro e atualização das tabelas de serviços, menus e diárias. • O hóspede pode a qualquer instante consultar o saldo de sua conta. • O setor de recepção é responsável pela extração do extrato final da conta e fechamento da mesma quando o hóspede finaliza sua estadia. Aplicação Prática ISCED Curso de Gestão de Sistema de Informação; 20 Ano Disciplina/Módulo: ADISI 43 Descrição de Casos de Uso • A Descrição de caso de uso é a representação textual dos casos de uso. Deve ser utilizada para complementar o modelo, pois muitas regras de negócio estão implícitas ao caso de uso. Este recurso ajuda a validar se a compreensão dos requisitos foi plena. • A descrição registra a funcionalidade lógica e é o documento comprobatório de nosso levantamento, onde o usuário poderá validar o nosso entendimento. A descrição de caso de uso é desenvolvida para cada caso de uso. As interações devem ser citadas na abrangência da descrição, mas não deve definir dois casos de uso em uma só descrição. Quanto mais clara a definição melhor o entendimento. • A descrição poderá ser desenvolvida de duas formas: Descrição não Expandida e Descrição Expandida. Formação: Cabeçalho + descrição ISCED Curso de Gestão de Sistema de Informação; 20 Ano Disciplina/Módulo: ADISI 44 • Descrição não Expandida prevê a apresentação sucinta dos procedimentos, como um pequeno relato apresentando os objetivos a serem atingidos. Deve ser utilizada quando o Caso de Uso for de conhecimento completo de todos, não possuir exceções ou, utilizar mecanismos de outro caso de uso. • Exemplo “Parque de Estácionamento”: Utilizando o Caso de Uso “Emitir autorização de saída”: – Nome: Emitir Autorização de saída – Objetivo: Gerar comprovante de quitação do aluguel da vaga. – Pré-condição: estar com a locação fechada. – Pós-condição: não há • Exemplo “Estacionamento Praça da Estácio”: • Utilizando o Caso de Uso “Emitir autorização de saída”: • Descrição • Emitir autorização de saída, Formulário 005, a partir das informações de fechamento de locação. • Descrição Expandida prevê a apresentação detalhados procedimentos, apresentando os objetivos a serem atingidos passo-a- passo e com referência a responsabilidade se ator ou sistema. • Devemos considerar a descrição em duas partes: Fluxo Normal e Fluxo Alternativo. • Fluxo Normal é o passo-a-passo dos procedimentos sem desvio. Uma lista de procedimentos considerando os passos frequentes e sem exceção. • Fluxo Alternativo é o passo-a-passo dos procedimentos de exceção e condições alternativas para ISCED Curso de Gestão de Sistema de Informação; 20 Ano Disciplina/Módulo: ADISI 45 determinado passo do Fluxo Normal. Não são todos os passos citados no Fluxo Normal que terá citação no Fluxo Alternativo. • Exemplo “Parque de Estacionamento”: – Utilizando o Caso de Uso “Registrar Locação”: Na Descrição Expandida, para consumar uma descrição consistente é necessário um projetode interface, mesmo que não possua todas as configurações visuais. O importante é representarmos a funcionalidade básica e não os detalhes de programação. • 1º Passo: IDEALIZAR A INTERFACE • 2º passo: CABEÇALHO – NOME........... : Registrar Locação – DESCRIÇÃO.: O atendente identifica o veiculo em sua entrada no estacionamento e cadastra sua ocupação da vaga. – Pré-Condição: Ter acesso a interface. ISCED Curso de Gestão de Sistema de Informação; 20 Ano Disciplina/Módulo: ADISI 46 – Pós-Condição: VAGA estará bloqueada • 3º Passo: Descrever FLUXO NORMAL • FLUXO NORMAL 1.Sistema Apresenta Tela de Locação. 2.Vendedor Informa Placa de VEÍCULO. 3.Sistema obtém dados de VEÍCULO. 4.Sistema obtém dados de CLIENTE. 5.Sistema apresenta dados de CLIENTE. 6.Sistema obtém dados de VAGA. 7.Sistema apresenta lista de VAGA. 8.Vendedor escolhe VAGA. 9.Vendedor clica CONFIRMA. 10.Sistema altera VAGA. 11.Sistema Inclui “Emitir Comprovante de Locação” 12.Sistema Encerra Caso De Uso. • 4º Passo: Descrever FLUXO ALTERNATIVO • FLUXO ALTERNATIVO • 3. Sistema obtém dados de VEÍCULO. – 3.1 Não há registro de VEÍCULO • 3.1.1 Sistema estende “Cadastrar Veículo”. • 3.1.2 Sistema retorna para item 4. • 4º Passo: Descrever fluxo normal – 4. Sistema obtém dados de CLIENTE. • 4.1 Não há registro de CLIENTE – 4.1.1 Sistema estende “Cadastrar Cliente”. – 4.1.2 Sistema retorna para item 5. – 5. Vendedor clica Cancela. • 5.1 Sistema retorna para item 1. ISCED Curso de Gestão de Sistema de Informação; 20 Ano Disciplina/Módulo: ADISI 47 • OBSERVAÇÕES: – Não possuímos no nosso Diagrama o Caso de Uso “Cadastrar Cliente”, item 4.1.1 da descrição. A necessidade surgiu durante a especificação. Quando isto ocorre é necessário voltarmos ao diagrama e incluir este novo caso de uso; – Mais uma vez deve ser comentado que a cada modelo/técnica utilizada deve-se estar pronto a recomeçar, pois é possível sempre estar descobrindo falhas ou complementos Descrição de Casos de Uso • A especificação de caso de uso também disponibiliza um recurso para informações adicionais do tipo, vagas bloqueadas terão código “B”. Para isto, retornamos a especificação e incluímos um COMENTÁRIO entre asteriscos imediatamente após o passo desejado; • Outra informação relevante para ser incluída em comentário é a tecla utilizada para fim, quando for o caso; • Fluxo Normal 1.Sistema Apresenta Tela de Locação. 2.Vendedor Informa Placa de VEÍCULO. 3.Sistema obtém dados de VEÍCULO. 4.Sistema obtém dados de CLIENTE. 5.Sistema apresenta dados de CLIENTE. 6.Sistema obtém dados de VAGA. 7.Sistema apresenta lista de VAGA. ISCED Curso de Gestão de Sistema de Informação; 20 Ano Disciplina/Módulo: ADISI 48 8.Vendedor escolhe VAGA. 9.Vendedor clica CONFIRMA. 10.Sistema altera VAGA. 11.Sistema Inclui “Emitir Comprovante de Locação” 12.Sistema Encerra Caso De Uso. • Portanto, deve-se preocupar em apresentar os detalhes necessários para: – Usuário aferir o atendimento do requisito; – Avaliar as restrições; – Dar segurança ao projeto no sentido do programador ter entendimento completo; – Documentação; •REGRAS: – Para descrever um caso de uso é preciso a aplicação de regras, pois assim é definido um padrão de entendimento entre o usuário e o técnico. Dentre as regras podemos destacar: • Estabelecer o diálogo entre o usuário e o sistema. • Adotar sentenças curtas, • Os passos devem ser numerados, sequenciados logicamente; • A primeira e a última sentença são comandadas pelo sistema; • Deve-se utilizar um padrão de linguagem; • Descrição não representa condição e repetição; • Descrição não representa controles técnicos (críticas, fim de leitura); • Não é preciso fluxo alternativo para todas as sentenças relacionadas no fluxo normal. Apresentar somente quando necessário. • Podem-se utilizar comentários para complementar a informação “*** comentários”; • Para representar os INCLUDES utilizar <INCLUIR>; • Para representar os EXTENDS utilizar <ESTENDER>. • EXERCÍCIO: ISCED Curso de Gestão de Sistema de Informação; 20 Ano Disciplina/Módulo: ADISI 49 • Dado o seguinte diagrama de caso de uso e diagrama de classe de um sistema de locação de carros. • EXERCÍCIO: – Interface • EXERCÍCIO: • Segue a DESCRIÇÃO EXPANDIDA – Nome: Alugar Veículos – Descrição: Registra o aluguel do veículo do cliente. – Pré-condição: Veículo deve estar cadastrado e disponível – Pós-Condição: Locação definida • Fluxo Normal: – 1. Sistema apresenta tela; – 2. Sistema apresenta lista de modelos disponíveis; – 3. Sistema apresenta lista de cor; ISCED Curso de Gestão de Sistema de Informação; 20 Ano Disciplina/Módulo: ADISI 50 – 4. Ator escolhe modelo; – 5. Sistema apresenta dados do veículo; – 6. Sistema apresenta lista de Clientes; – 7. Ator escolhe Nome do Cliente – 8. Ator informa data de aluguel e número de dias; • EXERCÍCIO (cont..): – 9. Sistema calcula data devolução; – 10. Ator confirma operação clicando em “Ok”; – 11. Sistema <inclui> “Emitir Contrato”; • EXERCÍCIO: – 12. Sistema cria locação; – 13. Sistema Atualiza veículo – ***Situação = indisponível – 14. Sistema encerra caso de uso • EXERCÍCIO – Revendo os modelos já produzidos... – 2. Sistema apresenta lista de modelos disponíveis; • Diagrama de Interação – Conceitos Básicos – Diagrama de Sequencia – Diagrama de Sequencia de Sistema - DSS – Diagrama de Colaboração – Aplicação Relembrar... ISCED Curso de Gestão de Sistema de Informação; 20 Ano Disciplina/Módulo: ADISI 51 • Conceitos: – O Diagrama de Interação apresenta a relação entre os objetos e a troca de mensagens que são necessárias para efetivar a realização do comportamento. – O Diagrama de Interação representa um único caso de uso e deve ser usado quando se deseja visualizar os comportamentos utilizados pelos vários objetos dentro do caso de uso. – Diagramas de interação são apresentados sob duas formas na UML através do Diagrama de Sequência e Diagrama de Comunicação. • DIAGRAMA DE SEQUÊNCIA: – Representa a sequência lógica dos comportamentos dentro do caso de uso. Portanto a leitura é realizada de cima para baixo e, da esquerda para direita. – Os elementos utilizados para compor o diagrama são os seguintes: • DIAGRAMA DE SEQUÊNCIA – SIMBOLOGIA ISCED Curso de Gestão de Sistema de Informação; 20 Ano Disciplina/Módulo: ADISI 52 ISCED Curso de Gestão de Sistema de Informação; 20 Ano Disciplina/Módulo: ADISI 53 DIAGRAMA DE SEQUÊNCIA – EXEMPLO – FLUXO NORMAL 1. Sistema Apresenta Tela de Locação. ISCED Curso de Gestão de Sistema de Informação; 20 Ano Disciplina/Módulo: ADISI 54 2. Vendedor Informa Placa de VEÍCULO. 3. Sistema obtém dados de VEÍCULO. 4. Sistema obtém dados de CLIENTE. 5. Sistema apresenta dados de CLIENTE. 6. Sistema obtém dados de VAGA. 7. Sistema apresenta lista de VAGA. 8. Vendedor escolhe VAGA. 9. Vendedor clica CONFIRMA. 10.Sistema altera VAGA. 11.Sistema Inclui “Emitir Comprovante de Locação” 12.Sistema Encerra Caso De Uso. • DIAGRAMA DE COMUNICAÇÃO
Compartilhar