modelagem de processos 2

Prévia do material em texto

9
MODELAGEM DE PROCESSOS
Re
vi
sã
o:
 B
ea
tr
iz
 -
 D
ia
gr
am
aç
ão
: M
ár
ci
o 
- 
22
/0
8/
09
GESTÃO-2ºsem-2ºmod
Unidade II
5
10
15
20
3 MODELAGEM DE SISTEMAS
A fase de desenvolvimento de um novo sistema de 
informação (Quadro 2) é um momento complexo que exige um 
signifi cativo esforço no sentido de agregar recursos que venham 
a apoiar a geração do código, a validação e a implantação do 
que é o objetivo do evento de uma forma clara, efi ciente e no 
tempo planejado. Os profi ssionais ligados ao desenvolvimento 
de sistemas usam dados, processos e modelos de objeto para 
compreender os sistemas existentes e projetar os novos. 
Esses modelos tornaram-se um padrão no mercado porque 
fornecem uma linguagem que os analistas, os projetistas e os 
desenvolvedores podem usar para comunicar-se efi cientemente. 
Dessa forma, os gerentes de projetos se benefi ciam da 
compreensão desses modelos, de modo que possam melhor 
comunicar suas necessidades.
Atualmente, existem softwares que geram programas 
de computador diretamente dos modelos de sistema. São 
as chamadas ferramentas CASE (Computer-Aided Software 
Engineering, ou Engenharia de Software Assistida por 
Computador), que podem acelerar, de maneira signifi cativa, 
o desenvolvimento de sistemas. Essas ferramentas podem 
auxiliar os desenvolvedores a compreender e a manter estes 
programas.
10
Unidade II
Re
vi
sã
o:
 B
ea
tr
iz
 -
 D
ia
gr
am
aç
ão
: M
ár
ci
o 
- 
22
/0
8/
09
3.1 Os desenvolvedores de sistemas podem 
escolher entre quatro caminhos
Modelo Descrição Usos Vantagens Desvantagens
Cascata
Segue ordenadamente os 
estágios do ciclo de vida 
do desenvolvimento de 
sistemas.
Projetos de grande porte 
e complexos, com muitas 
pessoas e áreas envolvidas
Sem retrabalho.
Fácil de administrar.
Altamente infl exível.
Não há entregas 
provisórias.
Espiral
Entrega o sistema em 
versões conforme a regra 
80/20, de acordo com a 
necessidade.
Organizações dinâmicas 
que podem tolerar 
ambiguidades e necessitam 
obter resultados com 
rapidez.
Rápida entrega do 
produto.
Progresso fácil de ver
Retrabalhos constantes 
Custos elevados.
Prototipagem
Concentra-se na interface 
do usuário numa interação 
cíclica dos estágios de 
projeto e desenvolvimento.
Projetos de porte pequeno 
a médio, em que os 
requisitos são vagos ou 
obscuros.
Curto período entre 
análise e implementação.
O sistema satisfaz melhor 
as necessidades.
Evita custos 
desnecessários.
Ampliada comunicação e 
interação entre usuários e 
desenvolvedores.
Aumenta as expectativas 
do usuário.
Não garante redução de 
custos.
Atrasa a funcionalidade 
do sistema.
Programação 
ágil
Avalia necessidades 
e desenvolve 
especifi cações durante o 
desenvolvimento.
Pequenos projetos 
conduzidos por 
desenvolvedores 
experientes e competentes 
e usuários que desejam 
tomar parte no processo de 
desenvolvimento.
Rápida entrega do 
produto
Pronto atendimento às 
necessidades do usuário
Mais difícil de aplicar 
conceitos de qualidade, 
tais como medição de 
desempenho e melhoria 
de processos.
Pode decair 
acentuadamente com 
desenvolvedores fracos.
Quadro 2 - Estilos de desenvolvimento de sistemas. Fonte: Gordon e Gordon, 2006.
11
MODELAGEM DE PROCESSOS
Re
vi
sã
o:
 B
