Definio de requisitos de software baseada numa

arquitetura de modelagem de negcios

DELMIR PEIXOTO

DE

AZEVEDO JUNIOR

Universidade Petrobras

RENATO

DE

CAMPOS

UNESP

Resumo
No uma tarefa fcil definir requisitos para os sistemas de software que daro suporte a um negcio, dada a
dinmica de mudanas nos processos. O levantamento de requisitos tem sido feito de forma emprica, sem o apoio
de mtodos sistematizados que garantam o desenvolvimento baseado nos reais objetivos do negcio. A engenharia
de software carece de mtodos que tornem mais ordenadas e metdicas as etapas de modelagem de negcios e
de levantamento de requisitos de um sistema. Neste artigo apresentada uma metodologia de desenvolvimento
de software resultante da incorporao de atividades propostas para modelagem de negcios e levantamento de
requisitos, baseadas em uma arquitetura de modelagem de negcios. Essas atividades tornam o desenvolvimento
de software mais sistemtico e alinhado aos objetivos da organizao, e podem ser incorporadas em qualquer
metodologia de desenvolvimento baseada no UP (Unified Process - Processo Unificado).

Palavras-chave
Desenvolvimento de software, modelagem de negcios, processo unificado, modelagem de requisitos.

Software requirements definition based

on a business modeling architecture
Abstract
It is not an easy task to define the requirements to software systems that support businesses by reason of the dynamic of changes in business processes. The activity of finding systems requirements has been performed empirically,
without systematic methods that can fulfill business objectives. The software engineering needs methods that become
the activity of finding systems requirements, in a software development process, a more systematic activity. In this
article is presented a software development methodology that integrates activities proposed to business modeling
and requirements definition, based on a business modeling architecture. The activities proposed become the software
development more systematic and focused on the organization objectives, and can be incorporated in any methodology
of development based on the UP (Unified Process).

Key words
Software development, business modeling, unified process, requirements definition.

26

Produo, v. 18, n. 1, p. 026-046, Jan./Abr. 2008

Definio de requisitos de software baseada numa arquitetura de modelagem de negcios

(1998), em Jacobson, Booch e Rumbaugh (1999), e em Lilly

(1999), no existem mtodos estabelecidos que tornem esta
atividade mais sistemtica.
O alinhamento entre requisitos de software e as reais
necessidades de informatizao da empresa pode ser melhorado e sistematizado atravs de tcnicas de modelagem de
negcios (ou de empresa). A tecnologia da orientao a objeto, atravs da UML, permite a integrao da representao
de modelos nos dois domnios, negcio e software. Porm,
existe a falta de metodologias completas que alinhem de
forma sistemtica o levantamento de requisitos de software
s reais necessidades de um negcio, em funo de seus
objetivos (AZEVEDO JR., 2003).

INTRODUO

Quanto mais rpido um negcio puder alterar seus

processos e os sistemas de informao que lhe do suporte, mais preparado estar para reagir a eventos de
concorrncia no mercado. O levantamento de requisitos
a etapa do desenvolvimento de sistemas de informao
responsvel por identicar e modelar as necessidades do
negcio a serem atendidas pelos sistemas de informao,
e , portanto, uma atividade cada vez mais relevante em
um dinmico cenrio.
As organizaes empresariais modernas precisam estar
em constante evoluo para manterem-se competitivas.
So necessrias freqentes reformulaes e inovaes nos
istemas de informaes so os habilitadores
processos de negcio e, conseqentemente, nos sistemas de indo negcio e, portanto, precisam estar
formao que lhes do suporte. A
integrao entre os objetivos do alinhados com os reais objetivos deste negcio.
negcio, os processos de negcio
e sistemas de informao um
Pode-se dizer que o UP como a unio das boas prticas
fator determinante da dinmica necessria organizao
do
desenvolvimento de software base para a denio de
e tambm um desao aos gerentes. Nesse cenrio, os
vrias metodologias encontradas no mercado. Este trabalho
sistemas de informaes so os habilitadores do negcio
descreve uma metodologia resultante da incorporao de
e, portanto, precisam estar alinhados com os reais objealgumas atividades para o levantamento de requisitos baseativos deste negcio. Existem vrios mtodos, tcnicas e
das na arquitetura de modelagem de negcios de Eriksson
ferramentas de modelagem para facilitar o entendimento
e Penker (2000), a m de tornar mais sistemtica esta etapa
e a anlise da complexidade das organizaes moderdo desenvolvimento de sistemas. As atividades propostas
nas (KALPIC; BERNUS, 2002; LI; WILLIAMS, 2002;
podem ser aplicadas em qualquer metodologia de desenVERNADAT, 2002). Essas facilidades so utilizadas na
volvimento de sistemas que se fundamente nos mesmos
tentativa de tornar a realidade organizacional, complexa
princpios estabelecidos no UP.
e abstrata, mais compreensvel. Tambm existem vrias
Em relao metodologia de pesquisa, fundamentoumetodologias para o desenvolvimento de sistemas de
se em extensa reviso bibliogrca; na elaborao e
informao. O que se observa, no entanto, a falta de
descrio de atividades baseadas em uma arquitetura de
integrao da anlise nos dois domnios, o do negcio e o
modelagem de negcios para metodologias de desenvoldos sistemas que lhe fornecero suporte (ODEH; KAMM,
vimento de software; na aplicao das atividades propos2003; SHEN, 2004).
tas na metodologia de desenvolvimento de sistemas de
O UP (Unied Process Processo Unicado) uma das
uma empresa; e em um teste com o desenvolvimento de
metodologias de desenvolvimento de sistemas de software
parte de um sistema de informao, visando a avaliao
que vem obtendo destaque entre as demais. No entanto,
da proposta.
mesmo no UP, a atividade de levantamento de requisitos
Ao longo deste artigo sero propostas atividades de
ainda um processo emprico, no considerando de forma
modelagem
baseadas em uma arquitetura de modelagem
sistemtica a importncia do foco nos objetivos do negcio.
de
negcios,
visando inseri-las de forma integrada em meNeste contexto, evidencia-se a necessidade de maior aprotodologias de desenvolvimento de sistemas de informaes
ximao entre o levantamento de requisitos de sistemas de
baseadas no Processo Unicado (UP), e assim torn-las
softwares e as reais necessidades do negcio em processos
capazes de melhor denir e alinhar, de forma sistemtica, os
ou metodologias de desenvolvimento. No paradigma da
requisitos do sistema aos reais objetivos do negcio. Desta
orientao a objeto, a anlise de requisitos tem sido feita
forma, na prxima seo so apresentadas denies relaticom base num elemento de modelagem da UML (Unied
vas Engenharia de Requisitos e ao UP, exibidos conceitos
Modeling Language) chamado Caso de Uso. Embora exisrelacionados modelagem de processos de negcios com a
tam algumas heursticas propostas para identicao de
UML e questes relacionadas com a identicao de casos
casos de uso, como as apresentadas em Schneider e Winters

Produo, v. 18, n. 1, p. 026-046, Jan./Abr. 2008

27

Delmir Peixoto de Azevedo Junior; Renato de Campos

de uso de negcio. Na seo seguinte so descritas as atividades propostas a serem inseridas em metodologias baseadas
no UP. Aps, so apresentados os uxogramas e descritas
as atividades de toda uma metodologia de desenvolvimento
de software com as atividades propostas, assim como os
artefatos resultantes, e as consideraes nais.

ENGENHARIA DE REQUISITOS E O UP
A engenharia de software se produz atravs de um conjunto de fases. Cada uma das fases pode envolver mtodos,
ferramentas e procedimentos, cujas formas de estruturao
so citadas como modelo de engenharia de software (PRESSMAN, 2002). Ainda segundo Pressman (2002), independentemente do modelo de desenvolvimento de software, o
processo contm trs fases genricas: denio, desenvolvimento e manuteno.
Quatro modelos de engenharia de software tm sido amplamente discutidos: o ciclo de vida clssico (ou cascata),
a prototipao, o modelo espiral e as tcnicas de Quarta
Gerao (PRESSMAN, 2002). Atualmente um novo modelo
tem sido bastante usado: o modelo iterativo e incremental
(JACOBSON; BOOCH; RUMBAUGH, 1999; PAULA
FILHO, 2001).
A anlise de requisitos uma etapa presente na fase
de denio do software, independentemente do modelo
de engenharia de software adotado. Paula Filho (2001)
arma que a engenharia de requisitos formada por um
conjunto de tcnicas empregadas para levantar, detalhar,
documentar e validar os requisitos de um produto de software. Assim, possvel denir a engenharia de requisitos
como um campo da engenharia de software que visa a
aplicao de tcnicas de engenharia em mtodos de anlise
de requisitos, que efetua a ligao entre a necessidade de
informatizao de processos e o projeto do software que
atender a tais necessidades.
No decorrer das duas ltimas dcadas, uma srie de mtodos de anlise e especicao de requisitos foi desenvolvida,
sendo poucas as propostas que visam a sistematizao da
denio de requisitos de forma menos subjetiva (SANTANDER, 2002).
O UP (Processo Unicado) um processo estabelecido
para o desenvolvimento de software resultado de trs dcadas de desenvolvimento e de uso prtico. Jacobson, Booch
e Rumbaugh (1999) apresentam as origens do UP no processo Objectory, que teve sua primeira verso apresentada
em 1987, passando pelas contribuies do Processo Rational Objectory (1997), at chegar ao Processo Unicado
da Rational RUP (KRUCHTEN, 2003). O propsito do
UP, como qualquer outro processo de desenvolvimento,
determinar um conjunto de atividades necessrias para
transformar requisitos em sistemas de software. Neste
28

Produo, v. 18, n. 1, p. 026-046, Jan./Abr. 2008

caso, utiliza a UML como linguagem para a modelagem

dos artefatos de software produzidos ao longo do processo
de desenvolvimento. O UP fundamentado em trs boas
prticas: dirigido por caso de uso, centrado em arquitetura,
iterativo e incremental. Os casos de uso denidos para um
sistema so a base de todo o processo de desenvolvimento.
A partir de uma perspectiva de gerenciamento, o ciclo de
vida de software do UP dividido em quatro fases seqenciais (Concepo, Elaborao, Construo e Transio),
sendo que cada fase refere-se a uma determinada meta a
ser atingida ao longo do desenvolvimento.
Cada uma das quatro fases do UP adicionalmente
dividida em iteraes e nalizada com um ponto de
checagem que verica se os objetivos daquela fase foram alcanados. Toda iterao organizada em termos
de workflows de processo, que so conjuntos de atividades realizadas pelos responsveis pela produo dos
artefatos. Os principais workflows de processo do UP
so Levantamento de Requisitos, Anlise, Projeto, Implementao, Teste e Implantao, sendo que o RUP se
diferencia, principalmente, em relao ao workflow de
Modelagem de Negcio.
A Figura 1, conhecida como Grco das Baleias, exemplica como os workflows podem ser utilizados, com maior
ou menor nfase, em cada fase de desenvolvimento. Nela
podem ser observadas duas dimenses:
O eixo horizontal representa o tempo e mostra os aspectos do ciclo de vida do processo medida que se
desenvolve;
O eixo vertical representa os workflows, que agrupam as
atividades de maneira lgica, por natureza.
A UML foi adotada pela OMG (Object Management
Group) em 1997 como linguagem padro para a modelagem de sistemas orientados a objeto. uma linguagem para
especicao, visualizao, construo e documentao
de artefatos de sistemas de software, como tambm para a
modelagem de negcios e outros sistemas no necessariamente relacionados a software, e representa uma coleo
das melhores prticas de engenharia que comprovaram
bom xito na modelagem de sistemas grandes e complexos (OMG, 1997). Os principais diagramas da UML so:
Diagrama de Classes, Diagrama de Objetos, Diagrama de
Casos de Uso, Diagrama de Seqncia, Diagrama de Colaboraes, Diagrama de Grcos de Estados, Diagrama
de Atividades, Diagrama de Componentes, Diagrama de
Implantao.
A UML tambm permite a ampliao da linguagem de
maneira controlada, atravs de mecanismos de extenso, de
forma a expressar todas as nuances possveis de todos os
modelos em qualquer domnio de anlise (exemplo: anlise
de negcios), fornecendo alguma exibilidade.

Definio de requisitos de software baseada numa arquitetura de modelagem de negcios

MODELAGEM DE PROCESSOS E CASOS DE

USO DE NEGCIOS
Processo de negcio pode ser denido como um conjunto
de atividades conexas que toma um insumo de entrada e o
transforma para criar um resultado de sada. Teoricamente,
a transformao que nele ocorre deve adicionar valor e criar
um resultado que seja mais til e ecaz ao cliente que recebe
o servio ou produto (JOHANSSON et al., 1995). Feliciano
Neto (1996) observa que a grande diculdade encontrada
pelos gerenciadores de projetos de implantao de sistemas
de informao para cumprir cronogramas e levantamento
de custos est relacionada diculdade de delimitao de
contexto do sistema. Decompor a empresa em funes de
negcio, sem se preocupar com uma viso organizacional,
facilita a denio do contexto onde o sistema de informao
ir atuar.
As funes do negcio propostas por Feliciano Neto
(1996) mostram-se, na prtica, como a descrio de processos de negcios. Assim sendo, necessrio que as
metodologias de modelagem de negcios (ou de empresas)
atuais tenham em sua essncia o tratamento baseado em
processos.
Vrias so as tcnicas, metodologias e notaes existentes para a modelagem dos processos de empresas (KOSANKE et al., 1999; KOSANKE; NELL, 1999; SCHEER,
2000; VERNADAT, 1996). No entanto, denir modelos
de negcio uma atividade complexa porque os usurios
tm diferentes necessidades e estas mudam constantemente
(KALPIC; BERNUS, 2002; KIRIKOVA, 2000). Para uma
empresa ser adaptvel a mudanas, necessrio que tenha
uma descrio simples e unicada de suas entidades e, em-

bora este seja o objetivo de muitos esforos para modelagem,

o que se tem ainda hoje uma descrio tipicamente extensa,
inexvel e frgil (MARSHALL, 1999).
A UML (Unified Modeling Language) encontra-se
atualmente consagrada para a modelagem de sistemas de
software e tem sido proposta para a modelagem de empresas
atravs de seus mecanismos de extenso e, segundo a OMG
(1997), esses mecanismos permitem adequ-la a novidades e
domnios especcos. As extenses denidas pelos usurios
na UML se do atravs de esteretipos, valores associados
e restries que coletivamente estendem-na e adaptam-na a
um domnio especco. Nas subsees seguintes so apresentadas trs propostas de extenses para a modelagem de
negcios com a UML, com maior nfase na descrio da
proposta de Eriksson e Penker (2000), j que apresentam um
mtodo mais sistemtico e completo para denir e alinhar os
requisitos de sistemas aos objetivos do negcio.
Proposta da OMG
A OMG (1997), em sua publicao UML extension for
business modeling, descreve uma extenso da UML para a
modelagem de negcios em termos de seus mecanismos de
extenso. O documento, porm, no uma tentativa de descrever completamente os novos conceitos e notaes para a
modelagem de negcios, apenas expe os stereotypes que
podem ser usados para adaptar o uso da UML. J a UML 2.0
apresenta algumas inovaes em relao ao mecanismo de
extenso e modelagem de processos de negcios.
Proposta de Marshall
Marshall (1999) apresenta uma proposta de extenso
da UML para a modelagem de negcios em que sugere um

Figura 1: Relao entre workflows e fases.

Fonte: Adaptado de KRUCHTEN, 2003.

Produo, v. 18, n. 1, p. 026-046, Jan./Abr. 2008

29

Delmir Peixoto de Azevedo Junior; Renato de Campos

metamodelo para identicar e descrever conceitos atravs

dos quais sistemas de negcios so delineados, utilizando a
UML para ilustrar tais conceitos, e prope uma modelagem
baseada em quatro elementos centrais: propsito, processo,
entidade e organizao.

mostra no seu topo um processo de negcio e abaixo

