APLICAÇÃO DA TÉCNICA DE MODELAGEM DE NEGÓCIO COM UML A PROCESSOS ITERATIVOS DE DESENVOLVIMENTO DE SOFTWARE

Prévia do material em texto

APLICAÇÃO DA TÉCNICA DE MODELAGEM DE NEGÓCIO COM UML A PROCESSOS 
ITERATIVOS DE DESENVOLVIMENTO DE SOFTWARE 
 
 
 
 
 
 
 
 
DELMIR PEIXOTO DE AZEVEDO JÚNIOR 
 
 
 
 
 
 
 
 
 
 
 
 
 
UNIVERSIDADE ESTADUAL DO NORTE FLUMINENSE – UENF 
 
CAMPOS DOS GOYTACAZES – RJ 
ABRIL DE 2003 
 
II 
APLICAÇÃO DA TÉCNICA DE MODELAGEM DE NEGÓCIO COM UML A PROCESSOS 
ITERATIVOS DE DESENVOLVIMENTO DE SOFTWARE 
 
 
 
 
 
 
 
 
DELMIR PEIXOTO DE AZEVEDO JÚNIOR 
 
 
Dissertação submetida ao corpo docente do 
Centro de Ciência e Tecnologia da Universidade 
Estadual do Norte Fluminense, como parte das 
exigências necessárias para obtenção do grau 
de mestre em Ciências de Engenharia, na área 
de concentração de Engenharia de Produção. 
 
 
 
 
 
 
Orientador: Prof. Renato de Campos, D.Sc. 
 
 
 
 
 
 
CAMPOS DOS GOYTACAZES – RJ 
ABRIL DE 2003 
 
III 
APLICAÇÃO DA TÉCNICA DE MODELAGEM DE NEGÓCIO COM UML A PROCESSOS 
ITERATIVOS DE DESENVOLVIMENTO DE SOFTWARE 
 
 
 
 
DELMIR PEIXOTO DE AZEVEDO JÚNIOR 
 
 
Dissertação submetida ao corpo docente do 
Centro de Ciência e Tecnologia da Universidade 
Estadual do Norte Fluminense, como parte das 
exigências necessárias para obtenção do grau 
de mestre em Ciências de Engenharia, na área 
de concentração de Engenharia de Produção. 
 
 
 
Aprovada em: 
 
Comissão Examinadora: 
 
 
______________________________________________________________________ 
Prof. Renato de Campos. D. Sc. – UENF 
 
 
 
Prof. Clevi Rapkiewicz. D. Sc. – UENF. 
 
 
 
Prof. Rogério Atem de Carvalho. D. Sc. – UCAM. 
 
 
 
Prof. Geraldo Galdino de Paula Júnior. D. Sc. – UENF. 
 
IV 
 
AGRADECIMENTOS 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Agradeço a todos que de alguma forma 
me ajudaram durante o período dedicado 
a este trabalho. Especialmente a Deus; a 
minha amada esposa, Marília; aos meus 
pais, Maria da Penha e Delmir; e ao meu 
orientador, Renato de Campos. 
 
V 
SUMÁRIO 
 
CAPÍTULO 1 - Introdução………………………………………………………………...…1 
 
1.1. Contexto.....................................................................................................................1 
1.2. Motivação...................................................................................................................2 
1.3. Objetivo......................................................................................................................3 
1.4. Hipótese.. ..................................................................................................................3 
1.5. Estratégia...................................................................................................................3 
1.6. Estrutura do trabalho..................................................................................................4 
 
CAPÍTULO 2 - Engenharia de Software.........................................................................5 
2.1. Introdução ..................................................................................................................5 
2.2. O Modelo Iterativo e Incremental...............................................................................7 
2.3. Arquitetura de Software............................................................................................11 
2.4. A Engenharia de Requisitos.....................................................................................13 
2.5. UML .........................................................................................................................17 
2.6. O Processo Unificado (UP) .....................................................................................28 
 
CAPÍTULO 3 - Modelagem de Negócio........................................................................38 
3.1. Introdução ................................................................................................................38 
3.2. Modelagem por Processos de Negócio....................................................................39 
3.3. Modelagem de Negócio com Orientação a Objeto...................................................41 
3.4. Considerações sobre a Modelagem de Processos de negócio com UML...............56 
 
CAPÍTULO 4 – Propostas de atividades para a sistematização do levantamento de 
requisitos no UP............................................................................................................58 
4.1. Introdução ................................................................................................................58 
4.2. Atividades Propostas................................................................................................61 
4.3. Aplicação das Atividades Propostas à MDS-OO Dataprev......................................69 
 
VI 
 
CAPÍTULO 5 – Conclusão...........................................................................................101 
 
Referências Bibliográficas.........................................................................................104 
 
Anexo I – Artefatos da MDS Dataprev OO.................................................................107 
 
Anexo II – Exemplos de Artefatos .............................................................................112 
 
 
 
 
 
 
 
 
 
 
 
 
 
VII 
LISTA DE FIGURAS 
 
Figura 1- Riscos de projeto no modelo Cascata (Adaptado de RUP 2002) .....................8 
Figura 2 - Riscos de projeto no modelo Iterativo (Adaptado de RUP 2002).....................9 
Figura 3 - Vistas de uma arquitetura de software...........................................................12 
Figura 4 – Limites da análise de requisitos ....................................................................14 
Figura 5 – O “Gráfico das Baleias” (Adaptado de RUP, 2002).......................................30 
Figura 6 - As fases e os marcos de um projeto no UP.(Adaptado do RUP 2002) ..........31 
Figura 7 – Ícones e Estereótipos estabelecidos por Marshall ........................................43 
Figura 8 – Um exemplo de Modelo Organizacional........................................................43 
Figura 9 – Meta Modelo proposto por Eriksson e Penker (2000) ...................................45 
Figura 10 – Um exemplo de Diagrama de Modelo Conceitual .......................................47 
Figura 11 – Exemplo de Diagrama de Objetivos ............................................................48 
Figura 12 – Exemplo de Modelo de Informação.............................................................49 
Figura 13- Ícone associado à atividade estereotipada como processo de negócio........51 
Figura 14 - Representação de um processo de negócio e sua interação com recursos 52 
Figura 15 – Exemplo de Diagrama de Linha de Montagem ...........................................53 
Figura 16 – Exemplo de identificação de casos de Uso no Diagrama de Linha de 
Montagem ................................................................................................................55 
Figura 17 - Workflow para a Modelagem de Negócio ....................................................62 
 
VIII 
Resumo da dissertação apresentada ao CCT/UENF como parte das exigências para a 
obtenção do grau de Mestre em Ciências (M. Sc.) em Engenharia de Produção. 
 
APLICAÇÃO DA TÉCNICA DE MODELAGEM DE NEGÓCIO COM UML A PROCESSOS 
ITERATIVOS DE DESENVOLVIMENTO DE SOFTWARE 
 
Delmir Peixoto de Azevedo Júnior 
Abril - 2003 
 
Orientador: Prof. Renato de Campos 
 
Curso de Mestrado em Ciências de Engenharia – Área de Engenharia de Produção 
 
 
A atual dinâmica do mercado tem exigido das organizações uma constante 
reformulação de seus processos de negócio a fim de se manterem competitivas. Esta 
dinâmica provoca também uma necessidade de adaptações nos softwares que dão 
suporte a tais processos, ou seja, o surgimento de novos requisitos de software. 
Entretanto, a atividadede levantamento de requisitos em processos de 
desenvolvimento de software é realizada muitas vezes de forma pontual, sem uma 
visão mais abrangente e estratégica do negócio. 
 
Evidencia-se neste cenário, portanto, a necessidade de alinhamento entre o 
levantamento de requisitos e os processos de negócio de uma organização. E neste 
sentido, este trabalho busca inserir no Processo Unificado (processo de 
desenvolvimento de software que tem sido usado como base para a definição de várias 
metodologias encontradas no mercado) atividades para a sistematização do 
levantamento de requisitos a partir da análise de arquiteturas de negócio. 
 
Uma vez definidas de forma genérica para o Processo Unificado, estas atividades serão 
exemplificadas através de sua aplicação à metodologia de desenvolvimento de 
sistemas da Dataprev, a MDS-OO Dataprev. 
 
IX 
Abstract of Dissertation Submitted to the CCT/UENF as partial fulfillment of the 
requirements for the degree of Master of Sciences. 
 
THE BUSINESS MODELING TECHNIQUE WITH UML APPLICATION TO SOFTWARE 
DEVELOPMENT ITERATIVE PROCESS 
 
Delmir Peixoto de Azevedo Júnior 
 
April - 2003 
 
Advisor: Renato de Campos 
 
Course of Master's Degree in Engineering Science - Area of Production Engineering 
 
 
 
The current market dynamics has been demanding a constant rebuilding of the 
organizations’ business processes in order to maintain their competitiveness. This 
dynamics also provokes needs for adaptations in the software that give support to such 
processes, in other words, the sprouting of new software requirements. However, the 
activity of requirements analysis in software development processes is accomplished a 
lot of times without a general and strategic vision of the business. 
 
It is evidenced in this scenery, therefore, the need of alignment between the 
requirements analysis and the business processes of an organization. In this sense, this 
work looks forward to insert in the Unified Process (process of software development 
that has been used as base for the definition of several methodologies found in the 
market) activities for the requirements analysis systematization through the analysis of 
business architectures. 
 
Once defined in a generic way for the Unified Process, these activities will be 
exemplified through its application to the systems development methodology of 
Dataprev, the MDS-OO Dataprev. 
 
CAPÍTULO 1 
 
Introdução 
 
 
1.1. Contexto 
 
