APLICAÇÃO DA TÉCNICA DE M N UML P - uenf.br€¦ · aplicaÇÃo da tÉcnica de modelagem de...
136
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
Transcript of APLICAÇÃO DA TÉCNICA DE M N UML P - uenf.br€¦ · aplicaÇÃo da tÉcnica de modelagem de...
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 atividade de 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 Desenvolvimento de 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, levando a 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 entrada e
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 mais comum) 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 existem
componentes 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 Eriksson formam uma Arquitetura baseada na linguagem UML para a
modelagem de negócios com a qual um arquiteto de negócios pode adicionar
estereótipos, valores atribuídos e restrições convenientes para sua linha de negócios.
A proposta do autor baseia-se na hipótese de que um negócio pode ser modelado
através de objetos e relacionamentos entre estes como mostra o meta-modelo na
Figura 9.
45
Figura 9 – Meta Modelo proposto por Eriksson e Penker (2000)
Um negócio é um sistema complexo que pode ser abordado sob mais de um aspecto.
Uma arquitetura de modelagem fornece vistas para a modelagem com foco em
aspectos significativos. Cada vista pode ser modelada por um ou mais tipos de
diagramas.
46
A Arquitetura de Eriksson oferece as seguintes vistas :
– Visão do Negócio (Business Vision) : Modela conceitos e objetivos a serem
seguidos de acordo com a estratégia do negócio.
– Processo do Negócio (Business Process): Modela os processos de negócio,
e seus relacionamentos com os recursos, a serem seguidos para atingir os
objetivos.
– Estrutura do Negócio (Business Structure): Modela a estrutura dos recursos
(físicos, informacionais, humanos)
– Comportamento do Negócio (Business Behavior): Modela o comportamento
e interação entre recursos e entre processos.
Os sub-itens a seguir detalham estas vistas.
3.3.3.1. Vista de Visão do Negócio (Business Vision View)
Fatores a serem considerados nesta vista:
•Missão
•Objetivos
•Pontos fortes
•Pontos Fracos
•Oportunidades
•Ameaças
•Fatores Críticos
•Competências Centrais
•Regras
•Unidades Organizacionais
•Estratégias
47
Diagramas da vista de Visão do Negócio:
–Diagrama de Modelo Conceitual
–Diagrama de Objetivos
Diagrama de Modelo conceitual
Características:
•Define os conceitos importantes usados no negócio e seus relacionamentos.
•Os conceitos são modelados por Classes.
•O modelo é representado pelo diagrama de Classes.
A Figura 10 apresenta um exemplo deste diagrama.
Figura 10 – Um exemplo de Diagrama de Modelo Conceitual
48
Diagrama de Objetivos
Características:
•Define os objetivos e sub-objetivos da empresa, e os problemas que impedem o
alcance daqueles.
A Figura 11 apresenta um exemplo deste diagrama no contexto do processo de
verificação de conformidade de sistemas desenvolvidos numa empresa de
desenvolvimento de software.
Figura 11 – Exemplo de Diagrama de Objetivos
3.3.3.2. Vista de Estrutura do Negócio (Business Structure View)
Mostra a estrutura da organização e de seus recursos. Suplementa a vista de Processo
de Negócio.
49
Diagramas da vista de Estrutura do negócio:
- Diagrama de Modelo de Recursos
- Diagrama de Modelo de Informações
- Diagrama de Modelo de Organização
Diagrama de Modelo de Recursos
Um recurso é uma entidade que pode ter um papel na realização de uma certa classe
de tarefas. (VERNADAT, 1996)
A técnica de Eriksson define alguns estereótipos para indicar diferentes categorias de
tipos de recursos.
Diagrama de Modelo de Informação
A Figura 12 apresenta um exemplo deste diagrama.
Figura 12 – Exemplo de Modelo de Informação
3.3.3.3. Visão de Processos do Negócio (Business Process View)
Esta vista aborda as seguintes questões:
50
• Que atividades são requeridas para se atingir os objetivos?
• Quando as atividades são realizadas, e em que ordem?
• Qual é o objetivo de cada atividade?
• Como as atividades são realizadas?
• Que recursos são necessários para realizar as atividades?
• O que é consumido e produzido por cada atividade?
• Quem controla as atividades ou processos?
• Como os processos estão relacionados com a organização do negócio?
• Como os processos se relacionam com outros processos?
Os diagramas dessa vista são:
- Diagrama de Processos de Negócio
- Diagrama de Linha de Montagem
Diagrama de Processos de Negócio
Descreve os processos de negócio através de suas relações com os seguintes Objetos:
–Objetivos
–Entradas
–Saídas
–Fornecedores
–Controles
Os processos mostram as atividades que devem ser realizadas para atingir um objetivo
explícito, através de seus relacionamentos com os recursos que participam do
processo.
Recursos incluem pessoas, material, energia, informação, e tecnologia. Os recursos
podem ser consumidos, refinados, criados, ou usados (agindo como catalisador)
durante o processo.
51
Existem relacionamentos entre um processo e seus recursos e entre diferentes
processos que se interagem, e há uma associação entre processos e objetivos.
O processo tem um propósito e um objetivo específico, e todos os processos
coletivamente buscam alcançar os objetivos globais do negócio.
Os objetivos do negócio, trabalhados na vista de visão de negócio, formam a base para
a modelagem dos processos. Além desta base devem ser utilizadas entrevistas,
discussões, seções de brainstorming, compostas por grupos seletos de pessoas
envolvidas no negócio e estudos práticos de como o negócio opera.
O resultado deve ser a criação de diagramas de processos que descrevam pelo menos
os processos centrais do negócio, sendo estes os processos que possuem interações
com o mundo exterior ou que seja crítico para o fornecimento do produto ou serviço do
negócio. Os processos centrais são portanto normalmente orientados ao cliente.
A técnica descreve os processos de negócio através de diagramas de atividade da
UML. Para isto ela estabelece um conjunto de estereótipos que define um processo e
os vários recursos que este envolve.
Um processo é representado por uma atividade com o estereótipo <<processo>>. Este
estereótipo possui o tradicional ícone para representar processo encontrado na
literatura e mostrado na Figura 13.
Figura 13- Ícone associado à atividade estereotipada como processo de negócio
Os outros objetos são representados com os seguintes estereótipos:
• Objetivos: <<Objetivo>>
<<Processo>>
nome do processo
52
• Entradas: Recursos: <<físico>>, <<abstrato>>, <<pessoa>>, ou
<<informação>>
• Saídas: Recursos: <<físico>>, <<abstrato>>, <<pessoa>>, ou
<<informação>>
• Fornecedores: Recursos: <<físico>>, <<abstrato>>, <<pessoa>>, ou
<<informação>>
• Controles: Recursos: geralmente <<pessoa>> ou <<físico>>
A Figura 14 apresenta os relacionamentos entre os objetos e o processo de negócio
Figura 14 - Representação de um processo de negócio e sua interação com recursos
Diagrama de Linha de Montagem
É uma variação do diagrama de processo para melhor descrever como os processos
interagem com os recursos de informação (objetos de informação em sistemas de
informação). Assim como o Diagrama de Processos de Negócio, o Diagrama de Linha
de Montagem é uma extensão do diagrama de atividade da UML. Seu diferencial está
na ênfase dada à visualização do fluxo de objetos entre as atividades.
53
O Diagrama de Linha de Montagem foi introduzido pelo método Astracan e tem sido
usado com sucesso na modelagem de processos, particularmente quando o propósito
da modelagem é a produção de sistemas de informação que dão suporte aos
processos. (ERIKSSON; HANS-ERIK; PENKER, 2000)
No topo do diagrama está um diagrama de processos. Abaixo deste estão um número
de pacotes horizontais que são chamados pacotes de linha de montagem, cada um
representando um grupo de objetos( os objetos de um pacote podem ser de uma classe
específica ou de diferentes classes. Um pacote de linha de montagem é um item pacote
da UML estereotipado para <<linha de montagem>> e desenhado como um longo
retângulo horizontal, como mostra a Figura 15.
Figura 15 – Exemplo de Diagrama de Linha de Montagem
O propósito deste diagrama é demonstrar como o processo na parte superior do
diagrama utiliza e gera objetos na linha de montagem. A referência de um objeto a uma
linha de montagem é indicada por um fluxo de objeto (representado por uma linha
tracejada na UML) entre o processo e o objeto dentro do pacote na linha de montagem.
O diagrama deve ser lido da esquerda para a direita na seqüência das referências aos
pacotes da linha de montagem.
54
Os objetos nos pacotes de linha de montagem podem ser qualquer recurso mas são
geralmente objetos de informação em sistemas de informação. O diagrama mostra
portanto quais informações são acessadas pelo processo e quais informações este
envia para o sistema de informação. Um pacote pode representar um sistema de
informação inteiro, um subsistema, uma categoria especial de classes, etc.
Diagrama de Linha de Montagem e Casos de Uso
O diagrama de linha de montagem pode ser usado como técnica para levantamento de
casos de uso do sistema ou sistemas que darão suporte aos processos de negócio.
Para isso, Eriksson orienta que a análise deve começar com os pacotes em um alto
nível de abstração, como os níveis de sistemas ou subsistemas. Uma vez que as
referências iniciais do processo para os sistemas, ou subsistemas, de informação
tenham sido identificadas, passa-se para a identificação das classes daqueles
sistemas, e a mesma análise pode ser então repetida com os pacotes agora definidos
em outro nível mais detalhado. Neste nível mais detalhado as referências também
devem ser mais detalhadas. Uma simples referência no diagrama inicial pode
corresponder a várias referências nos níveis subseqüentes.
Durante a execução de um processo, vários papéis são desempenhados por este
através de seus recursos de suporte, como funcionários e máquinas por exemplo. Cada
referência entre o processo e um sistema de informação será responsabilidade de um
dos papéis envolvidos no processo.
O conjunto de referências de responsabilidade de um mesmo papel (representado por
um ator na UML) corresponderá aos requisitos de interações deste com o sistema.
Como visto no capítulo 2, uma seqüência de interações entre um ator e um sistema de
informação, que traga um valor externo ao sistema, é representado e especificado na
UML como um Caso de Uso. Portanto, o conjunto de referências de um mesmo papel
caracterizará um caso de uso requerido ao sistema de informação como mostra o
exemplo da Figura 16 .
55
Figura 16 – Exemplo de identificação de casos de Uso no Diagrama de Linha de
Montagem
A identificação dos casos de uso através desta técnica faz com que os objetivos dos
atores, e conseqüentemente os requisitos do sistema em forma de casos de uso,
estejam alinhados aos objetivos globais do negócio uma vez que são analisados com
base nos processos de negócio e estes por sua vez foram definidos em função dos
objetivos do negócio. (AZEVEDO;CAMPOS, 2002)
3.3.3.4. Vista do Comportamento do Negócio (Business Behavior View)
Mostra o comportamento individual de recursos e processos e também o detalhamento
de interações específicas entre diferentes recursos ou processos O Workflow dos
processos e recursos é governado pela vista dos Processos de Negócio. A vista de
Comportamento aborda o comportamento dinâmico mais específico de um recurso ou
processo em particular.
56
Diagramas da vista de Comportamento do Negócio:
– Diagrama de Estado de Recursos
– Diagrama de Interação de Recursos
– Diagrama de Interação de Processos
3.4. Considerações sobre a Modelagem de Processos de negócio com UML
A forma de representação e concepção dos processos de negócio não é um ponto
comum nas propostas de modelagem de negócio com UML. São observadas duas
linhas distintas: a que defende a representação de processos de negócio através de
casos de uso de negócio e a que descorda de tal representação.
A primeira linha foi introduzida pela OMG em 1997 na primeira versão da especificação
da UML e posteriormente aprimorada no RUP. A Segunda linha corresponde às
iniciativas de Marshall(1999) e Eriksson et al (2000).
A primeira linha defende a modelagem de processos de negócio através de modelos de
casos de uso de negócio. Assim como o caso de uso para um sistema de software, o
modelo de caso de uso de negócio apresenta o sistema (agora, o negócio) da
perspectiva do usuário e esboça como ele agrega valor para seus usuários.
Um modelo de caso de uso de negócio descreve os processos de negócio de uma
organização em termos de casos de uso e atores de negócio correspondentes a
processos de negócio e clientes, respectivamente (JACOBSON; BOOCH;
RUMBAUGH, 1999).
Já a segunda linha defende que os processos de negócio não são bem representados
pelos casos de uso pois estes servem para representar um domínio fechado
correspondente a determinados requisitos de usuários, e que os processos de negócio
não podem ser vistos simplificadamente como requisitos de clientes.
57
Como apresentado anteriormente neste capítulo, 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 do resultado acima ou abaixo da cadeia. A modelagem por
processo de negócio surgiu 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
empresa, que possui uma visão departamental.
Uma vez que o modelo de caso de uso da UML não representa fluxo de informações
entre os casos de uso, esses não representam processos de negócio eficientemente
pois estes, por definição, devem estar ligados de forma a formar o fluxo de atividades
necessárias ao objetivo do negócio como um todo.
Um caso de uso não é equivalente a um processo. Um caso de uso fornece um serviço
que é requerido como parte de um processo exterior ao sistema de software. Um caso
de uso é completamente implementado no software, enquanto um processo é
normalmente apenas parcialmente implementado no software (o termo caso de uso é
uma abstração para definir comunicação entre atores e um sistema de software). Os
casos de uso podem ser considerados como as especificações dos serviços que o
sistema de software fornece ao processo de negócio. (ERIKSSON et al, 2000)
É necessário portanto que a modelagem dos processos de negócio de ênfase ao fluxo
de informações entre os processos ao longo da cadeia de valor que busca atingir os
objetivos globais do negócio.
Atentando para isto, a segunda linha propõe a utilização de diagramas de atividades
para a representação dos processos de negócio no domínio da modelagem de negócio.
Nesta linha, os processo de negócio são representados através do diagrama de
atividade da UML, no qual os itens atividade são estereotipados como processos.
CAPÍTULO 4
Propostas de atividades para a sistematização do levantamento de
requisitos no UP
4.1. Introdução Vários processos de desenvolvimento que utilizam a UML defendem que o
desenvolvimento deve começar com a modelagem de casos de uso para definir os
requisitos funcionais do sistema. Como apresentado no capítulo 2, um caso de uso
descreve um uso específico do sistema por um ou mais atores. Um ator é um papel que
um usuário ou outro sistema desempenha. O objetivo da modelagem de caso de uso é
identificar e descrever todos os casos de uso que os atores requisitam ao sistema. As
descrições de caso de uso são usadas portanto para analisar e projetar uma arquitetura
de software que realiza os casos de uso, este tipo de processo classifica-se como
desenvolvimento dirigido por caso de uso.
Mas como identificar todos os casos de uso , ou os casos de uso corretos que melhor
suportam o negócio no qual o sistema operará?
Segundo Eriksson et al (2000), para resolver este tipo de questão é necessário
entender o ambiente no qual o sistema irá operar, questionando:
Como os diferentes atores interagem?
Que atividades fazem parte de seus trabalhos?
Quais são os objetivos finais de seus trabalhos?
Que outras pessoas, sistemas ou recursos estão envolvidos mas que não agem como
atores neste sistema específico?
Que regras governam suas atividades e estruturas?
Existem formas dos atores trabalharem mais eficientemente?
59
Jacobson et al(1999) também ressaltam a importância da observação do ambiente no
levantamento dos casos de uso de um sistema afirmando que a construção de modelos
de domínio podem ser usados para este fim:
Um modelo de domínio captura os mais importantes tipos de objetos no contexto
do sistema. Os objetos de domínio representam as “coisas” que existem ou
eventos que se tornam conhecidos no ambiente em que o sistema trabalha. A
maioria dos objetos de domínio podem ser encontrada através de especificações
de requisitos ou de entrevistas com especialistas de domínio.
Segundo eles os objetos de domínio se apresentam de três formas típicas:
- Objetos de negócio que representam coisas que são manipuladas no negócio, como
pedidos, contas, e contratos.
- Objetos e conceitos do mundo real dos quais o sistema precisa manter registros,
como aeronaves, mísseis, e trajetórias.
- Eventos que são ou serão conhecidos, como chegada de aeronave, saída de
aeronave, e intervalo de almoço.
Ele afirma também que o modelo de domínio é um caso especial de um modelo de
negócio mais completo. A modelagem de negócio é uma técnica para entender e
representar os processos de negócio de uma organização e pode ser usada para
auxiliar a identificação dos casos de uso.
Embora exista o reconhecimento da importância da observação do ambiente, a
identificação dos requisitos a partir do entendimento deste ainda é feita de forma
bastante empírica, sendo realizada, na maioria das vezes, através de entrevistas com
futuros usuários do sistema. (SANTANDER, 2002)
Mas como tornar o processo de identificação de casos de uso mais sistemático?
60
É preciso considerar primeiramente que, como mostrado no capítulo 2, o
desenvolvimento de um sistema complexo de software deve ser guiado por uma
metodologia ou processo de desenvolvimento que organize e controle a produção das
várias partes (artefatos) constituintes de um sistema.
Segundo Kruchten (1998) o UP, reúne as boas práticas do desenvolvimento de
software e tem sido usado como base para a definição de várias metodologias
encontradas no mercado. Esta dissertação 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.
Para isso é proposto um wokflow a ser inserido no UP para a modelagem de negócio
com base na técnica de modelagem proposta por Eriksson. Também são propostas
atualizações em algumas atividades pré-estabelecidas no UP. As atividades são
propostas de forma a poderem ser aplicadas a qualquer metodologia que se baseie no
UP.
Como analisado anteriormente, a técnica de construção de arquiteturas de negócio
proposta por Eriksson é, dentre as propostas de modelagem de negócio com UML
pesquisadas, a única que aborda de forma sistemática a passagem da arquitetura de
negócio para uma arquitetura de software que dê suporte à primeira. Eriksson porém
não explora a sistematização desta passagem no contexto de um processo ou
metodologia de desenvolvimento de sistemas.
Esta dissertação define, e agrega ao UP, atividades para o levantamento de casos de
uso a partir de uma arquitetura de negócio. O trabalho também apresentará no item 4.3
como tais atividades poderão ser aplicadas a qualquer metodologia ou processo de
desenvolvimento que se baseie no UP, através de um exemplo utilizando a Metodologia
MDS-OO da Dataprev.
61
4.2. Atividades propostas
Como foi visto, no UP os requisitos funcionais são descritos através do modelo de caso
de uso UML. Como apresentado no capítulo 2 o modelo de caso de uso é um diagrama
da UML formado por casos de uso, atores, e relacionamentos entre estes itens. A
descrição de um caso de uso é a documentação que especifica o fluxo de eventos entre
atores e o sistema, bem como operações a serem realizadas pelo sistema.
Como apresentado no capítulo 2 o UP é dividido em quatro fases e possui workflows
(levantamento de requisitos, análise, projeto, implementação, e teste) que devem ser
executados nas quatro fases, considerando para cada uma destas uma abordagem
específica das atividades do fluxo.
Atividades do workflow de levantamento de requisitos existem em todas as fases do
desenvolvimento com maior ênfase nas fases de Concepção e Elaboração. Na fase de
Concepção existe uma maior ênfase na identificação dos requisitos mas não na
especificação detalhada dos mesmos. Desenvolve-se o diagrama de Casos de Uso
sem detalhar a especificação de cada um. A maior concentração de esforço na
atividade de especificação de requisitos está na fase Elaboração na qual, a partir das
informações de negócio e necessidades dos clientes levantadas em forma de casos de
uso na fase de Concepção, as especificações dos casos de uso são realizadas em
maior parte.
Cada fase do UP é ainda dividida em iterações que vão trabalhando subdomínios do
problema ao longo do tempo incrementalmente de forma que a iteração seguinte
busque sempre o incremento da anterior no sentido de formar um todo consistente.
Um método de levantamento de requisitos que derive os casos de uso de uma
arquitetura de software no UP deve definir atividades e seus fluxos, bem como o
estado esperado dos artefatos gerados por estas atividades, em cada fase do processo
(Concepção, Elaboração, Construção, e Transição), considerando tal estrutura iterativa
e incremental e as atividades já definidas nesta estrutura.
62
A aplicação da técnica de Eriksson ao UP se dará portanto através da definição de um
workflow para a modelagem de negócio e atualizações nas atividades já estabelecidas
para os outros workflows de forma a integrá-los. Nestas atualizações, algumas
atividades serão adicionadas e outras apenas atualizadas com a inserção de sub-
atividades.
Também será definida a abordagem que cada atividade proposta deve ter nas fases de
Concepção e Elaboração, que como visto anteriormente são as fases onde devem
existir as atividades de análise de requisitos.
4.2.1. Workflow para Modelagem de Negócio
O workflow definido para a modelagem de negócio é apresentado na Figura 17 e a
seguir são apresentadas as descrições de cada atividade e a abordagem que devem ter
em cada fase do processo de desenvolvimento.
Figura 17 - Workflow para a Modelagem de Negócio
63
Descrição das atividades e respectivos produtos:
Modelar os Objetivos do Negócio: A modelagem dos objetivos deve identificar os
principais objetivos e sub-objetivos do negócio numa estrutura hierárquica que
permita a visualização de dependência entre tais objetivos. Este modelo servirá
de base para a definição dos processos de negócio. A modelagem dos objetivos
do negócio deve ser feita com base em entrevistas realizadas com os
conhecedores do negócio. Produto resultante: Diagrama de Modelo de Objetivos.
Modelar os Processos de Negócio: Os processos de negócio devem ser
definidos buscando a realização dos objetivos identificados no Modelo de
Objetivos do Negócio. Porém, não é necessário haver uma relação 1 para 1
entre processos de negócios e objetivos do negócio pois muitos processos
auxiliares não estarão necessariamente relacionados a um objetivo do Modelo de
Objetivos do Negócio. Entrevistas com os envolvidos no negócio também devem
ser realizadas para fornecer subsídios à definição dos processos de negócio.
Produto resultante: Diagrama de Processos de Negócio.
Modelar os Recursos Envolvidos: – Os recursos, informações e unidades
organizacionais devem ser modelados através dos diagramas da Vista de
Estrutura do Negócio. A modelagem destes elementos deve ser feita
paralelamente às atividades de Modelagem de Processos de Negócio a fim de se
ter um melhor entendimento dos termos relacionados ao negócio e
conseqüentemente uma maior consistência na modelagem do mesmo. Produtos
resultantes: Diagramas de Modelos de Recursos, Informações e Organização.
Modelar Comportamento dos Recursos - Um Diagrama de Estados de Recurso
pode ser criado para facilitar a determinação dos processos de negócio quando
este se caracteriza por refinamentos de um mesmo objeto ao longo da cadeia de
valor. Por exemplo, considerando um negócio de vendas, o pedido pode ser
abordado como um objeto cujo estado vai sendo alterado (refinado) ao longo de
toda a cadeia de valor, desde a abertura do pedido até a confirmação do pedido
64
entregue ao cliente. Num caso como este a identificação dos estados possíveis
de tal objeto (como pedido solicitado, pedido em verificação de estoque, pedido
em produção, pedido em expedição e pedido entregue) pode facilitar a
identificação dos processos de negócio necessários ao cumprimento das
mudanças de estado do produto. Produto resultante: Diagrama de Estado de
Recurso e Diagramas de Interação de Recursos e de Estados.
Definir Papéis e Responsabilidades – Cada processo de negócio deve possuir
um responsável uma vez que ele geralmente não estará ligado a uma única
unidade organizacional, mas sim passando por mais de uma delas. Cada
processo por sua vez define um fluxo de eventos que podem envolver um ou
mais atores. É necessário definir que atores agem em cada um dos processos.
Isto pode ser feito através de uma análise do fluxo de eventos e associação
destes aos atores envolvidos no processo. Produto Resultante: Tabela de Papéis
e Responsabilidades.
As abordagens destas atividades em cada fase do desenvolvimento são descritas a
seguir:
Modelar os Objetivos do Negócio:
Na Concepção – o Modelo de Objetivos deve abordar todos os objetivos
relevantes ao projeto em questão, desde os de nível mais estratégico até os que
estejam ao nível de objetivos de processos de negócio.
Na Elaboração – Deve-se atualizar o modelo de objetivos em função de
possíveis esclarecimentos posteriores.
Modelar os Processos de Negócio:
Na Concepção – Deve-se identificar os principais processos de negócio, suas
relações com os recursos (entradas, saídas, fornecedores, controles e objetivo),
65
e a seqüência de execução dos mesmos. Porém, não é necessária a descrição
detalhada do fluxo de eventos ocorrido internamente no processo.
Na Elaboração – Detalhar o fluxo de eventos dos processo que serão abordados
na iteração atual.
Modelar os Recursos Envolvidos:
Na Concepção – Devem ser modelados todos os recursos significativos
identificados no Modelo de Processo de Negócio definido na fase Concepção, de
forma a analisar a dependência entre tais recursos e suas propriedades.
Na Elaboração – Modelar todos os recursos significativos identificados durante o
detalhamento dos fluxos de eventos de cada processo de negócio.
Modelar Comportamento dos Recursos:
Na Concepção – Modelar o comportamento de recursos nos casos em que estes
sofram várias alterações ao longo dos processos de negócio e esta dinâmica de
alterações precisa ser melhor entendida.
Na Elaboração – Detalhar os Diagramas de Estado de Recursos, caso tenham
sido criados na fase Concepção, com base no detalhamento dos fluxos de
evento dos processos.
Definir Papéis e Responsabilidades:
Na Concepção – Definir apenas os responsáveis por cada processo de negócio,
sejam eles unidades organizacionais ou funções.
Na Elaboração – Definir os papéis (atores) associados aos eventos que ocorrem
no fluxo de evento de cada processo de negócio.
66
4.2.2. Workflow de Levantamento de Requisitos
A atividade seguinte foi adicionada ao Workflow de Levantamento de Requisitos:
Identificar Necessidades de Informatização - Nesta atividade deve-se associar os
processos de negócio aos sistemas de informação que lhes dão suporte e assim
identificar a possível necessidade de novos sistemas de informação através da
identificação de carências de suporte automatizado de informação e operações
aos processos. Sugere-se a utilização do Diagrama de Linha de Montagem como
base para a realização desta atividade. Produto resultante: Diagrama de Linha
de Montagem com os pacotes de linha de montagem identificados.
A atividade Encontrar Atores e Casos de Uso, já existente no UP, foi atualizada com a
sub-atividade:
Derivar Casos de Uso dos Processos de Negócio: Os casos de uso devem ser
identificados com base nos processos de negócio. Esta atividade deve resultar
em uma Relação de Casos de Uso na qual deve-se associar cada caso de uso
identificado ao processo (ou processos) de negócio a que este atende. Sugere-
se a utilização do Diagrama de Linha de Montagem como base para a realização
desta atividade. A identificação dos casos de uso no Diagrama de Linha de
Montagem se dá através do agrupamento de referências (entre o processo e os
sistemas) de mesma natureza. Produto resultante: Diagrama de Linha de
Montagem com casos de uso identificados.
As abordagens destas atividades em cada fase do desenvolvimento são descritas a
seguir:
Identificar Necessidades de Informatização:
Na Concepção – Identificar sistemas de software que dão suporte aos processos
de negócio bem como identificar a necessidade de novos sistemas e
67
subsistemas. Utilizar o Diagrama de Linha de Montagem como recurso de apoio
ao desenvolvimento desta atividade. Deve-se começar com os pacotes em um
alto nível de abstração, representando os sistemas já existentes e a natureza das
informações das referências que estes fazem a cada processo de negócio
analisado. Deve-se então fazer uma primeira avaliação quanto à natureza das
informações e as operações necessárias ao processo e o atendimento destas
pelos sistemas existentes, de forma a buscar identificar tipos de informações e
operações que não estão sendo mantidas pelos sistemas de software
disponíveis. Tais necessidades de informação e de operações devem ser
referenciadas a um outro pacote representativo do sistema (ou sistemas) a ser
construído para atender tais requisitos.
Na Elaboração – Deve-se atualizar e aprofundar a análise iniciada na Concepção
com base na descrição do fluxo de evento dos processos. Deve-se avaliar cada
fluxo de evento e identificar eventos que podem ser auxiliados por sistemas de
informação mas que ainda não são. Tais auxílios devem ser representados como
referências do processo aos sistemas que os realizam. Considerando o escopo
de um sistema identificado na concepção deve-se representar cada linha de
montagem como uma classe do sistema e distribuir a responsabilidade entre as
classes através das referências feitas a cada uma delas pelos processos. Cada
evento a ser informatizado deve resultar em uma referência à classe que o
realizará e quando esta não 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 Negócio:
Na Concepção – A atividade deve visar a identificação dos casos de uso
arquiteturalmente significativos. Estes casos de uso representam funcionalidades
num alto nível de abstração. Estes casos de uso servem como base para a
definição da vista lógica da arquitetura de software que os realizará.
68
Na Elaboração – A atividade visa identificar todos os casos de uso do sistema
com base na análise das referências entre os processos detalhados e os
sistemas de software que os apoiará.
4.2.3. Workflow para Análise
A atividade Realização de Casos de Uso, já existente no UP, foi atualizada com a sub-
atividade:
Identificar Classes a partir da arquitetura de negócio – Esta atividade consiste a
identificação de Classes a partir de modelos da Vista de Estrutura do Negócio e
da Vista de Processos de Negócio. Produto resultante: Diagrama de Classes.
A abordagem desta atividade em cada fase do desenvolvimento é descrita a seguir:
Na Concepção: Busca-se a identificação das principais Classes do sistema com
base na análise dos Modelos de Recursos e de Informações.
Na Elaboração: Deve ser feita uma reavaliação das Classes identificadas com
base nas referências do Diagrama de Linha de Montagem desenvolvido nesta
fase. Através da análise das referências deve-se identificar que classes serão
responsáveis pela realização dos casos de uso identificados no Diagrama de
Linha de Montagem.
69
4.3. Aplicação das atividades propostas à MDS-OO Dataprev.
Muitas metodologias, como a apresentada em Paula (2001), têm sido concebidas com
base no UP. Cada empresa de desenvolvimento de software tem suas particularidades
e buscam portanto desenvolver suas próprias metodologias ou customizar alguma
existente no mercado. A MDS-OO Dataprev é outro exemplo de metodologia que foi
concebida com base no UP e será objeto de aplicação das atividades propostas neste
trabalho.
Para aplicar as atividades propostas neste trabalho a qualquer metodologia que se
baseie no UP é necessário identificar a correspondência entre as atividades incluídas
ou alteradas no UP e as estabelecidas na metodologia em questão.
A Empresa de Tecnologia e Informações da Previdência Social – Dataprev originou-se
dos centros de processamento de dados dos institutos de previdência existentes em
1974. É uma empresa pública instituída pela Lei nº 6.125, de 4 de novembro de 1974.
Atualmente, a empresa conta com cerca de 3000 empregados. É responsável pelo
processamento da maior folha de pagamento do país, alcançando mais de 20 milhões
de beneficiários/mês.
A MDS Dataprev OO é a metodologia (ou processo) de desenvolvimento de software da
Dataprev que guia o desenvolvimento dos sistemas concebidos no paradigma da
orientação a objeto. Ela é baseada no UP. Sua estrutura portanto é composta por
Fases (relacionadas às metas ao longo do tempo) e Workflows (relacionadas à
natureza das atividades). Cada disciplina é responsável por gerar seus respectivos
artefatos através de um 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 iterativa, cada fase
percorre todo o conjunto de workflows. Por ser incremental, cada iteração atualiza os
artefatos gerados nas iterações anteriores.
70
A metodologia estabelece um fluxograma de atividades a ser percorrido em cada fase.
Uma mesma atividade pode constar em mais de uma fase porém será abordada com
um enfoque específico em cada fase. Para cada atividade constante no fluxograma
existe uma descrição da mesma. A metodologia também estabelece os estados
esperados dos artefatos ao final de cada fase.
A tabela a seguir apresenta as atividades incluídas ou alteradas no UP e as
correspondentes atividades na MDS-OO Dataprev.
Tabela 1 – Atividades propostas X Atividades da MDS-OO Dataprev
Atividades na fase de Concepção Atividades na fase de Elaboração
No UP Na MDS-OO Dataprev No UP Na MDS-OO Dataprev
Modelar os Objetivos
do Negócio
Sem correspondência Modelar os Objetivos
do Negócio
Sem correspondência
Modelar os Processos
de Negócio
Modelar os Processos de
Negócio
Modelar os Processos
de Negócio
Incrementar Modelo de
Processos de Negócio
Modelar os Recursos
Envolvidos
Sem correspondência Modelar os Recursos
Envolvidos
Sem correspondência
Modelar
Comportamento dos
Recursos
Sem correspondência Modelar
Comportamento dos
Recursos
Sem correspondência
Definir Papéis e
Responsabilidades
Sem correspondência Definir Papéis e
Responsabilidades
Sem correspondência
Identificar
Necessidades de
Informatização
Sem correspondência Identificar
Necessidades de
Informatização
Sem correspondência
Encontrar Atores e
Casos de Uso
Esboçar Modelo de Casos
de Uso Principais
Encontrar Atores e
Casos de Uso
Incrementar Modelo de
Casos de Uso
Realização de Casos
de Uso
Desenvolver modelos de
Classes
Realização de Casos
de Uso
Incrementar Modelos de
Classe
71
As atividades sem correspondência foram adicionadas à MDS-OO Dataprev e as que
correspondiam de forma similar às atividades estabelecidas no UP foram atualizadas
conforme estabelecido no item 4.2..
As subseções a seguir apresentam os fluxogramas de atividades da MDS-OO Dataprev
resultantes para cada fase (Concepção, Elaboração, Construção, e Transição). Nos
fluxogramas as atividades adicionadas à metodologia apresentam-se em cor cinza
escuro e as atividades já constantes, mas que foram atualizadas com sub-atividades,
apresentam-se com listras. Também são apresentadas as descrições de cada atividade
e os estados esperados para cada artefato ao final de cada fase.
O Anexo I apresenta a descrição de cada artefato referenciado nas atividades da
metodologia.
O Anexo II apresenta exemplos de artefatos, produzidos nas atividades inseridas ou
modificadas na MDS-OO Dataprev, no contexto do desenvolvimento de um sistema de
controle de expedições da Dataprev.
4.3.1. A fase Concepção
Na fase de Concepção foram adicionadas as seguintes atividades conforme
estabelecido no método proposto:
• Modelar os Objetivos do Negócio;
• Modelar os Processos de Negócio;
• Modelar os Recursos Envolvidos;
• Modelar Comportamento dos Recursos;
• Definir Papéis e Responsabilidades;
• Identificar Necessidades de Informatização;
A atividade Esboçar Modelo de Casos de Uso Principais, já existente na MDS Dataprev
OO, foi atualizada com a sub-atividade Derivar Casos de Uso dos Processos de
Negócio.
72
A atividade Desenvolver Modelos de Classe, já existente na MDS Dataprev OO, foi
atualizada com a sub-atividade Identificar Classes a partir da Arquitetura de Negócio.
A seguir é apresentado o fluxograma de atividades resultante para a fase Concepção.
73
74
75
4.3.1.1. Descrição das atividades da fase Concepção
A.1.1.) Entrevistar Cliente para Modelagem do Negócio
Entrevistar o Cliente para o entendimento do negócio onde o futuro Sistema atuará .
Registrar as informações levantadas num Registro de Reunião. Dentre as informações
Registradas devem estar um esboço do Diagrama de contexto e do Modelo de
Processos de Negócio.
A.1.2.) Analisar e Modelar o Negócio
Consiste na realização em colaboração das atividades: Analisar o Negócio; Modelar os
Objetivos do Negócio; Modelar os Processos de Negócio; Modelar os Recursos
Envolvidos; Modelar Comportamento dos Recursos; definir Papéis e
Responsabilidades; Registrar Termos no Glossário e Registrar Especificações
Suplementares Principais.
A.1.2.1.) Analisar o Negócio
Documentar a Descrição do Negócio com base nas informações levantadas nas
reuniões.
A.1.2.2.) Modelar os Objetivos do Negócio
A modelagem dos objetivos deve identificar os principais objetivos e sub-objetivos do
negócio numa estrutura hierárquica que permita a visualização de dependência entre
tais objetivos. Este modelo servirá de base para a definição dos processos de negócio.
A modelagem dos objetivos do negócio deve ser feita com base em entrevistas
realizadas com os conhecedores do negócio.
o Modelo de Objetivos deve abordar todos os objetivos relevantes ao projeto em
questão, desde os de nível mais estratégico até os que estejam ao nível de objetivos de
processos de negócio.
76
A.1.2.3.) Modelar os Processos de Negócio
Os processos de negócio devem ser definidos buscando a realização dos objetivos
identificados no Modelo de Objetivos do Negócio. Porém, não é necessário haver uma
relação 1 para 1 entre processos de negócios e objetivos do negócio pois muitos
processos auxiliares não estarão necessariamente relacionados a um objetivo do
Modelo de Objetivos do Negócio. Entrevistas com os envolvidos no negócio também
devem ser realizadas para fornecer subsídios à definição dos processos de negócio.
Nesta fase deve-se identificar os principais processos de negócio, suas relações com
os recursos (entradas, saídas, fornecedores, controles e objetivo), e a seqüência de
execução dos mesmos. Porém, não é necessária a descrição detalhada do fluxo de
eventos ocorrido internamente no processo.
A.1.2.4.) Modelar os Recursos Envolvidos
Os recursos, informações e unidades organizacionais devem ser modelados através
dos diagramas da Vista de Estrutura do Negócio. A modelagem destes elementos deve
ser feita paralelamente às atividades de Modelagem de Processos de Negócio a fim de
se ter um melhor entendimento dos termos relacionados ao negócio e
consequentemente uma maior consistência na modelagem do mesmo.
Nesta fase devem ser modelados todos os recursos significativos identificados no
Modelo de Processo de Negócio definido na fase Concepção, de forma a analisar a
dependência entre tais recursos e suas propriedades.
A.1.2.5.) Modelar Comportamento dos Recursos
Um Diagrama de Estados de Recurso pode ser criado para facilitar a determinação dos
processos de negócio quando este se caracteriza por refinamentos de um mesmo
objeto ao longo da cadeia de valor. Por exemplo, considerando um negócio de vendas,
o pedido pode ser abordado como um objeto cujo estado vai sendo alterado (refinado)
ao longo de toda a cadeia de valor, desde a abertura do pedido até a confirmação do
pedido entregue ao cliente. Num caso como este a identificação dos estados possíveis
77
de tal objeto (como pedido solicitado, pedido em verificação de estoque, pedido em
produção, pedido em expedição e pedido entregue) pode facilitar a identificação dos
processos de negócio necessários ao cumprimento das mudanças de estado do
produto.
Nesta fase deve-se modelar o comportamento de recursos nos caso em que estes
sofram várias alterações ao longo dos processos de negócio e esta dinâmica de
alterações precisa ser melhor entendida.
A.1.2.6.) Definir Papéis e Responsabilidades
Definir apenas os responsáveis por cada processo de negócio, sejam eles unidades
organizacionais ou funções.
A.1.2.7.) Registrar Termos no Glossário
Os termos referenciados e definidos para expressar os conceitos presentes no negócio
devem ser documentados no Glossário.
A.1.2.8.) Registrar Especificações Suplementares Principais
Na medida em que o negócio é analisado na fase de Concepção, podem ser previstos
alguns requerimentos não funcionais como relativos à segurança e à performance por
exemplo. Esses requerimentos não funcionais devem ser registrados como
Especificações Suplementares.
A.1.3.) Validar Análise com o Cliente
Realizar reunião com o Cliente para apresentar e validar a Análise do Negócio,
Diagrama de Contexto, Modelo de Processos de Negócio, Glossário, e Especificações
Suplementares definidos. Deve-se gerar um Registro de Reunião.
78
A.1.4.) Entrevistar Cliente para Levantar Requisitos
Entrevistar o Cliente para o levantamento das principais funcionalidades do futuro
Sistema visando à identificação dos principais casos de uso e requerimentos não
funcionais. Registrar as informações levantadas num Registro de Reunião.
A.1.5.) Analisar e Especificar Requisitos Levantados
Consiste na realização em colaboração das atividades: Identificar Necessidades de
Informatização; Esboçar Casos de Uso Principais; Incrementar Glossário; e Incrementar
Especificações Suplementares Principais.
A.1.5.1.) Identificar Necessidades de Informatização
Nesta atividade deve-se associar os processos de negócio aos sistemas de informação
que os dão suporte e assim identificar a possível necessidade de novos sistemas de
informação através da identificação de carências de suporte automatizado de
informação e operações aos processos. Sugere-se a utilização do Diagrama de Linha
de Montagem como base para a realização desta atividade.
Nesta fase deve-se identificar sistemas de software que dão suporte aos processos de
negócio bem como identificar a necessidade de novos sistemas e subsistemas. Utilizar
o Diagrama de Linha de Montagem como recurso de apoio ao desenvolvimento desta
atividade. Deve-se começar com os pacotes em um alto nível de abstração,
representando os sistemas já existentes e a natureza das informações das referências
que estes fazem a cada processo de negócio analisado. Deve-se então fazer uma
primeira avaliação quanto à natureza das informações e as operações necessárias ao
processo e o atendimento destas pelos sistemas existentes, de forma a buscar
identificar tipos de informações e operações que não estão sendo mantidas pelos
sistemas de software disponíveis. Tais necessidades de informação e de operações
devem ser referenciadas a um outro pacote representativo do sistema (ou sistemas) a
ser construído para atender tais requisitos.
79
A.1.5.2.) Esboçar Modelo de Casos de Uso Principais
Esboçar o Modelo dos principais Casos de Uso do Sistema a ser desenvolvido através
de um Modelo de Caso de Uso. No Modelo devem estar identificados os principais
Atores e Casos de Uso bem como uma descrição de cada Caso de Uso.
Os casos de uso podem ser identificados com base nos processos de negócio. Esta
atividade deve resultar em uma Relação de Casos de Uso na qual deve-se associar
cada caso de uso identificado ao processo (ou processos) de negócio a que este
atende. Sugere-se a utilização do Diagrama de Linha de Montagem como base para a
realização desta atividade. A identificação dos casos de uso no Diagrama de Linha de
Montagem se dá através do agrupamento de referências (entre o processo e os
sistemas) de mesma natureza. Nesta fase a atividade deve visar a identificação dos
casos de uso arquiteturalmente significativos. Estes casos de uso representam
funcionalidades num alto nível de abstração. Estes casos de uso servem como base
para a definição da vista lógica da arquitetura de software que os realizará.
A.1.5.3.) Incrementar Glossário
Atualizar o Glossário com os novos termos definidos nas reuniões de Levantamento de
Requisitos.
A.1.5.4.) Incrementar Especificações Suplementares Principais
Atualizar as Especificações Suplementares com os novos requisitos não funcionais
identificado nas reuniões de Levantamento de Requisitos.
A.1.6.) Validar Levantamento de Requisitos com cliente
Realizar reunião com o Cliente para apresentar e validar o Modelo de Caso de Uso e as
alterações no Modelo de Processo de Negócio, no Glossário e nas Especificações
Suplementares caso tenha havido.
80
A.1.7.) Entrevistar Cliente para Definir Arquitetura
Entrevistar Cliente visando levantar informações para definir a Arquitetura do Software.
Na entrevista deve-se esboçar alternativas de Modelos de Classe e Pacotes, Modelo de
Componentes e de Implantação em alto nível (procurando definir a arquitetura de
hardware e software em linhas gerais).
A.1.8.) Definir Arquitetura do Software
A Arquitetura do Software deve especificar o Sistema em linhas gerais através dos
seguintes modelos: Modelo de Pacotes, Modelo de Classes, Modelo de Componentes,
Realizações dos principais Casos de Uso, e Modelo de Implantação (em alto nível).
A.1.8.1.) Desenvolver Modelo de Pacotes
Analisar e definir um Modelo de Pacotes em alto nível buscando identificar as relações
entre eles e a possível reutilização de arquiteturas de referência ou padrões.
A.1.8.2.) Desenvolver Modelo de Classes
Desenvolver o Modelo de Classes com as principais classes do sistema e seus
relacionamentos. Deve-se verificar a possibilidade de reutilização de Classes já
existentes.
A identificação das principais Classes do sistema pode ser feita com base na análise
dos Modelos de Recursos.
A.1.8.3.) Desenvolver Modelos de Componentes
Uma visão dos subsistemas de informação e seus relacionamentos.
A.1.8.4.) Desenvolver Modelos de Implantação
Uma visão da arquitetura de hardware do novo sistema.
81
A.1.8.5.) Incrementar Glossário
Atualizar o Glossário com os novos termos definidos nas entrevistas de definição da
Arquitetura do Software.
A.1.8.6.) Incrementar Especificações Suplementares
Atualizar as Especificações Suplementares com os novos termos definidos nas
entrevistas de definição da Arquitetura do Software.
A.1.8.7.) Incrementar Modelo de Casos de Uso Principais
Atualizar o Modelo de Casos de Uso com os novos termos definidos nas entrevistas de
definição da Arquitetura do Software.
A.1.9.) Validar Arquitetura com Cliente
Validar a arquitetura geral do sistema com o cliente.
A.1.10.) Elaborar Cronograma Geral
Definir o Cronograma Geral de Desenvolvimento do Projeto com base nos requisitos
levantados.
A.1.11.) Elaborar Orçamento
Elaborar Orçamento com base no Cronograma Geral e requisitos levantados.
A.1.12.) Formalizar Prestação de Serviço
82
Gerar a Formalização da Prestação de Serviço junto ao cliente. Geralmente consiste na
elaboração e assinatura de um contrato.
4.3.1.2. Estado esperado dos artefatos ao final da fase Concepção
A Tabela 2 apresenta o estado esperado dos artefatos ao final da fase Concepção.
Tabela 2 - Estados dos Artefatos ao final da Concepção
Artefato Estado Esperado ao final da Concepção
Cronograma Geral Definido
Orçamento Definido
Formalização da Prestação de Serviço
Realizada
Registro de Reunião Criado para cada reunião acontecida durante a fase
Descrição do Negócio Cerca de 90% definida pois o Modelo de Processos de Negócio será revisado na fase seguinte.
Modelo de Objetivos do Negócio
Principais objetivos identificados
Modelo de Processos de Negócio
Principais processos de negócio identificados
Modelos de Recursos Principais recursos identificados e modelados
Modelos de Comportamento Criado para recursos importantes e complexos
Tabela de Papéis e Responsabilidades
Com responsáveis pelos processos identificados
Diagrama de Linha de Montagem
Criado para os processos macros a serem informatizados.
Glossário Termos definidos e documentados
Especificações Suplementares
Principais requerimentos não funcionais docu-mentados.
Modelo de Casos de Uso Esboçado. Atores e Casos de Uso importantes definidos; Fluxo de eventos definidos em linhas gerais para os Casos de Uso identificados.
83
Arquitetura do Software Contendo os seguintes modelos e respectivos estados:
Modelo de Casos de Uso: Principais casos de uso numa visão macro;
Modelo de Pacotes: Descrendo os principais pacotes e seus relacionamentos numa abstração de alto nível;
Modelo de Classes: com principais classes e seus relacionamentos.
Modelo de Componentes: com os principais componentes do sistema.
Diagramas de seqüências e de Colaboração: descrevendo a realização dos principais Casos de Uso do sistema.
Modelo de Implantação: Especificando a arquitetura de hardware do sistema.
84
4.3.2. A fase Elaboração
Na fase de Elaboração foram adicionadas as seguintes atividades conforme
estabelecido no método proposto:
• Modelar os Objetivos do Negócio;
• Modelar os Processos de Negócio;
• Modelar os Recursos Envolvidos;
• Modelar Comportamento dos Recursos;
• Definir Papéis e Responsabilidades;
• Identificar Necessidades de Informatização;
A atividade Incrementar Modelo de Casos de Uso, já existente na MDS Dataprev OO,
foi atualizada com a sub-atividade Derivar Casos de Uso dos Processos de Negócio.
A atividade Incrementar Modelos de Classe, já existente na MDS Dataprev OO, foi
atualizada com a sub-atividade Identificar Classes a partir da Arquitetura de Negócio.
A seguir é apresentado o fluxograma de atividades resultante para a fase Elaboração.
85
86
4.3.2.1. Descrição das atividades da Elaboração
A.2.1.) Definir Iterações da Elaboração
Definir subdomínios para a fase de Elaboração com base na Arquitetura do Software e
nas Especificações Suplementares definidas. O documento deve conter a identificação
dos Casos de Uso que serão realizados (através de diagramas dinâmicos da UML) em
cada iteração. Também deve conter o detalhamento do cronograma para a fase de
Elaboração, programando o desenvolvimento dos Casos de Usos por iterações.
A.2.2.) Entrevistar Cliente para Levantar Requisitos
Entrevistar cliente visando o detalhamento dos Casos de Uso já identificados bem como
a identificação e detalhamento de outros Casos de Uso . Registrar o levantamento num
Registro de Reunião.
A.2.3.) Analisar e Modelar o Negócio
Consiste na realização em colaboração das atividades: Modelar os Objetivos do
Negócio; Modelar os Processos de Negócio; Modelar os Recursos Envolvidos; Modelar
Comportamento dos Recursos; e Definir Papéis e Responsabilidades.
87
A.2.3.1.) Modelar os Objetivos do Negócio
Deve-se atualizar o Modelo de Objetivos em função de possíveis esclarecimentos
posteriores.
A.2.3.2.) Modelar os Processos de Negócio
Detalhar o fluxo de eventos dos processos que serão abordados na iteração atual.
A.2.3.3.) Modelar os Recursos Envolvidos
Modelar todos os recursos significativos identificados durante o detalhamento dos
fluxos de eventos de cada processo de negócio.
A.2.3.4.) Modelar Comportamento dos Recursos
Detalhar os Modelos de Comportamento de Recursos, caso tenham sido criados na
fase Concepção, com base no detalhamento dos fluxos de evento dos processos.
A.2.3.5.) Definir Papéis e Responsabilidades
Definir os papéis (atores) associados aos eventos que ocorrem no fluxo de evento de
cada processo de negócio.
A.2.4.) Analisar e Especificar Requisitos Levantados
Consiste na realização em colaboração das atividades: Identificar Necessidades de
Informatização; Incrementar Modelo de Casos de Uso; Incrementar Glossário,
Incrementar Especificações Suplementares.
88
A.2.4.1.) Identificar Necessidades de Informatização
Deve-se atualizar e aprofundar a análise iniciada na Concepção com base na descrição
do fluxo de evento dos processos. Deve-se avaliar cada fluxo de evento e identificar
eventos que podem ser auxiliados por sistemas de informação mas que ainda não são.
Tais auxílios devem ser representados como referências do processo aos sistemas que
os realizam. Considerando o escopo de um sistema identificado na concepção deve-se
representar cada linha de montagem como uma classe do sistema e distribuir a
responsabilidade entre as classes através das referências feitas a cada uma delas
pelos processos. Cada evento a ser informatizado deve resultar em uma referência à
classe que o realizará e quando esta não existir deverá ser criada como uma nova linha
de montagem. Este processo deve ser feito respeitando-se o conceito de
encapsulamento.
A.2.4.2.) Incrementar Modelo de Caso de Uso
Analisar e atualizar o Modelo de Caso de Uso com base nas novas informações de
requisitos. A atividade visa identificar todos os casos de uso do sistema com base na
análise das referências entre os processos detalhados e os sistemas de software que
os apoiará.
A.2.4.3.) Incrementar Glossário
Atualizar o Glossário com os novos termos definidos na análise dos requisitos
levantados.
A.2.4.4.) Incrementar Especificações Suplementares
Atualizar o registro de Especificações Suplementares com novos requerimentos não
funcionais identificados.
89
A.2.5.) Desenvolver Modelos de Análise e Projeto
Esta atividade compreende a realização em cooperação das seguintes atividades:
Desenvolver Realizações de Caso de Uso, Incrementar Modelo de Classes,
Desenvolver Mapa de Navegação, Desenvolver Modelos de Estado, Derivar/ Ajustar
Modelo de Dados, Validar Análise e Projeto com o Cliente.
A.2.5.1.) Desenvolver Realizações de Caso de Uso
Desenvolver a Realização de Caso de Uso para cada Caso de Uso. Esta realização
deve mostrar as interações realizadas pelos objetos (Classes) necessárias à realização
do caso de uso.
A.2.5.2.) Incrementar Modelo de Classes
Através da análise das Realizações de Caso de Uso e Modelo de Classes, deve-se
identificar a necessidade de novas classes e incrementá-las no Modelo de Classes.
Os Diagramas de Linha de Montagem podem ser usados como base para a
identificação de novas classes. Deve ser feita uma reavaliação das Classes
identificadas com base nas referências do Diagrama de Linha de Montagem
desenvolvido nesta fase. Através da análise das referências deve-se identificar que
classes serão responsáveis pela realização dos casos de uso identificados no
Diagrama de Linha de Montagem.
A.2.5.3.) Desenvolver Mapa de Navegação
Identificar no modelo de Classes as Classes de Interface e dentre estas as que serão
páginas Web. Com as páginas Web identificadas, deve-se desenvolver o Mapa de
Navegação.
90
A.2.5.4.) Desenvolver Modelos de Estado
Caso seja necessário analisar e explicitar a mudança de estados de um determinado
objeto ao longo da execução dos processos ou eventos, deve-se desenvolver o Modelo
de Estado para tal objeto.
A.2.5.5.) Derivar / Ajustar Modelo de Dados
Com base no Modelo de Classes deve-se desenvolver o Modelo de Dados, fazendo a
correspondência das classes para o modelo relacional.
A.2.6.) Validar Análise e Projeto com o Cliente
Realizar entrevista com Cliente para validar os modelos de Análise e Projeto. Deve-se
gerar um Registro de Reunião.
A.2.7.) Atualizar Arquitetura do Negócio
Atualizar todos os modelos da Arquitetura do Negócio com as novas informações da
Análise e Projeto.
4.3.2.2. Estado esperado dos artefatos ao final da fase Elaboração
A Tabela 3 apresenta o estado esperado dos artefatos ao final da fase Elaboração.
Tabela 3 – Estado dos Artefatos ao final da Elaboração
Artefato Estado Esperado ao final da Elaboração
Plano de Iteração Subdomínios do sistema e seus respectivos Casos de Usos identificados. Com programação para a análise de cada subdomínio por iteração, respeitando-se o período total de tempo estimado para a fase de Elaboração.
Cronograma Geral Detalhado para a fase de Elaboração desde o início da fase.
91
Registro de Reunião Criado para cada reunião
Modelo de Casos de Uso Definido
Modelo de Objetivos Definido
Modelo de Processos de Negócio
Revisado
Modelos de Recursos Definido
Modelos de Comportamento de Recursos
Definido
Tabela de Papéis e Responsabilidades
Definida
Diagrama de Linha de Montagem
Criado para os processos detalhados a serem informatizados.
Glossário Atualizado com novos termos
Especificações Suplementares
Atualizado, capturando todos os requerimentos não funcionais.
Diagramas de Seqüência Diagramas de Seqüência descrevendo as realizações de Caso de Uso necessárias.
Diagramas de Colaboração Diagramas de Colaboração descrevendo as realizações de Caso de Uso necessárias.
Modelo de Classes Definido
Mapa de Navegação Definido
Modelo de Estado Desenvolvido para os principais objetos do sistema.
Modelo de Dados Definido no nível lógico.
Arquitetura do Negócio Revisada. Contendo os seguintes modelos e respectivos estados:
Modelo de Casos de Uso: Principais casos de uso numa visão macro;
Modelo de Pacotes: Descrendo os principais pacotes e seus relacionamentos numa abstração de alto nível;
Modelo de Classes: com principais classes e seus
92
relacionamentos.
Modelo de Componentes: com os principais componentes do sistema.
Diagramas de seqüências e de Colaboração: descrevendo a realização dos principais Casos de Uso do sistema.
Modelo de Implantação: Especificando a arquitetura de hardware do sistema.
93
4.3.3. A fase Construção
Conforme já citado anteriormente, as atividades propostas neste trabalho abrangem as
fases de Concepção e Elaboração pois é durante estas que os casos de uso são
completamente identificados. Portanto as fases de Construção e Transição não tiveram
suas atividades atualizadas ou modificadas. As atividades da fase de Construção são
apresentadas a seguir.
Implementar
Incrementar modelos de Requerimentos e de
Análise e Projeto
Definir Iterações da Construção
Implementar Componentes
Testar Componentes
Incrementar Glossário
Incrementar EspecificaçõesSuplementares
Atualizar Realizações de Caso de Uso
Atualizar Modelo de Dados
Atualizar Modelos de Estado
Plano de Iteração
Componentes
Implementados
Avaliação de Teste
Glossário
Especificações
Suplementares
Componentes Integrados
Atualizar Modelo de Classes
Elaborar Plano de Testes
Plano de Testes
Diagramas de
Seqüência
Diagramas de
Colaboração
Modelo de Classes
Modelo de Estado
Modelo de Dados
Atualizar Mapa de Navegação
Integrar Componentes
Mapa de Navegação
Realizar Testes Integrados
Cronograma Geral
TransiçãoVersão Instalável
S
N
Desenvolver / Incrementar Manual do Sistema
Iterações Programadaspara Construção Concluídas
S
N
Implementar Banco de Dados
Banco de Dados
94
4.3.3.1. Descrição das atividades da Construção
A.3.1.) Definir Iterações da Construção
Planejar a implementação de cada componentes respeitando-se o prazo estabelecido
para a fase de construção no Cronograma Geral. O documento deve conter a
identificação dos Componentes que serão implementados em cada iteração. Deve-se
identificar nos modelos do projeto a prioridade de implementação dos componentes e
assim estimar o período em que cada componente será implementado.
A.3.2.) Elaborar Plano de Testes
O Plano de Testes deve conter a descrição de todos os testes que serão realizados
durante o projeto, bem como o momento em que acontecerão.
A.3.3.) Implementar
Atividade de codificação dos componentes e geração do banco de dados.
A.3.3.1.) Implementar Componentes
Codificação dos componentes, gerando os Componentes Implementados.
A.3.3.2.) Implementar Banco de Dados
Geração do Banco de Dados com base no Modelo de Dados.
A.3.4.) Testar Componentes
Realizar testes dos componentes implementados com base no Plano de Testes.
A.3.5.) Incrementar Modelos de Requerimentos e de Análise e Projeto
95
Compreende a realização em cooperação das seguintes atividades: Incrementar
Glossário, Incrementar Especificações Suplementares, Atualizar Realizações de Caso
de Uso, Atualizar Modelo de Classes, Atualizar Mapa de Navegação, Atualizar Modelos
de Estado, Atualizar Modelo de Dados.
A.3.5.1.) Incrementar Glossário
Atualizar Glossário com novos termos definidos.
A.3.5.2.) Incrementar Especificações Suplementares
Atualizar Especificações Suplementares com novos requerimentos não funcionais
identificados na Construção.
A.3.5.3.) Atualizar Realizações de Caso de Uso
Atualizar as Realizações de Caso de Uso devido a possíveis necessidades de
mudanças de projeto identificadas durante a implementação.
A.3.5.4.) Atualizar Modelo de Classes
Atualizar o Modelo de Classes com possíveis alterações ocorridas na Implementação.
A.3.5.5.) Atualizar Mapa de Navegação
Atualizar Mapa de Navegação com possíveis mudanças ocorrida na Implementação.
A.3.5.6.) Atualizar Modelos de Estado
Atualizar Modelo de Estados com possíveis mudanças ocorrida na Implementação.
96
A.3.5.7.) Atualizar Modelo de Dados
Atualizar Modelo de Dados com possíveis mudanças ocorrida na construção do Banco.
A.3.6.) Integrar Componentes
Integrar Componentes Implementados de acordo com o Plano de Integração definido.
A.3.7.) Realizar Testes Integrados
Realizar testes com os componentes integrados, verificando as interações entre eles.
A.3.8.) Desenvolver / Incrementar Manual do Sistema
Desenvolver Manual do Sistema para os usuários. O manual deve conter explicações
operacionais para realização das funcionalidades requeridas para o Sistema.
4.3.3.2. Estado esperado dos artefatos ao final da fase Construção
A Tabela 4 apresenta o estado esperado dos artefatos ao final da fase Elaboração.
Tabela 4 - Estado dos Artefatos ao final da Construção
Artefato Estado Esperado ao final da Construção
Plano de Iteração Definido desde o início da fase. Com a estimativa para a implementação de cada componentes identificado no Modelo de Componentes. Deve constar a programação dos componentes por iteração, respeitando-se o período total de tempo estimado para a fase de Construção.
Cronograma Geral Detalhado para a fase de Construção desde o início da fase.
Plano de Testes Elaborado, contendo a descrição dos testes que serão aplicados nos componentes, bem como o cronograma
97
de suas realizações.
Componentes Implementados
Componentes implementados e testados. Com a maioria dos componentes já integrados.
Banco de Dados Construído.
Avaliação de Teste Realizadas para cada componente e para integração de conjuntos deles.
Glossário Atualizado e completamente revisado.
Especificações Suplementares
Atualizado e completamente revisado.
Diagramas de Seqüência Revisados.
Diagramas de Colaboração Revisados.
Modelo de Classes Revisado.
Mapa de Navegação Revisado.
Modelos de Estado Revisado.
Modelo de Dados Revisado.
Componentes Integrados Cerca de 90% integrados.
98
4.3.4. A fase Transição
As atividades da fase Transição são apresentadas no fluxograma a seguir.
Implantar
Documentar Notas de Versão
Instalação do Ambiente de Hardware e Software
Realizar testes no Ambiente de Produção
Notas de Versão
Ambiente de Hardware
e Software Instalado
Avaliação de Teste
Desenvolver Estratégia de Implantação
Estratégia de
Implantação
Treinar Usuários Usuários Treinados
Implantar Sistema Sistema Instalado
Sistema Aprovado?S
AvaliarManutenção
N Concepção
Elaboração
Construção
4.3.4.1. Descrição das atividades da Transição
A.4.1.) Documentar Notas de Versão
Documentar as características de cada versão entregue ao Cliente. Deve conter a
descrição das funcionalidades implementadas (quais os casos de uso que a versão
99
realiza). Deve conter uma descrição da plataforma em que foi testada, e como realizar
sua instalação ou o upgrade do sistema anterior à versão. Também deve documentar
os Bugs e limitações conhecidas nos testes e como contorná-los caso estes ainda não
tenham sido solucionados.
A.4.2.) Desenvolver Estratégia de Implantação
Desenvolver um planejamento para a implantação do sistema construído.
A.4.3.) Implantar
Consiste na realização das seguintes atividades: Instalação do Ambiente de Hardware
e Software, Treinar Usuários, e Implantar Sistema.
A.4.3.1.) Instalação do Ambiente de Hardware e Software
Preparação do ambiente de hardware e software do cliente para receber o novo
sistema. Consiste na preparação da infra-estrutura tecnológica do cliente.
A.4.3.2.) Treinar Usuários
Consiste em atividades de planejamento e execução de treinamento dos usuários no
novo sistema.
A.4.3.3.) Implantar Sistema
Preparação do ambiente organizacional para o novo sistema e implantação do novo
sistema.
A.4.4.) Realizar Testes no Ambiente de Produção
Realizar testes no ambiente de produção conforme Plano de Testes.
100
A.4.5.) Avaliar Manutenção
Após avaliação dos testes no ambiente de produção, deve-se planejar a manutenção
caso seja necessária e ou monitorar sua necessidade ao longo do ciclo de vida da
versão implantada. De acordo com a natureza da manutenção necessária pode ser
necessário voltar a uma das quatro fases do desenvolvimento: Concepção ,
Elaboração, Construção, ou Transição.
4.3.4.2. Estado esperado dos artefatos ao final da fase Transição
A Tabela 5 apresenta o estado esperado dos artefatos ao final da fase Transição.
Tabela 5 - Estado dos Artefatos ao final da Transição
Artefato Estado Esperado ao final da Transição
Notas de Versão Notas de Versão geradas para cada versão entregue ao usuário.
Estratégia de Implantação Definida no início da fase.
Ambiente de Hardware e Software Instalados
Infra-estrutura do cliente completamente instalada e operando.
Usuários Treinados Usuários treinados para o sistema.
Sistema Instalado Sistema Instalado e operando em ambiente de produção.
Avaliação de Teste Realizadas para cada componente construído e para cada módulo de componentes integrados.
CAPÍTULO 5
Conclusões
No domínio do desenvolvimento de sistemas de software foram evidenciadas neste
trabalho as vantagens do Processo Unificado (UP). No entanto, o UP não define
atividades para a Modelagem de negócio. Nele, as atividades começam a partir do
levantamento de requisitos e a modelagem de negócio é apenas citada como um
possível facilitador para a identificação de possíveis atores do sistema. O RUP
apresenta uma proposta de modelagem de negócio através de casos de uso de
negócio. Esta proposta no entanto apresenta limitações quanto à modelagem de fluxos
entre os processos de negócio e quanto ao alinhamento dos casos de uso identificados
aos reais objetivos do negócio.
No domínio da modelagem de negócio a técnica de construção de arquiteturas de
negócio proposta por Eriksson é, dentre as propostas de modelagem de negócio com
UML pesquisadas, a única que aborda de forma sistemática a passagem da arquitetura
de negócio para uma arquitetura de software que dê suporte à primeira. Eriksson porém
não explora a sistematização desta passagem no contexto de um processo ou
metodologia de desenvolvimento de sistemas.
O método proposto neste trabalho definiu atividades para a modelagem de negócio,
com base na técnica proposta por Eriksson, a serem inseridas no UP ou em qualquer
metodologia que se baseie nos mesmos princípios deste, com o objetivo de sistematizar
a identificação de requisitos de softwares alinhados aos objetivos do negócio. As
atividades definidas foram então aplicadas à metodologia de desenvolvimento de
sistemas da Dataprev.
As atividades definidas no método mostraram-se consistentes com o modelo iterativo e
incremental e com interfaces bem estabelecidas com as atividades pré-estabelecidas
no UP e na MDS-OO Dataprev.
102
Com a inserção das atividades na MDS-OO Dataprev duas vantagens foram de grande
destaque:
- A identificação sistemática de necessidade de informatização a partir do fluxo de
evento dos processos estabelecida na atividade Identificar Necessidades de
Informatização
- A identificação sistemática dos casos de uso numa abordagem iterativa estabelecida
na atividade Derivar Casos de Uso dos Processos de Negócio.
A arquitetura de negócio orientada a objeto mostrou-se eficaz na estruturação e
documentação de um negócio. Os modelos da arquitetura de referência proposta por
Eriksson mostraram-se capazes de representar os conceitos relacionados a negócios e
seus relacionamentos, mapeando-os para os conceitos da orientação a objetos e
representando-os através da UML.
Dentre as vantagens observadas na utilização de uma arquitetura de negócio foi a
capacidade de se isolar vistas diferentes de um mesmo negócio de forma que cada
vista se apresente com modelos onde se evidenciam a visualização de algum conceito ,
suprimindo os menos importantes, porém de forma que todas as vistas estejam
integradas, representando o mesmo negócio de forma consistente. Isto resulta em
modelos com representações simples e de fácil entendimento, mas ricas no
relacionamento com os outros modelos. Um estrategista ou gerente pode estar
analisando os objetivos do negócio através do modelo de objetivos, o especialista em
organizações e métodos pode definir formatos e fluxos de documentos com base nos
modelos de informações, os analistas de negócio podem estar analisando e projetando
processos de negócio com base no modelo de processos e nos demais modelos, de
forma que os processo de negócios estejam integrados aos reais objetivos e
relacionado de forma consistente com os recursos disponíveis na organização, e os
analistas de sistemas podem estar definindo melhor os requisitos de novos sistemas
desenvolvidos para apoiar os processos de negócio, bem como evitando que
funcionalidades e dados sejam duplicados em sistemas diferentes. Ou seja todos estão
trabalhando de forma integrada com base na arquitetura.
103
Quanto à modelagem de processos a arquitetura proposta por Eriksson (2000)
apresenta, numa mesma técnica, soluções para as carências de outras técnicas como a
representação simples e flexível de fluxos e decisões, a relação com os objetivos da
organização, e a relação de entrada, saída e utilização de recursos ao longo dos
processos.
A identificação dos casos de uso a partir do diagrama de linha de montagem da vista de
visão de processos mostrou-se um procedimento eficiente, facilitando a identificação
das reais necessidades de informatização nos processos de negócio. Na técnica de
Eriksson os processos de negócio são definidos em função dos objetivos do negócio e
os casos de uso são identificados de maneira sistemática a partir dos processos de
negócio. Desta forma, os casos de uso identificados estão diretamente alinhados aos
objetivos do negócio.
Além das vantagens como ferramenta de modelagem de negócios, uma arquitetura de
negócio baseada em objetos e linguagem UML pode ser representada em qualquer
ferramenta CASE (Computed Aided Software Engeneering) que contemple a linguagem
UML não sendo necessário gastos com a aquisição de uma ferramenta específica para
este fim.
Como proposta para trabalhos futuros sugere-se a comparação desta técnica com
demais técnicas de identificação de requisitos.
Outras propostas para trabalhos futuros são a inserção de atividades no workflow de
teste do UP para a validação dos modelos gerados no workflow Modelagem de Negócio
e a construção de uma ferramenta CASE que permita uma maior automação das
atividades definidas neste trabalho.
104
Referências Bibliográficas
AZEVEDO JÚNIOR, D. P.; CAMPOS, R. Modelagem de Arquiteturas de Negócio
com UML: Um facilitador para a integração de sistemas organizacionais. In:
SIMPOSIO DE ENGENHARIA DE PRODUÇÃO - SIMPEP, 2002, Bauru-SP. Anais do
SIMPEP. 2002.
BASS; CLEMENTS; KAZMAN. Software Architecture in Practice. MA: Addison
Wesley, 1998.
BOOCH, G.; JACOBSON, I.; RUMBAUGH,J. UML - Guia do Usuário. Rio de Janeiro:
Campos, 2000.
CAMPOS, R. Uma Proposta de Modelagem e Integração de Sistemas de
Gestão da Produção em Empresas de Manufatura. Tese de Doutorado em
Engenharia de Produção-Campinas-SP,Universidade Estadual de
Campinas-Unicamp,1998.
CRUZ, T. Workflow : a tecnologia que vai revolucionar processos. 2.ed. São
Paulo: Atlas, 2000.
ERIKSSON; HANS-ERIK; PENKER, M. Business Modeling with UML. USA: Wiley &
Sons, 2000.
FELICIANO, A. Sistemas Flexíveis de Informações. São Paulo: Makron Books, 1996.
JACOBSON, I.; BOOCH, G.; RUMBAUGH, J. The Unified Software Development
Process. Wokingham, Inglaterra: Addison Wesley, 1999.
JOHANSSON et al. Processos de Negócio. Rio de Janeiro: Pioneira, 1995.
105
KRUCHTEN, P.B. The 4+1 View Model of Architecture. Piscataway, NJ: IEEE
Software, November 1995.
______. The Rational Unified Process. MA: Addison-Wesley, 1998.
______. Rational Unified Process : an introdution. MA: Addison-Wesley, 2000.
LILLY, S. Use Case Pitfalls: top 10 problems from Real projects using Use Cases, In:
Proceedings, technology of object oriented languages and systems, 1999.
MANCUSO, F. L. Modelagem de Empresas: Integração de diferentes métodos através
do formalismo TF-ORM. Rio Grande do Sul, 1998. Dissertação (Mestrado em
Computação) – Instituto de Informática, UFRGS.
MARSHALL, C. Enterprise Modeling with UML. USA: Addison-Wesley, 1999.
MELLO, A. M. V. Modelagem, análise e redesenho de processos de negócio. São
Paulo: Expertise, 2001.
MENDES, A. Arquitetura de Software: desenvolvimento orientado para arquitetura.
Rio de Janeiro : Campus, 2002.
NAUR, P.; RANDELL, B.; BUXTON, J. Software Engineering: A Report on a
Conference Sponsored by NATO Science Committee. NATO, 1969.
OBOLENSKY, N. Guia prático de reengenharia. Rio de Janeiro: Record,1996.
OMG - Object Management Group. UML Especifications.1997. Disponível em:
http://www.rational.com/umlf. Acesso em: 14 maio 2002
PAULA, W. P. F. Engenharia de Software : Fundamentos, métodos e padrões. Rio de
Janeiro: LTC, 2001.
106
PETRIE, C.Enterprise Integration Modeling. Cambridge: MIT Press, 1992.
PRESSMAN, R. S. Engenharia de Software. São Paulo: Makron Books, 1995.
ROZENFELD, H. Processo de Negócio. 2001. Disponível em: e
http://www.numa.org.br/conhecimentos/Bps.htmlf. Acesso em: 10 abril 2001.
RUP - Rational Unified Process, Version 2001.03.00, Copyright c 1987 - 2000.
Rational Software Corporation.
RUP - Rational Unified Process, Version 2002.05.00, Copyright c 2000 - 2001.
Rational Software Corporation.
SANTANDER, V. F.; CASTRO, J. F. Integrating Use Cases and Organizational
Modeling. publicado nos anais da Conferência Internacional de Engenharia de
Requisitos do IEEE, RE’02, Alemanha, 2002.
SCHNEIDER, G.; WINTERS, J. P. Applying Use Cases: a pratical guide, USA:
Addison Wesley, 1998.
SOMMERVILLE, I. Software Engineering. 6.ed. USA: Addison Wesley, 2000
VERNADAT, F. B. Enterprise Modeling and Integration: Principles and Application.
Londres: Chapman & Hall, 1996.
107
Anexo I – Artefatos da MDS Dataprev OO
Metodologia de Desenvolvimento de Sistemas
Orientados a Objeto
da Dataprev
Descrição dos Artefatos
Versão 1.0 – Setembro de 2002
MDSMDSDataprev
108
Ambiente de Hardware e Software Instalados Infraestrutura do cliente preparada com hardware e software para receber a instalação do sistema desenvolvido. Arquitetura do Software É um estudo da organização global do sistema de software bem como do relacionamento entre subsistemas e componentes. É representado através de diagramas da UML de forma a capturar a estrutura de componentes num alto nível de abstração. É nesse momento que se define a possível utilização de arquiteturas de componentes padrões e suas relações com os componentes a serem desenvolvidos.Busca levantar as alternativas tecnológicas disponíveis, seus custos, benefícios, vantagens e desvantagens, buscando analisar a viabilidade de cada alternativa de arquitetura (batch, on-line, centralizada, distribuída, etc.), considerando-se as possibilidades de investimento dos Clientes e os prazos previstos para o desenvolvimento do sistema. Avaliação de Teste Relatório de demonstração dos resultados dos testes aplicados. Banco de Dados É o Banco de Dados físico do Sistema. Componentes Implementados São os componentes implementados. Componentes Integrados É o sistema de software propriamente dito, ou seja, a integração de todos os componentes implementados. Cronograma Geral Esta atividade destina-se a elaborar o Cronograma Geral de desenvolvimento do sistema, de acordo com a sistemática de controle de projeto da DATAPREV e as fases, etapas, atividades e artefatos da metodologia. Serão definidos prazos, responsabilidades e participantes.
Diagramas de Colaboração Descrição da realização de um caso de uso através do Diagrama de Colaboração da UML. Descreve a interação global entre objetos na realização de um caso de uso. Diferencia-se do Diagrama de Seqüência por não abordar as trocas de mensagens ordenadas no tempo. Diagramas de Seqüência
109
Descrição da realização de um caso de uso através do Diagrama de Seqüência da UML. Contém a descrição das trocas de mensagens entre os objetos ao longo do tempo na realização do caso de uso. Especificação de Caso de Uso Descrição dos Fluxos de Eventos de cada caso de uso. Especificações Suplementares Constitui-se da descrição dos requisitos não funcionais do sistema, entre eles: - Requerimentos legais e reguladores; - Atributos qualitativos do sistema incluindo usabilidade, segurança, e performance; - Outros requerimentos como sistemas operacionais e ambientes, compatibilidade e restrições de design. Formalização da Prestação de Serviço Nesta atividade é negociada formalmente, pelo Gestor de conta com os Clientes, a prestação do serviço através de contrato ou aditivo específico. Orçamento e Cronograma Geral podem ser renegociados nesta atividade, de acordo com a dinâmica do relacionamento do Gestor de conta com os Clientes. Após a assinatura de contrato ou aditivo, o desenvolvimento se inicia com o Documento de Ativação do Projeto. Glossário Uma relação dos termos, e respectivas descrições, usados no domínio do sistema. Manual do Sistema Manual do Sistema Desenvolvido. Pode ser impresso ou em mídia magnética. Mapa de Navegação Este artefato deve ser construído para as aplicações Web. É uma representação gráfica da estrutura hierárquica de navegação das páginas HTML. Modelo de Caso de Uso Este modelo identifica as funcionalidades que o sistema deverá atender ao ambiente externo. É o diagrama da UML usado para se identificar como o sistema se comporta em várias situações que podem ocorrer durante sua operação. Descreve o sistema, seu ambiente, e a relação entre os dois. Os componentes deste modelo são os atores e os Casos de Uso. Modelo de Classe É o modelo de classes do sistema a ser desenvolvido. Descreve as classes do sistema e seus relacionamentos de forma estática. É construído na forma do diagrama de classes da UML.
110
Modelo de Componentes Um componente representa uma parte do código do software (fonte, binário ou executável), ou um arquivo contendo informação (por exemplo, um arquivo de inicialização ou um arquivo ReadMe). O Modelo de Componentes apresenta o relacionamento entre os componentes do sistema. É representado pelo Diagrama de Componentes da UML. Modelo de Dados Modelo lógico de dados mapeado do modelo de classes. Modelos de Estado É a descrição dos possíveis estados de uma classe e a dinâmica de mudança dos estados. É representado pelo diagrama de Estado da UML. Modelo de Processos de Negócio Mapeamento dos processos do negócio. Notas de Versão Documento a ser gerado para toda versão liberada para instalação. Consiste numa descrição das características da versão. Orçamento Nesta atividade será feito o orçamento técnico do desenvolvimento do sistema, a ser negociado pelo gestor da respectiva conta com os Clientes. Plano de Implantação Neste documento são relacionadas e programadas todas as tarefas necessárias para implantação do sistema no ambiente produtivo tais como: povoamento, piloto, processamento paralelo, treinamento etc. Plano de Iteração Descrição dos subdomínios de análise de cada iteração. Um Sistema simples pode ser elaborado em apenas uma iteração. Porém, para projetos grandes (os que abrangem várias áreas distintas em um mesmo negócio) pode-se dividir o domínio do sistema em subdomínios e então realizar uma iteração para cada subdomínio facilitando assim a análise. O planejamento de cada iteração, e seus respectivos subdomínios, deve estar descrita no Plano de Iteração. Plano de Teste É um documento que define todo o planejamento de teste que será realizado no sistema.
111
Realizações de Caso de Uso As Realizações de Caso de Uso são a representação da interação entre classes na realização de cada caso de uso. Uma realização de caso de uso pode ser expressa por um ou mais diagramas de seqüência e colaboração da UML. Registro de Reunião Toda reunião relativa ao projeto, seja interna ou com clientes, deve ser registrada, anotando-se os principais pontos discutidos, as resoluções alcançadas e as pendências. Sistema Implantado Sistema instalado nos ambientes de produção e do usuário, disponibilizando suas funcionalidades para o usuário final, observando as diretrizes, normas e padrões das áreas de Produção e Telecomunicações, da DATAPREV. Usuários Treinados Usuários treinados para utilizar o novo Sistema. Visão Em Visão, é definida a visão que os envolvidos têm do produto a ser desenvolvido, em termos das necessidades e características mais importantes. Por conter uma descrição dos requisitos centrais pretendidos, ela proporciona a base contratual para requisitos técnicos mais detalhados.
Aborda os seguintes itens: - Análise do Ambiente Empresarial Busca-se identificar os objetivos da área do Cliente, suas linhas de atuação, a infra-estrutura disponível, o organograma e as pessoas chaves da área, bem como a disponibilidade de investimento em Informática. - Análise dos Fatores Críticos e Problemas Procura identificar os fatores críticos de sucesso e os principais problemas, relativos a sistemas de informação que afetam a área do Cliente em questão. - Definição das Principais Necessidades de Informação Aqui são identificadas as necessidades de informação de suporte a decisão que contribuam para atingir os fatores críticos de sucesso e superar os problemas de informação da área do Cliente em questão. - Identificação das Prioridades para informatização São definidas as prioridades das necessidades de informatização levantadas anteriormente, que irão orientar o desenvolvimento dos produtos para o Cliente. - Diagrama de Contexto Diagrama que contextualiza o sistema a ser desenvolvido no negócio e seu relacionamento com outros sistemas do negócio. Possui um alto nível de abstração.
112
Anexo II – Exemplos de artefatos
Atividade: A.1.2.6.) Definir Papéis e Responsabilidades
Artefato: Tabela de papéis e responsáveis
Tabela 1 – Tabela de papéis e responsáveis pelos processos (considerando apenas o
domínio do processo Tratar Entrega do Produto.)
Processo Responsável Papéis (atores)
envolvidos no processo
Formar Volumes por Modalidade/
Destino
Unidade de Expedição Operador de expedição
Enviar Volumes por Modalidade/
Destino
Unidade de Expedição Despachante de expedição
Agente de transporte
Entregar Volumes em seus Destinos Unidade de Expedição Despachante de expedição
Agente de transporte
113
Atividade: A.2.3.2.) Modelar os Processos de Negócio
Artefato: Modelo de Processos de Negócio (Descrições de Fluxos de Eventos dos
Processos de Negócio)
Processo: Formar Volumes por Modalidade/Destino:
Descrição: Este processo realiza a formação de volumes de objetos a serem
enviados. É um processo contínuo.
Fluxos de Eventos:
Os objetos chegam à unidade para ser expedidos;
Um operador de expedição deve colocar uma etiqueta de identificação
única em cada um dos objetos;
O operador de expedição pesa cada objeto e registra seu peso seu peso;
O operador de expedição deve identificar o próximo destino do objeto em
função da escolha entre possíveis Rotas pré-estabelecidas para cada
relação Origem/Destino;
Para cada combinação Destino/ Modalidade de Envio(malote, sedex,
correio, aéreo) os objetos são agrupados em volumes respeitando as
regras de formação de volume(limitações de peso e espaço dos volumes
em cada modalidade).
O operador de expedição deve gerar a Relação de Conteúdo de cada
Volume
114
Processo: Enviar Volumes por Modalidade/ Destino
Descrição: Este processo consiste em despachar os volumes formados no
processo anterior para a próxima unidade de expedição estabelecidas em suas
Rotas.
Fluxo de Eventos:
Quando chega a hora de despachar (pré-estabelecida para cada
Modalidade) um despachante de expedição deve registrar e gerar uma
Lista de Volumes a ser entregue ao agente de transporte junto com os
volumes;
O agente de transporte recolhe os volumes e partem para a entrega
destes.
Processo: Entregar Volumes em seus Destinos:
Descrição: Os agentes de transporte entregam os volumes nas unidades de
expedição de seus destinos.
Fluxo de Eventos:
Os agentes de viagem chegam às unidades de destino do volume e
entregam os entregam a um despachante da Unidade de Expedição.
O despachante da Unidade de Expedição deve confirmar o recebimento
de cada volume com base na Lista de Volumes.
115
Atividade: A.1.2.3.) Modelar os Processos de Negócio
Artefato:
116
Atividade: A.1.2.3.) Modelar os Processos de Negócio
Artefato: Modelo de Processos de Negócio
a) O processo Expedição:
117
b) Detalhamento do processo Expedição:
118
c) Detalhamento do processo Tratar Entrega dos Volumes:
119
d) Detalhamento:
120
e) Detalhamento do Processo Formar Volumes por Modalidade e Destino:
121
Atividade: A.2.3.1.) Modelar os Objetivos do Negócio Artefato: Modelo de Objetivos
122
Atividade: A.1.2.4.) Modelar os Recursos Envolvidos Artefato: Modelo de Recursos
123
Atividade: A.2.3.3.) Modelar os Recursos Envolvidos Artefato: Modelo de Recursos
124
Atividade: A.1.5.1.) Identificar Necessidades de Informatização Artefato: Diagrama de Linha de Montagem a) Identificação dos subsistemas de informação, e fluxos de eventos entre estes e o processo Expedição:
125
b) Identificação dos principais Casos de Uso do sistema para atender ao processo de Expedição:
126
Atividade: A.2.4.1.) Identificar Necessidades de Informatização
Artefato: Diagrama de Linha de Montagem a) Detalhamento do fluxo de eventos entre o processo de negócio e os subsistemas:
127
b) Casos de uso identificados no detalhamento:
