Daniel C. de Oliveira Filho UM PASSO A PASSO PARA A ELABORAÇÃO DO DIAGRAMA DE CASO DE USO DA UML LONDRINA 2011 DANIEL C. DE OLIVEIRA FILHO UM PASSO A PASSO PARA A ELABORAÇÃO DO DIAGRAMA DE CASO DE USO DA UML Monografia entregue à Banca Examinadora do Curso de Pós-Graduação em Engenharia de Software com UML do Centro Universitário Filadélfia de Londrina - UniFil como requisito parcial para obtenção do Título de Engenheiro de Software sob a orientação do Professor Sérgio Akio Tanaka e co-orientadora Sawasaki Tanaka. LONDRINA 2011 Professora Simone DANIEL C. DE OLIVEIRA FILHO UM PASSO A PASSO PARA A ELABORAÇÃO DO DIAGRAMA DE CASO DE USO DA UML Monografia entregue à Banca Examinadora do Curso de Pós-Graduação em Engenharia de Software com UML do Centro Universitário Filadélfia de Londrina – UniFil em cumprimento a requisito parcial para obtenção do título de Engenheiro de Software. APROVADA PELA COMISSÃO EXAMINADORA EM LONDRINA, 30 DE ABRIL DE 2011 Prof. Sérgio Akio Tanaka, (UniFil) – Orientador(a) Prof.ª Simone Sawasaki Tanaka, (UniFil) – Co-Orientador(a) Prof. Ruy Tsutomu Nishimura, (UniFil) – Examinador(a) Dedico este trabalho a minha família, em especial, aos meus avós João e Alayde Guidugli. Exemplos de caráter e honestidade. AGRADECIMENTOS Aos meus familiares que sempre me apoiaram e me incentivaram de todas as formas para que me tornasse a pessoa e profissional que sou hoje. Aos meus avós João e Alayde Guidugli por me proporcionarem a chance de ter uma profissão e agora o título de Engenheiro de Software. Por me mostrar o valor e o peso da palavra família. Obrigado pela confiança e pelas oportunidades que me foram concedidas. Meu eterno carinho e gratidão. A minha esposa Karla Gonçalves de Brito por ser essa pessoa maravilhosa e compreensiva que faz tudo valer a pena. Obrigado por me deixar fazer parte da sua história de vida. Ao meu filho Caio Brito de Oliveira pela paciência e compreensão pelos finais de semana sem passear e pelas horas trabalhando e estudando em casa. Meus agradecimentos. A minha mãe Cássia Rossana Guidugli pelas palavras de incentivo e motivação. Pessoa exemplo de superação que acreditou no meu potencial e me mostrou o caminho quando a direção era incerta. Meu muito obrigado. A minha tia Silvana Guidugli pela disponibilidade do tempo cuidando do Caio. Meus agradecimentos com imenso carinho. A minha irmã Andréia Guidugli, minha prima Ana Paula Guidugli e minha cunhada Kamila Gonçalves de Brito por me ajudarem direta ou indiretamente no que fosse preciso. Muito obrigado. A Deus, por ter me iluminado em mais uma jornada e, finalmente, a todos que, de uma forma ou de outra, me ajudaram a chegar até aqui. Muito obrigado. “A única coisa que separa um homem do que ele quer da vida normalmente é simplesmente a vontade de tentar aquilo e a fé para acreditar que aquilo é possível.” (RICHARD M. DEVOS) OLIVEIRA FILHO, Daniel C. UM PASSO A PASSO PARA ELABORAÇÃO DO DIAGRAMA DE CASO DE USO DA UML, 50fls. Londrina, 2011. Trabalho de Conclusão do Curso de Pós-Graduação em Engenharia de Software com UML do Centro Universitário Filadélfia de Londrina - UniFil, Londrina, 2011. RESUMO O trabalho tem como objetivo demonstrar um passo a passo para elaboração do diagrama de Caso de Uso da UML. Serão demonstrados quais os artefatos de entrada necessários para modelagem do diagrama em questão, os passos a serem seguidos e quais os produtos de trabalho gerados ao final do processo. Palavras chaves: UML, Workflow, Modelagem; ABSTRACT The work aims to propose workflows that demonstrate the process to create the Use Case diagram of UML Will be showed what the artifacts are required for modeling the diagram, the steps to be followed and what work products are generated at the end of the process. Key words: UML, Workflow, Modeling. LISTA DE FIGURAS Figura 2.1: Funções do Arquiteto de Negócio ...................................................... 21 Figura 2.2: O Rational Unified Process (RUP) ..................................................... 21 Figura 2.3: Modelo Espiral de Barry Boehm ........................................................ 22 Figura 2.4: As fases e os marcos de um projeto ................................................... 22 Figura 3.1:Representação gráfica do caso de uso Efetuar Pedido ......................... 42 Figura 4.1: Processo para criação de diagramas de caso de uso ............................ 45 Figura 4.2: Diagrama de caso de uso do estudo de caso ....................................... 47 LISTA DE TABELAS Tabela 1: Objetos de Fluxo .................................................................................. 30 Tabela 2: Objetos de Conexão ............................................................................. 31 Tabela 3: Objetos Swimlanes ............................................................................... 31 Tabela 4: Elementos do tipo Artefatos ................................................................. 32 Tabela 5: Relação entre disciplinas do RUP e artefatos ........................................ 48 LISTA DE ABREVIATURAS E SIGLAS BPD Business Process Diagram BPMN Business Process Modeling Notation BPMI Business Process Management Initiative OMG Object Management Coalition RSA Rational Software Architect RUP Rational Unified Process UML Unified Modeling Language WfMC Workflow Management Coalition WWF Windows Workflow Foundation XP Extreme Programming SUMÁRIO INTRODUÇÃO .................................................................................................................. 12 1.1. OBJETIVOS ............................................................................................................ 14 1.1.1. OBJETIVO GERAL ............................................................................................ 14 1.1.2. OBJETIVOS ESPECIFICOS .............................................................................. 15 1.2. METODOLOGIA ................................................................................................... 15 2. FUNDAMENTAÇÃO TEÓRICA .......................................................................... 16 2.1. PROCESSO DE DESENVOLVIMENTO DE SOFTWARE ................................ 18 2.1.1. 2.2. 2.2.1. RATIONAL UNIFIED PROCESS - RUP .......................................................... 19 WORKFLOW ......................................................................................................... 25 BPMN ................................................................................................................... 27 2.3. LINGUAGEM DE MODELAGEM UNIFICADA – UML.................................... 31 2.4. CONSIDERAÇÕES FINAIS .................................................................................. 33 3. ESTUDO DE CASO ................................................................................................ 35 3.1. DIAGRAMA DE CASO DE USO........................................................................... 36 4. WORKFLOWS PARA CRIAÇÃO DE DIAGRAMAS DA UML ........................ 42 4.1. PROCESSO PARA MODELAGEM DO DIAGRAMA DE CASO DE USO ....... 42 4.2. CONSIDERAÇÕES FINAIS .................................................................................. 45 5. CONCLUSÕES E TRABALHOS FUTUROS ....................................................... 47 REFERENCIAS BIBLIOGRÁFICAS .............................................................................. 48 INTRODUÇÃO As linguagens de modelagem orientada a objeto apareceram em algum momento entre meados da década de 70 e começo da década de 80, tornando-se uma abordagem alternativa de análise e projeto. O número de metodologias orientado a objetos aumentou de menos de 10 para mais de 50 durante o período entre 1989 e 1994. Muitos usuários desses métodos tiveram problema para encontrar uma linguagem de modelagem que supria todas as suas necessidades. Entre essa “Guerra de Metodologias” começaram a se destacar como mais notáveis Booch, Object Oriented Software Engineering (OOSE) de Jacobson e o Object Modeling Technique (OMT) criado por Rumbaugh. Cada um desses como um método completo embora sendo reconhecido que todos possuíam pontos fortes e fracos. Foi quando em meados de 1990 Grady Booch, Ivar Jacobson e James Rumbaugh unindo as idéias de cada método criaram o que mais tarde seria a linguagem unificada de modelagem orientada a objetos mais utilizada no mundo a UML (BOOCH, 2005). A Unified Modeling Language (UML) é uma linguagem padrão para a elaboração da estrutura de projetos de software. Ela poderá ser empregada para a visualização, a especificação, a construção e a documentação de artefatos que façam uso de sistemas complexos de software (BOOCH, 2005). Embora a UML ofereça uma vasta lista de artefatos, notações e padrões para a documentação de um projeto de software permitindo ao Analista, Engenheiro, Programador abstrair todo o conceito do sistema, a tarefa em si se torna um problema se a equipe de análise não tiver bem definido o roteiro, ou seja, algum tipo de processo para se criar toda a documentação. Cada empresa pode desenvolver seu próprio workflow para documentar seus projetos levando-se em consideração vários aspectos, entre eles: tecnologias de desenvolvimento; qualificação da equipe; magnitude e escopo do projeto e tipo de processo utilizado na empresa. Além dos profissionais que trazem na bagagem experiências anteriores de desenvolvimento de sistemas e processos de negócio, existem os alunos de graduação e pósgraduação que estão estudando a UML muita das vezes pela primeira vez e que precisam aprender e entender de uma forma significativa e não mecânica todos os conceitos envolvendo a linguagem de modelagem unificada. Um workflow consiste em uma seqüência de passos conectados entre si que demonstram a execução de um trabalho ou processo real desenvolvido por pessoas, máquinas ou qualquer tipo de entidade envolvida no processo. O termo workflow foi usado primeiramente de uma forma mais moderna na indústria de software, sintetizando o que seria uma automação do processo de negócio. Vislumbrando o grande potencial da tecnologia grandes empresas como Microsoft estão investindo em desenvolver ferramentas e máquinas de workflow que possam ser utilizadas na criação e gerenciamento de qualquer tipo de processo de negócio. Até mesmo um padrão de notação de processos de negócio foi criado na intenção de se tornar o processo visível independente de plataforma ou recurso utilizado. Ele foi chamado de Business Process Modeling Notation (BPMN). Uma empresa de software bem-sucedida é aquela que fornece um produto de qualidade capaz de atender as necessidades dos respectivos usuários. Uma empresa que consiga desenvolver esse software de maneira previsível e em determinado período, com utilização eficiente e eficaz de recursos, será uma empresa com um negócio viável (BOOCH, 2005). A modelagem é uma parte central de todas as atividades que leva à implantação de um bom software. Construímos modelos para comunicar a estrutura e o comportamento desejados do sistema. Construímos modelos para visualizar e controlar a arquitetura do sistema. Construímos modelos para compreender melhor o sistema que estamos elaborando, muitas vezes expondo oportunidades de simplificação e reaproveitamento. Construímos modelos para gerenciar os riscos (BOOCH, 2005). Dentre as dificuldades enfrentadas pelas empresas que desenvolvem software podemos destacar algumas: finalizar o produto no prazo estipulado durante o planejamento; não ultrapassar o orçamento previsto para o projeto; entregar ao Stakholder o produto ou serviço desejado, fruto do investimento. Possíveis motivos seriam: o mau planejamento; requisitos fracos; falta de um processo de desenvolvimento de software que possa direcionar tanto a equipe quanto os gerentes de projeto a estabelecer metas e diretrizes para o desenvolvimento; falta de um meio de comunicação comum entre os envolvidos, uma zona neutra entre a equipe de negócios e a equipe técnica para que ambas “conversem” entre si utilizando uma só forma de representar cada ponto de vista relevante ao projeto. Pensando-se em aumentar a produtividade, organização, melhorar o planejamento e qualidade, foram criados os processos de desenvolvimento de software. Existem no mercado vários processos voltados ao desenvolvimento de sistemas onde os mesmos são adotados por diferentes empresas de todos os tamanhos. Destacam-se entre eles: o Scrum e o Extreme Programming (XP) como formas de processos ágeis e o Rational Unified Process (RUP), um processo robusto, iterativo e incremental, que poder ser utilizado em projetos de pequenos e também em projetos de grande porte. Como forma de documentar o produto desenvolvido no processo a UML vem sendo amplamente utilizada como padrão de modelagem de sistemas e adotada em vários processos de desenvolvimento. Ela utiliza uma notação para que se possa demonstrar graficamente toda a arquitetura do sistema proposto. Tanto de uma visão estrutural quanto comportamental. Um método que demonstre um passo-a-passo de como modelar os diagramas do sistema utilizando a notação da UML poderá auxiliar não só profissionais que atuam no mercado de trabalho em projetos dentro das empresas, mas também alunos em projetos acadêmicos desenvolvidos em sala de aula ou como trabalhos de conclusão de curso. Como forma de demonstrar os passo do processo será utilizado um workflow que fará uso de padrões de notação para representar graficamente o processo proposto de modelagem dos diagramas. Sistemas de workflow são amplamente utilizados por empresas para criar uma linha lógica de um processo de negócio a ser seguido por pessoas, máquinas ou sistemas computacionais. Podendo o mesmo gerar um produto final palpável ou somente gerenciar documentos e rotinas de trabalho. 1.1. OBJETIVOS Os objetivos da pesquisa são elencados a seguir. 1.1.1. OBJETIVO GERAL Demonstrar em forma de passo-a-passo como pode ser modeladoo diagrama de Caso de Uso da UML, quais artefatos de entrada são necessários e quais produtos de trabalho são gerados ao final do processo, auxiliando profissionais e estudantes a abstrair um sistema computacional e representá-lo graficamente utilizando padrões universalmente adotados. 1.1.2. OBJETIVOS ESPECIFICOS a) identificar os artefatos de entrada e saída do diagrama proposto pelo trabalho; b) propor um processo e modelagem do diagrama utilizando a notação da UML; c) agregar valor ao processo de desenvolvimento mantendo o projeto do sistema documentado. 1.2. METODOLOGIA a) estudo da UML e dos diagramas propostos; b) estudo do BPMN e Workflow; c) aplicação do processo a um estudo de caso. Os capítulos seguintes farão uma breve introdução aos assuntos abordados na pesquisa passando pela fundamentação teórica, seguindo pela proposta de um estudo de caso e encerrando com a aplicação pratica do processo resultante do trabalho. O capítulo dois representa os principais conceitos utilizados na pesquisa em questão. Será feita uma explanação sobre processos de desenvolvimento de software tendo como foco o Rational Unified Process (RUP), seguindo pela explicação em síntese do que são workflows e padrões de notação BPMN, encerrando com a uma explanação resumida do que seria a UML. No capitulo três será abordado um estudo de caso. Este mesmo estudo de caso será utilizado pelo processo proposto. O objetivo de se trabalhar um estudo de caso é facilitar a compreensão e ver na prática toda teoria proposta até então. A demonstração do processo utilizando o estudo de caso citado acima estará a cargo do capítulo quatro que unindo um exemplo da vida real com o processo fruto da pesquisa demonstrará como poderá ser modelado o mesmo diagrama do capítulo três, mas agora seguindo uma linha lógica de execução. 2. FUNDAMENTAÇÃO TEÓRICA O software é o combustível dos negócios modernos, com o qual se conectam melhor controles governamentais e sociedades. O software nos ajudou a criar, acessar e visualizar a informação de formas anteriormente inconcebíveis. Globalmente, o passo surpreendente do progresso em software ajudou a direcionar o crescimento da economia mundial. Numa escala mais humana, os produtos de software intensivos ajudaram a curar o doente e deram voz ao mudo, mobilidade ao debilitado e oportunidade ao incapacitado. De todas essas perspectivas, o software é uma parte indispensável de todo mundo moderno (BOOCH, 2005). Diferentes projetos de desenvolvimento de software falham de formas diferentes – e, infelizmente, muitos deles falham – mas é possível identificar vários sintomas comuns que caracterizam esses tipos de projetos: incompreensão das necessidades do usuário final; inabilidade para lidar com requisitos variáveis; módulos que não se ajustam; software difícil de manter ou estender; descoberta tardia de sérias imperfeições do projeto; baixa qualidade de software; os membros da equipe um no caminho do outro, tornando impossível reconstruir quem mudou o quê, quando, onde e por quê; um processo de construção e lançamento indigno de confiança. Algumas causas de origem são comuns entre projetos que não atingem seus objetivos: gerenciamento inadequado de requisitos; comunicação ambígua e imprecisa; arquiteturas frágeis; complexidade subjugada; inconsistências não detectadas em requisitos, construções e implementações; teste insuficiente; avaliação subjetiva de status do projeto; deficiência para risco de ataque; propagação de mudança incontrolada; automação insuficiente. Com a proposta de serem aplicadas melhores práticas ao desenvolvimento de software foram criados os Processos de Desenvolvimento de Software. Empresas bem sucedidas chegaram a um consenso após inúmeros projetos no que diz respeito a melhores práticas, são eles: desenvolvimento iterativo; gerenciamento de requisitos; arquitetura e uso de componentes; modelagem visual; qualidade de processo e produto; gerenciamento de configuração e mudança. Processos de desenvolvimento como o RUP abordam essas e outras boas práticas em seu modelo. Criando um ambiente onde se possa documentar, organizar e compartilhar documentos e produtos de trabalho e também definir papéis e tarefas de cada envolvido. A sessão 2.1.1 irá abordar os conceitos propostos pelo RUP. Seguindo a linha de raciocínio envolvendo as melhores práticas citadas anteriormente encontra-se à modelagem visual do sistema que seria a representação gráfica, baseada em uma notação, da abstração do projeto. Tanto do ponto de vista estrutural quanto do comportamental. Reconhecida mundialmente a Unified Modeling Language (UML) é adotada como padrão para modelar sistemas. A UML não está vinculada a nenhum processo de desenvolvimento. Ela tem como função e objetivo fornecer uma notação que represente objetos e seus relacionamentos, comportamentos, ligações como sistemas externos, etc. Ficando a cargo do profissional ou da empresa definir quais diagramas serão criados dependendo do processo utilizado ou metodologia de trabalho. Uma introdução e alguns exemplos de diagramas da UML serão demonstrados na seção 2.1.4. A terceira tecnologia abordada na pesquisa será o workflow. Apesar de o termo estar sendo amplamente utilizado em áreas de reengenharia de processos, onde empresas estão buscando através da implantação de rotinas padronizadas, melhorar seus processos de negócio, pode-se também utilizar essa tecnologia para criar novos processos. A idéia por trás do workflow é se definir passos que seguem uma linha lógica de tarefas a serem executadas que tem como objetivo executar um trabalho, resultando ou não em um produto acabado. Sistemas de workflow são amplamente utilizados por empresas que tentam implantar padrões em suas rotinas de trabalho. Como exemplo de workflow poderia citar uma linha de montagem automotiva. O objetivo é entregar no final da linha de montagem um carro montado e pronto para exercer sua função oferecendo segurança e conforto aos seus condutores e passageiros. Cada passo do processo envolve um grupo de pessoas treinadas para executar tal tarefa destinada aquele passo. Começando pela montagem da carroceria e partes mecânicas, seguindo para estofamentos e acabamentos internos até a montagem do motor e encerrando com a fiscalização e aprovação. Todo esse processo pode ser definido com um sistema de workflow. Tarefas são atribuídas, monitoradas e avaliadas constantemente podendo a qualquer momento ser alterado o curso do fluxo baseado em tomadas de decisões. Desde a movimentação de um documento até a logística de fabricação de entrega de um produto. As seções seguintes abordarão assuntos que fizeram a base deste trabalho. Iniciando por processos de desenvolvimento de software, passando por workflows e sua notação BPMN e encerrando com UML. 2.1. PROCESSO DE DESENVOLVIMENTO DE SOFTWARE Durante o ciclo de vida de desenvolvimento de um software inúmeras são as influencias de cada participante. Gerentes de projetos, arquitetos, investidores, desenvolvedores são apenas alguns dos papéis existentes em um projeto. Para que se tornar possível administrar todos esses recursos empresas adotam diferentes tipos de processos de desenvolvimento. Esses processos são estudados e desenvolvidos por engenheiros de software que compilam informações de empresas bem sucedidas do ramo e propõe a comunidade uma metodologia que possa de alguma forma organizar e orientar a equipe durante o ciclo de vida de um projeto. Algumas dessas propostas já estão consolidadas no mercado, é o caso do Rational Unified Process (RUP), Scrum, Extreme Programming (XP). As duas últimas como metodologias ágeis. Cada processo pode gerar um conjunto específico de produtos de trabalho dependendo do escopo do projeto, pois é possível se personalizar o framework do processo conforme a necessidade da equipe e a dimensão do projeto. A seção seguinte tratará do processo unificado criado pela Rational. Um processo iterativo e incremental desenvolvido visando as melhores práticas utilizadas na engenharia de software. 2.1.1. RATIONAL UNIFIED PROCESS - RUP O Rational Unified Process é um processo de engenharia de software. Ele fornece uma abordagem disciplinada para assumir tarefas e responsabilidades dentro de uma organização de desenvolvimento. Seu objetivo é assegurar a produção de software de alta qualidade que satisfaça as necessidades de seus usuários finais dentro de um prazo e orçamento previsíveis (KRUCHTEN, 2003). Desenvolvido e mantido pela Rational o RUP é um processo iterativo e incremental de desenvolvimento de software, podendo cada empresa se adequar ao modelo conforme a dimensão e escopo do projeto. Profissionais de desenvolvimento de software que trabalham como parte de uma equipe de projeto, incluindo os investidores desses projetos e profissionais de engenharia de processo são os principais interessados em utilizar o processo unificado. Baseado nas funções propostas pelo RUP de cada envolvido no projeto é possível se definir quais produtos de trabalho e tarefas cada papel terá que desenvolver ou realizar. A estrutura proposta pelo RUP permite que as equipes possam colaborar e manter organizado toda a documentação do projeto, sendo definidas estruturas lógicas baseadas em cada disciplina. Um exemplo seria criar uma estrutura para fase de Iniciação, responsável por manter documentos de levantamento de requisitos, documento visão, solicitações do Stakholder entre outros. A Figura 2.1 demonstra o papel do Arquiteto de Negócio proposto pelo RUP. Como em outras atribuições ficam definidas quais as responsabilidades, que entre outras no caso do arquiteto de negócio são: Análise de Arquitetura de Negócio e Análise da Área Funcional e como produto de trabalho seus respectivos documentos. Figura 2.1. Funções do Arquiteto de Negócio (IBM, 2007). O ambiente de processo oferecido pelo RUP é em sua essência um conjunto de práticas coletadas da engenharia de software que são continuamente aprimoradas. Alguma dessas inclusive compartilhadas por outros processos de desenvolvimento de software. No RUP o processo possui duas dimensões. O eixo horizontal representa o ciclo de vida do processo e o eixo vertical que demonstra as disciplinas essenciais para o desenvolvimento do software. O modelo do processo é demonstrado na Figura 2.2. No eixo horizontal ficam visíveis as fases que vão de iniciação, passando pela elaboração, construção e transição. Em cada fase é possível se determinar os marcos entre as iterações. Na dimensão vertical ficam as disciplinas que demonstrando as atividades pertinentes ao desenvolvimento do sistema. Figura 2.2. Rational Unified Process (RUP) (IBM, 2007). O objetivo do processo é fazer com que cada iteração resulte, ao passar por todas as disciplinas, um lançamento executável. Dessa forma pode-se identificar, por exemplo, possíveis defeitos de construção, requisitos fracos e possíveis riscos para o projeto durante uma fase inicial, permitindo ao gerente do projeto tomar decisões e direcionar a equipe durante a próxima iteração. A Figura 2.3 representa este ciclo de iterações conhecido como Modelo Espiral de Barry Boehm baseado em um modelo iterativo e incremental. Figura 2.3. Modelo Espiral de Barry Boehm (IBM, 2007). Ao final de cada fase são definidos os marcos com objetivos específicos. A avaliação destes marcos define se os objetivos propostos para a fase foram alcançados permitindo que o projeto avance. As fases poderiam ser definidas como o intervalo de tempo entre os marcos. A Figura 2.4 demonstra os marcos durante o ciclo de vida do projeto. Figura 2.4. As fases e os marcos de um projeto (IBM, 2007). Existem princípios essenciais de um processo de desenvolvimento de software eficiente são eles: desenvolver uma visão: o artefato visão captura requisitos de nível muito alto e restrições de design, para fornecer ao leitor um entendimento do sistema a ser desenvolvido. gerenciar para o plano: um plano de desenvolvimento de software reúne as informações necessárias para gerenciar o projeto. Ele é utilizado para fazer o planejamento do projeto e planejar as necessidades de recursos e para acompanhar o progresso do planejamento. mitigar riscos e rastrear problemas relacionados: é essencial identificar e combater os itens de risco mais alto no inicio do projeto e acompanhá-los, juntamente com outros problemas relacionados. A lista de riscos foi projetada para capturar os riscos percebidos para o sucesso do projeto. examine o caso de negócio: o caso de negócio fornece as informações necessárias, de um ponto de vista de negócios, para identificar se compensa ou não investir no projeto. projete uma arquitetura de componente: no RUP, a arquitetura de um sistema de software é a organização ou estrutura dos componentes significativos do sistema que interagem por meio de interfaces com componentes constituídos de componentes e interfaces sucessivamente menores. Quais são as partes principais? E como elas se ajustam juntas? Temos uma estrutura na qual o restante do software pode ser incluído? progressivamente construir e testar o produto: o RUP é uma abordagem iterativa de criação, de teste e de avaliação de versões executáveis do produto, a fim de afastar os problemas e resolver os riscos e as questões o mais cedo possível. acessar resultados regularmente: a comunicação aberta contínua com dados e objetivos originados diretamente de atividades em andamento e as configurações do produto em desenvolvimento são importantes em qualquer projeto. Avaliações regulares de status fornecem um mecanismo para endereçar, comunicar e resolver problemas de gerenciamento, problemas técnicos e riscos do projeto. Além de identificar os problemas, é necessário designar a cada um deles uma data de expiração e uma pessoa responsável pela resolução. gerenciar e controlar alterações: assim que o primeiro protótipo for colocado diante dos usuários, as alterações serão solicitadas. Para controlar essas mudanças e gerenciar eficazmente o escopo do projeto e as expectativas dos investidores, é importante que todas as mudanças em quaisquer artefatos de desenvolvimento sejam propostas por meio de controles de mudanças e gerenciadas com um processo consistente. implementar um Produto Utilizável: a finalidade de um processo é produzir um produto utilizável. Todos os aspectos do processo dever ser adaptados considerando essa meta. O produto é normalmente mais do que apenas o software. No mínimo, deve haver um guia do usuário. dependendo da complexidade do produto, os materiais de treinamento também poderem ser necessários. adotar um processo que se ajuste ao projeto: é essencial que seja escolhido um processo que se ajuste ao tipo de produto que está sendo desenvolvido. Mesmo depois que um processo é escolhido, ele não deve ser seguido às escuras – o bom senso e a experiência devem ser aplicados para configurar o processo e as ferramentas para atender as necessidades da organização e do projeto. Quando se utiliza um processo de desenvolvimento que possa aplicar na prática os princípios acima citados as chances de sucesso com o projeto sofrem um aumento considerado. Esses princípios foram estabelecidos por grandes empresas do ramo e adotados como boas práticas do desenvolvimento de sistemas. Conforme explicado anteriormente o RUP prevê um desenvolvimento iterativo que utiliza uma linha de vida para o projeto dividida em fases e outra onde se ocorrem às iterações passando por nove disciplinas. Essas disciplinas iniciam na modelagem de negócios e vão até o ambiente. As fases definidas no ciclo de vida de um projeto são: iniciação: a meta dominante da fase de iniciação é atingir o consenso entre todos os investidores sobre os objetivos do ciclo de vida do projeto. elaboração: a finalidade principal é criar uma baseline para a arquitetura do sistema e fornecer um base estável para o esforço em massa do design e implementação na próxima fase. construção: terceira fase do RUP cuja finalidade principal é concluir o desenvolvimento do sistema baseado na arquitetura. transição: quarta e última fase com finalidade de assegurar que o software esteja pronto para ser fornecido a seus usuários. Deve ser estabelecido para cada fase um número de iterações que ao passarem por todas as disciplinas vão gerar artefatos. Estes artefatos irão incrementar ou até mesmo atualizar o repositório de artefatos do projeto. São nove as disciplinas previstas pelo RUP(IBM, 2007): modelagem de Negócio: fornece orientação sobre diferentes técnicas de modelagem que podem ser utilizadas durante um esforço de engenharia de negócio. requisitos: explica como eliciar os requisitos dos investidores e transformá-los em um conjunto de requisitos de produtos de trabalho, no escopo do sistema a ser construído e fornece requisitos detalhados sobre o que faz o sistema. análise e design: explica como transformar os requisitos dos produtos de trabalho em produtos de trabalho especificando o design do software que o projeto desenvolverá. implementação: explica como desenvolver, organizar, testar a unidade e integrar os componentes implementados de acordo com as especificações do design. teste: fornece orientação sobre como avaliar a qualidade do produto. implantação: descreve as atividades associadas a garantir que o produto de software esteja disponível a seus usuários. gerenciamento de configuração e mudança: explica como controlar e sincronizar a evolução do conjunto de produtos de trabalho que compõem o sistema de software. gerenciamento de projetos: enfoca o planejamento do projeto, gerenciamento de riscos, monitoramento do progresso e métricas. ambiente: a finalidade da disciplina ambiente é fornecer a organização de desenvolvimento de software com o ambiente de desenvolvimento de software – para processos e ferramentas – que oferecerão suporte à equipe de desenvolvimento. O nível de esforço varia ao longo do tempo. Em iterações iniciais o tempo gasto é maior com requisitos e em iterações posteriores a implementação exige maior atenção. O objetivo do desenvolvimento iterativo é que ao final de cada iteração se tenha um executável para validação dos investidores. O resultado dessa iteração pode alterar ou não o planejamento de iterações previstas no inicio do projeto. Ficando a cargo do gerente de projetos planejar as alterações. O mercado de desenvolvimento de software exige cada vez mais processos que aumentem a produtividade, melhorem organização e controle de documentação além de ser capaz de se adaptar a qualquer tipo de projeto. O RUP pode ser configurado para atender diferentes tipos de projetos, como: soluções de componentes soluções de e-business, soluções orientadas a serviços, projetos pequenos e outros. O escopo do RUP no presente projeto é servir como base para acomodar os artefatos gerados por cada processo proposto. Demonstrando em que fase do processo esse artefato é gerado e em qual disciplina. Na seção seguinte será apresentado o assunto chave da pesquisa. Quando se fala em criar um processo é impossível não falar de workflow. 2.2. WORKFLOW Workflow é a automação total ou parcial de um processo de negócio, durante a qual documentos, informações e tarefas são passadas entre os participantes do processo (WfMC, 1996). A busca por aumento de produtividade e melhoria na qualidade da execução de um processo está fazendo com que empresas de todos os ramos de atividade busquem implementar processos padronizados em seu ambiente de trabalho. Estes processos não dizem respeito somente ao gerenciamento de documentos ou rotinas de trabalho do ambiente formal, mas também podem ser aplicados na melhoria de processos de chão de fábrica por exemplo. Diminuir o desperdício, baixar o custo, conseqüentemente aumentar a margem de lucro estão diretamente relacionados à implantação de um sistema de workflow. Um processo de negócio pode ser resumidamente explicado como um trabalho a ser realizado onde são delegadas tarefas as entidades envolvidas e que o resultado destas ações seja um produto ou objetivo comum. Em um sistema de workflow as mesmas entidades são constantemente monitoradas e avaliadas por seus gestores, podendo-se alterar a direção do fluxo conforme seu andamento. Os primeiros protótipos de sistemas de workflow foram criados nos anos setenta com o objetivo de automatizar processos internos de escritório. Hoje sistemas de workflow são utilizados em uma enorme variedade de situações, desde controles de processo centrados em documentos até aplicações com fluxo de dados (FISCHER, 2009). Workflow é freqüentemente associado com reengenharia de processos de negócio, no que diz respeito à avaliação, análise, modelagem, definição e em subseqüentes implementações operacionais do núcleo do processo de negócio (ou outra entidade de negócio). Embora nem todas as atividades de reengenharia de processos de negócio resultem em implementações de workflow, a tecnologia é freqüentemente a solução apropriada para prover lógicas de procedimentos de negócio (HOLLINGSWORTH, 1995). O conceito de workflow está envolvido com a noção de processo advinda da manufatura e do escritório. Tal noção de processo está relacionada com a busca da eficiência das atividades concentrando-as em rotinas. Essas mesmas atividades são separadas em tarefas bem definidas, papéis, regras e procedimentos (FISCHER, 2009). Com o avanço da tecnologia do workflow surgiu-se a necessidade de criar padrões de notação e técnicas de modelagem. Fundou-se então em 1993 o Workflow Management Coalition(WfMC) responsável por criar e manter padrões referentes à tecnologia de workflow como: terminologia, Workflow API (WAPI) e Workflow Reference Model. Para se modelar um workflow foi criada uma notação específica chamada de Business Process Modeling Notation (BPMN) o qual especifica elementos gráficos e textuais para modelagem do diagrama. Existem inúmeras ferramentas no mercado que utilizam os padrões definidos pela WfMC para modelar workflows. Algumas delas trazem consigo a máquina ou engine que interpreta a modelagem e executa os passos solicitando entrada de dados dos usuários e gerando saídas conforma a lógica definida. Quando empresas adotam esse tipo de tecnologia para modelar seus processos é preciso mais do que simplesmente representá-los graficamente. É necessário que um sistema de workflow gerencie e monitores essas atividades. Esse sistema deve ser capaz atribuir tarefas e direcionar atividades conforme a lógica estabelecida pelo fluxo. Um sistema deve ser capaz de criar instancias do workflow, monitorar e controlar a sua execução em tempo real. A tecnologia de workflow vem evoluindo a cada dia. Ferramentas de modelagem e execução surgem no mercado com novas propostas e maior conectividade com o ambiente de trabalho. Diferentes empresas estão investindo nessa tecnologia desenvolvendo ferramentas de modelagem, engines e incorporando isso a outros produtos. É o caso da Microsoft que possui em seu leque de produtos o Windows Workflow Foundation (WWF) que utiliza a plataforma .NET para criar sistemas de workflow. O conceito envolvendo workflow é extenso e não cabe ao escopo do trabalho. O escopo estabelecido é o de usar o conceito de mapeamento de processos e criar um modelo utilizando a notação padrão. Esse modelo deve propor um processo que gere um produto de trabalho ao final. Para representar os passos do processo são definidas atividades que podem estar associadas a outras atividades, estruturas de condição, pontos de início e fim, artefatos e comentários. Para ilustrar esses passos será utilizada a notação padrão BPMN, assunto da seção seguinte. 2.2.1. BPMN O padrão BPMN foi desenvolvido pelo Business Process Management Initiative (BPMI). A especificação BPMN 1.0 foi publicada em Maio de 2004. Esta especificação representa mais de dois anos de esforços da BPMI Notation Working Group. O objetivo principal do BPMN foi prover uma notação que fosse realmente capaz de ser compreendida por todos os usuários do negócio, desde os analistas de negócio que criaram os primeiros rascunhos do processo até desenvolvedores técnicos responsáveis por implementar a tecnologia que executasse o processo e finalmente para as pessoas que iriam gerenciar e monitorar o processo. Todo workflow pode ser representado por um diagrama denominado Business Process Diagram (BPD), fazendo-se uso da notação definida no padrão BPMN para modelar diagramas que demonstrem o processo e todas as entidades envolvidas. Um BPD é criado utilizando-se elementos gráficos que demonstrem as atividades sendo executadas através de um fluxo. Todo fluxo tem um elemento de início e um ou mais elementos de finalização. As quatro categorias básicas de elementos são: objetos de fluxo; objetos de Conexões; raias (Swimlanes); artefatos. Os objetos de fluxo formam a base de elementos presentes nos diagramas. Os três elementos são listados na Tabela 1. Tabela 1. Objetos de fluxo (WfMC, 2010). Nome Descrição Evento Um evento é representado por um circulo e é Elemento Gráfico alguma coisa que “acontece” durante o curso do processo de negócio. Esses eventos afetam fluxo do processo e normalmente tem uma causa ou um resultado. São três tipos baseados em quando eles afetam o fluxo. Atividade Uma atividade é representada por um retângulo com bordas arredondadas. Uma atividade pode ser atômica ou não atômica. As atividades podem ser tarefas ou Sub-Processos que se distinguem por um sinal de mais centralizado na linha base do retângulo. Gateway Um gateway é representado por um diamante e é usado para controlar divergências e convergências na seqüência do fluxo. Ou seja, ele irá determinar decisões e pontos de união. Marcas internas irão determinar o tipo do comportamento do controle. Para se criar um processo de negócio os objetos de fluxo devem estar conectados entre si, para isso o BPMN prevê três objetos de conexão como mostra a Tabela 2. Tabela 2. Objetos de conexão (WfMC, 2010). Nome Descrição Elemento Gráfico Seqüência do Fluxo È representado por uma linha solida com uma seta solida na extremidade que aponta para a direção do fluxo a ser seguida. Mensagem do Fluxo É representada por uma linha tracejada com uma seta aberta e é usada para mensagens exibir entre o dois fluxo de processos participantes. Associação É representada por uma linha que faz a ligação entre os objetos. Estes podem ser dados, texto, e outros artefatos. Associações são usadas para mostrar entradas e saídas de atividades. Muitas metodologias de modelagem de processos utilizam o conceito de Swimlanes, ilustrado na Tabela 3, como um mecanismo para organizar atividades em uma categoria visualmente separada que ilustra capacidades funcionais diferentes ou responsabilidades. Tabela 3. Objetos Swimlanes (WfMC, 2010). Nome Pool Descrição Um Pool representa um participante em um processo. Ele também age como um container gráfico para particionar um grupo de atividades de outros Pools. Lane Um Lane é uma sub-partição dentro de um Pool. Lanes são usadas para organizar e categorizar atividades. Elemento Gráfico Além dos objetos utilizados para modelar o processo de negócio o BPMN possui elementos que podem ser utilizados para ilustrar um artefato criado em determinado momento, fazer alguma anotação sobre algum objeto do diagrama e também agrupar objetos com o propósito de documentar. A Tabela 4 descreve esses três elementos. Tabela 4. Elementos do tipo artefatos(WfMC, 2010). Nome Objeto Dados Descrição Elemento Gráfico São mecanismos que mostram como dados são requeridos ou produzidos por uma atividade. São conectados às atividades por associações. Grupo É representado por um retângulo com bordas arredondadas desenhado com uma linha tracejada. Anotação São mecanismos para o modelador adicionar textos informativos para o leitor do diagrama. A modelagem de processos de negócio é usada para comunicar uma variedade de informação entre diferentes audiências. A BPMN vem sem consolidando como um padrão para notação de processos de negócio. O desenvolvimento da BPMN é um importante passo para reduzir a fragmentação que existe de ferramentas de modelagem e notações. Estabelecendo-se um padrão os modelos criados por pessoas de negócio serão facilmente interpretadas por sistemas que irão implementar e executar o processo. A BPMN atualmente na versão 2.0 é mantida pela Object Management Group (OMG) que também especifica padrões para UML, Corba, XML, entre outras. Diagramas utilizando a notação BPMN serão demonstrados em todos os processos propostos pelo trabalho. Na seção seguinte será abordada a UML, apresentando resumidamente um histórico e em seguida os diagramas que fazem parte da linguagem. 2.3. LINGUAGEM DE MODELAGEM UNIFICADA – UML A linguagem unificada de modelagem (UML) é uma linguagem gráfica para visualização, especificação, construção e documentação e artefatos de sistemas complexos de software. A UML proporciona uma forma-padrão para a preparação de planos de arquitetura de projetos de sistemas, incluindo aspectos conceituais tais como processos de negócios e funções de sistema, além de itens concretos como as classes escritas em determinada linguagem de programação, esquemas de bancos de dados e componentes de software reutilizáveis (BOOCH, 2005). Com o surgimento de linguagens de programação orientada a objetos nos anos 80, como Smalltalk, Objective C, C++ e Eifeel foram necessários novas metodologias que pudessem modelar aplicações cada vez mais complexas. Foi nesse período que começou o que viria a ser chamado de guerra dos métodos. Muitas metodologias surgiram com o a proposta de atender as necessidades dos usuários e entre eles se destacaram três nomes que viriam a serem mais tarde os criadores da UML. O primeiro deles foi Grady Booch com o método que levava seu nome – Boochseguido por Ivar Jacobson com o Object-Oriented Software Engineering – OOSE e finalmente James Rumbaugh com o Object Modeling Technique – OMT. Cada um deles possuía pontos fortes e fracos apesar de serem muito completos. Foi então que na metade da década de 1990 quando esses métodos eram conhecidos mundialmente como os principais métodos orientados a objeto, que os três autores decidiram criar uma linguagem que unificaria seus métodos. Nascia então a UML. Eles tinham como objetivo fazer a modelagem de sistemas, do conceito ao artefato executável, utilizando técnicas orientadas a objeto. Essa linguagem deveria ser utilizada por homens e máquinas. Em junho de 1996 foi lançada a documentação da versão 0.9 e a partir daí a comunidade da engenharia de software começou a participar ativamente dado feedback sobre a utilização da UML. Algumas empresas vendo o potencial da UML como recurso estratégico para seus negócios criaram um consorcio direcionando recursos para o projeto. As primeiras a participarem foram Digital Equipment Corporation, HP, I-Logix, Intellicorp, IBM, ICON Computing, MCI Systemhouse, Microsoft, Oracle, Rational, Texas Instruments e Unisys. Os esforços resultaram no lançamento da versão 1.0 e que em janeiro de 1997 foi oferecida para padronização ao Object Management Group (OMG). Sob a manutenção do OMG após a versão 1.1 foram lançadas as versões 1.3, 1.4 e 1.5. Após a revisão e atualização da especificação a versão 2.0 foi adotada pela OMG em 2005. Essa é a versão final até então. Para que a UML seja utilizada independentemente do processo de desenvolvimento ou da linguagem de programação foram estabelecidos alguns limites pela OMG. A UML define apenas os elementos de modelagem usados para descrever artefatos do desenvolvimento de software. Metodologias como RUP, Shaler/Melor, Agile Modeling utilizam a UML para documentar seus projetos. A UML é o trabalho de várias pessoas, e as idéias que ali se encontram vêm de muitos trabalhos anteriores. Seria um trabalho importante de pesquisa histórica reconstruir uma lista completa de fontes e ainda mais difícil identificar os muitos precursores que influenciaram a UML, de maneira mais ou menos relevante. Como em qualquer pesquisa cientifica e prática de engenharia, a UML é uma pequena colina sobre uma grande montanha de experiência anterior (BOOCH, 2005). A UML permite que os desenvolvedores de sistemas especifiquem, visualizem e documentem os modelos de maneira que admita a escalabilidade, a segurança e a execução robusta. Como a modelagem UML eleva o nível de abstração por todo o processo de análise e projeto, é mais fácil identificar padrões de comportamento e, portanto, definir oportunidades para recriação e reuso. Conseqüentemente, a modelagem UML facilita a criação de projetos modulares, resultando em componentes e bibliotecas de componentes que agilizam o desenvolvimento e ajudam a garantir a coerência através de sistemas e implantações (PENDER, 2004). Algumas ferramentas de modelagem utilizam os modelos criados para gerar código direcionando para alguma linguagem de programação especifica. O mesmo acontece aplicando-se técnicas de engenharia reversa que a partir do código gera-se o modelo. A UML 2.0 possui 13 diagramas que permitem agrupar elementos e relacioná-los. Dessa forma é possível visualizar um sistema sob diferentes pontos de vista. Esses diagramas podem representar estruturas e comportamentos de um sistema. Os seguintes diagramas estão presentes na UML 2.0: classes, objetos, componentes, estruturas compostas, caso de uso, seqüência, comunicações, gráficos de estado, atividades, implantação, pacote, tempo e visão geral da interação. No presente trabalho serão apresentados os conceitos envolvendo o diagrama de caso de uso. Em trabalhos futuros serão abordados outros diagramas. A UML se consolidou entre a comunidade mundial de engenharia de software como linguagem de modelagem de sistemas orientada a objeto. Inúmeros processos de desenvolvimento utilizam a documentação gerada pela linguagem como artefatos em projetos de software. A cada dia sistemas se tornam mais complexos da mesma forma processos de desenvolvimento se tornam mais ágeis, incorporam novas tecnologias e para acompanhar essa evolução as ferramentas de modelagem devem ser capazes de juntamente com a linguagem e o processo fornecer um ambiente capaz de atender as expectativas dos usuários na hora de se modelar um software. Detalhes sobre a notação do diagrama proposto pelo estudo serão abordados no capítulo 3. 2.4. CONSIDERAÇÕES FINAIS Empresas que desenvolvem software tem em comum o objetivo de produzir um produto utilizável que atenda as expectativas dos investidores e usuários, mas diferentes formas de se chegar a esse resultado influenciam na organização de documentação, planejamento, avaliação de riscos e tomadas de decisão. O uso de um processo de desenvolvimento como Scrum, RUP ou a adaptação de qualquer um deles para o escopo do projeto e da rotina interna da empresa, faz com que o projeto tenha maior chance de chegar ao sucesso. Como parte deste pacote de sucesso cada tecnologia agrega seu valor. A UML especifica a notação e quais os artefatos farão parte dessa documentação. No caso do RUP cada disciplina possui uma lista de artefatos ligados ou não a diagramas da UML que orientam a equipe durante o desenvolvimento do projeto. Outra tecnologia implícita em um processo de desenvolvimento é o workflow. O próprio RUP pode ser interpretado como um workflow que tem seu ponto de início no cruzamento da primeira disciplina com a primeira fase do ciclo de vida do projeto e que continua pelas disciplinas subseqüentes até o término da primeira iteração. Isso acontece em todas as iterações previstas nas fases do ciclo de vida. Todas essas iterações geram documentos, releases ou até mesmo alterações em documentações anteriores por diferentes motivos. Controlar tudo isso se torna uma tarefa árdua para qualquer gerente de projetos. Para isso existem no mercado ferramentas que fornecem soluções para diferentes abordagens do projeto. A IBM oferece uma suíte de ferramentas que vai desde a modelagem, controle de requisitos, gerenciamento de versões até testes, controle de bugs e correções. Essas ferramentas estão ligadas diretamente ao RUP criando um ambiente unificado com orientação a criação de artefatos em cada etapa do projeto. A adoção de um processo de desenvolvimento auxiliado por ferramentas é imprescindível para o sucesso de empresas que desenvolvem software, tudo isso executado e gerenciado por pessoas capacitadas. Existem várias soluções no mercado capazes de atender empresas de todo porte. As seções seguintes darão inicio ao trabalho começando por apresentar o estudo de caso utilizado no processo mapeado, seguindo pelo conceito do diagrama e finalmente ilustrando o processo proposto. 3. ESTUDO DE CASO O trabalho em questão utilizará como base para o diagrama demonstrado um estudo de caso bastante comum entre profissionais que desenvolvem software comercial. De uma maneira bem simplificada será demonstrado um cadastro de pedidos. O cadastro tem como objetivo efetuar o pedido de um ou mais produtos oferecidos pela empresa fazendo uso do relacionamento entre as entidades: Empresa, Vendedor, Cliente, Pedido e Produto. Para modelar um sistema deve-se primeiramente definir quem será o leitor dessa modelagem. Nada impede que sejam feitos vários diagramas que representem a mesma estrutura ou comportamento e que estes tenham diferentes níveis de abstração. Ou seja, podese criar um diagrama de classes que seria apresentado à equipe de desenvolvimento onde o mesmo contenha maior riqueza de detalhes como, por exemplo, informações sobre atributos públicos ou privados que em outra situação ou para outro leitor não tenha relevância. Como o foco do trabalho são alunos que estão tendo o primeiro contato com a UML será adotado como padrão um nível de detalhamento menor, ou seja, serão abordadas as principais características do diagrama e seus componentes. Em trabalhos futuros serão demonstradas todas as opções e possibilidades que a notação da UML oferece para se modelar um sistema computacional. Um diagrama é uma apresentação gráfica de um conjunto de elementos, geralmente representados como um gráfico conectado de vértices (itens) e arcos (relacionamentos). Uma vez que nenhum sistema complexo pode ser compreendido em sua totalidade a partir de uma única perspectiva, a UML define um número de diagramas que permite dirigir o foco para aspectos deferentes de seu sistema de maneira independente (BOOCH, 2005). Cada diagrama possui componentes ou elementos que podem ser específicos para a sua modelagem ou de uso comum em outros diagramas. No caso do diagrama de caso de uso têm-se atores que são representados graficamente pelos famosos bonequinhos e os casos de uso que são as formas elípticas como nome do caso de uso em seu interior. O diagrama de classes por sua vez possui basicamente suas entidades ou classes que são representadas pelo retângulo dividido em três seções. Para demonstrar relacionamentos e associações utilizam-se as linhas que fazem a ligação entre elementos. 3.1. DIAGRAMA DE CASO DE USO O diagrama de caso de uso (Use Case) é um elemento gráfico exclusivo, pois é um diagrama usado para modelar o modo como às pessoas esperam usar um sistema. O diagrama descreve quem serão os usuários relevantes, os serviços que eles exigem do sistema e os serviços que eles precisam oferecer ao sistema (PENDER, 2004). O digrama de caso de uso normalmente é utilizado como parte de uma abordagem dirigida por caso de uso mais abrangente, que também inclui uma criação textual dos casos de uso individuais e a extração de cenários. A descrição textual enfatiza os requisitos detalhados para um caso de uso. Os cenários enfatizam a necessidade de explorar opções na execução do caso de uso, testar os requisitos o oferecer um plano de teste de alto nível para as fases de desenvolvimento subseqüentes (PENDER, 2004). Nenhum sistema existe isoladamente. Todo sistema interessante interage com atores humanos ou autômatos que utilizam esse sistema para algum propósito e esses atores esperam que o sistema se comporte de acordo com as maneiras previstas. Um caso de uso especifica o comportamento de um sistema ou de uma parte de um sistema e é uma descrição de um conjunto de seqüências de ações, incluindo variantes realizadas pelo sistema para produzir um resultado observável de um ator (BOOCH, 2005). Os casos de uso podem ser aplicados para captar o comportamento pretendido do sistema que esta sendo desenvolvido, sem ser necessário especificar como esse comportamento é implementado. Os casos de uso fornecem uma maneira para os desenvolvedores chegarem a uma compreensão comum com os usuários finais do sistema e com os especialistas do domínio. Além disso, os casos de uso servem para ajudar a validar a arquitetura e para verificar o sistema à medida que ele evolui durante o desenvolvimento. A proporção que você implementa o seu sistema, esses casos de uso são realizados por colaboração cujos elementos trabalham em conjunto para a execução de cada caso de uso (BOOCH, 2005). O diagrama de caso de uso é composto por seis elementos: atores, casos de uso, associações, relacionamentos e generalização. ator: um papel desempenhado por uma pessoa, sistema, dispositivo ou mesmo uma empresa, que possui interesse na operação bem-sucedida do sistema. caso de uso: identifica um comportamento-chave do sistema. Sem esse comportamento, o sistema não preencherá os requisitos do ator. Cada caso de uso expressa um objetivo que o sistema precisa alcançar e/ou um resultado que ele precisa produzir. associação: identifica uma interação entre atores e casos de uso. Cada associação torna-se um diálogo que deve ser em uma narrativa de caso de uso. Cada narrativa por sua vez oferece um conjunto de cenários que pode ajudar no desenvolvimento de casos de teste ao avaliar artefatos de análise, projetos e implementação do caso de uso e da associação. relacionamento include (inclusão): identifica um caso de uso reutilizável, que é incorporado incondicionalmente na execução de outro caso de uso. A responsabilidade pela decisão sobre quando e por que usar o caso de uso incluído encontra-se no caso de uso que o chama. relacionamento extend (extensão): identifica um caso de uso reutilizável, que interrompe condicionalmente a execução de outro caso de uso para aumentar sua funcionalidade. generalização: identifica o relacionamento de herança entre atores e entre casos de uso (PENDER, 2004). O objetivo do diagrama de caso de uso é oferecer uma visão externa do relacionamento entre o sistema e o mundo exterior. A simplicidade do diagrama de caso de uso produz pontos fortes e fracos. Um ponto fraco é a falta de explicação. No diagrama de caso de uso, um caso de uso é simplesmente uma elipse com um rótulo como “Transferir Fundos”. Isso não se torna uma definição de sistema adequada. Para enfrentar esse desafio, o diagrama de caso de uso normalmente é acompanhado por um conjunto de descrições de caso de uso, também chamadas de narrativas de caso de uso. Essa narrativa é um exemplo situado de um caso de uso em ação – um único exemplo altamente específico de um ator usando um sistema. Ela não é um caso de uso, e na maioria dos projetos não permanece no documento oficial dos requisitos (COCKBURN, 2005). O seguinte trecho descreve uma narrativa de caso de uso intitulada “Pegando Dinheiro Rápido”: Maria, levando suas duas filhas à creche no caminho do trabalho, dirige até o caixa eletrônico passa seu cartão no leitor de cartões, digita a senha, seleciona Dinheiro Rápido e entra com a quantia de R$ 35,00. O caixa eletrônico libera uma nota de R$ 20,00 e três de R$ 5,00, e mais um recibo mostrando o saldo de sua conta depois que os R$ 35,00 foram debitados. O terminal reseta sua tela após cada transação de Dinheiro Rápido, assim Maria pode sair e não se preocupar que o próximo cliente terá acesso a sua conta. Maria gosta de dinheiro rápido porque ele evita muitas questões que deixam a interação lenta. Pessoas escrevem narrativas de caso de uso para ajudá-las a antever o sistema em uso. Usam-na também para se aquecer antes de escrever um caso de uso, para trabalhar com detalhes. Ocasionalmente, uma equipe publica as narrativas no início de todos os casos de uso ou apenas antes dos casos de uso específicos que elas ilustram. A narrativa não é um requisito; particularmente, ela prepara o terreno para descrições mais detalhadas e generalizadas dos requisitos. A narrativa ancora o caso de uso. O caso de uso é uma forma enxuta de narrativa – uma fórmula – com um ator genérico em vez do nome real usado na narrativa (COCKBURN, 2005). A conclusão é que um diagrama de caso de uso é a representação gráfica que faz uso da notação fornecida pela UML para representar o que seriam as atividades executadas por um ator dentro de um cenário e escopo específicos. Com isso todos os envolvidos no projeto poderiam de uma maneira rápida e resumida ter total noção de como o sistema ou subsistema se comportará e se relacionará com objetos, atores ou interfaces externas. O objetivo do trabalho no que diz respeito ao diagrama de caso de uso é propor um processo para que seja modelado o diagrama. Para isso deve-se levar em consideração que já exista ao menos uma narrativa ou um conjunto de descrições que possa dar direção ao processo de modelagem. Baseado em no estudo de caso que tem o intuito de demonstrar resumidamente o processo em que um vendedor de determinada empresa efetua um pedido de venda de produtos a um cliente, a seguinte narrativa será utilizada no processo de modelagem do diagrama de caso de uso: “João inicia o sistema de controle de pedidos e seleciona a opção Cadastrar Pedido. Faz uma consulta para verificar se o cliente já está cadastrado no sistema. Se não efetua o cadastro e seleciona o mesmo para iniciar o processo de inclusão de produtos do pedido. João seleciona um produto da lista de produtos cadastrados no sistema e informa a quantidade adquirida pelo cliente. Esse procedimento é repetido até que todos os produtos escolhidos pelo cliente estejam incluídos no pedido. Assim que termina de lançar os produtos o vendedor João seleciona a opção Salvar Pedido. O sistema emite a nota fiscal para que o cliente possa pagar no caixa da empresa.” Essa narrativa descreve um fluxo muito simplificado de como seria feito o cadastramento de um pedido onde o cliente informa quais produtos deseja e o vendedor lança os mesmos e já emite a nota fiscal para pagamento. Analisando então a narrativa rapidamente identifica-se o ator e o caso de uso em si. Ou seja, a operação que esta sendo executada e que tem como objetivo realizar um pedido de venda. O Ator (Vendedor) então estaria representando o vendedor João e a operação de efetuar o pedido estaria sendo representado pelo caso de uso Efetuar Pedido. A Figura 3.1 ilustra a representação do caso de uso, o ator envolvido e o relacionamento entre eles utilizando a notação fornecida pela UML. No diagrama em questão nota-se a inclusão de um segundo caso de uso chamado “Verificar Disponibilidade Produto”. Este caso de uso é tratado com um caso de uso de inclusão ou include. Casos de uso de inclusão são utilizados para representar uma operação em que um comportamento já está definido em outra parte do sistema. A opção de verificar disponibilidade do produto é uma operação comum no sistema. Esta mesma operação pode ser chamada em diferentes situações, mas que produz um mesmo resultado que é informar se o produto selecionado está disponível em estoque. Componentes reutilizáveis são exemplos de casos de uso de inclusão. O componente possui as interfaces podendo ser tanto fornecidas quanto exigidas que conforme recebe as chamadas para execução produz o resultado baseado em sua regra de negócio. Figura 3.1. Representação gráfica do caso de uso Efetuar Pedido. Segundo BOOCH(2005) alguns itens são de suma importância para que um diagrama de caso de uso seja bem-estruturado, são eles: tem como foco comunicar um aspecto da visão estática de caso de uso do sistema; contém somente os casos de uso e atores essenciais à compreensão desse aspecto; fornece detalhes consistentes com seu nível de abstração; deverão ser expostos somente os adornos (com pontos de extensão) essenciais à compreensão; não é tão minimalista, que informe mal o leitor sobre a semântica que é importante. São definidas como boas-práticas ao se criar diagramas de caso de uso: dê-lhe um nome capaz de comunicar seu propósito; distribua seus elementos para minimizar o cruzamento de linhas; organize seus elementos espacialmente, de maneira que os comportamentos e papéis semanticamente relacionados apareçam próximos fisicamente; use notas e cores como indicações visuais e chamar atenção para características importantes do diagrama; tente não mostrar muitos tipos de relacionamentos. Em geral, se você tiver relacionamentos de inclusão e estendido complicados, coloque esses elementos em outro diagrama. Até aqui foi abordado resumidamente à teoria que envolve a definição e a modelagem de um diagrama de caso de uso. Foram identificados seus elementos, exemplificado uma narrativa de caso de uso, passando por recomendações de autores consagrados no assunto e encerrando com citações do que seriam boas-práticas ao se criar um diagrama de caso de uso. No capítulo seguinte será apresentado o processo proposto para criação de diagramas de caso de uso. 4. WORKFLOWS PARA CRIAÇÃO DE DIAGRAMAS DA UML A seção seguinte apresentará o passo a passo para criação do diagrama previsto na pesquisa. Ao final da proposta será ilustrado o diagrama resultante da aplicação do processo ao estudo de caso. 4.1. PROCESSO PARA MODELAGEM DO DIAGRAMA DE CASO DE USO Os seguintes artefatos de entrada foram utilizados para modelagem do processo de criação do diagrama de caso de uso: domínio do caso de uso; narrativa do caso de uso. Durante o processo de modelagem serão identificadas ou definidas as seguintes informações baseadas nos artefatos de entrada: identificar os atores envolvidos; identificar componentes reutilizáveis do sistema representando os mesmo como casos de uso de inclusão (include) ou de extensão (extend); definir os relacionamentos; definir as associações; identificar generalizações; Tendo em mãos todas essas informações podemos então modelar o seguinte processo utilizando como notação o BPMN. A Figura 4.1 mostra o processo proposto já modelado utilizando a ferramenta BizAgi Process Modeler. Figura 4.1. Processo para criação de diagramas de caso de uso. Como já citado anteriormente em qualquer diagrama da UML deve-se definir quem será o leitor do diagrama. Tendo isso definido será estabelecido o nível de detalhamento a ser demonstrado no final da modelagem. Como o foco do trabalho em questão são principalmente alunos e profissionais que tiveram pouco contato com a modelagem de sistemas utilizando UML, serão criados processos que definam diagramas com um nível de detalhes básico. O processo para criação de diagramas com maior riqueza de detalhes está previsto para trabalhos futuros baseando-se nos resultados do trabalho de pesquisa atual. A primeira atividade do processo ilustrado na Figura 4.1 tem como rótulo o texto “Identificar os Atores Envolvidos”. Essa atividade assim como todas as outras representadas no processo utilizam a notação BPMN abordada na seção 2.1.3, que determina a representação gráfica utilizando-se um retângulo com um rótulo que transmita com clareza o objetivo da atividade. Para que essa atividade seja concluída deve-se analisar então a narrativa do caso de uso e após identificar o(s) ator(es) representados no diagrama pelos bonequinhos e caso existam podemos adicionar quantos forem necessários. Atores como citado anteriormente são papeis desempenhados por alguém, um sistema ou até mesmo uma empresa que tem interesse em finalizar a operação de forma bem sucedida. A tomada de decisão para se adicionar ou não mais atores ao diagrama é representado pelo terceiro losango amarelo rotulado “Adicionar mais Atores”. Em todo processo estruturas condicionais utilizarão essa mesma simbologia em que uma entrada lógica possa ter uma ou mais saídas. Um recurso disponível para modelagem do diagrama de caso de uso e também utilizado em outros diagramas da UML é a generalização. Podemos utilizar a generalização para refinar as definições de atores. Esse refinamento é realizado tendo em mente o conceito de herança. Esse conceito tem origem nas técnicas de programação orientada a objetos. Trazendo esse conceito para o estudo de caso poder-se-ia, por exemplo, definir um ator Vendedor. Este mesmo poderia ser desmembrado em mais dois atores, o Vendedor Interno e o Vendedor Externo. Entre eles seria criada uma ligação representando a generalização. Essa associação é demonstrada através de uma linha cheia ligando os dois atores e na extremidade dessa linha ligada ao ator que serve de base um triangulo. A decisão de se criar ou não generalizações para atores participantes esta representada no processo pela atividade ”Identificar Generalização” Seguindo ainda a linha lógica de execução são identificados os casos de uso e adicionados ao diagrama informando um nome, lembrando que o nome de um caso de uso deve comunicar seu propósito e que os casos de uso são representados na UML como uma elipse que contém um rótulo interno. Identificar se o mesmo possui alguma associação podendo esta ser com outro caso de uso ou com um ator previamente adicionado. As associações são representadas por uma linha cheia que demonstra a ligação entre dois elementos. Alguns autores utilizam a seta de navegação em uma das extremidades do relacionamento demonstrando a origem e o destino da associação. Não é uma regra e sim uma postura particular de cada um. A opção de rotular a associação também fica a critério do criador do diagrama. A próxima atividade é identificar os relacionamentos em que se envolve o caso de uso, podendo estes serem tanto relacionamentos de inclusão (include) quanto de extensão (extend). Os relacionamentos também são representados por linhas, mas desta vez tracejadas. Diferentemente das associações os relacionamentos obrigatoriamente possuem uma seta de navegação indicando de onde parte e para quem vai a chamada. O rótulo define se é um relacionamento de inclusão ou de extensão. Com isso o leitor consegue ter uma maior clareza do objetivo e dos recursos demonstrados no diagrama. Depois de concluída a atividade que define ou não a necessidade de se criar um relacionamento o processo é encerrado caso a resposta a condição de se incluir outro caso de uso seja não. A proposta do processo demonstrado anteriormente é a de que o aluno ou profissional utilizando qualquer ferramenta de modelagem que adote a notação da UML possa seguir um passo-a-passo e ter como produto final um diagrama de caso de uso modelado em um nível de detalhes básico, mas que consiga representar todos os elementos definidos para esse tipo de diagrama. Ao final do processo será identificado ou gerado um produto de trabalho onde o mesmo terá a denominação de artefato. No processo em questão teremos então como artefato somente o diagrama de caso de uso modelado ilustrado na Figura 4.2. Figura 4.2. Diagrama de caso de uso do estudo de caso. 4.2. CONSIDERAÇÕES FINAIS O estudo de caso utilizado como exemplo para validar o processo é bem simples e não explora todas as possibilidades que a notação oferece. O escopo estabelecido para o trabalho foi o de mapear o processo de modelagem explorando os elementos básicos da notação para que se possa incrementá-los em trabalhos futuros. O terceiro objetivo previsto para o trabalho era o de agregar valor ao processo de desenvolvimento mantendo o projeto do sistema documentado. Para isso contamos com os artefatos que foram gerados depois de mapeado o processo e validado pela aplicação do estudo de caso. O processo teve como produto de trabalho um diagrama da UML. Conforme previsto pelo RUP cada disciplina possui sua lista de artefatos de entrada e de saída. Cabe agora serem definidos em qual disciplina o artefato deve ser acomodado para que se tenha uma estrutura de documentos definida conforme prevê o processo de desenvolvimento. A Tabela 5 relaciona os artefatos com as disciplinas previstas pelo RUP. Tabela 5. Relação entre Disciplina do RUP e Artefato. Disciplina Artefato Requisitos Narrativa de Caso de Uso Requisitos Diagrama de Caso de Uso O RUP prevê a criação de muitos outros artefatos. Cada disciplina possui uma lista extensa de documentos que podem ser criados durante o projeto. Empresas de diferentes tamanhos adaptam essa documentação a sua rotina de trabalho personalizando quais documentos farão parte do seu processo de desenvolvimento. Isso faz do RUP um processo totalmente adaptável. Diferentes ferramentas tanto proprietárias quanto de código aberto fornecem soluções para gerentes de projetos, desenvolvedores e analistas durante o ciclo de vida do projeto. A modelagem de diagramas é apenas uma das atividades propostas pelo RUP durante o ciclo de vida do projeto. Diferentes responsabilidade e papéis são definidos dentro e fora da equipe. Conforme o projeto avança o nível de esforço exigido em cada disciplina é alterado. Caso o resultado da pesquisa demonstre ser viável a adoção de um processo para modelagem de diagramas, o impacto poderá ser medido no quanto de esforço foi economizado nas fases de iniciação e elaboração. 5. CONCLUSÕES E TRABALHOS FUTUROS O estudo foi gratificante tanto pessoal quanto profissionalmente. Aprofundar os estudos em temas como UML e workflow tornou possível a conclusão do trabalho onde foi mapeado o processo para criação do diagrama de caso de uso da UML. Mapear o processo para modelagem do diagrama de caso de uso foi a primeira fase da pesquisa. Em trabalhos futuros o processo será submetido a situações do mundo real para que possa ser validado. Após essa validação o mesmo será portado para máquinas de workflow para que se possa automatizar os passos solicitando apenas entrada de dados do usuário para que ao final do processo se obtenha o diagrama desejado. Outro direcionamento da pesquisa será o meio acadêmico. A idéia é aplicar o processo em sala de aula para alunos iniciantes na UML demonstrando como pode ser criado o diagrama. O impacto será avaliado em quanto do processo foi assimilado pelo aluno. A principal conclusão obtida no que diz respeito ao processo em si é de que não é possível se ter somente um único processo que mapeie todos os recursos definidos pela UML. Poderia servir como tema para trabalhos futuros propor diferentes níveis de modelagem, principalmente por terem diferentes tipos de leitores. São muitos os recursos da notação e podem atender diferentes necessidades do modelador. O RUP permitiu demonstrar em um processo de desenvolvimento em que momento são gerados os artefatos criados pelo passo a passo. Este mesmo processo pode ser auxiliado por ferramentas que gerenciem essa documentação controlando, por exemplo, o versionamento dos mesmos. Todas essas aplicações e conclusões servirão como base para trabalhos futuros de dissertação de mestrado e publicação de artigos em congressos de engenharia de software. Com o feedback da comunidade, profissionais, mestres e doutores a pesquisa poderá ser concluída mostrando a viabilidade ou não de se ter processos definidos para modelagem de diagramas.A adoção ou não da proposta pela comunidade será o termômetro para medir o quanto a pesquisa está sendo útil ou não. REFERENCIAS BIBLIOGRÁFICAS COCKBURN, Alistair. “Escrevendo Casos de Uso Eficazes”, Porto Alegre: Bookman, 2005. KRUCHEN, Philippe. “Introdução ao RUP – Rational Unified Process”, Rio de Janeiro:Editora Ciência Moderna Ltda., 2003. LARMAN, C. “Utilizando UML e Padrões: uma Introdução a Analise e ao Projeto Orientados a Objetos”,Porto Alegre: Bookman, 2007. FISCHER, Layana,. “Workflow Handbook 2002”, Lighthouse Point, FL, USA: Future Strategies, Inc, 2002. MATIAS Pereira, José. “Manual de Metodologia de Pesquisa Científica”, São Paulo: Atlas, 2010. R. Medina-Mora, T. Winograd, and R. Flores, “ActionWorkflow as the Enterprise Integration Technology,” Bulletin of the Technical Committee on Data Engineering, IEEE Computer Society, USA, Vol. 16, No.2, Junho, 1993. PENDER, Tom. “UML, A Bíblia”, Rio de Janeiro: Elsevier, 2004. BOOCH, G; RUMBAUGH, J.; JACOBSON, I.;. “UML – Guia do Usuário”, Rio de Janeiro, Campus, 2ª Edição, 2005.