Modelagem de Processos UNIP

Prévia do material em texto

Modelagem de 
Processos
Professor conteudista: Ricardo Holderegger
Sumário
Modelagem de Processos
Unidade I
1 INTRODUÇÃO .......................................................................................................................................................1
1.1 Documentação importante .................................................................................................................1
1.2 Histórico do sistema ...............................................................................................................................2
1.3 Sistemas complexos ...............................................................................................................................4
1.4 A documentação na Antiguidade .....................................................................................................6
2 DESENVOLVIMENTO DE SOFTWARES ORIENTADO A OBJETOS .........................................................7
Unidade II
3 MODELAGEM DE SISTEMAS ...........................................................................................................................9
3.1 Os desenvolvedores de sistemas podem escolher entre quatro caminhos ................... 10
3.2 Modelos de dados .................................................................................................................................11
3.3 Modelos de processos ..........................................................................................................................11
3.4 Modelos de objeto ............................................................................................................................... 14
4 UML ...................................................................................................................................................................... 15
4.1 Para que é utilizado a UML? ............................................................................................................ 16
Unidade III
5 PROCESSO DE DESENVOLVIMENTO DE SISTEMAS ............................................................................. 18
5.1 Fluxo de trabalho em relação aos requisitos ............................................................................. 18
5.2 Diagramas ................................................................................................................................................ 19
5.3 Diagramas de casos de uso .............................................................................................................. 19
5.4 Diagrama de atividades ..................................................................................................................... 22
5.5 Diagrama de classes ............................................................................................................................ 24
5.5.1 Acessibilidade dos atributos e métodos: ....................................................................................... 25
5.5.2 Representação de uma classe ............................................................................................................ 25
5.5.3 Representação de uma interface ..................................................................................................... 25
5.5.4 Associação ................................................................................................................................................. 26
5.5.5 Generalização ........................................................................................................................................... 26
5.5.6 Agregação e composição ..................................................................................................................... 26
5.5.7 Diagrama de classes – outras considerações .............................................................................. 27
5.6 Diagrama de objetos ........................................................................................................................... 27
5.7 Diagrama de sequência ...................................................................................................................... 27
5.8 Diagrama de estados .......................................................................................................................... 28
5.9 Diagrama de pacotes .......................................................................................................................... 30
Unidade IV
6 RELACIONAMENTOS ....................................................................................................................................... 31
6.1 Associação ............................................................................................................................................... 31
6.2 Multiplicidade de associação ........................................................................................................... 31
6.3 Associação reflexiva ............................................................................................................................ 33
6.4 Agregação ................................................................................................................................................ 33
6.4.1 Associação ou agregação .................................................................................................................... 34
6.4.2 Classe de uma associação de classe ................................................................................................ 34
6.5 Relacionamento entre pacotes ....................................................................................................... 34
6.6 Diagrama de componentes .............................................................................................................. 35
6.7 Diagrama de implantação ................................................................................................................ 36
7 MODELAGEM CONCEITUAL ......................................................................................................................... 36
7.1 Elementos básicos do modelo conceitual .................................................................................. 38
1
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
Unidade I
5
10
15
20
1 INTRODUÇÃO
O termo documentação tornou-se um conceito básico 
nos negócios, na administração, na ciência e na tecnologia 
da informação. A modelagem nada mais é que uma forma de 
documentar com detalhes os passos da geração de um sistema.
1.1 Documentação importante
Atualmente, o documento é “aparentemente” mais 
importante do que aquilo sobre o que ele trata. Neste sentido, 
pode-se considerar o caso das instituições e autoridades 
governamentais, em que uma pessoa somente existe se houver 
documentos que certifi quem esse fato. Uma pessoa “sem 
documentos” não possui uma identidade ofi cial.
Da mesma forma, nas corporações, embora um contrato 
comercial que cria um vínculo legal possa ser estabelecido com 
um aperto de mãos, a prática comum é colocar os termos desse 
contrato no papel. Todos os dias, milhões de transações em 
todo o mundo são acompanhadas de documentos, eletrônicos 
ou não, podendo ser notas fi scais, pedidos de compras, faturas, 
recibos e assim por diante.
Os documentos também são importantes para comunicar 
resultados científi cos entre cientistas e o estudo científi co, além 
do trabalho experimental e do estudo de campo. A reputação de 
um cientista é medida pelo número de documentos publicados 
e pela frequência com que é citado nos documentos produzidos 
por outros cientistas. Isto é importante para os projetistas 
2
Unidade I
Re
vi
sã
o:
 B
ea
tr
iz
 -
 D