ea
tr
iz
 -
 D
ia
gr
am
aç
ão
: M
ár
ci
o 
- 
22
/0
8/
09
GESTÃO-2ºsem-2ºmod
3.2 Modelos de dados
Os modelos de dados são responsáveis por descrever os 
relacionamentos existentes entre os elementos de dados que 
uma organização utiliza. O modelo conhecido como “entidade-
relacionamento” ou “diagrama ER” é um dos modelos de dados 
mais usados (Figura 6). Contudo, existem também outros 
modelos. O ANSI (American National Standards Institute) suporta 
um padrão diferente, o modelo de dados conhecido por IDEF1X. 
Este modelo assemelha-se ao modelo entidade-relacionamento. 
Uma vantagem deste modelo está em se converter mais 
diretamente para uma implementação de banco de dados 
relacional. Os produto, tais como o Visible Analyst, da Visible 
Systems, e o System Architect, da Popkin Software, suportam 
ambos os modelos, bem como diversos outros.
região
nome-representante
contato
clientes
ID
endereço
fone-representante
fone-cliente
nome-cliente
representante-vendas
representa dados-representante
1
M
Figura 6 - Diagrama ER: mostra o relacionamento entre representantes de vendas 
e seus clientes. Fonte: Gordon e Gordon, 2006.
3.3 Modelos de processos
Os modelos de processos dividem um processo em etapas, 
identifi cam como estas etapas se relacionam entre si e indicam 
quais saídas de um processo são entradas para outros. Os 
modelos de processos mais utilizados incluem diagramas de 
5
10
15
12
Unidade II
Re
vi
sã
o:
 B
ea
tr
iz
 -
 D
ia
gr
am
aç
ão
: M
ár
ci
o 
- 
22
/0
8/
09
estrutura, quadros de funções e diagramas de fl uxo de dados 
(DFDs).
• Os diagramas de estrutura demonstram o relacionamento 
entre os programas e subprogramas que compreenderão 
o sistema acabado. Na Figura 7, o diagrama de estrutura 
para um sistema de folha de pagamento evidencia o 
projeto modular do sistema, no qual a execução de uma 
determinada tarefa, como o cálculo do pagamento líquido, 
requer a terminação das tarefas abaixo, que compreendem 
o cálculo de impostos e cálculo de deduções.
Processo 
da folha de 
pagamento
Calcular 
pagamento 
normal
Calcular 
horas 
extras
Calcular 
impostos
Calcular 
deduções
Ler registro 
mestre de 
empregado
Ler
cartão
de ponto
Gerar 
relatório de 
pagamento
Gerar
cheques de 
pagamento
Ler
entrada
Calcular
pagamento
Gerar
saída
Calcular 
pagamento 
bruto
Calcular 
pagamento 
líquido
1.0
2.0 3.0 4.0
2.1 2.2 4.1 4.2
3.23.1
3.1.1 3.1.2 3.2.1 3.2.2
Figura 7 - Diagrama de estrutura de um sistema de folha de pagamento. Divide os 
processos de folha de pagamento em três subprocessos.Os subprocessos
sofrem novas divisões. Fonte: Gordon e Gordon, 2006.
• O quadro de funções, ilustrado na Figura 8, implementa 
o modelo IDEF0 do ANSI, no qual cada quadro de função 
corresponde a uma caixa num diagrama de estrutura. As 
5
10
13
MODELAGEM DE PROCESSOS
Re
vi
sã
o:
 B
ea
tr
iz
 -
 D