O avanço tecnológico tem permitido o surgimento de novas formas de negócios. As 
organizações empresariais modernas precisam estar em constante evolução para se 
manterem competitivas. São necessárias freqüentes reformulações e inovações nos 
processos de negócio e conseqüentemente nos sistemas de informação que os dão 
suporte. Muitas vezes a complexidade atinge proporções que dificultam o 
gerenciamento e mesmo o conhecimento do negócio pelos que o gerenciam. Muitos 
gerentes não conhecem os recursos que possuem e entre estes os sistemas de 
informações que existem por toda a organização. É muito comum observar gerentes de 
departamentos vizinhos replicando dados em sistemas de informações. 
 
A integração entre os objetivos do negócio, os processos de negócio, e sistemas de 
informação é um fator determinante da dinâmica necessária à organização e também 
um desafio aos gerentes. Nesse cenário dinâmico, os sistemas de informações são os 
habilitadores do negócio e portanto precisam estar alinhados com os reais objetivos do 
negócio (AZEVEDO; CAMPOS, 2002). 
 
Existem vários métodos, técnicas e ferramentas de modelagem para facilitar o 
entendimento e análise da complexidade das organizações modernas. Essas 
facilidades são utilizadas na tentativa de tornar a realidade organizacional mais 
tangível. Também existem várias metodologias para o desenvolvimento de sistemas de 
informação. Entretanto, Santander e Castro (2002) observam que há uma falta de 
integração entre as análises no domínio do negócio e no domínio dos sistemas de 
informação. 
 
Dentre as metodologias de desenvolvimento de sistemas de software o Processo 
Unificado (UP) é uma das que vêm obtendo destaque entre as demais. Várias 
2 
 
metodologias, como a apresentada em Paula (2001), têm sido concebidas utilizando-se 
os princípios estabelecidos no UP. Entretanto mesmo no UP a atividade de 
levantamento de requisitos ainda é um processo empírico, não considerando de forma 
sistemática a importância do foco nos objetivos do negócio. 
 
Neste contexto, evidencia-se a necessidade de maior aproximação entre o 
levantamento de requisitos de sistemas de softwares, nos processos ou metodologias 
de desenvolvimento de software, às reais necessidades do negócio. Esta dissertação 
propõe contribuições para uma melhor aproximação entre estes dois domínios, 
mostrando como um processo de desenvolvimento de software pode utilizar modelos de 
negócio para sistematizar a identificação de requisitos em função dos reais objetivos do 
negócio. 
 
1.2. Motivação 
 
Segundo Santander e Castro (2002) a identificação dos requisitos funcionais dos 
sistemas de informação tem sido feita de forma bastante empírica, sem o apoio de 
métodos mais sistemáticos, o que resulta freqüentemente no desenvolvimento de 
sistemas não alinhados aos objetivos do negócio. 
 
Embora existam algumas heurísticas propostas para identificação de requisitos 
funcionais, como as apresentadas por Schneider e Winters (1998), Jacobson et al 
(1999), e em Lilly (1999), não existem métodos estabelecidos que tornem esta atividade 
mais sistemática. 
 
A principal motivação para este trabalho é, portanto, a carência de métodos que 
alinhem, de forma sistemática, o levantamento de requisitos de software às reais 
necessidades de um negócio. 
 
 
 
 
3 
 
1.3. Objetivo 
 
Este trabalho busca definir atividades a serem inseridas no UP, ou em qualquer outro 
processo de desenvolvimento baseado neste, de forma a sistematizar o levantamento 
de requisitos com base em análise de modelos de negócio. 
 
Um segundo objetivo deste trabalho é a aplicação das atividades propostas à MDS-OO 
Dataprev, a metodologia de desenvolvimento de sistemas da Dataprev, fundamentada 
nos mesmos princípios estabelecidos no UP. 
 
1.4. Hipótese 
 
O presente trabalho utiliza a hipótese de que o alinhamento entre requisitos de software 
e as reais necessidades de informatização da empresa pode ser melhorado através de 
técnicas de modelagem de empresa, e que a tecnologia da orientação a objeto, através 
da Unified Modeling Language (UML) permite a integração da representação de 
modelos nos dois domínios, negócio e software. 
 
Uma empresa pode ser modelada como um conjunto de objetos e seus 
relacionamentos. A análise do relacionamento entre objetos da empresa e objetos de 
sistemas de software permitirá o alinhamento entre os domínios da modelagem de 
empresa e de modelagem de requisitos de software e a conseqüente identificação de 
requisitos de software alinhados ao negócio. A atividade de identificação dos requisitos 
deve ser ajustada à estrutura do processo de desenvolvimento de software utilizado. 
 
1.5. Estratégia 
 
De maneira a testar a hipótese citada esta dissertação inicialmente avalia através de 
uma pesquisa bibliográfica técnicas de modelagem de negócio e de identificação de 
requisitos de software. 
 
4 
 
Em seguida são definidas atividades para identificação sistemática de requisitos, a 
partir de modelos de negócio, e aplicadas ao Processo Unificado de desenvolvimento 
de software. As atividades propostas são então aplicadas à MDS-OO Dataprev. 
 
1.6. Estrutura do trabalho 
 
A dissertação está organizada de acordo com a estrutura de capítulos a seguir: 
 
Capítulo 2: Apresenta os conceitos da engenharia de software e de requisitos. 
Apresenta a Linguagem UML e o Processo Unificado de Desenvolvimentode Software. 
 
Capítulo 3 : Apresenta os conceitos e métodos da modelagem de negócio e as 
propostas de extensão da linguagem UML para a modelagem de negócio. 
 
Capítulo 4. Apresenta as atividades propostas nesta dissertação, a serem inseridas no 
UP ou qualquer outra metodologia de desenvolvimento de sistemas baseada na 
estrutura deste. Apresenta também a aplicação destas atividades na metodologia de 
desenvolvimento de sistemas da Dataprev. 
 
Capítulo 5: Apresenta as conclusões do trabalho. 
 
 
 
 
 CAPÍTULO 2 
Engenharia de Software 
 
2.1. Introdução 
 
Uma primeira definição de engenharia de software foi proposta por Fritz Bauer na 
primeira grande conferência (NAUR; RANDELL; BUXTON, 1969) dedicada ao assunto: 
 
O estabelecimento e uso de sólidos princípios de engenharia para que se possa 
obter economicamente um software que seja confiável e que funcione 
eficientemente em máquinas reais. 
 
Segundo Pressman (1995) a engenharia de software abrange um conjunto de três 
elementos fundamentais: métodos, ferramentas e procedimentos, que possibilita ao 
gerente o controle do processo de desenvolvimento do software e oferece ao 
profissional uma base para a construção de software de alta qualidade com 
produtividade. A seguir o autor analisa cada um desses elementos: 
 
Os métodos - proporcionam os detalhes de “como fazer” para construir o 
software. Os métodos envolvem um amplo conjunto de tarefas que incluem: 
planejamento e estimativa de projeto, análise de requisitos de software e de 
sistemas, projeto da estrutura de dados, arquitetura de programa e algoritmo de 
processamento, codificação, teste e manutenção. Os métodos da engenharia de 
software muitas vezes introduzem uma notação gráfica ou orientada a uma 
linguagem específica, e introduzem um conjunto de critérios para a qualidade do 
software. 
 
As ferramentas – proporcionam apoio automatizado ou semi-automatizado aos 
métodos. Atualmente existem ferramentas para dar suporte a vários métodos. 
Quando as ferramentas são integradas de forma que a informação criada por 
uma ferramenta possa ser usada por outra, é estabelecido um sistema de 
6 
 
suporte ao desenvolvimento de software chamado engenharia de software 
auxiliada por computador (CASE – Computer-Aided Software Engineering). 
 
Os procedimentos (também citados como metodologia ou processos) – 
constituem o elo de ligação que mantém juntos os métodos e as ferramentas e 
possibilitam o desenvolvimento racional e oportuno do software de computador. 
Os procedimentos definem a seqüência em que os métodos serão aplicados, os 
produtos que se exige que sejam entregues (documentos, relatórios, formulários, 
etc.), os controles que ajudam a assegurar a qualidade e a coordenar as 
mudanças, e os marcos de referência que possibilitam aos gerentes de software 
avaliar o progresso. 
 
A engenharia de software se dá através de um conjunto de fases. Cada uma das fases 
pode envolver métodos, ferramentas e procedimentos. A forma de estruturação destas 
são citadas como modelo de engenharia de software (PRESSMAN, 1995). Um modelo 
de engenharia de software é escolhido tendo-se como base a natureza do projeto e da 
aplicação, os métodos e as ferramentas a serem usados, os controles e os produtos 
que precisam ser entregues. Pressman também analisa que independentemente do 
modelo de desenvolvimento de software, o processo de desenvolvimento contém três 
fases genéricas: definição, desenvolvimento e manutenção. 
 
Na fase de definição, o desenvolvedor de software tenta identificar que informações 
necessitam ser processadas, quais funções e desempenho são desejados, quais 
interfaces devem ser estabelecidas, quais restrições de projeto existem e quais critérios 
de validação são exigidos para se definir um sistema bem sucedido. 
 
Pressman(1995) também observa que embora os métodos aplicados durante a fase de 
definição variem em função do modelo, três etapas específicas ocorrerão de alguma 
forma: 
 
Análise do sistema – que define o papel de cada elemento num sistema baseado 
em computador determinando o papel que o sistema desempenhará; 
7 
 
 
Planejamento do projeto de software – que aborda a análise de riscos, alocação 
de recursos, estimativas de custos e a definição de tarefas e programação de 
trabalho. 
 
Análise de requisitos – que detalha o escopo através de uma análise do domínio 
da informação e das funções do software. 
 
A fase de desenvolvimento tenta definir como a estrutura de dados e a arquitetura de 
software têm de ser projetadas, como os detalhes procedimentais têm de ser 
implementados, como o projeto será traduzido numa linguagem de programação e 
como os testes têm de ser realizados. Assim como na fase de definição, os métodos da 
fase de desenvolvimento também variam em função do modelo de engenharia de 
software a ser usado no projeto. Mas três etapas genéricas ocorrerão de alguma forma: 
projeto de software, codificação e realização de testes do software. 
 
A fase de manutenção concentra-se nas mudanças que estão associadas a correção 
de erros, adaptações e melhoramento funcional do software. 
 
Quatro modelos de engenharia de software têm sido amplamente discutidos: o ciclo de 
vida clássico (ou cascata), a prototipação, o modelo espiral, e as técnicas de Quarta 
geração (PRESSMAN, 1995). 
 
Atualmente um novo modelo tem sido amplamente usado, o modelo iterativo e 
incremental. Este modelo é apresentado em (JACOBSON; BOOCH; RUMBAUGH, 
1999) e em (PAULA, 2001). Este modelo será apresentado a seguir e utilizado como 
base para o método proposto neste trabalho. 
 
2.2. O Modelo Iterativo e Incremental 
 
Um projeto de desenvolvimento de software transforma uma quantidade de requisitos e 
usuários em uma quantidade de produto de software. Num processo iterativo e 
8 
 
incremental a quantidade de mudança é feita por partes. Em outras palavras, divide-se 
o projeto em um número de mini-projetos, cada um correspondendo a uma iteração. 
Cada iteração abrange todas as etapas do desenvolvimento: planejamento, 
levantamento de requisitos, análise, projeto, implementação, teste, e preparação para a 
implantação. Cada uma destas iterações assemelha-se ao tradicional modelo Cascata 
da engenharia de software porque se procedem através de atividades seqüenciais e 
subsequentes. Pode-se considerar cada iteração como um processo “minicascata”. 
 
Geralmente, uma abordagem iterativa é superior a uma abordagem linear ou em 
cascata. O RUP (2002) apresentada vários motivos para isto, entre eles: 
 
• Os riscos são reduzidos mais cedo, pois os elementos são integrados 
progressivamente: 
 
Todos os projetos têm um conjunto de riscos envolvidos. Quanto mais 
cedo puder ser verificado que se evitou um risco no ciclo de vida, mais 
precisos serão os planos. Muitos riscos nem são descobertos até que se 
tente integrar o sistema. É impossível prever todos eles, por mais 
experiente que seja a equipe de desenvolvimento. Em um ciclo de vida em 
cascata, não se pode verificar se o projeto está livre de um risco até o 
final do ciclo.(Figura 1) 
 
Figura 1- Riscos de projeto no modelo Cascata (Adaptado de RUP 2002) 
9 
 
Em um ciclo de vida iterativo, a seleção do incremento a ser desenvolvido 
em uma iteração é feita com base em uma lista dos principais riscos. 
Como a iteração produz um conjunto de artefatos testados, pode-se 
verificar a diminuição dos riscos em cada iteração. (Figura 2) 
 
Figura 2 - Riscos de projeto no modelo Iterativo (Adaptado de RUP 2002) 
 
• As táticas e os requisitos variáveis são acomodados: 
 
A abordagem iterativa permite que sejam considerados os requisitos 
variáveis, já que eles normalmente serão alterados durante o processo. 
 
As mudanças efetuadas nos requisitos e a forma lenta como eles são 
levantados têm sido sempre as principais fontes de problemas para um 
projeto, levandoa liberação depois do prazo, programações atrasadas, 
clientes insatisfeitos e desenvolvedores frustrados. Os usuários mudarão 
de idéia durante o processo. Essa é a natureza humana. Forçar os 
usuários a aceitarem o sistema como o imaginaram originalmente está 
errado. Eles mudam de idéia porque o contexto está sendo alterado; eles 
aprendem mais sobre o ambiente e a tecnologia e enxergam uma 
demonstração intermediária do produto durante o seu desenvolvimento. 
 
Um ciclo de vida iterativo fornece o gerenciamento com um modo de fazer 
mudanças táticas no produto. Por exemplo, para competir com os 
10 
 
produtos existentes, pode-se decidir lançar um produto com 
funcionalidade reduzida mais cedo como reação a uma movimentação de 
um concorrente ou poderá adotar um outro fornecedor de uma 
determinada tecnologia. 
 
A iteração também permite mudanças tecnológicas durante o processo. 
Se alguma tecnologia é alterada ou se torna um padrão conforme aparece 
uma nova, o projeto poderá aproveitá-la. Particularmente, esse é o caso 
de mudanças de plataforma e de infra-estrutura de nível inferior. 
 
• A melhoria e o refinamento do produto são facilitados, resultando em um produto 
mais robusto. 
 
Uma abordagem iterativa resulta em uma arquitetura mais robusta, pois os 
erros são corrigidos após várias iterações. As falhas iniciais são 
detectadas conforme o produto amadurece, durante as iterações iniciais. 
Os gargalos de desempenho são descobertos e podem ser reduzidos, em 
vez de aparecerem na véspera da liberação. 
 
Desenvolver iterativamente, ao contrário de executar testes uma vez ao 
final do projeto, resulta em um produto totalmente testado. Houve muitas 
oportunidades para testar as funções críticas após várias iterações, e os 
próprios testes, além dos softwares de teste, tiveram tempo para 
amadurecer. 
 
• Aumento de Reutilização 
 
Um ciclo de vida iterativo facilita a reutilização. Identificar as partes 
comuns quando estão parcialmente projetadas ou implementadas é mais 
fácil que identificar todas as semelhanças no início. 
 
11 
 
É difícil identificar e desenvolver partes reutilizáveis. As revisões de design 
nas iterações iniciais possibilitam que os arquitetos de software 
identifiquem reutilizações inesperadas e potenciais, e as iterações 
subseqüentes permitem que eles desenvolvam e amadureçam 
posteriormente esse código comum. 
 
O uso de uma abordagem iterativa facilita o aproveitamento dos produtos 
desenvolvidos internamente e adquiridos prontos para serem usados. 
Haverá várias iterações para selecioná-los, integrá-los e confirmar que 
eles são adequados à arquitetura. 
 
2.3. Arquitetura de Software 
 
O tamanho e a complexidade dos softwares têm aumentado tanto que as técnicas de 
abstração utilizadas até o final da década de 1980 (como, por exemplo, tipos de dados 
abstratos, linguagens de programação de alto nível e técnicas de decomposição 
modular) já não são mais suficientes para lidar com esses novos problemas envolvendo 
o projeto de software no nível de sistema. (MENDES, 2002) 
 
O desenvolvimento de software baseado em arquitetura de software vem atender a esta 
maior necessidade de abstração, permitindo que o sistema possa ser analisado através 
de várias vistas integradas. Cada vista evidenciando informações de determinado 
aspecto e suprimindo de outros a fim de facilitar a análise de cada um dos aspectos. 
 
A arquitetura de software é a estrutura do sistema, que compreende os componentes 
do software, as propriedades externamente visíveis desses componentes, e os 
relacionamentos entre eles. (BASS; CLEMENTS; KAZMAN, 1998). 
 
O conceito de arquitetura engloba os aspectos mais relevantes, tanto estáticos como 
dinâmicos, do sistema a fim de garantir um todo consistente que represente bem as 
12 
 
necessidades dos interessados. Uma arquitetura é composta por vistas que evidenciam 
as informações de determinados aspectos do sistema. 
 
A arquitetura de software não se preocupa apenas com a estrutura e o comportamento 
mas também com restrições e concessões quanto ao uso, funcionalidade, performance, 
elasticidade, reuso, compreensibilidade, economia e tecnologia. (KRUCHTEN, 1998). 
 
Uma arquitetura de software deve abordar características funcionais, não funcionais e 
de desenvolvimento. As características funcionais Refere-se à capacidade do sistema 
em realizar as funções requeridas pelos usuários. As características não funcionais 
correspondem às demais características que afetam o sistema como um todo, tais 
como: performance, segurança, e viabilidade. As características não funcionais também 
podem ser em parte derivadas do modelo do negócio. Elas se apresentam em forma de 
Restrições (ex: restrições de hardware) e Qualitativos (ex: segurança). As 
características de desenvolvimento referem-se ao processo de desenvolvimento e à 
qualidade do software. 
 
Um software é um sistema complexo que pode ser abordado sob mais de um aspecto. 
Cada aspecto pode ser observado a partir de uma vista. Cada vista pode ser modelada 
por um ou mais tipos de diagramas. A Figura 3 apresenta as cinco vistas estabelecidas 
por Kruchten (1995). Segundo Kruchten o uso de múltiplas vistas permite endereçar os 
requisitos de vários interessados no sistema: usuários finais, desenvolvedores, 
engenheiros de sistemas, e gerentes de projetos entre outros. 
 
Figura 3 - Vistas de uma arquitetura de software 
13 
 
2.4. A Engenharia de Requisitos 
 
Como foi apresentada na seção anterior, a análise de requisitos é uma etapa sempre 
presente na fase de definição do software, independentemente do modelo de 
engenharia de software adotado. 
 
Paula (2001) diz que a engenharia de requisitos é formada por um conjunto de técnicas 
empregadas para levantar, detalhar, documentar, e validar os requisitos de um produto 
de software. 
 
Sommerville (2000) apresenta as seguintes definições para requisito: 
 
(1) Uma condição ou capacidade necessitada por um usuário para resolver um 
problema ou atingir um objetivo. 
(2) Uma condição ou capacidade que deve ser atingida ou possuída por um 
sistema ou componente de sistema para satisfazer um contato, padrão, 
especificação, ou outro documento de formalidade. 
(3) Uma representação documentada de uma condição ou capacidade como em 
(1) ou (2). 
 
Segundo Pressman (1995) a tarefa de análise de requisitos é um processo de 
descoberta, refinamento, modelagem e especificação, e embora possa parecer uma 
tarefa relativamente simples, o conteúdo de comunicação é muito elevado, o que 
abundam as chances de interpretações errôneas e informações falsas. 
 
Portanto, pode-se definir a engenharia de requisitos como um campo da engenharia de 
software que visa a aplicação de técnicas de engenharia em métodos de análise de 
requisitos. A análise de requisitos efetua a ligação entre a necessidade de 
informatização de processos ao projeto do software que atenderá tais necessidades 
(ver Figura 4). 
14 
 
 
Figura 4 – Limites da análise de requisitos 
 
A análise de requisitos possibilita que o analista de sistemas especifique a função e o 
desempenho do software, indique a interface do software com outros elementos do 
sistema e estabeleça quais são as restrições de projeto que o software deve enfrentar. 
 
2.4.1 Atividades da Análise de Requisitos 
 
Segundo Pressman (1995) a análise de requisitos de software pode ser dividida em 
cinco áreas de esforço: reconhecimento do problema, avaliação e síntese, modelagem, 
especificação e revisão. 
 
Reconhecimento do problema : No reconhecimento do problema é importante 
entender o software num contexto de sistema e revisar o escopo do software que 
foi usado para gerar as estimativas de planejamento. 
 
Avaliação e síntese: Durante a avaliação a meta do analista é o reconhecimento 
dos elementos problemáticos básicos e as informações desejadas de entradae 
saída no sistema. No decorrer da síntese de avaliação e solução, o principal foco 
do analista recai sobre “o que”, não sobre “como”. Quais dados o sistema produz 
e consome, quais funções o sistema deve executar, quais interfaces são 
definidas e quais restrições se aplicam. 
 
15 
 
Modelagem: Durante a atividade de síntese e avaliação, o analista cria modelos 
do sistema num esforço para compreender melhor o fluxo de dados e de 
controle, o processamento funcional e a operação comportamental. 
 
Especificação: A atividade de especificação esforça-se para oferecer uma 
representação de software que possa ser revisada e aprovada pelo cliente. 
 
Revisão: Após especificados os requisitos devem ser revisados pelo cliente e 
pelo desenvolvedor. 
 
De forma similar, Sommerville (2000) afirma que o processo de engenharia de 
requisitos pode ser descrito como um processo sistemático de cinco passos distintos: 
elicitação, análise e negociação, especificação e modelagem, validação, e 
gerenciamento de requisitos: 
 
Elicitação: A elicitação de requisitos corresponde a identificar junto aos clientes, 
usuários e outros envolvidos, quais são os objetivos do sistema ou produto, o 
que deve ser acompanhado, como o sistema ou produto se encaixa no contexto 
das necessidades do negócio e, finalmente, como será a utilização do sistema ou 
produto no dia-a-dia. 
 
Análise e Negociação: A análise categoriza e organiza os requisitos em 
subconjuntos relacionados, explora o relacionamento de cada requisito com 
todos os demais, examina consistência, omissão e ambigüidade dos requisitos e 
prioriza requisitos com base nas necessidades dos clientes/usuários. 
 
Especificação e Modelagem: A especificação do sistema é o produto final 
produzido pelos engenheiros de requisitos. Ela é usada como base para as 
engenharias de hardware, software e banco de dados, pois descreve funções e 
performance requeridas de um sistema baseado em computação e as regras que 
irão guiar seu desenvolvimento. A especificação limita cada elemento alocado ao 
sistema. A especificação do sistema também descreve a informação (dados e 
16 
 
controle) que é entrada e saída do sistema. A modelagem dos requisitos 
especificados pode facilitar o entendimento das relações existentes entre os 
mesmos. 
 
Validação: A validação examina a especificação para garantir que todos os 
requisitos do sistema foram estruturados de maneira não ambígua, que as 
inconsistências, omissões e erros foram apagados e corrigidos, e que os 
produtos de trabalho estão em conformidade com os padrões estabelecidos para 
o processo, para o projeto e para o produto. 
 
Gerenciamento de Requisitos: É necessário persistir as alterações de requisitos 
através de toda a vida do software; neste sentido, o gerenciamento de requisitos 
corresponde ao conjunto de atividades que auxilia a equipe do projeto a 
identificar, controlar e rastrear os requisitos, bem como as alterações nos 
requisitos em muitos momentos do projeto. 
 
2.4.2. Métodos de análise de requisitos 
 
No decorrer das duas últimas décadas, uma série de métodos de análise e 
especificação de requisitos foi desenvolvida, entretanto, poucas são as propostas que 
visam uma sistematização da elicitação de requisitos de forma a tornar esta atividade 
menos subjetiva (SANTANDER; CASTRO, 2002). 
 
No paradigma da orientação a objeto a análise de requisitos tem sido feita com base 
num elemento de modelagem da UML chamado de Caso de Uso. Embora existam 
algumas heurísticas propostas para identificação de casos de uso, como as 
apresentadas em Schneider e Winters (1998), Jacobson et al (1999), e em Lilly (1999), 
não existem métodos estabelecidos que tornem esta atividade mais sistemática. Os 
casos de uso são geralmente identificados em entrevistas com futuros usuários do 
sistema e responsáveis pelo negócio, realizadas por analistas de sistemas. 
 
17 
 
Segundo PRESSMAN (1995) cada método de análise tem uma notação e um ponto de 
vista únicos porém todos eles relacionam-se com um conjunto de princípios 
fundamentais: 
 
1. O domínio de informação de um problema deve ser representado e compreendido 
para que a função possa ser entendida mais completamente. 
2. Modelos que descrevam a informação, função e comportamento do sistema devem 
ser desenvolvidos para que a informação possa ser comunicada completamente. 
3. Os modelos (e o problema) devem ser divididos em partições, de maneira que 
revele os detalhes em forma de camadas (ou hierarquicamente), e assim reduzir a 
complexidade. 
4. O processo de análise deve mover-se da informação essencial para os detalhes de 
implementação para acomodar as restrições lógicas impostas por requisitos de 
processamento e as restrições físicas impostas por outros elementos do sistema. 
 
 
2.5. UML 
 
A UML foi adotada pela OMG (Object Management Group) em 1997 como linguagem 
padrão para a modelagem de sistemas orientados a objeto. Ela é uma linguagem para 
especificação, visualização, construção, e documentação de artefatos de sistemas de 
software, tão bem como para a modelagem de negócios e outros sistemas que não de 
software. Ela representa uma coleção das melhores práticas de engenharia que 
provaram sucesso na modelagem de sistemas grandes e complexos. (OMG, 2002) 
 
Os principais objetivos na definição da UML (OMG, 2002) são: 
 
1. Prover aos usuários uma linguagem de modelagem visual de forma que eles 
pudessam desenvolver e trocar modelos; 
2. Prover mecanismos de extensão e especialização para estender o centro dos 
conceitos; 
18 
 
3. Ser independente de uma linguagem de programação específica e de processos de 
desenvolvimento; 
4. Prover uma base formal para o entendimento da linguagem de modelagem; 
5. Incentivar o crescimento de ferramentas de orientação a objeto no mercado; 
6. Suportar desenvolvimento de conceitos de alto nível como colaboração, arquiteturas 
de referência, padrões, e componentes; 
7. Integrar as melhores práticas. 
 
Muitos usuários de outros métodos (BOOCH, OMT, FUSION, entre outros) adotaram a 
UML. A maioria das ferramentas de modelagem de sistemas têm implementado o 
suporte à linguagem, entre elas o Rose da Rational e o Together da Together Soft. 
 
A UML padroniza notação para descrever modelos, mas não padroniza um processo 
para produzir aquelas descrições (uma ordem de atividades bem definidas, um conjunto 
de artefatos produzidos, e meios de controlar e monitorar o trabalho). A UML pode ser 
usada por diversos processos de desenvolvimento distintos, mais ou menos 
formalmente especificados. 
 
Com relação a estrutura da UML, conforme apresentado em (BOOCH; JACOBSON; 
RUMBAUGH, 2000), o vocabulário da UML abrange três tipos básicos de blocos de 
construção: 
 
1- Itens 
2- Relacionamentos 
3- Diagramas 
 
Os itens são as abstrações identificadas em um modelo; os relacionamentos reúnem 
esses itens; os diagramas agrupam coleções interessantes de itens. 
 
2.5.1. Itens da UML 
 
Existem quatro tipos de itens na UML: 
19 
 
1- Itens estruturais 
2- Itens comportamentais 
3- Itens de agrupamentos 
4- Itens de anotação 
 
Estes itens constituem os blocos de construção básicos orientados a objetos da UML e 
são utilizados para escrever modelos bem-formados. 
 
2.5.1.1. Itens estruturais 
 
São os substantivos utilizados em modelos da UML. São as partes mais estáticas do 
modelo, representando elementos conceituais ou físicos. Ao todo existem sete tipos de 
itens estruturais: 
Classes - são descrições de conjuntos de objetos que compartilham os mesmos 
atributos, operações, relacionamentos e semântica. 
 
Interface - é uma coleção de operações que especificam serviços de uma classe 
ou componente. Portanto, uma interface descreve o comportamento 
externamente visível desse elemento. Uma interface poderá representar todo o 
comportamento de uma classe ou componente,como também apenas parte 
desse comportamento. A interface define um conjunto de especificações de 
operações (suas assinaturas), mas nunca um conjunto de implementações de 
operações. 
 
