Baixe o app para aproveitar ainda mais
Prévia do material em texto
Professor Me. Ricardo Bortolo Vieira • Graduação em Ciência da Computação pela Universidade Estadual de Maringá (2003). • Especialização de Engenharia de Software pela Universidade Estadual de Lon- drina (2007). • MBA em Gestão em Saúde Suplementar pela São Marcos (2009). • Especialização de Gerência de Projetos pela Fundação Getúlio Vargas (2011). • Mestre em Desenvolvimento de Tecnologias pelo Instituto LACTEC.(2017) • Doutorando em Informática para PUCPR . • Gerente de Desenvolvimento de software e profissional do mercado de TI a mais de 12 anos. • Professor de nível superior da Faculdade Cidade Verde de Maringá (FCV), Universidade Federal do Paraná (UFPR), Faculdade de Engenharia e Inovação Tecnológica (FEITEP), Fundação Getúlio Vargas (FGV) e Pontifícia Universida- de Católica (PUC). • Experiência na área de Ciência da Computação, com ênfase em Sistemas de Computação e Automação e Robótica, além de experiência em Administração com ênfase em Gerenciamento de Projetos. Lattes: http://lattes.cnpq.br/5731213234468142 AUTOR http://lattes.cnpq.br/5731213234468142 Seja muito bem-vindo(a)! Olá prezado(a) aluno(a), este é o livro Fundamentos de Engenharia de Software, sou o professor Ricardo Vieira, autor deste material, e o assunto que abordarei no decorrer do nosso estudo poderá auxiliá-lo em sua carreira e abrir caminho para o mundo dos negó- cios, mostrando-lhe um lado mais gerenciar do processo de desenvolvimento de software. Com o passar do tempo, você irá se adaptar aos jargões. Meu objetivo principal com este livro é apresentar os conceitos mais importantes da engenharia de software e discutir técnicas para gerenciar o processo de desenvolvimento de software. Este processo vai auxiliar você a levantar as necessidade de cada empresa e produto e analisar cada necessidade apresentada e escolher o melhor processo. Além disso, pretendo deixar claro que o uso correto dos conceitos de engenharia de software podem ajudá-lo a alcançar os objetivos estratégicos de sua empresa ou auxiliá-lo a colocar em prática uma nova ideia. Este livro está organizado em quatro unidades, além da apresentação e conclusão. Cada uma delas correspondendo a uma das partes importante do processo de desenvolvi- mento de software. Na primeira unidade você irá estudar os conceitos básicos da engenharia de sof- tware, revisar um pouco da história desta engenharia tão recente em relação às demais e introduzir os processos de software que serão detalhados em outras unidades. Já na unidade II você poderá constatar que a ela está totalmente focada em projetos, e assim estudaremos desde o projeto arquitetural, passando pelos projetos de componentes, interface de usuário, e WebApps e não deixando de discutir um pouco sobre padrões de projetos. APRESENTAÇÃO DO MATERIAL Depois, na terceira unidade, falaremos sobre os processos da qualidade, apren- dendo sobre os conceitos básicos da qualidade e as técnicas de revisão de código e arte- fatos. Além disso, vamos discutir sobre a garantia da qualidade de software e apresentar estratégias de teste de software, que devem se adaptar ao processo criado para cada necessidade discutida na unidade I. Na última unidade, vamos entender melhor sobre o gerenciamento de projetos e as métricas de processo e projeto. Pois sem indicadores não é possível gerenciar. Vamos também discutir sobre estimativas de projeto de software e manutenção e reengenharia como processos necessários em alguns projetos. Agora, mãos à obra! Tenha uma boa e agradável leitura! SUMÁRIO UNIDADE I ...................................................................................................... 6 Introdução da Engenharia de Software UNIDADE II ................................................................................................... 31 Projetos de Software UNIDADE III .................................................................................................. 57 Qualidade e Técnicas de Revisão UNIDADE IV .................................................................................................. 81 Gerenciamento de Projetos 6 Plano de Estudo: • Introdução e Objetivos da Engenharia de Software • Modelos de Processo • Princípios que Orientam a Prática • Desenvolvimento Dirigido a plano e desenvolvimento Ágil Objetivos de Aprendizagem: • Capacitar o aluno a desenvolver habilidades manuais corriqueiras do dia a dia do profissional da área de Tecnologia da Informação; • Proporcionar competências e habilidades para que o aluno adquira as habilidades básicas a respeito da Engenharia de Software, como um instrumento para modelagem de sistemas, no auxílio ao Planejamento de Software UNIDADE I Introdução da Engenharia de Software Professor Mestre Ricardo Bortolo Vieira 7UNIDADE I Introdução da Engenharia de Software INTRODUÇÃO Caro(a) aluno(a), neste capítulo, trataremos de assuntos iniciais importantes paro o bom entendimento dos demais capítulos desta apostila. Para tanto, conceitos genéricos serão explicados (como software, dados, informações, engenharia de software), fornecendo uma visão geral, do funcionamento do processo até chegar a definição de engenharia de software propriamente dito e as atividades que são essenciais para esse processo, desde a engenharia de requisitos até os testes e evolução do software. Vamos estudar também o modelo de processo de software e discutir o que es- sencialmente todo o processo de software deve ter, que são as 4 atividades principal: Especificação de Software, Projeto e Implementação de software, Validação de Software e Evolução do Software. Neste tópico vamos também trabalhar o conceito de cada um deles. No tópico sobre desenvolvimento dirigido a plano, estudaremos a sequência de atividades que cada um dos modelos que seguem esse conceito trabalham. Os modelos estudados neste tópico serão: Modelo Cascata, modelo espiral e modelo incremental. Já no tópico sobre desenvolvimento ágil iremos estudar o manifesto que deu origem a todos estes tipos de processo o chamado manifesto ágil. Neste tópico iremos estudar 2 modelos: o modelo XP (eXtreme Programming) e o modelo SCRUM. Além disso, será apresentado a Linguagem de Modelagem Unificada (UML) que representa uma linguagem visual extremamente poderosa e não ambígua. Esta linguagem é muito importante para o engenheiro de software pois assim ele pode desenhar o processo de software baseado nas regras de negócio, independente da linguagem de desenvolvi- mento. Ainda neste tópico conheceremos alguns exemplos de software CASE baseadas em UML para apoiar o processo da engenharia de software e torná-la mais eficiente e reutilizável. Então vamos lá! Bons estudos! 8UNIDADE I Introdução da Engenharia de Software 1 INTRODUÇÃO A ENGENHARIA DE SOFTWARE A maior parte dos serviços e infraestruturas são controladas atualmente por software (SOMMERVILLE, 2011). Ele é importante porque afeta quase todos os aspectos da nossa vida e está incorporado no comércio, na cultura e nas atividades cotidianas (PRESSMAN, 2011). Por isso o mundo moderno não poderia existir sem o software (SOMMERVILLE, 2011). O Software, produto final e objeto principal de todo o trabalho desenvolvimento dentro da engenharia de software, cada dia mais é indispensável a qualquer atividade, seja ela industrial, comercial ou até pessoal. As atividades que ainda não tem nenhum ou pouco tipo de automação de software, estão em vias de fazê-lo. Para essa atividade de desenvolver o produto, aplica-se o mesmo paradigma para um produto bem-sucedido da indústria, ou seja, adaptar o processo e torná-lo ágil para conduzir a um resultado de alta qualidade, atendendo as necessidades do cliente e do usuário final. Para o estudo deste conceito, apresentamos a engenharia de software (PRESSMAN, 2011). 9UNIDADE I Introdução da Engenharia de Software 2 MAS O QUE SERIA UM SOFTWARE? “Software de computadoré o produto que profissionais de software desenvol- vem e ao qual dão suporte no longo prazo. Abrange programas executáveis em um computador de qualquer porte ou arquitetura, conteúdos (apresenta- dos à medida que os programas são executados), informações descritivas tanto na forma impressa como na virtual, abrangendo praticamente qualquer mídia eletrônica.” (PRESSMAN, 2011, p.29) Com base nessa definição, a engenharia de software pode definir processos abran- gentes, métodos (práticas) e um leque de ferramentas que possibilitam aos profissionais desenvolverem software de altíssima qualidade. Outra questão que é importante ressaltar é que, do ponto de vista de um engenheiro de software, o software é um conjunto de programas, conteúdo (dados) e outros artefatos. Porém, do ponto de vista do usuário, o artefato consiste em informações resultantes que, de alguma forma, tornam a vida dele melhor. Ainda segundo Pressman (2011), software consiste em: 1 - Instruções (programas de computador), que, durante sua execução, podem fornecem características, funções e desempenho desejados; 2 - Estruturas de dados que permitem aos programas buscar e alterar informações da forma como os programas precisam; e 3 - Informação descritiva, tanto na forma impressa como na virtual, e tanto para o foco técnico como para o usuário final, descrevendo a operação e o uso dos programas. O software distribui basicamente informação. Ele transforma dados de modo que possam ser mais úteis num determinado contexto, gerencia informações comerciais para aumentar a competitividade, fornece um portal para redes mundiais de informação e os meios para obter informações de todas as formas (PRESSMAN, 2011). Os sistemas de software são abstratos e intangíveis, não há limites naturais para o potencial do software, sejam pelas propriedades naturais, leis da física ou processos da manufatura (SOMMERVILLE, 2011). Segundo Pressman (2011), software é mais um elemento lógico do que físico. Desta maneira há algumas características que o diferencia de hardware: 1. Software é desenvolvido ou passa por um processo de engenharia, ele não é fabricado no sentido clássico. 2. Software não se desgasta, ele não é suscetível aos males ambientais que fazem com que o hardware se desgaste. Não existem peças de reposição de software, cada defeito indica um erro no projeto; 10UNIDADE I Introdução da Engenharia de Software 3. A maioria dos softwares continua a ser construído de forma personalizada. Todo projeto de software se inicia por alguma necessidade de negócios, seja ela de corrigir algum defeito de uma aplicação já existente, a necessidade de estender as funções e ou recursos ou a de criar um novo produto, serviço ou sistema (PRESSMAN, 2011). Para Sommerville (2011), um software é um programa de computador e a docu- mentação associada. E os produtos de software podem ser desenvolvidos para um cliente específico ou para o mercado em geral. Assim, produtos de software que podem ser clas- sificados em dois tipos: 1. Produtos genéricos: existem sistemas que são feitos e colocados no mercado para qualquer cliente que esteja interessado em comprá-los. 2. Produto sob-encomenda: diferente dos genéricos, estes são encomendados por um cliente em particular de acordo com suas necessidades. 3 ENGENHARIA DE SOFTWARE Fazer software não é uma tarefa fácil, software de qualidade é ainda mais difícil. Todavia, mesmo apresentando baixa qualidade, o interesse das organizações pelo desen- volvimento de sistemas tem aumentado. Isso porque as organizações reconhecem que software é fonte de importantes vantagens competitivas (SILVA; VIDEIRA, 2001). Segundo Sommerville (2011), os diversos relatos de software que deram errado e resultaram em “falhas de software” são conseqüências de dois fatores: 1. Aumento da demanda: Os sistemas devem ser construídos e entregues mais rapidamente e esses sistemas são maiores e até mais complexos. A engenharia de software não consegue lidar com isso, novas técnicas de engenharia de software precisam ser criadas para atender essas novas demandas. 2. Expectativas baixas: As empresas eram obrigadas a desenvolver software à medida que suas necessidades continuavam aumentando. O que torna seu software menos confiável e mais caro do que devia ser. Por isso é necessário educação e treinamento em engenharia de software para solucionar esses problemas. Segundo Pressman (2011), existem inúmeros desafios que os desenvolvedores de software devem estar preparados para enfrentar no século XXI, por exemplo: • Software tornou-se incorporado em todos os sentidos da nossa vida, o número de pessoas interessadas no que o software pode oferecer tem crescido signifi- 11UNIDADE I Introdução da Engenharia de Software cantemente; • Os requisitos da tecnologia da informação demandados estão cada vez mais complexos; • Pessoas, governos e negócios dependem cada vez mais de software para deci- sões estratégicas e táticas; • Software deve ser passível de manutenção para tolerar as mudanças necessá- rias. A engenharia de software é uma disciplina da engenharia que tem foco desde os estágios iniciais da especificação de um sistema até a manutenção de um software. A engenharia de software é importante por dois motivos, segundo (SOMMERVILLE, 2011): 1. Cada vez mais os indivíduos dependem de software avançado. Por isso eles devem ser produzidos de forma confiável, econômica e rápida; 2. Em longo prazo, é mais barato usar métodos e técnicas de engenharia de sof- tware para sistema de software. Uma das primeiras definições da Engenharia de Software foi dada por Fritz Bauer no final dos anos 60: “a definição e utilização de princípios de engenharia sólidos, de modo a desenvolver software econômico, confiável e que trabalha eficientemente em máquinas reais. Inclui um conjunto de métodos, de ferramentas e de procedimentos” (BAUER, 1971, p. 524). Outra definição, mais comumente usado foi proposta por Potts na IEEE em 1993: “a Engenharia de Software é a aplicação de um processo sistemático, disciplinado e quan- tificado ao desenvolvimento, operação e manutenção de software, ou seja, e Engenharia de Software é a aplicação de técnicas da Engenharia de Software” (POTTS, 1993, p. 20). Todos os tipos de sistemas precisam da engenharia de software, independente do fim ou da complexidade, o que diferencia são as técnicas utilizadas para chegar ao objetivo final (SOMMERVILLE, 2011). A engenharia de software é importante porque ela nos capacita para o desen- volvimento de sistemas complexos, dentro do prazo e com alta qualidade, atendendo as necessidades daqueles que usarão o produto. Necessidade essa que normalmente é expressa no início de qualquer projeto com uma simples conversa entre as partes (cliente e desenvolvedor) (PRESSMAN, 2011). De acordo com Sommerville (2011), a maior parte do desenvolvimento de software é profissional, com um propósito específico de negócio e é normalmente criado, mantido e alterado por equipes. A engenharia de software busca apoiar esse desenvolvimento com técnicas que auxiliam na especificação, projeto e evolução de programas. 12UNIDADE I Introdução da Engenharia de Software Quando falamos na engenharia de software, estamos falando também de toda documentação envolvida e configurações necessárias para o bom funcionamento do pro- grama (SOMMERVILLE, 2011). Segundo Sommerville (2011) existem fundamentos da engenharia de software que se aplica independentemente do tipo de sistema de software: 1. Devem ser desenvolvidos em um processo gerenciado e compreendido; 2. Confiança e desempenho são importantes para todos os tipos de sistema; 3. É importante entender o que os clientes esperam do sistema; 4. Deve-se fazer o melhor uso possível dos recursos existentes. A engenharia de software é dividida em camadas, cada uma delas é descrita por Pressman (2011) da seguinte maneira: A peça fundamental quesustenta a Engenharia de Software é o Foco na Qualida- de, qualquer abordagem de engenharia deve estar fundamentada em um comprometimento organizacional de qualidade. Em seguida, a Camada de Processos mantém as camadas de tecnologia coesas e possibilita o desenvolvimento de software de forma racional e dentro do prazo. Para que isso ocorra, uma metodologia é estabelecida, com uma base de controle de gerenciamento de projetos, gerenciamento de mudanças e controle de qualidade, para entrega efetiva dos produtos concebidos na engenharia de software (PRESSMAN, 2011). Os Métodos fornecem as informações técnicas, com uma gama de tarefas, como comunicação, análise de requisitos, construção do programa, teste e suporte, para desen- volver o software. Por fim, as Ferramentas dão suporte automatizado ou semiautomatizado para os processos e métodos. O posicionamento das camadas descritas anteriormente é ilustrado na Figura 1. Figura 1 - Camadas da Engenharia de Software. Fonte: Pressman (2011) 13UNIDADE I Introdução da Engenharia de Software 3 MODELOS DE PROCESSO DE SOFTWARE Um software não pode ser desenvolvido de qualquer jeito, sem seguir critérios, sem que se saiba qual o próximo passo a ser dado. Por isso que os conceitos relacionados à engenharia de software devem ser utilizados. Hoje em dia, a empresa precisa definir qual o seu processo de software. Esta engenharia é realizada por pessoas (como engenheiros de software e geren- tes) de amplo conhecimento que precisam adaptar um processo de software de acordo com as demandas do mercado de modo que fique apropriado aos produtos desenvolvidos e com suas necessidades (PRESSMAN, 2011). Processo é um conjunto de atividades, ações e tarefas realizadas na criação de algum produto (PRESSMAN, 2011; SOMMERVILLE, 2011). Essas atividades podem ser a partir do zero em determinada linguagem de programação, ou por meio de alterações/ incrementos em sistemas já existentes (SOMMERVILLE, 2011). No contexto de engenharia de software, esse processo não é uma “receita” rígida e restrita de como desenvolver um software. É uma abordagem adaptável que possibilita a equipe de software realizar o trabalho de solucionar o conjunto apropriado de ações e tarefas. Ou seja, significa a abordagem adotada conforme um software é elaborado pela engenharia que pode estabilizar e organizar uma atividade que pode ser bastante caótica (PRESSMAN, 2011). Tarefa é um objetivo pequeno, porém bem definido que produz um resultado tangí- 14UNIDADE I Introdução da Engenharia de Software vel (PRESSMAN, 2011). Uma ação pode ser definida como um conjunto de tarefas que resultam num arte- fato de software fundamental (PRESSMAN, 2011). Segundo Pressman (2011), a metodologia de processo é o alicerce para um pro- cesso de engenharia de software completo. Para Sommerville (2011), existem muitos processos de software diferentes, mas todos eles incluem pelo menos quatro atividades fundamentais para a Engenharia de Sof- tware. 1. Especificação de Software: É necessário que o cliente defina as funcionalida- des do software que será desenvolvido, e que o software tenha suas restrições operacionais bem levantadas; 2. Projeto e Implementação de software: O software deve ser produzido de acordo com as especificações; 3. Validação de Software: Depois de produzido, o software deve ser validado para garantir que a demanda do cliente tenha sido atendida; 4. Evolução do Software: As funcionalidades definidas pelo cliente durante o desenvolvimento podem mudar e o software deve evoluir para atender tanto as necessidades de mudança do cliente, como do mercado. Essas atividades genéricas podem ser usadas para o desenvolvimento de sistemas simples até os mais complexos. Para muitos projetos de software, essas atividades são aplicadas repetidamente conforme as iterações do projeto (PRESSMAN, 2011). Diversas outras atividades apóiam as atividades fundamentais para o desenvol- vimento de um software, são elas: controle e acompanhamento do projeto, administração de riscos, garantia de qualidade de software, gerenciamento da usabilidade, entre outras (PRESSMAN, 2011). Em geral, os processos de software incluem atividades complexas, que como todo processo intelectual e criativo, depende de pessoas para tomar decisões e fazer julga- mentos, desta maneira, não existe processo ideal, as empresas os adaptam conforme sua necessidade (SOMMERVILLE, 2011). Para alguns sistemas, como os críticos, é necessário um processo de desenvolvimento bem estruturado, já para um sistema de negócios, com requisitos que se alteram constantemente, um processo menos formal e mais flexível seria o mais indicado (SOMMERVILLE, 2011). Mas o que acontece é que nem sempre as empresas aproveitam as boas técni- cas da engenharia de software em seu desenvolvimento de software. E, normalmente, o software não atende aos requisitos do usuário, acaba demorando mais tempo para ser desenvolvido do que o previsto, aumentando assim, o valor do custo do software. 15UNIDADE I Introdução da Engenharia de Software 4 PRINCÍPIOS QUE ORIENTAM A PRÁTICA DOS MODELOS DE PROCESSO DE SOFTWARE Todos os modelos de processos de software podem acomodar as atividades essen- ciais descritas no tópico anterior, porém cada um deles dá uma ênfase diferente a essas atividades e define um fluxo de processo que invoca essas atividades de diferentes formas (PRESSMAN, 2011). Os processos de software podem ser categorizados como modelo dirigido a plano ou como um modelo ágil. Todas as atividades planejadas com antecedência e que o pro- gresso é avaliado por comparação com o projeto inicial se caracterizam por um modelo dirigido a plano. Já em um modelo ágil, o planejamento é gradativo, e por isso é mais fácil alterar o processo de maneira a refletir as necessidades de mudanças dos clientes. (SOMMERVILLE, 2011). Cada abordagem é indicada para diferentes tipos de software, e é necessário en- contrar um equilíbrio entre eles. A Figura 2 mostra as diferenças entre as abordagens dirigidas a planos e ágil para a especificação do sistema. Na primeira maneira, ocorrem interações nas atividades com documentos formais, usados para estabelecer a comunicação entre os estágios do proces- so, então os requisitos evoluem e depois será produzida uma especificação de requisitos, que é entrada para o projeto e implementação. Em uma abordagem ágil, iterações ocorrem em todas as atividades, portanto, os requisitos e o projeto são produzidos em conjunto (SOMMERVILLE, 2011). Figura 2 - Especificações dirigidas a planos e ágil. Fonte: Sommerville (2011) 16UNIDADE I Introdução da Engenharia de Software Existem vários tipos de modelos de processos de software, e inclusive os artigos científicos continuam a propor novas adaptações. Vamos apresentar aqui, três tipos de modelos baseados no conceito dirigidos a plano e segundo Sommerville (2011): • Modelo Cascata: Considera as atividades de especificação, desenvolvimento, validação, e evolução, fundamentais ao processo e as representa como fases separadas; • Desenvolvimento Incremental: Intercala as atividades de especificação, de- senvolvimento e validação. Um sistema é rapidamente desenvolvido através de especificações abstratas e a partir dele várias versões são entregues com refinamento contínuo; • Modelo Espiral: Processo dirigido a riscos, onde cada volta da espiral represen- ta uma fase do processo de software. Estas voltas são concêntricas e partem do centro para a marginal. A espiral mais interna pode ser o processo de estudo de viabilidade do software e a próxima define os requisitos, e assim por diante. 17UNIDADE I Introdução da Engenharia de Software 5 MODELOS DE DESENVOLVIMENTO DIRIGIDOS A PLANO 5.1 Modelo Cascata Modelo de processo prescritivo, proposto para trazer ordem ao caos existente no desenvolvimento de software, fornecendo um roteiro razoavelmente eficaz para as equipesde desenvolvimento de software. O modelo cascata sugere uma abordagem seqüencial e sistemática, começando com levantamento de requisitos com o cliente e passando pelas fases de planejamento, modelagem, construção e entrega. É normalmente utilizado quando os requisitos são bem compreendidos ou quando adaptações ou aperfeiçoamento são bem definidos (PRESSMAN, 2011). Figura 3: Modelo Cascata. Fonte: Adaptado de Sommerville (2011) 5.2 Modelo Incremental Também é um modelo prescritivo, em que os requisitos iniciais são razoavelmente bem definidos, no entanto, um processo puramente linear não é usado. O fornecimento de partes do sistema ao usuário é necessário para que se possa refinar e expandir suas funcionalidades em versões posteriores (PRESSMAN, 2011). 18UNIDADE I Introdução da Engenharia de Software Figura 4 - Modelo Incremental. Fonte: Adaptado de Sommerville (2011) 5.3 Modelo Espiral O software é desenvolvido de maneira que possa evoluir ao longo do tempo. Acopla iteratividade e prototipação com os aspectos sistemáticos e controlados do modelo cascata (PRESSMAN, 2011). Figura 5 - Modelo Espiral. Fonte: Adaptado de Sommerville (2011) 19UNIDADE I Introdução da Engenharia de Software Existe também o chamado processo unificado, que é uma metodologia para enge- nharia de software orientada a objetos usando a UML e reúne as melhores práticas dos modelos já existentes (PRESSMAN, 2011). 6 MODELOS DE DESENVOLVIMENTO ÁGIL Em 2001, Kent Beck e outros dezesseis renomados desenvolvedores, autores e consultores da área de software assinaram o “Manifesto para o Desenvolvimento Ágil de Software”. Normalmente, um manifesto é associado a um movimento político emergente: atacando a velha guarda e sugerindo uma mudança revolucionária. De certa forma, é exa- tamente do que trata o desenvolvimento ágil (PRESSMAN, 2011). Por que Scrum? Criei o Scrum, junto com Ken Schwaber, há vinte anos, como um jeito mais rápido, confiável e eficiente de desenvolver softwares na indús- tria de tecnologia. Até aquele momento — e até 2005 —, a maior parte do de- senvolvimento de softwares era executada com base no método em cascata, de acordo com o qual um projeto era concluído em etapas distintas e levado passo a passo até o lançamento para Os consumidores ou usuários. O pro- cesso era lento, imprevisível, e muitas vezes não resultava em um produto que as pessoas quisessem ou pelo qual se dispusessem a pagar. Atrasos de meses, ou até mesmo anos, eram endêmicos. Os antigos planos passo a passo, confortavelmente detalhados em diagramas de Gantt, davam à gerên- cia uma sensação de que se tinha total controle sobre o desenvolvimento de um projeto. No entanto, na maioria esmagadora dos casos, em pouco tempo os atrasos em relação ao cronograma começavam e o orçamento era ultra- passado em uma escala desastrosa. Para superar essas falhas, inventei, em 1993, um novo jeito de fazer as coi- sas: o Scrum. Trata-se de uma mudança radical em relação às metodologias prescritivas e hierarquizadas empregadas na gerência de projetos no pas- sado. Ao contrário delas, o Scrum se assemelha a sistemas evolucionários, adaptativos e autocorretivos. Desde seu nascimento, a estrutura do Scrum se tornou a maneira como o setor de tecnologia cria novos softwares e produtos. Porém, apesar de ter obtido muito sucesso no gerenciamento de projetos de software e hardware no Vale do Silício, o Scrum permanece relativamente desconhecido no mundo dos negócios em geral.” (SUTHERLAND, 2016) Embora as ideias básicas que norteiam o desenvolvimento ágil já existam a muitos anos, só a duas décadas que se consolidaram como um “movimento”. Dentre estes méto- dos ágeis, existentes na literatura, vou abordar aqui, de forma sucinta, somente duas delas: • Modelo eXtreming Programming (XP): Representa uma metodologia ágil de desenvolvimento de software voltada para times de pequeno a médio porte, no qual os requisitos são vagos e mudam frequentemente. Desenvolvido por Kent Beck, Ward Cunningham e Ron Jeffries. O XP tem como principal tarefa a codifi- cação com ênfase menor nos processos formais de desenvolvimento e com uma maior disciplina de engenharia ágil de software para codificação e testes. Tem como valores a comunicação, a simplicidade, o feedback, a coragem e o respei- 20UNIDADE I Introdução da Engenharia de Software to. O XP valoriza a automatização de testes, sendo estes criados antes, durante e depois da codificação. É flexível para a mudanças de requisitos, valorizando o feedback com o usuário e a qualidade do código-fonte final. A ideia principal do XP é a criação de software de alta qualidade, e orientada explicitamente às pessoas. Seu método é melhor apresentado na Figura 6 (WILDT, 2015); • Modelo SCRUM: O nome provém de uma atividade que ocorre durante a partida de ‘rugby’. Este método foi criado por Jeff Sutherland e sua equipe de desen- volvimento, conforme relato dele no início deste tópico. Os princípios do Scrum são baseados no 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 cha- mado sprint. O trabalho realizado dentro de um sprint é adaptado ao problema em questão e definido, e muitas vezes modificado em tempo real, pela equipe Scrum. O fluxo geral do processo Scrum é ilustrado na Figura 7 (PRESSMAN, 2011). Figura 6 - Modelo Extreme Programming. Fonte: Teles (2017) 21UNIDADE I Introdução da Engenharia de Software Figura 7 - Modelo SCRUM. Fonte: Adaptado de Sutherland (2016) 7 UML E ORIENTAÇÃO A OBJETOS A UML (Unified Modeling Language ou Linguagem de Modelagem Unificada) é uma linguagem gráfica, utilizada para a elaboração da estrutura de projetos de software. Constrói modelos concisos, precisos, completos e sem ambiguidades, tendo, de maneira geral, as seguintes características, segundo Pereira (2011): • Modela os aspectos estruturais (estáticos) e comportamentais (dinâmicos) do sistema. Em outras palavras, a UML provê elementos de notação para modelar dados, funções de transformação dos dados e as restrições aplicáveis aos dados e às funções; • Provê uma linguagem que permite o entendimento e a utilização por humanos e a leitura por máquinas; • Provê elementos de notação para modelar todos os tipos de sistemas de com- putação; • Permite a modelagem do conceito ao artefato executável, utilizando técnicas Orientadas a Objeto (OO); • A linguagem é extensível e adaptável a necessidades específicas; palavras- -chave permitem que se modifique a semântica de elementos da linguagem; 22UNIDADE I Introdução da Engenharia de Software • Contempla as necessidades de produção de modelos pequenos e simples a grandes e complexos; • Modela processos manuais ou automatizados, estes independentemente da tecnologia que usam; • É uma linguagem para visualização do modelo, facilitando o entendimento pelas equipes de análise de negócio, desenvolvimento de sistemas e pelos clientes; • Serve para construir código de computador, embora não seja uma linguagem de programação de computadores; • Está em evolução, mesmo após mais de dez anos da publicação da versão inicial. De acordo com Guedes (2011), a UML é uma linguagem de modelagem e é in- dependente de processo de software, podendo ser utilizada em modelo cascata, desen- volvimento evolucionário, ou qualquer outro processo que esteja sendo utilizado para o desenvolvimento de software. Esta linguagem utiliza diversos símbolos gráficos, e possui uma semântica bem definida para cada um deles, sendo possível elaborar diversos modelos. A UML tem sido empregada de maneira efetiva em sistemas cujos domínios abrangem: sistemas de infor- mações corporativos, serviços bancários e financeiros, transportes, serviços distribuídos baseadosna Web entre outros. Porém, a UML, não se limita à modelagem de software, podendo modelar sistemas como o fluxo de trabalho no sistema legal, a estrutura e o com- portamento de sistemas de saúde e o projeto de hardware. Ela surgiu da junção de 3 grandes métodos: Método Booch de Grady Boock, Méto- do OMT (Object Modeling Technique) de Rumbaugh e do método OOSE (Object-Oriented Software Engineering) de Jacobson. Esses eram, até meados da década de 1990, as três metodologias de modelagem orientada a objetos mais populares entre os engenheiros de software (GUEDES, 2011). A UML é baseada no paradigma de orientação a objetos (OO), que está ligado a nove conceitos (JONES, 2001): • Encapsulamento; • Ocultação de informação e Implementações; • Retenção de Estado; • Identidade de Objeto; • Mensagens; • Classes; • Herança; 23UNIDADE I Introdução da Engenharia de Software • Polimorfismo; e • Generalização. Em sua última versão vigente, 2.5, a UML possui 14 diagramas vigentes apresen- tados na Figura 8. Figura 8 - Organograma da UML 2.5. Fonte: Adaptado de Pereira (2011) 24UNIDADE I Introdução da Engenharia de Software FERRAMENTAS CASE Uma ferramenta CASE (Computer-Aided Software Engineering - Engenharia de Software Auxiliada por Computador) é um software que, de alguma forma, colabora na realização de uma ou mais atividades da engenharia de software. Ou segundo Terry (1990, p. 349), “CASE designa um conjunto de ferramentas que auxiliam um programador ou gestor de projetos durante uma ou mais fases do processo de desenvolvimento de software, incluindo a manutenção”. Outra definição, dada por Silva e Videira (2011, p. 326) é: “Um conjunto de técnicas e ferramentas informáticas que auxiliam o enge- nheiro de software no desenvolvimento de aplicações, com o objetivo de di- minuir o respectivo esforço e complexidade, de melhorar o controle do proje- to, de aplicar sistematicamente um processo uniformizado e de automatizar algumas atividades e verificação da consistência e qualidade do produto final e geração de artefatos.” Para a modelagem de sistemas usando a UML, normalmente usamos as ferramen- tas CASE, as mais conhecidas são descritas a seguir: 25UNIDADE I Introdução da Engenharia de Software Astah Community é um software para modelagem UML (Unified Modeling Lan- guage – Linguagem de Modelagem Unificada) com suporte a UML 2, desenvolvido pela Change Vision, Inc e disponível para sistemas operacionais Windows 64 bits. Anteriormente conhecido por JUDE, um acrônimo de Java and UML Developers Environment (Ambiente para Desenvolvedores UML e Java). Astah Community disponibiliza para desenvolvimento, os diagramas de Classes, Casos de Uso, Sequência, Comunicação, Máquina de Estados, Atividade, Componentes, Implantação e Diagrama de Estrutura Composta. Figura 9 - Logotipo do Software Astah Community Fonte: ASTAH (2006) Rational Rose é uma ferramenta CASE, mais especificamente, uma ferramenta UML que auxilia nos processos de construção de um software profissional. Hoje em dia essa ferramenta tem um peso no mercado sendo usada por diversos profissionais e gran- des empresas. Foi criada pela Rational que, posteriormente foi adquirida pela IBM em 20 de fevereiro de 2003 e a ferramenta não é gratuita. Permite a modelagem com os quatorze diagramas da UML. Permite também a construção de modelos de Dados com possibilidade de exportação para construção da base de dados ou realização de engenharia reversa de uma base de dados existente. Dá suporte ao Visual Studio (pacote de programas para desenvolvimento de software da Microsoft). Foi sucedido pelo IBM Rational Architect. Figura 10 - Logotipo do Software Rational Rose Fonte: IBM (2001) Enterprise Architect é uma ferramenta paga com recursos de ponta e um rico conjunto de recursos para ajudar a gerenciar informações e inovar no ambiente complexo e exigente de hoje. Em conjunto com o UML 2.0 é possivel modelar, projetar e construir um software ou projeto comercial. Ele suporta MDA (Model-Driven Architecture) e geração de códigos em linguagem Java, C#, C++, VB.NET, VB, Python e DLL (Dynamic-Link Library) https://pt.wikipedia.org/wiki/Ferramenta_CASE https://pt.wikipedia.org/wiki/Ferramenta_UML https://pt.wikipedia.org/wiki/Ferramenta_UML https://pt.wikipedia.org/wiki/Engenharia_de_software https://pt.wikipedia.org/wiki/Software https://pt.wikipedia.org/wiki/IBM https://pt.wikipedia.org/wiki/20_de_fevereiro https://pt.wikipedia.org/wiki/20_de_fevereiro https://pt.wikipedia.org/wiki/2003 https://pt.wikipedia.org/wiki/UML https://pt.wikipedia.org/wiki/Modelos_de_Dados https://pt.wikipedia.org/wiki/Banco_de_dados https://pt.wikipedia.org/wiki/Engenharia_reversa 26UNIDADE I Introdução da Engenharia de Software para um movimento rápido da análise para o projeto e construção. Além disso, é possível criar relatórios, gerenciar testes, recursos e muito mais. Enterprise Architect suporta o ciclo de vida UML 2.0 com ótimos recursos de fóruns de discussão, construção, execução de códigos, suporte a MOF (Microsoft Operations Framework), WSDL (Web Services Des- cription Language - Linguagem de Descrição de Serviços Web) e XML (Extensible Markup Language). Figura 11 - Logotipo do Software Enterprise Architect Fonte: SPARK (2000) Visual Paradigm for UML é uma ferramenta CASE com várias opções de modela- gem com os diagramas da UML 2.0 e que também oferece suporte a diagramas de requi- sitos SysML e a diagramas ER (Entidade Relacionamento). A ferramenta possui um bom ambiente de trabalho, o que facilita a visualização e manipulação do projeto de modelagem. É uma ferramenta comercial e também oferece suporte a transformações específicas para códigos-fonte de algumas linguagens de programação como, por exemplo, C++ e Java. Figura 12 - Logotipo do Software Visual Paradigm Fonte: VISUAL-PARADIGM (2002) 27UNIDADE I Introdução da Engenharia de Software SAIBA MAIS Segundo Mellor (1994), na Guerra do Golfo, em 1991, um míssil Scud passou pelo escudo antimísseis Patriot e atingiu um acampamento militar próximo de Dhahran, na Arábia Saudita. Ao todo, morreram 28 soldados americanos e 98 ficaram feridos. O software para o míssil Patriot continha uma falha de contagem de tempo acumulativa. O Patriot havia sido projetado para operar apenas por algumas horas por vez, após o que o contador de tempo era reiniciado. Como resultado, a falha jamais havia tido um efeito significativo e, consequentemente, não fora detec- tada. Na Guerra do Golfo, entretanto, a bateria de mísseis Patriot em Dhahran ficou operando por mais de 100 horas ininterruptas. Isso fez com que a discrepância de tempo acumulado se tornasse suficientemente grande para fazer com que o sistema se tornasse impreciso. Durante a Guerra do Golfo, os Estados Unidos enviaram mísseis Patriot a Is- rael para proteção contra mísseis Scud. As forças israelenses detectaram o problema da contagem de tempo apenas após 8 horas e relataram o problema imediatamente para o fabricante nos Estados Unidos. O fabricante corrigiu a falha o mais rápido possível, porém, tragicamente, o novo software chegou somente um dia depois de o acampamento ter sido atingido pelo Scud (MELLOR, 1994). Esta é uma das várias situações relatadas pelo autor Peter Mellor em seu artigo “computer-aided disaster” publicado em 1994. Peter é professor na University of Northampton, em Londres. Este e muitos outros relatos de tragédias com falhas de software nos mostram como é importante investir tempo e dinheiro em engenharia de software para minimizar estes impactos que as falhas de software trazem para as operações das empresas e para nossas vidas. REFLITA “As pessoas apostam seus empregos, seu conforto, sua segurança, sua diversão, suas decisões e suas próprias vidas nos softwares de computadores. Eles precisam estar certos”. Roger S. Pressman - Presidente da R. S. Pressman & Associates, Inc., uma consul- toria especializadaem treinamentos e métodos em engenharia de software. 28UNIDADE I Introdução da Engenharia de Software Nesta primeira unidade foram apresentados alguns conceitos básicos sobre en- genharia de software que serão utilizados no decorrer de todo o livro, por isso, é muito importante que esses conceitos fiquem bem claros para você. A engenharia de software foi proposta para tentar levar a precisão da engenharia para o desenvolvimento de software, pois até aquela época, desenvolver um software era algo que não podia ser mensurado, nem em relação ao custo, levando-se, normalmente, muito mais tempo do que o previsto. E o que acontecia era que não se tinha uma regra, uma sequência de atividades para o desenvolvimento. Você vai ver nas próximas unidades que, para tentar solucionar esse problema, os estudiosos da engenharia de software propuse- ram vários modelos de processos de software, sendo que a empresa pode escolher o que melhor se adequa a ela. Isso tem ajudado muito o desenvolvimento de software. Você vai perceber isso durante o estudo deste livro. Não se preocupe, pois estaremos juntos nas próximas unidades. Até lá! CONSIDERAÇÕES FINAIS 29UNIDADE I Introdução da Engenharia de Software Leitura Complementar A “View of 20th and 21st Century Software Engineering” consiste de uma visão do passado e do futuro da engenharia de software. É uma ótima referência para traçar um paralelo entre a origem da engenharia de software e como ela está se renovando e se adaptando a uma sociedade que cada vez mais exige eficiência dos software e além disso, se tornam cada vez mais dependentes dos aplicativos e programas. Disponível em: <https://www.researchgate.net/publication/221554200_A_view_of_20th_an- d_21st_century_software_engineering> 30UNIDADE I Introdução da Engenharia de Software Material Complementar LIVRO • Título: Engenharia de Software Essencial • Autor: Leandro Costa. • Editora: Amazon Digital Services. • Sinopse: Você está começando no mundo da Engenharia de Software e quer garantir que os prazos sejam cumpridos, com a qualidade das entregas e com o time comprometido de verdade? Você quer entregar valor para seus clientes, desenvolvendo so- luções e não criando pilhas de documentos que ninguém irá ler? Você se identificou? Então esse livro é para você. FILME/VÍDEO • Título: O que um Engenheiro de Software faz? • Ano: 2018. • Sinopse: Nesse vídeo responderemos a esta pergunta que cla- ma por uma resposta mais clara e direta! Será que conseguimos? De uma vez por todas: O que faz um Engenheiro de Software? • Link do vídeo: https://www.youtube.com/watch?v=wdU9L3DqU2w https://www.youtube.com/watch?v=wdU9L3DqU2w 31 Plano de Estudo: • Projeto da Arquitetura • Projeto de Componentes • Projeto de Interface do Usuário • Projeto Baseado em Padrões Objetivos de Aprendizagem: • Esta unidade estará focada em apresentar os conceitos de Projeto de software e tornar o aluno familiarizado como os termos, jargões e processos dessa fase da engenharia de software; • Proporcionar competências e habilidades para que o aluno desenvolva um bom projeto em todas as áreas apresentadas: Arquitetura, Componentes, Interface e Padrões de projeto. UNIDADE II Projetos de Software Professor Mestre Ricardo Bortolo Vieira 32UNIDADE II Projetos de Software INTRODUÇÃO Olá Caro(a) aluno(a)! Neste capítulo meu objetivo é introduzir os conceitos de pro- jeto de software, proporcionando as seguintes discussões: • Decisões necessárias sobre a arquitetura de sis tema durante o processo de projeto de arquitetura; • Os padrões de arquitetura, bem como as maneiras já experimentadas de or- ganizar as arquiteturas de siste ma, que podem ser reusadas em projetos de sistemas; • Conhecerá os padrões de arquiteturas que muitas vezes são usados em dife- rentes tipos de sistemas de aplicações, incluindo sistemas de processamento de transações e os sistemas de processamento de linguagens; • Que a engenharia de software baseada em componen tes está preocupada com o desenvolvimento dos componentes padronizados baseados em modelos de componentes, além da composição destes em sistemas de aplicações; • compreenderá o que se entende por um componente e um mo delo de compo- nente; • Que o projeto de interface busca identificar objetos e ações em interfaces e criar um layout de tela adaptado a essa necessidade. Este processo é baseado em protótipo; • Que o desenvolvimento de software baseado em padrão de projetos é foca- do em encontrar problemas e apresentar propostas a este tipo de problema (solução). Assim, os padrões são apresentado conforme novos problemas são encontrados durante o desenvolvimento e o levantamento da arquitetura do sistema. Além disso, será apresentado a importância de cada um destes projetos, bem como os processos e artefatos necessários para o desenvolvimento destes projetos. Então vamos lá! Bons estudos! 33UNIDADE II Projetos de Software 1 PROJETO DE ARQUITETURA DE SOFTWARE É um processo criativo no qual define-se uma organização de um sistema para sa- tisfazer aos requisitos funcionais e não funcionais. Aspectos que influenciam a arquitetura: • Tipo de sistema a ser desenvolvido; • Experiência do arquiteto de sistemas; • Requisitos específicos para o sistema. O projeto de arquitetura está preocupado com a compreensão de como um sistema deve ser organizado e com a estrutura geral desse sistema. No modelo do processo de desenvolvimento de software, o projeto de arquitetura é o primeiro estágio no processo de projeto de software. Este projeto é o elo crítico entre o projeto e a engenharia de requisitos, pois identifica os principais componentes estruturais de um sistema e os relacionamentos entre eles. Os produtos dessa fase do projeto de arquitetura serão dois artefatos: o modelo de arquitetura, que descreve como o sistema está organizado, e o conjunto de componentes de comunicação (SOMMERVILLE, 2011). Para exemplificar a arquitetura que estou descrevendo aqui apresento a Figura 13 que mostra a arquitetura de repositório de uma determinada IDE (Integrated Development Environment - Ambiente de Desenvolvimento Integrado) . Este tipo de arquitetura é usada para sistemas com grandes volumes de dados a serem armazenados ou em sistemas baseados em informação, pois quando algo é adicionado ou removido do repositório uma ação ou tarefa pode ser realizada. 34UNIDADE II Projetos de Software Figura 13 - Exemplo de arquitetura de um sistema de repositório de código fonte. Fonte: Adaptado de Sommerville, 2011) Em geral, as arquiteturas de sistema são modeladas por meio de diagramas de blocos simples, como na Figura 13. No diagrama, cada caixa representa um componente. Caixas dentro de caixas indicam que o componente foi decomposto em sub-componentes. As setas significam que os dados e/ou sinais de controle são passados de um componente a outro na direção das setas. Diagramas de bloco são uma forma adequada de, durante o processo de projeto, descrever a arquitetura do sistema. Estes diagramas representam uma boa maneira de apoiar a comunicação entre as pessoas envolvidas no processo. Em muitos projetos, eles são a única documentação de arquitetura que existe. No entanto, se a arquitetura de um sistema deve ser bem documen tada, é melhor usar uma notação com semântica bem defi- nida para a descrição de arquitetura. 1.1 Visão da arquitetura Os modelos de arquitetura de um sistema de software podem ser usados para focar a discussão sobre os requisitos de software ou de projeto. Além disso, podem ser usados para documentar um projeto para que este possa ser usado como base para um projeto e uma implementação mais detalhados e para a futura evolução do sistema. É impossível representar todas as informações relevantes sobre a arquitetura de um sistema em um único mo delo de arquitetura, pois cada modelo mostra apenas uma vi- são ou perspectiva do sistema. Pode mostrarcomo um sistema é decomposto em módulos, como os processos de run-time interagem, ou as diferentes formas como são distribuídos 35UNIDADE II Projetos de Software os componentes do sistema através de uma rede. Tudo isso é útil em momentos diferentes, por tanto, para ambos, projeto e documentação, geralmente é preciso apresentar múltiplas visões da arquitetura de software. Existem 4 visões de arquitetura discutidas no livro de Sommerville (2011) e concei- tualmente mais aceitas como válidas. São elas: 1. A visão lógica, que mostra as abstrações fundamentais do sistema como ob- jetos ou classes de objetos. Nessa visão, deveria ser possível relacionar os requisitos de sistema com as entidades. 2. A visão de processo, que mostra como, no tempo de execução, o sistema é composto de processos interativos. Essa visão é útil para fazer julgamentos sobre as características não funcionais do sistema, como desempenho e dispo- nibilidade. 3. A visão de desenvolvimento, que mostra como o software é decomposto para o desenvolvimento, ou seja, apresenta a distribuição do software em componen- tes que são implementados por um único desenvolvedor ou por uma equipe de desenvolvimento. Essa visão é útil para gerentes de software e programadores. 4. Uma visão física, que mostra o hardware do sistema e como os componentes de software são distribuídos en tre os processadores. Essa visão é útil para os engenheiros de sistemas que estão planejando uma implantação do sistema. Na prática, as visões conceituais são, quase sempre, desenvolvidas durante o processo de projeto e são usadas para apoiar a tomada de decisões de arquitetura. Elas são uma maneira de comunicar a essência de um sistema para os diferentes stakeholders (as partes envolvidas no projeto). Durante o processo de projeto, quando diferentes as- pectos do sistema são discu tidos, outras visões também podem ser desenvolvidas, mas não há necessidade de uma descrição completa de todas as perspectivas. Também pode ser possível associar os padrões de arquitetura, com as diferentes visões de um sistema (SOMMERVILLE, 2011). 36UNIDADE II Projetos de Software 1.2 Padrões de arquitetura Um padrão de arquitetura é uma descrição genérica de uma organização do sistema: • Estrutura dos Padrões; • Nome; • Descrição; • Quando é usado; • Vantagens; • Desvantagem. Iremos estudar 3 tipos de arquiteturas: MVC, Repositório e Cliente-Servidor 1.2.1 MVC Tabela 01 - O padrão modelo-visão-controle (MVC). Fonte: Sommerville (2011) Nome Característica Descrição Acrônimo para Model View and Controller. Separa a apresentação e a interação dos dados do sistema. O sistema é estruturado em três componentes lógicos que interagem entre si. O componente Modelo gerencia o sistema de dados e as operações associadas a esses dados. 0 componente Visão define e gerencia como os dados são apresentados ao usuário. O componente Controlador gerencia a interação do usuário (por exemplo, teclas, cliques do mouse etc.) e passa essas interações para a Visão e o Modelo. Quando é usado É usado quando existem várias maneiras de se visualizar e inte- ragir com dados. Também quando são desconhecidos os futuros requisitos de interação e apresentação de dados. Vantagens Permite que os dados sejam alterados de forma independente de sua representação, e vice-versa. Apoia a apresentação dos mesmos dados de maneiras diferentes, com as alterações feitas em uma representação aparecendo em todas elas. Desvantagens Quando o modelo de dados e as interações são simples, pode envolver código adicional e complexidade de código. 37UNIDADE II Projetos de Software 1.2.2 Repositório Tabela 02 - O padrão Repositório. Fonte: Sommerville (2011) Nome Característica Descrição Todos os dados em um sistema são gerenciados em um reposi- tório central, acessível a todos os componentes do sistema. Os componentes não interagem diretamente, apenas por meio do repositório. Quando é usado Você deve usar esse padrão quando tem um sistema no qual grandes volumes de informações são gerados e precisam ser armazenados por um longo tempo. Você também pode usá-lo em sistemas dirigidos a dados, nos quais a inclusão dos dados no repositório dispara uma ação ou ferramenta. Vantagens Os componentes podem ser independentes — eles não precisam saber da existência de outros componentes. As alterações feitas a um componente podem propagar-se para todos os outros. To- dos os dados podem ser gerenciados de forma consistente (por exemplo, backups feitos ao mesmo tempo), pois tudo está em um só lugar. Desvantagens 0 repositório é um ponto único de falha, assim, problemas no repositório podem afetar todo o sistema. Pode haver ineficiências na organização de toda a comunicação através do repositório. Distribuir o repositório através de vários computadores pode ser difícil. 1.2.3 Cliente-Servidor Tabela 03 - O padrão Cliente-Servidor. Fonte: Sommerville (2011) Nome Característica Descrição Em uma arquitetura cliente-servidor, a funcionalidade do sistema está organizada em serviços — cada serviço é prestado por um servidor. Os clientes são os usuários desses serviços e acessam os servidores para fazer uso deles. Quando é usado é usado quando os dados em um banco de dados compartilhado precisam ser acessados apartir de uma série de locais. Como os servidores podem ser replicados, também pode ser usado quando a carga em um sistema é variável. Vantagens A principal vantagem desse modelo é que os servidores podem ser distribuídos através de uma rede. A funcionalidade geral (por exemplo, um serviço de impressão) pode estar disponível para todos os clientes e não precisa ser implementada por todos os serviços. Desvantagens Cada serviço é um ponto único de falhas uscetível a ataques de negação de serviço ou de falha do servidor. O desempenho, bem como o sistema, pode ser imprevisível pois depende da rede. Pode haver problemas de gerenciamento se os servidores forem propriedade de diferentes organizações. 38UNIDADE II Projetos de Software 2 PROJETO DE COMPONENTES DE SOFTWARE Caro(a) aluno(a), neste tópico, irei descrever uma abordagem sobre o reúso de software baseado na composição de componentes reusáveis, padro nizados. E segundo Sommerville (2011), muitos novos sistemas de negócios são desenvolvidos pela configura- ção de sistemas disponíveis no mercado. No entanto, quando uma empresa não pode usar um “sistema de pratelei ra”, porque eles não atendem a seus requisitos, o software de que necessitam precisa ser especialmente desenvolvido. Para o desenvolvimento de software customizado, a engenharia de software baseada em componentes é uma forma eficaz, orientada ao reúso, de desenvolver novos sistemas corporativos. Ainda segundo Sommerville (2011), a engenharia de software baseada em com- ponentes (CBSE, do inglês component-based software engineering) surgiu na década de 1990 como uma abordagem para softwares de desenvolvimento de sistemas com base no reúso de compo nentes de softwares. Sua criação foi motivada pela frustração de proje- tistas, pois o desenvolvimento orientado a objetos não levou a um amplo reúso, como se havia sugerido. As classes de objetos foram muito detalhadas e específicas e muitas vezes precisavam ser associadas com uma aplicação em tempo de compilação. Era preciso ter conhecimento detalhado das classes para usá-las e isso geralmente significava que era necessário ter o código-fonte do componente, o que signifi cava que vender ou distribuir objetos como componentes reusáveis individuais era praticamente impossível. 39UNIDADE II Projetos de Software Os fundamentos da engenharia de software baseada em componentes, segundo Sommerville (2011), são: 1. Os componentes independentes que são completamente especificados por suas interfaces. Deve haver uma se paração clara entre a interface de componente e sua implementação. Isso significa que a implementação de um componentepode ser substituída por outra, sem que se alterem outras partes do sistema. 2. Os padrões de componentes que facilitam a integração destes. Essas normas são incorporadas a um modelo de componentes. Eles definem, no mínimo, como interfaces de componentes devem ser especificadas e como os componentes se comunicam. Alguns modelos vão muito mais longe e definem as interfaces que devem ser imple mentadas por todos os componentes. Se os componentes estão em conformidade com os padrões, sua operação é independente de sua linguagem de programação. Componentes escritos em linguagens diferentes podem ser integrados ao mesmo sistema. 3. O middleware que fornece suporte de software para a integração de componen- tes. Para tornar independentes, os componentes distribuídos trabalham juntos; você precisa de suporte de middleware que lide com as comunicações de componentes. O middleware para suporte ao componente lida, com eficiência, com questões de nível inferior e permite que você se concentre nos problemas relacionados com a aplicação. Além disso, o middleware para su porte de com- ponentes pode fornecer suporte para alocação de recursos, gerenciamento de transações, proteção e concorrência. 4. Um processo de desenvolvimento que é voltado para a engenharia de software baseada em componentes. Você precisa de um processo de desenvolvimento que permita que os requisitos evoluam, dependendo da funcionalida de dos componentes disponíveis. A CBSE apoia-se nos seguintes princípios de projeto na construção de softwares compreensíveis e passíveis de manutenção: 1. Componentes são independentes, então eles não interferem na operação uns dos outros. Detalhes de implemen tação são ocultados. Implementação dos componentes pode ser alterada sem afetar o restante do sistema. 2. Os componentes comunicam-se por meio de interfaces bem definidas. Se essas interfaces forem mantidas, um componente poderá ser substituído por outro, que forneça funcionalidade adicional ou aumentada. 40UNIDADE II Projetos de Software 3. As infraestruturas dos componentes oferecem uma gama de servi- ços-padrão que podem ser usados em sistemas de aplicações, o que reduz a quantidade de códigos novos a serem desenvolvidos. 2.1 Modelo de Componentes Para Sommerville (2011), a Tabela 4 mostra o que deve ser considerado como característica para um componentes seguindo os preceitos da CBSE. Tabela 04 - Característica de um componente. Fonte: Sommerville (2011) Característica do componente Descrição Padronizado A padronização de componentes significa que um componente usado em um processo CBSE precisa obedecer a um modelo de componentes padrão. Esse modelo pode definir as interfaces de componentes, metadados de componente, documentação, com- posição e implantação. Independente Um componente deve ser independente, deve ser possível compor e implantá-lo sem precisar usar outros componentes específicos. Nessas situações, em que o componente precisa dos serviços prestados externamente, estes devem ser explicitamente defini- dos em uma especificação de interface ‘requires’. Passível de com- posição Para um componente ser composto, todas as interações externas devem ter lugar por meio de interfaces publicamente definidas. Além disso, ele deve proporcionar acesso externo a informações sobre si próprio, como seus métodos e atributos. Implantável Para ser implantável, um componente dever ser autocontido. Deve ser capaz de operar como uma entidade autônoma em uma plataforma de componentes que forneça uma implementação do modelo de componentes, o que geralmente significa que o com- ponente é binário e não tem como ser compilado antes de ser implantado. Se um componete é implantado como um serviço, ele não precisa ser implantado por um usuário de um componente. Pelo contrário, é implantado pelo prestador do serviço. Documentado Os componentes devem ser completamente documentados para que os potenciais usuários possam decidir se satisfazem a suas necessidades. A sintaxe e, idealmente, a semântica de todas as interfaces de componentes devem ser especificadas. Os componentes têm duas interfaces relacionadas, como mostrado na Figura 14. Essas in- terface refletem os serviços que o componente fornece e os serviços de que o componente necessita para funcionar corretamente: 41UNIDADE II Projetos de Software • A interface ‘provides’ define os serviços prestados pelo componente. Essa inter- face, essencialmente, é uma API (Application Programming Interface - Interface de Programação de Aplicativo) de componente. Ela define os métodos que podem ser chamados por um usuário do componente. • A interface ‘requires’ especifica quais serviços devem ser fornecidos por outros componentes no sistema se um componente deve funcionar corretamente. Se eles não estiverem disponíveis, o componente não funcionará. Isso não compro- mete a independência ou a capacidade de implantação de um componente, pois a interface ‘requires’ não define como esses serviços deverão ser prestados. Figura 14 - Interface de componentes. Fonte: Sommerville (2011) Os elementos básicos de um modelo ideal de componentes são apresentados na Figura 15, em um diagrama que mostra os elementos de um modelo de componentes e domo eles definem a utilização e a processo de implantação (SOMMERVILLE, 2011). 1. Interfaces. Os componentes são definidos pela especificação de suas interfaces. O modelo de componente especifica como as interfaces devem ser definidas e os elementos, como nomes de operação, parâmetros e exceções, que devem ser incluídos na definição de interface. O modelo também deve especificar a linguagem usada para definir as interfaces de componente. Alguns modelos de componentes exigem interfaces especí ficas que devem ser definidas por um componente. Esses modelos são usados para compor o componente com a infraestrutura de modelo de componente, que fornece serviços padronizados, como gerenciamento de proteção e transação. 2. Uso. Para que componentes sejam distribuídos e acessados remotamente, eles precisam ter um nome exclu sivo ou identificador associado a eles. Isso deve ser globalmente exclusivo — por exemplo, no EJB, um nome hierárquico é gerado com a raiz baseada em um nome de domínio de Internet. Os serviços têm um único URI (Uniform Resource Identifier). 42UNIDADE II Projetos de Software Figura 15 - Elementos básicos de um modelo de componentes. Fonte: Sommerville (2011) 2.2 Processos CBSE Os processos CBSE são processos de software que oferecem suporte a engenha- ria de software baseada em componentes. Consideram as possibilidades de reúso e as diferentes atividades do processo envolvidas no de senvolvimento e uso de componentes reusáveis. A Figura 16 apresenta uma visão geral dos processos CBSE. • Desenvolvimento para reúso. Esse processo está interessado no desenvolvi- mento de componentes ou serviços que serão reusados em outras aplicações. Esse processo geralmente envolve generalizar os componentes exis tentes. • Desenvolvimento com reúso. Esse é o processo de desenvolvimento de novas aplicações usando componentes e serviços existentes. Esses processos têm objetivos diferentes e, portanto, incluem atividades diferentes. No desenvolvimento por processo de reúso, o objetivo é produzir um ou mais componentes reusáveis. Você conhece os com ponentes com os quais trabalhará, além de ter acesso a seu código-fonte para generalizá-lo. Em desenvol vimento com reúso, você não sabe quais componentes estão disponíveis, por isso você precisa descobrir esses componentes e projetar seu sistema para fazer o uso mais eficiente deles. Você não pode ter acesso ao código-fonte do componente. Na Figura 16, você pode ver que os processos básicos CBSE com e para reúso apoiam os processos que estão preocupados com a aquisição de componente, gerencia- mento de componente e certificação de componente. 43UNIDADEII Projetos de Software Figura 16 - Processos CBSE. Fonte: Sommerville (2011) 44UNIDADE II Projetos de Software 3 PROJETO DE INTERFACE DE USUÁRIO Caro(a) aluno(a), neste capítulo, iremos discutir sobre a Interface com o Usuário e a importância dela para os softwares e aplicativos da atualidade. Conforme PFLEIGER (2004), o tipo de projeto Interface de Usuário, produz uma parte fundamental de um software. Ele é a parte do sistema visível para o usuário, através da qual, ele se comunica para realizar suas tarefas. Pode se tornar uma fonte de motivação e até, dependendo de suas características, uma grande ferramenta para o usuário, ou então, se mal projetada, pode se transformar em um ponto decisivo na rejeição de um sistema. As interfaces atuais têm como objetivo fornecer uma interação pessoa-computador o mais “amigável” possível (pois na verdade não são). Dessa forma, ela deve ser fácil de ser usada pelo usuário, fornecendo seqüências simples e consistentes de interação, mostrando claramente as alternativas disponíveis a cada passo da interação sem confundir nem deixar o usuário inseguro. Ela deve passar despercebida para que o usuário possa se fixar somente no problema que deseja resolver utilizando o sistema. Visando tornar a interação com o usuário mais natural e menos hostil, às interfaces passaram a ser constituídas, entre outros itens, por elementos gráficos, onde imagens representando dados e tarefas disponíveis são manipuladas diretamente pelo usuário. Na realidade, tais itens não constituem os dados nem as tarefas; são apenas seus signos, isto é tudo que possa ser assumido como um substituto significante de outra coisa qualquer. 45UNIDADE II Projetos de Software Segundo Mandel (1997) as três regras de ouro dos projetos de interface de usuário são: 1. Deixar o usuário no comando; 2. Reduzir a carga de memória do usuário; 3. Tornar a interface consistente. Essas regras formam, na verdade, a base para um conjunto de princípio para o projeto de interface do usuário que orienta esse importante aspecto do projeto de software. 3.1 Usuário no Comando A maioria das restrições de interface impostas por um designer tem a intenção de simplificar o modo de interação. Mas para quem? Como designer, você pode se sentir tentado a introduzir restrições e limitações para simplificar a implementação da interface. O resultado pode ser uma interface fácil de construir, mas frustrante de usar. Mandel (1997) define vários princípios de design que permitem ao usuário manter este controle tão desejado: • Defina os modos de interação de uma maneira que não force o usuário a ações desnecessárias ou indesejadas; • Providencie interação flexível. Como usuários diferentes têm diferentes prefe- rências de interação, as opções devem ser fornecidas; • Permitir que a interação do usuário seja interrompível e que possa ser desfeita; • Agilize a interação à medida que os níveis de habilidade avançam e permitem que a interação seja personalizada; • Ocultar internos técnicos do usuário casual. A interface do usuário deve mover o usuário para o mundo virtual do aplicativo; • Design para interação direta com objetos que aparecem na tela. 3.2 Reduzir a carga de memória do usuário Quanto mais um usuário tiver de se lembrar, mais sujeita a erros será a interação com o sistema. É por essa razão que uma interface do usuário bem desenhada não exaure a memória do usuário. Sempre que possível, o sistema deve “se lembrar” de informações pertinentes e auxiliar o usuário em um cenário de interação que o ajude a recordar-se. Mandel (1997) define princípios de projeto que possibilitam a uma interface reduzir a carga de memória do usuário: • Reduza a demanda de memória recente; 46UNIDADE II Projetos de Software • Estabeleça defaults significativos; • Defina atalhos intuitivos; • O layout visual da interface deve se basear na metáfora do mundo real; • Revele as informações de maneira progressiva. A interface deve ser organizada hierarquicamente. 3.3 Tornar a interface consistente A interface deve apresentar e obter informações de forma consistente. Isso implica: 1. Todas as informações visuais são organizadas de acordo com regras de projeto mantidas ao longo de todas as exibições de telas; 2. Mecanismos de entrada são restritos a um conjunto limitado que é usado de forma consistente por toda a aplicação; 3. Mecanismos de navegação para passar de uma tarefa a outra são definidos e implementados de maneira consistente. Mandel (1997) define um conjunto de princípios de projeto que ajudam a tornar a interface consistente: • Permita ao usuário inserir a tarefa atual em um contexto significativo. Muitas interfaces implementam camadas de interações complexas com dezenas de imagens de tela; • Mantenha a consistência ao longo de uma família de aplicações; • Se modelos interativos anteriores tiverem criado expectativa nos usuários, não faça alterações a menos que haja uma forte razão para isso. 47UNIDADE II Projetos de Software 4 PADRÕES DE PROJETO Caro(a) aluno(a), neste capítulo, trataremos de padrões de projeto. Este assunto trata sobre soluções gerais para um problema que ocorre com frequência dentro do contex- to de projetos de software. Segundo Pressman (2011), O projeto baseado em padrões cria uma nova apli- cação através da busca de um conjunto de soluções comprovadas para um conjunto de problemas claramente delineados. Cada problema é descrito por um padrão de projeto que foi catalogado e investigado por outros engenheiros de software que depararam com o problema e implementaram a solução ao projetarem outras aplicações. Cada padrão de projeto nos oferece uma abordagem comprovada para parte do problema a ser resolvido. Ainda segundo Pressman (2011), um engenheiro de software examina cada pro- blema que surge para uma nova aplicação e tenta encontrar uma solução relevante por meio de pesquisa em um ou mais repositórios de padrões. Ao usarmos padrões de projeto, podemos encontrar uma solução comprovada para um problema específico. À medida que cada padrão é aplicado, são integradas soluções, e a aplicação a ser construída se aproxi- ma cada vez mais de um projeto completo. 48UNIDADE II Projetos de Software Os melhores projetistas, de qualquer área, têm uma habilidade excepcional de visualizar padrões que caracterizam um problema e padrões correspondentes que podem ser combinados para criar a solução. Embora o projeto baseado em padrões seja relativamente novo no campo de de- senvolvimento de software, a tecnologia industrial tem usado projeto baseado em padrões há décadas, talvez há séculos. Catálogos de mecanismos e configurações padronizadas fornecem elementos de projeto que são usados para criar automóveis, aeronaves, máqui- nas-ferramenta e robôs. A aplicação de projeto baseado em padrões ao desenvolvimento de software promete os mesmos benefícios para o software como os já proporcionados à tecnologia industrial: previsibilidade, redução de riscos e maior produtividade. 4.1 Contexto do projeto baseado em padrões Ao longo do processo de projeto, e segundo Pressman (2011), devemos buscar toda oportunidade de aplicar padrões de projeto existentes em vez de criar novos. O projeto baseado em padrões não é utilizado isoladamente. Os conceitos e as técnicas discutidas para projeto da arquitetura, de componentes e para interfaces do usuá- rio são usados em conjunto com uma abordagem baseada em padrões. O conjunto de diretrizes e atributos de qualidade serve como base para todas as decisões de projeto de software. As próprias decisões são influenciadas por um conjunto de conceitos de projeto fundamentais que são atingidos usando-se heurística que evoluiu ao longo de várias dé- cadas e práticas melhores propostas para fazer com que o projeto seja mais fácil de ser realizado e mais efetivo como base para a construção (PRESSMAN, 2011). O papel do projetobaseado em padrões está ilustrado na Figura 17. Um projetista de software inicia com um modelo de requisitos que apresenta uma representação abstrata do sistema. O modelo de requisitos descreve o conjunto de problemas, estabelece o con- texto e identifica o sistema de forças que exerce domínio. Talvez sugira o projeto de maneira abstrata, mas o modelo de requisitos faz pouco para representar o projeto explicitamente. Ao iniciar seu trabalho como projetista, é sempre importante manter os atributos de qualidade como foco principal. Esses atributos estabelecem uma maneira de avaliar a qualidade do software, mas pouco fazem para ajudar a atingi-lo efetivamente. 49UNIDADE II Projetos de Software Figura 17 - Contexto do projeto baseado em padrões. Fonte: Pressman (2011) Consequentemente, devemos aplicar técnicas comprovadas para traduzir as abs- trações contidas no modelo de requisitos de maneira mais concreta que é o projeto de software. Para tanto, usaremos os métodos e as ferramentas de modelagem disponíveis para projeto da arquitetura, de componentes e para interfaces. Mas apenas quando de- pararmos com um problema, um contexto e um sistema de forças que ainda não foram resolvidos anteriormente. Se já existir uma solução, devemos usá-la, e isso significa aplicar uma abordagem de projeto baseado em padrões. 4.2 Padrões de Projeto de Arquitetura Conforme Pressman (2011), os padrões de arquitetura para software definem uma abordagem específica para tratar alguma característica do sistema e definem uma série de domínios de padrões de arquitetura. Exemplos representativos são apresentados por Pressman (2011): Controle de acesso. Há várias situações em que o acesso a dados, recursos e 50UNIDADE II Projetos de Software funcionalidade fornecidos por uma aplicação é limitado a usuários finais especificamente definidos. Do ponto de vista da arquitetura, o acesso a alguma parte da arquitetura de software deve ser rigorosamente controlado. Concorrência. Muitas aplicações têm de tratar múltiplas tarefas em um modo que simule paralelismo (isso ocorre sempre que vários componentes ou tarefas “paralelas” são administradas por um único processador). Há uma série de maneiras diferentes com a qual uma aplicação pode tratar a concorrência, e cada uma delas pode ser apresentada por um padrão de arquitetura distinto. Por exemplo, uma abordagem é usar um padrão Operating System Process Management (Sistema Operacional de Gerenciamento de processos) que fornece recursos embutidos no sistema operacional que permitem aos componentes exe- cutarem de forma concorrente. O padrão também incorpora funcionalidade que gerencia a comunicação entre processos, agendamento e outras capacidades exigidas para alcançar a concorrência. Distribuição. O problema da distribuição trata a maneira pela qual os sistemas ou componentes nos sistemas se comunicam entre si em um ambiente distribuído. São consi- derados dois subproblemas: (1) a maneira pela qual as entidades se conectam entre si e (2) a natureza da comunicação que ocorre. O padrão de arquitetura mais comum estabelecido para tratar o problema de distribuição é o padrão Broker (agente). Um agente atua com um “intermediário” entre o componente-cliente e o componente-servidor. O cliente envia uma mensagem ao agente (contendo todas as informações apropriadas para a comunicação a ser efetuada) e o agente completa a conexão. Persistência. Os dados persistem se sobreviverem depois da execução do pro- cesso que o criou. Os dados persistentes armazenados em um banco de dados ou arquivo podem ser lidos ou modificados por outros processos posteriormente. Em ambientes orien- tados a objetos, a ideia de um objeto persistente estende um pouco mais o conceito de persistência. Os valores de todos os atributos do objeto, o estado geral do objeto e outras informações complementares são armazenados para recuperação e uso futuro. Em geral, usam-se dois padrões de arquitetura para obter a persistência — o padrão Database Ma- nagement System (sistema de gerenciamento de bancos de dados), que aplica o recurso de armazenamento e recuperação de um DBMS à arquitetura da aplicação, ou o padrão Application Level-Persistence (persistência no nível de aplicação) que constrói recursos de persistência na arquitetura da aplicação. 51UNIDADE II Projetos de Software Antes que qualquer um dos padrões de arquitetura citados anteriormente possa ser escolhido, ele deve ser avaliado em termos de sua adequação para a aplicação e estilo de arquitetura geral, bem como o contexto e o sistema de forças que ele especifica. 4.3 Padrões de Projeto de Componentes Ainda conforme Pressman (2011), os padrões de projeto de componentes nos dão soluções comprovadas que tratam um ou mais subproblemas extraídos do modelo de requisitos. Em muitos casos, os padrões de projeto desse tipo se concentram em algum elemento funcional de um sistema. Por exemplo, em uma aplicação web temos o seguinte subproblema de projeto: Como podemos obter especificações de um determinado produto e suas informações relacionadas para um site de vendas? Tendo enunciado o subproblema que deve ser resolvido, devemos considerar agora o contexto e o sistema de forças que afetam uma solução. Assim, podemos perceber que a solução para o subproblema envolve uma pesquisa. Como pesquisar é um problema muito comum, não deve ser nenhuma surpresa a existência de muitos padrões relacionados à pesquisa. Pressman (2011) apresenta alguns destes padrões: • AdvancedSearch. Os usuários precisam encontrar um item específico em um grande conjunto de itens. • HelpWizard. Os usuários precisam de ajuda sobre certo tópico relativo ao site ou quando eles precisam encontrar uma página específica dentro deste site. • SearchArea. Os usuários precisam encontrar uma página Web. • SearchTips. Os usuários precisam saber como controlar o mecanismo de bus- ca. • SearchResults. Os usuários têm de processar uma lista de resultados de uma busca. • SearchBox. Os usuários têm de encontrar um item ou informações específicas. 4.4 Padrões de Projeto de Interface de Usuário Foram propostas centenas de padrões para interfaces do usuário nos últimos anos. A maior parte deles cai em uma das seguintes categorias de padrões apresentados a seguir. 52UNIDADE II Projetos de Software Toda a Interface com o Usuário fornece orientação para estrutura de alto nível e navegação por toda a interface. Pressman (2011) apresenta algumas categorias de padrões na Tabela 05. Tabela 05 - Tipos de Padrões de Projeto de Interface de Usuário. Fonte: Pressman (2011) Padrão Descrição Detalhes TopLevelNavigation Usada quando um site ou uma aplicação implementa uma série de funções prin- cipais. Oferece um menu de alto nível, geralmente aco- plado a um logo ou imagem identificadora, que possibilita a navegação direta para qualquer uma das principais funções do sistema. Funções principais (em geral limitadas a quatro a sete nomes de função) são lista- das na parte superior da tela (possível também formatos de colunas verticais) em uma linha horizontal de texto. Cada nome fornece um link para uma fonte de informações ou função apropriada. Geralmente, usada com o padrão BreadCrumbs discutido mais à frente. CardStack Usado quando uma série de subfunções ou categorias de conteúdo específicas rela- cionadas com um recurso ou função deve ser selecionada em ordem aleatória. Dá a aparência de uma pilha de fi- chas indexadoras, cada uma delas selecionável com um clique de mouse e cada qual representando subfunções ou categorias de conteúdo específicas. As fichas indexadoras são uma metáfora bem compreendida e fácil para o usuário manipular. Cada ficha indexadora (se- parador) pode ter um formato ligeiramente diverso. Alguns poderão exigir entrada de da- dos e possuir botões ou outros mecanismos de navegação. Poderiam ser combinados com outros padrões como
Compartilhar