ia
gr
am
aç
ão
: M
ár
ci
o 
- 
22
/0
8/
09
GESTÃO-2ºsem-2ºmod
linhas entre as caixas mostram os relacionamentos entre 
as entradas e saídas dos procedimentos. Os documentos 
que suportam a metodologia IDEF0 mostram um único 
quadro de função juntamente com a divisão dessa caixa 
em suas subtarefas em cada página.
Função de 
manutenção
Controles
Mecanismos
Entradas Saídas
Figura 8 - O quadro de funções IDEF0 mostra como um processo se conecta com 
outros processos. Fonte: Gordon e Gordon, 2006.
• Os diagramas de fl uxo de dados (DFDs) - Figura 9 - 
são responsáveis por modelar o fl uxo dos dados entre 
processos. Mas, eles não modelam a decomposição dos 
processos em subprocessos ou a ordem em que as tarefas 
são executadas para realizar um processo. Por exemplo, 
um arquivo de empregados mantém dados armazenados 
sobre a classe de pagamento do empregado, o nível de 
pagamento e as deduções. Dessa forma, os processos para 
determinar o pagamento bruto e calcular o pagamento 
líquido usam esses dados armazenados.
5
10
15
14
Unidade II
Re
vi
sã
o:
 B
ea
tr
iz
 -
 D
ia
gr
am
aç
ão
: M
ár
ci
o 
- 
22
/0
8/
09
Limite do sistema
Catrão de
ponto
Classe de 
incidência
Nível de 
pagamento
Pagamentobruto
Cheque de 
pagamento
Pagamento 
líquido
Pagamento 
líquido
Condição 
de imposto
Pagamento 
de deduções
Empregados
Calcula 
pagamento
bruto
Calcula 
deduções 
extras de 
impostos
Arquivo de 
empregado
Cria 
contracheque
Calcula 
impostos
Saldo da 
tesouraria
Registro 
histórico de 
pagamentos
Tabelas de 
impostos
Figura 9 - Diagrama de fl uxo de dados de um sistema de folha de pagamento. São 
mostradas as entradas e saídas de cada procedimento e as fontes e o uso de dados 
que estão fora do limite do sistema. Fonte: Gordon e Gordon, 2006.
3.4 Modelos de objeto
Os modelos de objeto identifi cam as propriedades dos objetos, 
seus relacionamentos entre si e as funções que executam. Os 
modelos de objeto incluem, frequentemente, os diagramas de 
herança, que mostram como os objetos herdam suas propriedades 
de outros objetos. Os modelos de objeto podem também incluir 
diagramas de estado para mostrar como as características de 
objeto mudam à medida que os eventos externos afetam um 
objeto, e como o objeto responde diferentemente às mensagens, 
dependendo do seu estado.
5
15
MODELAGEM DE PROCESSOS
Re
vi
sã
o:
 B
ea
tr
iz
 -
 D
ia
gr
am
aç
ão
: M
ár
ci
o 
- 
22
/0
8/
09
GESTÃO-2ºsem-2ºmod
Os objetos incorporam tanto os dados quanto as operações 
que podem ser executadas sobre os dados. Os relacionamentos 
entre objetos, dados e processos motivaram o desenvolvimento 
de modelos que incorporam todos os três elementos. Entre os 
recursos mais populares para se gerar modelos que estabeleçam 
os relacionamentos desejados está o UML.
Porém, deve-se refl etir a respeito sobre o que é realmente 
desenvolver sistemas orientados a objetos. Ao se observar a 
forma como a análise e o projeto de sistemas vem sendo realizada 
em muitos lugares, pode-se verifi car que muitos profi ssionais 
simplesmente adotam uma linguagem orientada a objetos ou 
até algum fragmento de processo orientado a objetos, sem 
muita consciência do que estão fazendo.
Portanto, de nada adianta realizar investimentos pesados na 
aquisição de ferramentas CASE orientadas a objetos sem a devida 
compreensão da forma de se pensar orientada a objetos. Dessa 
forma, conclui-se que o uso de diagramas pode não melhorar a 
qualidade do software produzido. Para um profi ssional chegar a 
ser um arquiteto de software, existe uma série de conhecimentos 
que precisam ser compreendidos.
4 UML
Muitos profi ssionais acreditam que UML é uma metodologia, 
mas na verdade é uma linguagem. UML signifi ca Unifi ed Modeling 
Language (linguagem de modelagem unifi cada) e é usada para 
descrever eventos. Contudo, conhecer uma linguagem não implica 
em habilidade para saber utilizá-la com efeito. Tome-se por base 
a língua portuguesa ou a inglesa, nas quais saber escrever não 
necessariamente implica em saber falar bem, ou descrever eventos 
com precisão para que qualquer leitor possa compreender. Nesse 
caso, existem “métodos” ou “processos” que auxiliam, por exemplo, 
os escritores na defi nição de eventos com clareza. Esses métodos 
e processos ajudam a estruturar adequadamente as frases para 
que estas produzam o efeito desejado.
5
10
15
20
25
30
16
Unidade II
Re
vi
sã
o:
 B