iagr
am
aç
ão
: M
ár
ci
o 
- 
22
/0
8/
09
de sistemas de documentação: quanto mais fácil for fazer 
referência cruzada em um sistema, maior é a possibilidade de 
ele ser adotado pela comunidade científi ca.
1.2 Histórico do sistema
Observando o processo de desenvolvimento de um sistema 
por meio de uma visão de alto nível, percebemos que ele possui 
uma estrutura específi ca (Figura 1).
TesteAnálise Projeto Implementação
1 2 3 ...
Figura 1 - Esboço do processo de desenvolvimento. Fonte: Fowler e Scott, 2000.
Este processo se dá de forma iterativa e incremental, no 
qual o sistema ou o software não é implementado em um 
instante no fi m do projeto, mas é, ao contrário, desenvolvido 
e implementado em etapas. A fase de construção consiste de 
várias iterações, em que cada iteração constrói software de 
qualidade de produção, testado e integrado, que satisfaz um 
subconjunto de requisitos de projeto. Cada iteração contém 
todas as fases usuais do ciclo de vida da análise, do projeto, da 
implementação e do teste.
As duas primeiras fases são a análise e o projeto. Durante 
a análise, estabelece-se a lógica do domínio da aplicação para 
o projeto e decide-se o escopo do projeto. No projeto, são 
coletados os requisitos mais detalhados para se estabelecer 
uma arquitetura básica e criar um plano para a construção do 
sistema.
Os projetos variam de acordo com o volume de formalidade 
que eles possuem. Projetos de muita formalidade têm muitos 
documentos formais a ser entregues, reuniões formais, 
encerramentos formais. Projetos de pouca formalidade podem 
ter uma fase de concepção que consiste de um bate-papo de 
5
10
15
20
25
3
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
uma hora com o patrocinador do projeto e um plano que cabe 
em uma folha de papel. Naturalmente, quanto maior o projeto, 
maior formalidade é necessária.
A implementação elabora o sistema em uma série de 
iterações. Cada iteração é um novo “miniprojeto”, com casos de 
uso designados para cada iteração. Você termina a iteração com 
uma demonstração para o usuário e realiza testes de sistema 
na fase seguinte para confi rmar que os casos de uso foram 
construídos corretamente.
O objetivo deste processo é reduzir o risco. O risco, 
geralmente, aparece porque casos difíceis são deixados para o 
fi m do projeto.
As iterações dentro da implementação são tanto incrementais 
quanto iterativas.
• As iterações são incrementais na função. Cada iteração 
é construída sobre os casos de uso desenvolvidos nas 
iterações prévias.
• As iterações são iterativas em termos da base de código. 
Cada iteração implicará que alguns trechos de código 
existentes sejam reescritos para torná-los mais fl exíveis.
O teste e a integração são tarefas extensas, e elas sempre 
demoram mais do que as pessoas imaginam. Deixadas para o 
fi m, elas são difíceis e desanimadoras. Os testes visam identifi car 
quaisquer possíveis erros de construção ou conceito antes 
que o aplicativo seja disponibilizado para o usuário. Essa fase 
é de fundamental importância para a confi ança do software, 
pois aplicativos que apresentam muitos erros e interferem 
no desempenho de seus usuários tendem a ter uma pequena 
aderência e uma vida curta.
5
10
15
20
25
4
Unidade I
Re
vi
sã
o:
 B
ea
tr
iz
 -
 D
ia
gr
am
aç
ão
: M
ár
ci
o 
- 
22
/0
8/
09
1.3 Sistemas complexos
A documentação tornou-se o centro da infraestrutura 
de grandes sistemas de TI não apenas porque a autoria, o 
gerenciamento e a recuperação de documentos são áreas de 
aplicação importantes, mas também porque os componentes 
de software estão se tornando cada vez mais complexos. Nos 
primórdios da computação, na programação com Assembler 
(Figura 2) ou Fortran, as sub-rotinas eram construções bastante 
simples que podiam ser facilmente controladas com parâmetros 
igualmente simples: inteiros simples, números de ponto 
fl utuante, strings e endereços.
; the easiest way to print “hello, world!”
name “hi”
org 100h
jmp Start ; jump over string declaration
msg db “hello, world”, 0Dh, 0Ah, 24h
start: lea dx, msg ; load effective address of msg into dx.
mov ah, 09h ; print function is 9
int 21h ; do it!
mov ah, 0
int 16h ; wait for any key any...
ret ; return to operating system.
Figura 2 – Código Assembler
Fonte: <http://www.emu8086.com/dr/asm2html/assembler_source_code/>.
Nos dias atuais, os componentes reutilizáveis de softwares 
podem ser módulos enormes e bastante complexos, normalmente 
apoiados por interfaces repletas de recursos, o que tornou o 
entendimento dos sistemas modernos uma atividade altamente 
complexa. Por exemplo, um serviço Web. O protocolo de um 
serviço Web é descrito com uma linguagem chamada WSDL 
(Web Service Description Language), e a sintaxe das mensagens 
passada para um serviço Web pode ser descrita com a linguagem 
5
10
15
5
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
XML (Quadro 1), inicialmente chamada SOAP (Simple Object 
Access Protocol).
<?xml version=”1.0” encoding=”UTF-8”?>
<arder orderNo=“NILE01709” orderDate=”04/23/2002”>
<customer customerNo=”BD023432”>
<name>
<fi rst>John</fi rst>
<last>Doe</last>
</name>
<address>
<street>747 Sunset Strip</street>
<town>Miami</town>
<zip>99999</zip>
<state>FL</state>
<country>USA</country>
</address>
</customer>
<orderItem amount=”1”>
<CD productNo=“9488149012” year=”1999”>
<title>surte africaine</title>
<publisher>harmonia mundo</publisher>
<contributor kind=”performer”>Romano</contributor>
<contributor kind=”performer”>Sclavis</contributor>
<contributor kind=”performer”>Texier</contributor>
<contributor kind=”performer”>Ee Querrec</contributor>
</CD>
</orderItem>
<orderItem amount=“1”>
<book ISBN=”0140053972” year=“1977”>
<title>On Photography</title>
<publisher>Penguin</publisher>
<author>Susan Sontag</author>
<prece>19.95</prece>
</book>
</OrderItem>
</arder>
Quadro 1 - Exemplo de código XML. Compreende um pedido de compra serializado 
em XML, que poderia ser enviado a um sistema de compras que o executaria.
Fonte: Daun, 2004.
6
Unidade I
Re
vi
sã
o:
 B