um nmero de pacotes horizontais chamados pacotes de
linha de montagem, cada um representando um grupo de
objetos, que podem ser de uma classe especca ou de
diferentes classes.
Um pacote de linha de montagem um item pacote da
UML estereotipado para <<linha de montagem>> e deseProposta de Eriksson e Penker
nhado como um longo retngulo horizontal, e o diagrama
Eriksson e Penker (2000) propem uma tcnica que
de linha de montagem pode ser usado como tcnica para
estende a UML fundamentada em processos e orientao a
levantamento de casos de uso do sistema ou de sistemas que
objetos para construir arquiteturas de negcios, baseandodaro suporte aos processos de negcio. Um exemplo de um
se no uso de extenses da UML para representar processos,
diagrama de linha de montagem apresentado na Figura 2
recursos, regras e objetivos. Armam que sua tcnica no
em que mostrada a identicao de necessidades de leitudeve ser vista como um conjunto denido de extenses para
ras e gravaes em sistemas existentes e a serem desenvolvinegcios, mas como uma base para que desenvolvimentos
dos, e a conseqente identicao de casos de uso relativos
e adaptaes possam ser feitos (por arquitetos de negcios)
ao processo de negcio Vericao de Documentao. O
para situaes especcas de modelagem.
propsito deste diagrama mostrar
como o processo (na parte superior
UP fundamentado em trs boas prticas: do diagrama) utiliza e gera objetos
na linha de montagem. A referncia
dirigido por caso de uso, centrado em
de um objeto a uma linha de montagem indicada por um uxo de
arquitetura, iterativo e incremental.
objeto (representado por uma linha
tracejada na UML) entre o processo
e o objeto dentro do pacote na linha de montagem. A idenAs propostas de Eriksson e Penker (2000) formam uma
ticao dos casos de uso atravs desta tcnica mostra-se
Arquitetura baseada na linguagem UML para a modelagem
mais adequada, pois faz com que os objetivos dos atores,
de negcios onde podem ser adicionados stereotypes, tage conseqentemente os requisitos do sistema em forma de
ged values e constraints convenientes para cada linha de
casos de uso, estejam alinhados aos objetivos globais do
negcios. Fundamentam-se na hiptese de que um negcio
negcio, j que so analisados com base nos processos de
pode ser modelado atravs de objetos e dos relacionamentos
negcio e estes, por sua vez, foram denidos em funo dos
entre estes, que a arquitetura de modelagem fornece vistas
objetivos do negcio.
para a modelagem com foco em aspectos signicativos e
cada vista pode ser modelada por um ou mais tipos de diagramas. Oferecem as seguintes vistas para a Arquitetura:
Identificao de Casos de Uso do Negcio
Viso do Negcio (Business vision): modela conceitos
A forma de representao e concepo dos processos
e objetivos a serem seguidos de acordo com a estratgia
de negcio no um ponto comum nas propostas de
do negcio;
modelagem de negcio com UML. So observadas duas
Processo do Negcio (Business process): modela os prolinhas distintas: a que defende a representao e denicessos de negcio e seus relacionamentos com os recursos
o dos requisitos dos negcios atravs de casos de uso,
a serem seguidos para atingir os objetivos;
que corresponderia a um processo; e a que discorda de
Estrutura do Negcio (Business structure): modela a estal representao, propondo que se faa primeiramente a
trutura dos recursos (fsicos, informacionais, humanos);
modelagem dos processos para denio dos requisitos de
Comportamento do Negcio (Business behavior): monegcios, e s depois se denam os requisitos de sistemas
dela o comportamento e a interao entre recursos e entre
de informaes atravs de casos de uso.
processos.
A primeira linha foi introduzida pela OMG em 1997 na
primeira verso da especicao da UML, posteriormente
O Diagrama de Processos de Negcio e o Diagrama de
aprimorada no RUP, e defende a modelagem de processos
Linha de Montagem tm um papel importante na ligao
de negcio atravs de modelos de casos de uso de negcio.
entre requisitos de negcios e casos de uso. O primeiro
Assim como o caso de uso para um sistema de software,
descreve os processos de negcio atravs de suas relaes
o modelo de caso de uso de negcio representa o sistema
com Objetos (Objetivos, Entradas, Sadas, Fornecedores
(agora, o negcio) na perspectiva do usurio, e esboa como
e Controles). J o Diagrama de Processos de Negcio
ele agrega valor a quem o utiliza.

30

Produo, v. 18, n. 1, p. 026-046, Jan./Abr. 2008

Definio de requisitos de software baseada numa arquitetura de modelagem de negcios

Um modelo de caso de uso de negcio descreve os processos de negcio de uma organizao em termos de casos
de uso e atores de negcio, correspondentes a processos de
negcio e clientes, respectivamente (JACOBSON; BOOCH; RUMBAUGH, 1999; OMG, 1997).
A segunda linha corresponde s iniciativas de Marshall
(1999) e Eriksson e Penker (2000), que sustentam no
serem os processos de negcio bem representados pelos
casos de uso, pois estes servem para representar um domnio fechado correspondente a determinados requisitos de
usurios e no podem ser vistos simplicadamente como
requisitos de clientes.
Isto signica que um caso de uso nem sempre equivalente a um processo, pois fornece um servio que requerido como parte de um processo exterior ao sistema de
software. Um caso de uso completamente implementado
no software, enquanto um processo , em geral, apenas
parcialmente implementado no software (o termo caso de
uso uma abstrao para denir comunicao entre atores

e um sistema de software). Os casos de uso podem ser considerados como as especicaes dos servios que o sistema
de software fornece ao processo de negcio (ERIKSSON;
PENKER, 2000), conforme ilustrado na Figura 2.
necessrio, portanto, que a modelagem dos processos
de negcio d nfase ao uxo de informaes entre os
processos ao longo da cadeia de valores que busca atingir
os objetivos globais do negcio. Atentando para isto, a
segunda linha prope a utilizao de diagramas de atividades para a representao dos processos de negcio no
domnio da modelagem de negcio, exibidos atravs do
diagrama de atividade da UML, em que os itens atividade
so estereotipados como processos, conforme o proposto
por Eriksson e Penker (2000). Faltam, porm, mtodos
para a sistematizao das etapas de denio dos processos de negcios e de denio dos requisitos de software
em processos de desenvolvimento de software (tal como o
UP), que considerem o alinhamento entre os objetivos do
negcio e os requisitos do software.

Figura 2: Exemplo de identificao de casos de uso no Diagrama de Linha de Montagem.

Armazenar Resultados da Verif.

Consultar Produtos MDS

Consultar Anlise da Conf.

<<Linha de montagem>>
Catlogo de Projetos

Cadastrar Projeto

<<Processo>>
Verificao de
documentao

Cadastrar
Projeto
Casos de uso do
sistema a ser
desenvolvido para
apoiar o processo

Verificar
conformidade

Armazenar
resultado de
Verificaes

<<Linha de montagem>>
Repositrio Oracle

<<Linha de montagem>>
Sistema a ser desenvolvido
para apoiar a verificao
de documentos

Dados armazenados no
sistema a ser desenvolvido

Produo, v. 18, n. 1, p. 026-046, Jan./Abr. 2008

31

Delmir Peixoto de Azevedo Junior; Renato de Campos

ATIVIDADES PARA SISTEMATIZAO DO

LEVANTAMENTO DE REQUISITOS
O UP une as boas prticas no desenvolvimento de
software e base para a denio de vrias metodologias
encontradas no mercado, porm sente-se a falta de mtodos
e ferramentas adequadas para o levantamento dos requisitos do negcio. Assim, procura-se inserir nesse processo
atividades para o levantamento de requisitos de sistemas
baseados em uma arquitetura modelagem de negcio, com
o intuito de tornar mais sistemtica esta etapa do desenvolvimento. Para isso, proposto um conjunto de atividades a
ser inserido no UP para a modelagem de negcio, com base
na tcnica de modelagem proposta por Eriksson e Penker
(2000), incorporando em processos de desenvolvimento
(neste caso, o UP) as caractersticas e vantagens destacadas
no nal da seo anterior. Tambm so propostas atualizaes em algumas atividades preestabelecidas no UP, de
forma a poderem ser aplicadas a qualquer metodologia que
nele se baseie.

deve denir atividades e seus uxos, bem como o estado

esperado dos artefatos gerados por estas atividades em cada
fase do processo (Concepo, Elaborao, Construo, e
Transio), considerando-se uma estrutura iterativa e incremental, bem como as atividades j denidas nesta estrutura. A aplicao da tcnica de Eriksson e Penker (2000) ao
UP se realiza, portanto, atravs da criao de um workflow
completo para a modelagem de negcio (que no existe
originalmente no UP), da criao de novas atividades,
e da atualizao de algumas atividades anteriormente j
estabelecidas nos workflows do UP, com a preocupao de
integr-los. So denidas tambm as abordagens que cada
atividade proposta deve ter nas fases de Concepo e de
Elaborao. As demais atividades do UP so consideradas
inalteradas, como originalmente proposto (JACOBSON;
BOOCH; RUMBAUGH, 1999). A seguir, so descritas as
atividades propostas para os trs workflows (Modelagem
de Negcio, Levantamento de Requisitos e Anlise) e as
abordagens das fases de Concepo e de Elaborao de
um processo de desenvolvimento baseado no UP (AZEVEDO JR.; CAMPOS, 2004).

forma de representao e concepo

dos processos de negcio no um
ponto comum nas propostas de modelagem
de negcio com UML.

A tcnica de construo de arquiteturas de negcio proposta por Eriksson e Penker (2000) , dentre as propostas
de modelagem de negcio com UML pesquisadas, a nica
que aborda de forma sistemtica a passagem da arquitetura de negcio para uma arquitetura de software que
d suporte primeira. Porm, os autores no exploram a
sistematizao desta passagem no contexto de um processo
ou metodologia de desenvolvimento de sistemas. O UP
dividido em quatro fases (levantamento de requisitos,
anlise, projeto, implementao e teste) e possui workflows
que devem ser executados em todas elas, com uma abordagem especca das atividades do uxo de trabalho para
cada uma. As atividades do workflow de levantamento de
requisitos existem em todas as fases do desenvolvimento,
com nfase nas fases de Concepo e de Elaborao. Na
concepo, h destaque para a identicao dos requisitos,
mas no para a especicao detalhada dos mesmos. A fase
Elaborao (ver Figura 1) a que requer maior concentrao de esforos e detalhes na atividade de especicao
de requisitos.
Um mtodo de levantamento de requisitos que derive
dos casos de uso de uma arquitetura de software no UP
32

