Baixe o app para aproveitar ainda mais
Prévia do material em texto
2015 Análise OrientAdA A ObjetOs ii Profa. Simone Cristina Aléssio Copyright © UNIASSELVI 2015 Elaboração: Profa. Simone Cristina Aléssio Revisão, Diagramação e Produção: Centro Universitário Leonardo da Vinci – UNIASSELVI Ficha catalográfica elaborada na fonte pela Biblioteca Dante Alighieri UNIASSELVI – Indaial. 005.1 A372a Aléssio, Simone Cristina Análise orientada a objetos II/ Simone Cristina Aléssio. Indaial : UNIASSELVI, 2015. 156 p. : il. ISBN 978-85-7830-934-3 1. Programação Orientada a Objetos. I. Centro Universitário Leonardo Da Vinci. III ApresentAçãO Prezado(a) acadêmico(a)! Seja bem-vindo(a) ao mundo da Programação Orientada a Objetos. Neste universo você vai se deparar com termos como atributos, métodos, abstração, encapsulamento, classes, hierarquia das classes, processo unificado, entre outros, que compõem o material de estudo desta disciplina e, por consequência, o dia a dia de um analista, desenvolvedor, programador, ou seja, o profissional da programação. Este caderno pressupõe que você já possua alguma experiência anterior em programação, principalmente JAVA, afinal, muitos dos objetos, classes e diagramas apresentados neste material estão voltados a esta linguagem de programação. É essencial você fazer uso dos conhecimentos adquiridos em disciplinas anteriores para então conseguir acompanhar o desenvolvimento de um sistema e, assim, auxiliar você na construção do entendimento em programação orientada a objetos. Aproveito a oportunidade para destacar a importância de desenvolver as autoatividades, afinal, cada exercício deste caderno foi desenvolvido para a fixação de conceitos por meio da prática. Em caso de dúvida na realização das atividades, sugiro que você entre em contato com seu tutor externo ou com a tutoria da UNIASSELVI, não prosseguindo as atividades sem ter sanado todas as dúvidas que irão surgindo. Vale destacar a necessidade de dedicação e de muita determinação, afinal, a Programação Orientada a Objetos exige de você bem mais do que apenas este caderno para sua total compreensão. Aqui você recebe somente um início, ou seja, os conceitos de determinados pontos importantes na programação, porém, é somente na prática que você consegue compreender o mundo da programação como um todo. Lembre-se de que o mundo da informática é encantador, assim, seu entusiasmo por este universo depende somente de você, destacando neste momento a compreensão da lógica envolvida no processo de construção de programas. Por este motivo, destaco uma frase que considero importante no caso da programação, afinal: “Para se ter sucesso, é amar de verdade o que se faz. Caso contrário, levando em conta apenas o lado racional, você simplesmente desiste. É o que acontece com a maioria das pessoas” (Steven Jobs – criador da Apple). Bom estudo! Sucesso na sua trajetória acadêmica e profissional! Simone Cristina Aléssio IV Você já me conhece das outras disciplinas? Não? É calouro? Enfim, tanto para você que está chegando agora à UNIASSELVI quanto para você que já é veterano, há novidades em nosso material. Na Educação a Distância, o livro impresso, entregue a todos os acadêmicos desde 2005, é o material base da disciplina. A partir de 2017, nossos livros estão de visual novo, com um formato mais prático, que cabe na bolsa e facilita a leitura. O conteúdo continua na íntegra, mas a estrutura interna foi aperfeiçoada com nova diagramação no texto, aproveitando ao máximo o espaço da página, o que também contribui para diminuir a extração de árvores para produção de folhas de papel, por exemplo. Assim, a UNIASSELVI, preocupando-se com o impacto de nossas ações sobre o ambiente, apresenta também este livro no formato digital. Assim, você, acadêmico, tem a possibilidade de estudá-lo com versatilidade nas telas do celular, tablet ou computador. Eu mesmo, UNI, ganhei um novo layout, você me verá frequentemente e surgirei para apresentar dicas de vídeos e outras fontes de conhecimento que complementam o assunto em questão. Todos esses ajustes foram pensados a partir de relatos que recebemos nas pesquisas institucionais sobre os materiais impressos, para que você, nossa maior prioridade, possa continuar seus estudos com um material de qualidade. Aproveito o momento para convidá-lo para um bate-papo sobre o Exame Nacional de Desempenho de Estudantes – ENADE. Bons estudos! NOTA V VI VII UNIDADE 1 – REVISÃO DE CONCEITOS DE ORIENTAÇÃO A OBJETOS, REVISÃO DE CONCEITOS DA UML, DIAGRAMAS DE VISÃO COMPORTAMENTAL: CASOS DE USO, DIAGRAMA DE ATIVIDADES E DIAGRAMA DE MÁQUINA DE ESTADOS .......................................................................................... 1 TÓPICO 1 – REVISÃO DE CONCEITOS DE ORIENTAÇÃO A OBJETOS, REVISÃO DE CONCEITOS DA UML .................................................................................................... 3 1 INTRODUÇÃO ..................................................................................................................................... 3 2 ORIENTAÇÃO A OBJETOS ............................................................................................................... 5 2.1 ABSTRAÇÃO .................................................................................................................................... 5 2.2 CLASSE ............................................................................................................................................. 6 2.2.1. Método .................................................................................................................................... 7 2.2.2 Responsabilidades .................................................................................................................. 7 2.2.3 Tipos de relacionamento entre classes ................................................................................. 8 2.2.4 Mensagem ................................................................................................................................ 10 2.2.5 Objeto........................................................................................................................................ 10 3 PROJETO ORIENTADO A OBJETOS .............................................................................................. 10 4 AS VÁRIAS OPÇÕES DA UML ........................................................................................................ 11 4.1 CONCEITOS DA ESTRUTURA DA UML ................................................................................... 12 4.1.1 Itens ........................................................................................................................................... 12 4.1.2 Itens estruturais ....................................................................................................................... 12 4.1.3 Itens comportamentais ........................................................................................................... 15 4.1.4 Itens de agrupamento ............................................................................................................ 15 4.1.5 Item anotacional ...................................................................................................................... 16 4.2 DIAGRAMAS ................................................................................................................................... 16 RESUMO DO TÓPICO 1........................................................................................................................ 19 AUTOATIVIDADE .................................................................................................................................20 TÓPICO 2 – MODELO DE DESENVOLVIMENTO, DIAGRAMAS DA UML, DIAGRAMA DE CASOS DE USO ......................................................................................................... 21 1 INTRODUÇÃO ..................................................................................................................................... 21 2 UML ......................................................................................................................................................... 22 3 DIAGRAMAS DA UML ...................................................................................................................... 23 3.1 DIAGRAMAS ESTRUTURAIS .................................................................................................. 25 3.2 DIAGRAMAS COMPORTAMENTAIS .................................................................................... 25 4 DIAGRAMAS COMPORTAMENTAIS .......................................................................................... 26 4.1 DIAGRAMA DE CASOS DE USO ................................................................................................ 27 4.2 ELEMENTOS DO DIAGRAMA DE CASOS DE USO ................................................................ 27 4.3 ELEMENTO ATORES ..................................................................................................................... 28 4.4 ELEMENTO CASOS DE USO ........................................................................................................ 28 4.4.1 Descrição .................................................................................................................................. 29 5 FLUXO DE EVENTOS ......................................................................................................................... 29 5.1 FLUXO BÁSICO ............................................................................................................................... 30 sumáriO VIII 5.2 SUBFLUXO ....................................................................................................................................... 30 5.2.1 Pontos de extensão ................................................................................................................. 31 5.3 FLUXO ALTERNATIVO ................................................................................................................. 31 6 ELEMENTO RELAÇÕES ..................................................................................................................... 32 6.1 ASSOCIAÇÃO .................................................................................................................................. 32 6.2 ATOR X ATOR .................................................................................................................................. 32 6.3 ATOR X CASO .................................................................................................................................. 32 6.4 ELEMENTO DEPENDÊNCIA - INCLUSÃO E EXTENSÃO .................................................... 33 7 EXTENSÃO ............................................................................................................................................ 34 8 ELEMENTO GENERALIZAÇÃO/ESPECIALIZAÇÃO ................................................................ 34 9 DICAS IMPORTANTES ...................................................................................................................... 36 RESUMO DO TÓPICO 2........................................................................................................................ 39 AUTOATIVIDADE ................................................................................................................................. 40 TÓPICO 3 – DIAGRAMA DE ATIVIDADES E DIAGRAMA DE MÁQUINA DE ESTADOS .............................................................................................. 43 1 INTRODUÇÃO ..................................................................................................................................... 43 2 AÇÃO ...................................................................................................................................................... 45 3 ATIVIDADES ........................................................................................................................................ 45 4 EVENTOS ............................................................................................................................................... 45 5 NÓS DE CONTROLE .......................................................................................................................... 45 6 PONTOS DE EXTENSÃO ................................................................................................................... 45 7 OUTROS RECURSOS EM DIAGRAMAS DE ATIVIDADES .................................................... 47 8 RELAÇÃO COM OUTROS DIAGRAMAS ..................................................................................... 47 9 EXEMPLO DE CRIAÇÃO DE DIAGRAMA DE ATIVIDADES ................................................. 48 LEITURA COMPLEMENTAR ............................................................................................................... 53 RESUMO DO TÓPICO 3........................................................................................................................ 61 AUTOATIVIDADE ................................................................................................................................. 62 UNIDADE 2 – DIAGRAMAS COMPORTAMENTAIS (INTERAÇÃO) ...................................... 65 TÓPICO 1 – DIAGRAMAS DE INTERAÇÃO .................................................................................. 67 1 INTRODUÇÃO ..................................................................................................................................... 67 2 DIAGRAMA DE SEQUÊNCIA .......................................................................................................... 67 2.1 TIPOS DE MENSAGEM ................................................................................................................. 68 2.2 DIAGRAMA DE COMUNICAÇÃO ............................................................................................. 70 2.2.1 Principais componentes: objetos, mensagens e vínculo .................................................... 71 2.2.2 Notação: semelhante ao Diagrama de Sequência .............................................................. 72 2.2.3 Atores ........................................................................................................................................ 73 2.2.4 Condições ................................................................................................................................. 73 2.2.5 Autochamadas ........................................................................................................................ 74 2.2.6 Exemplo de Diagrama de Comunicação ............................................................................. 74 2.3 DIAGRAMA DE TEMPO ............................................................................................................... 75 2.4 DIAGRAMA DE VISÃO GERAL .................................................................................................. 76 RESUMO DO TÓPICO 1........................................................................................................................ 77 AUTOATIVIDADE ................................................................................................................................. 79 TÓPICO 2 – DIAGRAMAS ESTRUTURAIS: DE CLASSES E DE PACOTES 1 INTRODUÇÃO .....................................................................................................................................81 2 DIAGRAMA DE CLASSES ................................................................................................................ 81 2.1 CENÁRIO .......................................................................................................................................... 82 IX 2.2 IDENTIFICAR OS OBJETOS TANGÍVEIS ................................................................................... 84 2.3 AGRUPAR OS OBJETOS POR SEMELHANÇA ......................................................................... 85 2.4 DELIMITAR CLASSES REDUNDANTES OU QUE NÃO SÃO NECESSÁRIAS .................. 85 2.5 MONTANDO O DIAGRAMA DE CLASSE ................................................................................ 85 2.6 REALIZANDO AS PRIMEIRAS LIGAÇÕES ............................................................................... 86 3 DIAGRAMA DE CLASSE COMPLETO .......................................................................................... 88 3.1 DIAGRAMA DE PACOTES ........................................................................................................... 89 3.1.1 Definindo as classes de um Pacote ....................................................................................... 90 3.1.2 Principais componentes: pacotes .......................................................................................... 91 RESUMO DO TÓPICO 2........................................................................................................................ 93 AUTOATIVIDADE ................................................................................................................................. 95 TÓPICO 3 – DIAGRAMAS ESTRUTURAIS: DE OBJETOS E DE COMPONENTES .............. 97 1 INTRODUÇÃO ..................................................................................................................................... 97 2 PRINCIPAIS COMPONENTES: OBJETOS, RELACIONAMENTOS .................................... 97 3 DIAGRAMA DE COMPONENTES .................................................................................................. 99 3.1 PRINCIPAIS COMPONENTES: COMPONENTES, INTERFACES, CLASSES E RELACIONAMENTOS .................................................................................................................. 99 3.1.1 Componente ..........................................................................................................................100 3.1.2 Objetivos ................................................................................................................................100 3.1.3 Diagrama de Componentes .................................................................................................101 LEITURA COMPLEMENTAR .............................................................................................................103 RESUMO DO TÓPICO 3......................................................................................................................107 AUTOATIVIDADE ...............................................................................................................................108 UNIDADE 3 – DIAGRAMAS ESTRUTURAIS ...............................................................................109 TÓPICO 1 – DIAGRAMA DE IMPLANTAÇÃO E ESTRUTURA COMPOSTA ......................111 1 INTRODUÇÃO ...................................................................................................................................111 2 PRINCIPAIS COMPONENTES .......................................................................................................112 3 DIAGRAMA DE ESTRUTURA COMPOSTA ..............................................................................113 RESUMO DO TÓPICO 1......................................................................................................................117 AUTOATIVIDADE ...............................................................................................................................118 TÓPICO 2 – INTEGRAÇÃO DOS DIAGRAMAS – UMA VISÃO GERAL DO DESENVOLVIMENTO USANDO UML ..........................................................................................119 1 INTRODUÇÃO ...................................................................................................................................119 2 EXEMPLO DE DESENVOLVIMENTO DE PROJETOS USANDO UML ...............................119 RESUMO DO TÓPICO 2......................................................................................................................123 AUTOATIVIDADE ...............................................................................................................................124 TÓPICO 3 – ESTUDO DE CASO .......................................................................................................125 1 INTRODUÇÃO ...................................................................................................................................125 2 NECESSIDADE DE COMPREENDER OS PROCESSOS DA ORGANIZAÇÃO .................126 2.1 O MAPEAMENTO DE PROCESSOS .........................................................................................127 2.1.1 Fluxograma ...........................................................................................................................128 2.1.2 SADT (Structured Analysis and Design Technic) .................................................................129 2.1.3 IDEF3 .....................................................................................................................................129 2.1.4 UML (Unified Modeling Language) .......................................................................................130 2.1.5 Diagrama de Atividades ......................................................................................................130 2.1.6 Aplicação do Diagrama de Atividades da UML ..............................................................131 X 2.1.7 Avaliação da Aplicação do Diagrama de Atividades.......................................................136 2.1.8 Conclusões ............................................................................................................................137 LEITURA COMPLEMENTAR .............................................................................................................138 RESUMO DO TÓPICO 3......................................................................................................................150 AUTOATIVIDADE ...............................................................................................................................151 REFERÊNCIAS .......................................................................................................................................153 1 UNIDADE 1 REVISÃO DE CONCEITOS DE ORIENTAÇÃO A OBJETOS, REVISÃO DE CONCEITOS DA UML, DIAGRAMAS DE VISÃO COMPORTAMENTAL: CASOS DE USO, DIAGRAMA DE ATIVIDADES E DIAGRAMA DE MÁQUINA DE ESTADOS OBJETIVOS DE APRENDIZAGEM PLANO DE ESTUDOS A partir desta unidade, você será capaz de: • revisar conceitos de Orientação a Objetos; • revisar conceitos de UML; • conhecer a visão comportamental dos diagramas da UML; • elaborar diagramas de casos de uso, de atividades e máquina de estados. Esta unidade de ensino contém três tópicos. Ao final de cada um deles você encontrará atividades que contribuirão para a apropriação dos conteúdos. TÓPICO 1 – REVISÃO DE CONCEITOS DE ORIENTAÇÃO A OBJETOS, REVISÃO DE CONCEITOS DA UML TÓPICO 2 – MODELO DE DESENVOLVIMENTO, DIAGRAMAS DA UML, DIAGRAMA DE CASOS DE USO TÓPICO 3 – DIAGRAMA DE ATIVIDADES E DIAGRAMA DE MÁQUINA DE ESTADOS 2 3 TÓPICO 1 UNIDADE 1 REVISÃO DE CONCEITOS DE ORIENTAÇÃO A OBJETOS, REVISÃO DE CONCEITOS DA UML 1 INTRODUÇÃO Este tópico reapresenta conceitosque são o alicerce da disciplina, bem como os seus principais autores, conforme mostra a Figura 1. FIGURA 1 – ORIGEM E EVOLUÇÃO DA UML Origem e evolução da UML 1962-1963 1962 - Krysten Nygaard e Ole-Johan Dahl, pesquisadores do Centro de Computação da Noruega, em Oslo, criam a linguagem Simula, derivada do Algol, introduzindo os primeiros conceitos de orientação a objetos. 1963 - Ivan Sutherland desenvolve, no MIT (Massachusets Institute of Tecnology), nos Estados Unidos, o Sketchpad, primeiro editor gráfico para desenhos orientado a objetos. O Sketchpad usava conceitos de instância e herança. Ivan Suthorland Krysten Nygaard 1969 1970 - 1983 Alan Curtis Kay Alan Curtis Kay apresenta sua tese de doutorado intitulada The Reactive Engine na Universidade de Utah, na qual propõe uma linguagem (Flex), que contém conceitos de orientação a objetos. É lançada linguagem de programação Smaltalk, desenvolvida no centro de pesquisas da Xerox em Palo Alto, Estados Unidos. Essa foi por muito tempo a única linguagem 100% orientada a objetos. 1980 - Surge a linguagem de programação C++, que também pode ser orientada a objetos. 1983 - Jean Ichbiah cria a linguagem ADA a pedido do Departamento de Defesa dos Estados Unidos, também orientada a objetos. UNIDADE 1 | REVISÃO DE CONCEITOS DE ORIENTAÇÃO A OBJETOS, REVISÃO DE CONCEITOS DA UML, DIAGRAMAS DE VISÃO COMPORTAMENTAL: CASOS DE USO, DIAGRAMA DE ATIVIDADES E DIAGRAMA DE MÁQUINA DE ESTADOS 4 1985 - 1989 Bertrand Meyer Bertrand Meyer lança a linguagem Eifel, orientada a objetos. 1988 - Sally Shlaer e Stepen Mellor publicam o livro Object-Oriented Systems Analysis: Modeling the World in Data, que propõe uma técnica para análise e projetos orientados a objeto. 1989 - É criado o OMG (Object Management Group), que aprova padrões para aplicações orientadas a objeto. Peter Coad e Ed Yourdon lançam o livro Object - Oriented Analysis, também contendo técnicas para análise e projetos orientados a objeto. Rebecca Wirfs - Brock, Brian Wilkerson e Lauren Wiener publicam o livro Designing Object - Oriented Software, tratando de técnicas de modelagem orientada a objetos. 1992 - Ivar Jacobson, Magnus Christerson, Patrik Jonsson e Gunnar Overgaard lançam o livro Object - Oriented Software Enginnering: A Use Case Driven 1990 - 1993 1970 - 1983 Approach, também sobre técnicas de orientação a objetos. D. Embley, B. Kurtz, e S. Woodfield publicam o livro Object - Oriented System Analysis. A Madel-Driven Approach. 1993 - Grady Booch lança seu Booch Method com técnicas para análise e projeto orientado a objetos. É lançada linguagem de programação Smaltalk, desenvolvida no centro de pesquisas da Xerox em Palo Alto, Estados Unidos. Essa foi por muito tempo a única linguagem 100% orientada a objetos. 1980 - Surge a linguagem de programação C++, que também pode ser orientada a objetos. 1983 - Jean Ichbiah cria a linguagem ADA a pedido do Departamento de Defesa dos Estados Unidos, também orientada a objetos. James Martin James Gosling FONTE: Piva (2010) Este tópico foi criado com o objetivo de revisar conceitos da disciplina de Análise Orientada a Objetos I, reapresentando os conceitos da UML, que possibilita visualização, especificação, construção e documentação de requisitos no desenvolvimento de software com orientação a objetos. Será exibido um pequeno histórico da UML e principais conceitos da metodologia orientada a objetos e sua representação na UML. Três grandes nomes criaram a UML. Dois deles são norte-americanos: Grady Booch e James Rumbaugh, o terceiro é o suíço Ivar Jacobson. Juntos, em 1995 lançaram a UML 0. Unificando os seus três métodos de estudos desenvolvidos individualmente: Método de Booch: desenvolvido por Grady Booch, da Rational Software Corporation, expressivo principalmente nas fases de projeto e construção de sistemas. OOSE (Object-Oriented Software Engineering), de Ivar Jacobson, que fornecia excelente suporte para casos de usos como forma de controlar a captura de requisitos, a análise e o projeto de alto nível. TÓPICO 1 | REVISÃO DE CONCEITOS DE ORIENTAÇÃO A OBJETOS, REVISÃO DE CONCEITOS DA UML 5 OMT (Object Modeling Technique), de James Rumbaugh, que é um método de modelagem e projeto orientado a objetos publicado em 1991 por James Rumbaugh, Michael Blaha, Willian Premerlani, Frederick Eddy e Willian Lorensen, no livro Object-Oriented Modeling and Design. FONTE: Disponível em: <http://issuu.com/geeadcps/docs/livro3_alta/81>. Acesso em: 5 out. 2015. Kay foi considerado o pai da orientação a objetos. Foi ele quem definiu o computador como um organismo vivo, promovendo a independência das células, que, mesmo independentes, deveriam se relacionar ou juntar-se a outras, a fim de atingir um objetivo específico. À época do surgimento da linguagem Smalltalk, Kay era pesquisador da Xerox, e, em 1970, foi o primeiro a usar o termo “Orientação a Objetos”. A UML oferece suporte em todas as etapas do desenvolvimento de software. Por este motivo, atualmente é considerada um padrão de desenvolvimento quando se utiliza da orientação a objetos. 2 ORIENTAÇÃO A OBJETOS O objetivo da orientação a objetos é o de aproximar o desenvolvimento de software da realidade dos acontecimentos, do fluxo real da informação. Para isso, cria elementos e dados que tenham funcionalidades em si mesmos. O conceito continua evoluindo, pois ainda existem limitações de hardware que se relacionam a problemas de acesso e armazenamento de dados, e de software relativas a processos do sistema operacional e a falta de sistemas gerenciadores de banco de dados orientados a objetos (PIVA, 2010). 2.1 ABSTRAÇÃO Abstração é uma característica específica da entidade, fazendo com que a mesma se torne distinta de todas as outras entidades envolvidas em um modelo de dados. A abstração foca o escopo da entidade. Por exemplo, ao pensarmos na entidade PRODUTO, não precisamos pensar em todos os atributos desta entidade. Posso focar a atenção apenas nos atributos principais e essenciais, os quais serão a característica desta entidade e que a tornarão exclusiva dentro de um modelo, na análise e desenvolvimento do sistema. UNIDADE 1 | REVISÃO DE CONCEITOS DE ORIENTAÇÃO A OBJETOS, REVISÃO DE CONCEITOS DA UML, DIAGRAMAS DE VISÃO COMPORTAMENTAL: CASOS DE USO, DIAGRAMA DE ATIVIDADES E DIAGRAMA DE MÁQUINA DE ESTADOS 6 2.2 CLASSE Para os autores Booch, Rumbaugh e Jacobson (2005), a classe descreve vários objetos, que juntos compartilham os mesmos atributos, operações, relacionamentos e semântica. A representação completa de uma classe tem quatro divisões, conforme podemos visualizar na Figura 2. FIGURA 2 – REPRESENTAÇÃO DE UMA CLASSE Carro - nomeFabricante: String - nomeModelo: String - cor: String - numeroPortas: Int - anoFabricação: Int - velocidadeMaxima: double + abrirPortas( ): vold + fecharPortas( ): vold + ligar( ): vold + desligar( ): vold + acelerar( ): vold + frear( ): vold + trocarMarcha( ): vold Responsabilidades - Se locomover na velocidade e direção indicados pelo usuário. - Acelerar quando solicitado. - Frear quando solicitado. Nome da classe Responsabilidades Métodos Atributos Defi nição da classe segundo UML 2. FONTE: Piva (2010) FIGURA 3 – OUTRA FORMA DE REPRESENTAÇÃO DE CLASSE Carro - nomeFabricante: String - nomeModelo: String - cor: String - numeroPortas: Int - anoFabricação: Int - velocidadeMaxima: double + abrirPortas( ): vold + fecharPortas( ): vold + ligar( ): vold + desligar( ): vold + acelerar( ): vold + frear( ): vold + trocarMarcha( ): vold Carro Outra forma de representar uma classe em UML 2.0. FONTE: Piva (2010) Nome da classe: Cada classe deve ter um nome único, que sejacapaz de diferenciar a mesma de outras classes (BOOCH; RUMBAUGH; JACOBSON, 2005). TÓPICO 1 | REVISÃO DE CONCEITOS DE ORIENTAÇÃO A OBJETOS, REVISÃO DE CONCEITOS DA UML 7 Atributo: Pode ser entendido como um campo, uma propriedade que mantém valores cujas instâncias desse atributo podem apresentar (BOOCH; RUMBAUGH; JACOBSON, 2005). 2.2.1. Método Para modificar o seu comportamento, um objeto da classe pode solicitar um serviço. É algo que muda o objeto e que pode afetar todos os objetos da classe (BOOCH; RUMBAUGH; JACOBSON, 2005). Relembre alguns dos principais métodos, conforme descrição abaixo: Os métodos especiais • Construtor: é o método que constrói, isto é, reserva o espaço em memória onde serão armazenadas as informações daquele objeto da classe. • Get: é o método que apresenta o valor armazenado em determinado atributo de um objeto. • Set: dá um valor a um atributo. Os métodos Get e Set encapsulam os atributos de uma classe, garantindo que as alterações nos atributos sejam feitas única e exclusivamente por eles. Os atributos permanecem com visibilidade privada. Lembrando: Get (para retornar o valor que está no atributo). Set (para atribuir um valor a ele). Normalmente, no processo de desenvolvimento são adotados um método Set e um método Get para cada atributo da classe. • Destrutor: destrói o objeto criado da memória, liberando o espaço de memória alocado na sua criação. • Assinatura: é a primeira linha da definição de um método, no qual podemos observar sua visibilidade, seu nome, seus parâmetros de entrada e de retorno. 2.2.2 Responsabilidades As responsabilidades remetem às obrigações das classes, que, quando criadas, estabelecem que todos os seus objetos terão o mesmo estado e tipo de comportamento. Por isso é possível representar uma classe apenas com seu nome ou com nome dos principais atributos e principais métodos, de acordo com o que se quer analisar ao iniciar a criação dos diagramas. UNIDADE 1 | REVISÃO DE CONCEITOS DE ORIENTAÇÃO A OBJETOS, REVISÃO DE CONCEITOS DA UML, DIAGRAMAS DE VISÃO COMPORTAMENTAL: CASOS DE USO, DIAGRAMA DE ATIVIDADES E DIAGRAMA DE MÁQUINA DE ESTADOS 8 2.2.3 Tipos de relacionamento entre classes Dependência, associação e herança estabelecem os principais relacionamentos entre as classes. 1) Dependência: determina que um objeto de uma classe possa usar as informações e serviços de outra classe, que um objeto de uma classe use informações e serviços de um objeto de outra classe. A dependência é representada grafi camente por uma linha tracejada com uma seta indicando o sentido da dependência. Verifi que a representação na fi gura a seguir. A classe Janela é dependente da classe Evento. FIGURA 4 – DEPENDÊNCIA DA UML Janela - largura: double - altura: double + abrir ( ): void + fechar ( ): void + tratarEvento ( ): void Evento - nome: String + start ( ): void Representação de uma dependência em UML 2.0. Exemplo de associação entre classes UML. Funcionário - salario: double - nroCarteiraProfi ssional: String Empresa - nome: String - ramoAtividade: String - cnpj: String Trabalha para ► 1..* * empregadortrabalhador FONTE: Piva (2010) 2) Associação: é um relacionamento de estrutura, que aponta os objetos de uma classe que estão conectados a objetos de outra classe estrutural que especifi ca objetos de uma classe conectados a objetos de outra classe. A associação é representada por uma linha interligando as duas classes. FIGURA 5 – ASSOCIAÇÃO ENTRE CLASSES FONTE: Piva (2010) A fi gura a seguir apresenta um exemplo de agregação, que é um tipo de associação entre classes na qual é mostrada a relação todo-parte entre as classes. Uma classe é a parte, e a outra, o todo. TÓPICO 1 | REVISÃO DE CONCEITOS DE ORIENTAÇÃO A OBJETOS, REVISÃO DE CONCEITOS DA UML 9 FIGURA 6 – ASSOCIAÇÃO ENTRE CLASSES Empresa - nome: String - ramoAtividade: String - cnpj: String Representação da agregação entre classes UML 2.0. Representação de uma composição UML 2.0. 1 * 1 * Departamento - nome: String ItemdePedido -- descrição: String - quantidade: Int - precoUnitario: double Pedido - numero: Int - data: Date - valor Total: double FONTE: Piva (2010) Observe, na fi gura anterior, que uma empresa é formada por vários departamentos. Pode-se ver ainda que cada departamento está associado a uma empresa. Não podemos esquecer-nos da composição, que nada mais é do que uma forma de agregação, tempo de vida semelhante entre as partes pelo todo. Pode-se afi rmar que numa relação de composição só faz sentido existir a parte se houver o todo (PIVA, 2010). 3) Herança: na herança, classes mais específi cas assumem a estrutura e o comportamento de classes mais gerais. A representação da Herança pode ser entendida pela representação da Figura 7, onde a classe Pessoa possui os atributos nome e cpf e pode executar os métodos de andar e falar. Já a classe Funcionario herda os atributos e métodos da classe Pessoa, possui nome, cpf, salário e nroCarteiraProfi ssional, podendo executar os métodos andar, falar e trabalhar. Logo, conclui-se que é a classe pai de Funcionario e que Funcionario é classe fi lha de Pessoa. UNIDADE 1 | REVISÃO DE CONCEITOS DE ORIENTAÇÃO A OBJETOS, REVISÃO DE CONCEITOS DA UML, DIAGRAMAS DE VISÃO COMPORTAMENTAL: CASOS DE USO, DIAGRAMA DE ATIVIDADES E DIAGRAMA DE MÁQUINA DE ESTADOS 10 FIGURA 7 – REPRESENTAÇÃO DE HERANÇA Pessoa # nome: String # cpf: String + andar ( ): void + falar ( ): void Representação de herança utilizando UML. Generalização Especialização Funcionario - salario: double - nroCarteiraProfi ssional: String + trabalhar ( ): void FONTE: Piva (2010) 2.2.4 Mensagem As mensagens confi guram uma forma de comunicação entre os objetos. Elas carregam informações de uma determinada atividade que está por ser executada. Os seja, objetos trocam informações para tornar possível o funcionamento dos sistemas. 2.2.5 Objeto É pelo objeto que se concretiza a abstração, através de entidades bem defi nidas, entidades que encapsulam estados e comportamentos; é a instância de uma classe. Utilizando como exemplo um automóvel, podemos pensar nos atributos como sendo: o modelo, cor, ano de fabricação, combustível, e seus métodos como: andar, acelerar, frear, entre outros. Ao pensar nas responsabilidades do automóvel, podemos dizer que ele deve obedecer aos comandos que lhe são impostos, como aceleração, velocidade, trajeto etc. (PIVA, 2010). 3 PROJETO ORIENTADO A OBJETOS Num projeto é necessário defi nir com precisão quais são as principais classes que irão compor a solução para a construção de determinado software. Em seguida, deve-se estabelecer como os objetos criados a partir dessas classes vão interagir entre si para atingir a solução proposta em termos de desenvolvimento de aplicação. TÓPICO 1 | REVISÃO DE CONCEITOS DE ORIENTAÇÃO A OBJETOS, REVISÃO DE CONCEITOS DA UML 11 Deve-se projetar todo o funcionamento do sistema em detalhes. Um recurso satisfatório é proposto pela UML, através do uso dos seus diagramas, que permitem definir como funcionará cada um dos itens da solução, até, por exemplo, em que estrutura de hardware e software será implementada e como estarão dispostos componentes da rede envolvida na solução. É comum, no decorrer do planejamento e desenvolvimento do projeto, o surgimento de novas classes. Estas, geralmente, são responsáveis pela interação do usuário com o sistema em si (PIVA, 2010). Além disso, são definidos e protocolados todos os requisitos necessários para a segurança das informações que serão mantidas pelo sistema. Tudo isso é possível de ser realizado mantendo- se o uso e aplicação da UML, cujas ferramentas permitem o detalhamento de cadaum dos componentes da solução de software. Na fase da análise do sistema (orientada a objetos) devemos concentrar nossos esforços a fim de mapear o funcionamento e comportamento das classes para que o sistema funcione da forma como foi projetado em termos de estrutura de rede, software e hardware (PIVA, 2010). 4 AS VÁRIAS OPÇÕES DA UML Segundo Piva (2010), devemos estar atentos ao que é estático e dinâmico ao utilizarmos a UML. Como estático podemos entender: • definição das classes; • modularização; • as camadas e a configuração do hardware. Como processo dinâmico podemos classificar as mudanças de estado que os itens podem sofrer no decorrer da execução do software, por exemplo, pelas alterações ocasionadas pelas trocas de mensagens entre os itens nesse momento. Ainda de acordo com o Piva (2010) podemos perceber cinco diferentes visões proporcionadas pela UML durante a construção de modelos de software. São elas: • Visão de casos de uso: permite melhor compreensão do problema a ser resolvido, ajudando na definição das fronteiras do sistema, seus principais usuários e as principais funcionalidades a serem implementadas. • Visão de projeto: auxilia na análise da estrutura e das funcionalidades esperadas da solução. • Visão de processo: também chamada de visão de interação, foca o fluxo de controle entre os diversos componentes da solução, permitindo também a análise de seu desempenho, a sincronização e a concorrência entre seus componentes, necessária para o perfeito funcionamento da solução. UNIDADE 1 | REVISÃO DE CONCEITOS DE ORIENTAÇÃO A OBJETOS, REVISÃO DE CONCEITOS DA UML, DIAGRAMAS DE VISÃO COMPORTAMENTAL: CASOS DE USO, DIAGRAMA DE ATIVIDADES E DIAGRAMA DE MÁQUINA DE ESTADOS 12 • Visão de implementação: ajuda a definir a estrutura da solução, isto é, os arquivos de instalação, seu controle de versões. • Visão de implantação: trata da estrutura de hardware e software, ou seja, do ambiente em que a solução será implementada. 4.1 CONCEITOS DA ESTRUTURA DA UML A formação da UML tem seu alicerce em três componentes básicos: • blocos de construção; • regras que restringem como os blocos de construção podem ser associados entre si; • mecanismos de uso geral, que dão mais clareza às definições criadas pelos blocos de construção. Estes, por sua vez, são de três tipos: itens, relacionamentos e diagramas (PIVA, 2010). 4.1.1 Itens São as abstrações em si e a base da UML. Os itens mantêm relacionamentos, que são mantidos pelos diagramas. Existem diferentes tipos de itens, que podem ser classificados em quatro grupos: estruturais, comportamentais, de agrupamento e anotacionais, que serão estudados no decorrer deste caderno. 4.1.2 Itens estruturais São responsáveis por definir a estrutura da solução. São formados por: • classes; • as interfaces; • as colaborações; • os casos de uso; • os componentes; • os artefatos; • os nós. Para prosseguirmos, torna-se necessário o entendimento acerca dos elementos mencionados acima, conforme esclarecimento proposto por Piva (2010, p. 173): Classes: são os elementos básicos da orientação a objetos e, consequentemente, da UML. TÓPICO 1 | REVISÃO DE CONCEITOS DE ORIENTAÇÃO A OBJETOS, REVISÃO DE CONCEITOS DA UML 13 Interfaces: são as funcionalidades a serem implementadas por uma classe ou por um componente. Demonstram o comportamento visível de uma classe, mas nunca a implementação de tal comportamento, pois contêm apenas a assinatura dos métodos, e sua implementação é feita pelas classes que herdam seu comportamento. Servem para defi nir comportamentos padronizados para conjuntos de classes e itens. As interfaces são representadas por um círculo. Colaboração: são agrupamentos de classes, relacionamentos e interfaces que constituem uma unidade do sistema. Dizemos que essa unidade é maior que a soma das classes e relacionamentos implementados. São representados por uma elipse tracejada com o nome da colaboração ao centro. A colaboração serve também para nos dar uma visão em nível mais alto de abstração, quando não é necessário entrar em todos os detalhes de determinado item em análise. FIGURA 8 – COLABORAÇÃO Controle de Estoque Solicitar Preço FONTE: Piva (2010) Casos de uso: descrevem uma sequência de ações a serem executadas pelos componentes da solução. São ativados por um ator, servem de base para defi nirmos comportamentos dos elementos da solução de software e são realizados por uma colaboração. São representados por uma elipse com o nome da operação que implementa no centro (PIVA, 2010, p. 174). FIGURA 9 – REPRESENTAÇÃO DE CASOS DE USO FONTE: Piva (2010) Componentes: são estruturas que instituem uma funcionalidade de uma solução de software por meio da implementação de uma ou mais interfaces defi nidas. Podem ser substituídos dentro de uma solução por outro componente que implemente todas as suas interfaces, sem prejuízo ao sistema como um todo (PIVA, 2010, p. 174). UNIDADE 1 | REVISÃO DE CONCEITOS DE ORIENTAÇÃO A OBJETOS, REVISÃO DE CONCEITOS DA UML, DIAGRAMAS DE VISÃO COMPORTAMENTAL: CASOS DE USO, DIAGRAMA DE ATIVIDADES E DIAGRAMA DE MÁQUINA DE ESTADOS 14 FIGURA 10 – REPRESENTAÇÃO DE COMPONENTES FormCliente <<artefato>> Cliente.class imprimir Nota Fiscal FONTE: Piva (2010) Artefato: é um elemento físico do sistema, que pode ser um programa (fonte ou executável), um script do sistema operacional e tudo o mais que pode ser transformado em bits e bytes. É representado por um retângulo com o estereótipo <<artefato>> e o seu nome (PIVA, 2010, p. 174). FIGURA 11 – REPRESENTAÇÃO DE ARTEFATO FONTE: Piva (2010) Nó: representa um recurso de computação. Pode ser um servidor, um computador cliente, um switch, um hub etc. Qualquer elemento computacional que faça parte da arquitetura na qual será implementada a solução pode ser defi nido como um nó. Em UML é desenhado como um cubo com seu nome dentro (PIVA, 2010, p. 174). FIGURA 12 – REPRESENTAÇÃO DE NÓ Servidor FONTE: Piva (2010) Atividade: “é um comportamento que especifi ca a sequência de etapas realizadas por um processo computacional. É representada em UML por um retângulo de vértices arredondados” (PIVA, 2010, p. 174). FIGURA 13 – REPRESENTAÇÃO DE HERANÇA FONTE: Piva (2010) TÓPICO 1 | REVISÃO DE CONCEITOS DE ORIENTAÇÃO A OBJETOS, REVISÃO DE CONCEITOS DA UML 15 EmEspera 4.1.3 Itens comportamentais São os itens que defi nem as partes dinâmicas dos modelos UML. São também chamados de verbos do modelo. Constituem itens: interações, máquina de estados e atividades. Interações: são os conjuntos de troca de mensagens entre objetos, também chamados de comportamento. Em UML as mensagens são representadas por uma seta traçada sob seu nome. Máquina de estados: “especifi ca os diversos estados pelos quais pode passar um objeto ou uma interação em seu ciclo de vida. Sua defi nição inclui outros componentes, como estados, transições, eventos e atividades. Em UML é representada por um retângulo com os vértices arredondados” (PIVA, 2010, p. 174). FIGURA 14 – REPRESENTAÇÃO DE MÁQUINA DE ESTADOS FONTE: Piva (2010) 4.1.4 Itens de agrupamento Servem para agrupar os demais itens da UML em bloco, permitindo uma melhor organização do projeto. É composto apenas pelo item pacote (PIVA, 2010). Pacote: “permite a inclusão de itens em seu interior para organizar o projeto, tornando-o modular e mais organizado. É conceitual, não existindo em tempo de execução. É representado por uma pasta, que pode receber apenas seu nome ou a visualização dos itens que a compõem” (PIVA, 2010, p. 175). FIGURA 15 – REPRESENTAÇÃO DE PACOTE Controle FONTE: Piva (2010) UNIDADE 1 | REVISÃO DE CONCEITOS DE ORIENTAÇÃO A OBJETOS, REVISÃO DE CONCEITOS DA UML, DIAGRAMAS DE VISÃO COMPORTAMENTAL:CASOS DE USO, DIAGRAMA DE ATIVIDADES E DIAGRAMA DE MÁQUINA DE ESTADOS 16 4.1.5 Item anotacional É o componente que permite a inserção de comentários nos modelos, tornando-os mais claros e inteligíveis. É composto apenas pelo item nota. Nota: tem como objetivo inserir comentários em um modelo para deixá- lo mais compreensível. É representado por um retângulo com a ponta superior direita dobrada para dentro. Em seu interior são inseridos os comentários pertinentes ao que se quer explicar melhor dentro do modelo. Também pode ser utilizada uma linha tracejada para apontar exatamente a que ponto do modelo se destina a explicação da nota (PIVA, 2010, p. 175). FIGURA 16 – REPRESENTAÇÃO DE NOTA Esta classe faz a conexão entre o software aplicativo e o sistema operacional. FONTE: Piva (2010) 4.2 DIAGRAMAS A versão 2.0 da UML traz consigo 13 diagramas, divididos em quatro grupos: • diagramas estruturais; • diagramas comportamentais; • diagramas de interação; • diagramas de implementação. A fi gura a seguir permite uma melhor visualização dos diagramas e os grupos aos quais cada um pertence. TÓPICO 1 | REVISÃO DE CONCEITOS DE ORIENTAÇÃO A OBJETOS, REVISÃO DE CONCEITOS DA UML 17 FIGURA 17 – DIAGRAMAS DA UML Diagramas da UML Diagramas Estruturais Diagramas Comportamentais Diagrama de Objetos Diagrama de Estrutura Composta Diagrama de implementação Diagrama de Componentes Diagrama de Implantação Diagrama de Sequência Diagrama de Temporação Diagrama de Colaboração Diagrama de Visão Geral da Interação Diagrama de Interação Diagrama de Atividades Diagrama de Classes Diagrama de Pacotes Diagrama de Casos de Uso Diagrama de Transições de Estados Diagrama de Objetos Diagrama de Diagrama de Classes Diagrama de Pacotes Comportamentais Diagrama de implementaçãoimplementação FONTE: Piva (2010) Adiante estudaremos em detalhes cada um dos diagramas apresentados. Para facilitar nosso entendimento acerca da elaboração de cada diagrama, precisamos estar atentos às cinco regras propostas pela UML para uma adequada construção dos mesmos. São elas: • Nome: sempre devemos lembrar que o nome de um item deve deixar clara sua formação, suas ações e responsabilidades. Não devemos nos esquecer também de que esse nome é único dentro de um modelo. • Escopo: todo item inserido em um modelo deve mostrar claramente quais são seus limites, o que implementa e quando pode ser utilizado. • Visibilidade: indica que é necessário também que fi que claro quando um item estará disponível para ser utilizado e que ações estarão disponíveis por seu intermédio. • Integridade: também é importante levar em conta na criação de um item a defi nição clara de como este se relaciona e a consistência de tal relacionamento. • Execução: deve estar evidente ainda o que o modelo representa e/ou simula. O que queremos observar com a criação desse modelo. FONTE: Disponível em: <http://issuu.com/geeadcps/docs/livro3_alta/81>. Acesso em: 7 out. 2015. UNIDADE 1 | REVISÃO DE CONCEITOS DE ORIENTAÇÃO A OBJETOS, REVISÃO DE CONCEITOS DA UML, DIAGRAMAS DE VISÃO COMPORTAMENTAL: CASOS DE USO, DIAGRAMA DE ATIVIDADES E DIAGRAMA DE MÁQUINA DE ESTADOS 18 As regras definem que ao inserir um item em um diagrama, você tem de se preocupar com as características apresentadas acima, para que consiga criar modelos bem elaborados e consistentes. 19 Neste tópico você aprendeu que: • A UML oferece diversos subsídios para a criação de modelos claros que nos auxiliam na construção de soluções de software de qualidade. • A UML permite também a criação de modelos que simulam o comportamento do software em construção em diversos aspectos. Mas nunca se esqueça: sempre caberá ao desenvolvedor a responsabilidade de usar as informações de modo a obter soluções de qualidade de acordo com as expectativas do usuário e que sejam capazes de produzir os melhores resultados possíveis. • Ao utilizar a UML precisamos de bom senso para oferecer soluções adequadas e no prazo esperado pelo usuário, criando modelos apenas para as partes que realmente demandam definição mais aprofundada. RESUMO DO TÓPICO 1 20 1 Cite os objetivos da UML. 2 Defina classe. 3 Defina objeto. 4 O que você entende por pacote? 5 O que é um diagrama? AUTOATIVIDADE 21 TÓPICO 2 MODELO DE DESENVOLVIMENTO, DIAGRAMAS DA UML, DIAGRAMA DE CASOS DE USO UNIDADE 1 1 INTRODUÇÃO Desenvolver um software exige do gestor do projeto a habilidade de equilibrar pessoas, atividades, tecnologias e metodologias. Projetos de softwares são cercados por riscos desde a sua fase embrionária. Com isso, os modelos surgem como uma alternativa ágil para tornar a correção mais rápida e com custo reduzido. O próprio uso de modelos já possibilita reduzir o custo do desenvolvimento das atividades, pois permite prever o comportamento do sistema quando o mesmo estiver finalizado e em uso. Uma forma mais eficiente de pensar em modelagem e desenvolvimento de projetos é a proposta orientada a objetos, que organiza os problemas em torno de situações reais, ou seja, como elas de fato acontecem na prática, e isso impõe uma forma completamente diferente de pensar e organizar a solução, se comparado à forma como o pensamento estruturado apresenta a solução (BOOCH, 1994). A grande vantagem da orientação a objetos é que os projetos são mais facilmente compreendidos, e em consequência, mais facilmente construídos, pelos profissionais envolvidos no projeto. A “partícula” fundamental desta metodologia é o objeto, que traz consigo o seu comportamento, que pode vir acrescido de regras, conhecimentos, responsabilidades e um ciclo de vida definido. Depois de modelado não sofre modificações, sendo agregado ao que já existe no sistema. A figura a seguir mostra as visões de um projeto orientado a objetos. UNIDADE 1 | REVISÃO DE CONCEITOS DE ORIENTAÇÃO A OBJETOS, REVISÃO DE CONCEITOS DA UML, DIAGRAMAS DE VISÃO COMPORTAMENTAL: CASOS DE USO, DIAGRAMA DE ATIVIDADES E DIAGRAMA DE MÁQUINA DE ESTADOS 22 FIGURA 18 – VISÕES DE UM PROJETO COM UML Visão de Projeto Funcionalidade Vocabulário Visão do Processo Desempenho Escalabilidade Throughput Visão da Implantação Topologia do Sistema Distribuição Instalação Visão da Implementação Codifi cação Montagem Visão de Caso de Uso Conceitual Físico Workfl ow de Design (Arquitetura): Introdução. UML, Visões: D es en ha nd o C om po ne nt e de S of tw ar e co m U M L FONTE: Piva (2010) 2 UML UML signifi ca Linguagem de Modelagem Unifi cada de projetos orientados a objetos. É uma linguagem, não podendo ser considerada um método. A UML é uma linguagem padrão de notação de projetos. Por notação entende-se especifi car, visualizar e documentar os elementos de um sistema OO. A UML é importante: serve como linguagem para expressar decisões de projeto que não são óbvias ou que não podem ser deduzidas do código; provê uma semântica que permite capturar as decisões estratégicas e táticas;provê uma forma concreta o sufi ciente para a compreensão das pessoas e para ser manipulada pelas máquinas. NOTA A UML não depende das ferramentas de programação utilizadas no desenvolvimento do projeto. Além de dar suporte a todos os processos de engenharia de software necessários ao projeto, a UML pode ser defi nida como a linguagem de modelagem padrão no desenvolvimento de sistemas distribuídos, por exemplo, pois, basicamente, sua característica principal baseia-se em um conglomerado de técnicas de notação gráfi ca para criar a modelagem visual dos sistemas. É TÓPICO 2 | MODELO DE DESENVOLVIMENTO, DIAGRAMAS DA UML, 23 FONTE: Disponível em: <http://issuu.com/geeadcps/docs/livro3_alta/81>.Acesso em: 7 out. 2015. É uma linguagem de modelagem única e atualmente muito utilizada! NOTA A UML não tem a preocupação de demonstrar como o trabalho ou as atividades envolvidas no projeto serão executados. O objetivo da linguagem é descrever "o que fazer", “como fazer", "quando fazer" e "por que fazer". A Linguagem Unificada de Modelagem utiliza diagramas que podem ser usados de forma combinada a fim de obter todas as visões e aspectos do sistema. 3 DIAGRAMAS DA UML Diagramas, na verdade, são gráficos que permitem visualizar o sistema de formas diferentes. Pela notação dos diagramas da UML é possível descrever de forma ágil e objetiva todos os aspectos da modelagem de dados, sendo que cada diagrama tem seu significado, sua notação e a forma de ser utilizado (ANDRADE, 2007). Os diagramas da UML estão classificados em dois grupos distintos: estruturais e comportamentais, sendo que o primeiro grupo mostra tudo o que não muda no sistema, e o segundo mostra as reações e evoluções do mesmo. Cada diagrama analisa o sistema, ou parte dele, sob uma determinada ótica (GUEDES, 2007). NOTA uma ferramenta ágil, pois combina e suporta as melhores técnicas, que vão desde a modelagem dos dados até o levantamento e engrenagem de todos os componentes do sistema. A figura a seguir mostra todos os diagramas da UML agrupados de acordo com sua classificação. Os diagramas estruturais tratam o aspecto estrutural do ponto de vista do sistema e das classes. São para visualizar, especificar, construir e documentar os aspectos que não são mutáveis (ANDRADE, 2007). Ainda de acordo com o autor, os aspectos estáticos de um sistema de software envolvem a existência e a colocação de itens como classes, interfaces, colaborações, componentes. UNIDADE 1 | REVISÃO DE CONCEITOS DE ORIENTAÇÃO A OBJETOS, REVISÃO DE CONCEITOS DA UML, DIAGRAMAS DE VISÃO COMPORTAMENTAL: CASOS DE USO, DIAGRAMA DE ATIVIDADES E DIAGRAMA DE MÁQUINA DE ESTADOS 24 FIGURA 19 – MODELOS DE DIAGRAMAS DA UML FONTE: Piva (2010) D ia gr am as da U M L D ia gr am as E st ru tu ra is D ia gr am a de O bj et os D ia gr am a de C om po ne nt es D ia gr am a de Im pl an ta çã o D ia gr am a de S eq uê nc ia D ia gr am a de Te m po riz aç ão D ia gr am a de C ol ab or aç ão D ia gr am a de V is ão G er al d a In te ra çã o D ia gr am a de E st ru tu ra C om po st a D ia gr am a de Im pl em en ta çã o D ia gr am a de C la ss es D ia gr am a de P ac ot es D ia gr am as C om po rta m en ta is D ia gr am a de A tiv id ad es D ia gr am as d e In te ra çã o D ia gr am a de Tr an si çõ es de E st ad os D ia gr am a de C as os d e U so TÓPICO 2 | MODELO DE DESENVOLVIMENTO, DIAGRAMAS DA UML, 25 Os diagramas da UML estão divididos em Estruturais e Comportamentais. 3.1 DIAGRAMAS ESTRUTURAIS • De Classe: Este diagrama é fundamental e o mais utilizado na UML e serve de apoio aos outros diagramas. O Diagrama de Classe mostra o conjunto de classes com seus atributos e métodos e os relacionamentos entre classes. • De Objeto: O Diagrama de Objeto está relacionado com o diagrama de classes e é praticamente um complemento dele. Fornece uma visão dos valores armazenados pelos objetos de um Diagrama de Classe em um determinado momento da execução do processo do software. • De Componentes: Está associado à linguagem de programação e tem por finalidade indicar os componentes do software e seus relacionamentos. • De Implantação: Determina as necessidades de hardware e características físicas do sistema. • De Pacotes: Representa os subsistemas englobados de forma a determinar partes que o compõem. • De Estrutura: Descreve a estrutura interna de um classificador. FONTE: Disponível em: <http://issuu.com/geeadcps/docs/livro3_alta/81>. Acesso em: 7 out. 2015. 3.2 DIAGRAMAS COMPORTAMENTAIS De Caso de Uso (Use Case): Geral e informal para fases de levantamento e análise de Requisitos do Sistema. De Máquina de Estados: Procura acompanhar as mudanças sofridas por um objeto dentro de um processo. De Atividades: Descreve os passos a serem percorridos para a conclusão de uma atividade. De Interação: Dividem-se em: o De Sequência: Descreve a ordem temporal em que as mensagens são trocadas entre os objetos. o Geral interação: Variação dos diagramas de atividades que fornece visão geral dentro do sistema ou processo do negócio. o De comunicação: Associado ao diagrama de Sequência, complementando-o e concentrando-se em como os objetos estão vinculados. o De tempo: Descreve a mudança de estado ou condição de uma instância de uma classe ou seu papel durante o tempo. UNIDADE 1 | REVISÃO DE CONCEITOS DE ORIENTAÇÃO A OBJETOS, REVISÃO DE CONCEITOS DA UML, DIAGRAMAS DE VISÃO COMPORTAMENTAL: CASOS DE USO, DIAGRAMA DE ATIVIDADES E DIAGRAMA DE MÁQUINA DE ESTADOS 26 FIGURA 20 – DIAGRAMAS COMPORTAMENTAIS Diagramas Comportamentais Diagrama de Atividades Diagrama de Transições de Estados Diagrama de Interação Diagrama de Casos de Uso Diagrama de Sequência Diagrama de Temporização Diagrama de Visão Geral da Interação Diagrama de Colaboração FONTE: Piva (2010) Os diagramas comportamentais podem ser divididos em: • Diagramas de Casos de Uso • Diagrama de Atividades • Diagrama de Máquina de Estados • Diagramas de Interação: o Diagrama de Sequência o Diagrama de Comunicação o Diagrama de Tempo o Diagrama de Interação Geral 4 DIAGRAMAS COMPORTAMENTAIS Os diagramas de comportamento têm o mesmo objetivo da modelagem dinâmica do sistema. São usados para visualizar, especificar, construir e documentar os aspectos do sistema que sofrem mudanças ao longo do tempo, como, por exemplo, o fluxo de mensagens e a movimentação física de componentes em uma rede. FONTE: Disponível em: <http://issuu.com/geeadcps/docs/livro3_alta/81>. Acesso em: 7 out. 2015. Cada diagrama citado acima será estudado posteriormente! ESTUDOS FU TUROS TÓPICO 2 | MODELO DE DESENVOLVIMENTO, DIAGRAMAS DA UML, 27 4.1 DIAGRAMA DE CASOS DE USO O objetivo principal deste diagrama é propor uma visão de como os usuários interagem com o sistema. NOTA Estes diagramas especificam o que o sistema faz, mas não detalham como o trabalho deve ser feito. FIGURA 21 – EXEMPLO DE DIAGRAMA DE CASO DE USO Vender CDs Administrar estoque Atendente Gerente FONTE: Tacla (2010) Diagrama de casos de uso é uma ferramenta de comunicação entre clientes, usuários e desenvolvedores para discutirem e definirem as funcionalidades que devem ser realizadas pelo sistema. 4.2 ELEMENTOS DO DIAGRAMA DE CASOS DE USO • Atores • Casos de uso • Relacionamentos • Associação • Generalização • Dependência: Extensão e Inclusão UNIDADE 1 | REVISÃO DE CONCEITOS DE ORIENTAÇÃO A OBJETOS, REVISÃO DE CONCEITOS DA UML, DIAGRAMAS DE VISÃO COMPORTAMENTAL: CASOS DE USO, DIAGRAMA DE ATIVIDADES E DIAGRAMA DE MÁQUINA DE ESTADOS 28 De acordo com Tacla (2010), para encontrar os atores de um sistema deve- se sempre examinar a situação, procurando por pessoas ou sistemas no entorno da situação. Para esse processo ser mais eficiente deve-se questionar: • Quais pessoas ou outras entidades interessam a um requisito funcional? • Quem irá alimentar as informações do sistema e também quem será o receptor destas informações? • Quais recursos externos são utilizados pelo sistema? • Existem pessoas que desempenhampapéis diferentes no sistema? • O sistema interage com outros sistemas que já existem e são usados pela organização? 4.4 ELEMENTO CASOS DE USO “A coleção de casos de uso representa todos os modos de execução do sistema do ponto de vista do usuário. Um caso de uso é uma sequência de ações que produz um resultado significativo (com valor) para um ator” (TACLA, 2010, p. 17). • Quais são as tarefas de cada ator? • Que informações o ator obtém do sistema? • Quem as fornece? • Quem as captura? • Algum ator precisa ser informado sobre eventos produzidos pelo sistema? o Sim => casos de uso de registro e notificação • Há eventos externos que devem ser notificados ao sistema? o Sim => deve haver casos para que os atores possam notificar o sistema 4.3 ELEMENTO ATORES Representam papéis desempenhados por usuários ou qualquer outra entidade externa ao sistema, por exemplo, hardware e outros sistemas. Podem iniciar casos de uso; podem prover e/ou receber informações dos casos de uso. Gerente Contas Receber Scanner FIGURA 22 – REPRESENTAÇÃO DE ATORES FONTE: Tacla (2010) TÓPICO 2 | MODELO DE DESENVOLVIMENTO, DIAGRAMAS DA UML, 29 4.4.1 Descrição 5 FLUXO DE EVENTOS Um fluxo de evento serve para descrever como o sistema e os atores cooperam entre si para entregar algo de valor aos atores e também descrevem o que pode impedir que isso aconteça. Na verdade, um fluxo de eventos faz a descrição de um caminho entre muitos, uma vez que um caso de uso pode ser representado e executado de formas distintas (TACLA, 2010). Ainda segundo o mesmo autor, existem fluxos distintos: fluxos primários ou básicos e fluxo alternativo. Por esta visão, o fluxo básico se torna a explicação, enquanto que o fluxo alternativo é a alternativa. Tomemos como exemplo a situação proposta pelo autor citado onde uma pessoa explica um caminho para outra. Há fluxos primários ou básicos (fluxo normal de eventos) e alternativos (o que fazer se…). Para descrevê-los, é possível se inspirar na situação em que uma pessoa explica um caminho a outra. “Para ir ao churrasco, pegue a BR-116 na direção de São Paulo. Logo após o Clube Santa Mônica, tem um retorno por baixo da pista. Faça o retorno e continue reto (não retorne à BR). Continue nesta estradinha asfaltada por 1 km, no entroncamento pegue a estrada de terra à direita, ande cerca de 500m, você verá um grande eucalipto A UML não apresenta uma descrição padrão para casos de uso, sendo composta por diagramas informais. Vale lembrar que os diagramas de caso de uso facilitam a visualização, mas não são descritos detalhadamente, sendo que o uso deste diagrama apenas não é considerado suficiente para a compreensão e modelagem total da situação (TACLA, 2010, p. 17). De acordo com o autor, os casos de uso são facilmente descritos quando utilizados os seguintes elementos: • Nome • Descrição • Requisitos (requirements): são os requisitos funcionais providos pelo caso de uso • Restrições (constraints), tais como pré e pós-condições e condições invariantes: o Precondições: “define o que deve ser verdadeiro para que o caso de uso seja iniciado. Por exemplo, num sistema bancário, para o caso de uso Abrir conta corrente, uma precondição é apresentar CPF sem restrições (aprovação do pedido)” (TACLA, 2010, p. 17). o 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: conta aberta e com um depósito inicial ou conta não aberta por reprovação do CPF” (TACLA, 2010, p. 17). UNIDADE 1 | REVISÃO DE CONCEITOS DE ORIENTAÇÃO A OBJETOS, REVISÃO DE CONCEITOS DA UML, DIAGRAMAS DE VISÃO COMPORTAMENTAL: CASOS DE USO, DIAGRAMA DE ATIVIDADES E DIAGRAMA DE MÁQUINA DE ESTADOS 30 e uma araucária. A entrada da chácara é entre os dois. Não se esqueça de trazer o pinhão” (TACLA, 2010, p. 18) // EXEMPLO DE FLUXO PRIMÁRIO “Se estiver chovendo muito, os 500m na terra podem ser bem difíceis, porque o barro é mole. Neste caso, siga reto no entroncamento (ao invés de virar à direita) e na próxima à direita pegue a rua de paralelepípedos. Ande cerca de 1 km e depois vire na segunda à direita que vai desembocar na frente da chácara” (TACLA, 2010, p. 18) // EXEMPLO DE FLUXO ALTERNATIVO 1 “Se você for comprar o pinhão no caminho, logo depois de fazer o retorno da BR tem uma venda. Se estiver fechada, um pouco mais à frente tem um senhor da Chácara Pinhais que também vende. Se não encontrar pinhão, não tem problema” (TACLA, 2010, p. 18) // EXEMPLO DE FLUXO ALTERNATIVO 2 Tacla (2010) sugere que nas fases iniciais de análise dos dados é importante manter o foco nos fluxos básicos, pois 80% do tempo de execução de um sistema são ocupados por casos primários. Mas não devemos nos esquecer de documentar os fluxos alternativos, uma vez que ambos documentam como as responsabilidades especificadas nos casos de uso são divididas entre sistema e atores. “No desenrolar do projeto, as responsabilidades atribuídas ao sistema devem ser distribuídas entre os objetos que compõem o sistema” (TACLA, 2010, p. 19). IMPORTANT E 5.1 FLUXO BÁSICO Um fluxo básico demonstra o que acontece quando se executa o caso de uso. Para que isso seja possível, o mesmo deve conter o ator e o evento disparado para dar início ao caso; a iteração entre o ator e o sistema e a descrição de como o caso é finalizado. 5.2 SUBFLUXO Para melhor entendimento de um fluxo, este pode ser fragmentado em vários subfluxos. NOTA TÓPICO 2 | MODELO DE DESENVOLVIMENTO, DIAGRAMAS DA UML, 31 “Um fluxo de eventos pode ser decomposto em subfluxos para melhorar a legibilidade. Importante evitar muitas decomposições para não dificultar o entendimento. Os subfluxos devem ser executados na totalidade, não podem ser executados pela metade” (TACLA, 2010, p. 19). 5.2.1 Pontos de extensão São pontos específicos do fluxo que permitem inserir comportamentos adicionais. Podem ser privados ou públicos (TACLA, 2010, p. 20). Privados: caso sejam visíveis somente dentro do caso de uso onde foram criados. Públicos: quando estendem o caso onde foram definidos. NOTA No exemplo Buscar produtos e fazer pedido, os pontos de extensão seguintes são encontrados (TACLA, 2010, p. 20): _ {Mostrar catálogo de produtos} _ {Escolher produto} _ {Produto esgotado} _ {Processar pedido} _ {Informações de pagamento não válidas} _ {Informações de envio não válidas} Um ponto de extensão pode definir: • uma localização única dentro do fluxo, por exemplo, {Mostrar catálogo de produtos}, {Escolher produtos} e {Processar pedido}; • um conjunto de localizações que representam um certo estado do caso de uso, por exemplo, {Produto esgotado} que poderia aparecer em vários pontos do fluxo de eventos; • uma região entre dois pontos de extensão, por exemplo, {Escolher produtos} e {Processar pedido} (TACLA, 2010, p. 20). 5.3 FLUXO ALTERNATIVO “Um fluxo alternativo apresenta um comportamento opcional, de outra forma, que não é parte do comportamento normal de um caso de uso” (TACLA, 2010, p. 21). Fluxos alternativos são fluxos que podem ser executados numa funcionalidade a partir de escolha do usuário, e não de erros do sistema. São três tipos de fluxos alternativos: UNIDADE 1 | REVISÃO DE CONCEITOS DE ORIENTAÇÃO A OBJETOS, REVISÃO DE CONCEITOS DA UML, DIAGRAMAS DE VISÃO COMPORTAMENTAL: CASOS DE USO, DIAGRAMA DE ATIVIDADES E DIAGRAMA DE MÁQUINA DE ESTADOS 32 6 ELEMENTO RELAÇÕES São várias as relações em Casos de Uso, mas as mesmas não representam a ordem de execução dos casos. E as mesmas devem melhorar a compreensão daquilo que o sistema deve executar. 6.1 ASSOCIAÇÃO Associação é a mais comum das relações. Pode ser percebida entre dois atores ou entre um ator e um caso de uso. São representadas por uma linha cheia, comou sem direção. 6.2 ATOR X ATOR Relações associativas podem conectar atores para representar comunicação entre atores. A relação pode receber um nome que identifica o conteúdo da mensagem, documento ou objeto que trafega entre os atores. A figura mostra uma associação entre o ator usuário de biblioteca que passa o livro ao atendente que realiza o empréstimo ou a devolução. Como não há flechas, assume-se que o atendente devolve algo ao usuário da biblioteca, provavelmente um comprovante não representado no diagrama. Não é recomendável colocar este tipo de relação no diagrama de casos de uso (TACLA, 2010, p. 22). FIGURA 23 – REPRESENTAÇÃO DE RELAÇÕES EM CASOS DE USO Usuário Biblioteca Atendente livro Realizar Empréstimo Realizar Devolução FONTE: Tacla (2010) 6.3 ATOR X CASO Associações entre atores e casos de uso servem para indicar se quem dá início à comunicação é o ator ou o caso de uso, além de traçar o fluxo da informação, indicando quem alimenta quem com a informação. • Específico: iniciam num ponto de extensão. • Regional: podem ocorrer entre dois pontos de extensão. • Geral: podem ocorrer em qualquer ponto do caso de uso. TÓPICO 2 | MODELO DE DESENVOLVIMENTO, DIAGRAMAS DA UML, 33 6.4 ELEMENTO DEPENDÊNCIA - INCLUSÃO E EXTENSÃO Quando um caso de uso inclui outro caso de uso (considerado um subcaso) na sua execução, este está usando a relação de inclusão entre casos de uso. Um subcaso pode ser considerado como um subfluxo de um fluxo de eventos primário, que foi separado e deve ser executado por completo. A Figura 24 mostra: Um caso onde se efetua uma matrícula que possui subfluxos escolher disciplinas, alocar alunos às turmas e emitir boleto. Este último é compartilhado com o caso Efetuar inscrição curso opcional e, portanto, deve ser representado no diagrama. Um erro comum que adiciona complexidade ao diagrama é incluir os subfluxos escolher disciplinas e alocar alunos às turmas no diagrama (TACLA, 2010, p. 22). FIGURA 24 – RELAÇÃO DE INCLUSÃO Aluno Efetuar inscrição Curso Opcional Alocar Alunos as Turmas Escolher Disciplinas Efetuar Matrícula Emitir Boleto <<Include>> <<Include>> <<Include>> <<Include>> FONTE: Tacla (2010) A inclusão deve ser utilizada para administrar comportamentos comuns e não para estruturar funcionalmente o diagrama. NOTA UNIDADE 1 | REVISÃO DE CONCEITOS DE ORIENTAÇÃO A OBJETOS, REVISÃO DE CONCEITOS DA UML, DIAGRAMAS DE VISÃO COMPORTAMENTAL: CASOS DE USO, DIAGRAMA DE ATIVIDADES E DIAGRAMA DE MÁQUINA DE ESTADOS 34 7 EXTENSÃO É uma indicação de que outros casos de uso poderão ser adicionados a um caso de uso específi co. Para Tacla (2010, p. 25): • Um caso de uso de extensão não requer modifi cações no caso base (aquele que é estendido). O comportamento básico do caso base permanece intacto. Um caso de uso que estende um caso base conhece este último (não é muito comum um caso de uso estender mais de um caso base). • Uma extensão nasce como um fl uxo alternativo, mas nem todo fl uxo alternativo vira uma extensão. • vCasos de uso que estendem assumem o controle no ponto de extensão e quando terminam devolvem o controle no mesmo ponto. Pelo exemplo proposto na Figura 25, “a emissão de histórico escolar é estendida pelo caso imprimir comprovante de término quando o aluno solicitante for formado. Observa-se que é um comportamento opcional que pode não ser oferecido sem prejuízo ao comportamento básico emitir histórico escolar” (TACLA, 2010, p. 26). FIGURA 25 – EXEMPLO DE EXTENSÃO Aluno Imprimir Comprovante Termino aluno formado e um ponto de extensão Emitir Historico Escolar aluno formado values <<extend>> FONTE: Tacla (2010) Nota-se no ponto de extensão público denominado {aluno formado} onde o comportamento opcional imprimir comprovante término é inserido. É provável que existam outros pontos de extensão privados defi nidos nos fl uxos de emitir histórico escolar, porém, no diagrama só os usados pelas extensões são listados (TACLA, 2010, p. 26). 8 ELEMENTO GENERALIZAÇÃO/ESPECIALIZAÇÃO A relação de generalização/especialização pode ocorrer entre casos de uso ou entre atores. Caso x Caso TÓPICO 2 | MODELO DE DESENVOLVIMENTO, DIAGRAMAS DA UML, 35 Generalização permite especificar comportamentos genéricos que podem ser especializados para atender necessidades específicas. Normalmente é utilizado quando se quer descrever famílias de sistemas. Por exemplo, uma empresa que desenvolve software para terminais bancários de autoatendimento quer expandir seus negócios para outras áreas, tais como pagamento direto em bombas de gasolina. NOME: Realizar transação (caso abstrato). DESCRIÇÃO: Permite ao usuário comprar mercadorias de um terminal automático, sendo o valor das mercadorias descontado de uma conta bancária. PRECONDIÇÕES: (e) O cliente possui um cartão bancário; a conexão com o banco está ativa; o terminal deve ter mercadoria. PÓS-CONDIÇÕES: (ou) O terminal retornou o cartão bancário ao cliente, entregou a mercadoria ao cliente e debitou o valor de sua conta. O terminal retornou o cartão bancário ao cliente, não entregou nenhuma mercadoria e nenhum valor foi debitado da sua conta. FONTE: Disponível em: <https://www.passeidireto.com/arquivo/6299813/analise-e-projeto-oo-e- uml/8>. Acesso em: nov. 2015. Ator x Ator Especialização de atores representa que um conjunto deles possui responsabilidades ou características em comum. Algumas dicas para evitar modelagens desnecessárias: • Não utilizar atores para representar permissões de acesso. • Não utilizar atores para representar organogramas (hierarquias) de cargos de uma empresa. • Utilizar atores somente para definir papéis em relação ao sistema. Por exemplo, se num sistema de matrículas de uma universidade há casos de usos especiais para alunos de ciências exatas e para alunos de humanas, então é sinal de que estes alunos são especializações de um ator genérico aluno. A Figura 26 ilustra a notação UML para este caso. Observar que alunos de ciências exatas e de humanas herdam todas as associações do ator aluno. FONTE: Disponível em: <https://www.passeidireto.com/arquivo/6299813/analise-e-projeto-oo-e- uml/8>. Acesso em: nov. 2015. UNIDADE 1 | REVISÃO DE CONCEITOS DE ORIENTAÇÃO A OBJETOS, REVISÃO DE CONCEITOS DA UML, DIAGRAMAS DE VISÃO COMPORTAMENTAL: CASOS DE USO, DIAGRAMA DE ATIVIDADES E DIAGRAMA DE MÁQUINA DE ESTADOS 36 FIGURA 26 – REPRESENTAÇÃO DE HERANÇA Aluno Aluno C. Extas Aluno Humanas FONTE: Tacla (2010) 9 DICAS IMPORTANTES Casos de uso auxiliares “Casos de uso auxiliares são frequentemente esquecidos, pois não são essenciais à funcionalidade do sistema. Porém, esquecê-los completamente pode conduzir a um sistema difícil de ser utilizado” (TACLA, 2010, p. 27). “Lembrar de colocar casos de uso para executar, manter e configurar o sistema, tais como: lançar e parar o sistema, incluir novos usuários, fazer backup das informações, incluir novos relatórios e realizar configurações” (TACLA, 2010, p. 27). Decomposição funcional Tacla (2010, p. 28) explica a decomposição funcional desta forma: • Não é necessário detalhar em excesso os casos de uso. Muitos detalhes levam à decomposição dos casos em funções. O objetivo é compreender o sistema através de cenários de utilização. • Casos de uso não são feitos para analisar (no sentido de decompor) os requisitos em requisitos menores. É um processo de síntese ou elaboração (e não de análise) no qual o problema não é totalmente conhecido. Quebrá-lo em partes menores (análise) dificulta a obtenção de uma visão geral. • Em equipes com forte competência em análise estruturada, há tendência em encontrar funções ao invés de casos de uso. Por exemplo, fazer pedido, revisar pedido, cancelar pedido e atender pedido podem parecer
Compartilhar