daniel c. de oliveira filho um passo a passo …oliveira filho, daniel c. um passo a passo para...
TRANSCRIPT
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 Professora Simone
Sawasaki Tanaka.
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 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. RATIONAL UNIFIED PROCESS - RUP .......................................................... 19
2.2. WORKFLOW ......................................................................................................... 25
2.2.1. 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ós-
graduaçã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 Elemento Gráfico
Evento Um evento é representado por um circulo e é
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 exibir o fluxo de
mensagens entre dois 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 Descrição Elemento Gráfico
Pool 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.
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 Descrição Elemento Gráfico
Objeto Dados 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 – Booch-
seguido 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, pode-
se 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.