Produo, v. 18, n. 1, p. 026-046, Jan./Abr. 2008

Workflow para Modelagem de

Negcio
O workflow denido para a modelagem
de negcio apresentado na Figura 3. A
seguir, as descries de cada atividade proposta e seus respectivos produtos:
Modelar os Objetivos do Negcio: a
modelagem dos objetivos deve identicar
os principais objetivos e subobjetivos do negcio em
uma estrutura hierrquica que permita a visualizao de
dependncia entre tais objetivos. Este modelo servir de
base para a denio dos processos de negcio. A modelagem dos objetivos do negcio deve ser feita com base em
entrevistas realizadas com os conhecedores do negcio.
Produto resultante: Diagrama de Modelo de Objetivos.
Modelar os Processos de Negcio: os processos de
negcio devem ser denidos buscando-se a realizao
dos objetivos identicados no Modelo de Objetivos do
Negcio. Porm, no necessrio haver uma relao
um para um entre processos de negcios e objetivos do
negcio, pois muitos processos auxiliares no estaro
necessariamente relacionados a um objetivo do Modelo
de Objetivos do Negcio. Entrevistas com os envolvidos
no negcio tambm devem ser realizadas para fornecer
subsdios denio dos processos de negcio. Produto
resultante: Diagrama de Processos de Negcio.
Modelar os Recursos Envolvidos: os recursos, informaes e unidades organizacionais devem ser modelados atravs dos diagramas da Vista de Estrutura
do Negcio. A modelagem destes elementos deve ser

Definio de requisitos de software baseada numa arquitetura de modelagem de negcios

feita paralelamente s atividades de Modelagem de

Processos de Negcio, a m de melhor entender os termos relacionados ao negcio e, conseqentemente, ter
maior consistncia na modelagem do mesmo. Produtos
resultantes: Diagramas de Modelos de Recursos, de
Informaes e de Organizao.
Modelar Comportamento dos Recursos: um Diagrama
de Estados de Recurso pode ser criado para facilitar a
determinao dos processos de negcio quando este se
caracteriza por renamentos de um mesmo objeto ao longo da cadeia de valor. Por exemplo, considerando-se um
negcio de vendas, o pedido pode ser abordado como um
objeto cujo estado vai sendo alterado (renado) ao longo
de toda a cadeia de valor, desde a abertura do pedido at
a conrmao do pedido entregue ao cliente. Em um caso
como este, a identicao dos estados possveis de tal
objeto (como pedido solicitado, pedido em vericao de
estoque, pedido em produo, pedido em expedio e pedido entregue) pode facilitar a identicao dos processos
de negcio necessrios ao cumprimento das mudanas
de estado do produto. Produto resultante: Diagrama de

Estado de Recurso e Diagramas de Interao de Recursos

e de Estados.
Denir Papis e Responsabilidades: cada processo de
negcio deve possuir um responsvel, uma vez que geralmente no estar ligado a uma nica unidade organizacional, mas passando por mais de uma delas. Cada processo,
por sua vez, dene um uxo de eventos que pode envolver
um ou mais atores. necessrio denir quais atores agem
em cada um dos processos. Isto pode ser feito atravs de
uma anlise do uxo de eventos e associao destes aos
atores envolvidos no processo. Produto resultante: Tabela
de Papis e Responsabilidades.
Abordagens das atividades propostas para Modelagem
de Negcios
As abordagens das atividades propostas em cada fase de
desenvolvimento esto descritas a seguir:
Modelar os Objetivos do Negcio
Na fase de Concepo o Modelo de Objetivos deve
abordar todos os objetivos relevantes ao projeto, desde os

Figura 3: Workflow para a Modelagem de Negcio.

Produo, v. 18, n. 1, p. 026-046, Jan./Abr. 2008

33

Delmir Peixoto de Azevedo Junior; Renato de Campos

de nvel mais estratgico at os que estejam ao nvel dos

objetivos de processos de negcio.
Na fase de Elaborao deve-se atualizar o modelo de
objetivos em funo de possveis esclarecimentos posteriores.
Modelar os Processos de Negcio
Na fase de Concepo deve-se identicar os principais processos de negcio, suas relaes com os recursos
(entradas, sadas, fornecedores, controles e objetivo), e a
seqncia de execuo dos mesmos. Porm, no necessria
a descrio detalhada do uxo de eventos ocorrido internamente no processo.
Na fase de Elaborao detalhar o uxo de eventos dos
processos que sero abordados na iterao atual.
Modelar os Recursos Envolvidos
Na fase de Concepo devem ser modelados todos os
recursos signicativos identicados no Modelo de Processo
de Negcio denido na fase Concepo, de forma a analisar
a dependncia entre tais recursos e suas propriedades.
Na fase de Elaborao modelar todos os recursos signicativos identicados durante o detalhamento dos uxos
de eventos de cada processo de negcio.
Modelar Comportamento dos Recursos
Na fase de Concepo modelar o comportamento de recursos nos casos em que ocorram vrias alteraes ao longo
dos processos de negcio, j que esta dinmica de alteraes
precisa ser melhor entendida.
Na fase de Elaborao detalhar os Diagramas de Estado
de Recursos, caso tenham sido criados na fase Concepo,
com base no detalhamento dos uxos de evento dos processos.
Denir Papis e Responsabilidades
Na fase de Concepo denir apenas os responsveis
por cada processo de negcio, sejam eles unidades organizacionais ou funes.
Na fase de Elaborao denir os papis (atores) associados aos eventos que ocorrem no uxo de evento de cada
processo de negcio.
Workflow de Levantamento de Requisitos
A seguinte atividade foi adicionada ao Workflow de Levantamento de Requisitos:
Identicar Necessidades de Informatizao: nesta
atividade necessrio associar os processos de negcio
aos sistemas de informao que lhes do suporte e, assim,
identicar a possvel necessidade de novos sistemas de
informao, com a caracterizao de carncias de suporte
automatizado de informao e operaes aos processos.
34

Produo, v. 18, n. 1, p. 026-046, Jan./Abr. 2008

Sugere-se a utilizao do Diagrama de Linha de Montagem como base para a realizao desta atividade. Produto
resultante: Diagrama de Linha de Montagem com os
pacotes de linha de montagem identicados.
A atividade Encontrar Atores e Casos de Uso, j existente
no UP, foi atualizada:
Derivar Casos de Uso dos Processos de Negcio: os
casos de uso devem ser identicados com base nos processos de negcio. Esta atividade deve resultar em uma
Relao de Casos de Uso na qual deve-se associar cada
caso de uso identicado ao processo (ou processos) de negcio a que este atende. Sugere-se a utilizao do Diagrama de Linha de Montagem como base para a realizao
desta atividade (exemplo na Figura 2). A identicao dos
casos de uso no Diagrama de Linha de Montagem se d
atravs do agrupamento de referncias (entre o processo
e os sistemas) de mesma natureza. Produto resultante:
Diagrama de Linha de Montagem com casos de uso
identicados.

Abordagens das atividades propostas para Levantamento

de Requisitos
As abordagens destas atividades em cada fase de desenvolvimento considerada so descritas a seguir:
Identicar Necessidades de Informatizao
Na fase de Concepo identicar sistemas de software
que do suporte aos processos de negcio, bem como identicar a necessidade de novos sistemas e subsistemas. Utilizar
o Diagrama de Linha de Montagem como recurso de apoio
ao desenvolvimento desta atividade. Deve-se comear com
os pacotes em um alto nvel de abstrao, representando
os sistemas j existentes e a natureza das informaes das
referncias que estes fazem a cada processo de negcio
analisado. Aplica-se, ento, uma primeira avaliao quanto
natureza das informaes e s operaes necessrias ao
processo e o atendimento destas pelos sistemas existentes,
de forma a identicar tipos de informaes e operaes que
no esto sendo mantidas pelos sistemas de software disponveis. Tais necessidades de informao e de operaes
devem ser referenciadas a um outro pacote representativo
do sistema (ou sistemas) a ser construdo para atender a tais
requisitos.
Na fase de Elaborao deve-se atualizar e aprofundar
a anlise iniciada na Concepo, com base na descrio do
uxo de eventos dos processos. necessrio avaliar cada
uxo de evento e identicar eventos que podem ser auxiliados por sistemas de informao, mas que ainda no so.
Tais auxlios devem ser representados como referncias
do processo aos sistemas que os realizam. Considerando

Definio de requisitos de software baseada numa arquitetura de modelagem de negcios

