Baixe o app para aproveitar ainda mais
Prévia do material em texto
ANÁLISE E PROJETO ORIENTADO A OBJETOS Professor Me. Déverson Rogério Rando GRADUAÇÃO Unicesumar C397 CENTRO UNIVERSITÁRIO DE MARINGÁ. Núcleo de Educação a Distância; RANDO, Déverson Rogério. Análise e Projeto Orientado a Objetos. Déverson Rogério Rando. (Reimpressão revista e atualizada) Maringá-Pr.: UniCesumar, 2016. 176 p. “Graduação - EaD”. 1. Projeto. 2. Orientado. 3. Objetos. 4. EaD. I. Título. ISBN 978-85-459-0113-6 CDD - 22 ed. 005.1 CIP - NBR 12899 - AACR/2 Ficha catalográfica elaborada pelo bibliotecário João Vivaldo de Souza - CRB-8 - 6828 Reitor Wilson de Matos Silva Vice-Reitor Wilson de Matos Silva Filho Pró-Reitor de Administração Wilson de Matos Silva Filho Pró-Reitor de EAD Willian Victor Kendrick de Matos Silva Presidente da Mantenedora Cláudio Ferdinandi NEAD - Núcleo de Educação a Distância Direção Operacional de Ensino Kátia Coelho Direção de Planejamento de Ensino Fabrício Lazilha Direção de Operações Chrystiano Mincoff Direção de Mercado Hilton Pereira Direção de Polos Próprios James Prestes Direção de Desenvolvimento Dayane Almeida Direção de Relacionamento Alessandra Baron Gerência de Produção de Conteúdo Juliano de Souza Supervisão do Núcleo de Produção de Materiais Nádila de Almeida Toledo Coordenador de Conteúdo Fabiana de Lima Design Educacional Paulo Victor Souza e Silva Iconografia Amanda Peçanha dos Santos Ana Carolina Martins Prado Projeto Gráfico Jaime de Marchi Junior José Jhonny Coelho Arte Capa André Morais de Freitas Editoração Fernando Henrique Mendes Revisão Textual Viviane Favaro Notari Ilustração Bruno Pardinho Viver e trabalhar em uma sociedade global é um grande desafio para todos os cidadãos. A busca por tecnologia, informação, conhecimento de qualidade, novas habilidades para liderança e so- lução de problemas com eficiência tornou-se uma questão de sobrevivência no mundo do trabalho. Cada um de nós tem uma grande responsabilida- de: as escolhas que fizermos por nós e pelos nos- sos farão grande diferença no futuro. Com essa visão, o Centro Universitário Cesumar assume o compromisso de democratizar o conhe- cimento por meio de alta tecnologia e contribuir para o futuro dos brasileiros. No cumprimento de sua missão – “promover a educação de qualidade nas diferentes áreas do conhecimento, formando profissionais cidadãos que contribuam para o desenvolvimento de uma sociedade justa e solidária” –, o Centro Universi- tário Cesumar busca a integração do ensino-pes- quisa-extensão com as demandas institucionais e sociais; a realização de uma prática acadêmica que contribua para o desenvolvimento da consci- ência social e política e, por fim, a democratização do conhecimento acadêmico com a articulação e a integração com a sociedade. Diante disso, o Centro Universitário Cesumar al- meja ser reconhecido como uma instituição uni- versitária de referência regional e nacional pela qualidade e compromisso do corpo docente; aquisição de competências institucionais para o desenvolvimento de linhas de pesquisa; con- solidação da extensão universitária; qualidade da oferta dos ensinos presencial e a distância; bem-estar e satisfação da comunidade interna; qualidade da gestão acadêmica e administrati- va; compromisso social de inclusão; processos de cooperação e parceria com o mundo do trabalho, como também pelo compromisso e relaciona- mento permanente com os egressos, incentivan- do a educação continuada. Seja bem-vindo(a), caro(a) acadêmico(a)! Você está iniciando um processo de transformação, pois quan- do investimos em nossa formação, seja ela pessoal ou profissional, nos transformamos e, consequente- mente, transformamos também a sociedade na qual estamos inseridos. De que forma o fazemos? Criando oportunidades e/ou estabelecendo mudanças capa- zes de alcançar um nível de desenvolvimento compa- tível com os desafios que surgem no mundo contem- porâneo. O Centro Universitário Cesumar mediante o Núcleo de Educação a Distância, o(a) acompanhará durante todo este processo, pois conforme Freire (1996): “Os homens se educam juntos, na transformação do mundo”. Os materiais produzidos oferecem linguagem dialó- gica e encontram-se integrados à proposta pedagó- gica, contribuindo no processo educacional, comple- mentando sua formação profissional, desenvolvendo competências e habilidades, e aplicando conceitos teóricos em situação de realidade, de maneira a inse- ri-lo no mercado de trabalho. Ou seja, estes materiais têm como principal objetivo “provocar uma aproxi- mação entre você e o conteúdo”, desta forma possi- bilita o desenvolvimento da autonomia em busca dos conhecimentos necessários para a sua formação pes- soal e profissional. Portanto, nossa distância nesse processo de cres- cimento e construção do conhecimento deve ser apenas geográfica. Utilize os diversos recursos peda- gógicos que o Centro Universitário Cesumar lhe possi- bilita. Ou seja, acesse regularmente o AVA – Ambiente Virtual de Aprendizagem, interaja nos fóruns e en- quetes, assista às aulas ao vivo e participe das discus- sões. Além disso, lembre-se que existe uma equipe de professores e tutores que se encontra disponível para sanar suas dúvidas e auxiliá-lo(a) em seu processo de aprendizagem, possibilitando-lhe trilhar com tranqui- lidade e segurança sua trajetória acadêmica. Diretoria Operacional de Ensino Diretoria de Planejamento de Ensino Professor Me. Déverson Rogério Rando Mestre em Ciência da Computação pela Universidade Estadual de Maringá (UEM). Especialista em Engenharia de Software pela Universidade Norte do Paraná. Graduado em Geografia pela Universidade Estadual de Londrina e Análise e Desenvolvimento de Sistemas pelo CESUMAR. 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 disciplinas 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, Trabalho de Conclusão de Curso. A U TO R SEJA BEM-VINDO(A)! Caro(a) Aluno(a)! Seja bem-vindo(a) à disciplina de Análise e Projeto Orientado a Ob- jetos (OO). Sou o professor Déverson Rogério Rando. Esta disciplina abordará vários aspectos relacionados à análise e projeto de sistemas orientados a objetos, utilizando como notação a UML. Apresento a você o livro que conduzirá seus estudos, auxiliando no aprendizado de aná- lise e projeto orientado a objetos com a UML. O livro encontra-se estruturado em cinco unidades e cada uma conta com uma seção Reflita, Saiba Mais, Vídeos e Atividades de Autoestudo. A seção Reflita apresenta frases que te remetem ao conteúdo estudado na disciplina e o fazem pensar um pouco mais sobre ele. A seção Saiba Mais conta com links para artigos que complementam o aprendizado sobre análise de projetos. A seção Vídeo apresenta links para vídeos. E, por último, a seção Atividades de Autoestudo ex- pressa um conjunto de questões sobre o conteúdo abordado. A unidade I apresenta os conceitos iniciais sobre a análise e projetos orientados a ob- jetos. 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. Conhece- remos os conceitos básicos que envolvem a orientação a objetos, para dar subsídio nos capítulos subsequentes. E, por fim, veremos os principais diagramas da UML utilizados na documentação de software. Na unidade II, estudaremos as fases que compreendem a análise e o projeto de um sof- tware. Entraremos em contato com dois dos modelos de processos, cascata e evolucio- nário, veremos as vantagens e desvantagens da utilização de cada um desses métodos. Abordaremos, também, os requisitos de software e vamos conhecer os procedimentos mínimos para a obtenção de um software de qualidade. Encerraremos aunidade falan- do 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 III está toda dedicada à confecção do Diagrama de Classes responsável por demonstrar a estrutura estática do sistema. Conheceremos a notação para o diagrama de classes em detalhes. Abordaremos os conceitos e a assinatura da declaração de atri- butos e métodos. Veremos como ocorrem as ligações entre as classes e como definir a multiplicidade entre elas. Discutiremos, ainda, sobre as várias formas de se associar as classes, sejam elas unária, binária, ternária, associativa, agregação ou generalização. Na unidade IV, avançaremos conhecendo mais três diagramas, essenciais na análise e projeto OO, que utilizaremos para refinar o diagrama de classes que representa a estru- tura do sistema. O primeiro diagrama que veremos nessa unidade é o de sequência, que tem como objetivo estudar as interações entre os objetos, considerando a dimensão tempo. O segundo diagrama que veremos é o de estados, que tem como objetivo es- pecificar 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 que o diagrama de sequência, porém não considera o tempo e sim a ordem da comunicação. APRESENTAÇÃO ANÁLISE E PROJETO ORIENTADO A OBJETOS Por fim, na unidade V, resolveremos, juntos, um estudo de caso, no qual teremos a oportunidade de apresentar de forma prática a construção dos diagramas citados na elaboração da análise e projeto de um software. Dessa forma, reforçaremos to- dos os conceitos trabalhados nas unidades anteriores. Ao longo deste livro, você encontrará indicações de Leitura Complementar, as quais enriquecerão o seu conhecimento sobre projetos. É importante que você desenvol- va as Atividades de Autoestudo para fixar o conteúdo abordado e identificar even- tuais dificuldades. Vamos lá!? APRESENTAÇÃO SUMÁRIO 09 UNIDADE I INTRODUÇÃO AO ESTUDO DE ORIENTAÇÃO A OBJETOS 15 Introdução 16 Introdução À Orientação A Objetos 19 Evolução Dos Métodos OO 21 Conceitos Básicos De OO 27 Principais Diagramas da UML 38 Considerações Finais UNIDADE II CASOS DE USO 47 Introdução 48 Fases da Análise e do Projeto 53 Modelos de Processo 58 Requisitos de Software 63 Diagrama de Casos de Uso 71 Considerações Finais SUMÁRIO UNIDADE III DIAGRAMA DE CLASSES 77 Introdução 78 Diagrama de Classes 79 Notação Para Classes 81 Atributos 83 Métodos 85 Multiplicidade 88 Associação Unária 89 Associação Binária 90 Classe Associativa 91 Agregação 94 Generalização 98 Herança Múltipla 99 Considerações Finais SUMÁRIO 11 UNIDADE IV DIAGRAMAS DE SEQUÊNCIA, ESTADO E COLABORAÇÃO 109 Introdução 110 Avançando nos Diagramas 112 Diagrama de Sequência 120 Diagrama de Estados 125 Diagrama de Comunicação 129 Considerações Finais UNIDADE V ESTUDO DE CASO 137 Introdução 138 Ferramentas Case 139 Estudo de Caso 142 Diagrama de Caso de Uso 153 Diagrama de Classes 156 Diagrama de Sequência 162 Diagrama de Estado 164 Diagrama de Comunicação 168 Considerações Finais 173 CONCLUSÃO 175 REFERÊNCIAS U N ID A D E I Professor Me. Déverson Rogério Rando INTRODUÇÃO AO ESTUDO DE ORIENTAÇÃO A OBJETOS Objetivos de Aprendizagem ■ Entender a importância da análise e projeto. ■ Conhecer a evolução dos métodos OO. ■ Compreender as características dos métodos OO. ■ Entender os diferentes termos utilizados em OO. ■ Conhecer os principais diagramas da UML. Plano de Estudo A seguir, apresentam-se os tópicos 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 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 desen- volvimento de software. É nessa fase que determinamos e especificamos 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 colabora- tivo entre analistas de sistemas e usuários. Em seguida, veremos como os métodos surgiram e como aconteceu a evo- lução deles. Abordaremos a partir do primeiro método Orientado a Objetos, proposto por Shlaer e Mellor em 1988, o OOSA, até chegarmos a Unified Modeling Language-UML, que será a linguagem que utilizaremos para as nossas análises e 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 dos méto- dos que serão apresentados. Ou seja, a evolução de todos os demais 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 ter- mos utilizados na análise e no projeto OO. Dentre os conceitos que veremos, estão o de objeto, abstração, classe, instância, atributo, operação, mensagem, evento, estado, parâmetro, entre outros. 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 diagrama de classes que modela a estrutura estática do sistema, o diagrama de sequência, o de cola- boração e o de estado. Então, o que estamos esperando? Vamos ao trabalho? Boa leitura a todos. Introdução Re pr od uç ão p ro ib id a. A rt . 1 84 d o Có di go P en al e L ei 9 .6 10 d e 19 d e fe ve re iro d e 19 98 . 15 INTRODUÇÃO AO ESTUDO DE ORIENTAÇÃO A OBJETOS Reprodução proibida. A rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998. IU N I D A D E16 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 essa 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 respectivo ambiente. De acordo com Sommerville (2011), podemos chamar “análise de sistemas” de “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 de sistemas, por ser uma etapa inicial e cujas falhas terão efeitos em cadeia nas etapas subsequentes, assim como no produto final. A determi- nação incorreta dos requisitos levará à obtenção e disponibilização de sistemas computacionais inadequados. 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 uti- lizados. 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 con- siste na solução computacional aplicada ao problema. Dizer onde acaba a análise e inicia o projeto é muito complicado, uma vez que o projeto é o resultado de refinamentos sucessivos do modelo conceitual de análise. A Orientação a Objetos fez com que fossealterado o enfoque necessário para desenvolver um sistema, enquanto na programação estruturada tínhamos Introdução à Orientação a Objetos Re pr od uç ão p ro ib id a. A rt . 1 84 d o Có di go P en al e L ei 9 .6 10 d e 19 d e fe ve re iro d e 19 98 . 17 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 tratar esses atributos, 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 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 é compreen- dido 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 projeto estruturado são: ■ Diagrama entidade e relacionamento (DER). ■ Dicionários de dados. ■ Diagrama de Fluxo de Dados (DFD). O DER modela a estrutura de dados parados, ou seja, é o modelo conceitual do sistema. Mostra-nos as entidades e seus relacionamentos, nesse 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 de dados, em outras palavras, mostra os dados em movi- mento, 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 desenvol- vimento de software que organiza o software como uma coleção de objetos que INTRODUÇÃO AO ESTUDO DE ORIENTAÇÃO A OBJETOS Reprodução proibida. A rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998. IU N I D A D E18 contém tanto a estrutura dos dados como 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 de objetos. A proposta da orientação a objetos é deslocar o esforço de desenvolvimento para a fase de análise, dando ênfase nas estruturas de dados antes do que as fun- ções, os benefícios são: a reutilização do código (componentes), a confiabilidade (objetos encapsulados), o aumento de produtividade (SOMMERVILE, 2011). Com o planejamento adequado, desenvolvedores capacitados e a 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 modelar os requisitos dos usuários que o sistema deve atender. Nos anos 50, quando inicia a informática, desenvolver software era um pro- cesso informal, sem técnicas de projeto, conceito de reusabilidade, controle de qualidade ou documentação. Neste artigo, Marcos Rodrigues Pinto e Sér- gio Cosme Noronha C. Filho fazem um Estudo comparativo sobre a aborda- gem tradicional de desenvolvimento de sistemas e a orientação a objetos. Confira o texto completo no link disponível em: <http://www.dcc.ufrj.br/~s- chneide/es/2002/1/g11/index.htm>. Acesso em: 28 jul. 2015. Fonte: o autor. Evolução dos Métodos OO Re pr od uç ão p ro ib id a. A rt . 1 84 d o Có di go P en al e L ei 9 .6 10 d e 19 d e fe ve re iro d e 19 98 . 19 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 também, 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 de 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 metodologia 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. Shlaer e Mellor (1990): abrangem as fases de análise, projeto e implementa- ção. Propõem mecanismos para facilitar a representação de modelos dinâmicos dos objetos, dando ênfase na modelagem da informação, por meio dos modelos de objetos, de estados, dos 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 orien- tado 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 objetos, modelagem dinâmica e modelagem funcional, des- tacando o tratamento de processos e dividindo a fase de projeto em projeto de objetos e projeto de sistema. INTRODUÇÃO AO ESTUDO DE ORIENTAÇÃO A OBJETOS Reprodução proibida. A rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998. IU N I D A D E20 Martin e Odell (1995): abrange as fases de análise e projeto. Propõe o uso da Engenharia da Informação Baseada em Objetos por meio de um repositório de objetos, para obtenção de um alto nível de reaproveitamento dos sistemas. Fusion (1996): abrange as fases de análise, projeto e implementação. Sintetizando os aspectos 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). UML-Unified Method Language (2000): abrange as fases de levantamento de requisitos, análise, projeto e implementação. Fusão dos métodos de James Rumbaugh/OMT, Grady Boock e Ivar Jacobson. A fusão inicia com o trabalho de James Rumbaugh e Grady Booch, os dois metodistas que ganharam maior popularização; os quais se juntaram para criar um método comum por meio de pontos fortes ao público em 1995. Em seguida, em meados de 1996, Ivar 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, con- siderado um padrão mundial. A UML sugere fortemente a adoção de casos de uso (use cases) como dire- cionador de projetos de software, a utilização de diagramas de interação para identificação de objetos e uma série de outros conceitos. Figura 1: Objetos Concretos Figura 2: Objetos Abstratos Figura 3: Abstração de Bolsa Figura 4: Abstração de avião Conceitos Básicos de OO Re pr od uç ão p ro ib id a. A rt . 1 84 d o Có di go P en al e L ei 9 .6 10 d e 19 d e fe ve re iro d e 19 98 . 21 CONCEITOS BÁSICOS DE OO Conheceremos, a seguir, os principais termos e conceitos utilizados na análise e projeto OO. Vamos lá! ■ Objeto: qualquer coisa concreta ou abstrata que existe no mundo real, em quese pode individualizá-la por possuir comportamentos e caracte- rísticas próprias. ■ Abstração: abstraímos quando definimos um objeto conceitual partindo de OBJETOS do mundo real com os mesmos comportamentos e caracte- rísticas, os quais são classificados como de um mesmo tipo. Figura 5: Abstração de Esporte Figura 6: Classe Funcionário Fonte: o autor. Figura 7: Classe e Objetos Fonte: o autor. ©istock INTRODUÇÃO AO ESTUDO DE ORIENTAÇÃO A OBJETOS Reprodução proibida. A rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998. IU N I D A D E22 ■ Classe: representa a ABSTRAÇÃO de um conjunto de OBJETOS do mundo real que possui comportamentos e características comuns. ■ Instância: é cada umas das ocorrências de um OBJETO formado a par- tir da sua CLASSE. Figura 8: Classe, objeto e valor Fonte: o autor. Figura 9: Operação Fonte: o autor. Figura 10: Mensagem Fonte: o autor. Conceitos Básicos de OO Re pr od uç ão p ro ib id a. A rt . 1 84 d o Có di go P en al e L ei 9 .6 10 d e 19 d e fe ve re iro d e 19 98 . 23 ■ Atributo: é uma característica particular que os OBJETOS de uma CLASSE possuem, assumindo valores diferentes para cada OBJETO. ■ 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. ■ 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. Estado Criado Estado Eliminado Estado Parado Estado Decolando Figura 13: Estado Fonte: o autor. Figura 12: Parâmetro Fonte: o autor. Figura 11: Evento Fonte: o autor. Figura 14: Transição de estado Fonte: o autor. INTRODUÇÃO AO ESTUDO DE ORIENTAÇÃO A OBJETOS Reprodução proibida. A rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998. IU N I D A D E24 ■ Evento: é um tipo especial de OPERAÇÃO que faz com que os OBJETOS mudem de ESTADO. ■ Parâmetro: é um ou mais ATRIBUTOS que são carregados para dentro de uma MENSAGEM. ■ Estado: é a forma de apresentação dos OBJETOS de uma CLASSE em um determinado instante. ■ Transição de Estado: é quando ocorre a mudança de ESTADO de um OBJETO de uma CLASSE como resposta à chegada de um EVENTO. Figura 16: Encapsulamento Fonte: o autor. Figura 15: Associação de classes Fonte: o autor. Figura 17: Polimorfismo Fonte: o autor. Conceitos Básicos de OO Re pr od uç ão p ro ib id a. A rt . 1 84 d o Có di go P en al e L ei 9 .6 10 d e 19 d e fe ve re iro d e 19 98 . 25 ■ Associação: é a forma como os OBJETOS de uma mesma CLASSE ou de CLASSES diferentes se conectam. ■ Encapsulamento: é a reunião de características e comportamentos de OBJETOS em uma CLASSE. ■ Polimorfismo: é a capacidade que OBJETOS de CLASSES diferentes pos- suem de se comportarem de forma diferente em uma mesma operação. A estrutura (ATRIBUTOS) de cada CLASSE é diferente. Figura 18: Troca de mensagens entre os objetos Fonte: o autor. Quadro 1: Declaração de um método Fonte: o autor. Figura 19: Herança Fonte: o autor. INTRODUÇÃO AO ESTUDO DE ORIENTAÇÃO A OBJETOS Reprodução proibida. A rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998. IU N I D A D E26 ■ Método: é o algoritmo (conjunto de passos) que um OBJETO executa quando 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; } ■ Colaboração: é a troca de MENSAGENS que acontece entre OBJETOS e atores. ■ Herança: é a propriedade que possibilita que a CLASSE herde caracte- rísticas e comportamento de uma outra CLASSE. Figura 20: Organização do Diagrama UML Fonte: o autor. Principais Diagramas da Uml Re pr od uç ão p ro ib id a. A rt . 1 84 d o Có di go P en al e L ei 9 .6 10 d e 19 d e fe ve re iro d e 19 98 . 27 PRINCIPAIS DIAGRAMAS DA UML Agora que já conhecemos os principais termos utilizados na análise e projeto OO, quero convidar você a conhecer os diagramas utilizados para documentação de software. Apresentarei, de forma sucinta, cada um dos diagramas e veremos com detalhes nas unidades seguintes. A UML 2.0 apresenta treze diagramas, classificados em estruturais e de com- portamento. A figura 20 mostra essa organização em um diagrama de classes. É comum verificarmos que a documentação do software, na maioria das vezes, não tem a devida atenção da equipe de desenvolvimento, ou por preguiça, ou por falta de tempo, ou mesmo por achar que é uma perda de tempo elaborar inúmeros diagramas. Porém bons softwares têm documentação que nos permite contar e entender a história desse software. Figura 21: Diagrama de Caso de Uso Fonte: o autor. INTRODUÇÃO AO ESTUDO DE ORIENTAÇÃO A OBJETOS Reprodução proibida. A rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998. IU N I D A D E28 DIAGRAMAS DE COMPORTAMENTO Os diagramas de comportamento são utilizados para descrever o sistema mode- lado já 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 Iniciaremos, então, pelo Diagrama de Casos de Uso (comportamento), utilizado na análise de requisitos. Esse 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 stick man (homem palito) e suas res- pectivas ações descritas nas elipses. Principais Diagramas da Uml Re pr od uç ão p ro ib id a. A rt . 1 84 d o Có di go P en al e L ei 9 .6 10 d e 19 d e fe ve re iro d e 19 98 . 29 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, em que, a partir dessa ação, é desencadeado um conjunto de men- sagens entre os objetos que permite a verificação da existência da pessoa aluno, em seguida, é criado o item de empréstimo, que verifica a existência do exem- plar solicitado, realizando o empréstimo. Como é possível observar, a partir das informações fornecidas pelo dia- grama de sequência, pode-se identificar os métodos associados às classes, além da identificação das relações entre elas. Figura 22: Diagrama de Sequência Fonte: o autor. INTRODUÇÃO AO ESTUDO DE ORIENTAÇÃO A OBJETOS Reprodução proibida. A rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998. IU N I D A D E30 Uma outra forma de representar o cenário é pelo diagrama de comunicação (com- portamento), este contém as mesmas informações que o diagrama de sequência, porém não considera a dimensão temporal. Principais Diagramas da Uml Re pr od uç ão p ro ib id a. A rt . 1 84 d o Có di go P en al e L ei 9 .6 10 d e 19 d e fe ve re iro d e 19 98 . 31 DIAGRAMA DE ESTADOS Em seguida, veremos o diagrama de estados (comportamento), que tem como objetivo 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 comportamentos considerando o seu estado. O estado guarda informações sobre o passado do objeto, a transição indica que o objeto está mudando deestado e uma ação é o detalhamento de uma atividade que deve ser execu- tada em determinado momento. Fonte: adaptado de Sommervile (2011). Figura 23: Diagrama de Estado Fonte: o autor. Figura 24: Diagrama de Comunicação (comportamento) Fonte: o autor. INTRODUÇÃO AO ESTUDO DE ORIENTAÇÃO A OBJETOS Reprodução proibida. A rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998. IU N I D A D E32 Não são todas as classes do sistema que apresentam mais de um estado. O diagrama de estado abaixo mostra todos os estados do exemplar no momento empréstimo, o início do estado é marcado pelo círculo e o fim é mercado pelo duplo círculo. Figura 25: Diagrama de Atividades Fonte: o autor. Principais Diagramas da Uml Re pr od uç ão p ro ib id a. A rt . 1 84 d o Có di go P en al e L ei 9 .6 10 d e 19 d e fe ve re iro d e 19 98 . 33 DIAGRAMA DE COMUNICAÇÃO O diagrama de comunicação permite a identificação das classes mais próxi- mas e a ordem de envio de mensagens é identificada por números sequenciais. A seguir, é apresentado o diagrama de comunicação que é equivalente ao dia- grama de sequência mostrado anteriormente. DIAGRAMA DE ATIVIDADES O diagrama de atividade é, em sua essência, um gráfico de fluxo, demonstrando como ocorre o fluxo de controle entre as atividades. Esse diagrama é um dos mais detalhistas, dando ênfase maior ao nível de algoritmo. Os diagramas de atividades podem ser utilizados com vários propósitos. Dentre seus propósitos, podemos citar a captura do funcionamento interno do objeto, bem como mostrar como pode ser executo um conjunto de ações rela- cionadas e como elas podem afetar os objetos ao seu redor. INTRODUÇÃO AO ESTUDO DE ORIENTAÇÃO A OBJETOS Reprodução proibida. A rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998. IU N I D A D E34 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 representam 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. CLASSES Após a elaboração do diagrama de caso de uso, podemos modelar a primeira versão do diagrama de Classes. O diagrama de classes 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 com- portamento de seus objetos, e os possíveis estados do objeto são modelados por meio de atributos. Para entendermos melhor, vamos fazer a analogia com a construção de um veículo. Todos os veículos serão rigorosamente iguais, pois estarão baseados em uma planta (projeto) que esclarece o número de portas, potência do motor, número de marchas do câmbio, dentre 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, abaixo, modela a estrutura estática do sistema de biblioteca 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 03, mas, para adiantar, é possível observar nesse 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: o autor. Figura 27: Diagrama de Objetos Fonte: o autor. Principais Diagramas da Uml Re pr od uç ão p ro ib id a. A rt . 1 84 d o Có di go P en al e L ei 9 .6 10 d e 19 d e fe ve re iro d e 19 98 . 35 DIAGRAMA DE OBJETOS Os diagramas de objetos correspondem a um segundo nível de abstração do dia- grama de classes. Não têm a mesma importância do diagrama de classes, porém pode 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 do diagrama de classes para mostrar as instâncias da classe. 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ódu- los executáveis do software. Apesar de ser um diagrama de alto nível, a organização do sistema é dependente da linguagem de programação utilizada, portanto, a solução de desenvolvimento adotada refletirá diretamente nesse diagrama. Figura 28: Diagrama de Componentes Fonte: o autor. INTRODUÇÃO AO ESTUDO DE ORIENTAÇÃO A OBJETOS Reprodução proibida. A rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998. IU N I D A D E36 Um componente corresponde a uma parte do código distribuível que pode ser substituída por outro componente e que contém elementos que mostram um conjunto de interfaces fornecidas e requeridas. Podemos apresentar como exem- plos de componentes os executáveis, tabelas, bibliotecas, documento e arquivo. DIAGRAMA DE IMPLANTAÇÃO Diagramas de implantação são utilizados para modelar a arquitetura física de distribuição onde 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 computacio- nal com memória e processamento, ou seja, um disco rígido, um computador, uma impressora etc. O diagrama de implantação é uma ferramenta importante quando qui- ser saber quais computadores e outros hardwares estão conectados, bem como saber como estão distribuídas as classes e quando a atualização de determinado arquivo resulta na recompilação de outros. Principais Diagramas da Uml Re pr od uç ão p ro ib id a. A rt . 1 84 d o Có di go P en al e L ei 9 .6 10 d e 19 d e fe ve re iro d e 19 98 . 37 DIAGRAMA DE PACOTES O pacote representa um agrupamento de classes, formando uma unidade. Normalmente, os pacotes apresentam relações, em que um pacote depende de outro para o funcionamento. Como a estrutura de uma aplicação é dada pelas classes e associações, pode- mos 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 subsistemas, que, nesse caso, cada subsistema é representado por um pacote. Dessa forma, um pacote pode representar uma biblioteca, um subsistema, um sistema, entre outros. Um pacote, também, pode conter outros pacotes. Os pacotes, invariavelmente, apresentam dependência entre si. O relaciona- mento de dependência indica que o pacote dependente precisa de alguma forma do pacote do qual depende. Figura 29: Diagrama de Implantação Fonte: o autor. Figura 30: Diagrama de Pacotes Fonte: o autor. INTRODUÇÃO AO ESTUDO DE ORIENTAÇÃO A OBJETOS Reprodução proibida. A rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998. IU N I D A D E38 CONSIDERAÇÕES FINAIS Nesta unidade, aprendemos que a análise é a solução conceitual dada ao problema. 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 gerencia- dor 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 o software como uma coleção de objetos, que contém tanto a estrutura dos dados como o comportamento deles. Verificamos que os métodosde análise e projeto orientado a objetos surgiram assim que as linguagens 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. Por meio do estudo da evolução dos métodos, podemos perceber que 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 James Rumbaugh e Grady Booch, em seguida, em meados de 1996, Ivar Jacobson integrou-se ao grupo e lançaram a UML versão 0.9. A partir daí, criaram forças com a coope- ração da OMG (Object Management Group) em julho de 1997, considerado um padrão mundial. Considerações Finais Re pr od uç ão p ro ib id a. A rt . 1 84 d o Có di go P en al e L ei 9 .6 10 d e 19 d e fe ve re iro d e 19 98 . 39 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, dentre 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ê vai conhecer as eta- pas da análise e a notação para o diagrama de caso de uso. 1. Na análise e 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 projeto estruturados, na orientação a objetos, o processo a ser infor- matizado é 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 Jacob- son 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 pro- postos pelos autores citados? I. A UML – Unified Modeling Language abrange as fases de levantamento de requisitos, 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 ob- jetos? II. Objetos: qualquer coisa concreta ou abstrata com existência perceptível no mundo real. III. Classes: ABSTRAÇÃO de um conjunto de OBJETOS. IV. Atributo: característica particular possuída por todos os OBJETOS de uma CLASSE. 5. Chave Primária: identifica unicamente um objeto. Está(ão) correta(s) somente: A. ( ) I. B. ( ) I e II. C. ( ) I, II e III. D. ( ) III e IV. E. ( ) I, II, III e IV. 4. É comum verificarmos que a documentação do software, na maioria das vezes, não tem a devida atenção da equipe de desenvolvimento, ou por preguiça, ou por falta de tempo, ou mesmo por achar que é uma perda de tempo elaborar inúmeros diagramas. Bons softwares, porém, têm documentação que nos per- mite contar e entender a história desse software. Contamos essa história por meio de diagramas, sabendo disso, quais diagramas são utilizados na UML e como estão organizados? 41 5. O Diagrama _____________ contém as mesmas informações que o diagrama de sequência, porém não considera a dimensão temporal. Observe os Diagramas: I. Comunicação II. Caso de Uso III. Classes IV. Estado A(s) afirmativa(s) que pode(m) completar a lacuna é(são) somente: A. ( ) I. B. ( ) I e II. C. ( ) I, II e III. D. ( ) III e IV. E. ( ) I, II, III e IV. QUALIFICAÇÃO DE SOFTWARES Como pode ser qualificado um software? É muito simplório definir isso pelo tempo de desenvolvimento ou pela excelência na programação. Existe caso de desenvolvimento de softwares em que o programador ouve todas as informações e apresenta uma solu- ção instantânea, quase que “mágica”. Algo que resolve perfeitamente o que foi apresen- tado. Olhando assim, a sensação que temos parece que o atendimento foi excepcional, contudo, na maioria dos casos, programas feitos nesse formato não suprem a real ne- cessidade do cliente. Não podemos julgar o cliente por não saber apresentar de forma assertiva as suas ne- cessidades, pois o conhecimento da construção técnica é inexistente ou superficial, 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 vai 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á tenha viven- ciado isso. Mas esse problema não é exclusivo do desenvolvimento de softwares, é algo corriquei- ro no mercado. Para provar isso, basta precisarmos de um serviço em que não tenha nenhum conhecimento do processo, como consertar um carro. A solução só vem quan- do um profissional qualificado está mais preocupado em te satisfazer como cliente do que resolver exclusivamente o seu problema apresentado. Os profissionais que mantêm esse método de atendimento vão sendo substituídos aos poucos. Na rotina diária de programação, normalmente, o início do projeto vem de um conversa informal e só lá na primeira apresentação, depois de um grande tempo de dedicação, é que o cliente consegue esclarecer ainda de forma abstrata com frases como “não é bem isso que eu esperava”. Outro caso comum que acontece pela falta de alinhamento é as solicitações do cliente irem aumentando durante o processo todo, e, como nada é esta- belecido de forma clara no início do trabalho, você pode até prolongar o projeto, mas, possivelmente, não atenderá todas as necessidades do seu cliente. Finalizo lembrando que cliente não tem obrigação de entender como funciona toda a programação e que a preocupação deve ser do programador de atender o cliente, e não o contrário. Um bom profissional precisa “interpretar” a necessidade de um cliente e oferecer não o que ele está pedindo, mas sim o que vai suprir sua necessidade. Fonte: Autor. Material Complementar MATERIAL COMPLEMENTAR Desenvolvendo software com UML 2.0 defi nitivo Ernani Medeiros Editora: Makron Books Sinopse: Este livro apresenta, de maneira prática e já testada, o que é, para que serve e como usar os diagramas da UML 2.0. Além de sugerir o melhor momento para se 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, fi nalidade do conceito e como usá-lo. Para aprofundar os conhecimentos sobre OO, leia o artigo intitulado “A história de UML e seus diagramas”. Esse artigo descreve a história de UML desde a década de 1990 até o momento atual. Apresenta-se a organização dos treze diagramas de UML, classifi cando-os em diagramas estruturais e comportamentais. Os quatro documentos pertencentes à especifi cação também são mencionados e explicados. O artigo encontra-se disponível em: <https://projetos.inf.ufsc.br/arquivos_projetos/projeto_721/ artigo.tcc.pdf>. Acesso em: 28 jul. 2015. U N ID A D E II Professor Me. Déverson Rogério Rando CASOS DE USO Objetivos de Aprendizagem ■ Conhecer as fases da 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 diagrama de Caso de Uso. Plano de EstudoA seguir, apresentam-se os tópicos que você estudará nesta unidade: ■ Fases da análise e do projeto ■ Modelos de processo ■ Requisitos de software ■ Diagrama de Casos 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 acredito ser a fase mais difícil e crítica da produção de um software, difícil porque é o momento que ocorrem as tentativas de delimitar o domínio do problema e entendê-lo, crítica porque uma análise mal feita comprometerá todas as outras fases de produção do software, além do que o produto a ser entregue não será o que o cliente ini- cialmente requeria. Entenderemos e conheceremos dois modelos de processos de software, entre os “N” processos existentes. Citarei, aqui, o modelo em cascata e o evo- lucioná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 estabele- cidas por clientes e usuários do sistema que definem as diversas propriedades 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 que o sistema deverá possuir. Ainda, veremos a importância do levantamento de requisitos para o desen- volvimento de software. Aprenderemos que a definição de requisitos pode se utilizar de uma narrativa ou de 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 software. 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. Então, o que estamos esperando? Vamos ao trabalho. Boa leitura a todos. Introdução Re pr od uç ão p ro ib id a. A rt . 1 84 d o Có di go P en al e L ei 9 .6 10 d e 19 d e fe ve re iro d e 19 98 . 47 CASOS DE USO Reprodução proibida. A rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998. IIU N I D A D E48 FASES DA ANÁLISE E DO PROJETO Como vimos na unidade 1, a análise de sistemas é a atividade inicial do pro- cesso de desenvolvimento de software em que se determina e especifica o que um sistema deve fazer, bem como as circunstâncias sob as quais deve operar, envol- vendo, geralmente, um 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 ao hardware, software, pessoas, banco de dados e aos 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 traba- lho subsequente. Independente do método ou processo utilizado para a análise, projeto e imple- mentação, algumas etapas são comuns, são elas (SOMMERVILE, 2011): ■ Identificação da Necessidade. ■ Estudo de Viabilidade. ■ Análise. ■ Projeto (Ferramentas). ■ Implementação (Codificação). ■ Implantação. ■ Manutenção (Adaptativa, Corretiva e Evolutiva). A seguir, detalharei cada uma dessas etapas de suma importância para a produ- ção de um software de qualidade. Fases da Análise e do Projeto Re pr od uç ão p ro ib id a. A rt . 1 84 d o Có di go P en al e L ei 9 .6 10 d e 19 d e fe ve re iro d e 19 98 . 49 IDENTIFICAÇÃO DA NECESSIDADE Vamos comentar cada uma dessas etapas começando pela identificação da neces- sidade, que é o ponto de partida na evolução de um sistema. Nessa etapa, são definidas as metas globais do sistema, respondendo algumas perguntas-chave: ■ Quais informações serão produzidas? ■ Quais informações devem ser fornecidas? ■ Que funções e desempenho são exigidos? Ainda nessa 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 tempo necessário para conclusão? Caso o novo sistema seja um produto a ser desenvolvido para venda a muitos clientes, o analista ainda deve avaliar o seguinte: ■ Qual é o mercado em potencial para o produto? ■ Como esse 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 deter- minar 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, sistema operacional. E, também, se existe pessoal competente à disposição para desenvolver o sistema em questão (SOMMERVILE, 2011). 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 esta- duais/federais e nas cláusulas contratuais. CASOS DE USO Reprodução proibida. A rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998. IIU N I D A D E50 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 deter- minar 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 uma análise completa de um sistema, portanto, o analista deve considerar os seguintes objetivos (SOMMERVILE, 2011): ■ Entender os objetivos do sistema (o que o administrador/usuário espera do sistema). ■ Entender as exigências do sistema (o que processar e que saídas produzir). ■ Entender que os objetivos e 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. Fases da Análise e do Projeto Re pr od uç ão p ro ib id a. A rt . 1 84 d o Có di go P en al e L ei 9 .6 10 d e 19 d e fe ve re iro d e 19 98 . 51 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 estrutura 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 se elaborar modelos com diferentes níveis de abstração, é possível detectar problemas nos níveis anterio- res. 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 no qual se cria uma versão executável do software, utilizando as ferramentaspara desenvolvimento defini- das no projeto. A implementação pode iniciar após o término do projeto, ou pode acontecer de forma paralela ao projeto, 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 imple- mentado usando os recursos existentes: computadores, periféricos, sistema operacional, dentre outros, e, também, se existe pessoal competente à disposi- ção para desenvolver o sistema em questão. Todo o projeto é construído com base no estudo de viabilidade técnica, utilizando ferramentas suportadas pelo hardware e entendida pelos usuários, portanto, os riscos da implantação não funcionar são minimizados no projeto. CASOS DE USO Reprodução proibida. A rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998. IIU N I D A D E52 O fator de maior preocupação 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 determinada 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 por motivos que não foram possíveis observar no momento da análise, projeto ou mesmo na implementação. As manutenções podem ser adaptativas, que têm o objetivo, como o próprio nome diz, de adaptar algumas tarefas ou funções para o ambiente de implanta- ção. As manutenções também podem ser evolutivas, que têm como objetivo a inserção de novos módulos no sistema. Figura 53: Modelo Cascata Fonte: adaptada de Sommervile (2011). Modelos De Processo Re pr od uç ão p ro ib id a. A rt . 1 84 d o Có di go P en al e L ei 9 .6 10 d e 19 d e fe ve re iro d e 19 98 . 53 MODELOS DE PROCESSO A análise e o projeto de sistemas de software deve fornecer para os stakeholders (equipe envolvida), composto pelo cliente, analista, programador, entre outros, uma única compreensão do projeto. De acordo com Medeiros (2004), a UML não se trata de um método, mas sim de uma linguagem. Um método é composto por processo e um modelo de linguagem. Os processos são os passos que devem ser seguidos para se construir o projeto. O modelo de linguagem é a notação que o método usa para descrever o projeto. Um modelo de processo de software define a sequência em que as ati- vidades do processo serão realizadas. MODELO CASCATA Vamos tomar como exemplo o modelo de processo em cascata, ou queda d’água, como colocado por alguns autores. 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. CASOS DE USO Reprodução proibida. A rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998. IIU N I D A D E54 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 requisi- tos em sistemas de hardware ou de software são agrupados, estabelecendo uma arquitetura do sistema geral. A terceira fase é a Implementação e teste de unidades, durante esse 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 atenda a sua especificação. A quarta fase é a Integração e teste de sistemas; nesse estágio, as unidades de programa ou programas individuais são integrados e testados como um sis- tema completo, a fim de garantir que os requisitos de software foram atendidos. A quinta fase é a Operação e Manutenção, normalmente, essa é a fase mais longa do ciclo de vida. O sistema é instalado e colocado em operação. A manu- tençã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 requi- sitos são descobertos. Nesse 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 domí- nio do problema, é recomendável a utilização do modelo de desenvolvimento evolucionário. O modelo evolucionário tem como base a ideia de desenvolver uma imple- mentaçã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 tenha sido desenvolvido. Figura 32: Modelo Evolucionário Fonte: adaptada de Sommervile (2011). Modelos De Processo Re pr od uç ão p ro ib id a. A rt . 1 84 d o Có di go P en al e L ei 9 .6 10 d e 19 d e fe ve re iro d e 19 98 . 55 Em vez de ter as atividades de especificação, desenvolvimento e validação em separado, todo esse trabalho é realizado concorrentemente com um rápido feedback por meio dessas atividades. A figura 32 ilustra bem as fases do modelo evolucionário. 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 especi- ficação que pode ser desenvolvida gradualmente, na medida em que os usuários compreendem melhor o problema. Porém, como nem tudo são flores, problemas acontecem nesse modelo, vamos enumerar alguns: ■ 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 constante tende a corromper a estrutura do software. Incorporar modificações tor- na-se cada vez mais difícil e oneroso. Utilizando o modelo em cascata ou modelo 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 dia- gramas de entidade-relacionamento (DER), diagrama de fluxo de dados (DFD), CASOS DE USO Reprodução proibida. A rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998. IIU N I D A D E56 diagrama de contexto, dicionário de dados etc. Esses modelos fornecem uma compreensão única do projeto. Contudo, o foco da nossa disciplina é a orientação a objetos, portanto, nas fases de análise e projeto, construiremos Diagramas de Caso de Uso, Diagramas de Classes, Diagramas de Estado, Diagramas de Sequência etc. Esses modelos fornecerão uma compreensão única do projeto. LINGUAGEM DE MODELAGEM A Linguagem de modelagem é uma parte muito importante do método. Corresponde ao ponto principal da comunicação. Se uma pessoa quer conver- sar 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 representação gráfica vistos no modelo (retângulo, setas, o texto etc.) são a nota- ção, esta é 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 isso, é possível concluir que, independente do modelode 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 charge a seguir ilustra de forma lúdica o que ocorre em um projeto de soft- ware em que a equipe de desenvolvimento e o cliente não se entendem. Figura 33: Projeto de Software Modelos De Processo Re pr od uç ão p ro ib id a. A rt . 1 84 d o Có di go P en al e L ei 9 .6 10 d e 19 d e fe ve re iro d e 19 98 . 57 CASOS DE USO Reprodução proibida. A rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998. IIU N I D A D E58 REQUISITOS DE SOFTWARE Agora que já sabemos a importância da análise e do projeto na produção de um software, vamos conhecer 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 é enge- nharia de requisitos? Vamos por partes, então. O termo “ENGENHARIA” permite dizer que é utilizado 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 é a de elicitar, devemos obter o máximo de informa- ções para o conhecimento do objeto em questão, dentro do domínio do problema. 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. Fonte: o autor. Requisitos De Software Re pr od uç ão p ro ib id a. A rt . 1 84 d o Có di go P en al e L ei 9 .6 10 d e 19 d e fe ve re iro d e 19 98 . 59 DOMÍNIO E o que é domínio? Para entender melhor, vamos imaginar que você foi contra- tado para desenvolver um software em uma determinada Casa de Carnes. Do lado direito da Casa de Carnes, existe uma farmácia, do lado esquerdo, um mer- cado, atrás, uma lanchonete e, em frente, uma igreja. Nesse caso, o domínio do seu problema é a Casa de Carnes, os demais esta- belecimentos 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 para desenvolver um software para determinado departamento de uma empresa, dessa forma, determinar o domínio do problema 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 deve- mos centrar em funcionalidades, e sim na finalidade. REQUISITOS E o que são requisitos? Os requisitos são os objetivos e as restrições estabelecidas pelo usuário do sistema. É o usuário ou cliente o responsável por descrever as necessidades ou desejo para o software (SOMMERVILE, 2011). Em um primeiro momento, é interessante definir os requisitos sem se preo- cupar em detalhá-los. Isso 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 de requisitos, produzimos um documento estruturado contendo requisitos e restrições descritos detalhadamente. Vamos aos exemplos: Felipe Destacar Felipe Destacar Felipe Destacar Felipe Destacar Felipe Destacar CASOS DE USO Reprodução proibida. A rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998. IIU N I D A D E60 Especificação de requisitos: 1.1. O usuário deverá ser provido de recursos que permitam definir os tipos de arquivos 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 utiliza- dos na representação dos arquivos externos. Na definição de requisitos, pode se utilizar de uma narrativa ou de represen- tações gráficas. Normalmente, as informações coletadas são fornecidas pelo usuário. Por meio dessas definições, pode ser elaborado o documento prelimi- nar de requisitos. Requisitos 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 pro- vidas 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, usabili- dade, desempenho, segurança, confiabilidade, manutenibilidade, disponibilidade que o sistema deverá possuir. Por exemplo: ■ O sistema deverá apresentar interface gráfica (padrão windows). ■ Facilidade de uso. Felipe Destacar Requisitos De Software Re pr od uç ão p ro ib id a. A rt . 1 84 d o Có di go P en al e L ei 9 .6 10 d e 19 d e fe ve re iro d e 19 98 . 61 ■ Possibilitar ajuda no contexto. A partir das definições dos requisitos, produzimos o documento preliminar de requisitos, que deve conter todos os serviços (requisitos) requeridos pelo cliente explicitados de forma clara, sem contradições. Atingir esse objetivo é uma tarefa difícil pelas inúmeras dificuldades que são encontradas no domínio. 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 pode tornar o documento de requisi- tos um documento de adivinhações. Característica 2 - precisam ser possíveis: você precisa ser hábil para imple- mentar cada requisito declarado, observando os recursos e limitações do sistema e ambiente. Para evitar requisitos impossíveis, trabalhe com o pessoal técnico o documento de requisitos, checando o que é possível e o que 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 uma interface externa, ou, ainda, um padrão. Você pode pensar que “necessário” significa cada requi- sito que tem 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 auxi- liem 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 conjuntamente com o cliente a prioridade de cada requisito. Característica 5: não podem ser ambíguas: cada declaração deve ser expli- citada de maneira que permita somente uma interpretação. Linguagem natural é altamente propensa a ambiguidades. Elimine termos subjetivos, como ami- gável ao usuário, fácil, simples, rápido, eficiente, vários, aperfeiçoar, maximizar FelipeDestacar CASOS DE USO Reprodução proibida. A rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998. IIU N I D A D E62 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 testes 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 desprovidos de ambiguidades também não são verificáveis. Após o estágio de elicitação (extração), um documento contendo os requisi- tos 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 envolve uma série de atividades (SUMMERVILE, 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. Os casos de uso têm um papel importantíssimo na análise de requisitos, pois permitem criar um cenário do domínio. Talvez esse seja o único instrumento que acompanha o software do início até seu término. Casos de uso representam funcionalidades completas para o usuário e não funcionalidades internas do sistema. Outro ponto importante é que o dia- grama 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 usuários no processo de desenvolvimento. Diagrama de Casos de Uso Re pr od uç ão p ro ib id a. A rt . 1 84 d o Có di go P en al e L ei 9 .6 10 d e 19 d e fe ve re iro d e 19 98 . 63 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. Um ator pode ser um usuário ou outro sistema. O diagrama de casos de uso é apenas um panorama visual das funcionalida- des do sistema, é necessária uma descrição textual para detalhar os casos de uso. 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. 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. Diagramas de casos de uso são utilizados para representar, de forma pano- râ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 pre- ocupar nesse momento com a implementação). Figura 34: 0 Ator Fonte: o autor. CASOS DE USO Reprodução proibida. A rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998. IIU N I D A D E64 Vamos conhecer a notação para os diagramas de caso de uso preconizados pela UML. Os elementos básicos de um diagrama de casos de uso são: ■ Atores. ■ Casos de uso. ■ Relações entre atores e casos de uso. Atores Começaremos, então, pelo homem palito, que representa um ator no meu sistema, este ator pode ser uma pessoa, outro sistema ou uma entidade externa ao sistema. Como encontrar os atores para um sistema? Usando as seguintes dicas: ■ Examine o problema procurando por pessoas ou sistemas do entorno. ■ Faça as seguintes perguntas: • Quais as pessoas ou departamentos interessados em um determinado requi- sito funcional? • Quem irá suprir o sistema com informações e quem irá receber informa- ções do sistema? • Quais os recursos externos utilizados pelo sistema? • Uma pessoa desempenha diferentes papéis? • O sistema interage com outros sistemas já existentes? Essas dicas também não garantem que o ator foi bem escolhido da primeira vez, pois esse é um processo iterativo, a primeira tentativa dificilmente será a definitiva. Diagrama de Casos de Uso Re pr od uç ão p ro ib id a. A rt . 1 84 d o Có di go P en al e L ei 9 .6 10 d e 19 d e fe ve re iro d e 19 98 . 65 Casos de Uso A coleção de casos de uso representa todos os modos de execução do sis- tema do ponto de vista do usuário. Um caso de uso é uma sequência de ações que produz um resultado significativo para um ator. Em um caso de uso, são necessárias as seguintes 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, as duas denominações são utilizadas. Um caso de uso representa uma atividade que o ator realiza. “As empresas vivem os desafios constantes de produzir software de alta qualidade, de impacto no sucesso de seus negócios, com ótima relação cus- to benefício e, acima de tudo, em curto prazo. A engenharia de software estabelece a importância de considerar a estratégia da organização e a ge- ração de valor no planejamento e na implantação dos seus projetos”. O texto completo do artigo “Proposta de integração da engenharia de sof- tware nas estratégias empresariais”, de Adalberto Faria dos Reis e Ivanir da Costa, você encontra no link disponível em: <http://www.scielo.br/scielo. php?script=sci_arttext&pid=S0103-65132005000300013&lang=pt>. Aces- so em: 29 jul. 2015. Fonte: Reis e Costa (online). Figura 35: Caso de Uso Fonte: o autor. CASOS DE USO Reprodução proibida. A rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998. IIU N I D A D E66 O caso de uso necessita de uma descrição, porém não há descrição padrão defi- nida pela UML. Em geral, o diagrama é bastante informal e sua estruturação (relação entre casos) não deve ser levada ao extremo. É importante ressaltar que o diagrama de casos de uso é uma forma de visua- lizar 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 onde normalmente relacionamos os seguin- tes itens: ■ Nome. ■ Descrição. ■ Requisitos funcionais providos pelo caso de uso. ■ Restrições, tais como pré e pós-condições. ■ 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 de uso acima, o sistema pode se encontrar em um dos seguintes estados: seguro concedido ou seguro não concedido por repro- vaçã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. Figura 37: Inclusão
Compartilhar