ea
tr
iz
 -
 D
ia
gr
am
aç
ão
: M
ár
ci
o 
- 
22
/0
8/
09
Dessa forma, ao se usar a linguagem UML, pretende-se 
produzir projetos de sistemas com elegância, claros e bem 
estruturados, nos quais os leitores terão uma fácil assimilação 
do que se pretende descrever.
4.1 Para que é utilizado a UML?
A UML é uma das mais linguagens mais utilizadas no mundo 
para especifi car modelos de sistemas. Foi desenvolvido pelo OMG 
(Object Management Group), e destina-se a modelar aplicações, 
comportamentos, arquitetura e também processos de negócios 
e estruturas de dados. Além disso, promove a unifi cação de 
vários passos do desenvolvimento e da integração de modelos 
de negócios por meio da modelagem de arquitetura e aplicação 
para o desenvolvimento, implantação, manutenção e evolução.
O OMG é formado por um consórcio da indústria da 
computação, sem fi ns lucrativos, que desenvolve uma força 
tarefa para defi nir padrões de integração para as corporações 
para um amplo escopo de tecnologias.
Segundo a OMG, a UML é uma linguagem visual para 
especifi cação, construção e documentação de “artefatos” de 
software:
• a criação de esquemas UML, cujo o propósito da modelagem 
é, principalmente, para entender e documentar;
• a UML sozinha não resolve nada: ela deve ser usada dentro 
de um processo de desenvolvimento!
A UML defi ne uma linguagem padrão e uma notação gráfi ca 
para a criação de modelos de negócios e sistemas técnicos. 
Ao contrário da opinião popular, a UML não é apenas para 
programadores. De fato, a UML defi ne diversos tipos de modelos 
que abrangem uma grande escala de modelos e requisitos 
funcionais de fl uxo de trabalho para projetos de estrutura de 
5
10
15
20
25
17
MODELAGEM DE PROCESSOS
Re
vi
sã
o:
 B
ea
tr
iz
 -
 D
ia
gr
am
aç
ão
: M
ár
ci
o 
- 
22
/0
8/
09
GESTÃO-2ºsem-2ºmod
classe e diagramas de componentes. Este livro descreve como 
esses modelos são aplicados para especifi car o uso da XML 
no contexto de um sistema de e-business. Esses modelos, e 
um processo de desenvolvimento que os utiliza, melhoram e 
simplifi cam a comunicação entre interessados de aplicações 
muito diversas.
A UML tem progredido a passos largos para atingir seu 
objetivo de possuir um padrão unifi cado e está se tornando a 
linguagem preferida para a descrição de sistemas de negócios. 
O fato de a UML ter sido aceita na prática, e não apenas 
como um padrão teórico formal, contribuiu para um rápido 
desenvolvimento e para uma competição saudável entre as 
ferramentas de modelagem UML. Os produtos compatíveis com 
UML abrangem desde conjuntos de engenharia de software 
completos até ferramentas de análise de requisitos orientadas a 
negócios relativamente baratas.
5
10
15