o escopo de um sistema identicado na concepo, devese representar cada linha de montagem como uma classe
do sistema e distribuir a responsabilidade entre as classes
atravs das referncias feitas a cada uma delas pelos processos. Cada evento a ser informatizado deve resultar em
uma referncia classe que o realizar e quando esta no
existir, dever ser criada como uma nova linha de montagem. Este processo deve ser feito respeitando-se o conceito
de encapsulamento.
Derivar Casos de Uso dos Processos de Negcio
Na fase de Concepo a atividade deve objetivar a identicao dos casos de uso arquiteturalmente signicativos.
Estes casos de uso representam funcionalidades num alto
nvel de abstrao e servem como base para a denio da
vista lgica da arquitetura do software que os realizar.
Na fase de Elaborao a atividade visa identicar todos
os casos de uso do sistema com base na anlise das referncias entre os processos detalhados e os sistemas de software
que os apoiaro.
Workflow para anlise
A atividade Realizao de Casos de Uso, j existente no
UP, foi atualizada:
Identicar Classes a partir da Arquitetura de Negcio: esta atividade consiste na identicao de Classes
a partir de modelos da Vista de Estrutura do Negcio e
da Vista de Processos de Negcio. Produto resultante:
Diagrama de Classes.
Abordagem da atividade proposta para anlise
As abordagens da atividade proposta nas fases de desenvolvimento consideradas so descritas a seguir:
Na fase de Concepo busca-se a identicao das principais Classes do sistema, com base na anlise dos Modelos
de Recursos e de Informaes.
Na fase de Elaborao deve ser feita uma reavaliao
das Classes identicadas, com base nas referncias do
Diagrama de Linha de Montagem desenvolvido nesta fase.
Atravs da anlise das referncias deve-se identicar que
classes sero responsveis pela realizao dos casos de uso
identicados no Diagrama de Linha de Montagem.

INCORPORAO DAS ATIVIDADES EM UMA

METODOLOGIA
Cada empresa que desenvolve software tem suas particularidades e busca desenvolver suas prprias metodologias ou
adaptar alguma existente no mercado. Neste trabalho utilizouse para teste uma metodologia de desenvolvimento de software
de uma empresa que baseada no UP e guia o desenvolvimento
dos sistemas concebidos no paradigma da orientao a objeto.

Por ser iterativa, cada fase percorre todo o conjunto de workflows. Por ser incremental, cada iterao atualiza os artefatos
gerados nas iteraes anteriores. Cada Artefato corresponde a
uma documentao (como um modelo) ou outro objeto de valor
a ser criado no desenvolvimento (como um componente de
software). A metodologia da empresa tambm estabelece os
estados esperados dos artefatos ao nal de cada fase. Porm
ela no apresenta, como o UP, atividades para o adequado
levantamento dos requisitos dos negcios.
Nesta seo so descritos os uxogramas de atividades
originados da incorporao das atividades propostas na metodologia (principalmente as fases de Concepo e Elaborao). Nas guras dos uxogramas as atividades adicionadas
metodologia apresentam-se em cor cinza escuro e as atividades j constantes, mas que foram atualizadas, apresentamse com listras. Tambm so apresentadas as descries de
cada atividade e os estados esperados para cada artefato ao
nal de cada fase. Esta metodologia resultante foi utilizada
no contexto do desenvolvimento de um sistema de Controle
de Expedies da empresa, sendo apresentados exemplos de
modelos gerados neste teste.
Descrio do Fluxograma da Fase Concepo
Na Figura 3 apresentada a parte inicial do uxograma
de atividades resultante para a fase Concepo. A Figura
4 apresenta um modelo gerado nesta fase, na atividade
de Modelagem de Processos de Negcios. O Quadro 1
apresenta o estado esperado dos artefatos ao nal da fase
de Concepo. Descrevem-se a seguir as atividades do
uxograma desta fase.
A.1) Entrevistar Cliente para Modelagem do Negcio:
entendimento do negcio onde o futuro Sistema atuar,
com registro das informaes levantadas num Registro de
Reunio, contendo um esboo do Diagrama de Contexto e
do Modelo de Processos de Negcio;
A.2) Analisar e Modelar o Negcio
- Analisar o Negcio: Documentar a Descrio do Negcio com base nas informaes levantadas nas reunies;
- Modelar os Objetivos do Negcio, Modelar os Processos
de Negcio (ver Figura 4), Modelar os Recursos Envolvidos, Modelar Comportamento dos Recursos e Denir
Papis e Responsabilidades so atividades que devem
ser feitas conforme descritas na seo Workow para
Modelagem de Negcio com a abordagem para a fase de
Concepo (seo Abordagens das atividades propostas
para Modelagem de Negcios) ;
- Registrar Termos no Glossrio: para expressar os conceitos presentes no negcio, documentando no Glossrio;
- Registrar Especicaes Suplementares Principais: podem ser previstos alguns requisitos no funcionais como
relativos segurana e performance por exemplo, registrando em Especificaes Suplementares;
Produo, v. 18, n. 1, p. 026-046, Jan./Abr. 2008

35

Delmir Peixoto de Azevedo Junior; Renato de Campos

Figura 3: Parte inicial do fluxograma referente fase de Concepo.

Entrevistar Cliente para

Modelagem do Negcio

Registro de Reunio

Analisar e Modelar
Negcio
Analisar o Negcio

Viso

Modelar os Objetivos
do Negcio

Modelo de Objetivos
do Negcio

Modelar os Processos
de Negcio

Modelo de Processos
do Negcio

Modelar os Recursos
Envolvidos

Modelos de Recursos

Modelar Comportamento
dos Recursos

Modelos de
Comportamento

Definir Papis e
Responsabilidades

Tabela de Papis e
Responsabilidades

Registrar Termos
no Glossrio

Glossrio

Registrar Especificaes
Suplementares Principais

Especificaes
Suplementares

Validar Anlise
com o Cliente

Registro de Reunio

Modelagem do
Negcio Validada
S

Entrevistar Cliente para

Levantar Requisitos

Registro de Reunio

Analisar e Especificar
Requisitos Levantados
Identificar Necessidades
de Informao

Diagrama de Linha de
Montagem

Esboar Modelo de
Casos de Uso Principais

Modelo de Caso de Uso

Incrementar Glossrio
Incrementar Especificaes
Suplementares Principais

Validar Levantamento de
Requisitos com Cliente
N

Modelagem de
Requisitos Validada
S

36

Produo, v. 18, n. 1, p. 026-046, Jan./Abr. 2008

Registro de Reunio

Definio de requisitos de software baseada numa arquitetura de modelagem de negcios

A.3) Validar Anlise com o Cliente: realizar reunio com

o Cliente para apresentar e validar a Anlise do Negcio,
Diagrama de Contexto, Modelo de Processos de Negcio,
Glossrio e Especificaes Suplementares;
A.4) Entrevistar Cliente para Levantar Requisitos: levantamento das principais funcionalidades do futuro Sistema
visando a identicao dos principais casos de uso e requerimentos no funcionais, registrando as informaes num
Registro de Reunio;
A.5) Analisar e Especicar Requisitos Levantados
- Identicar Necessidades de Informatizao: conforme seo Workow de Levantamento de Requisitos e Abordagens das atividades propostas para Levantamento de
Requisitos (abordagem para a fase de concepo);
- Esboar Modelo de Casos de Uso Principais: conforme
seo Workow de Levantamento de Requisitos e
Abordagens das atividades propostas para Levantamento
de Requisitos (abordagem para a fase de concepo);
- Incrementar Glossrio: atualizar o Glossrio com os
novos termos denidos nas reunies de Levantamento de
Requisitos;
- Incrementar Especicaes Suplementares Principais:
Atualizar as Especificaes Suplementares com os novos
requisitos no funcionais identicados nas reunies de
Levantamento de Requisitos;
A.6) Validar Levantamento de Requisitos com Cliente:
reunio para apresentar e validar o Modelo de Caso de
Uso e as alteraes no Modelo de Processo de Negcio, no
Glossrio e nas Especificaes Suplementares;

A.7) Entrevistar Cliente para Denir Arquitetura: levantar informaes e esboar alternativas de Modelos de Classe
e Pacotes, Modelo de Componentes e de Implantao em
alto nvel (procurando denir a arquitetura de hardware e
software em linhas gerais).
A.8) Denir Arquitetura do Software
- Desenvolver Modelo de Pacotes: analisar e denir um
Modelo de Pacotes em alto nvel buscando identicar as
relaes entre eles e a possvel reutilizao de arquiteturas
de referncia ou padres;
- Desenvolver Modelo de Classes: com as principais
classes do sistema e seus relacionamentos, vericando
a possibilidade de reutilizao de Classes j existentes,
utilizando a proposta da seo Workow para anlise,
abordagem para a fase de concepo (Abordagem da
atividade proposta para anlise);
- Desenvolver Modelos de Componentes: uma viso dos
subsistemas de informao e seus relacionamentos;
- Desenvolver Modelos de Implantao: uma viso da
arquitetura de hardware do novo sistema;
- Incrementar Glossrio: atualizar o Glossrio com os
novos termos denidos na denio da Arquitetura do
Software;
- Incrementar Especicaes Suplementares: atualizar as
Especificaes Suplementares com os novos termos
denidos na denio da Arquitetura do Software;
- Incrementar Modelo de Casos de Uso Principais: atualizar o Modelo de Casos de Uso com os novos termos
denidos na denio da Arquitetura do Software;

