Baixe o app para aproveitar ainda mais
Prévia do material em texto
2016 ModelageM de SiSteMaS eMpreSariaiS Prof. Neli Miglioli Sabadin Copyright © UNIASSELVI 2016 Elaboração: Prof. Neli Miglioli Sabadin Revisão, Diagramação e Produção: Centro Universitário Leonardo da Vinci – UNIASSELVI Ficha catalográfica elaborada na fonte pela Biblioteca Dante Alighieri UNIASSELVI – Indaial. 003 S113m Sabadin; Neli Miglioli Modelagem de sistemas empresariais/ Neli Miglioli Sabadin: UNIASSELVI, 2016. 191 p. : il ISBN 978-85-7830-962-6 1. Sistemas. I. Centro Universitário Leonardo da Vinci. Impresso por: III apreSentação Prezado (a) acadêmico (a) Bem-vindo à disciplina de Modelagem de Sistemas Empresariais. Através desta disciplina verificaremos como o caminho da modelagem se modificou nos últimos anos, para se adequar aos constantes progressos das linguagens de programação, dos sistemas operacionais, dos bancos de dados, regras de negócio cada vez mais complexas e paradigmas da programação que buscam cada vez mais agilidade. Vale lembrar que um dos assuntos mais relevantes da modelagem é que ela tem o objetivo de permitir o entendimento do projeto a qualquer pessoa da equipe, seja por parte da solicitante ou da solicitada, e em qualquer ponto do processo. Como já diz o ditado popular, “uma imagem vale mais que mil palavras”. Conheceremos na primeira unidade os modelos de processo de desenvolvimento tradicionais e os modelos evolucionários. Na sequência, na segunda unidade, verificaremos como é realizado o levantamento dos requisitos e as técnicas para essa atividade, além de entendermos como funcionam as equipes e as fases do desenvolvimento do projeto. Para finalizar, conheceremos a UML, bem como seus diagramas. E complementando os estudos, será apresentada uma atividade para consolidar os conhecimentos aprendidos na disciplina de Modelagem de Sistemas Gerenciais. Aproveito a oportunidade para destacar a importância de desenvolver as autoatividades, lembrando que essas atividades NAO SÃO OPCIONAIS. Elas objetivam a fixação dos conceitos apresentados. Em caso de dúvida na realização das atividades, sugiro que você entre em contato com seu tutor externo ou com a tutoria da UNIASSELVI, não prosseguindo as atividades sem ter sanado todas as dúvidas que irão surgindo. Bom estudo! Sucesso na sua trajetória acadêmica e profissional! Neli Miglioli Sabadin IV Você já me conhece das outras disciplinas? Não? É calouro? Enfim, tanto para você que está chegando agora à UNIASSELVI quanto para você que já é veterano, há novidades em nosso material. Na Educação a Distância, o livro impresso, entregue a todos os acadêmicos desde 2005, é o material base da disciplina. A partir de 2017, nossos livros estão de visual novo, com um formato mais prático, que cabe na bolsa e facilita a leitura. O conteúdo continua na íntegra, mas a estrutura interna foi aperfeiçoada com nova diagramação no texto, aproveitando ao máximo o espaço da página, o que também contribui para diminuir a extração de árvores para produção de folhas de papel, por exemplo. Assim, a UNIASSELVI, preocupando-se com o impacto de nossas ações sobre o ambiente, apresenta também este livro no formato digital. Assim, você, acadêmico, tem a possibilidade de estudá-lo com versatilidade nas telas do celular, tablet ou computador. Eu mesmo, UNI, ganhei um novo layout, você me verá frequentemente e surgirei para apresentar dicas de vídeos e outras fontes de conhecimento que complementam o assunto em questão. Todos esses ajustes foram pensados a partir de relatos que recebemos nas pesquisas institucionais sobre os materiais impressos, para que você, nossa maior prioridade, possa continuar seus estudos com um material de qualidade. Aproveito o momento para convidá-lo para um bate-papo sobre o Exame Nacional de Desempenho de Estudantes – ENADE. Bons estudos! UNI V VI VII SuMário UNIDADE 1 - INTRODUÇÃO AOS MODELOS DE PROCESSO TRADICIONAIS: MODELO CASCATA E INCREMENTAL E MODELOS EVOLUCIONÁRIOS: MODELO ESPIRAL E PROTOTIPAÇÃO ........................ 1 TÓPICO 1 - MODELOS DE CICLO DE VIDA .................................................................................. 3 1 INTRODUÇÃO ..................................................................................................................................... 3 2 MODELOS DE PROCESSOS PRESCRITIVOS OU TRADICIONAIS ..................................... 4 2.1 MODELO EM CASCATA ............................................................................................................... 4 2.1.1 Modelo Incremental ............................................................................................................... 7 2.1.2 Modelos de processo evolucionário .................................................................................... 9 2.1.3 Modelo Espiral ........................................................................................................................ 9 2.1.4 Prototipação ............................................................................................................................ 10 RESUMO DO TÓPICO 1........................................................................................................................ 12 AUTOATIVIDADE ................................................................................................................................. 13 TÓPICO 2 - INTRODUÇÃO A MODELAGEM ESTRUTURADA E MODELAGEM ORIENTADA A OBJETO .................................................................... 15 1 INTRODUÇÃO ..................................................................................................................................... 15 2 IMPORTÂNCIA DA MODELAGEM DE SISTEMAS .................................................................. 18 3 EVOLUÇÃO HISTÓRICA DA MODELAGEM ............................................................................. 20 3.1 MODELAGEM ESTRUTURADA ................................................................................................. 21 3.2 PARADIGMA DA ORIENTAÇÃO A OBJETO (OO) ................................................................. 23 RESUMO DO TÓPICO 2........................................................................................................................ 26 AUTOATIVIDADE ................................................................................................................................. 27 TÓPICO 3 - MÉTODO DE DESENVOLVIMENTO ÁGIL .............................................................. 29 1 INTRODUÇÃO ..................................................................................................................................... 29 2 PRECEITOS E PRINCÍPIOS ............................................................................................................... 31 2.1 FATORES HUMANOS ................................................................................................................... 32 2.2 METODOLOGIAS ÁGEIS DE DESENVOLVIMENTO DE SOFTWARE ................................ 33 2.2.1 Extreme Programming (programação extrema) XP .......................................................... 34 2.2.2 Desenvolvimento de Software Adaptativo (ASD)............................................................. 35 2.2.3 Scrum ....................................................................................................................................... 36 2.2.4 Método de Desenvolvimento de Sistemas Dinâmicos (DSDM) ...................................... 39 2.2.5 Crystal ...................................................................................................................................... 40 2.2.6 Desenvolvimento Dirigido a Funcionalidades (FDD) ...................................................... 40 2.2.7 Desenvolvimento de Software Enxuto (LSD) ....................................................................41 2.2.8 Modelagem Ágil (AM) .......................................................................................................... 41 2.2.9 Processo Unificado Ágil (AUP) ............................................................................................ 42 2.2.10 Rational Unified Process (RUP) ......................................................................................... 42 LEITURA COMPLEMENTAR ............................................................................................................... 45 RESUMO DO TÓPICO 3........................................................................................................................ 59 AUTOATIVIDADE ................................................................................................................................. 61 VIII UNIDADE 2 - ENGENHARIA DE REQUISITOS E EQUIPE DE DESENVOLVIMENTO ...... 63 TÓPICO 1 - ENGENHARIA DE REQUISITOS ................................................................................. 65 1 INTRODUÇÃO ..................................................................................................................................... 65 2 ENGENHARIA DE REQUISITOS .................................................................................................... 65 2.1 DEFININDO OS REQUISITOS...................................................................................................... 68 2.1.1 Requisitos Funcionais ............................................................................................................ 68 2.1.2 Requisitos não funcionais ..................................................................................................... 69 2.2 CRITÉRIOS PARA VALIDAÇÃO E ACEITAÇÃO DE REQUISITOS ..................................... 71 2.3 PROBLEMAS ENCONTRADOS REFERENTES A REQUISITOS ............................................ 73 2.4 ESPECIFICAÇÃO DE REQUISITOS ............................................................................................ 74 2.4.1 Especificação em Linguagem Natural ................................................................................. 76 2.4.2 Especificação Estruturada ..................................................................................................... 77 2.4.3 Documento de requisito de software .................................................................................. 79 2.4.4 Gerenciamento de requisitos ................................................................................................ 82 LEITURA COMPLEMENTAR ............................................................................................................... 83 RESUMO DO TÓPICO 1........................................................................................................................ 86 AUTOATIVIDADE ................................................................................................................................. 88 TÓPICO 2 - DESCOBERTA DE REQUISITOS .................................................................................. 91 1 INTRODUÇÃO ..................................................................................................................................... 91 2 TÉCNICAS DE LEVANTAMENTO .................................................................................................. 92 2.1 ENTREVISTA ................................................................................................................................... 93 2.1.1 Etnografia - Observação pessoal .......................................................................................... 94 2.1.2 Questionário ............................................................................................................................ 95 2.1.3 Brainstorming ........................................................................................................................... 96 2.1.4 JAD (Joint Application Design) ............................................................................................... 97 RESUMO DO TÓPICO 2........................................................................................................................ 99 AUTOATIVIDADE ................................................................................................................................. 100 TÓPICO 3 - DESENVOLVIMENTO E EQUIPE DE SOFTWARE ................................................... 101 1 INTRODUÇÃO ..................................................................................................................................... 101 2 FASES DO DESENVOLVIMENTO DE SISTEMAS ...................................................................... 101 2.1 ESTUDO DE VIABILIDADE ......................................................................................................... 102 2.1.1 Análise...................................................................................................................................... 103 2.1.2 Projeto ...................................................................................................................................... 104 2.1.3 Implementação ....................................................................................................................... 105 2.1.4 Implantação ............................................................................................................................. 105 2.2 GERENCIAMENTO DE PROJETOS ............................................................................................ 105 2.3 EQUIPE DE DESENVOLVIMENTO ............................................................................................. 107 2.3.1 Gerente ..................................................................................................................................... 108 2.3.2 Analistas .................................................................................................................................. 109 2.3.3 Projetistas ................................................................................................................................. 110 2.3.4 Arquitetos de software .......................................................................................................... 110 2.3.5 Programadores ....................................................................................................................... 112 LEITURA COMPLEMENTAR ............................................................................................................... 113 RESUMO DO TÓPICO 3........................................................................................................................ 116 AUTOATIVIDADE ................................................................................................................................. 117 UNIDADE 3 - REVISÃO DE CONCEITOS DA UML, DIAGRAMAS DE VISÃO COMPORTAMENTAL E ESTRUTURAL E UM DETALHAMENTO NOS CASOS DE USO ................................................................................................... 119 IX TÓPICO 1 - UML (UNIFIED MODELING LANGUAGE) .............................................................. 121 1 INTRODUÇÃO ..................................................................................................................................... 121 2 MODELO CONCEITUAL DA UML ................................................................................................. 121 2.1 BLOCOS DE CONSTRUÇÃO BÁSICOS DA UML .................................................................... 122 2.1.1 Itens estruturais ..................................................................................................................... 122 2.1.2 Itens comportamentais ..........................................................................................................124 2.1.3 Itens de agrupamento ............................................................................................................ 125 2.1.4 Itens anotacionais ................................................................................................................... 125 2.2 RELACIONAMENTOS NA UML................................................................................................. 125 RESUMO DO TÓPICO 1........................................................................................................................ 127 AUTOATIVIDADE ................................................................................................................................. 128 TÓPICO 2 - DIAGRAMAS DA UML: DIAGRAMAS ESTRUTURAIS E COMPORTAMENTAIS ................................................................................................ 129 1 INTRODUÇÃO ..................................................................................................................................... 129 2 DIAGRAMAS ........................................................................................................................................ 129 2.1 DIAGRAMAS ESTRUTURAIS ...................................................................................................... 131 2.1.1 Diagrama de Objetos ............................................................................................................. 131 2.1.2 Diagrama de Estrutura Composta ....................................................................................... 132 2.1.3 Diagrama de Classes .............................................................................................................. 134 2.1.4 Diagrama de Pacotes .............................................................................................................. 135 2.2 DIAGRAMAS COMPORTAMENTAIS ........................................................................................ 136 2.2.1 Diagramas de atividade ........................................................................................................ 136 2.2.2 Diagramas de Caso de Uso ................................................................................................... 137 2.2.3 Diagrama de Transição de Estados...................................................................................... 138 2.3 DIAGRAMAS DE INTERAÇÃO ................................................................................................... 139 2.3.1 Diagrama de Sequência ......................................................................................................... 139 2.3.2 Diagrama de Temporização .................................................................................................. 140 2.3.3 Diagrama de Comunicação ................................................................................................... 140 2.3.4 Diagrama de Visão Geral de Interação ............................................................................... 141 2.4 DIAGRAMAS DE IMPLEMENTAÇÃO ....................................................................................... 142 2.4.1 Diagrama de Componentes .................................................................................................. 142 2.4.2 Diagrama de Implantação ..................................................................................................... 143 RESUMO DO TÓPICO 2........................................................................................................................ 145 AUTOATIVIDADE ................................................................................................................................. 147 TÓPICO 3 - MODELO DE CASO DE USO ........................................................................................ 149 1 INTRODUÇÃO ..................................................................................................................................... 149 2 CASO DE USO ...................................................................................................................................... 150 3 ATORES .................................................................................................................................................. 150 4 FLUXO DE EVENTOS ......................................................................................................................... 151 5 RELACIONAMENTO .......................................................................................................................... 152 5.1 RELACIONAMENTO ENTRE ATORES ...................................................................................... 152 5.2 ATOR X CASO DE USO ................................................................................................................. 152 5.3 INCLUSÃO E EXTENSÃO ............................................................................................................ 153 5.4 EXTENSÃO ...................................................................................................................................... 154 6 GENERALIZAÇÃO .............................................................................................................................. 156 RESUMO DO TÓPICO 3........................................................................................................................ 158 AUTOATIVIDADE ................................................................................................................................. 159 TÓPICO 4 - DIAGRAMA DE CLASSE ............................................................................................... 161 1 INTRODUÇÃO ..................................................................................................................................... 161 X 2 DIAGRAMAS DE CLASSE ................................................................................................................ 161 LEITURA COMPLEMENTAR ............................................................................................................... 165 RESUMO DO TÓPICO 4........................................................................................................................ 174 AUTOATIVIDADE ................................................................................................................................. 175 TÓPICO 5 - DIAGRAMA DE SEQUÊNCIA ...................................................................................... 177 1 INTRODUÇÃO ..................................................................................................................................... 177 2 TIPOS DE MENSAGEM ..................................................................................................................... 177 2.1 NOTAÇÃO DO DIAGRAMA DE SEQUÊNCIA ........................................................................ 178 LEITURA COMPLEMENTAR ............................................................................................................... 180 RESUMO DO TÓPICO 5........................................................................................................................ 188 AUTOATIVIDADE ................................................................................................................................. 189 REFERÊNCIAS ......................................................................................................................................... 190 1 UNIDADE 1 INTRODUÇÃO AOS MODELOS DE PROCESSO TRADICIONAIS: MODELO CASCATA E INCREMENTAL E MODELOS EVOLUCIONÁRIOS: MODELO ESPIRAL E PROTOTIPAÇÃO OBJETIVOS DE APRENDIZAGEM PLANO DE ESTUDOS Esta unidade tem por objetivos: • introdução aos conceitos de ciclo de vida; • modelagem orientada e estruturada; • conhecimento dos modelos ágeis de desenvolvimento. Esta unidade de ensino contém trêstópicos. No final de cada um deles você encontrará atividades que contribuirão para a apropriação dos conteúdos. TOPICO 1 – MODELOS DE CICLO DE VIDA TÓPICO 2 – INTRODUÇÃO À MODELAGEM ESTRUTURADA E MODELAGEM ORIENTADA A OBJETO TÓPICO 3 – METÓDO DE DESENVOLVIMENTO ÁGIL 2 3 TÓPICO 1UNIDADE 1 MODELOS DE CICLO DE VIDA 1 INTRODUÇÃO A existência de um sistema de informação passa por um processo conhecido como Ciclo de Vida, com três estágios bastante conhecidos pelo analista de sistema: concepção, desenvolvimento e vida útil. De acordo com Silva (2014, p. 28), o nome de cada fase da vida de um sistema pode sofrer variações, mas, na sua essência, nada muda. Como vemos na definição: Existe um encadeamento específico dessas fases, para a construção do sistema dá-se o nome de Ciclo de vida. O processo de software é o conjunto de atividades que constituem o desenvolvimento de um sistema computacional. Estas atividades são agrupadas em fases, como: • Definição de requisitos, • Análise, projeto, • Desenvolvimento, • Teste e implantação. Cada fase do desenvolvimento de software é definida. Além das suas atividades, as funções e responsabilidades de cada membro da equipe, e, como produto resultante, os artefatos. Como tudo que dá certo se repete, no mercado de software ocorre o mesmo. Repetiram-se as práticas que ofereceram resultados positivos. E a formalização em modelos de ciclo de vida. Em outras palavras, os modelos de Ciclo de Vida são o esqueleto ou as estruturas predefinidas, nas quais encaixamos as fases do processo. De acordo com Macêdo e Spínola (2016), a NBR ISO/IEC 12207:1998, o Ciclo de Vida é a “Estrutura contendo processos, atividades e tarefas envolvidas no desenvolvimento, operação e manutenção de um produto de software, abrangendo a vida do sistema desde a definição de seus requisitos, até o término de seu uso”. O modelo de Ciclo de Vida é a primeira escolha a ser feita no processo de software, e a partir desta escolha definir-se-á desde a maneira mais adequada para obter as necessidades do cliente, até quando e como o cliente receberá sua primeira versão operacional do sistema. Vale ressaltar que não existe um modelo ideal. O perfil e complexidade do empreendimento do cliente, o tempo disponível, o custo, a equipe, o ambiente operacional são fatores que influenciarão diretamente na escolha do Ciclo de Vida de software a ser adotado. Da mesma forma, também é difícil uma empresa adotar somente um Ciclo de Vida no processo. Os ciclos de vida se comportam de maneira sequencial (fases seguem determinada ordem) e/ou incremental (divisão de escopo) e/ou iterativa (retroalimentação de fases) e/ou evolutiva (software é aprimorado). UNIDADE 1 | INTRODUÇÃO AOS MODELOS DE PROCESSO TRADICIONAIS: MODELO CASCATA E INCREMENTAL E MODELOS EVOLUCIONÁRIOS: MODELO ESPIRAL E PROTOTIPAÇÃO 4 Não existe uma regra, a escolha de um modelo de processo depende muito das características do projeto. Para escolher o modelo mais adequado é importante conhecer alguns modelos de Ciclo de Vida e as situações em que são aplicáveis. 2 MODELOS DE PROCESSOS PRESCRITIVOS OU TRADICIONAIS Originalmente, modelos prescritivos foram propostos para trazer ordem ao caos existente na área de desenvolvimento de software. Segundo Pressman (2011, p.58), esses modelos proporcionavam uma contribuição quanto à estrutura utilizável no trabalho de engenharia de software e forneceram um roteiro razoavelmente eficaz para as equipes deste. 2.1 MODELO EM CASCATA Também chamado de “modelo de ciclo de vida clássico”, o Modelo em Cascata organiza as atividades do processo de desenvolvimento de forma sequencial, como mostra a Figura 1. Uma característica desse modelo é que cada fase resulta na elaboração de um ou mais documentos, que devem ser aprovados antes de se iniciar a fase seguinte. Ou seja, uma fase só será iniciada após a conclusão daquela que a precede. Uma vez que, na prática, essas fases se sobrepõem de alguma forma, geralmente permite-se um retorno à fase anterior para a correção de erros encontrados. O resultado final, ou melhor, a entrega do sistema completo ocorre de uma única vez, ao final da fase de Entrega e Implantação. No Modelo em Cascata, todo o projeto deve ser entendido em suas fases iniciais, seguindo até o final com pouquíssima interação com o cliente. TÓPICO 1 | MODELOS DE CICLO DE VIDA 5 FIGURA 1 - MODELO EM CASCATA FONTE: Disponível em: <http://www.inf.ufes.br/~monalessa/PaginaMonalessa- NEMO/ ES_Mestrado/Artigos/ProcessoDeSoftware.pdf> Acesso em: 23 fev. 2016 Os principais estágios do Modelo em Cascata refletem diretamente as atividades fundamentais do desenvolvimento, segundo Sommerville (2011, p. 20): 1. Análise e definição de requisitos: Os serviços, restrições e metas do sistema são estabelecidos por meio de consulta aos usuários. Em seguida, são definidos em detalhes e funcionam como uma especificação do sistema. 2. Projeto de sistema e software: O processo de projeto de sistemas aloca os requisitos tanto para sistemas de hardware como para sistemas de software, por meio de definição de uma arquitetura geral do sistema. O projeto de software envolve a identificação e descrição das abstrações fundamentais do sistema de software e seus relacionamentos. 3. Implementação e teste unitário: Durante esse estágio, o projeto do software é desenvolvido como um conjunto de programas ou unidades de programa. O teste unitário envolve a verificação de que cada unidade atende à sua especificação. 4. Integração e teste de sistema: As unidades individuais do programa ou programas são integradas e testadas como um sistema completo, para assegurar que os requisitos do software tenham sido atendidos. Após o teste o sistema de software é entregue ao cliente. No capítulo 2- Detalharemos os tipos de requisitos e técnicas de levantamento de requisitos. ESTUDOS FU TUROS UNIDADE 1 | INTRODUÇÃO AOS MODELOS DE PROCESSO TRADICIONAIS: MODELO CASCATA E INCREMENTAL E MODELOS EVOLUCIONÁRIOS: MODELO ESPIRAL E PROTOTIPAÇÃO 6 5. Operação e manutenção: Normalmente (embora não necessariamente), essa é a fase mais longa do ciclo de vida. O sistema é instalado e colocado em uso. A manutenção envolve a correção de erros que não foram descobertos em estágios iniciais do ciclo de vida, com melhora da implementação das unidades do sistema e ampliação de seus serviços em resposta às descobertas de novos requisitos. Existe uma variação do Modelo em Cascata que é chamado de modelo V. Nesse modelo, procura-se enfatizar a estreita relação entre as atividades de teste (teste de unidade, teste de integração, teste de sistema e teste de aceitação) e as demais fases do processo. Pressman (2011) explica que à medida que a equipe de software desce em direção ao lado esquerdo do V, os requisitos básicos do problema são refinados em representações progressivamente cada vez mais detalhadas e técnicas do problema e de sua solução. Como mostra a Figura 2. FIGURA 2 - MODELO V FONTE: Adaptado de Pressman (2011, p. 60) TÓPICO 1 | MODELOS DE CICLO DE VIDA 7 O Modelo em Cascata é o modelo mais antigo na engenharia de software, e nos últimos anos recebeu várias críticas, conforme relatadas por Pressman (2011, p. 61): • Projetos reais raramente seguem o fluxo sequencial que o modelo propõe. Embora o modelo linear possa conter interações, ele o faz indiretamente. Como consequência, mudanças podem provocar confusão à medida que a equipe de projeto prossegue. • Frequentemente, é difícil para o cliente estabelecer explicitamente todas as necessidades. O modelo em cascata requer isso e tem dificuldade para adequar a incerteza natural que existe no início de muitos projetos. • O cliente deve ter paciência. Uma versão operacional do(s) programa(s) não estará disponível antes de estarmos próximo do final do projeto. Um erro grave, se não detectado até o programa operacional ser revisto, pode ser desastroso. 2.1.1 Modelo IncrementalNem todos os projetos que conseguem ter todos os requisitos são razoavelmente bem definidos, e devido ao tamanho do sistema a ser desenvolvido, isso torna impossível a adoção de um modelo sequencial, especialmente pela necessidade de disponibilizar uma versão para o usuário rapidamente. Para esses casos o Modelo Incremental é o mais indicado, como detalharemos. Pressman (2011) diz que o Modelo Incremental combina elementos dos fluxos de processos lineares e paralelos. A Figura 3 ilustra esses modelos. UNIDADE 1 | INTRODUÇÃO AOS MODELOS DE PROCESSO TRADICIONAIS: MODELO CASCATA E INCREMENTAL E MODELOS EVOLUCIONÁRIOS: MODELO ESPIRAL E PROTOTIPAÇÃO 8 FIGURA 3 - MODELO INCREMENTAL FONTE: Pressman (2011, p. 54) O princípio fundamental desse modelo é que, seja iteração ou ciclo, uma versão operacional do sistema é gerada e entregue para avaliação e uso detalhado do cliente. Para que isso aconteça, os requisitos têm que ser levantados detalhadamente e há de se constatar que o sistema é modular, de modo que se possa planejar o desenvolvimento em incrementos. O primeiro incremento, tipicamente, contém funcionalidades centrais, tratando dos requisitos básicos. A cada ciclo, novas funcionalidades são adicionadas e as funcionalidades providas anteriormente podem ser modificadas para melhor satisfazer às necessidades dos clientes/ usuários. Outras características são tratadas em ciclos subsequentes. Dependendo do tempo estabelecido para a liberação dos incrementos, algumas atividades podem ser feitas para o sistema como um todo ou não. TÓPICO 1 | MODELOS DE CICLO DE VIDA 9 2.1.2 Modelos de processo evolucionário Pressman (2011) afirma que o software, assim como todos os sistemas complexos, evolui ao longo do tempo e, conforme o desenvolvimento deste software avança, temos mudanças nas necessidades de negócio e de produtos, uma vez que mudam frequentemente. Isso torna inadequado seguirmos um planejamento em linha reta de determinado produto. Muitas vezes, os prazos reduzidos, a necessidade de atender à pressão comercial e até mesmo da concorrência e em outras situações como essas ou similares, faz-se necessário um modelo de processo que tenha sido projetado especificamente para desenvolver um produto que evolua ao longo do tempo. Modelos Evolucionários são caracterizados por serem iterativos e apresentarem características que possibilitem desenvolvermos versões cada vez mais completas do software. Os Processos Evolucionários se caracterizam por dois modelos comuns: Prototipação e Espiral. 2.1.3 Modelo Espiral O Modelo Espiral foi originalmente proposto por Boehm em 1988. Para definir esse modelo de uma maneira mais simples, basta analisa-lo como um Modelo em Cascata, onde cada fase é precedida por uma análise de risco e sua execução é feita evolucionariamente (ou incrementalmente). Neste modelo de desenvolvimento é possível avaliar riscos de projeto, tomando-se decisões baseadas na experimentação de diferentes soluções. Para entendermos melhor, veja a Figura 4. A dimensão radial representa o custo acumulado atualizado e a dimensão angular representa o progresso através da espiral. Cada setor da espiral corresponde a uma tarefa (fase) do desenvolvimento. No modelo original foram propostas quatro tarefas (fases ou quadrantes) onde, por exemplo, na primeira volta pode gerar como resultado a especificação do produto, na espiral subsequente o resultado pode ser o protótipo, e nas voltas seguintes podem ser relativos a versões aprimoradas do sistema (PRESSMAN, 2008, p.38). UNIDADE 1 | INTRODUÇÃO AOS MODELOS DE PROCESSO TRADICIONAIS: MODELO CASCATA E INCREMENTAL E MODELOS EVOLUCIONÁRIOS: MODELO ESPIRAL E PROTOTIPAÇÃO 10 FIGURA 4 - MODELO ESPIRAL FONTE: Pressman (2011, p. 65) 2.1.4 Prototipação Em relação a esse paradigma, Pressman (2011) afirma que, embora possa ser utilizada como um modelo de processo isolado (stand-alone-process), é mais comumente utilizada como uma técnica passível de ser implementada no contexto de qualquer um dos modelos apresentados. Ele explica o funcionamento deste paradigma de maneira reduzida. Na fase de comunicação, faz-se uma reunião com os envolvidos para definir os objetivos gerais do software, identificar quais requisitos já são conhecidos e esquematizar quais áreas necessitam, obrigatoriamente, de uma definição mais ampla. Uma interação de prototipação é planejada rapidamente e ocorre a modelagem (na forma de um “projeto rápido”). Durante a fase de modelagem do projeto rápido: se concentra em uma representação daqueles aspectos do software que serão visíveis aos usuários finais, como, por exemplo, o layout da interface com o usuário ou formatos de exibição na tela. E, finalmente, a construção de um protótipo: Nesta fase é feita a construção do protótipo, que é empregado e avaliado, conforme vemos na Figura 5. TÓPICO 1 | MODELOS DE CICLO DE VIDA 11 FIGURA 5 - PROTOTIPAÇÃO FONTE: Pressman (2011, p. 63) Sommerville (2011, p. 31) alerta que, às vezes, os desenvolvedores são pressionados pelos gerentes para entregar protótipos descartáveis, especialmente quando há atrasos na entrega da versão final do software. No entanto, isso costuma ser desaconselhável: 1. Pode ser impossível ajustar o protótipo para atender aos requisitos não funcionais, como requisitos de desempenho, proteção, robustez e confiabilidade, que foram ignorados durante o desenvolvimento do protótipo. 2. Mudanças rápidas durante o desenvolvimento inevitavelmente significam que o protótipo não está documentado. A única especificação do projeto é o código do protótipo. Para a manutenção a longo prazo, isso não é bom o suficiente. 3. As mudanças durante o desenvolvimento do protótipo provavelmente terão degradado a estrutura do sistema. O sistema será difícil e custoso de ser mantido. 4. Padrões de qualidade organizacional geralmente são relaxados para o desenvolvimento do protótipo. 12 Neste tópico, vimos: • Um breve contato com conceitos e modelos relacionados ao processo de desenvolvimento de software. • Modelos de processos prescritivos ou tradicionais: Modelo em Cascata e Modelo Incremental e um resumo das fases. • Modelos de processo evolucionário: Modelo espiral e Prototipação. RESUMO DO TÓPICO 1 13 1 Qual deve ser a primeira escolha a ser feita no processo de software? 2 Projetos reais raramente seguem o fluxo sequencial que o modelo propõe. Embora o modelo linear possa conter interações, ele o faz indiretamente. Como consequência, mudanças podem provocar confusão à medida que a equipe de projeto prossegue. Essa é uma crítica que vem sendo apresentada referente a qual modelo de desenvolvimento? 3 Quando se começa um projeto, nem todos conseguem ter todos os requisitos razoavelmente bem definidos, e devido ao tamanho do sistema a ser desenvolvido, isso torna impossível a adoção de qual modelo? E qual modelo pode ser sugerido? 4 Preencha de acordo com a definição das fases de desenvolvimento: AUTOATIVIDADE Normalmente (embora não necessariamente), essa é a fase mais longa do Ciclo de Vida. O sistema é instalado e colocado em uso. A manutenção envolve a correção de erros que não foram descobertos em estágios iniciais do Ciclo de Vida, com melhora da implementação das unidades do sistema e ampliação de seus serviços em resposta às descobertas de novos requisitos. O processo de projeto de sistemas aloca os requisitos tanto para sistemas de hardware como para sistemas de software, por meio de definição de uma arquitetura geral do sistema. O projeto de software envolve a identificação e descrição das abstrações fundamentais do sistema de software e seus relacionamentos. Os serviços, restrições e metas do sistema são estabelecidos por meio de consulta aos usuários. Em seguida, são definidos em detalhes e funcionam como uma especificação do sistema. As unidades individuais do programa ou programas são integradas e testadas como um sistema completo, para assegurar que os requisitosdo software tenham sido atendidos. Após o teste, o sistema de software é entregue ao cliente. Durante esse estágio, o projeto do software é desenvolvido como um conjunto de programas ou unidades de programa. O teste unitário envolve a verificação de que cada unidade atende à sua especificação. 14 5 Qual é o modelo ideal que se aplica à maioria dos projetos de software? 6 A definição de que, embora possa ser utilizada como um modelo de processo isolado (stand-alone-process), é mais comumente utilizada como uma técnica passível de ser implementada no contexto de qualquer um dos modelos apresentados, se refere a qual modelo de desenvolvimento? 15 TÓPICO 2 INTRODUÇÃO A MODELAGEM ESTRUTURADA E MODELAGEM ORIENTADA A OBJETO UNIDADE 1 1 INTRODUÇÃO Se pedissem para você desenhar ou procurar na internet um item bem específico: Uma cadeira com bolinhas amarela e confortável. A princípio não parece ser um pedido muito difícil, certo? Mas, qual das cadeiras era a solicitada? FIGURA 6 - CADEIRA DE BOLINHA FONTE: Disponível em: <http://arquitetura-tamiris.blogspot. com/2011/03/cadeira-de-bolinha-amarelinhaa.html>. Acesso em: 22 mar. 2016. 16 UNIDADE 1 | INTRODUÇÃO AOS MODELOS DE PROCESSO TRADICIONAIS: MODELO CASCATA E INCREMENTAL E MODELOS EVOLUCIONÁRIOS: MODELO ESPIRAL E PROTOTIPAÇÃO FIGURA 7- CADEIRA DE BOLINHA FONTE: Disponível em: <http://revistacasaejardim.globo.com/Revista/ Common/0,,ERT75860-16940,00.html>. Acesso em: 22 mar. 2016. Isso foi apenas uma maneira de ilustrar a dificuldade de atender aos requisitos. Mas se foi tão difícil para um item tão simples como uma cadeira, imagine para o sistema de uma empresa. Para ajudar nessa tarefa, têm-se os modelos, que são uma visualização dos requisitos, bem como o desejo do cliente do que deve ser implementado. Juntos, eles auxiliam no entendimento do que o cliente solicitou e do que a equipe deve desenvolver. O ponto mais importante do desenvolvimento de um sistema é compreender as necessidades e desejos do usuário e da organização e visualizar os benefícios que serão obtidos com esse sistema, mas se isso não for bem entendido, os requisitos e as atividades relacionadas ao seu desenvolvimento não terão significado algum. O termo modelagem já sugere a criação de um modelo, a elaboração de um esboço do que se pretende fazer, por meio de um gráfico, um desenho, antes de começar a construção propriamente dita. Essa atividade abrange vários segmentos, pode ser uma casa, um carro, um vestido ou até mesmo um software. Abaixo há alguns esboços de coisas bem diferentes, mas que seguem a mesma linha de raciocínio. 17 TÓPICO 2 | INTRODUÇÃO A MODELAGEM ESTRUTURADA E MODELAGEM ORIENTADA A OBJETO FIGURA 8- MODELO CASA FONTE: Disponível em: < http://www.tudoconstrucao.com/10-modelos- de-plantas-de-casas-para-2015/>. Acesso em: 22 mar. 2016. FIGURA 9- MODELO CARRO FONTE: Disponível em: < http://pt.dreamstime.com/fotos-de-stock- royalty-free-desenho-do-carro-image7844748>. Acesso em: 22 mar. 2016. FIGURA 10- MODELO VESTIDO FONTE: Disponível em: <http://vida-estilo.estadao.com.br/ noticias/moda,veja-quais-sao-os-vestidos-de-casamento-mais- iconicos-de-todos-os-tempos,1786989>. Acesso em: 22 mar. 2016. 18 UNIDADE 1 | INTRODUÇÃO AOS MODELOS DE PROCESSO TRADICIONAIS: MODELO CASCATA E INCREMENTAL E MODELOS EVOLUCIONÁRIOS: MODELO ESPIRAL E PROTOTIPAÇÃO É durante a fase de modelagem que o autor do projeto, independentemente do tipo, prepara um “modelo” com todos os requisitos, funcionalidade ou características, que o seu cliente ou usuário solicitou. Nesse modelo apresentam-se a estrutura e o comportamento do sistema que será desenvolvido, enxergando seu funcionamento. Durante essa fase é possível verificar com o usuário se o modelo proposto atende às suas necessidades, conforme os requisitos informados. A criação de modelos é de suma importância para o entendimento do projeto como um todo. 2 IMPORTÂNCIA DA MODELAGEM DE SISTEMAS Pode-se construir uma casa para um cachorro apenas juntando algumas tábuas, alguns pregos e algumas ferramentas básicas. Com um planejamento mínimo, em poucas horas e com um pouco de habilidade, nosso cachorro terá uma casa (BOOCH et al., 2000). FIGURA 11 - CASA DE CACHORRO FONTE: Disponível em: <http://bioretro.eco.br/lar-cao-tambem-sustentavel/>. Acesso em: 23 fev. 2016. Ainda segundo o autor, se o plano for construir a casa para sua família, com certeza uma pequena pilha de tábuas e alguns pregos não será o suficiente, pois, com certeza, sua família será um pouco mais exigente que o seu cachorro. Para fazer a sua casa, antes de sair batendo o primeiro prego é necessário que você saiba o que 19 TÓPICO 2 | INTRODUÇÃO A MODELAGEM ESTRUTURADA E MODELAGEM ORIENTADA A OBJETO sua família espera, será melhor fazer um planejamento bem detalhado de como será essa construção. Fazer alguns desenhos e verificar todos os procedimentos para garantir a segurança da edificação. Durante esse detalhamento, você verá que é muito difícil construir uma casa sozinho, e que terá que ter uma equipe para auxiliar, com cada membro da equipe sabendo o que deve desempenhar. Se tudo correr bem e o modelo for seguido, provavelmente, ao final do projeto, sua família ficará satisfeita. Vale ressaltar que, para não gerar frustrações ao final do projeto, é muito importante definir as expectativas desde o início. FIGURA 12 - CASA SEM PROJETO FONTE: Disponível em: <http://atl.clicrbs.com.br/mundoidao/2008/08/26/ casa-e-construida-de-cabeca-para-baixo/> Acesso em: 23 fev. 2016. Agora, se você não quer construir software equivalente a uma casa, Booch et al. (2000) advertem que o segredo estará em criar o código correto e pensar em como será possível elaborar menos software. Isso faz com que o desenvolvimento de programa de qualidade se torne uma questão de arquitetura, processo e ferramentas. Para uma empresa de software ter sucesso, existem vários elementos que contribuem para isso, um deles é a utilização da modelagem. Ainda segundo Booch et al. (2000, p.6) constroem-se modelos para compreender melhor o sistema que estamos desenvolvendo. E com ela é possível alcançar quatro objetivos: • Os modelos ajudam a visualizar o sistema como ele é ou como desejamos que seja. • Os modelos permitem especificar a estrutura ou o comportamento de um sistema. • Os modelos proporcionam um guia para a construção do sistema. • Os modelos documentam as decisões tomadas. Vale ressaltar que a modelagem não se restringe apenas a grandes sistemas. Ainda de acordo com Booch et al. (2000), softwares pequenos, equivalentes a uma casa de cachorro, poderão receber os benefícios da modelagem, porém é verdade que quanto maior e mais complexo o sistema, maior será a importância da modelagem, por um motivo bem simples, que não é possível compreendê-los em sua totalidade. 20 UNIDADE 1 | INTRODUÇÃO AOS MODELOS DE PROCESSO TRADICIONAIS: MODELO CASCATA E INCREMENTAL E MODELOS EVOLUCIONÁRIOS: MODELO ESPIRAL E PROTOTIPAÇÃO 3 EVOLUÇÃO HISTÓRICA DA MODELAGEM Bezerra (2015) apresenta um breve resumo histórico da evolução das técnicas de desenvolvimento, para explicar como chegamos ao cenário atual. Décadas de 1950/1960: Os sistemas eram bem simples, e o seu desenvolvimento era direto ao assunto, não tinha um planejamento inicial, como dizem, “ad hoc”. Como os sistemas eram significativamente mais simples, as técnicas de modelagem também: Eram usados fluxogramas e diagramas de módulos. Década de 1970: Começaram a surgir computadores mais avançados e acessíveis. Houve grande ampliação do mercado computacional. Sistemas mais complexos começavam a surgir. Consequentemente, modelos mais robustos foram propostos. Os autores Larry Constantine e Edward Yourdon são grandes colaboradores nessas técnicas. Década de 1980: Nessa fase os computadores se tornaram ainda mais avançados e mais baratos. Surge a necessidade por interfaces mais sofisticadas, o que originoua produção de sistemas de softwares mais complexos. A Análise Estruturada surgiu no início desse período, com os trabalhos de Edward Yourdon, Peter Coad, Tom De Marco, James Martin e Chris Gane. Década de 1990: No início dessa década é o período em que surge um novo paradigma de modelagem, a Análise Orientada a Objetos, como resposta a dificuldades encontradas na aplicação da análise estruturada em algumas aplicações. Grandes colaboradores desse paradigma são Sally Shlaer, Stephen Mellor, Rebecca Wirfs-Brock, James Rumbaugh, Grady Booch e Ivar Jacobson. Já no fim da década, o paradigma da orientação a objetos atinge sua maturidade. Os conceitos de padrões de projeto, frameworks, componentes e qualidade começam a ganhar espaço. Surge a Linguagem de Modelagem Unificada UML. Década de 2000: O reúso por meio de padrões de projetos e frameworks se solidifica. As denominadas metodologias ágeis começam a ganhar espaço. Técnicas de testes automatizados e refatoração começaram a se difundir entre os desenvolvedores que trabalham com orientação a objeto. Grandes nomes dessa fase são: Rebecca Wirfs-Brock, Martin Fowler e Eric Vans. Como percebemos, durante a década de 90 surgiram várias propostas e técnicas para modelagem de sistema segundo o paradigma da orientação a objeto. Era comum, durante essa década, duas técnicas possuírem diferentes notações gráficas para modelar a mesma perspectiva de um sistema. Todas tinham pontos fortes e fracos em relação à notação utilizada, mas via-se a necessidade de uma notação que viesse a se tornar um padrão para a modelagem de sistemas orientados a objeto, e que fosse amplamente aceita, nas indústrias e na academia. 21 TÓPICO 2 | INTRODUÇÃO A MODELAGEM ESTRUTURADA E MODELAGEM ORIENTADA A OBJETO FONTE: Disponível em: <https://www.passeidireto.com/arquivo/19056116/principios-de-analise- e-projeto---eduardo-bezerra/7>. Acesso em: 11 abr. 2016. Alguns esforços surgiram em 1996 para essa padronização, o que resultou na definição da UML (Unified Modeling Language), que detalharemos a seguir em um tópico específico, mas antes falaremos na Modelagem Estruturada e da Modelagem Orientada a Objetos. 3.1 MODELAGEM ESTRUTURADA A modelagem estruturada teve seu início na década de 1970, com uma abordagem bem sistemática, utilizando técnicas de construção de modelos. O seu princípio é a divisão em módulos e submódulos. Ele é de fácil utilização, especialmente por ser diagrama de fácil compreensão e minimização, a lacuna de conhecimento, muitas vezes, existente entre os analistas e os usuários. A sua documentação é feita através dos diagramas de fluxo de dados (DFD), Diagrama de entidade-relacionamento (DER). O Diagrama de fluxo de dados tem como objetivo representar graficamente o fluxo dos dados, normalmente usados para apresentar uma visão geral do sistema, onde podemos verificar a entrada e saída das informações e onde os dados serão armazenados. Entidades Externas: São categorias lógicas de objetos ou pessoas que representam Origem ou destino de dados, e que acionam um sistema e/ou recebem informações. Podem ser pessoas, sistemas ou unidades departamentais, segundo Rezende (2005, p.170). Fluxo de dados: Representa um processo de transformação de dados, é o meio por onde os dados e as informações trafegam, eles sempre envolvem um processo, sua representação é um retângulo com cantos arredondados; Processos: Transformam fluxos de dados em uma atividade, ou seja, são as atividades que transformam as entradas, transportam dados de processo a processo, armazena os dados, e produz as saídas de um sistema. Depósito de dados: São locais de armazenamento de dados, são arquivos físicos. 22 UNIDADE 1 | INTRODUÇÃO AOS MODELOS DE PROCESSO TRADICIONAIS: MODELO CASCATA E INCREMENTAL E MODELOS EVOLUCIONÁRIOS: MODELO ESPIRAL E PROTOTIPAÇÃO FIGURA 13- SUBSISTEMAS DE FATURAMENTO FONTE: Rezende (1997, p. 109) Diagrama entidade-relacionamento (DER): O principal propósito do DER é representar os objetos de dados e suas relações, sendo que cada entidade termina representada pelo menos por uma tabela de dados, e normalmente expressa por um depósito de dados do DFD. Os objetos de dados são representados por retângulos rotulados e os relacionamentos são indicados por losangos, e as conexões entre os dados e os relacionamentos são estabelecidos usando-se uma série de linhas e ligações especiais. 23 TÓPICO 2 | INTRODUÇÃO A MODELAGEM ESTRUTURADA E MODELAGEM ORIENTADA A OBJETO FIGURA 14- ELEMENTOS E SÍMBOLOS DER FIGURA 15- EXEMPLO DE DIAGRAMA DER FONTE: Disponível em: < http://www.devmedia.com.br/artigo-sql-magazine-61-modelagem- de-dados-para-um-sistema-de-controle-de-orcamento/11726>. Acesso em: 23 fev. 2016. 3.2 PARADIGMA DA ORIENTAÇÃO A OBJETO (OO) Uma forma mais eficiente de pensar em modelagem e desenvolvimento de projetos é a Proposta Orientada a Objetos, que organiza os problemas em torno de situações reais, como elas realmente acontecem na prática, e isso impõe uma forma completamente diferente de pensar e organizar a solução, se comparado à forma como o pensamento estruturado apresenta esta. (BOOCH, 1994). Inicialmente é importante definir a palavra paradigma. Pode-se dizer, então, que o termo “paradigma da orientação a objetos” é uma forma de abordar um problema. Segundo Bezerra (2015, p. 5): 24 UNIDADE 1 | INTRODUÇÃO AOS MODELOS DE PROCESSO TRADICIONAIS: MODELO CASCATA E INCREMENTAL E MODELOS EVOLUCIONÁRIOS: MODELO ESPIRAL E PROTOTIPAÇÃO Há alguns anos, Alan Kay, um dos pais do paradigma a orientação a objetos, formulou a chamada “analogia biológica”. Por meio dela, ele imaginou um sistema de software que funcionasse como um ser vivo. Nesse sistema, cada “célula” interagiria com outras células através do envio de mensagens com o propósito de realizar um objetivo comum. Além disso, cada célula se comportaria como uma unidade autônoma. Ele pensou em construir um sistema de software a partir de agentes autônomos que interagem entre si. E estabeleceu os seguintes princípios da orientação a objetos Kay apud Bezerra (2005, p 6). 1. Qualquer coisa é um objeto. 2. Objetos realizam tarefas por meio da requisição de serviços a outros objetos. 3. Cada objeto pertence a uma determinada classe. Uma classe agrupa objetos similares. 4. A classe é um repositório para comportamento associado ao objeto. 5. Classes são organizadas em hierarquia. Pode-se concluir que a Orientação a Objeto como técnica para modelagem de sistemas diminui a diferença semântica entre a realidade que está sendo modelada e os modelos construídos. A visão contemporânea no desenvolvimento de software, segundo Booch et al. (2000), adota uma perspectiva orientada a objeto. Nessa visão, o principal bloco de construção de todos os sistemas de software é o objeto ou classe. Objeto é alguma coisa geralmente estruturada a partir do vocabulário do espaço ou problema ou do espaço da solução. E uma Classe é a descrição de um conjunto de objetos comuns. Todos os objetos têm uma identidade. É possível atribuir nomes ou diferenciá-los de alguma maneira. Um estado (costuma haver dados a eles relacionados) e um comportamento, que indica que você pode fazer algo com o objeto ou ele poderá fazer algo com outros objetos. Entre as ideias fundamentais básicas para a tecnologia orientada a objeto temos: • Objetos. • Classes. • Métodos. • Herança. • Encapsulamento. Objetos: Cada conceito é uma ideia ou um entendimento coletivo que temos do nosso mundo. Os conceitos que adquirimos nos permitem dar sentido sobre as coisas do nosso mundo. Essas coisas às quais nossos conceitos se aplicam são denominados objetos. Um objeto pode ser real ou abstrato. • Os objetos possuem informações (contêm dados) e desempenham ações (possuem funcionalidade). 25 TÓPICO 2 | INTRODUÇÃO A MODELAGEM ESTRUTURADA E MODELAGEM ORIENTADA A OBJETO • Qualquer coisa à qual um conceito ou tipo de objeto se aplica – uma instância de um conceito ou tipo de objeto.• Um objeto é uma instância de uma classe. Classe: O termo classe refere-se à implementação de software de um tipo de objeto. Um tipo de objeto especifica uma família de objetos sem estipular como o tipo e o objeto são implementados. Os tipos de objetos são especificados durante a análise OO. Os tipos de objetos são implementados como módulos, enquanto na linguagem orientada a objeto os tipos de objetos são classificados como classes. • Uma classe é uma implementação de um tipo de objeto. • Uma classe especifica uma estrutura de dados e os métodos operacionais permissíveis que se aplicam a cada um de seus objetos. • Uma classe pode ter sua própria estrutura de dados e métodos, bem como herdá-la de sua superclasse. Métodos: • Os métodos especificam a maneira pela qual os dados de um objeto são manipulados. • Uma especificação dos passos pelos quais uma operação deve ser executada. • Ele é um script de implementação de uma operação. • Diferentes métodos podem ser usados para executar a mesma operação. • Os métodos de um tipo de objeto referenciam somente as estruturas de dados desse tipo de objeto. • A ação que um objeto ou uma classe podem desempenhar. • Os métodos são similares às funções e procedures do universo da programação estruturada. Encapsulamento: O ato de empacotar ao mesmo tempo dados e objetos é denominado encapsulamento. O objeto esconde seus dados de outros objetos e permite que os dados sejam acessados por intermédio de seus próprios métodos. Isso é chamado de ocultação de informações (information hiding). • O encapsulamento protege os dados do objeto do uso arbitrário e não intencional. • O encapsulamento é o resultado (ou ato) de ocultar do usuário os detalhes da implementação de um objeto. • O encapsulamento é importante porque separa a maneira como um objeto se comporta da maneira como ele é implementado. FONTE: Disponível em: <http://www.macoratti.net/net_oocb.htm>. Acesso em: 11 abr. 2016. 26 RESUMO DO TÓPICO 2 Neste tópico, vimos que: • A modelagem facilita a comunicação entre as partes envolvidas. • A importância da modelagem de sistemas, como parte imprescindível no desenvolvimento dos projetos. • A evolução histórica da modelagem, o que deu certo e o que mudou. • As técnicas de Modelagem estruturada e o Paradigma da Orientação a Objeto (OO). 27 1 “Cada conceito é uma ideia ou um entendimento coletivo que temos do nosso mundo. Os conceitos que adquirimos nos permitem dar sentido sobre as coisas do nosso mundo. Essas coisas às quais nossos conceitos se aplicam são denominadas objetos.” Essa definição é verdadeira ou falsa? 2 Para que serve a modelagem? 3 Quais definições apresentadas não estão corretas? • Encapsulamento – É o agrupamento de ideias afins em uma unidade. Permite ao programador apresentar os detalhes da representação dos dados por trás de um conjunto de operações (como a interface). Reflita sobre o seguinte: você sabe como funciona internamente o seu micro-ondas? Mas você sabe como ligá-lo, programá-lo e desligá-lo. Você interage com o micro-ondas por meio de sua interface sem se preocupar com os detalhes da implementação: esse é um exemplo de encapsulamento. • Ocultação de informações e implementações – é exatamente o uso do encapsulamento que restringe a visibilidade de detalhes e informações que ficam internas à estrutura do encapsulamento. • Mensagens – solicitação de um objeto para que outro objeto efetue uma de suas operações. Os objetos não podem mandar mensagens entre si. As mensagens resultam na chamada de métodos que executam as ações necessárias. • Classes – as classes são conjuntos de objetos com características semelhantes. • Herança – o mecanismo de herança permite que uma classe seja criada a partir de outra classe (superclasse), e a nova classe (subclasse) herda todas as suas características. • Poliformismo – é a propriedade segundo a qual uma operação pode se comportar de modos diversos em classes diferentes. Sistemas orientados a objetos são flexíveis a mudanças, possuem estruturas bem conhecidas e oferecem a oportunidade de criar e implementar componentes totalmente reutilizáveis. 4 Quais são os objetivos atingidos utilizando modelos? 5 Quando e por que a Análise Orientada a Objetos surgiu? 6 Defina os objetivos da análise estruturada e como ela é documentada. AUTOATIVIDADE 28 29 TÓPICO 3 MÉTODO DE DESENVOLVIMENTO ÁGIL UNIDADE 1 1 INTRODUÇÃO Em 2001, Kent Beck e outros 16 renomados desenvolvedores, autores e consultores da área de software, batizados de “Aliança dos ágeis (Agile Alliance)”, assinaram o Manifesto para o Desenvolvimento Ágil de Software (Agile Software Development Manifesto), que se inicia da seguinte maneira, segundo Pressman (2011, p. 81): Desenvolvendo e ajudando outros a desenvolver software, estamos desvendando formas melhores de desenvolvimento. Por meio deste trabalho passamos a valorizar: Indivíduos e interações acima de processos e ferramentas. Software operacional acima de documentação completa. Colaboração dos clientes acima de negociação comercial. Respostas a mudanças acima de seguir um plano. Ou seja, embora haja valor nos itens à direita, valorizaremos os da esquerda mais ainda. Ainda segundo o autor, normalmente, um manifesto é associado a um movimento político emergente: atacando a velha guarda e sugerindo uma mudança revolucionária (normalmente, espera-se que para a melhor). E, de certa forma, é exatamente disso que o desenvolvimento ágil trata. Vale frisar que apesar de parecer benéfica, essa metodologia não é indicada para todos os projetos, produtos, pessoas e situações. Afinal, no contexto de engenharia de software, o que é agilidade? Jacobson apud Pressman (2011, p. 82) responde essa pergunta: Atualmente agilidade tornou-se a palavra da moda quando se descreve um moderno processo de software. Todo mundo é ágil. Uma equipe ágil é aquela capaz de responder apropriadamente a mudanças. Mudanças têm muito a ver com desenvolvimento de software. Mudanças no software que está sendo criado, mudanças nos membros da equipe, mudanças devido a novas tecnologias, mudanças de todos os tipos Para maiores informações, acesse: http://agilemanifesto.org/ DICAS 30 UNIDADE 1 | INTRODUÇÃO AOS MODELOS DE PROCESSO TRADICIONAIS: MODELO CASCATA E INCREMENTAL E MODELOS EVOLUCIONÁRIOS: MODELO ESPIRAL E PROTOTIPAÇÃO que poderão ter um impacto no produto que está em construção ou no projeto do produto. Suporte para mudanças deve ser incorporado em tudo o que fazemos em software, algo desenvolvido por indivíduos trabalhando em equipes e que as habilidades dessas pessoas, suas capacidades em colaborar estão no cerne do sucesso do projeto. O Método Ágil de desenvolvimento incentiva a estruturação e as atitudes em equipe que tornam a comunicação mais fácil entre todos os envolvidos no projeto, e também enfatiza a entrega rápida do software operacional e diminui a importância dos artefatos intermediários. Importante salientar que os custos para as alterações em software aumentam de forma não linear conforme o projeto avança, e quando mais tarde for feita a alteração, mais alto será o custo. É fácil imaginar que se uma alteração for feita durante a fase de requisitos, no início do projeto, estes custos serão mínimos, e o tempo não afetará negativamente o resultado do projeto, como podemos observar na Figura 16. FIGURA 16 - CUSTO DE ALTERAÇÃO Fonte: Pressman (2011, p. 83) 31 TÓPICO 3 | MÉTODO DE DESENVOLVIMENTO ÁGIL 2 PRECEITOS E PRINCÍPIOS Pressman (2011, p.84) ressalta que qualquer processo ágil de software é caracterizado de uma forma que se relacione a uma série de preceitos-chave acerca da maioria dos projetos de software. 1. É difícil afirmar antecipadamente quais requisitos de software irão persistir e quais sofrerão alterações. É igualmente difícil prever de que maneira as prioridades do cliente sofrerão alterações conforme o projeto avança. 2. Para muitos tipos de software,o projeto e a construção são “interconduzidos”, ou seja, ambas as atividades devem ser realizadas uma atrás da outra, para que modelos de projeto sejam provados conforme sejam criados. É difícil prever quanto de trabalho de projeto será necessário antes que seu desenvolvimento seja implementado para avaliar o projeto. 3. Análise, projeto, desenvolvimento e testes não são tão previsíveis quanto gostaríamos que fossem segundo o ponto de vista do planejamento. Em análise a esses pontos, surge a dúvida de como é possível administrar a imprevisibilidade. A resposta, conforme observado, consiste na adaptabilidade de processos, ou seja, um processo ágil deve ser adaptável. Para se conseguir essa agilidade, segundo Pressman (2011, p.84), o grupo “Aliança dos ágeis” estabeleceu 12 princípios: 1. A maior prioridade é satisfazer o cliente por meio da entrega adiantada e contínua de software valioso. 2. Acolha bem os pedidos de alterações, mesmo atrasados no desenvolvimento. Os processos ágeis se aproveitam das mudanças como uma vantagem competitiva na relação com o cliente. 3. Entregue o software em funcionamento frequentemente, de algumas semanas para alguns meses, dando preferência a intervalos mais curtos. 4. O pessoal do comercial e os desenvolvedores devem trabalhar em conjunto diariamente ao longo de todo o projeto. 5. Construa projetos em torno de indivíduos motivados. Dê a eles o ambiente e apoio necessários e confie neles para ter o trabalho feito. 6. O método mais eficiente e efetivo de transmitir informações para e dentro de uma equipe de desenvolvimento é uma conversa aberta, de forma presencial. 7. Software em funcionamento é a principal medida de progresso. 8. Os processos ágeis promovem desenvolvimento sustentável. Os proponentes, desenvolvedores e usuários devem estar capacitados para manter um ritmo constante indefinidamente. 9. Atenção contínua para com a excelência técnica e para com bons projetos aumenta a agilidade. 10. Simplicidade, a arte de maximizar o volume de trabalho não efetuado, é essencial. 11. As melhores arquiteturas, requisitos e projetos emergem de equipes que se auto-organizam. 12. A intervalos regulares, a equipe se avalia para ver como tornar-se mais eficiente, então sintoniza e ajusta seu comportamento de acordo. 32 UNIDADE 1 | INTRODUÇÃO AOS MODELOS DE PROCESSO TRADICIONAIS: MODELO CASCATA E INCREMENTAL E MODELOS EVOLUCIONÁRIOS: MODELO ESPIRAL E PROTOTIPAÇÃO O autor ressalta que nem todo modelo de processo ágil aplica esses 12 princípios de maneira igual, adequando-se e priorizando um ou outro princípio. Entretanto, os princípios definem um espírito ágil mantido em cada um dos modelos de processo. 2.1 FATORES HUMANOS Os defensores das metodologias ágeis de desenvolvimento esforçam-se para reforçar a importância dos “fatores humanos”. Pressman (2011) afirma que o desenvolvimento ágil foca talentos e habilidades de indivíduos, moldando o processo de acordo com as pessoas e equipes específicas. Abaixo listaremos algumas características ou traços-chave que uma pessoa de uma equipe ágil e a equipe em si devem possuir. Competência: Abrange talentos inatos, habilidades específicas relacionadas a software e conhecimento generalizado do processo que a equipe escolheu para aplicar. Habilidade e conhecimento de processo podem e devem ser ensinados para todas as pessoas que sejam membros de uma equipe ágil. Foco comum: Embora os membros de uma equipe ágil possam realizar tarefas e tenham habilidades diferentes em um projeto, todos devem estar focados em um único objetivo: entregar um incremento de software funcionando ao cliente, dentro do prazo estipulado. Para atingir essa meta, a equipe também irá focar em adaptações contínuas (pequenas e grandes) que farão com que o processo se ajuste às necessidades da equipe. Colaboração: Criar informações que ajudarão todos os envolvidos a compreender o trabalho da equipe e a construir informações (software para computadores e banco de dados relevantes) que forneçam valor de negócio para o cliente. Para realizar essas tarefas, os membros da equipe devem colaborar entre si, e com todos os demais envolvidos. Habilidade à tomada de decisão: Ter liberdade para controlar seu próprio destino, ou seja, a equipe deve ter autonomia, autoridade na tomada de decisões. Tanto nos assuntos técnicos como de projetos. Habilidade de solução de problemas confusos: Os gerentes de software devem reconhecer que a equipe ágil terá de lidar continuamente com ambiguidade e que será continuamente atingida por mudanças. Em alguns casos, a equipe tem de aceitar o fato de que o problema que eles estão solucionando hoje talvez não seja o problema que necessita ser solucionado amanhã. Entretanto, lições aprendidas de qualquer atividade de solução de problemas podem ser futuramente benéficas para a equipe no projeto. 33 TÓPICO 3 | MÉTODO DE DESENVOLVIMENTO ÁGIL Confiança mútua e respeito: Deve ser uma equipe consistente, pois demonstra confiança e o respeito necessário para torná-la fortemente unida. O todo é maior que a soma das partes. Auto-organização: No contexto do desenvolvimento ágil, a auto- organização implica três fatores: 1. A equipe ágil se organiza para o trabalho a ser feito; 2. A equipe organiza o processo para melhor se adequar ao seu ambiente local; 3. A equipe organiza o cronograma de trabalho para melhor cumprir a entrega do incremento de software. FONTE: Disponível em: <https://www.passeidireto.com/arquivo/16282034/engenharia-de- software---uma-abordagem-profissional----7-edicao/35>. Acesso em: 11 abr. 2016. A auto-organização possui uma série de benefícios técnicos, mas o mais importante é o fato de servir para melhorar a colaboração e levantar o moral da equipe. Vale ressaltar que a equipe faz seu próprio gerenciamento, pois seleciona quanto trabalho acredita ser capaz de realizar dentro da iteração e se compromete com o trabalho. É extremamente desmotivador para o conjunto um terceiro assumir compromissos por ele. 2.2 METODOLOGIAS ÁGEIS DE DESENVOLVIMENTO DE SOFTWARE Como foi visto até agora, as metodologias ágeis têm o objetivo de acelerar o desenvolvimento do software visando a melhoria contínua do processo, gerando benefícios como o aumento da comunicação e interação da equipe, organização diária para o alcance da meta definida, evitar falhas na elaboração, respostas rápidas às mudanças e aumento significativo da produtividade. A seguir, algumas metodologias de desenvolvimento ágil. • Extreme Programming XP. • Desenvolvimento de Software Adaptativo (ASD). • Scrum. • Método de Desenvolvimento de Sistemas Dinâmicos (DSDM). • Crystal. • Desenvolvimento Dirigido à Funcionalidade (FDD). • Desenvolvimento de Software Enxuto (LSD). • Modelagem Ágil (AM). • Processo Unificado Ágil (AUP). • Rational Unified Process (RUP). 34 UNIDADE 1 | INTRODUÇÃO AOS MODELOS DE PROCESSO TRADICIONAIS: MODELO CASCATA E INCREMENTAL E MODELOS EVOLUCIONÁRIOS: MODELO ESPIRAL E PROTOTIPAÇÃO 2.2.1 Extreme Programming (programação extrema) XP Em seu livro, Pressman (2011, p.87) define um conjunto de cinco valores que estabelecem as bases para todo o trabalho realizado com parte da XP, onde cada um deles é usado como um direcionador das atividades, ações e tarefas específicas da XP: • Comunicação • Simplicidade • Feedback (realimentação ou retorno) • Coragem e • Respeito. A Extreme Programming emprega uma abordagem orientada a objetos como seu paradigma de desenvolvimento preferido e envolve um conjunto de regras e práticas constantes no contexto de quatro atividades metodológicas, que são: planejamento, projeto, codificação e testes. A Figura 17 ilustra o processo e destaca alguns conceitos e tarefas-chave associados a cada uma das atividades metodológicas. FIGURA 17 - EXTREME PROGRAMMING FONTE: Pressman (2011, p. 88) Segundo Sommerville (2011, p.44), em um processo XP os clientes estão intimamente envolvidos na especificação e priorização dos requisitos do sistema.Os requisitos não estão especificados como uma lista de funções requeridas do 35 TÓPICO 3 | MÉTODO DE DESENVOLVIMENTO ÁGIL sistema. Pelo contrário, o cliente do sistema é parte da equipe de desenvolvimento e discute cenários com outros membros da equipe. Juntos eles desenvolvem um “cartão de história” englobando as necessidades do cliente. FIGURA 18 - DESENVOLVIMENTO XP FONTE: Sommerville (2011, p.45) 2.2.2 Desenvolvimento de Software Adaptativo (ASD) É uma técnica para a construção de software e sistemas complexos. As bases se concentram na colaboração humana e na auto-organização das equipes. Nesta técnica de desenvolvimento define-se um ciclo de vida que incorpora três fases: especulação, colaboração e aprendizagem. Princípio ou prática Descrição Planejamento incremental Os requisitos são gravados em cartões de história e as histórias que serão incluídas em um release são determinadas pelo tempo disponível e sua relativa prioridade. Os desenvolvedores dividem essas histórias em 'Tarefas'. Veja quadro 3.1 e 3.2. Pequenos releases Em primeiro lugar, desenvolve-se um conjunto mínimo de funcionalidades útil, que fornece o valor do negócio. Releases do sistema são frequentes e gradualmente adicionam funcionalidade ao primeiro release. Projeto simples Cada projeto é realizado para atender às necessidades atuais e nada mais. Desenvolvimento test-first Um framework de testes iniciais automatizados é usado para escrever os testes para uma nova funcionalidade antes que a funcionalidade em si seja implementada. Refatoração Todos os desenvolvedores devem refatorar o códio continuamente assim que encontrarem melhorias de código. Isso mantém o código simples e manutenível. Programação em pares Os desenvolvedores trabalham em pares, verificando o trabalho dos outros e prestando apoio para um bom trabalho sempre. Propriedade Coletiva Os pares de desenvolvedores trabalham em todas as áreas do sistema, de modo que não se desenvolvam ilhas de expertise. Todos os conhecimentos e todos os desenvolvedores assumem responsabilidade por todo o código. Qualquer um pode mudar qualquer área. Integração contínua Assim que o trabalho em uma tarefa é concluído, ele é integrado ao sistema como um todo. Após essa integração, todos os testes de unidade do sistema devem passar. Ritmo sustentável Grandes quantidades de horas-extras não são consideradas aceitáveis, pois o resultado final, muitas vezes, é a redução da qualidade do código e da produtividade a médio prazo. Cliente no local Um representante do usuário final do sistema (o cliente) deve estar disponível todo o tempo à equipe de XP. Em um processo de Extreme Programming, o cliente é um membro da equipe de desenvolvimento e é responsável por levar a ela os requisitos de sistema para implementação. 36 UNIDADE 1 | INTRODUÇÃO AOS MODELOS DE PROCESSO TRADICIONAIS: MODELO CASCATA E INCREMENTAL E MODELOS EVOLUCIONÁRIOS: MODELO ESPIRAL E PROTOTIPAÇÃO FIGURA 19 - DESENVOLVIMENTO DE SOFTWARE ADAPTATIVO (ASD) FONTE: Pressman (2011, p.94) 2.2.3 Scrum Os princípios do Scrum são consistentes com o manifesto ágil e são usados para orientar as atividades de desenvolvimento dentro de um processo que incorpora as seguintes atividades estruturais: Requisitos, análise, projeto, evolução e entrega. Em cada atividade metodológica ocorrem tarefas a realizar dentro de um padrão de processo chamado Sprint. O fluxo geral do processo de Scrum é ilustrado na Figura 20. 37 TÓPICO 3 | MÉTODO DE DESENVOLVIMENTO ÁGIL FIGURA 20 - DESENVOLVIMENTO SCRUM FONTE: Pressman (2011, p. 96) Segundo o guia do Scrum (2013, p. 4), ele é baseado nas teorias empíricas de controle de processo, ou empirismo. O empirismo garante que o conhecimento vem da experiência e de tomada de decisões baseadas no que é conhecido. O Scrum emprega uma abordagem iterativa e incremental para aperfeiçoar a previsibilidade e o controle de riscos. São três os pilares que apoiam a implementação de controle de processo empírico: transparência, inspeção e adaptação, que detalharemos a seguir: Transparência: Aspectos significativos do processo devem estar visíveis aos responsáveis pelos resultados. Esta transparência requer aspectos definidos por um padrão comum para que os observadores compartilhem um mesmo entendimento do que está sendo visto. Por exemplo: • Uma linguagem comum referindo-se ao processo deve ser compartilhada por todos os participantes; e, • Uma definição comum de “Pronto” deve ser compartilhada por aqueles que realizam o trabalho e por aqueles que aceitam o resultado do trabalho. Inspeção: Os usuários Scrum devem, com frequência, vistoriar os artefatos Scrum e o desenvolvimento em direção a detectar variações. Esta inspeção não deve, no entanto, ser tão frequente que atrapalhe a própria execução das tarefas. As inspeções são mais benéficas quando realizadas de forma diligente por inspetores especializados no trabalho a se verificar. Esse assunto merece seu estudo, acesse http://www.scrumguides.org/docs/ scrumguide/v1/Scrum-Guide-Portuguese-BR.pdf DICAS 38 UNIDADE 1 | INTRODUÇÃO AOS MODELOS DE PROCESSO TRADICIONAIS: MODELO CASCATA E INCREMENTAL E MODELOS EVOLUCIONÁRIOS: MODELO ESPIRAL E PROTOTIPAÇÃO Adaptação: Se um inspetor determina que um (ou mais) aspectos de um processo desviou para fora dos limites aceitáveis, e que o produto resultado será inaceitável, o processo ou o material sendo produzido deve ser ajustado. O ajuste deve ser realizado o mais breve possível, para minimizar mais desvios. O Scrum (2013, p.4) prescreve quatro eventos formais, contidos dentro dos limites da Sprint, para inspeção e adaptação, como descrito na seção Eventos do Scrum deste documento. • Reunião de planejamento da Sprint • Reunião diária • Reunião de revisão da Sprint • Retrospectiva da Sprint Steffen (2011) afirma que o Scrum não é um processo ou uma técnica, mas um framework que, quando usado puro ou em conjunto com demais práticas ou processos, promove maior flexibilidade, visibilidade e produtividade, além, é claro, de outros benefícios que ainda serão abordados. É importante que fique claro que Scrum não é uma abordagem prescritiva. Não é um processo previsível, ele não define o que fazer em toda circunstância. É uma ferramenta, um framework, um conjunto de práticas que torna tudo visível. O Scrum deixa muitas decisões a critério da equipe, porque acredita que a equipe sabe como melhor resolver algum problema apresentado, assim como quais práticas ela está madura suficiente para adotar. Ainda segundo a autora, os envolvidos em um projeto podem ser divididos em dois grupos: • Stakeholders (interessados no produto, mas não comprometidos) • Time Scrum, que é composto do Product Owner, ScrumMaster e equipe de desenvolvimento (7 + ou - 2, ou seja, de 5 até 9 pessoas). O Product Owner gerencia o product Backlog • Representa todos os demais stakeholders (cliente, usuários, representantes de negócios, etc.). • Responsável por definir a funcionalidade do produto • Foco nos negócios. É responsável pelo gerenciamento do Product Backlog, pelo ROI e prioridades. • Responsável pelo aceite do produto - resultado de cada Sprint. • Não é um comitê, mas uma única pessoa. • É o único responsável pela manutenção do Backlog. • Não pode ser o ScrumMaster • Define para onde o time deve ir mas não como chegar lá, não em qual velocidade. O ScrumMaster é quem gerencia o processo, ele é o facilitador da equipe e é responsável por: • Garantir que os valores e as práticas do Scrum foram entendidos pelo time e estão sendo seguidos. 39 TÓPICO 3 | MÉTODO DE DESENVOLVIMENTO ÁGIL • Ensinar e treinar a equipe de forma que ela seja autogerenciável e multifuncional. • Ensinar/Garantir que o Product Owner também está desempenhando seu trabalho. • Remover impedimentos (visíveis e não visíveis) (internos e externos). • Motivar e manter a saúde da equipe, trabalho em equipe, comunicação, minimizando atritos e promovendo
Compartilhar