Colaborações - definem interações e são sociedades de papéis e outros 
elementos que funcionam em conjunto para proporcionar um comportamento 
cooperativo superior à soma de todos os elementos. Portanto, as colaborações 
contêm dimensões estruturais, assim como comportamentais. Uma determinada 
classe poderá participar em várias colaborações. Assim, essas colaborações 
representam a implementação de padrões que formam um sistema. 
 
20 
 
Caso de Uso - é a descrição de um conjunto de seqüência de ações realizadas 
pelo sistema que proporciona resultados observáveis de valor para um 
determinado ator. Um caso de uso é utilizado para estruturar o comportamento 
de itens em um modelo. Um caso de uso é realizado por uma colaboração. 
 
Os outros três itens restantes – classes ativas, componentes e nós – são semelhante a 
classes, ou seja, descrevem conjuntos de objetos que compartilham os mesmos 
atributos, operações, relacionamentos e semânticas. Porém, esses três são 
suficientemente diferentes e necessários para a modelagem de certos aspectos de 
sistemas orientados a objetos e, portanto merecem um tratamento especial: 
 
Classes ativas - são classes cujos objetos têm um ou mais processos ou threads 
e, portanto, podem iniciar a atividade de controle. Uma classe ativa é semelhante 
a uma classe, exceto pelo fato de que seus objetos representam elementos cujo 
comportamento é concorrente com o de outros elementos. 
 
Componentes - são partes físicas e substituíveis de um sistema, que 
proporcionam a realização de um conjunto de interfaces. Em um sistema, 
encontram-se diferentes tipos de componentes próprios da implantação, como os 
componente COM+ ou Java Beans, assim como componentes que são artefatos 
do processo de desenvolvimento, como os arquivos de código-fonte. Tipicamente 
os componentes representam o pacote físico de elementos lógicos diferentes, 
como classes, interfaces e colaborações. 
 
Nó - é um elemento físico existente em tempo de execução que representa um 
recurso computacional, geralmente com pelo menos alguma memória e, 
freqüentemente , capacidade de processamento. Um conjunto de componentes 
poderá estar contido em um nó e também poderá migrar de um nó para outro. 
 
Esses sete elementos – classes, interfaces, colaborações, casos de uso, classes ativas, 
componentes e nós – são os itens estruturais básicos que se pode incluir em um 
modelo da UML. Também existem variações desses sete elementos, como atores, 
21 
 
sinais e utilitários (tipos de classes), processos e threads (tipos de classes ativas), e 
aplicações, documentos, arquivos, bibliotecas, páginas e tabelas (tipos de 
componentes). 
 
2.5.1.2. Itens comportamentais 
 
Os itens comportamentais são as partes dinâmicas dos modelos de UML. São os 
verbos de um modelo, representando comportamentos no tempo e no espaço. Ao todo, 
existem dois tipos principais de itens comportamentais: 
 
Interação - é um comportamento que abrange um conjunto de mensagens 
trocadas entre um conjunto de objetos em determinado contexto para a 
realização de propósitos específicos. O comportamento de uma sociedade de 
objetos ou de uma operação individual poderá ser especificado por meio de uma 
interação. As interações envolvem outros elementos, inclusive mensagens, 
sequências de ações (os comportamentos chamados pelas mensagens) e 
ligações (as conexões entre objetos). 
 
Máquina de estado - é um comportamento que especifica as sequências de 
estados pelos quais objetos ou interações passam durante sua existência em 
reposta a eventos, bem como suas respostas a esses eventos. O 
comportamento de uma classe individual ou de uma colaboração de classes 
pode ser especificado por meio de uma máquina de estados. Um máquina de 
estado abrange outros elementos, incluindo estados, transições (o fluxo de um 
estado a outro), eventos (itens que disparam uma transição) e atividades (as 
respostas às transições). 
 
Semanticamente, esses itens comportamentais costumam estar conectados a vários 
elementos estruturais, classes principais, colaborações e objetos. 
 
22 
 
2.5.1.3. Itens de agrupamento 
 
Os itens de agrupamento são as partes organizacionais dos modelos de UML. São os 
blocos em que os modelos podem ser decompostos. Ao todo, existe apenas um tipo 
principal de itens de agrupamento, chamado pacote: 
 
Pacote - é um mecanismo de propósito geral para a organização de elementos 
em grupos. Os itens estruturais, os itens comportamentais e até outros itens de 
grupos podem ser colocados em pacotes. Ao contrário dos componentes (que 
existem em tempo de execução), um pacote é puramente conceitual (o que 
significa que existe apenas em tempo de desenvolvimento). 
 
Os pacotes são itens de agrupamento básico, servem para organizar modelos de UML. 
Também existem variações, como frameworks, modelos e subsistemas (tipos de 
pacotes). 
 
2.5.1.4. Itens de anotação 
 
Os itens de anotação são as partes explicativas dos modelos de UML. São 
comentários, incluídos para descrever, esclarecer e fazer alguma observação sobre 
qualquer elemento de modelo. Existe um único tipo de item de anotação, chamado 
nota: 
 
Nota - é apenas um símbolo para representar restrições e comentários anexados 
a um elemento ou a uma coleção de elementos. 
 
Esse elemento é o único item de anotação básico que se pode incluir em um modelo 
de UML. Geralmente são utilizadas para aprimorar os diagramas com restrições ou 
comentários que possam ser mais bem expressos por um texto formal ou informal. 
Também existem variações desse elemento, como os requisitos (que especificam 
determinado comportamento desejado sob uma perspectiva externa ao sistema). 
 
23 
 
2.5.2. Relacionamentos na UML 
 
Existem quatro tipos de relacionamentos na UML: 
 
1- Dependência 
2- Associação 
3- Generalização 
4- Realização 
 
Esses relacionamentos são os blocos relacionais básicos de construção da UML: 
 
Dependência - é um relacionamento semântico entre dois itens, nos quais a 
alteração de um (o item independente) pode afetar a semântica do outro (o outro 
dependente). 
 
Associação - é um relacionamento estrutural que descreve um conjunto de 
ligações, em que as ligações são conexões entre objetos. A agregação é um tipo 
especial de associação, representando um relacionamento estrutural entre o todo 
e suas partes. 
 
Generalização - é um relacionamento de especialização/generalização, nos 
quais os objetos dos elementos especializados (os filhos) são substituíveis por 
objetos do elemento generalizado (os pais). Dessa maneira, os filhos 
compartilham a estrutura e o comportamento dos pais. 
 
Realização - é um relacionamento semântico entre classificadores, em que um 
classificador especifica um contrato que outro classificador garante executar. Os 
relacionamentos de realizações serão encontrados em dois locais: entre 
interfaces e as classes ou componentes que as realizam; e entre casos de uso e 
as colaborações que os realizam. 
 
24 
 
Também existem variações desses quatro elementos, como refinamentos, rastros, 
inclusões e extensões (para dependências). 
 
2.5.3. Diagramas da UML 
 
Um diagrama é a apresentação gráfica de um conjunto de elementos, geralmente 
representadas como gráficos de vértices (itens) e arcos (relacionamentos). São 
desenhados para permitir a visualização de um sistema sob diferentes perspectivas; 
nesse sentido, um diagrama constitui uma projeção de um determinado sistema. Em 
todos os sistemas, com exceção dos mais triviais, um diagrama representa uma visão 
parcial dos elementos que compõem o sistema. O mesmo elemento pode aparecer em 
todos os diagramas, em apenas alguns (o caso maiscomum) ou em nenhum diagrama 
(um caso muito raro). Na teoria, um diagrama pode conter qualquer combinação de 
itens e de relacionamentos. Na prática, porém, aparecerá um pequeno número de 
combinações comuns, que são consistentes com as cinco visões mais úteis da 
arquitetura de um sistema complexo de software apresentadas no item 2.3. A UML 
inclui nove diagramas: 
 
1- Diagrama de classes 
2- Diagrama de objetos 
3- Diagrama de casos de uso 
4- Diagrama de seqüência 
5- Diagrama de colaborações 
6- Diagrama de gráficos de estados 
7- Diagrama de atividades 
8- Diagrama de componentes 
9- Diagrama de implantação 
 
Diagrama de classe - exibe um conjunto de classes, interfaces e colaborações, bem 
como seus relacionamentos. Esses diagramas são encontrados com maior frequência 
em sistemas de modelagem orientados a objeto e abrangem uma visão estática da 
estrutura do sistema. 
25 
 
Diagrama de objetos - exibe um conjunto de objetos e seus relacionamentos. 
Representa retratos estáticos de instâncias de itens encontrados em diagrama de 
classes. São diagramas que abrangem a visão estática da estrutura ou do processo de 
um sistema, como ocorre nos diagramas de classes, mas sob perspectiva de casos 
reais ou de protótipos. 
 
Diagrama de caso de uso - exibe um conjunto de caso de uso e atores (um tipo 
especial de classe) e seus relacionamentos. Diagramas de caso de uso abrangem a 
visão estática de casos de uso do sistema. Esses diagramas são importantes 
principalmente para a organização e a modelagem de comportamentos do sistema. 
 
Tanto os diagramas de seqüências como os de colaborações são tipos de diagramas 
de interações. Um diagrama de interação exibe uma interação, consistindo de um 
conjunto de objetos e seus relacionamentos, incluindo as mensagens que podem ser 
trocadas entre eles. Diagramas de interações abrangem a visão dinâmica de um 
sistema. 
 
Diagrama de seqüências - é um diagrama de interações cuja ênfase está na ordenação 
temporal das mensagens. 
 
Diagrama de colaborações - é um diagrama de interação cuja ênfase está na 
organização estrutural dos objetos que enviam e recebem mensagens. Os diagramas 
de seqüências e de colaborações são isomórficos, o que significa que você poderá 
transformar o diagrama de um tipo em um diagrama de outro tipo. 
 