Figura 4: Exemplo de Modelo de Processo de Negcio Expedio.

Controlar a Formao
de Volumes por
Modalidade e Destino:
Objetivo Qualitativo

<<realiza>>

Formar
Volumes por
Modalidade
e Destino

Enviar Volumes por

Modalidade/Destino:
Objetivo Qualitativo

<<realiza>>

Enviar
Volumes por
Modalidade/
Destino

Entregar Volumes
em seu Destino:
Objetivo Qualitativo

<<realiza>>

Entregar
Volumes
em seus
Destinos

Produo, v. 18, n. 1, p. 026-046, Jan./Abr. 2008

37

Delmir Peixoto de Azevedo Junior; Renato de Campos

A.9) Validar Arquitetura com Cliente: validar a arquitetura geral do sistema com o cliente.
A.10) Elaborar Cronograma Geral: para Desenvolvimento do Projeto com base nos requisitos levantados;
A.11) Elaborar Oramento: com base no Cronograma
Geral e requisitos levantados;
A.12) Formalizar Prestao de Servio: consiste na elaborao e assinatura de um contrato junto ao cliente.
Descrio do Fluxograma da Fase de Elaborao
O uxograma de atividades resultante para a fase Elaborao apresentado na Figura 5. A Figura 6 apresenta um
modelo gerado nesta fase, na atividade Identicar Necessidades de Informatizao, sendo que o Quadro 2 apresenta o
estado esperado dos artefatos ao nal desta fase.
B.1) Denir Iteraes da Elaborao: denir subdomnios para a fase de Elaborao com base na Arquitetura do
Software e nas Especificaes Suplementares denidas em
cada iterao (deve conter o detalhamento do cronograma
para a fase de Elaborao, programando o desenvolvimento
dos Casos de Uso por iteraes);
B.2) Entrevistar Cliente para Levantar Requisitos: detalhamento dos Casos de Uso j identicados bem como a

identicao e detalhamento de outros Casos de Uso (registrar o levantamento num Registro de Reunio);
B.3) Analisar e Modelar o Negcio: Modelar os Objetivos
do Negcio; Modelar os Processos de Negcio; Modelar
os Recursos Envolvidos; Modelar Comportamento dos
Recursos; e Denir Papis e Responsabilidades, conforme
descritas na seo Workflow para Modelagem de Negcio
com a abordagem para a fase de Elaborao (Abordagens
das atividades propostas para Modelagem de Negcios);
B.4) Analisar e Especicar Requisitos Levantados:
consiste na realizao em colaborao das atividades:
Identicar Necessidades de Informatizao (ver Figura
6); Incrementar Modelo de Casos de Uso (conforme seo
Workflow de Levantamento de Requisitos com abordagem para a fase de Elaborao, seo Abordagens das
atividades propostas para Levantamento de Requisitos);
Incrementar (atualizar) Glossrio; e Incrementar (atualizar) Especicaes Suplementares;
B.5) Desenvolver Modelos de Anlise e Projeto
- Desenvolver Realizaes de Caso de Uso: para cada Caso
de Uso, mostrar as interaes realizadas pelos objetos
(Classes) necessrias realizao do caso de uso;
- Incrementar Modelo de Classes: atravs da anlise das

Quadro 1: Estados dos Artefatos ao final da Concepo.

ARTEFATO

ESTADO ESPERADO AO FINAL DA CONCEPO

Cronograma Geral

Definido.

Oramento

Definido.

Formalizao da Prestao de Servio

Realizada.

Registro de Reunio

Criado para cada reunio acontecida durante a fase.

Descrio do Negcio

Cerca de 90% definida ( revisado na fase seguinte).

Modelo de Objetivos do Negcio

Principais objetivos identificados.

Modelo de Processos de Negcio

Principais processos de negcio identificados.

Modelos de Recursos

Principais recursos identificados e modelados.

Modelos de Comportamento

Criado para recursos importantes e complexos.

Tabela de Papis e Responsabilidades

Com responsveis pelos processos identificados.

Diagrama de Linha de Montagem

Criado para os processos macros a serem informatizados.

Glossrio

Termos definidos e documentados.

Especificaes Suplementares

Principais requerimentos no funcionais documentados.

Modelo de Casos de Uso

Esboado. Atores e Casos de Uso importantes definidos; Fluxo de

eventos definidos em linhas gerais para os Casos de Uso.

Arquitetura do Software

Modelo de Casos de Uso, Modelo de Pacotes, Modelo de Classes, Modelo

de Componentes, Diagramas de Seqncias e de Colaborao, e Modelo
de Implantao descritos de uma maneira macro (principais aspectos).

38

Produo, v. 18, n. 1, p. 026-046, Jan./Abr. 2008

Definio de requisitos de software baseada numa arquitetura de modelagem de negcios

Figura 5: Fluxograma referente fase de Elaborao.

Plano de Iterao
Definir Iteraes da
Elaborao

Cronograma Geral

Entrevistar Cliente para

Levantar Requisitos

Registro de Reunio

Analisar e Modelar
Negcio
Modelar o Objetivo do
Negcio

Modelo de
Objetivos do Negcio

Modelar os Processos
de Negcio

Modelo de
Processos de Negcio

Modelar os Recursos
Envolvidos

Modelos de Recursos

Modelar Comportamento
dos Recursos

Modelos de
Comportamento

Definir Papis e
Responsabilidades

Tabela de Papis e
Responsabilidades

Analisar e Especificar
Requisitos Levantados
Identificar Necessidades
de Informao

Diagrama de
Linha de Montagem

Incrementar Modelo de
Caso de Uso

Modelo de
Casos de Uso

Incrementar Glossrio

Glossrio

Incrementar Especificaes
Suplementares

Especificaes
Suplementares

Desenvolver Modelos de
Anlise e Projeto

Diagramas
de Seqncia

Desenvolver Realizaes
de Caso de Uso

Diagramas
de Colaborao

Incrementar Modelo
de Classes

Modelo de Classes

Desenvolver Mapa de
Navegao

Mapa de Navegao

Desenvolver Modelos
de Estado

Modelo de Estado

Derivar/Ajustar
Modelo de Dados

Modelo de Dados

Validar Anlise e Projeto

com o Cliente

Registro de Reunio

Modelos de Anlise e
Projetos Validados
S

Produo, v. 18, n. 1, p. 026-046, Jan./Abr. 2008

39

Delmir Peixoto de Azevedo Junior; Renato de Campos

de Classes deve-se desenvolver o Modelo de Dados,

fazendo a correspondncia das classes para o modelo
relacional;
B.6) Validar Anlise e Projeto com o Cliente: entrevista
com Cliente para validar os modelos de Anlise e Projeto
(gerar um Registro de Reunio);
B.7) Atualizar Arquitetura do Negcio: atualizar todos os
modelos da Arquitetura do Negcio com as novas informaes da Anlise e Projeto.
As atividades propostas neste trabalho abrangem principalmente as fases de Concepo e Elaborao, pois durante
estas que os casos de uso so normalmente identicados.
Portanto, as fases de Construo e Transio no tiveram
suas atividades atualizadas ou modicadas. Para uma compreenso mais completa da metodologia resultante, nas

Realizaes de Caso de Uso e Modelo de Classes, deve-se

identicar a necessidade de novas classes e incrementlas no Modelo de Classes (os Diagramas de Linha de
Montagem podem ser usados como base para a identicao de novas classes, conforme seo Workflow para
Anlise, abordagem para a fase de Elaborao, seo
Abordagem da atividade proposta para Anlise);
- Desenvolver Mapa de Navegao: identicar no Modelo
de Classes as Classes de Interface, e dentre estas as que sero pginas Web, desenvolvendo o Mapa de Navegao;
- Desenvolver Modelos de Estado: para analisar e explicitar a mudana de estados de objetos ao longo da execuo dos processos ou eventos, desenvolvendo Modelos
de Estado;
- Derivar / Ajustar Modelo de Dados: com base no Modelo

Figura 6: Exemplo de modelo de Linha de Montagem: Processo de Expedio.

Controlar a Formao
de Volumes por
Modalidade e Destino:
Objetivo Qualitativo
<<realiza>>

<<realiza>>

Formar
Volumes por
Modalidade
e Destino

<<Linha de Montagem>>
Novo Sistema

40

Produo, v. 18, n. 1, p. 026-046, Jan./Abr. 2008

Entregar
Volumes
em seus
Destinos

Enviar
Volumes por
Modalidade/
Destino

Casos de Uso Identificados:

1- Gerar Etiqueta de Objeto;
Registrar Confirmao de Entrega

2- Manter informaes dos Objetos;

Gerar Lista de Volumes

Gerar Relao de Contedo de cada Volume

Registrar Informaes dos Volumes

Informar Rotas Possveis

Registrar Peso dos Objetos

3
Imprimir Etiqueta para os Objetos

Obter informaes de Origem e Destino

<<Linha de Montagem>>
Sistema de Pessoal

<<realiza>>

2
1

Entregar Volumes
em seus Destinos:
Objetivo Qualitativo

Enviar Volumes por

Modalidade/Destino:
Objetivo Qualitativo

3- Definir Rota;
4- Manter informaes dos Volumes;
5- Gerar Relatrios.

Definio de requisitos de software baseada numa arquitetura de modelagem de negcios

prximas sees so apresentados os uxogramas relativos

s fases de Construo e Transio.
Descrio do Fluxograma da Fase de Construo
As atividades da fase de Construo so apresentadas
na Figura 7. O Quadro 3 apresenta o estado esperado dos
artefatos ao nal da fase Construo.
C.1) Denir Iteraes da Construo: planejar a implementao de cada componente nas iteraes respeitando-se
o prazo estabelecido no Cronograma Geral (deve-se identicar a prioridade de implementao dos componentes);
C.2) Elaborar Plano de Testes: deve conter a descrio de
todos os testes que sero realizados durante o projeto, bem
como o momento em que acontecero;
C.3) Implementar: consiste das atividades Implementar Componentes (Codificao dos componentes, gerando os Componentes Implementados) e Implementar
Banco de Dados (Gerao do Banco de Dados com base
no Modelo de Dados);

C.4) Testar Componentes: realizar testes dos componentes implementados com base no Plano de Testes;
C.5) Incrementar Modelos de Requisitos e de Anlise e
Projeto: Atualizar Glossrio com novos termos denidos;
Atualizar Especificaes Suplementares com novos requerimentos no funcionais identicados na Construo; Atualizar
as Realizaes de Caso de Uso devido a possveis necessidades
de mudanas de projeto identicadas durante a implementao;
Atualizar o Modelo de Classes; Atualizar Mapa de Navegao; Atualizar Modelo de Estados com possveis mudanas
ocorridas na Implementao; Atualizar Modelo de Dados com
possveis mudanas ocorridas na construo do Banco;
C.6) Integrar Componentes Implementados de acordo
com o Plano de Integrao denido;
C.7) Realizar Testes Integrados com os componentes
integrados, vericando as interaes entre eles;
C.8) Desenvolver/Incrementar Manual do Sistema para
os usurios com explicaes operacionais para realizao
das funcionalidades requeridas para o Sistema.

Quadro 2: Estado dos Artefatos ao final da fase de Elaborao.

ARTEFATO

ESTADO ESPERADO AO FINAL DA ELABORAO

Plano de Iterao

Subdomnios do sistema e seus respectivos Casos de Uso identificados.

Cronograma Geral

Detalhado para a fase de Elaborao desde o incio da fase.

Registro de Reunio

Criado para cada reunio.

Modelo de Casos de Uso

Definido.

Modelo de Objetivos

Definido.

Modelo de Processos de Negcio

Revisado.

Modelos de Recursos

Definido.

Modelos de Comport. de Recursos

Definido.

Tabela de Papis e Responsabilidades

Definida.

Diagrama de Linha de Montagem

Criado para os processos detalhados a serem informatizados.

Glossrio

Atualizado com novos termos.

Especificaes Suplementares

Atualizado, capturando todos os requerimentos no funcionais.

Diagramas de Seqncia

Diagramas de Seqncia descrevendo as realizaes de Caso de Uso.

Diagramas de Colaborao

Diagramas de Colaborao descrevendo as realizaes de Caso de Uso.

Modelo de Classes

Definido.

Mapa de Navegao

Definido.

Modelo de Estado

Desenvolvido para os principais objetos do sistema.

Modelo de Dados

Definido no nvel lgico.

Arquitetura do Negcio

Revisada, com um maior nmero de detalhes.

Produo, v. 18, n. 1, p. 026-046, Jan./Abr. 2008

41

Delmir Peixoto de Azevedo Junior; Renato de Campos

Figura 7: Fluxograma referente a fase de Construo.

Plano de Iterao
Definir Iteraes
da Construo

Cronograma Geral

Elaborar Plano de Testes

Plano de Testes

Implementar
Implementar
Componentes

Componentes
Implementados

Implementar
Banco de Dados

Banco de Dados

Testar Componentes

Avaliao de Teste

Incrementar modelos de
Requerimentos e de Anlise
e Projeto
Incrementar Glossrio

Glossrio

Incrementar Especificaes
Suplementares

Especificaes
Suplementares

Atualizar Realizaes
de Caso de Uso

Diagramas
de Seqncia

Atualizar Modelo
de Classes

Diagramas
de Colaborao

Atualizar Mapa de
Navegao

Modelo de Classes

Atualizar Modelos
de Estado

Mapa de Navegao

Atualizar
Modelo de Dados

Modelo de Estado
Modelo de Dados

Integrar Componentes

Componentes Integrados

Realizar Testes Integrados

Verso Instalvel
S
N
Desenvolver/Incrementar
Manual do Sistema
N

Iteraes Programadas
para Construo Concludas
S

42

Produo, v. 18, n. 1, p. 026-046, Jan./Abr. 2008

Transio

Definio de requisitos de software baseada numa arquitetura de modelagem de negcios

Descrio do Fluxograma da Fase de Transio

As atividades da fase Transio so apresentadas no
uxograma da Figura 8 e o Quadro 4 apresenta o estado
esperado dos artefatos ao nal da fase Transio.
D1) Documentar Notas de Verso: descrio das funcionalidades implementadas (quais os casos de uso que a verso
realiza), da plataforma em que foi testada, de como realizar
sua instalao, Bugs, limitaes e solues conhecidas nos
testes;
D2) Desenvolver Estratgia de Implantao: planejamento para a implantao do sistema construdo;
D3) Implantar
- Instalao do Ambiente de Hardware e Software: preparao do ambiente de hardware e software do cliente para
receber o novo sistema (preparao da infra-estrutura
tecnolgica do cliente) ;
- Treinar Usurios: atividades de planejamento e execuo
de treinamento dos usurios no novo sistema;
- Implantar Sistema: preparao do ambiente organizacional para implantao do novo sistema;
D4) Realizar Testes no Ambiente de Produo: conforme
Plano de Testes;

D5) Avaliar Manuteno: planejar a manuteno, podendo ser necessrio voltar a uma das quatro fases do
desenvolvimento: Concepo, Elaborao, Construo ou
Transio.

CONSIDERAES FINAIS
Neste artigo enfatizou-se a necessidade de o desenvolvimento de sistemas complexos de software ser guiado por
uma metodologia ou um processo de desenvolvimento que
organize e controle a produo das vrias partes (artefatos)
constituintes de um sistema. O UP contempla boas prticas
de engenharia de software, mas no dene adequadamente
atividades para a modelagem de negcio. O RUP oferece
uma proposta de modelagem de negcio, porm, apresenta
limitaes quanto modelagem e quanto ao alinhamento dos
casos de uso identicados aos reais objetivos do negcio. A
tcnica de construo de arquiteturas de negcio proposta
por Eriksson e Penker (2000) , dentre as propostas de modelagem de negcio com UML pesquisadas neste trabalho,
a nica que aborda de forma sistemtica a passagem da
arquitetura de negcio para uma arquitetura de software.

Quadro 3: Estado dos Artefatos ao final da fase de Construo.

ARTEFATO

ESTADO ESPERADO AO FINAL DA CONSTRUO

Plano de Iterao

Estimativa para a implementao de cada componente identificado no

Modelo de Componentes, por iterao.

Cronograma Geral

Detalhado para a fase de Construo desde o incio da fase.

Plano de Testes

Elaborado, contendo a descrio dos testes que sero aplicados nos

componentes, bem como o cronograma de sua realizao.

Componentes Implementados

Componentes implementados e testados. Com a maioria dos componentes

j integrados.

Banco de Dados

Construdo.

Avaliao de Teste

Realizadas para cada componente e para integrao de conjuntos deles.

Glossrio

Atualizado e completamente revisado.

Especificaes Suplementares

Atualizado e completamente revisado.

Diagramas de Seqncia

Revisados.

Diagramas de Colaborao

Revisados.

Modelo de Classes

Revisado.

Mapa de Navegao

Revisado.

Modelos de Estado

Revisados.

Modelo de Dados

Revisado.

Componentes Integrados

Cerca de 90% integrados.

Produo, v. 18, n. 1, p. 026-046, Jan./Abr. 2008

43

Delmir Peixoto de Azevedo Junior; Renato de Campos

Figura 8: Fluxograma referente fase de Transio.

Documentar
Notas de Verso

