Glauber Dantas Macedo R.A. 0650348-8º Semestre Modelagem de Sistema WEB de Controle de Impostos Municipais utilizando UML. Jaguariúna 2008 1
Glauber Dantas Macedo R.A. 0650348-8º Semestre Modelagem de Sistema WEB de Controle de Impostos Municipais utilizando UML. Projeto apresentado à disciplina Trabalho de Graduação III, do curso de Ciência da Computação da Faculdade de Jaguariúna, sob a orientação do Prof. Ms. Peter Jandl Junior e Prof. Ms Fernando Augusto Zancheta, como exigência parcial para a obtenção de média semestral. Jaguariúna 2008 2
MACEDO, Glauber Dantas. Modelagem de Sistema WEB de Controle de Impostos Municipais utilizando UML. 2008. Monografia defendida e aprovada na FAJ em 10 de dezembro de 2008 pela banca examinadora constituída pelos professores: Prof. Ms. Peter Jandl Junior. FAJ - Orientador Prof. Ms. Fernando Augusto Zancheta FAJ Convidado FAJ 3
AGRADECIMENTOS Não seria justo citar nomes apenas das pessoas que me ajudaram diretamente, mas sim lembrá-las para sempre dentro de mim, e carregá-las em minha lembrança pelo resto da missão chamada VIDA. Por isso deixarei de citar seus nomes para que não magoe pessoas que não terão seus nomes elencados em minha grandiosa lista de pessoas que sou muito grato, que vai de A a Z. Por isso, agradeço a TODAS as pessoas que de maneira direta ou indireta me apoiaram nesta batalha em minha vida, que me ajudaram muito ou pouco, mas SIM contribuíram na realização de um sonho, seja meu ou de outrem ligado a mim! Aos meus Pais, João e Marileide, que muito fizeram por mim, mais do que deveriam, para alcançar esse triunfo, e também aos meus irmãos João Carlos (Carlinhos) e Hugo. A minha família, Sandra e Rafael, que tiveram muita, mais muita paciência e compreenderam as minhas ausências em parte de suas vidas. Em fim, a Deus que me proporcionou essa jornada minha vida e por ter colocados pessoas maravilhosas em meu caminho, sejam amigos ou colegas, de professores aos motoristas de ônibus. 4
O único lugar onde "sucesso" vem antes de "trabalho" é no dicionário. (Albert Einstein) 5
MACEDO, Glauber Dantas. Modelagem de Sistema WEB de Controle de Impostos Municipais utilizando UML. 2008. Monografia (Bacharelado em Ciência da Computação) Curso de Ciência da Computação da Faculdade de Jaguariúna, Jaguariúna. RESUMO O presente trabalho tem por objetivo maior apresentar a modelagem e a regra de negócio de um sistema de controle de Imposto Municipal denominado ISSQN (Imposto Sobre Serviço de Qualquer Natureza), abordando o uso da Análise de Requisitos e suas metodologias para modelagem do referido Sistema. Apresentar também a tecnologia UML, mostrando seus conceitos, suas regras, e suas vantagens. Levantar as necessidades de uma Prefeitura Municipal para a modelagem dos diagramas específicos, necessários e suficientes para referenciar o uso de uma ferramenta desse porte. PALAVRAS CHAVES: MODELAGEM, ORIENTAÇÃO A OBJETO, UML, DIAGRAMA, IMPOSTO. 6
SUMÁRIO AGRADECIMENTOS... 4 RESUMO... 6 SUMÁRIO... 7 LISTA DE SIGLAS... 9 LISTA DE FIGURAS... 10 LISTA DE TABELAS... 12 1. INTRODUÇÃO... 13 2. ORIENTAÇÃO A OBJETO... 15 2.2. Conceitos... 15 3. UML... 17 3.1. Visão de Geral da UML... 17 3.2. Modelagem com UML... 18 3.2.1. Blocos de Construção... 18 4. DIAGRAMAS ESTÁTICOS... 21 4.1. DIAGRAMA DE CLASSES... 21 4.1.2 Visibilidade... 21 4.1.3. Multiplicidade... 22 4.1.4. Relacionamentos... 22 4.1.4.1. Associação... 22 4.1.4.2. Generalização... 24 4.1.4.3. Dependência... 24 4.1.4.4. Agregação... 24 4.1.4.5. Composição... 25 4.2. DIAGRAMA DE OBJETOS... 26 4.3. DIAGRAMA DE IMPLEMENTAÇÃO... 28 4.3.1. Diagrama de Componentes... 28 4.3.2. Componente... 28 4.3.3. Diagrama de Implantação... 29 4.3.4. Nó... 29 5. DIAGRAMAS DINÂMICOS... 31 5.1. DIAGRAMA DE CASO DE USO... 31 5.1.1. O Que é?... 31 5.1.2 Atores... 32 5.1.3 Levantamento de Requisitos / Necessidades... 33 5.1.4. Casos de Uso e Atores... 34 5.1.4.1. Associação (Association)... 34 5.1.4.2. Generalização (Generalization)... 34 5.1.4.3 Extensão (Extend)... 35 5.1.4.4. Inclusão (Include)... 35 5.2. DIAGRAMA DE INTERAÇÃO... 36 5.2.1. Diagrama de Seqüência... 36 5.2.2. Diagrama de Colaboração... 37 5.3. DIAGRAMA DE GRÁFICO E ESTADO... 38 5.3.1. Estado... 38 5.3.1.1. Estado Inicial e Estado final... 39 5.3.2. Transições... 40 5.4. DIAGRAMA DE ATIVIDADES... 41 5.4.1. Modelagem com Diagrama de Atividades... 41 5.4.1.1. Estado de ação... 42 5.4.1.2. Transições... 42 5.4.1.3. Decisões e Intercalação... 42 7
5.4.1.4. Bifurcação e União... 43 5.4.1.5. Raias... 44 6. ANÁLISE DE REQUISITOS... 45 6.1. Introdução... 45 6.3. Estrutura... 45 6.3. Descrição do Sistema... 45 7. MODELAGEM... 50 7.1 Modelagem UML... 51 7.1.1 Diagrama de Use Case... 51 7.1.2 - Caso de Uso Fazer login... 52 7.1.3 - Caso de Uso Consulta Débitos... 52 7.1.4 - Caso de Uso Consulta dados Cadastrais... 52 7.1.5 - Caso de Uso Criar acesso... 53 7.1.6 - Caso de Uso Cadastro de Empresa... 54 7.1.7 - Caso de Uso Cadastro de Sócios... 55 7.1.8 - Caso de Uso Cadastrar Receitas... 56 7.1.9 - Caso de Uso Cadastrar Endereço... 56 7.1.10 - Caso de Uso Consulta Pagamentos... 56 7.1.11 - Caso de Uso Fazer Escrituração... 57 7.1.12 - Caso de Uso Alterar Escrituração... 58 7.1.13 - Caso de Uso Retificar Declaração... 58 7.1.14 - Caso de Uso Fechamento Mensal Escrituração... 59 7.1.15 - Caso de Uso Emitir Boleto... 60 7.1.16 - Caso de Uso Cadastrar Atividades... 60 7.1.17 - Caso de Uso Alterar Cadastro... 60 7.1.18 Diagrama de Classe... 62 7.1.19 Diagrama de Objeto... 63 7.1.20 Diagrama de Seqüência... 64 7.1.21 Diagrama de Atividades... 65 8. CONCLUSÕES... 66 9. BIBLIOGRAFIA... 68 10. ASSINATURAS... 70 8
LISTA DE SIGLAS CEP CNAE CNPJ CTN DECA IBGE I.M. IPTU ISSQN O.M.T. O.O. O.O.S.E. PHP UF UML Código de Endereçamento Postal Cadastro Nacional de Atividades Econômicas Cadastro Nacional de Pessoas Jurídicas Código Tributário Municipal Declaração Cadastral Instituto Brasileiro de Geografia e Estatística Inscrição Municipal Imposto Predial Territorial Urbano Imposto sobre Serviço de Qualquer Natureza Object Modeling Technique Orientação a Objetos Object-Oriented Software Enginnering Hypertext Preprocessor Unidade Federativa Unified Modeling Language 9
LISTA DE FIGURAS Figura 1 - Exemplo de um Objeto instanciado em relação a sua Classe... 15 Figura 2 - Herança em notação UML... 16 Figura 3 Polimorfismo em UML... 16 Figura 4 - Representação de Associação Binária.... 22 Figura 5 - Representação de Associação Ternária.... 23 Figura 6 - Representação de Associação Ternária.... 23 Figura 7 - Representação de Multiplicidade em uma Associação.... 23 Figura 8 Representação de Generalização... 24 Figura 9 - Representação de Dependência... 24 Figura 10 Representação de Agregação... 25 Figura 11 Representação de Composição.... 25 Figura 12 - Representação de um Diagrama de Classe... 27 Figura 13 - Representação de um Diagrama de Objetos.... 27 Figura 14 Representação de Componente.... 29 Figura 15 Representação de Diagrama de Implementação.... 29 Figura 16 Representação de Nós.... 30 Figura 17 - Representação de Caso de Uso.... 31 Figura 18 - Representação de Atores.... 33 Figura 19 - Representação de uma Associação... 34 Figura 20 - Representação de uma Generalização... 34 Figura 21 - Representação de Inclusão.... 35 Figura 22 - Representação de Inclusão.... 35 Figura 23 - Representação de um Diagrama de Seqüências... 37 Figura 24 - Representação de um Diagrama de Colaboração.... 38 Figura 25 Exemplo de estados.... 39 Figura 26 Exemplo de estado com compartimento de transições internas... 39 Figura 27 Exemplo de estado inicial.... 40 Figura 28 Exemplo de estado inicial.... 40 Figura 29 Exemplo de Transição.... 41 Figura 30 Representação dos Símbolos do Diagrama de Atividades... 42 Figura 31 Representação de Estado de ação.... 42 Figura 32 Representação de Transição.... 42 Figura 33 Representação de Estado de ação.... 43 Figura 34 Representação de Bifurcação e Raia... 44 10
Figura 35 Diagrama de Use Case... 51 Figura 36 Diagrama de Classe... 62 Figura 37 Diagrama de Objeto... 63 Figura 38 Diagrama de Seqüência Consulta dados cadastrais... 64 Figura 39 - Diagrama de Seqüência Escrituração... 64 Figura 40 Diagrama de Atividades Escrituração... 65 11
LISTA DE TABELAS Tabela 1 - Divisão de elementos do Modelo.... 18 Tabela 2 Tipos de Diagramas.... 19 Tabela 3 Propriedades de Visibilidade... 21 Tabela 4 Representação de Multiplicidade... 22 Tabela 5 Tabela de Cadastro das Empresas... 47 Tabela 6 Tabela de cadastro de logradouro... 47 Tabela 7 Tabela de cadastro de Bairro... 47 Tabela 8 Tabela de cadastro de Município... 47 Tabela 9 Tabela de cadastro de UF... 48 Tabela 10 Tabela de Atividades... 48 Tabela 11 Tabela de cadastro de notas fiscais... 48 Tabela 12 Tabela de cadastro de Receitas... 49 12
1. INTRODUÇÃO Os municípios brasileiros, ainda, de forma morosa, vêm informatizando a disponibilidade de acesso aos serviços administrativos na Internet. Segundo o IBGE (Instituto Brasileiro de Geografia e Estatísticas), apenas menos de 10% dos municípios possuem página na Internet disponibilizando serviços a população, onde os mesmo priorizam somente os serviços informativos. Como a economia brasileira tem crescido nos últimos anos (IBGE), é natural que se aumente a prestação de serviços nos municípios brasileiros, refletindo diretamente na economia dos municípios. Conforme define o CTN (Código Tributário Nacional), em seu Artigo 3, Tributo é toda prestação pecuniária compulsória, em moeda ou cujo valor nela se possa exprimir, que não constitua sanção de ato ilícito, instituída em lei e cobrada mediante atividade administrativa plenamente vinculada. Deste modo, toda prestação de serviço remunerado (pecuniário) é passível de Tributação, que para empresas que prestam serviço, recaem o ISSQN (Imposto Sobre Serviço de Qualquer Natureza). O ISSQN, imposto sobre serviço de qualquer natureza, é um imposto de competência municipal, previsto em nossa Carta Magna (Constituição Federal), formando uma das fontes de recurso financeiro dos municípios brasileiros. A cada ano que passa vem aumentando sua importância relativa no computo das receitas municipais, visto o IPTU se tratar de imposto político. Este aumento é, também, decorrente em parte do problema federativo brasileiro, que em suma pode ser resumido em uma maior delegação das obrigações sociais, de segurança pública, infra-estrutura, educação, saúde, etc, aos municípios brasileiros em contrapartida com a menor parte das receitas tributárias obtidas, ou seja, a fatia dessas receitas para os municípios é muito pequena pela gama de obrigações que um município detém. Com isso, a necessidade dos municípios brasileiros trabalharem mais suas receitas próprias é cada vez maior. Neste aspecto o ISSQN é um dos impostos mais difíceis de apuração e controle, por ser resumido em uma obrigação imaterial, prestar serviço, uma obrigação de fazer. Assim, um sistema de controle de imposto arrecadação que faça frente a esta demanda, poderá reduzir a evasão de receitas, por conseqüência aumento na arrecadação. Dessa maneira, um Sistema de Controle de ISSWEB atenderá a diversos interesses, sejam eles públicos ou privados. Tal sistema, todavia, deve ser confiável, versátil e de interface de fácil compreensão e utilização tanto para usuários internos do sistema como externos das prefeituras. Desta forma, deve-se elaborar um sistema confiável e bem planejado. Todavia, para uma boa gestão (dimensionar recursos e prazos adequadamente, 13
reduzir e simplificar a manutenção) é necessário ter em mãos toda uma documentação de um sistema, a fim de evitar vários problemas futuros com atualizações e manutenção, e acima de tudo, reaproveitar o código. Reusabilidade de código está diretamente ligado a um paradigma de programação que é Orientação a Objeto. Para modelagem de um sistema de informação orientada a objeto utiliza-se a conceituada UML (Unified Modeling Language). A UML é composta por muitos elementos de modelo que representam as diferentes partes de um sistema de software, onde o mesmo busca levantar as necessidades e requisitos para seu desenvolvimento e modelagem. Os elementos UML são usados para criar diagramas, que representam uma determinada parte, ou um ponto de vista do sistema. Modelar os requisitos de um sistema simplifica o seu desenvolvimento, norteia um programador. A UML não é um método de desenvolvimento, o que significa que ela não diz o que fazer primeiro e em seguida ou como desenhar o sistema, mas auxilia a visualizar seu desenho e a comunicação entre objetos. Modelagem de requisitos ou Engenharia de Requisitos implica numa visão ampla sobre o produto que se deseja. É fato que, utilizando Engenharia de Requisitos, o desenvolvimento de um sistema tende a reduzir drasticamente problemas relacionados ao desenvolvimento de um software, pois a regra de negócios com complexidades elevadas, com o uso de diagramas UML, fica mais fácil o entendimento do funcionamento do sistema. 14
2. ORIENTAÇÃO A OBJETO 2.1 Visão geral de Orientação a Objetos Segundo Melo (2002), OO (Orientação a Objetos) é a abstração feita por representações do mundo real, cujo descrevem um objeto propriamente dito através de suas peculiaridades, sendo essas representadas através de características físicas próprias ou conceituais bem como seus comportamentos. Já Meilir Page-Jones (2001) considera que, OO possa ser direcionado na direção que quase tudo o que você possa imaginar. Para maior clareza, o autor julga arbitrária a definição do termo, visto que o termo Orientado a Objeto ser desprovido de um significado inerente. Por fim pode-se concluir que, OO é o poder de simplificar/descrever um objeto. 2.2. Conceitos Objeto - Um objeto é qualquer coisa que exista no mundo real, em formato concreto ou abstrato. Os objetos possuem características ou propriedades que são seus atributos, que também podem ser caracterizados por estado, explica Melo (2002, p.15). Além dos atributos, todo objeto possuem operações ou produzem ações que em OO são caracterizados por métodos. Ex.: Rafael, tem 7 anos de idade, criança, gosta de brincar. Idade e criança são seus atributos e brincar é um método (ação). Classe Uma classe é representação de concreta de vários objetos que possuem atributos, métodos e operações em comum entre eles, ou seja, uma classe é uma estrutura onde contém todos os atributos e métodos de um objeto específico, de acordo com Melo (2002, p.17). Na Figura 1 demonstra um objeto e sua classe. Figura 1 - Exemplo de um Objeto instanciado em relação a sua Classe. Herança Herança, de acordo com Melo (2002, p.20), procede do conceito de herdar atributos e métodos de uma classe mais genérica, denominada superclasse ou classe-mãe ou ainda classe-pai para uma classe mais específica, denominada sub-classe 15
ou classe-filho, onde está última contém somente atributos ou métodos especifico. Em outras palavras, pode-se dizer que está referenciando (Figura 2) generalização e especialização. Figura 2 - Herança em notação UML Polimorfismo Significa poder realizar uma mesma tarefa de maneiras diferentes, sem perder sua natureza (Melo, 2002, p.22). Considerando uma superclasse Polígono, onde por herança existam duas sub-classes Quadrado e Retângulo (Figura 3), uma operação CalcularArea, que pode ser comum entre as duas sub-classes pode ser instanciada através das duas produzindo o mesmo efeito. Figura 3 Polimorfismo em UML. 16
3. UML 3.1. Visão de Geral da UML UML, de acordo com PAGE-JONES (2001), é uma linguagem de modelagem que é um padrão adotado pelos OMG entre outras, que, como linguagem, consegue capturar a estrutura de sistemas orientados a objeto em um nível acima das linhas de código, que são formadas de formas expressas em diagramas que englobam a gama de construções que aparecem em sistemas típicos OO. Esses diagramas incluem: diagrama de classe, diagrama de seqüência, diagrama de colaboração e diagrama de estado. Já Melo (2002) procede que, UML é uma linguagem para especificação, visualização, construção e documentação de artefatos (requisitos, arquitetura, projeto, etc) de sistema de software. Com ela pode-se elencar alguns pontos positivos para desenvolvimento de um software com esse padrão: - Permite visualização precisa e dá aos desenvolvedores condições de interpretar os modelos sem ambigüidade; - Auxilia na construção de software, pois permite um mapeamento de seus modelos para as linguagens de programação, ou vice-versa. Assim é possível gerar código a partir de modelos da UML; - Facilita a documentação, pois possui suporte para a criação de documentação de vários artefatos que são gerados durante o desenvolvimento de um sistema, como: requisitos, arquitetura, projeto, código fonte, planos de projeto, teste, protótipos e versões; - Conceituou a unificação de modelagem na Engenharia de Software, baseado na OMT e OOSE e Booch. UML, em outras palavras, tem como finalidade principal tornar mais simples possível o entendimento e absorção de idéias abstratas do mundo real, buscando diminuir a descrições extensas de um objeto e de casos de uso, em representações gráficas para melhor absorção e fácil entendimento para um programador. 17
3.2. Modelagem com UML Para modelagem de sistemas utilizando a UML, existem dois elementos fundamentais para sua construção: blocos de construção e regras de formação. 3.2.1. Blocos de Construção Os blocos se dividem em elementos dos modelos, relacionamento e diagramas. Para compor os diagramas, utiliza-se elementos do modelo e os relacionamentos. - Elementos do modelo São os elementos básicos para a utilização na modelagem de qualquer sistema, como mostra a Tabela 1. Estruturais Classes, interface, colaboração, casos de uso, componentes, nós Comportamentais Interação, estado Agrupamento Pacotes Anotacionais Notas Tabela 1 - Divisão de elementos do Modelo. Classes representa a descrição de um conjunto de objeto em seus atributos, métodos (operações), relacionamento e semântica; Interface especifica as operações extremamente visíveis de uma classe ou componente e não possuem implementação; Colaboração indica as instância e cooperações de elementos que são envolvidos na realização de alguma tarefa; Caso de Uso representa a funcionalidade provida por um sistema. Consiste na descrição de um conjunto ações seqüenciais que serão executadas por um sistema, interagindo com os atores; Componentes corresponde a uma parte significativa de um sistema, que é representada modularmente, de forma totalmente substituível; Nó é um objeto físico existente de tempo de execução que representa um recurso computacional; Interação é um padrão de comunicação com o objetivo de realizar algum propósito; 18
Estado condição de vida de um objeto ou uma interação durante a qual alguma condição executa ação ou espera por algum evento; Pacote é um agrupamento de elementos modelo; Nota é um símbolo gráfico contendo informação textual, que possibilita a representação de informações do tipo restrições, comentários ou restrição. - Relacionamentos São ligações entre os elementos do modelo, podendo ser: dependência, associação, generalização e realização. Dependência é um relacionamento entre dois elementos de modelagem, que indica a mudança que um elemento afetará o outro; Associação é um relacionamento entre dois ou mais classificadores que envolvem conexões entre duas instâncias; Generalização / Especialização é um relacionamento entre um elemento mais genérico e outro mais específico; Realização é um relacionamento entre uma especificação e sua implementação. - Diagramas A UML define 09 (nove) tipos de diagramas, divididos em 02 (duas) categorias: Diagramas Estruturais (Estáticos) e Diagramas Dinâmicos (Tabela 2). Diagramas Estáticos Diagramas Dinâmicos Diagrama de Classes Diagrama de Objetos Diagrama de Componentes Diagrama de Implantação Diagrama de Caso de Uso Diagrama de Seqüências Diagrama de Atividades Diagrama de Colaboração Diagrama de Gráficos e Estados Tabela 2 Tipos de Diagramas. Diagrama de Classes apresenta elementos conectados por relacionamentos. Esses elementos são classes, interfaces e pacotes; 19
Diagrama de Objetos apresenta objetos e valores dos dados. Corresponde a uma instância do diagrama de classes, mostrando o estado de um sistema em um determinado ponto do tempo; Diagrama de Componentes mostra as dependências entre os componentes de software, incluindo implementação das classes, arquivos de códigos-fonte, arquivos de código-binário, arquivos executáveis e scripts; Diagrama de Implantação mostra a configuração dos elementos de processamento em tempo de execução, além dos componentes, processos e objetos do sistema neles existentes; Diagrama de Caso de Uso mostra os casos de uso, atores, e seus relacionamentos que expressam a funcionalidade de um sistema; Diagrama de Seqüências mostra as interações que corresponde a um conjunto de mensagens trocadas entre classes; Diagrama de Atividades é uma variação do Diagrama de Gráficos de Estados, que apresenta a execução de ações ou atividades e as transições que são disparadas pela conclusão de outras ações; Diagrama de Colaboração apresenta a colaboração que contém os papéis representados pelas instâncias e os seus relacionamentos em um determinado contexto; Diagrama de Gráfico e Estado representa ações ocorridas em resposta ao recebimento de eventos; 20
4. DIAGRAMAS ESTÁTICOS 4.1. DIAGRAMA DE CLASSES Um diagrama é uma representação gráfica de um conjunto de elementos e são usados para visualiza os sistema sob diferentes perspectivas, que tem a finalidade de facilitar a compreensão do sistema que está sendo desenvolvido. Diagrama de Classe, corresponde a uma estrutura de um diagrama com seus elementos peculiares referente a OO, ou seja, a classe propriamente dita. Tal diagrama além de possuir as classes e seus elementos, consigo traz também o seguintes elementos: relacionamentos, generalizações, agregações, associações e pacotes utilizados para agrupar elementos. Vale salientar que, Diagrama de Classe representa estruturas estáticas das classes integrantes ao sistema. 4.1.2 Visibilidade A visibilidade identifica por quem uma propriedade (atributos ou operação) pode ser utilizada. Visibilidade define o modo ou método de acesso que cada atributo ou método de uma classe terá (Melo,2002). Com isso, pode-se definir um nível maior ou não de segurança aos dados e execução dos métodos, aumentando a confiabilidade do sistema. A visibilidade é definida por palavras chaves ou caracteres coringas, de acordo com a Tabela 3. + ou public (público) A propriedade será vista e usada dentro da classe na qual foi declarada, em qualquer elemento externo e nas classes descendentes. - ou private (privado) A propriedade será vista e usada apenas dentro da classe na qual foi declarada. # ou protected (protegido) A propriedade será vista e usada dentro da classe na qual foi declarada e nas classes descendentes. ~ ou package (pacote) A propriedade será vista e usada por elementos que estejam declarados dentro do mesmo pacote no qual está inserida a classe que a declarou. É como a visibilidade pública, só que não generalizada a qualquer elemento, mas apenas elementos externos localizados no mesmo pacote. Tabela 3 Propriedades de Visibilidade 21
4.1.3. Multiplicidade Multiplicidade indica uma cardinalidade permitida a um elemento mostrando a quantidade de instâncias possíveis em um relacionamento entre classes, ou seja, é a quantidade de objetos totais que pode-se obter de uma classe em relação a uma outra diretamente relacionada (Melo,2002). A especificação deve ser feita como mostra a Tabela 4. * Muitos 0..1 Nenhum ou Um 0..* Nenhum ou Muitos 1..* Um ou Muitos 2..4 Dois até Quatro Tabela 4 Representação de Multiplicidade 4.1.4. Relacionamentos Em modelagem de sistemas, quando trabalhamos com classes, elas colaboram umas com as outras através de relacionamentos e, poucas vezes uma classe não possui em relacionamento com uma outra. Em Diagrama de Classes existem três tipos de relacionamentos, de associação, generalização e dependência. 4.1.4.1. Associação Associação é um relacionamento que conecta duas (associação binária) ou mais classes (ternário ou de ordem-n), demonstrando colaboração entre as classes (Melo,2002). Associação binária consiste em associar apenas duas classes, podendo ser consigo mesmo. A Figura 4 mostra associações onde aluno está associado a Disciplina, onde um Aluno cursa Disciplina. Já a outra associação demonstra que em uma Empresa possui Funcionário que possui Chefe que também é Funcionário. Figura 4 - Representação de Associação Binária. 22
Associação ternária ou n-ária consiste em associar ou relacionar três ou mais classes, por meio de uma forma geométrica (losango) ligada através de suas extremidades. Na Figura 5 é exibida uma associação ternária onde um possui instrumentos e pode tocar em bandas. Figura 5 - Representação de Associação Ternária. Ainda em Associação, destacam-se alguns elementos que ajudam a melhorar na compreensão do Diagrama de Classe, cujo são opcionais, mas esses rótulos devem ser usados para simplificar e ajudar melhor a compreensão, e deve-se conter o uso demasiado para não tornar a modelagem poluída e confusa. Para isso, serão citadas apenas dois conceitos básicos, Nome da Associação e Multiplicidade. Nome da Associação indica papel ou ação inerente a ou que uma classe diretamente associada, e deve ser colocada acima da linha de relacionamento, facultando a direção da ação, conforme mostrado na Figura 6. Figura 6 - Representação de Associação Ternária. Multiplicidade São rótulos colocados nas extremidades do caminho da associação, identificando o numero máximo e mínimo que uma classe pode relacionar, ou seja, a quantidade de instanciações que uma classe pode relacionar a outra. Exemplo: Considerando que músico pode ter nenhuma banda ou quantas ele conseguir tocar e que uma banda deve ser composta pelo menos por dois músicos, em multiplicidade seria da seguinte maneira: Um músico possui nenhuma ou várias bandas e Uma banda possui dois músicos ou vários músicos, como mostra a Figura 7. Figura 7 - Representação de Multiplicidade em uma Associação. 23
4.1.4.2. Generalização Como dito anteriormente é a partir de um objeto genérico que se consegue obter outros objetos mais específicos em suas particularidades distintas, como mostra a Figura 8. O Diagrama de Classe mostra graficamente de forma estática, o conjunto de classes ligadas entre si através de associações. Em generalização, quando se trata de UML, isso é demonstrada através de uma associação com um triângulo na ponta em direção a classe mais genérica. 4.1.4.3. Dependência Figura 8 Representação de Generalização Esse tipo de relacionamento, como segue na Figura 9, ocorre entre duas classes e existe quando a mudança na interface de uma delas afeta a outra. Para melhor entendimento, segue alguns casos onde ocorrem dependência entre classes. 1 Ocorre quando há troca de mensagens entre classes; Ex.: Uma classe AgendaConsulta(A) necessita da classe HorarioMedico(H). Mudanças na interface dessa classe H pode afetar a classe A. Assim dizemos que a classe A é dependente da classe H. 2 Ocorre quando uma classe tem como atributo outra classe; Ex.: Uma classe Carro possui o atributo Motorista que é uma instância da classe Carro 4.1.4.4. Agregação Figura 9 - Representação de Dependência. Agregação é um relacionamento binário entre classes, cujo objetivo principal é figurar a existência de uma entidade fraca, que para sua existência necessite se relacionar com uma classe onde ela está contida, determinando uma finalidade a ela (Melo,2002). 24
Se considerar uma roda e, em seu contexto ela não está caracterizada como uma entidade, sua existência estará diretamente ligada a uma outra classe, conforme Figura 10. Figura 10 Representação de Agregação. 4.1.4.5. Composição Composição nada mais é que uma variação de agregação, entretanto, a partir do momento de seu relacionamento, começa a interpretar como um objeto composto de partes, e também a classe pertence só e somente só a classe como todo, não podendo fazer parte de outro relacionamento de composição (Melo,2002). Ao definir uma classe como parte de uma composição, fica indicado no relacionamento que perdeu sua identidade, pois é parte incorporada da outra classe, como demonstra Figura 11. Figura 11 Representação de Composição. 25
4.2. DIAGRAMA DE OBJETOS Esse diagrama nada mais é que uma instanciação do Diagrama de Classes em um determinado ponto de tempo, segundo Melo (2002, p.125), facilitando o entendimento do Diagrama de Classe, ou seja, para um Diagrama de Classe existente existirá um Diagrama de Objeto para que se possa trabalhar com dados reais, além da estrutura da Classe. Um diagrama de objeto auxilia o desenvolvedor na identificação de problemas na execução de aplicações, mapeando os objetos que estão sendo manipulados, juntamente com suas relações. Esse diagrama possui uma a visão sobre todas as classes que foram determinadas durante a construção das classes, impedindo problemas futuros por má implementação das classes do projeto, identificado durante a análise. Representa-se graficamente o diagrama de objeto justamente similar ao diagrama de classe, com o nome do objeto seguido por qual classe ela é denominada juntamente com seus atributos. No diagrama de objetos, diferentemente das classes, não é esboçado os métodos pertencentes à classe. Sua notação consiste da seguinte maneira: nome_do_objeto:nome_da_classe por exemplo GunsnRoses:Banda Para representação dos atributos, deve-se seguir a seguinte notação: nome_do_atributo = valor_do_atributo por exemplo guitarrista = Slash Para que se possa fazer relacionamento entre objetos em seu diagrama deve-se utilizar links. Um link é a instância de uma associação. Segundo definição de Melo (2002, p.127), em um link podem-se mostrar o nome de associação, entretanto, as multiplicidades não existem, pois a mesma já são instâncias, da mesma forma que se pode definir agregação, composição, navegação e qualificadores, cujo podem ser mostrados ao final de cada link. Na Figura 12, apresenta um diagrama de objetos, tomando com base um diagrama de classe, para melhor ilustrar o teor e a idéia de um diagrama de objeto: 26
Figura 12 - Representação de um Diagrama de Classe. No diagrama da Figura 13 mostra uma classe Músico relacionado a classe Banda. Figura 13 - Representação de um Diagrama de Objetos. No diagrama de objeto (Figura 19) mostra justamente a relação entre os objetos com multiplicidade simples, onde objeto Slash que é músico, denominado guitarrista que de acordo com o diagrama de classe, toca na banda Guns n Roses. Note que a esse diagrama facilita na análise do requisito, não deixando nenhum dado duvidoso, pois é relacionado ao mundo real (abstração), servindo também para revisão de modelo. 27
4.3. DIAGRAMA DE IMPLEMENTAÇÃO Diagramas de implementação (Melo, 2002) mostram aspectos de implementação física, incluindo estrutura de componentes e a estrutura do sistema em tempo de execução (run time). São expressos de duas maneiras: Diagrama de componentes e Diagrama de implementação. Esses diagramas podem, também, ser aplicados na modelagem de negócios, no qual os componentes representam artefatos e procedimentos de negócio e os nós de implantação representam a organização de unidades e recursos (humanos e outros) do negócio. 4.3.1. Diagrama de Componentes Diagrama de componentes (Melo, 2002) mostra a estrutura de componentes, incluindo os classificadores que eles especificam e os artefatos que eles implementam, ele mostra as dependências entre componentes de software, incluindo os classificadores que eles especificam e os artefatos que eles implementam (código fonte, código binário, executáveis, scripts). Este diagrama representa tipo e não instância, sendo que este é representado pelo Diagrama de Implantação. O diagrama de componentes é um gráfico de componentes que representa conexões por relacionamento de dependência. Componentes podem ser conectados a outros componentes físicos representando relacionamento de composição. Classificadores que especificam componentes podem ser conectados a eles por compartimentos físicos ou por um relacionamento estereotipado <<reside>>, e também, artefatos que especificam componentes podem ser conectados a eles por compartimentos físicos ou por um relacionamento estereotipado <<implement>>. Um diagrama contendo tipo de componentes pode ser usado para mostrar dependências estáticas, como as dependências de compilação entre programas, que são representadas por setas tracejadas de um componente cliente para um componente fornecedor que depende dele de alguma maneira. Um diagrama pode mostrar interface e a chamada de dependência entre componentes. 4.3.2. Componente Um componente (Melo, 2002) representa um módulo físico, implementável e substituível, corresponde a uma parte de um sistema. Um componente encapsula a sua implementação e exibe um conjunto de interfaces. 28
Um componente não possui atributos nem operações. Um componente age como container para outros classificadores que são definidos com propriedades. São tipos de componente: os necessários para execução de um sistema (script,.exe,.dll), arquivos de código-fonte, etc. Componente é esboçado no diagrama através de um retângulo grande (Figura 14), contendo dois pequenos sobrepostos. Figura 14 Representação de Componente. 4.3.3. Diagrama de Implantação Diagrama de implantação (Figura 15) mostra a configuração de elementos de processamento em tempo de execução e os componentes de software, processos e objetos que são executados sobre eles. Um diagrama de implantação é um gráfico de nós conectados por associações de comunicação. Os nós podem conter instâncias de componentes, implicando que um componente é executado dentro deles. Componentes são conectados a outros componentes por meio de dependência. 4.3.4. Nó Figura 15 Representação de Diagrama de Implementação. Um nó é um objeto físico que representa um recurso de processamento. Os nós incluem dispositivos de computação, mas também recursos humanos ou de processamento mecânico. Nós são representados como tipo e como instâncias. 29
Graficamente é representado por um cubo. As normas de apresentação do nó com seu tipo são similares com a apresentação de objetos, conforme demonstra a Figura 16. Figura 16 Representação de Nós. Uma instância tem um nome e um nome de tipo. Sua sintaxe é: Nome: tipo-do-nó A palavra <<deploy>>, quando acompanha relação de dependência, mostra a capacidade de um tipo nó suportar um tipo componente. 30
5. DIAGRAMAS DINÂMICOS 5.1. DIAGRAMA DE CASO DE USO Uma das grandes vantagens da UML é representar graficamente todas as necessidades levantadas junto ao usuário, para que assim possa se evitar a ambigüidade e ao desvio de interpretação por parte dos desenvolvedores de sistema no que se refere à produção, construção ou alteração de um software. A grande dificuldade para que se possa fazer um software computacional de qualidade é fazer com que se consiga interpretar a idéias mais destorcidas do usuário, transformando-a em uma linguagem estruturada compreensível, intuitiva e livre de ruídos. Para tal necessidade, existe o Diagrama de Caso de Uso. 5.1.1. O Que é? Conforme definição de Melo (2002, p.46), um Caso de Uso ou Use Case (Figura 17) descreve uma seqüência de ações que representam em cenário principal (perfeito) e cenários alternativos, com o objetivo de demonstrar o comportamento de um sistema (ou parte dele), através de interações com atores. O Caso de Uso deve descrever uma rotina bem definida do sistema e deve ser totalmente compreensível tanto para a equipe de desenvolvimento quanto para os clientes que detêm o conhecimento do domínio do Sistema. Figura 17 - Representação de Caso de Uso. O Diagrama de Caso de Uso são elaborados durante ou após o levantamento dos requisitos / necessidades do sistema que estará em questão, e também será considerado o alicerce para construção de outros diagramas relacionados a UML. Esse diagrama, tem como objetivo fundamental a separação das funcionalidades do sistema que, além de sua representação gráfica, deverá conter as descrições da cada Use Case, que será separada em dois tipos de cenários, o Principal e o Alternativo. 31
Cenário Principal: descreve uma seqüência de ações que serão executadas considerando que não haverá nenhum erro durante a seqüência; Cenário Alternativo: descreve uma seqüência de ações alternativas ao fluxo principal, considerando os erros ocasionados por esta. Esse cenário é considerado as exceções e são representadas por subitem ao item do cenário principal. Para a construção da Descrição dos Eventos ou Fluxo de Eventos, a mesma deve conter, além dos Cenários supracitados, outros elementos obrigatórios para sua Estruturação, sendo eles: Nome do Caso de Uso, Objetivo (Resumo das Funcionalidades), Pré-condição e Ator(es). Em suma, estrutura-se uma Descrição de Caso de Uso da seguinte maneira: 1. Nome do Caso de Uso; 2. Objetivo; 3. Pré-condição ou requisitos; 4. Ator; 5. Cenário/Fluxo Principal; 6. Cenário/Fluxo Alternativo Ainda, Caso de Uso é uma representação de seqüências de ações, conforme definido acima, que recebem e enviam informações, cujo algo ou alguém externamente deve mandar e receber. Os responsáveis por essa troca de informações num sistema modelado em UML são denominados atores. 5.1.2 Atores Um ator (Melo 2002) representa um conjunto de papéis exercido por um usuário do sistema ao interagir com um determinado Caso de Uso. Cada ator não significa expressamente uma pessoa específica que irá interagir com o sistema, mas sim em sua qualificação, como por exemplo, Secretária. Quando é especifica Secretária como um ator, não esta se referenciando uma Secretária específica, mas sim qualificando que um usuário ou pessoa determinada interagirá com o sistema. As entidades externas representadas como atores podem ser descritas em: Pessoas: ser humano qualificado conforme determinado sua função (aluno, funcionário, gerente, etc), cujo geralmente é intitulado usuário; Dispositivos: é qualquer equipamento externo. Ex.: Impressora; Hardware: qualquer parte integrante física do PC integrante ao Sistema. Ex.: Placa de Rede; 32
Software: qualquer sistema legado que tenha relação ao sistema em questão Ex: SGBD, Aplicativos externos, etc; Figura 18 - Representação de Atores. Um ator (Figura 18) é uma peça fundamental para a diagramação da Use Case, pois o mesmo interage ativamente com cada Use Case identificada na descrição e levantamento dos requisitos. Entretanto, deve-se atentar a parte que, existem atores que não precisam ser explicitados na Use Case, como por exemplo, teclado e mouse, mas sim os que fazem interação ativa com o sistema e de forma genérica, não determinando nome ao ator mas sim sua intitulação, ou seja, não deve-se colocar o nome do usuário, como por exemplo Robert, mas sim funcionário, ou caixa. 5.1.3 Levantamento de Requisitos / Necessidades Uma das etapas mais importantes e fundamentais para uma diagramação em UML é o Levantamento de Requisitos junto ao usuário. Levantamento de requisitos nada mais é que uma ou mais entrevista com o(s) conhecedor (es) da(s) regra(s) do negócio, onde será descrito o comportamento do sistema. Pode-se dizer que essa não é uma fase fácil, pois o projetista deve extrair o máximo de informações coerentes e prioritários para que o sistema atenda plenamente as necessidades do usuário. O levantamento dos requisitos exige muito de quem o faz, pois o mesmo deve buscar um texto pouco extenso e muito estruturado, para que seja feita uma proposta de solução e apresentação de um sistema cheio de ambigüidades e comandos repetitivos e extensos, mas sim definição das necessidades do usuário. Para que seja bem estruturado e não haja retrocesso no processo, o desenvolvedor deve sempre visitar seu cliente. A partir de um levantamento e análise, o desenvolvedor deve modelá-lo e documentá-lo em uma linguagem e estrutura de tal maneira a apresentá-lo ao cliente, para entendimento entre as partes. 33
5.1.4. Casos de Uso e Atores Casos de Uso são seqüências de ações ou funcionalidades que não podem trabalhar sozinha no sistema. Sendo assim, um Caso de Uso é relacionado por atores ou outros Casos de Uso, pois não faria sentido a existência de uma Use Case sem relacionamento ou ligação a outra entidade. Para tanto, existem 04 (quatro) tipos de relacionamentos, que são: Associação, Generalização, Extensão e Inclusão. 5.1.4.1. Associação (Association) Associação é a forma de interação entre ator e o Caso de Uso, simbolizando a comunicação entre as parte (Figura 19). Esse tipo de relacionamento só poder ser feita apenas entre atores e casos de uso (Melo,2002). Figura 19 - Representação de uma Associação. 5.1.4.2. Generalização (Generalization) O conceito de generalização nada mais é que a partir de um objeto genérico consegue se obter outros objetos mais específicos em suas particularidades distintas. Este tipo de relacionamento ocorre entre casos de uso ou entre atores (Melo,2002), conforme demonstra na Figura 20. Figura 20 - Representação de uma Generalização. 34
5.1.4.3 Extensão (Extend) Extensão (Figura 21) é um tipo de relacionamento que indica que uma Use Case terá um procedimento acrescido ou entendido por uma outra Use Case, indicando uma especialização, exceção ou obrigatoriedade da Use Case base, utilizando a palavra chave extend (Melo,2002). Figura 21 - Representação de Inclusão. 5.1.4.4. Inclusão (Include) Inclusão é um tipo de relacionamento que indica que será copiado um procedimento de uma Use Case base, cujo devem ser utilizados na existência de ações para mais de uma Use Case, evitando cópia ou reescrita de códigos idênticos, facilitando no desenvolvimento, na modelagem e implementação quanto na manutenção do sistema (Melo,2002), conforme demonstrado na Figura 22. Figura 22 - Representação de Inclusão. 35
5.2. DIAGRAMA DE INTERAÇÃO Um diagrama de interação (Melo, 2002) mostra as interações por meio de uma visão dinâmica do sistema. Tal diagrama pode representar um sistema propriamente dito ou um subsistema, classe ou cenário de um caso de uso, que utilizam-se com maior freqüência, no ultimo citado. Por si só, um diagrama de interação, demonstra as comunicações entre os objetos, relacionando-se também com atores (use case). Um diagrama de interação é formado basicamente por objetos, relacionamentos e mensagens, podendo ser representado por duas formas: diagramas de seqüência e diagrama de colaboração. 5.2.1. Diagrama de Seqüência O diagrama de seqüência enfatiza a seqüência de mensagens dentro de uma linha de tempo, onde os objetos (atores e classes) trocam informações entre si. Este é um diagrama que demonstra interações. O diagrama de seqüência (Melo, 2002) demonstra como são realizadas as interações entre objetos, através de forma seqüencial. Esse diagrama enfatiza as mensagens, dentro de uma linha de tempo, às comunicações dos objetos. A melhor forma de se estruturar tal diagrama é através de uma use case, por meio ou através de sua descrição. Para ilustrar ou estruturar graficamente um diagrama de seqüência, existem os seguintes elementos que são: linha de tempo ou de vida, mensagens, ativação e objeto. Linha de tempo é representado por uma linha tracejada na vertical até o fim do diagrama, indicando o tempo de vida do objeto dentro de um determinado período de tempo. Mensagem identifica as operações que está sendo chamada, acompanhada de seu nome, são transmitidas de um objeto para outro, partindo de uma ativação e acionando outra na linha de vida. As mensagens devem ser numeradas para representar a seqüência da ação. o Tipos de mensagens Síncronas - esse tipo indica que o objeto que enviou a mensagem fica em espera aguardando a resposta ou conclusão do pedido de execução (ativação), de maneira que sua ativação permanece ativa durante sua espera, podendo ser encerrado após a resposta, cujo é obrigatório. É representada por uma seta tracejada; 36
Assíncronas esse tipo indica que o objeto envia a mensagem a outro objeto e prossegue sua execução, podendo ser finalizado, sem depender do objeto destino; Auto chamada é uma chamada recursiva, onde o objeto chama a si próprio através de uma mensagem. Esse tipo de mensagem é utilizada para representar condições (if / else) e laços (while / for / do while). Ativação corresponde ao período de tempo durante o qual um determinado procedimento de um objeto está sendo executado. Essa ativação é mostrada graficamente como um retângulo fino e comprido, que tem sua parte superior alinhada ao final da seta (mensagem), ativada e se estende até o final do processamento; Objeto é representado por um retângulo alinhado ao corpo do diagrama a sua parte superior, contendo seu nome. A Figura 23, mostra o exemplo de um diagrama de seqüências. Figura 23 - Representação de um Diagrama de Seqüências. 5.2.2. Diagrama de Colaboração O diagrama de colaboração (Melo, 2002) enfatiza o relacionamento estrutural entre os objetos, sem se preocupar com tempo determinado para cada interação. O diagrama é 37
semelhante ao de seqüência, com uma particularidade, não se tem a visualização temporal dos eventos, tornado-o menos estruturado. Os objetos são distribuídos no diagrama na ordem similar a do diagrama de seqüência, obedecendo à seqüência de mensagens. A colaboração entre objetos é representada por uma ligação simples, acompanhado de uma numeração seqüencial com condições e operações, como mostra a Figura 24. Figura 24 - Representação de um Diagrama de Colaboração. De uma forma geral, diagrama de colaboração é um diagrama de seqüência sem a linha de vida, com estrutura gráfica diferente, mas com a mesma finalidade. 5.3. DIAGRAMA DE GRÁFICO E ESTADO Os diagramas de gráfico e estado descrevem o comportamento de objetos como reação a eventos discretos, por meio de seqüências de estados e ações que ocorrem durante a vida. Esse diagrama tem por objetivo mostrar uma máquina de estados, cujo consiste num comportamento que específica à seqüência de estado de um objeto durante sua vida, em resposta a eventos, junto com suas responsabilidades e ações. 5.3.1. Estado Um estado é uma condição ou situação existente na vida de um objeto durante a qual satisfaz alguma condição, executa uma atividade ou espera por algum evento, cujo graficamente é representado por um retângulo com seus cantos arredondados e em seu centro sua descrição (Figura 25). 38
Figura 25 Exemplo de estados. Opcionalmente, podem ser subdivididos em sua descrição, em compartimento de nome e de transições internas. Compartimento de nome contém / armazena o nome do estado. Compartimento de transições internas contém / armazena lista de ações que são executadas enquanto apresenta um estado. Além do mais, apresenta expressões identificadora às circunstâncias sobre a ação associada. Uma transição interna não modifica o estado do objeto. Existem algumas palavras reservadas que representam transições internas. entry identifica uma ação que é executada na entrada do estado; exit - identifica uma ação que é executada na saída do estado; do identifica uma atividade atual durante o estado; include invoca uma submáquina, com nome ligado a expressão. Estas expressões identificam o evento que dispara a expressão correspondente associada. O formato geral para qualquer item é: Nome do evento(lista de parâmetros separada por vírgula)[condição de guarda]/expressão ação. Na Figura 26 é demonstrado um exemplo de estado. Figura 26 Exemplo de estado com compartimento de transições internas 5.3.1.1. Estado Inicial e Estado final Estado inicial (Figura 27) indica o início na máquina de estado ou subestado. É representado por um círculo preenchido. 39
Figura 27 Exemplo de estado inicial. Estado final (Figura 28) indica o fim das execuções da máquina de estado. É representado por um círculo preenchido envolvido por círculo não preenchido. Figura 28 Exemplo de estado inicial. 5.3.2. Transições Transição (Figura 29), para Melo (2002, p.160) é um relacionamento entre dois estados indicando que houve uma mudança de estado, e determinadas ações serão executadas. A mudança de estado que ocorre através da transição, só será realizado a partir do momento em que um evento específico ocorreu, garantindo que condições foram satisfeitas. A transição é disparada somente quando ocorrer mudanças de estado. Sua representação gráfica é feita através de uma linha sólida com uma flecha de destino, identificando estado de origem atingindo estado de destino. Transição é identificada com o seguinte formato: Assinatura do evento [condição-de-guarda] / expressão ação. formato: - Assinatura-do-evento descreve um evento com seus argumentos, no seguinte Ex: Checar Estoque (PROD). 40
- Condição de guarda indica condição para tomada de decisão, que quando verdadeiro, dispara o início da transação. Podem haver várias transições a serem disparadas, cujo serão apenas aquelas que forem verdadeiras. Ex: [valor >=0] - Expressão ação somente é executada no início da transição, se esta ocorrer. Podem ser escrita com operações, atributos e links do objeto proprietário da máquina de estados. Ex: DataPagamento:=DataPgamento + 3 Figura 29 Exemplo de Transição. 5.4. DIAGRAMA DE ATIVIDADES O diagrama de atividade (Melo, 2002) é um diagrama que esboça as ações e estados de uma atividade em um sistema, saindo de um estado, que após sua conclusão, assume outro. Vale lembrar que para sair de um estado ou ação, o mesmo deve estar satisfeito por completo, ou seja, assumirá o próximo estado quando de sua conclusão ou definição, podendo referenciar a si próprio. Este diagrama tem por propósito fundamental focalizar um fluxo de atividade que, ocorre internamente em um processamento, dentro de um período de tempo. 5.4.1. Modelagem com Diagrama de Atividades Na modelagem de um diagrama de atividades, existem alguns símbolos e elementos para sua composição. Os símbolos para sua construção são dados na Figura 30: 41
Figura 30 Representação dos Símbolos do Diagrama de Atividades Já os elementos que compõem o diagrama são: Estado de Ação, Estado de Transições, Decisões, Intercalação, Bifurcação. 5.4.1.1. Estado de ação Um estado de ação ilustra o estado de uma ação de um processo inerente a atividade a ser executada, ou seja, é uma forma de modelagem de um passo específico da execução de um processo. Um estado é descrito, geralmente, através de verbo, indicando a ação executada ou a ser executada. Estado de ação é uma forma geométrica retangular com as pontas arredondadas, como demonstra a Figura 31. Figura 31 Representação de Estado de ação. 5.4.1.2. Transições Uma transição indica o fluxo de um estado de ação a outro, representado, graficamente por uma seta direcionada a outro estado de ação, ligando o estado de origem ao estado de destino ou a uma decisão, mostrado na Figura 32. 5.4.1.3. Decisões e Intercalação Figura 32 Representação de Transição. Uma decisão (Melo, 2002) ou desvio é indicado no diagrama de Atividades para desviar ou executar uma ação alternativa, dependendo das situações no momento da transição entre um estado e outro. Ele faz a separação de uma transição de entrada de 42