Diagramas de gráfico de estados - exibem uma máquina de estados, formada por 
estados, transições, eventos e atividades. Os diagramas de gráfico de estados 
abrangem a visão dinâmica de um sistema. São importantes principalmente para a 
modelagem de comportamentos de uma interface, classe ou colaboração e para dar 
ênfase a comportamentos de um objeto ordenados por eventos, o que é de grande 
ajuda para a modelagem de sistemas reativos. 
 
26 
 
Diagrama de atividade - é um tipo especial de diagrama de gráfico de estado, exibindo 
o fluxo de uma atividade para outra no sistema. Abrange a visão dinâmica do sistema e 
é importante principalmente para a modelagem da função de um sistema. Dá ênfase ao 
fluxo de controle entre objetos. 
 
Diagrama de componente - exibe as organizações e as dependências existentes em um 
conjunto de componentes. Abrange a visão estática da implementação de um sistema. 
Está relacionado aos diagramas de classes, pois tipicamente os componentes são 
mapeados para uma ou mais classes, interface ou colaborações. 
 
Diagrama de implantação - mostra a configuração dos nós de processamento em tempo 
de execução e os componentes neles existentes. Abrange a visão estática do 
funcionamento de uma arquitetura. Está relacionado aos diagramas de componentes, 
pois tipicamente um nó inclui um ou mais componentes. 
 
2.5.4. Adornos 
 
Em sua maioria, os elementos da UML têm uma notação gráfica única e direta, que 
proporciona uma apresentação visual dos aspectos mais importantes do elemento. Por 
exemplo, a notação para uma classe é intencionalmente projetada para ser desenhada 
facilmente, pois as classes são os elementos mais comumente encontrados em 
sistemas de modelagem orientados a objetos. A notação de classe também expõe os 
aspectos mais importantes da classe, ou seja, seu nome, atributos e operações. 
 
A especificação da classe pode incluir outros detalhes, como se a classe é abstrata ou 
como é a visibilidade de seus atributos e operações. Muitos desses detalhes podem ser 
representados como adornos gráficos ou textuais para a notação retangular básica da 
classe. 
 
Todos os elementos da notação da UML são iniciados com um símbolo básico, ao qual 
pode ser acrescentada uma variedade de adornos específicos desse símbolo. 
 
27 
 
2.5.5. Mecanismos de extensibilidade 
 
A UML fornece uma linguagem-padrão para a elaboração de estrutura de projetos de 
software, mas não é possível que uma única linguagem fechada seja suficiente para 
expressar todas as nuances possíveis de todos os modelos em qualquer domínio o 
tempo todo. Por isso, a UML permite que a linguagem seja ampliada de uma maneira 
controlada através de mecanismos de extensão. 
 
Estes mecanismos têm a intenção de servirem aos seguintes propósitos: 
 
• Podem ser usados para adicionar elementos de modelagem na criação de modelos; 
• São usados nas especificações da UML para definir itens padrões não considerados 
ou complexos demais para serem modelados diretamente pelos elementos do meta-
modelo UML; 
• São usados para definir processos específicos ou implementação de extensões de 
linguagens específicas; 
• São usados para unir arbitrariamente informações semânticas e não semânticas a 
elementos do modelo. 
 
Os mecanismos de extensibilidade da UML incluem: 
 
Estereótipos - definem novos blocos construtores na UML baseados em 
blocos existentes. Embora não seja possível adicionar novos tipos de 
elementos, todos os elementos da UML podem ser customizados, 
estendidos, ou adaptados através da definição e nomeação de estereótipos. 
 
Valores atribuídos - estendem um elemento da UML através de uma etiqueta 
(tag) e um valor (value). Por exemplo pode ser definida um valor atribuído 
para expressar a versão de uma determinada classe. 
 
Restrições - são regras aplicadas aos modelos UML. Podem ser aplicadas 
para apenas um ou para vários elementos do modelo. Por exemplo pode-se 
28 
 
definir através de uma restrição um condicionamento numa associação entre 
duas classes. 
 
A UML possui um grande potencial de expressão e modelagem podendo ser 
amplamente aplicada sem extensões, portanto empresas e projetos devem definir 
extensões apenas quando for realmente necessário introduzir novas notações e 
terminologias. Os conceitos fundamentais não devem ser mudados mais que o 
estritamente necessário (OMG, 2001). 
 
No capítulo 3 será apresentada a disciplina de modelagem de negócio e como a UML 
tem sido proposta como linguagem para a construção dos modelos neste domínio. 
 
A seção a seguir irá apresentar o Processo Unificado, uma metodologia baseada no 
modelo iterativo e incremental e que será usada como base para o desenvolvimento 
deste trabalho. 
 
2.6. O Processo Unificado 
 
O Processo Unificado (UP) é um processo estabelecido para o desenvolvimento de 
software que resultou de três décadas de desenvolvimento e uso prático. Jacobson et 
al(1999) apresenta as origens do UP desde o processo Objectory (com primeira versão 
em 1987) passando pelas contribuições do Processo Rational Objectory (em 1997) até 
o Processo Unificado da Rational (RUP) (em 1998). 
 
O propósito do UP , como qualquer outro processo de desenvolvimento, é determinar 
um conjunto de atividades necessárias para transformar requisitos em sistemas de 
software. Ele utiliza a UML como linguagem para a modelagem dos artefatos de 
software produzidos ao longo do processo de desenvolvimento. 
 
O processo Unificado representa a disponibilização do RUP (que é proprietário da 
Rational) ao público geral. (JACOBSON;BOOCH; RUMBAUGH, 1999) 
 
 
29 
 
2.6.1. Caractéristicas do UP 
 
O UP é fundamentado em três boas práticas: dirigido por caso de uso, centrado em 
arquitetura, e iterativo e incremental. Estas práticas são descritas a seguir, conforme 
apresentadas em RUP(2001): 
 
Dirigido por caso de uso: 
 
Os casos de uso definidos para um sistema são a base de todo o processo de 
desenvolvimento. Baseados no modelo de caso de uso, os desenvolvedores criam uma 
série de modelos de projeto e implementações que realizam no sistema as 
funcionalidades dos casos de uso. Os testes também são realizados de forma a 
verificar se os componentes implementados implementam corretamente as 
funcionalidades dos casos de uso. 
 
Centrado em arquitetura: 
 
Os casos de uso orientam o UP durante todo o ciclo de vida, mas as atividades de 
projeto são centralizadas na noção da arquitetura de software. O foco principal das 
iterações iniciais do processo, principalmente na fase de Elaboração, é produzir e 
validar uma arquitetura de software, que no ciclo de desenvolvimento inicial toma a 
forma de um protótipo arquitetural executável que gradualmente evolui até se tornar o 
sistema final em iterações posteriores. 
 
Iterativo e Incremental: 
 
O UP utiliza pequenos ciclos de projeto (mini-projetos) que correspondem a uma 
iteração e que resultam em um incremento no software. Iterações referem-se a passos 
no processo, e incrementos a evoluções do produto. Esta característica foi apresentada 
anteriormente no item 2.2. Sua estrutura portanto é composta por Fases (relacionadas 
às metas ao longo do tempo) e Workflows (relacionadas à natureza das atividades). 
Cada Workflow é responsável por gerar seus respectivos artefatos através de um 
30 
 
conjunto de atividades. Cada Artefato corresponde a uma documentação (como um 
modelo) ou outro objeto de valor a ser criado no desenvolvimento (como um 
componente de software). 
 
Por ser iterativo, cada fase percorre todo o conjunto de fluxos de trabalho (workflows). 
Por ser incremental, cada iteração atualiza os artefatos gerados nas iterações 
anteriores. Cada fase possui uma maior ênfase em determinados fluxos de trabalho. A 
Figura 5, conhecida como “Gráfico das Baleias” apresenta a ênfase que é cada em 
cada fase. 
 
Figura 5 – O “Gráfico das Baleias” (Adaptado de RUP, 2002) 
Na figura podem ser observadas duas dimensões: 
• 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 
lógica, por natureza. 
A primeira dimensão representa o aspecto dinâmico do processo quando ele é 
aprovado e é expressa em termos de fases, iterações e marcos. 
A segunda dimensão representa o aspecto estático do processo, como ele é descrito 
em termos de componentes, atividades, fluxos de trabalho, artefatos e papéis do 
processo. 
31 
 
O gráfico mostra como a ênfase varia através do tempo. Por exemplo, nas iterações 
iniciais, dedica-se mais tempo aos requisitos. Já nas iterações posteriores, gasta-se 
mais tempo com implementação. 
 
2.6.2. Fases 
 
A partir de uma perspectiva de gerenciamento, o ciclo de vida de software do UP é 
dividido em quatro fases seqüenciais. Cada fase refere-se a uma determinada meta a 
ser atingida ao longo do desenvolvimento. As fases correspondem a períodos 
determinados por pontos de controle ao longo do tempo. Em cada ponto de controle, ou 
seja, ao final de cada fase, é esperado um determinado estado de alguns artefatos do 
desenvolvimento. Em cada final de fase é executada uma avaliação para determinar se 
os objetivos da fase foram alcançados. Uma avaliação satisfatória permite que o projeto 
passe para a próxima fase. As fases e seus marcos são apresentados na Figura 6. 
 
Figura 6 - As fases e os marcos de um projeto no UP.(Adaptado 
do RUP 2002) 
 
Concepção: 
O objetivo da fase de Concepção é conseguir a simultaneidade entre o cliente e 
o desenvolvedor nos objetivos do ciclo de vida do projeto. A Fase de Concepção 
é de importância primária para novos esforços de desenvolvimento quando há 
um negócio significativo e riscos requeridos que precisam ser esclarecidos antes 
do procedimento do projeto. Para projetos focados ou aprimoramento de um 
sistema já existente, a fase de Concepção é mais breve, mas ainda deve estar 
focalizado para assegurar que o projeto ainda é válido e possível de ser feito. 
32 
 