Notas de Verso

Desenvolver Estratgia
de Implantao

Estratgia
de Implantao

Implantar
Instalao do Ambiente
de Hardware e Software

Ambiente de Hardware e
Software Instalado

Treinar Usurios

Usurios Treinados

Implantar Sistema

Sistema Instalado

Realizar Testes no
Ambiente de Produo

Avaliao de Teste

S
Sistema Aprovado?
Concepo

N
Avaliar Manuteno

Elaborao

Construo

Quadro 4: Estado dos Artefatos ao final da Transio.

ARTEFATO

ESTADO ESPERADO AO FINAL DA TRANSIO

Notas de Verso

Notas de Verso geradas para cada verso entregue ao usurio.

Estratgia de Implantao

Definida no incio da fase.

Ambiente de Hardware e Software

Infra-estrutura do cliente completamente instalada e operando.

Usurios Treinados

Usurios treinados para o sistema.

Sistema Instalado

Sistema Instalado e operando em ambiente de produo.

Avaliao de Teste

Realizada para cada componente construdo e para cada mdulo de

componentes integrados.

44

Produo, v. 18, n. 1, p. 026-046, Jan./Abr. 2008

Definio de requisitos de software baseada numa arquitetura de modelagem de negcios

objetivos do negcio, atividades, classes de objetos e neOs autores, porm, no exploram a sistematizao desta
cessidades de informatizao do processo de expedio)
passagem no contexto de um processo ou metodologia de
desenvolvimento de sistemas.
que no seriam (ou no seriam facilmente) identicados
O objetivo deste artigo foi descrever toda uma metocom a metodologia normalmente usada na empresa. Isto
dologia de desenvolvimento de software com atividades
indica que a metodologia resultante apresentou melhorias com relao a uma metodologia original, puramente
para a modelagem de negcio trazendo vantagens como: (i)
baseada no UP.
identicao sistemtica de necessidades de informatizao
a partir do uxo de evento dos processos
metodologia resultante apresentou
estabelecido na atividade, conforme os
objetivos do negcio; (ii) identicao
melhorias com relao a uma metodologia
sistemtica dos casos de uso numa abordagem iterativa estabelecida na atividaoriginal, puramente baseada no UP.
de Derivar Casos de Uso dos Processos
de Negcio; (iii) e tambm incorporao
Atualmente, parte dos conceitos apresentados neste
de atividades de forma consistente com o modelo incrementrabalho est sendo incorporada a uma metodologia
tal, com interfaces bem estabelecidas com as atividades
de desenvolvimento de ERPs (Enterprise Resources
preestabelecidas do UP.
Planning) de cdigo aberto (SILVA et al., 2006),
A metodologia resultante apresentada foi aplicada a um
dentro do projeto ERP5 (www.erp5.org). Como proprojeto piloto que correspondeu ao desenvolvimento de
posta para trabalhos futuros sugere-se a comparao
um sistema para controle de expedio de uma empresa.
desta tcnica com demais tcnicas de identificao de
Percebeu-se por desenvolvedores, que usavam a metodorequisitos, e a construo de uma ferramenta CASE
logia da empresa e que tambm participaram do projeto
que permita maior automao das atividades definidas
piloto, que a metodologia proposta permitiu identicar
neste trabalho.
requisitos e artefatos no projeto do sistema (tais como

Artigo recebido em 12/07/2005

Aprovado para publicao em 27/09/2007

Referncias

AZEVEDO JR., D. P. Aplicao da tcnica de

Modelagem de Negcio com UML a processos
iterativos de desenvolvimento de software.
2003. 127 f. Dissertao (Mestrado
Cincias de Engenharia, rea Engenharia
de Produo) Universidade Estadual do
Norte Fluminense Darcy Ribeiro, Centro
de Cincias e Tecnologia, Campos dos
Goytacazes, 2003.

AZEVEDO JR., D. P.; C AMPOS, R.

Aplicao de uma Arquitetura de
Modelagem de Processos de Negcios no
Desenvolvimento de Software. Vrtices,
v. 6, n. 3, p. 147-175, 2004.

ERIKSSON, H. E.; PENKER, M. Business

modeling with UML: business patterns at
work. New York: John Wiley, 2000.

FELICIANO NETO, A. Sistemas flexveis de

informaes. So Paulo: Makron, 1996.

JACOBSON, I.; BOOCH, G.; RUMBAUGH,

J. The unified software development process.
Reading: Addison-Wesley, 1999.

KOSANKE, K.; NELL, J. G. Standardisation

in ISO for enterprise engineering and
integration. Computers in Industry, v. 40,
n. 2, p. 311-319, Nov. 1999.

JOHANSSON, H. J. et al. Processos de negcios. So Paulo: Pioneira, 1995.

KALPIC, B.; BERNUS, P. Business process

modelling in industry: the powerful tool
in enterprise management. Computers in
Industry, v. 47, n. 3, p. 299-318, 2002.

KIRIKOVA, M. Explanatory capability of

enterprise models. Data and Knowledge
Engineering, v. 33, n. 2, p. 119-136,
May 2000.

KOSANKE, K.; VERNADAT, F.; ZELM, M.

CIMOSA: enterprise engineering and
integration. Computers in Industry, v. 40,
n. 2, p. 83-97, Nov. 1999.

KRUCHTEN, P. Introduo ao RUP: Rational

Unified Process. Rio de Janeiro: Cincia
Moderna, 2003.

LI, H.; WILLIAMS, T. J. Management of

complexity in enterprise integration projects by the PERA methodology. Journal
of Intelligent Manufacturing, v. 13, n. 6, p.
417-427, Dec. 2002.

LILLY, S. Use case pitfalls: top 10

problems from real projects using use
cases. In: TECHNOLOGY OF OBJECTORIENTED LANGUAGES AND SYSTEMS TOOLS, 30., 1999, Santa Barbara.

Proceedings... Santa Barbara: IEEE, p.

174-183, 1999.

MARSHALL, C. Enterprise modeling with

UML: designing successful software
through business analysis. Reading:
Addison-Wesley, 1999.

ODEH, M.; KAMM, R. Bridging the gap between business models and system models. Information and Software Technology,
v. 45, n. 15, p. 1053-1060, 2003.

OMG Object Management Group. UML

extension for business modeling. v. 1.1,
1997. Disponvel em: <ftp://ftp.omg.
org/pub/docs/ad/97-08-07.pdf>. Acesso
em: 12 nov. 2007.

Produo, v. 18, n. 1, p. 026-046, Jan./Abr. 2008

45

Delmir Peixoto de Azevedo Junior; Renato de Campos

Referncias

PAULA FILHO, W. P. Engenharia de software: fundamentos, mtodos e padres. Rio de Janeiro: Livros Tcnicos e
Cientficos, 2001.

DE ENGENHARIA DE SOFTWARE, 16.

2002, Gramado. Anais... Disponvel em:
<http://www.lbd.dcc.ufmg.br:8080/
colecoes/sbes/2002/013.pdf>. Acesso
em: 10 nov. 2003.

PRESSMAN, R. S. Engenharia de software.

5. ed. Rio de Janeiro: McGraw-Hill,
2002.

SCHEER, A. ARIS Business process modeling. 3. ed. New York: Springer, 2000.

SANTANDER, V. F. A.; CASTRO, J. F B.

Integrating use cases and organizational
modeling. In: SIMPSIO BRASILEIRO

SCHNEIDER, G.; WINTERS, J. P. Applying

use cases: a practical guide. Boston:
Addison-Wesley, 1998.

SHEN, H. et al. Integration of business

modelling methods for enterprise
information system analysis and user
requirements gathering. Computers
in Industry, v. 54, n. 3, p. 307-323,
Aug. 2004.

VERNADAT, F. B. Enterprise modeling

and integration: principles and application. London: Chapman & Hall,
1996.

SILVA, C. M. F. et al. GERAM como arquitetura de referncia para um ERP livre de

cdigo aberto. In: ENCONTRO NACIONAL
DE ENGENHARIA DE PRODUO, 26.
2006, Fortaleza. Anais eletrnicos... Rio de
Janeiro: ABEPRO, 2006. 1 CD-ROM.

VERNADAT, F. B. Enterprise modeling

and integration (EMI): current status
and research perspectives. Annual
Reviews in Control, v. 26, n. 1, p. 15-25,
2002.

Sobre os autores

Delmir Peixoto de Azevedo Junior

Universidade Petrobras
Analista de Sistema
E-mail: delmirjunior@yahoo.com.br
Renato de Campos
Universidade Estadual Paulista UNESP
Professor
End.: Rua Alberto Segalla, 1-117, ap. 91A Bairro Infante Dom Henrique Bauru SP CEP 17012-634
Tel./Fax: (14) 3103-6122
E-mail: rcampos@feb.unesp.br

46

Produo, v. 18, n. 1, p. 026-046, Jan./Abr. 2008