ea
tr
iz
 -
 D
ia
gr
am
aç
ão
: M
ár
ci
o 
- 
22
/0
8/
09
1.4 A documentação na Antiguidade
Utilizando padrões de documento, o setor de TI pode 
aproveitar quase nove mil anos da experiência humana.
O conceito de documentação está totalmente relacionado 
ao propósito do desenvolvimento da representação gráfi ca de 
elementos que possam resgatar a fatos passados.
O advento dos sistemas de escrita remonta há nove mil anos e 
provavelmente coincidiu com a transição das sociedades de caça e 
coleta para sociedades mais agrárias. As evidências dos sistemas de 
escrita apareceram primeiramente em pedras entalhadas, utilizadas 
como símbolos de contagem, provavelmente usadas para contar 
certas propriedades, como animais ou medidas de grão (Figura 3).
Entre 4.100 e 3.800 a.C., na cultura suméria, na Mesopotâmia 
(atual Iraque), surgiu a escrita baseada em pictogramas.
Figura 3 - Símbolos de contagem entalhados no período neolítico.
Ao fi nal do quarto milênio a.C., a cultura egípcia desenvolveu 
o conceito de som. Pictogramas – hieróglifos – representavam 
as sílabas. Os hieróglifos (Figura 4), porém, representavam 
apenas as consoantes, não as vogais. Eles eram utilizados 
para representar o primeiro som da palavra representada 
pelo pictograma, um conceito chamado acrofonia. O mesmo 
conceito pode ser encontrado na escrita fenícia, que infl uenciou 
aescrita hebraica, aramaica e grega. Já em 800 a.C., os gregos 
5
10
15
7
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
foram os primeiros a representar as vogais com letras (Figura 5), 
sendo os precursores do alfabeto romano, no qual boa parte dos 
países latinos baseou o seu alfabeto.
Figura 4 - O hieróglifo egípcio.
Figura 5 - Os alfabetos fenício, grego antigo e romano.
Fonte: Daun, 2004.
2 DESENVOLVIMENTO DE SOFTWARES 
ORIENTADO A OBJETOS
Este conceito tem sido discutido há muito tempo, desde o 
lançamento da 1ª linguagem orientada a objetos, a Simula. Vários 
autores da engenharia de software mundial, como Peter Coad, 
Edward Yourdon e Roger Pressman, abordaram extensamente a 
análise orientada a objetos como, realmente, um grande avanço 
no desenvolvimento de sistemas. Porém, eles citam que não 
existe uma linguagem que possibilite o desenvolvimento de 
qualquer software utilizando a análise orientada a objetos.
Os conceitos que Coad, Yourdon, Pressman, e que tantos 
outros abordaram, discutiram e defi niram em suas publicações 
foram que:
• a orientação a objetos é uma tecnologia para a produção 
de modelos que especifi quem o domínio do problema de 
um sistema;
5
10
15
8
Unidade I
Re
vi
sã
o:
 B
ea
tr
iz
 -
 D
ia
gr
am
aç
ão
: M
ár
ci
o 
- 
22
/0
8/
09
• quando construídos corretamente, sistemas orientados 
a objetos são fl exíveis a mudanças, possuem estruturas 
bem conhecidas e provêm a oportunidade de criar e 
implementar componentes totalmente reutilizáveis;
• modelos orientados a objetos são implementados 
convenientemente utilizando uma linguagem de 
programação orientada a objetos. A engenharia de 
software orientada a objetos é muito mais que utilizar 
mecanismos de sua linguagem de programação, é saber 
utilizar, da melhor forma possível, todas as técnicas da 
modelagem orientada a objetos;
• a orientação a objetos não é só teoria, mas uma tecnologia 
de efi ciência e qualidade comprovadas, usadas em 
inúmeros projetos e para construção de diferentes tipos 
de sistemas;
• a orientação a objetos requer um método que integre o 
processo de desenvolvimento e a linguagem de modelagem 
com a construção de técnicas e ferramentas adequadas.
5
10
15