Dentre os objetivos da fase de Concepção estão: 
• Uma visão operacional do negócio onde o sistema atuará; 
• A discriminação dos dados de uso críticos do sistema, os cenários 
primários de operação que levará as trocas principais do projeto; 
• Exibir e talvez demonstrar pelo menos uma arquitetura candidata contra 
alguns cenários primários; 
• Estimar o custo que abrange tudo e o Cronograma Geral para todo o 
projeto (e estimativas mais detalhadas para a elaboração da fase posterior 
que virá imediatamente a seguir); 
• Estimar os riscos potenciais; 
• Estabelecer o escopo do software do projeto e suas condições limites; 
 
Elaboração: 
O objetivo da fase de Elaboração é definir uma arquitetura do sistema preliminar 
para prover uma base estável para o desenvolvimento do projeto e posteriores 
esforços de implementação na fase de Construção. A arquitetura evolui pela 
consideração dos requisitos mais significativos (aqueles que têm um grande 
impacto na arquitetura do sistema) e uma estimativa de risco. A estabilidade da 
arquitetura é avaliada através de um ou mais protótipos de arquitetura. 
Dentre os objetivos da fase de Elaboração estão: 
• Assegurar que a arquitetura, os requerimentos e os planos sejam 
bastante estáveis, e os riscos sejam suficientemente suavizados para que 
se possa detalhar o custo e o Cronograma Geral do desenvolvimento por 
completo; 
• Endereçar todos os riscos significantes da arquitetura do projeto; 
• Estabelecer a linha de base da arquitetura derivada pelo endereçamento 
dos cenários significantes da arquitetura, que expõe tipicamente os altos 
riscos técnicos do projeto; 
• Produzir um protótipo evolucionário de produção e componentes de 
qualidade, como também possivelmente um ou mais protótipos 
33 
 
exploratórios, disponibilizando protótipos para suavizar riscos específicos 
como: 
o Design/ requisitos de trocas 
o Reuso de componentes 
o A demonstração para investidores, clientes e usuários finais 
• Demonstrar que a linha de base da arquitetura vai suportar os 
requisitostos do sistema num custo razoável e num tempo razoável; 
• Estabelecer um ambiente de suporte. 
 
Construção: 
 
O objetivo da fase de Construção é esclarecer os requisitos restantes e 
completar o desenvolvimento do sistema baseado na arquitetura de base. A fase 
de construção é sobretudo um processo de manufatura, onde a ênfase é dada no 
gerenciamento de recursos e controle de operações para otimizar custos, 
programação, e qualidade. 
 
Dentre os objetivos da fase de Construção estão: 
 
• Minimização de custos de desenvolvimento pela otimização de 
recursos e evitando re-trabalhos desnecessários; 
• Alcançar qualidade adequada de forma rápida e prática; 
• Obter versões utilizáveis (alpha, beta, e outras versões de teste) rápido 
e praticamente; 
• Completar a análise, projeto, desenvolvimento e teste de todas as 
funcionalidades requeridas; 
• Desenvolver iterativamente e incrementalmente um produto completo, 
pronto para ser transmitido aos usuários. Isto implica em descrever os 
use cases e outros requerimentos restantes, concluir o projeto, 
completar a implementação, e testar o software; 
• Decidir se o software, os locais e os usuários estão todos prontos para 
a aplicação a ser implantada; 
34 
 
• Alcançar algum grau de paralelismo no trabalho de equipes de 
desenvolvimento. Mesmo em pequenos projetos, geralmente existemcomponentes que podem ser desenvolvidos independentemente uns 
dos outros, permitindo um paralelismo natural entre equipes. Este 
paralelismo pode acelerar significativamente as atividades de 
desenvolvimento, mas também aumenta a complexidade de 
gerenciamento de recursos e sincronização de fluxo de trabalho. Ter 
uma arquitetura robusta é essencial para atingir um paralelismo 
significativo. 
 
Transição: 
 
O foco da fase de transição é assegurar que o software está pronto para o 
usuário final. A fase de transição pode transpor várias iterações, e inclui testes 
do produto na preparação para liberação, e realizar ajustes mínimos baseados 
no retorno dos usuários. Neste ponto do ciclo de vida, o retorno dos usuários 
deve focar o ajuste fino do produto, na configuração, instalação e usabilidade. 
 
Ao final do ciclo de vida da fase Transição os objetivos devem ter sido 
alcançados e o projeto concluído. Em alguns casos, o fim de um ciclo de vida de 
Transição corrente pode coincidir com o início de outro ciclo de vida do mesmo 
produto, levando a uma nova geração ou versão do produto. 
 
Entra-se na fase de Transição quando um projeto está maduro o suficiente para 
ser implantado no domínio do usuário final. Isto tipicamente requer que um 
subconjunto utilizável do sistema tenha sido terminado com um nível de 
qualidade aceitável e com documentação para o usuário (Manual do Usuário). 
 
Dentre os objetivos da fase de Transição estão: 
 
• Testes Beta para validar o novo sistema frente expectativas dos 
usuários; 
35 
 
• Operações paralelas de substituição do sistema legado; 
• Treinamento dos usuários; 
• Conserto de bugs; 
• Preparar infra-estrutura de Hardware e Software do Cliente para 
receber o novo sistema. 
 
2.6.3. Workflows 
 
Cada uma das quatro fases do UP é adicionalmente dividida em iterações e finalizada 
com um ponto de checagem que verifica se os objetivos daquela fase foram 
alcançados. Toda iteração é organizada em termos de workflows de processo, que são 
conjuntos de atividades realizadas por responsáveis que produzem artefatos, conforme 
ilustrado na Figura 5. Os principais workflows de processo são descritos a seguir: 
 
Modelagem de negócio: 
 
Provê um entendimento comum entre as partes interessadas no sistema sobre quais os 
processos de negócio que devem ser apoiados. A modelagem dos processos de 
negócio é feita através dos casos de uso de negócio. 
 
No UP, descrito em (JACOBSON; BOOCH; RUMBAUGH, 1999) não havia o workflow 
de modelagem de negócios, partindo-se diretamente para o workflow de requisitos. 
Entretanto, este workflow é proposto no RUP e será comentado no capítulo 3. 
 
Requisitos: 
 
Objetiva capturar os requisitos que serão atendidos pelo produto de software. Nas fases 
de iniciação e elaboração, a ênfase será maior neste workflow de requisitos, pois o 
objetivo destas fases é o entendimento e a delimitação do escopo do produto de 
software. O Workflow Levantamento de Requisitos aborda as seguintes atividades: 
� Identificar casos de uso; 
� Priorizar casos de uso; 
36 
 
� Detalhar casos de uso; 
� Estruturar o modelo de caso de uso. 
 
Análise e Projeto: 
 
Objetiva compreender mais precisamente os casos de uso definidos no workflow de 
requisitos, produzindo um modelo já voltado para a implementação que deverá estar 
adequado ao ambiente de implementação. Este workflow será bastante utilizado na 
fase de elaboração e durante o início da fase de construção. 
 
Implementação: 
 
Objetiva a organização do código em termos de implementação de subsistemas, 
implementa as classes e objetos em termos de componentes, testa os componentes em 
termos de unidades e integra os códigos produzidos. Este workflow é bastante utilizado 
na fase de construção. 
 
Teste: 
 
Objetiva analisar, através de testes, se os requisitos foram atendidos e que os defeitos 
serão removidos antes da implantação. Os modelos de testes são criados para 
descrever como os testes serão realizados. Sua ênfase será maior no final da fase de 
construção e no início da fase de transição. 
 
Implantação: 
 
Objetiva produzir releases do produto e entregá-los aos usuários finais. Isto pode incluir 
atividades de beta-teste, migração de dados ou software existente e aceitação formal. 
 
 
 
 
37 
 
2.6.3.1. Principais workflows de Apoio do RUP 
 
Os workflows de apoio foram definidos no RUP (2002) como forma de suprir algumas 
das lacunas deixadas pelo UP (JACOBSON;BOOVH;RUMBAUGH,1999). Seu objetivo 
é auxiliar a execução dos workflows principais. São eles: 
 
Configuração e Gerenciamento de Mudanças: Controla as diversas versões 
dos artefatos produzidos durante o projeto, garantindo sua integridade. Ou seja, 
assegura que os resultados não sejam conflitantes. 
 
Gerência de Projeto: Fornece um framework para a gerência de projetos, 
orientações para planejamento, alocação de recursos e gerência de riscos. 
 
Ambiente: Fornece a descrição para a organização do ambiente de 
desenvolvimento em termos de processos e ferramentas. 
 
 CAPÍTULO 3 
Modelagem de Negócio 
 
3.1. Introdução 
 
As organizações empresariais são sistemas complexos e como tal podem ser mais 
facilmente entendidas e gerenciadas através de modelos que tornem a abstração da 
realidade mais tangível. O conceito de ponto de vista sistêmico é o simples 
reconhecimento de que qualquer empresa é um sistema composto por partes, cada 
uma das quais tendo suas próprias metas. O administrador percebe que ele só pode 
alcançar as metas globais da empresa se visualizar todo o sistema, procurar 
compreender e medir as inter-relações e integrá-las de modo que capacite a empresa a 
buscar suas metas eficientemente (MANCUSO, 1998). 
 
Modelagem de empresa (tratada neste trabalho como sinônimo para modelagem de 
negócio) é um termo genérico que cobre um conjunto de atividades, métodos, e 
ferramentas relacionadas ao desenvolvimento de modelos para vários aspectos de uma 
empresa (PETRIE, 1992). Segundo Vernadat (1996) um modelo é uma representação 
significativa de algum assunto. É uma abstração da realidade expressa em termos de 
algum formalismo (ou linguagem) definido por construtores de modelagem para o 
propósito do usuário. Um modelo de empresa é um conjunto consistente de modelos de 
propósitos especiais e complementares descrevendo as várias facetas de uma empresa 
para satisfazer alguma finalidade de alguns usuários do negócio. 
 
Toda empresa, seja ela pequena ou grande, possui um modelo de empresa, porém, na 
maioria dos casos este modelo é precariamente formalizado. O modelo se encontra na 
forma de gráficos organizacionais estabelecidos por gerentes, documentação de 
procedimentos operacionais, textos de regulamentações, e em muitas outras formas 
como banco de dados e arquivos entre outras. Porém, uma parte do modelo permanece 
apenas na mente das pessoas envolvidas no sistema, não sendo formalizado e 
documentada. Métodos e ferramentas são necessários para capturar, formalizar, 
39 
 
manter, e usar este conhecimento para um melhor controle e operação de sistemas 
complexos como os de empresas de manufatura. 
 
De acordo com a teoria do controle, toda vez que um sistema precisa ser controlado ou 
analisado, é necessário um modelo. Os modelos também são necessários para as 
atividades de tomada de decisão (PETRIE, 1992). Através de modelos de empresa o 
tomador de decisão pode ver a empresa com um certo tamanho e velocidade de 
entendimento muito maior, permitindo a integração dos componentes da empresa 
(VERNADAT, 1996). 
 
Outros exemplos de finalidade da modelagem de empresa são: projeto funcional de um 
novo sistema de manufatura, análise de performance de uma célula de manufatura, 
análise de custo de um processo existente, e re-projeto de um sistema de informação 
empresarial. (CAMPOS, 1998) 
 
Assim como as arquiteturas de software,uma arquitetura de negócio pode ser criada 
para analisar o negócio a luz de diferentes aspectos. Uma arquitetura de negócio é 
representada por várias vistas e cada uma destas apresentando um conjunto de 
informações significativas, suprimindo outras, e portanto facilitando a análise através de 
modelos mais simples. A vista mais comum encontrada em arquiteturas de negócio é a 
vista de processos de negócio. 
 
3.2. Modelagem por Processos de Negócio 
 
Os processos de negócios definem como as empresas operam para alcançarem seus 
objetivos. Como exemplos típicos desses processos podem ser citados: Planejamento 
estratégico, Vendas, Fabricação e Atendimento a Clientes, entre outros. 
 
Rozenfeld (2001) define processo de negócio como um fenômeno que ocorre dentro 
das empresas e compreende um conjunto de atividades realizadas, associadas às 
informações que manipulam, utilizando os recursos e a organização da empresa. Forma 
40 
 
uma unidade coesa e deve ser focalizado em um tipo de negócio, que normalmente 
está direcionado a um determinado mercado/cliente, com fornecedores bem definidos. 
 
Segundo Johansson et al (1995) um processo de negócio é um conjunto de atividades 
ligadas que tomam um insumo de entrada e o transformam para criar um resultado de 
saída. Teoricamente, a transformação que nele ocorre deve adicionar valor e criar um 
resultado que seja mais útil e eficaz ao recebedor acima ou abaixo da cadeia. 
 
A ênfase atual em se definir os processos de negócios das empresas advém da febre 
da Reengenharia. Pode-se dizer que a Reengenharia é que forneceu este termo com o 
significado atual de conjunto de atividades, que normalmente são realizadas por 
diversos departamentos de uma empresa (ROZENFELD, 2001). 
 
Reengenharia é um termo criado pelo professor de Tecnologia Michael Hammer, para 
designar uma nova abordagem de implantação de sistemas diferente da que se usava 
até então. Em síntese, nessa nova abordagem Hammer preconiza que antes de se 
tentar organizar um processo por meio do emprego de tecnologias da informação pura 
e simplesmente, perpetuando a desordem ou tentando engessá-la pelo uso de algum 
novo sistema ou dispositivo, deve-se literalmente, abandonar a forma como se vinha 
operando determinado processo e recriá-lo completamente; novo e melhor, para só 
então implantar uma nova tecnologia da informação, que dessa forma estaria sendo 
mais bem aproveitada. (CRUZ, 2000) 
 
As definições dos processos são usadas para entender o negócio, ver ameaças ou 
oportunidades, melhorar ou inovar, e servir como base para outros modelos (como para 
modelos de sistemas de software que dão suporte ao negócio). (ERIKSSON; HANS-
ERIK; PENKER, 2000) 
 
A modelagem por processo surge portanto da necessidade de se delinear limites da 
abrangência de atuação e da dinâmica de interação entre os recursos da empresa em 
toda sua extensão de atividades desde o fornecedor até o cliente. Tal delineação não 
era alcançada com modelos baseados simplesmente na estrutura organizacional da 
41 
 
empresa, que possui uma visão departamental. A falta de capacidade de representação 
da realidade da empresa através de modelos departamentais começou a ser 
evidenciada pela dificuldade que os analistas de sistemas tinham em definir o contexto 
e limites do sistema. 
 
Feliciano (1996) observa que a grande dificuldade, encontrada pelos gerenciadores de 
projetos de implantação de sistemas de informação, em cumprir cronogramas e 
levantamento de custos está relacionada à dificuldade de delimitação de contexto do 
sistema. Decompor a empresa em funções de negócio, sem se preocupar com uma 
visão organizacional, facilita a definição do contexto onde o sistema de informação irá 
atuar. As funções de negócio propostas por Feliciano (1996) se mostram na prática 
como a descrição de processos de negócios. 
 
É necessário portanto que as metodologias de modelagem de negócios atuais tenham 
em sua essência o tratamento baseado em processos. 
 
3.3. Modelagem de Negócio com Orientação a Objeto 
 
A técnica de modelagem orientada a objetos é uma ferramenta poderosa e universal, 
apesar de ser baseada em apenas um construtor de modelagem: o objeto. A principal 
característica da técnica é o encapsulamento, combinando a modelagem funcional e a 
modelagem de informação em um paradigma unificado. Objetos são identificados 
unicamente, possuem estados (uma estrutura de dados), e possivelmente possuem 
comportamentos (conjunto de operações representando sua funcionalidade). Eles 
descrevem coisas abstratas ou concretas da empresa. Todo o modelo é definido como 
um conjunto de objetos comunicantes. 
 
Em termos de modelagem de empresas, as maiores vantagens e originalidade de 
técnicas orientadas a objetos são o mecanismo de herança de propriedades e a 
reutilização de modelos. A propriedade de herança consiste em compartilhar 
propriedades comuns de objetos da empresa como uma super-classe de objetos para 
evitar repetição. Estes grupos de propriedades podem ser reutilizados em outros 
42 
 
objetos, e objetos podem ser reutilizados de um modelo para outro, diminuindo o tempo 
de modelagem. 
 
Várias são as técnicas, metodologias e notações existentes para a modelagem de 
empresa. A maioria dos modelos de negócio são complexos devido ao fato dos 
usuários terem diferentes necessidades e estas necessidades mudarem a cada tempo. 
Para que uma empresa possa ser adaptável às mudanças, ela precisa ter uma 
descrição simples e unificada de suas entidades. Embora este seja o objetivo de muitos 
esforços para modelagem, o que se tem hoje ainda é uma descrição tipicamente 
extensa, inflexível, e frágil (MARSHALL, 1999). 
 
Recentemente a UML (Unified Modeling Language), que já encontra-se consagrada 
para a modelagem de sistemas de software, têm sido proposta para a modelagem de 
empresas através de seus mecanismos de extensão. 
 
Como apresentado no capítulo 2, as extensões definidas pelos usuários na UML se dão 
através de estereótipos, valores associados e restrições que coletivamente estendem e 
adaptam a UML a um domínio específico, como por exemplo ao de Modelagem de 
Negócios. Nas subseções seguintes são apresentadas três propostas de extensões da 
para a modelagem de negócio. 
 
3.3.1. OMG 
 
A OMG (2002) em sua publicação “UML Extension for Busines Modeling” descreve 
uma extensão da UML para a modelagem de negócios, em termos de seus 
mecanismos de extensão. O documento porém não é uma tentativa de descrever 
completamente os novos conceitos e notações para a modelagem de negócios. Ele 
apenas descreve estereótipos que podem ser usados para adaptar o uso da 
UML à modelagem de negócios. 
 
 
 
43 
 
3.3.2. MARSHALL 
 
MARSHALL (1999) apresenta uma proposta de extensão da UML para a modelagem 
de negócios. Ele propõe um meta-modelo para identificar e descrever conceitos 
através dos quais sistemas de negócios são modelados, e utiliza a UML para ilustrar 
tais conceitos. No seu trabalho ele propõe uma modelagem baseada em quatro 
elementos centrais que são: propósito, processo, entidade, e organização. (ver 
figuras Figura 7 e 8) 
 
Figura 7 – Ícones e Estereótipos estabelecidos por Marshall 
 
Figura 8 – Um exemplo de Modelo Organizacional 
44 
 
3.3.3. ERIKSSON 
 
Eriksson et al (2000) propõe uma técnica que estende a UML baseada em 
processos e orientação a objetos para construir arquiteturas de negócios. Seu 
trabalho baseia-se em extensões da UML para representar: processos, recursos, 
regras e objetivos. Ele afirma que sua técnica não deve ser vista como um conjunto 
definido de extensões para negócios, mas sim como uma base para que 
desenvolvimentos e adaptações possam ser feitos (por arquitetos de negócios) para 
situações específicas de modelagem. 
 
As propostas de