Baixe o app para aproveitar ainda mais
Prévia do material em texto
ANÁLISE E PROJETO ORIENTADO A OBJETOS PROFESSORES Me. Déverson Rogério Rando Esp. Janaína Aparecida de Freitas ACESSE AQUI O SEU LIVRO NA VERSÃO DIGITAL! https://apigame.unicesumar.edu.br/qrcode/2888 EXPEDIENTE C397 CENTRO UNIVERSITÁRIO DE MARINGÁ. Núcleo de Educação a Distância. RANDO, Déverson Rogério; FREITAS, Janaína Aparecida de. Análise e Projeto Orientado a Objetos. Déverson Rogério Rando; Janaína Aparecida de Freitas. Maringá - PR.: UniCesumar, 2020. Reimpresso em 2023. 176 p. “Graduação - EaD”. 1. Análise 2. Projeto Orientado a Objeto 3. Informática. EaD. I. Título. FICHA CATALOGRÁFICA NEAD - Núcleo de Educação a Distância Av. Guedner, 1610, Bloco 4Jd. Aclimação - Cep 87050-900 | Maringá - Paraná www.unicesumar.edu.br | 0800 600 6360 Coordenador(a) de Conteúdo Flavia Lumi Matuzawa Projeto Gráfico e Capa Arthur Cantareli, Jhonny Coelho e Thayla Guimarães Editoração Flávia Thaís Pedroso Design Educacional Paulo Victor Souza e Silva Revisão Textual Carla Cristina Farinha e Ariane Andrade Fabreti Ilustração Bruno Pardinho e André Azevedo Fotos Shutterstock CDD - 22 ed. 005.1 CIP - NBR 12899 - AACR/2 978-85-459-0113-6 Impresso por: Bibliotecário: João Vivaldo de Souza CRB- 9-1679 DIREÇÃO UNICESUMAR NEAD - NÚCLEO DE EDUCAÇÃO A DISTÂNCIA Diretoria Executiva Chrystiano Mincoff, James Prestes, Tiago Stachon Diretoria de Design Educacional Débora Leite Diretoria Diretoria de Graduação e Pós-graduação Kátia Coelho Diretoria de Permanência Leonardo Spaine Head de Curadoria e Inovação Tania Cristiane Yoshie Fukushima Head de Produção de Conteúdo Franklin Portela Correia Gerência de Contratos e Operações Jislaine Cristina da Silva Gerência de Produção de Conteúdo Diogo Ribeiro Garcia Gerência de Projetos Especiais Daniel Fuverki Hey Supervisora de Projetos Especiais Yasminn Talyta Tavares Zagonel Supervisora de Produção de Conteúdo Daniele C. Correia Reitor Wilson de Matos Silva Vice-Reitor Wilson de Matos Silva Filho Pró-Reitor de Administração Wilson de Matos Silva Filho Pró-Reitor Executivo de EAD William Victor Kendrick de Matos Silva Pró-Reitor de Ensino de EAD Janes Fidélis Tomelin Presidente da Mantenedora Cláudio Ferdinandi BOAS-VINDAS Neste mundo globalizado e dinâmico, nós tra- balhamos com princípios éticos e profissiona- lismo, não somente para oferecer educação de qualidade, como, acima de tudo, gerar a con- versão integral das pessoas ao conhecimento. Baseamo-nos em 4 pilares: intelectual, profis- sional, emocional e espiritual. Assim, iniciamos a Unicesumar em 1990, com dois cursos de graduação e 180 alunos. Hoje, temos mais de 100 mil estudantes espalhados em todo o Brasil, nos quatro campi presenciais (Maringá, Londrina, Curitiba e Ponta Grossa) e em mais de 500 polos de educação a distância espalhados por todos os estados do Brasil e, também, no exterior, com dezenas de cursos de graduação e pós-graduação. Por ano, pro- duzimos e revisamos 500 livros e distribuímos mais de 500 mil exemplares. Somos reconhe- cidos pelo MEC como uma instituição de exce- lência, com IGC 4 por sete anos consecutivos e estamos entre os 10 maiores grupos educa- cionais do Brasil. A rapidez do mundo moderno exige dos edu- cadores soluções inteligentes para as neces- sidades de todos. Para continuar relevante, a instituição de educação precisa ter, pelo menos, três virtudes: inovação, coragem e compromis- so com a qualidade. Por isso, desenvolvemos, para os cursos de Engenharia, metodologias ati- vas, as quais visam reunir o melhor do ensino presencial e a distância. Reitor Wilson de Matos Silva Tudo isso para honrarmos a nossa mis- são, que é promover a educação de qua- lidade nas diferentes áreas do conheci- mento, formando profissionais cidadãos que contribuam para o desenvolvimento de uma sociedade justa e solidária. P R O F I S S I O N A LT R A J E T Ó R I A Me. Déverson Rogério Rando Mestre em Ciência da Computação pela Universidade Estadual de Maringá (UEM). Es- pecialista em Engenharia de Software pela Universidade Norte do Paraná. Graduado em Geografia pela Universidade Estadual de Londrina e Análise e Desenvolvimento de Sistemas pela Unicesumar. Atualmente, coordenador do Curso de Bacharelado em Sistemas de Informação da FAP – Faculdades Apucarana. Professor dos cursos de Técnico em Redes e Informática, respectivamente, no Senac e Senai, nas disci- plinas de Banco de Dados, Análise Estruturada e OO, Organização e Arquitetura de Computadores, Computação Gráfica, IHC, Algoritmos, Linguagens de Programação, Sistemas de Informações Geográficas e Trabalho de Conclusão de Curso. http://lattes.cnpq.br/3108532655755995 Esp. Janaína Aparecida de Freitas Possui graduação em Informática pela Universidade Estadual de Maringá (2010) e especialização em MBA em Teste de Software pela Unicesumar (2012). Atualmente, cursa o Programa de Mestrado em Ciência da Computação na Universidade Estadual de Maringá (UEM) e é graduanda de Letras – Português/Inglês na Unicesumar. Atua, há três anos, como professora mediadora, professora conteudista em gravação de aulas ao vivo e conceituais nos cursos do NEAD – Núcleo de Educação a Distância, da Unicesumar, para os cursos de graduação de Sistemas para Internet, Análise e Desenvolvimento de Sistemas, Gestão da Tecnologia da Informação e Engenharia de Software, nas disciplinas de Engenharia de Software, Design Gráfico, Tópicos Especiais, Gerenciamento de Software, Design de Interação Humano-Computador, Projeto de Implementação e Teste de Software. Além disso, tem experiência em iniciativa privada na área de Análise de Sistemas e Testes de Software. http://lattes.cnpq.br/4906244382612830 A P R E S E N TA Ç Ã O D A D I S C I P L I N A ANÁLISE E PROJETO ORIENTADO A OBJETOS Caro(a) aluno(a)! Seja bem-vindo(a) à disciplina de Análise e Projeto Orientado a Objetos (OO). Esta disciplina abordará vários aspectos relacionados à análise e ao projeto de sistemas orien- tados a objetos, utilizando, como notação, a linguagem de modelagem UML. Apresentamos a você, aluno(a), o livro que conduzirá seus estudos, auxiliando no aprendizado de análise e projeto orientado a objetos com a UML. A Unidade 1 apresenta os conceitos iniciais sobre a análise e os projetos orientados a objetos. Estudaremos como surgiu e como ocorreu a evolução dos métodos orientados a objetos. Abordaremos, também, as características desses principais métodos, conheceremos os con- ceitos básicos que envolvem a Orientação a Objetos para dar subsídio às unidades subse- quentes. E, por fim, veremos os principais diagramas da UML utilizados na documentação de software. Na Unidade 2, estudaremos as fases que compreendem a análise e o projeto de um software. Entraremos em contato com dois dos modelos de processos: cascata e evolucionário. Vere- mos as vantagens e desvantagens da utilização de cada um desses métodos, abordaremos, também, os requisitos de software e conheceremos os procedimentos mínimos para a obten- ção de um software de qualidade. Encerraremos a unidade falando sobre a importância da construção de casos de uso no levantamento de requisitos bem como a notação necessária para a construção de diagramas de casos de uso. A Unidade 3 é toda dedicada à confecção do diagrama de classes responsável por demons- trar a estrutura estática do sistema. Conheceremos, em detalhes, a notação para o diagrama de classes. Abordaremos os conceitos e a assinatura da declaração de atributos e métodos. Veremos como ocorrem as ligações entre as classes e como definir a multiplicidade entre elas. Discutiremos, ainda, as várias formas de associar as classes, sejam elas unária, binária, ternária, sejam elas associativa, de agregação ou generalização. D A D I S C I P L I N AA P R E S E N TA Ç Ã O Na Unidade 4, conheceremos mais três diagramas, essenciais em análise e projeto OO, que utilizaremos para refinar o diagrama de classes que representa a estrutura do sistema. O primeiro diagramaque veremos, nesta unidade, é o de sequência, cujo objetivo é estudar as interações entre os objetos, considerando a dimensão tempo. O segundo diagrama que ve- remos é o de estados, que tem como objetivo especificar o comportamento das classes mais complexas, utilizando máquinas de estado. Já o terceiro diagrama é o de comunicação, que contém as mesmas informações do diagrama de sequência, porém não considera o tempo, e sim a ordem da comunicação. Por fim, na Unidade 5, resolveremos, juntos, um estudo de caso, no qual teremos a oportu- nidade de apresentar, de forma prática, a construção dos diagramas citados na elaboração da análise e do projeto de um software. Dessa forma, reforçaremos todos os conceitos tra- balhados nas unidades anteriores. Ao longo deste livro, você encontrará indicações de leitura complementar, as quais enrique- cerão o seu conhecimento sobre projetos. É importante que você desenvolva as atividades de estudo para fixar o conteúdo abordado e identificar eventuais dificuldades. Preparados(as)? Vamos lá! ÍCONES Sabe aquela palavra ou aquele termo que você não conhece? Este ele- mento ajudará você a conceituá-la(o) melhor da maneira mais simples. conceituando No fim da unidade, o tema em estudo aparecerá de forma resumida para ajudar você a fixar e a memorizar melhor os conceitos aprendidos. quadro-resumo Neste elemento, você fará uma pausa para conhecer um pouco mais sobre o assunto em estudo e aprenderá novos conceitos. explorando ideias Ao longo do livro, você será convidado(a) a refletir, questionar e transformar. Aproveite este momento! pensando juntos Enquanto estuda, você encontrará conteúdos relevantes online e aprenderá de maneira interativa usando a tecno- logia a seu favor. conecte-se Quando identificar o ícone de QR-CODE, utilize o aplicativo Unicesumar Experience para ter acesso aos conteúdos online. O download do aplicativo está disponível nas plataformas: Google Play App Store CONTEÚDO PROGRAMÁTICO UNIDADE 01 UNIDADE 02 UNIDADE 03 UNIDADE 05 UNIDADE 04 FECHAMENTO INTRODUÇÃO AO ESTUDO DE ORIENTAÇÃO A OBJETOS 10 CASOS DE USO 40 70 DIAGRAMA DE CLASSES 102 DIAGRAMAS DE SEQUÊNCIA, ESTADO E COLABORAÇÃO 130 ESTUDO DE CASO 168 CONCLUSÃO GERAL 1 INTRODUÇÃO AO ESTUDO de orientação a objetos PLANO DE ESTUDO A seguir, apresentam-se as aulas que você estudará nesta unidade: • Introdução à Orientação a Objetos • Evolução dos Métodos OO • Conceitos Básicos de OO • Principais Diagramas da UML. OBJETIVOS DE APRENDIZAGEM Entender a importância de análise e projeto • Conhecer a evolução dos métodos OO • Compreender as características dos métodos OO e seus diferentes termos • Conhecer os principais diagramas da UML. PROFESSORES Me. Déverson Rogério Rando Esp. Janaína Aparecida de Freitas INTRODUÇÃO Caro(a) aluno(a), iniciamos a primeira unidade do livro Análise e Projeto Orientado a Objetos falando sobre a importância da análise de sistemas dentro do projeto de produção de software. Veremos que a análise de sistemas é a atividade inicial do processo de desenvolvimento de software. É nessa fase que determinamos e especifi- camos o que um software deve fazer. Também, nessa fase, verificamos as circunstâncias sob as quais o software deve operar, envolvendo, geralmente, um esforço colaborativo entre analistas de sistemas e usuários. Em seguida, veremos como os métodos surgiram e como aconteceu sua evolução. Abordaremos, a partir do primeiro método orientado a objetos, proposto por Shlaer e Mellor em 1988, o OOSA, até chegarmos à Unified Modeling Language, UML, que será a linguagem que utilizaremos para as nossas análises e nossos projetos OO. Mesmo utilizando a UML, é importante conhecermos as características dos principais métodos OO, uma vez que a UML é a unificação de vários métodos que serão apresentados. Ou seja, a evolução de todos os outros métodos permitiu que chegássemos a uma unificação que, na verdade, apropria-se das melhores características dos demais métodos. Nesta unidade, também conheceremos e entenderemos os conceitos e termos utilizados na análise e no projeto OO. Dentre os conceitos que veremos, estão os de objeto, abstração, classe, instância, atributo, operação, mensagem, evento, estado e parâmetro. Com esses conceitos iniciais, você terá uma visão geral sobre OO. Conheceremos, ainda, os principais diagramas da UML utilizados na análise e no projeto de softwares, dentre eles: o diagrama de casos de uso utilizado na fase de análise para criar um cenário para o software, o dia- grama de classes que modela a estrutura estática do sistema, o diagrama de sequência, o de colaboração e o de estado. Então, o que estamos esperando? Vamos ao trabalho? Boa leitura a todos. U N ID A D E 1 12 1 INTRODUÇÃO À ORIENTAÇÃO a objetos ANÁLISE E PROJETO O processo de desenvolvimento de um sistema computacional tem, na análise, sua atividade inicial. Atividade esta que determina e especifica o que um sistema deve fazer, além das circunstâncias sob as quais ele deve operar, envolvendo um esforço colaborativo que abrange analistas de sistemas e usuários. Os analistas procuram obter, a partir dos usuários, em um processo gradual e cumulativo, o maior conhecimento possível acerca do domínio do problema e do respectivo ambiente. De acordo com Sommerville (2011), podemos chamar de “análise de sistemas” o que faz parte da “engenharia de requisitos”. Acrescentar o termo “engenharia” implica dizer que técnicas sistemáticas deverão ser utilizadas para assegurar que os requisitos do sistema sejam consistentes, relevantes e completos. A análise de sistemas é uma atividade de suma importância no processo de desenvolvimento destes, por ser uma etapa inicial e, também, porque as falhas terão efeitos em cadeia nas etapas subsequentes, assim como no produto final. A determinação incorreta dos requisitos levará à obtenção e à disponibilização de sistemas com- putacionais inadequados. U N IC ES U M A R 13 Resumindo: a análise é a solução conceitual dada ao problema. Marca o início da definição informática, mas sem levar em conta detalhes da implementação, tais como a linguagem e o sistema gerenciador de banco de dados a serem utilizados. Preocupa-se, principalmente, com as classes do domínio do problema e suas relações e, também, com os casos de uso. Se, por um lado, a análise é a solução conceitual, por outro, o projeto consiste na solução computacional aplicada ao problema. Dizer onde acaba a análise e se inicia o projeto é muito complicado, uma vez que o projeto é o resultado de refinamentos sucessivos do modelo con- ceitual de análise. A Orientação a Objetos fez com que fosse alterado o enfoque necessário para desenvolver um sistema, enquanto que, na programação estruturada, havia, nitidamente, uma visão sequencial e bem dividida, como os programas, que exe- cutam determinados processos e tratam determinados dados. Na Orientação a Objetos, passamos a visualizar classes responsáveis por atributos, com operações criadas para tratá-los, e a execução das atividades dos sistemas passa a depender da interação dessas classes. Análise e projeto OO Na década de 80, houve preponderância dos métodos estruturados para o desen- volvimento de software. Atualmente, o paradigma OO é mais forte e, por isso, é importante diferenciar entre análise e projeto estruturado e orientado a objetos. A análise e o projeto estruturados têm, como ênfase, as funções que atuam sobre os dados, ou seja, todo o processo que se deseja informatizar é compreendi- do como um conjunto de funções com dados de entrada, processamento e saída. Yourdon (1990) apresenta as principais características: ■ Modularidade e coesão. ■ Desenvolvimento top-down (diferentes níveis de abstração). Os diagramas que apoiam a análise e o projeto estruturado são: ■ Diagrama Entidade e Relacionamento (DER). ■ Dicionários de dados. ■ Diagrama de Fluxo de Dados (DFD). U N ID A D E 1 14 ODER modela a estrutura de dados parados, ou seja, é o modelo conceitual do sistema, mostra-nos as entidades e seus relacionamentos. Neste modelo, muitos detalhes não são mostrados, ficando a cargo do dicionário de dados os detalhes de nomes de atributos, tipos de dados, comprimento e demais restrições de dados. O DFD modela o fluxo destes, em outras palavras, mostra os dados em movimento, como ocorre a interação entre as diversas entidades (depósito) do sistema. A Orientação a Objetos – ou, simplesmente, OO – é uma estratégia de de- senvolvimento de software que o organiza como uma coleção de objetos que contém tanto a estrutura dos dados quanto o comportamento deles. A Orientação a Objetos tem, como principal característica, a forma natural de tratar a realidade, pois considera que o mundo real é formado por objetos. A proposta da Orientação a Objetos é deslocar o esforço de desenvolvimento para a fase de análise, dando ênfase às estruturas de dados antes das funções e, assim, os benefícios são: a reutilização do código (componentes), a confiabilidade (objetos encapsulados) e o aumento de produtividade (SOMMERVILE, 2011). Com planejamento adequado, desenvolvedores capacitados e adoção de uma metodologia, o sucesso é garantido. A análise OO apresenta um conjunto de regras e modelos que auxiliam o analista a levantar e a modelar os requisitos dos usuários que o sistema deve atender. Um sistema orientado a objetos é composto de objetos interativos que mantêm seu pró- prio estado local e oferecem operações nesse estado. A representação do estado é privada e não pode ser acessada diretamente, de fora do objeto. Processos de projeto orientado a objetos envolvem projetar as classes de objetos e os relacionamentos entre essas classes. Essas classes definem os objetos no sistema e suas interações. Quando o projeto é con- cebido como um programa em execução, os objetos são criados dinamicamente a partir dessas definições de classe. Sistemas orientados a objetos são mais fáceis de mudar do que os sistemas desenvolvidos com abordagens funcionais. Os objetos incluem os dados e as operações para manipulá-los. Portanto, eles podem ser entendidos e modificados como entidades autônomas. Como os objetos são associados com coisas, muitas vezes, existe um mapeamento claro entre entidades do mundo real e seus objetos de controle no sistema, o que melhora a inteligibilidade e, portanto, a manuteniblidade do projeto. Fonte: Sommerville (2011, p.125). explorando Ideias U N IC ES U M A R 15 2 EVOLUÇÃO DOS MÉTODOS OO Os métodos de análise e projeto orientado a objetos surgiram assim que as lingua- gens de programação OO começaram a estabilizar, sendo que um dos primeiros métodos foi o modelo OOSA, proposto por Shlaer e Mellor, em 1988, e o Wirfs- -Brock, lançado em 1989, pelo grupo de pesquisa da Smalltalk (MEDEIROS, 2004). A maior parte dos métodos OO, porém, passou a se tornar estável na década de 90, com a fusão das metodologias de Grady Boock, James Rumbaugh e Ivar Jacobson e a criação da UML, que teve como base outras metodologias, como a de Shlaer-Mellor. Buscava-se, com a criação da UML, uma padronização das metodologias OO. Ivar Jacobson (1995) Apresenta uma abordagem mais conceitual do que de detalhes, composta por cinco fases: levantamento de requerimentos, análise de robustez, projeto, implementação e teste. Ele segue a estratégia de métodos não lineares e em espiral com refinamentos sucessivos. Coad e Yourdon (1992) Abrangem as fases de análise, projeto e implementação; propõem uma meto- dologia simples para iniciantes. As críticas mais fluentes destacam a ausência de modelagem para abranger todo o contexto necessário na fase de análise. U N ID A D E 1 16 Shlaer e Mellor (1990) Abrangem as fases de análise, projeto e implementação. Propõem mecanis- mos para facilitar a representação de modelos dinâmicos dos objetos, dando ênfase à modelagem da informação, por meio dos modelos de objetos, de estados, de diagramas de fluxo de dados e de ações. Grady Booch (1997) Abrange as fases de análise, projeto e implementação. Apresenta uma poderosa notação utilizada para expressar as relações entre as classes, destacando-se, principalmente, na fase de projeto. É considerado um dos mais autênticos e tradicionais métodos de desenvolvimento de sistemas orientados a objetos. James Rumbaugh (1991) Abrange as fases de levantamento de dados com a descrição do domínio e do enunciado do problema, dividindo a fase de análise em modelagem de obje- tos, modelagem dinâmica e modelagem funcional, destacando o tratamento de processos e dividindo a fase de projeto em projeto de objetos e de sistema. Martin e Odell (1995) Abrangem as fases de análise e projeto. Propõem o uso da Engenharia da Informação baseada em objetos por meio de um repositório de objetos, para a obtenção, em alto nível, de reaproveitamento dos sistemas. Fusion (1996) Abrange as fases de análise, projeto e implementação. Sintetiza os aspec- tos mais positivos dos métodos de James Rumbaugh/OMT, Grady Booch, Wirfs-Brock/CRC e Ivar Jacobson/Objectory. O autor enfoca os modelos de objetos e processos do método OMT, a interação de objetos da CRC, a visibilidade do método de Booch e complementa com pré e pós-condições de métodos formais (COLEMAN, 1996). U N IC ES U M A R 17 UML – Unified Modeling Language (2000) Abrange as fases de levantamento de requisitos, análise, projeto e implemen- tação. Fusão dos métodos de James Rumbaugh/OMT, Grady Boock e Ivar Jacobson. A fusão inicia com o trabalho de Rumbaugh e Booch, os dois me- todistas que ganharam mais popularização, os quais se juntaram para criar para o público um método comum por meio de pontos fortes em 1995. Em seguida, em meados de 1996, Jacobson integrou-se ao grupo, e lançaram a UML versão 0.9. A partir daí, criaram forças com cooperação da OMG (Object Management Group), em julho de 1997, considerado um padrão mundial. A UML sugere, fortemente, a adoção de casos de uso (use cases) como dire- cionadores de projetos de software, a utilização de diagramas de interação para identificação de objetos e uma série de outros conceitos. O projeto de software começa quando a primeira iteração da engenharia de requisitos chega a uma conclusão. O intuito do projeto de software é aplicar um conjunto de prin- cípios, conceitos e práticas que levam ao desenvolvimento de um sistema ou produto de alta qualidade. O objetivo do projeto é criar um modelo de software que irá implementar corretamente todos os requisitos do cliente e trazer satisfação àqueles que o usarem. Os projetistas de software devem examinar completamente muitas alternativas de projeto e convergir para uma solução que melhor atenda às necessidades dos interessados no pro- jeto. O processo de projeto passa de uma visão macro do software para uma visão mais estreita que define os detalhes necessários para implementar um sistema. O processo começa concentrando-se na arquitetura. São definidos subsistemas; são estabelecidos mecanismos de comunicação entre os subsistemas; são identificados componentes; e é desenvolvida uma descrição detalhada de cada componente. Além disso, são projetadas interfaces externas, internas e para o usuário. Fonte: Pressman (2011, p. 226). explorando Ideias O modelo de projeto engloba quatro elementos distintos; à medida que cada um é desen- volvido, evolui uma visão mais completa do projeto. (Roger Pressman) pensando juntos U N ID A D E 1 18 3 CONCEITOS BÁSICOS DE OO Conheceremos, a seguir, os principais termos e conceitos utilizados em análise e projeto OO. Vamos lá! ■ Objeto: qualquer elemento concreto ou abstrato que existe no mundo real, que se pode individualizar por possuir comportamentos e caracte- rísticas próprios. Figura 1 - Objetos concretos Figura 2 - Objetos abstratos U N IC ES U M A R 19 ■ Abstração: abstraímos quando definimos um objeto conceitual partindo de objetos do mundo real com os mesmoscomportamentos e caracterís- ticas, os quais são classificados como de um mesmo tipo. Figura 3 - Abstração de bolsa Figura 4 - Abstração de avião Figura 5 - Abstração de esporte ■ Classe: representa a abstração de um conjunto de objetos do mundo real que possui comportamentos e características comuns. Figura 6 - Classe funcionário U N ID A D E 1 20 ■ Instância: é cada umas das ocorrências de um objeto formado a partir da sua classe. Figura 7 - Classe e objetos / Fonte: os autores. ■ Atributo: é uma característica particular que os objetos de uma classe possuem, assumindo valores diferentes para cada objeto. Figura 8 - Classe, objeto e valor / Fonte: os autores. ■ Operação: é uma ordem que faz um objeto executar uma ação. As ope- rações são tudo o que os objetos de uma classe fazem e nada além do que esses objetos podem fazer. Figura 9 - Operação / Fonte: os autores. U N IC ES U M A R 21 ■ Mensagem: representa o mecanismo de chamada de uma operação. É utilizada na solicitação de execução de uma operação. É a maneira como conseguimos que um método seja executado. Figura 10 - Mensagem / Fonte: os autores. ■ Evento: é um tipo especial de operação que faz com que os objetos mu- dem de estado. Figura 11 - Evento / Fonte: os autores. ■ Parâmetro: é um ou mais atributos que são carregados para dentro de uma mensagem. Figura 12 - Parâmetro - Avião, partida (linha aérea, número do voo, cidade) / Fonte: os autores. U N ID A D E 1 22 ■ Estado: é a forma de apresentação dos objetos de uma classe em deter- minado instante. Figura 13 - Estado / Fonte: os autores. ■ Transição de estado: é quando ocorre a mudança de estado de um ob- jeto de uma classe como resposta à chegada de um evento. Estado Criado Estado Eliminado Estado Parado Estado Decolando Figura 14 - Transição de estado / Fonte: os autores. ■ Associação: é a forma como os objetos de uma mesma classe ou de classes diferentes se conectam. Figura 15 - Associação de classes / Fonte: os autores. ■ Encapsulamento: é a reunião de características e comportamentos de objetos em uma classe. Figura 16 - Encapsulamento / Fonte: os autores. U N IC ES U M A R 23 ■ Polimorfismo: é a capacidade que objetos de classes diferentes possuem de se comportarem de forma diferente em uma mesma operação. A es- trutura (atributos) de cada classe é diferente. Figura 17 - Polimorfismo / Fonte: os autores. ■ Método: é o algoritmo (conjunto de passos) que um objeto executa quan- do reage a uma operação. O método é a lógica interna de uma operação. public int somar( int num1, int num2 ) { return num1 + num2; } Quadro 1 - Declaração de um método / Fonte: os autores. ■ Colaboração: é a troca de mensagens que acontece entre objetos e atores ■ Figura 18 - Troca de mensagens entre os objetos / Fonte: os autores. ■ Herança: é a propriedade que possibilita que a classe herde característi- cas e comportamento de outra classe. Figura 19 - Herança / Fonte: os autores. U N ID A D E 1 24 4 PRINCIPAIS DIAGRAMAS DA UML Agora que já conhecemos os principais termos utilizados na análise e no projeto OO, conheceremos os diagramas utilizados para documentação de software. A UML 2.5 apresenta vários diagramas, classificados em estruturais e de compor- tamento. A Figura 20 mostra esta organização em um diagrama de classes. Figura 20 - Organização do diagrama UML / Fonte: os autores. U N IC ES U M A R 25 É comum verificarmos que a documentação do software, na maioria das vezes, não tem a devida atenção da equipe de desenvolvimento, por preguiça, ou por falta de tempo, ou mesmo por pensar que é perda de tempo elaborar inúmeros diagramas. Porém, bons softwares têm documentação que nos permite contar e entender a sua história. A seguir, conheceremos alguns dos diagramas mais utilizados na UML. Diagramas de comportamento Os diagramas de comportamento são utilizados para descrever o sistema mo- delado em execução. São utilizados para especificar, visualizar, documentar e construir os aspectos dinâmicos de um sistema, ou seja, é a representação das partes que sofrem alterações. Diagrama de casos de uso O diagrama de casos de uso (comportamento) é utilizado na análise de requisitos. Este diagrama acompanha o software desde o seu início até a conclusão. Para conhecermos o conceito de caso de uso, temos que conhecer, primeira- mente, o ator. Este pode ser uma pessoa (usuário), um sistema ou uma máquina. O ator é quem realiza as atividades e sempre atua sobre um caso de uso. O diagrama de caso de uso da Figura 21 modela o comportamento dos atores no sistema de uma biblioteca. No exemplo, o diagrama mostra os atores aluno e bibliotecária, representados pelo stickman (“homem palito”) e suas respectivas ações descritas nas elipses. Figura 21 - Diagrama de caso de uso / Fonte: os autores. Cria livro Cria aluno Efetua empréstimo Bibliotecária Realiza empréstimo Realiza consulta Realiza devolução Aluno U N ID A D E 1 26 Diagrama de sequência Com o objetivo de refinar o diagrama de classes, o diagrama de sequência (com- portamento) é um dos vários tipos de diagrama de interação disponibilizados pela UML, sua utilidade é estudar as interações entre os objetos, possibilitando a identificação de relação entre as classes. O cenário representado na Figura 22 mostra a solicitação de um empréstimo pelo aluno. A partir desta ação, é desencadeado um conjunto de mensagens entre os objetos, que, por sua vez, permite a verificação da existência da pessoa aluno, e, em seguida, é criado o item de empréstimo, que verifica a existência do exemplar solicitado, realizando o empréstimo. Como é possível observar, a partir das informações fornecidas pelo diagra- ma de sequência, pode-se identificar os métodos associados às classes, além da identificação das relações entre elas. s Figura 22 - Diagrama de sequência / Fonte: os autores. U N IC ES U M A R 27 Outra forma de representar esse cenário é pelo diagrama de comunicação (com- portamento). Ele contém as mesmas informações que o diagrama de sequência, porém não considera a dimensão temporal. Diagrama de estados Agora, veremos o diagrama de estados (comportamento), que tem como obje- tivo especificar o comportamento das classes mais complexas, utilizando uma máquina de estados. Autômato finito ou máquina de estados finitos representa a modelagem de comporta- mentos considerando o seu estado. O estado guarda informações sobre o passado do objeto, a transição indica que o objeto está mudando de estado, e uma ação é o detalha- mento de uma atividade que deve ser executada em determinado momento. Fonte: adaptado de Sommervile (2011). explorando Ideias Não são todas as classes do sistema que apresentam mais de um estado. O diagrama de estado a seguir mostra todos os estados do exemplar no momento empréstimo. O início do estado é marcado pelo círculo, e o fim é marcado pelo duplo círculo. Figura 23 - Diagrama de estado / Fonte: os autores. U N ID A D E 1 28 Diagrama de comunicação O diagrama de comunicação permite a identificação das classes mais próximas, e a ordem de envio de mensagens é identificada por números sequenciais. A seguir, é apresentado o diagrama de comunicação equivalente ao diagrama de sequência mostrado anteriormente. Figura 24 - Diagrama de comunicação (comportamento) / Fonte: os autores. Diagrama de atividades O diagrama de atividade é, em sua essência, um gráfico de fluxo demonstran- do como ocorre o fluxo de controle entre as atividades. Este diagrama é um dos mais detalhistas, dando mais ênfase ao nível de algoritmo. Os diagramas de atividades podem ser utilizados com vários propósitos. Den- tre eles, podemos citar a captura do funcionamento interno do objeto, mostrar como pode ser executado um conjunto de ações relacionadas e como elas podem afetar os objetos ao seu redor. U N IC ES U M A R 29 Figura 25 - Diagrama de atividades / Fonte: os autores.Diagramas de estrutura Os diagramas estruturais são utilizados para especificar, visualizar, documentar e construir os aspectos estáticos de um sistema, ou seja, diagramas estruturais repre- sentam a estrutura estável. A estrutura estática de um sistema envolve a existência e a colocação de itens como classes, pacotes, objetos, componentes e utilização. Diagrama de classes Após a elaboração do diagrama de caso de uso, podemos modelar a primeira ver- são do diagrama de classes, pois este mostra a estrutura estática do sistema. Uma classe é uma estrutura que modela um conjunto de objetos cujas características são similares. A classe, por meio dos métodos, modela o comportamento de seus objetos, e os possíveis estados do objeto são modelados por meio de atributos. U N ID A D E 1 30 Para entendermos melhor, faremos a analogia com a construção de um veícu- lo. Todos os veículos serão rigorosamente iguais, pois estarão baseados em uma planta (projeto) que esclarece o número de portas, a potência do motor, o número de marchas do câmbio, entre outros atributos. Portanto, o projeto do veículo é a classe, e os veículos são os objetos que foram baseados na classe. O diagrama de classes a seguir modela a estrutura estática do sistema de bi- blioteca, apresentado em análise inicial. Por meio do diagrama de caso de uso, a classe possibilita a abstração dos objetos mediante os atributos (data: date; nome: string...) e métodos (Cria(); Recupera()...). Toda notação do diagrama será inteiramente desmistificada na Unidade 3, mas, para adiantar, é possível observar, neste diagrama, além das classes, que contêm atributos e métodos, as conexões entre as classes, que podem ser uma agregação, representada pelo losango, ou uma especialização, representada pelo triângulo. Figura 26 - Diagrama de classes / Fonte: os autores. Diagrama de objetos Os diagramas de objetos correspondem a um segundo nível de abstração do diagrama de classes. Não têm a mesma importância que ele, porém podem ser uma ótima opção para exemplificar os diagramas de classes mais complexos. O diagrama de objetos é o diagrama de classes instanciado. Utiliza a mesma notação deste para mostrar as instâncias da classe. U N IC ES U M A R 31 PESSOA • Nome: “João da Silva” • Fone: “(43) 3948-4039 ALUNO • Curso: “Programação Java” PROFESSOR • Disciplina: “Java” Figura 27 - Diagrama de objetos / Fonte: os autores. Diagrama de componentes Um diagrama de componente mostra a organização e dependência entre todos os componentes. Seu objetivo é modelar a visão de implementação dos módulos executáveis do software. Apesar de ser um diagrama de alto nível, a organização do sistema é depen- dente da linguagem de programação utilizada, portanto a solução de desenvol- vimento adotada refletirá, diretamente, neste diagrama. Um componente corresponde a uma parte do código distribuível, a qual pode ser substituída por outro componente e que contém elementos que mostram um conjunto de interfaces fornecidas e requeridas. Podemos apresentar como exemplos de componentes: os executáveis, as tabelas, as bibliotecas, o documento e o arquivo. Figura 28 - Diagrama de componente / Fonte: os autores. U N ID A D E 1 32 Diagrama de implantação Diagramas de implantação são utilizados para modelar a arquitetura física de distribuição em que o software será executado. Esse diagrama mostra os nós e os relacionamentos de comunicação. O diagrama de implantação mapeia a arquitetura lógica de classe no nó de processamento e suas dependências. Um nó representa um recurso computa- cional com memória e processamento, ou seja, um disco rígido, um computa- dor, uma impressora etc. É uma ferramenta importante quando queremos saber quais computadores e outros hardwares estão conectados, bem como saber de que modo estão distribuídas as classes e quando a atualização de determinado arquivo resulta na recompilação de outros. Figura 29 - Diagrama de implantação / Fonte: os autores. U N IC ES U M A R 33 Diagrama de pacotes O pacote representa um agrupamento de classes, formando uma unidade. Nor- malmente, os pacotes apresentam relações em que um depende de outro para o funcionamento. Como a estrutura de uma aplicação é dada pelas classes e associa- ções, podemos agrupar as classes em pacotes de análise, o que facilita o manuseio do modelo de análise. Podemos utilizar o diagrama de pacotes para representar um conjunto de sub- sistemas, e, neste caso, cada subsistema é representado por um pacote. Dessa forma, um pacote pode representar uma biblioteca, um subsistema, um sistema, entre outros, e, também, um pacote pode conter outros. Os pacotes, invariavelmente, apresentam dependência entre si, o relacionamento de dependência indica que o pacote dependente precisa, de alguma forma, daquele outro do qual depende. Figura 30 - Diagrama de pacotes / Fonte: os autores. U N ID A D E 1 34 CONSIDERAÇÕES FINAIS Nesta unidade, aprendemos que a análise é a solução conceitual dada ao proble- ma. Ela marca o início da definição informática, preocupa-se, principalmente, com as classes do domínio do problema e suas relações e, também, com os casos de uso. Já o projeto é o resultado do refinamento da análise e considera os detalhes da implementação, tais como a linguagem a ser utilizada e o sistema gerenciador de banco de dados. Você se familiarizou com o conceito de Orientação a Objetos, ou, simples- mente, OO, que é um novo paradigma para o desenvolvimento de aplicações, ou seja, é uma estratégia de desenvolvimento de software que organiza este como uma coleção de objetos, que contém tanto a estrutura dos dados quanto o com- portamento deles. Verificamos que os métodos de análise e projeto orientado a objetos surgiram assim que as linguagens de programação OO começaram a se estabilizar, sendo que um dos primeiros métodos foi o modelo OOSA, proposto por Shlaer e Mellor, em 1988, e o Wirfs-Brock, lançado em 1989, pelo grupo de pesquisa da Smalltalk. Por meio do estudo da evolução dos métodos, podemos perceber que a UML – Unified Modeling Language é a fusão dos métodos de James Rumbaugh/OMT, Grady Boock e Ivar Jacobson. A fusão inicia com o trabalho de Rumbaugh e Boo- ch; em seguida, em meados de 1996, Jacobson integrou-se ao grupo, e lançaram a UML versão 0.9. A partir daí, criaram forças com a cooperação da OMG (Object Management Group) em julho de 1997, considerado um padrão mundial. Estudamos as características dos principais métodos OO, e foi possível verificar que a maioria das propostas abrangem as fases de análise, projeto, implementação e testes. Após conhecermos os principais métodos e estudarmos as suas caracte- rísticas, entramos em contato com os conceitos de OO, em que aprendemos sobre objetos, abstração, classes, operações, atributos, instância, mensagem, entre outros. Por fim, conhecemos os diagramas utilizados para documentação de software. Os diagramas de caso de uso, classes, estado, sequência e colaboração foram apre- sentados de forma sucinta, já que os veremos com detalhes nas unidades seguintes. A partir dos conceitos que foram abordados nesta unidade, conseguimos ter uma visão geral sobre a Orientação a Objetos. Agora, você conhecerá as etapas da análise e notação para o diagrama de caso de uso. 35 na prática 1. Na análise e no projeto estruturados, o processo a ser informatizado é visto como um conjunto de funções com dados de entrada, processamento e dados de saída, ou seja, a ênfase está em funções que agem sobre dados. Diferentemente da análise e do projeto estruturados, na Orientação a Objetos, o processo a ser informatizado é visto como um conjunto de objetos que interagem para realizar as funções. Sabendo disso, quais as vantagens do modelo OO? 2. A maior parte dos métodos OO passaram a se tornar estáveis na década de 90, com a fusão das metodologias de Grady Boock, James Rumbaugh e Ivar Jacobson e a criação da UML, que se baseou, também, em outras metodologias,como a de Shlaer-Mellor. Diante do exposto, quais as fases comuns aos métodos propostos pelos autores citados? 3. A UML – Unified Modeling Language abrange as fases de levantamento de requisi- tos, análise, projeto e implementação. É dada como a fusão dos métodos de James Rumbaugh/OMT, Grady Boock e Ivar Jacobson. Quais dos conceitos elencados nas assertivas são próprios da orientação a objetos? I - Objetos: qualquer elemento concreto ou abstrato com existência perceptível no mundo real. II - Classes: abstração de um conjunto de objetos. III - Atributo: característica particular possuída por todos os objetos de uma classe. IV - Chave primária: identifica, unicamente, um objeto. É correto o que se afirma em: a) I, apenas. b) I e II, apenas. c) I, II e III, apenas. d) III e IV, apenas. e) I, II, III e IV. 36 na prática 4. É comum verificarmos que a documentação do software, na maioria das vezes, não tem a devida atenção da equipe de desenvolvimento, por preguiça, ou por falta de tempo, ou mesmo por pensar que é uma perda de tempo elaborar inúmeros diagramas. Bons softwares, porém, têm documentação que nos permite contar e entender a sua história, e contamos esta por meio de diagramas. Sabendo disso, quais diagramas são utilizados na UML e como estão organizados? 5. Leia o excerto a seguir e veja quais das alternativas preenche, corretamente, a lacuna: O diagrama __________ contém as mesmas informações que o diagrama de sequência, porém não considera a dimensão temporal. Assinale a alternativa correta: a) De comunicação. b) De caso de uso. c) De classes. d) De estado. e) De pacotes. 37 aprimore-se QUALIFICAÇÃO DE SOFTWARES Como um software pode ser qualificado? É muito simplório definir isto pelo tempo de desenvolvimento ou pela excelência na programação. Existem casos de desen- volvimento de softwares em que o programador ouve todas as informações e apre- senta uma solução instantânea, quase que “mágica”, algo que resolve perfeitamente o que foi apresentado. Vendo desta forma, a sensação é que o atendimento foi excepcional, contudo, na maioria dos casos, programas feitos neste formato não suprem a real necessidade do cliente. Não podemos julgar o cliente por não saber apresentar, de forma assertiva, as suas necessidades, pois o conhecimento da construção técnica é inexistente ou su- perficial, não acompanha as tendências do mercado, entre outras hipóteses. E a consequência disso tudo é a perda de investimento financeiro e de tempo em um projeto que não suprirá a necessidade geral e uma programação desgastante, tanto para o programador quanto para o cliente. Casos assim não são exceções, é muito provável que você já os tenha vivenciado. Este problema, porém, não é exclusivo do desenvolvimento de softwares, é cor- riqueiro no mercado. Para provar isto, basta necessitarmos de um serviço que não temos nenhum conhecimento do processo, como consertar um carro. A solução só vem quando um profissional qualificado está mais preocupado em satisfazer o cliente do que resolver, exclusivamente, o seu problema apresentado. Os profissio- nais que mantêm este método de atendimento são substituídos aos poucos. Na rotina diária de programação, normalmente, o início do projeto vem de uma conversa informal, e, só na primeira apresentação, depois de um bom tempo de de- dicação, é que o cliente consegue esclarecer o que deseja, ainda de forma abstrata, por meio de frases como “não é bem isso que eu esperava”. Outro caso comum que acontece pela falta de alinhamento é o seguinte: as solicitações do cliente aumen- tam durante o processo todo, e, como nada é estabelecido de forma clara no início do trabalho, você pode até prolongar o projeto, mas, possivelmente, não atenderá a todas as necessidades do seu cliente. 38 aprimore-se Finalizo lembrando que o cliente não tem obrigação de entender como funciona toda a programação e que a preocupação em o atender deve ser do programador, não o contrário. Um bom profissional precisa “interpretar” a necessidade de um clien- te e oferecer não o que ele está pedindo, mas, sim, o que suprirá a necessidade dele. Fonte: o autor. 39 eu recomendo! Desenvolvendo Software com UML 2.0: definitivo Autor: Ernani Medeiros Editora: Makron Books Sinopse: este livro apresenta, de maneira prática e testada, o que é, para que serve e como usar os diagramas da UML 2.0. Além de sugerir o melhor momento para pensar em modelagem de banco de dados e propor passos dentro do processo de construção de software, também aborda parte técnica, notação, semântica, finalidade do con- ceito e como usá-lo. livro Para aprofundar os conhecimentos sobre OO, leia o artigo intitulado “A história de UML e seus diagramas”. Ele descreve a história da UML desde a década de 90 até o momento atual. É apresentada a organização dos 13 diagramas de UML, classi- ficando-os em diagramas estruturais e comportamentais. Os quatro documentos pertencentes à especificação também são mencionados e explicados. https://fdocumentos.tips/document/a-historia-de-uml-e-seus-diagramas.html conecte-se 2 CASOS DE USO PROFESSORES Me. Déverson Rogério Rando Esp. Janaína Aparecida de Freitas PLANO DE ESTUDO A seguir, apresentam-se as aulas que você estudará nesta unidade: • Fases da Análise e do Projeto • Modelos de Processo • Requisitos de Software • Diagrama de Casos de Uso. OBJETIVOS DE APRENDIZAGEM Conhecer as fases de análise e projeto • Entender os modelos de processo • Compreender como ocorre o levantamento de requisitos • Diferenciar requisitos funcionais de não funcionais • Conhecer o diagra- ma de caso de uso. INTRODUÇÃO Caro(a) aluno(a), iniciamos a segunda unidade do livro Análise e Projeto Orientado a Objetos falando sobre as fases da análise e do projeto de software. Conheceremos cada uma das etapas da análise, que acreditamos ser a fase mais difícil e crítica da produção de um software. Difícil porque é o momento em que ocorrem as tentativas de delimitar o domínio do proble- ma e entendê-lo; crítica porque uma análise malfeita comprometerá todas as outras fases de produção do software, além do fato de que o produto a ser entregue não será aquele que o cliente, inicialmente, requeria. Entenderemos e conheceremos dois modelos de processos de software, dentre os diversos processos existentes. Citaremos, aqui, o modelo em cas- cata e o evolucionário; em cascata, por ser o primeiro modelo de processo a ser utilizado; e evolucionário, por ser um dos modelos mais utilizados, principalmente, na fase de aprendizagem do problema. Veremos que os requisitos de software são objetivos ou restrições esta- belecidos por clientes e usuários do sistema, que definem as diversas pro- priedades dele. Aprenderemos como identificar os “requisitos funcionais”, que definem as funções do sistema, e os “requisitos não funcionais”, que definem outros tipos de características, os quais o sistema deverá possuir. Ainda, veremos a importância do levantamento de requisitos para o desenvolvimento de software. Aprenderemos que a definição de requisitos pode utilizar uma narrativa ou representações gráficas. Por meio dessas definições, pode ser elaborado o documento preliminar de requisitos. E, finalmente, conheceremos o diagrama de caso de uso, em que enten- deremos a notação e o objetivo do caso de uso na fase de análise do softwa- re. Esses diagramas são utilizados para representar, de forma panorâmica, os requisitos funcionais de um sistema do ponto de vista do usuário. Então, o que estamos esperando? Vamos ao trabalho! Boa leitura a todos. U N ID A D E 2 42 1 FASES DA ANÁLISE e do projeto Como vimos na primeira unidade, a análise de sistemas é a atividade inicial do processo de desenvolvimento de software em que se determina e especifica o que um sistema deve fazer, assim como as circunstâncias sob as quais ele deve operar, envolvendo, geralmente, esforço colaborativo entre analistas de sistemas e usuá- rios.De acordo com Sommervile (2011), a análise é realizada com os seguintes objetivos em mente: ■ Identificar a necessidade do usuário. ■ Executar análise econômica e técnica. ■ Atribuir funções a hardware, software, pessoas, banco de dados e demais elementos do sistema. ■ Estabelecer as restrições de prazo e de custo. ■ Criar uma definição de sistema que constitua a base para todo o trabalho subsequente. Independentemente do método ou processo utilizado para a análise, o projeto e a implementação, algumas etapas são comuns, são elas (SOMMERVILE, 2011): ■ Identificação da necessidade. ■ Estudo de viabilidade. ■ Análise. ■ Projeto (ferramentas). U N IC ES U M A R 43 ■ Implementação (codificação). ■ Implantação. ■ Manutenção (adaptativa, corretiva e evolutiva). A seguir, conheceremos cada uma dessas etapas de suma importância para a produção de um software de qualidade. Identificação da necessidade Comentaremos cada uma dessas etapas começando pela identificação da ne- cessidade, que é o ponto de partida na evolução de um sistema. Nesta etapa, são definidas as metas globais do sistema, respondendo a algumas perguntas-chave: ■ Quais informações serão produzidas? ■ Quais informações devem ser fornecidas? ■ Que funções e desempenho são exigidos? Ainda nesta etapa, após a definição das metas, o analista deve avaliar: ■ Existe tecnologia para construir o sistema? ■ Qual é o custo de produção e o tempo necessário para conclusão? Caso o novo sistema seja um produto a ser desenvolvido para a venda direcio- nada a muitos clientes, o analista, ainda, deve avaliar o seguinte: ■ Qual é o mercado em potencial para o produto? ■ Como este produto se compara com os produtos dos concorrentes? Estudo de viabilidade Na etapa seguinte, temos a análise de viabilidade, em que o analista deve determi- nar, rapidamente, se o problema pode ser resolvido considerando cinco aspectos de viabilidade: técnico, legal, operacional, temporal e econômico. No aspecto da viabilidade técnica, o analista deve determinar se o projeto pode ser desenvolvido e implementado usando os recursos existentes: computa- dores, periféricos e sistema operacional. E, também, se existe pessoal competente à disposição para desenvolver o sistema em questão (SOMMERVILE, 2011). U N ID A D E 2 44 No aspecto da viabilidade legal, o analista verifica se não existem conflitos entre o sistema em consideração e os compromissos legais que a empresa tem. O analista deve considerar as implicações legais que aparecem nos estatutos es- taduais/federais e nas cláusulas contratuais. No aspecto operacional, o analista faz a verificação de que o sistema será capaz de executar as funções projetadas no ambiente organizacional existente, com o pessoal atual. No aspecto de tempo, o analista deve determinar o cronograma para desen- volvimento e verificar se o sistema será factível no tempo determinado. O último aspecto é o da viabilidade econômica, em que o analista deve de- terminar se os benefícios sobrepõem os custos; se a despesa estimada ultrapassar a expectativa da administração ou se os benefícios não justificarem os custos, o projeto, provavelmente, será abandonado. Análise A coleção exata dos dados é essencial para a análise completa de um sistema, por- tanto o analista deve considerar os seguintes objetivos (SOMMERVILE, 2011): ■ Entender os objetivos do sistema (o que o administrador/usuário espera dele). ■ Entender as exigências do sistema (o que processar e que saídas produzir). ■ Entender que os objetivos e as exigências são satisfeitos por meio de cui- dadosa análise. ■ Entender as áreas-problema do sistema. Para tanto, são utilizadas técnicas para o levantamento de dados, tais como: ■ Estudo dos manuais de procedimentos. ■ Análise de formulários. ■ Entrevista. ■ Questionário. ■ Observação. U N IC ES U M A R 45 Projeto Após a análise, ou levantamento de requisitos, ou, ainda, engenharia de requisitos (como quiser chamar), vem o projeto, que é a solução informática dada ao problema. De acordo com Sommerville (2011), o projeto de software descreve a es- trutura do software que será implementado. Nele, estão contidos os dados e a interface entre os componentes do sistema. Na primeira versão do projeto, ainda não é possível detalhar completamente o sistema, pois, ao elaborar modelos com diferentes níveis de abstração, é possível detectar problemas nos níveis anteriores. A cada nível seguinte, são criados modelos mais detalhados, diminuindo, cada vez mais, a abstração. O projeto de software é importante para formalizar as regras de negócio do sistema, melhorando a comunicação entre o cliente e o programador. Implementação É neste estágio de desenvolvimento de software em que se cria uma versão exe- cutável ele, utilizando as ferramentas para desenvolvimento definidas no projeto. A implementação pode iniciar após o término do projeto ou pode acontecer de forma paralela a ele, tudo depende do modelo de processo escolhido. Implantação A implantação corresponde à fase na qual o software será entregue ao cliente. Na fase do estudo da viabilidade, foi levantada, pelo analista, a viabilidade técnica, em que se buscou verificar se o projeto pode ser desenvolvido e implementado usando os recursos existentes: computadores, periféricos, sistema operacional, entre outros, e, também, se existe pessoal competente à disposição para desen- volver o sistema em questão. Todo o projeto é construído com base no estudo de viabilidade técnica, utili- zando ferramentas suportadas pelo hardware e entendida pelos usuários, portan- to os riscos da implantação não funcionar são minimizados no projeto. O fator U N ID A D E 2 46 mais preocupante, nesta fase, é, justamente, o período que será necessário para a adaptação do usuário com o novo sistema, pois toda mudança gera transtornos, na maioria das vezes, o usuário está acostumado a executar suas tarefas de de- terminada forma, e a mudança é vista com restrição. Manutenção A manutenção é o processo de modificar o sistema desenvolvido depois que ele é colocado em operação, é a fase do ciclo de vida do software que dura mais tempo, até que o sistema deixe de ser utilizado. O software é continuamente modificado ao longo de seu tempo de duração, em resposta a requisitos em constante modificação e às necessidades do cliente. As manutenções não dizem respeito somente à correção do software, mas tam- bém a motivos que não foram possíveis de observar no momento da análise, do projeto ou, mesmo, da implementação. As manutenções podem ser adaptativas, cujo objetivo, como o próprio nome diz, é adaptar algumas tarefas ou funções para o ambiente de implantação. As manutenções também podem ser evolutivas, cujo objetivo é a inserção de novos módulos no sistema. Projeto é o que quase todo engenheiro quer fazer. É o lugar onde a criatividade impera — onde os requisitos dos interessados, as necessidades da aplicação e considerações técnicas se juntam na formulação de um produto ou sistema. O projeto cria uma repre- sentação ou modelo do software, mas diferentemente do modelo de requisitos (que se concentra na descrição do “O que” é para ser feito: dos dados, função e comportamento necessários), o modelo de projeto indica “O Como” fazer, fornecendo detalhes sobre a ar- quitetura de software, estruturas de dados, interfaces e componentes fundamentais para implementar o sistema. Os engenheiros de software conduzem cada uma das tarefas de projeto. Por que é importante? O projeto permite que se modele o sistema ou produto a ser construído. O modelo pode ser avaliado em termos de qualidade e aperfeiçoado ANTES de o código ser gerado, ou de os testes serem realizados, ou de os usuários finais se envolverem com grandes números. Fonte: Pressman (2011, p. 206, grifo do autor). explorando Ideias U N IC ES U M A R 47 2 MODELOS DE PROCESSO A análise e o projeto de sistemas de software devem fornecer para os stakeholders,a equipe envolvida, composta pelo cliente, analista, programador, entre outros, uma única compreensão do projeto. De acordo com Medeiros (2004), a UML não é um método, mas, sim, uma linguagem. Um método é composto por processos e um modelo de linguagem. Os processos são os passos que devem ser seguidos para construir o projeto. O modelo de linguagem é a notação que o método usa para descrever o projeto, enquanto um modelo de processo de software define a sequência em que as atividades do processo serão realizadas. Modelo cascata Tomaremos como exemplo o mode- lo de processo em cascata, ou queda d’água, como colocado por alguns autores. Figura 1 - Modelo cascata / Fonte: adaptada de Sommerville (2011). U N ID A D E 2 48 Conhecido como ciclo de vida clássico, o modelo em cascata é o primeiro a ser publicado do processo de desenvolvimento de software. O modelo considera as atividades de especificação, desenvolvimento, validação e evolução como fases separadas do processo. A primeira fase é a análise e definição de requisitos (especificação de requi- sitos). As funções, as restrições e os objetivos do sistema são estabelecidos por meio da consulta aos usuários. A segunda fase é o projeto de sistemas e de software, em que os requisitos em sistemas de hardware ou de software são agrupados, estabelecendo uma arqui- tetura do sistema geral. A terceira fase é a implementação e o teste de unidades. Durante este estágio, o projeto de software é compreendido como um conjunto de programas ou de unidades de programa. O teste de unidade envolve verificar que cada unidade atende à sua especificação. A quarta fase é a integração e o teste de sistemas. Neste estágio, as unidades de programa ou programas individuais são integrados e testados como um sistema completo, a fim de garantir que os requisitos de software foram atendidos. A quinta fase é a operação e manutenção. Normalmente, esta é a fase mais longa do ciclo de vida. O sistema é instalado e colocado em operação. A manutenção envolve corrigir erros que não foram descobertos em estágios anteriores do ciclo de vida ou aumentar as funções desse sistema à medida que novos requisitos são descobertos. Neste modelo de processo em cascata, pressupõe-se que o domínio do pro- blema foi inteiramente compreendido, portanto é o modelo indicado quando conhecemos por inteiro a regra de negócio do software. Modelo evolucionário Quando estamos produzindo um software e ainda não conhecemos todo o do- mínio do problema, é recomendável a utilização do modelo de desenvolvimento evolucionário. Este tem, como base, a ideia de desenvolver uma implementação inicial, expor o resultado ao comentário do usuário e fazer seu aprimoramento por meio de muitas versões, até que um sistema adequado seja desenvolvido. Em vez de ter as atividades de especificação, desenvolvimento e validação em separado, todo esse trabalho é realizado concorrentemente, com rápido feedback por meio dessas atividades. A Figura 2 ilustra bem as fases do modelo evolucionário. U N IC ES U M A R 49 Figura 2 - Modelo evolucionário / Fonte: adaptada de Sommerville (2011). Devido à característica de produzir sistemas que atendam às necessidades ime- diatas do usuário, muitas vezes, o modelo evolucionário é mais eficaz do que a abordagem em cascata. A vantagem da abordagem evolucionária está na espe- cificação, que pode ser desenvolvida gradualmente, à medida que os usuários compreendem melhor o problema. Como nem tudo são flores, porém, problemas acontecem nesse modelo; enu- meraremos alguns deles: ■ Como os sistemas são desenvolvidos rapidamente, não é viável produzir documentos que reflitam cada versão do sistema. ■ Os sistemas, frequentemente, são mal estruturados. A mudança constan- te tende a corromper a estrutura do software, incorporar modificações torna-se cada vez mais difícil e oneroso. Utilizando o modelo em cascata, ou o evolucionário ou qualquer outro modelo de desenvolvimento, é possível, nas fases de análise e projeto, optar por uma abordagem de análise e projeto estruturado, dessa forma, construiremos Diagra- mas de Entidade-Relacionamento (DER), Diagrama de Fluxo de Dados (DFD), diagrama de contexto, dicionário de dados etc. Esses modelos fornecem uma compreensão única do projeto. O foco da nossa disciplina, contudo, é a orientação a objetos, portanto, nas fases de análise e projeto, construiremos diagramas de caso de uso, de classes, de estado, de sequência etc. Esses modelos também fornecerão uma compreensão única do projeto. U N ID A D E 2 50 Linguagem de modelagem – UML A linguagem de modelagem é uma parte muito importante do método. Corresponde ao ponto principal da comunicação. Se uma pessoa quer conversar sobre o projeto com outra pessoa, é por meio da linguagem de modelagem que elas se entendem. A UML define uma notação e um meta-modelo. Todos os elementos de repre- sentação gráfica vistos no modelo (retângulo, setas, texto etc.) são a notação, essa é a sintaxe da linguagem de modelagem. A notação do diagrama de classes define a representação de itens e conceitos, tais como: classe, associação e multiplicidade. Visto isto, é possível concluir que, independentemente do modelo de processo de software que você escolheu, é de suma importância que o domínio do problema seja entendido por todos da equipe de desenvolvimento, inclusive o cliente. A figura a seguir ilustra, de forma lúdica, o que ocorre em um projeto de software em que a equipe de desenvolvimento e o cliente não se entendem. U N IC ES U M A R 51 Figura 3 - Charge sobre projeto de software / Fonte: Ampersand (2013, on-line, traduzido pelo autor)1. Pense em quais habilidades o analista deve possuir, uma vez que lida com vários grupos de usuários, além de se preocupar com o desenvolvimento e com todos os componentes do sistema. pensando juntos U N ID A D E 2 52 3 REQUISITOS DE SOFTWARE Agora que já sabemos a importância da análise e do projeto na produção de um software, conheceremos os procedimentos mínimos necessários para a obtenção de um software de qualidade. Para tal, precisamos fazer uma engenharia de requisitos, mas o que é isso? Vamos por partes, então. O termo “engenharia” permite dizer que se utiliza um processo sistemático na definição do software. Nesse contexto, a engenharia de requisitos tem, como objetivo, compreender o sistema, ou seja, preocupa-se com “o que fazer”, e não com o “como fazer”. As principais atividades da engenharia de requisitos são (SOMMERVILE, 2011): ■ Especificar o problema (elicitar). ■ Compreender o problema (analisar). ■ Definir uma proposta (modelo válido). ■ Atualizar requisitos (gerenciar). Na primeira atividade, que é elicitar, devemos obter o máximo de informações para o conhecimento do objeto em questão dentro do domínio do problema. U N IC ES U M A R 53 Domínio O que é domínio? Para entender melhor, imaginaremos que você foi contrata- do(a) para desenvolver um software em determinada Casa de Carnes. Do lado direito da Casa de Carnes, existe uma farmácia, do lado esquerdo, um mercado, atrás, uma lanchonete e, em frente, uma igreja. Neste caso, o domínio do seu problema é a Casa de Carnes, os demais estabelecimentos estão na fronteira do seu problema, portanto não fazem parte dele. Creio que, dessa forma, fica fácil compreender o que é o domínio do problema. É óbvio que determinar o domínio do problema não é uma tarefa trivial, pois você pode ser contratado(a) para desenvolver um software para determinado departamento de uma empresa, dessa forma, determinar esse domínio se torna mais complexo. Sendo assim, os limites do domínio (fronteira) podem ser determinados por meio do estabelecimento dos objetivos pretendidos. Para tanto, não devemos centrar em funcionalidades, mas, sim, em finalidade. Requisitos Os requisitos são os objetivos e as restrições estabelecidas pelo usuário do sis- tema. É o usuário ou o cliente o responsável por descreveras necessidades ou o desejo para o software (SOMMERVILE, 2011). Em um primeiro momento, é interessante definir os requisitos sem se preocupar em detalhá-los, isto permite ter uma visão global do domínio de maneira mais rápida. Para a definição de requisitos, produzimos um documento contendo decla- rações, em linguagem de alto nível, dos requisitos e restrições do sistema. Já na especificação, produzimos um documento estruturado contendo requisitos e restrições descritos detalhadamente. Vamos aos exemplos. U N ID A D E 2 54 Definições de requisitos: 1. O software deve proporcionar um meio para representar e acessar arquivos exter- nos criados por outros aplicativos. Especificação de requisitos: 1.1. O usuário deverá ser provido de recursos que permitam definir os tipos de arqui- vos externos que serão acessados. 1.2. Para cada tipo de arquivo externo, deve ser associado o aplicativo que o gerou. 1.3. A cada tipo de arquivo externo, deve ser associado um ícone específico. 1.4. Deverá ser permitido ao usuário definir os ícones que serão utilizados na repre- sentação dos arquivos externos. Quadro 1 - Exemplos de definições e especificação de requisitos / Fonte: o autor. Na definição de requisitos, pode-se utilizar uma narrativa ou representações grá- ficas. Normalmente, as informações coletadas são fornecidas pelo usuário. Por meio dessas definições, pode ser elaborado o documento preliminar de requisitos. Eles podem ser divididos em: ■ Requisitos funcionais (RF). ■ Requisitos não funcionais (RNF). Os requisitos funcionais definem as funções do sistema, ou seja, o que se espera que o sistema faça. Eles relatam as diversas funções que deverão ser providas pelo software ao cliente ou usuário. Por exemplo: ■ Monitorar sensores de temperatura. ■ Cancelar o débito na conta corrente caso a operação não seja completada. ■ Avisar quando o estoque chegar ao limite mínimo. Os requisitos não funcionais estão relacionados às tecnologias utilizadas, à usa- bilidade, ao desempenho, à segurança, confiabilidade, manuteniblidade e dispo- nibilidade que o sistema deverá possuir. Por exemplo: ■ O sistema deverá apresentar interface gráfica (padrão Windows). ■ Facilidade de uso. ■ Possibilidade de ajuda no contexto. U N IC ES U M A R 55 A partir das definições dos requisitos, produzimos o documento preliminar deles, que deve conter todos os serviços (requisitos) requeridos pelo cliente, explicitados de forma clara, sem contradições. Atingir este objetivo é uma tarefa difícil pelas inúmeras dificuldades que são encontradas no domínio. Mas, para que essas dificuldades sejam superadas, o documento preliminar de requisitos deve conter algumas características de qualidade. Segundo Pressman (1995), são elas: Característica 1 – Precisam ser corretas: cada declaração de requisito deve expressar, exatamente, a funcionalidade almejada. Declarações de requisitos que conflitam com suas respectivas necessidades não estão corretas, apenas o usuário pode determinar se a declaração está correta por meio de inspe- ções. Inspeções em que não há a participação do usuário podem tornar o documento de requisitos um documento de adivinhações. Característica 2 – Precisam ser possíveis: você deve ser hábil em imple- mentar cada requisito declarado, observando os recursos e as limitações do sistema e ambiente. Para evitar requisitos impossíveis, trabalhe, com o pes- soal técnico, o documento de requisitos, checando o que é ou não possível fazer, avaliando custos e viabilidade. Característica 3 – Precisam ser necessários para o projeto: cada declaração de requisito deve documentar apenas as necessidades do cliente ou qualquer outra necessidade que exija atender a um requisito externo, ou a uma interfa- ce externa ou, ainda, um padrão. Você pode pensar que “necessário” significa cada requisito com origem na fonte que tem autoridade para determiná-lo. Característica 4 – É necessário definir prioridades: atribua uma prioridade de implementação para cada requisito, ou, ainda, defina casos de uso que auxiliem na indicação do quanto é essencial um requisito para o produto. Clientes devem ter sua parte na responsabilidade do estabelecimento de prioridades. Se todos os requisitos forem igualmente prioritários, você deve ter a habilidade de definir com o cliente a prioridade de cada um. U N ID A D E 2 56 Característica 5 – Não podem ser ambíguas: cada declaração deve ser ex- plicitada de maneira que permita somente uma interpretação. Linguagem natural é altamente propensa a ambiguidades, elimine termos subjetivos, como: amigável ao usuário, fácil, simples, rápido, eficiente, vários, aperfeiçoar, maximizar e minimizar. Escreva cada requisito na linguagem do cliente de forma sucinta, simples, direta, sem utilizar jargões técnicos. Característica 6 – Precisam ser verificáveis: veja se é possível aplicar tes- tes ou utilizar outras abordagens para verificações, tais como inspeções ou demonstrações para se certificar de que cada requisito será implementado apropriadamente. Requisitos que não são consistentes, possíveis ou despro- vidos de ambiguidades também não são verificáveis. Após o estágio de elicitação (extração), um documento contendo os requisitos do cliente (necessidades, restrições, objetivos etc.) é definido. Esse documento, que poderíamos chamar de Documento Preliminar de Requisitos, deverá sofrer um processo de análise. A fase de análise, por sua vez, envolve uma série de atividades (SOMMER- VILE, 2011): ■ Validação e verificação. ■ Análise de viabilidade. ■ Resolução de conflitos. ■ Definição de prioridade. Os requisitos coletados devem ser verificados e validados, com o objetivo de garantir se estão completos, consistentes e de acordo com as reais necessidades do domínio. Assim como nos demais procedimentos da análise de requisitos, a participação dos interessados deve ser intensa, ou seja, todos os agentes que, direta ou indiretamente, influenciam os requisitos do sistema precisam estar envolvidos nesse processo. U N IC ES U M A R 57 Os casos de uso têm um papel importantíssimo na análise de requisitos, pois permitem criar um cenário do domínio, e, talvez, este seja o único instrumento que acompanha o software do início até seu término, além disso, casos de uso representam funcionalidades completas para o usuário e não funcionalidades internas do sistema. Outro ponto importante é que o diagrama de casos de uso é um artefato de comunicação entre cliente, usuários e desenvolvedores. Por ser extremamente simples e, consequentemente, de fácil compreensão, incentiva a participação do cliente e dos usuários no processo de desenvolvimento, também serve como um contrato entre a equipe desenvolvedora e o cliente. A coleção de casos de uso representa todos os modos pelos quais o sistema pode ser utilizado pelos atores envolvidos. Um caso de uso é uma sequência de ações realizada, colaborativamente, pelos atores envolvidos e pelo sistema que produz um resultado significativo (com valor) para os atores, e estes podem ser um usuário ou outro sistema. O diagrama de casos de uso é apenas um panorama visual das funciona- lidades do sistema, é necessária uma descrição textual para detalhar os casos. Portanto, a saída da fase de análise de requisitos é composta por: ■ Lista de requisitos funcionais e não funcionais. ■ Diagrama de casos de uso e definições textuais dos casos. A especificação de requisitos é o processo de escrever os requisitos de usuário e de sis- tema em um documento de requisitos. Idealmente, os requisitos de usuário e de sistema devem ser claros, inequívocos, de fácil compreensão, completos e consistentes. Na práti- ca, isso é difícil de conseguir, pois os stakeholders interpretam os requisitos de maneiras diferentes, e, muitas vezes, notam-se conflitos e inconsistências inerentes aos requisitos. Os requisitos de usuário para um sistema devem descrever os requisitos funcionais e não funcionais de modo que sejam compreensíveispara os usuários do sistema que não te- nham conhecimentos técnicos detalhados. Idealmente, eles devem especificar somente o comportamento externo do sistema. O documento de requisitos não deve incluir detalhes da arquitetura ou projeto do sistema. Fonte: Sommerville (2011, p. 65). explorando Ideias U N ID A D E 2 58 4 DIAGRAMA DE CASOS DE USO Agora que já conhecemos o contexto de requisito de software, vamos para a con- fecção do diagrama de caso de uso. O modelo de casos de uso (que é mais do que o diagrama) é o principal resultado da fase de análise de requisitos, e, também, diagramas de casos de uso são utilizados para representar, de forma panorâmica, os requisitos funcionais de um sistema do ponto de vista do usuário. O modelo de caso de uso é um diagrama utilizado na análise de requisitos com objetivos claros: ■ Compreender o problema (elicitar). ■ Delimitar o sistema (domínio). ■ Definir as funcionalidades oferecidas ao usuário (não precisamos nos preocupar, neste momento, com a implementação). Conhecer a notação para os diagramas de caso de uso preconizados pela UML. Os elementos básicos deste diagrama são: ■ Atores. ■ Casos de uso. ■ Relações entre atores e casos de uso. U N IC ES U M A R 59 Atores Começaremos, então, pelo homem palito, que representa um ator no meu sistema. Esse ator pode ser uma pessoa, outro sis- tema ou uma entidade externa ao sistema. Como encontrar os atores para um sistema? Usando as seguintes dicas: ■ Examine o problema procurando por pessoas ou sis- temas do entorno. ■ Faça as seguintes perguntas: ■ Quais são as pessoas ou os departamentos interessados em determi- nado requisito funcional? ■ Quem suprirá o sistema com informações e quem receberá informa- ções dele? ■ Quais os recursos externos utilizados pelo sistema? ■ Uma pessoa desempenha diferentes papéis? ■ O sistema interage com outros sistemas existentes? Essas dicas também não garantem que o ator foi bem escolhido da primeira vez, pois este é um processo iterativo; dificilmente, a primeira tentativa será a definitiva. Figura 4 - O ator / Fonte: os autores. Os casos de uso são documentados por um diagrama de casos de uso de alto nível. O conjunto de casos de uso representa todas as possíveis interações que serão descritas nos requisitos de sistema. Atores, que podem ser pessoas ou outros sistemas, são repre- sentados como figuras “palito”. Cada classe de interação é representada por uma elipse. Linhas fazem a ligação entre os atores e a interação. Opcionalmente, pontas de flechas podem ser adicionadas às linhas para mostrar como a interação se inicia. Não há distin- ção entre cenários e casos de uso que seja simples e rápida. Algumas pessoas consideram cada caso de uso um cenário único; outros, encapsulam um conjunto de cenários em um único caso de uso. Cada cenário é um segmento através do caso de uso. Portanto, seria um cenário para a interação normal, além de cenários para cada possível exceção. Você pode, na prática, usá-los de qualquer forma. Fonte: Sommerville (2011, p. 74). explorando Ideias U N ID A D E 2 60 Casos de uso A coleção de casos de uso representa, do ponto de vista do usuário, todos os modos de execução do sistema. Um caso de uso é uma sequência de ações que produz um resultado significativo para um ator, e, assim, são necessárias as se- guintes definições: ■ As tarefas de cada ator. ■ Quais informações o ator obtém do sistema. ■ Quem fornece as informações. ■ Quem captura as informações. ■ Se algum ator precisa ser informado sobre eventos produzidos pelo sistema. ■ Se existem eventos externos que devem ser notificados ao sistema. A elipse é a notação para os casos de uso, ou use case, na verdade, as duas denomi- nações são utilizadas. Um caso de uso representa uma atividade que o ator realiza. O caso de uso necessita de uma descri- ção, porém, não há descrição padrão definida pela UML. Em geral, o diagra- ma é bastante informal e sua estrutura- ção (relação entre casos) não deve ser levada ao extremo. É importante ressal- tar que o diagrama de casos de uso é uma forma de visualizar os casos, e não de descrevê-los detalhadamente. Sendo assim, o diagrama, por si só, não é suficiente. Os casos de uso devem vir acompanhados de uma descrição em que, normalmente, relacionamos os se- guintes itens: ■ Nome. ■ Descrição. ■ Requisitos funcionais providos pelo caso de uso. ■ Restrições, tais como pré e pós-condições. Figura 5 - Caso de uso / Fonte: os autores. U N IC ES U M A R 61 ■ Pré-condições: define o que deve ser verdadeiro para que o caso de uso seja iniciado. Por exemplo, em um sistema para seguro de veículo, para o caso de uso Fazer Seguro Veicular, uma pré-condição é apresentar a CNH. ■ Pós-condições: o que se torna verdadeiro pela execução do caso de uso. No mesmo caso anterior, o sistema pode se encontrar em um dos seguintes es- tados: seguro concedido ou seguro não concedido por reprovação da CNH. ■ Invariantes: condições que são verdadeiras durante a execução do caso de uso. ■ Fluxos de eventos: descrição de interações entre atores e sistema que ocor- rem durante a execução do caso de uso. ■ Outras informações: data, autor etc. Relações de dependência As relações de dependência são representadas por uma seta tracejada, ela parte do caso de uso que depende de outro em algum momento. O diagrama da Figura 6 nos diz que, para o cadastro de aluno, é necessária a conclusão do cadastro de pessoa. ´ Figura 6 - Dependência / Fonte: os autores. Se um caso de uso inclui o comportamento de outro, então dizemos que um usa o outro. Aqui, a linha tracejada com uma seta também pode representar uma inclusão de outro caso de uso. No exemplo da Figura 7, o caso de uso Calcular Contas a Receber utilizará a forma de cálculo que está na documentação de Cal- cular Contas a Pagar; usamos este artifício para evitar a necessidade de digitar duas vezes a mesma especificação. U N ID A D E 2 62 <<include>> Calcular contas a pagar Calcular contas receber Figura 7 - Inclusão / Fonte: os autores. Já as extensões adicionam um comportamento a um caso de uso que descreve uma variação do comportamento normal. Nesta situação, o caso de uso base pode ser executado mesmo sem a extensão. O modelo da Figura 8 mostra que existe um cálculo em Calcular Descontos que se estenderá para Calcular Contas a Pagar, ampliando o significado da fórmula existente em Calcular Descontos. Figura 8 - Extensão / Fonte: os autores. Vale lembrar que o diagrama de casos de uso é apenas um panorama visual das funcionalidades do sistema; é necessária uma descrição textual para detalhar os casos de uso. Ilustraremos esta documentação, por meio do caso de uso, para resolver ex- pressões aritméticas. Figura 9 - Diagrama de caso de uso / Fonte: os autores. U N IC ES U M A R 63 Podemos fazer a descrição textual para o caso de uso Resolver Expressões Arit- méticas de acordo com o quadro a seguir: Nome do caso de uso Resolver Expressões Aritméticas. Descrição Permite resolver expressões envolvendo números inteiros e reais e as operações básicas de soma, subtração, multiplica- ção e divisão. Ator Aluno. Pré-condições O sistema deve estar em execução. Pós-condições Expressão aritmética resolvida ou cance- lamento da operação pelo aluno. Fluxo básico Usuário Sistema {Solicita expressão} Solicita a expressão (A2). Fornece a expressão {Valida a expressão} Avalia se a expressão é sintaticamente correta (A1). {Calcula valor} Calcula o valor da expressão. {Mostra o resultado} Informa o resultado da expressão. {Fim} Fim do caso de uso. U N ID A D E 2 64 Fluxos alternativos A1: em {Valida expressão} Se o usuário fornecer uma expressão sintaticamente incorreta, informá-lo so- bre o erro e retornar ao fluxo básico em {Solicita expressão} A2: em {Solicita expressão} O usuário pode decidir encerrar o caso de uso sem fornecer uma expressão. Neste caso, retornar
Compartilhar