Apostila PSI

Projeto de Sistemas
Caderno de Contedo da Disciplina (Projeto de

Sistemas)

Prof. Gustavo Campos Menezes

Centro Federal de Educao Tecnolgica de Minas Gerais
2
P
g
i
n
a
2

1

Projeto de Sistemas - Viso Geral

Prof. Autor: Gustavo Campos Menezes
e-Tec Brasil Projeto de Sistemas

3
P
g
i
n
a
3

Meta

Apresentar uma viso histrica do surgimento da Teoria de
Desenvolvimento de Sistemas e dos Processos existentes.

Objetivos

Ao final desta aula, voc dever ser capaz de:
Entender o que um sistema
Conhecer os processos de desenvolvimento de sistemas
existentes.

4
P
g
i
n
a
4

1 Teoria de Sistemas
A Teoria de Sistemas (TS) um ramo especfico da Teoria Geral de Sistemas (TGS).
A Teoria Geral de Sistemas (T.G.S.) surgiu com os trabalhos do bilogo alemo
Ludwig von Bertalanffy.
Bertalanffy criticava a viso que se tem do mundo dividido em diferentes reas,
como fsica, qumica, biologia, etc. So divises arbitrrias. E com fronteiras
solidamente definidas. E espaos vazios entre elas. A natureza no est dividida em
nenhuma dessas partes.
A TGS fundamenta-se em trs premissas bsica:
a) Os sistemas existem dentro de sistemas
b) Os sistemas so abertos
c) As funes de um sistema dependem de sua estrutura

A soma das partes menor que o todo. Bertalanffy, 1976.
Todo = Soma das partes + Relacionamento entre partes

1.2 Constituio dos Sistemas

1. Sistemas fsicos ou concretos: quando so compostos de equipamentos, de
maquinaria e de objetos ou coisas reais. (hardware)
2. Sistemas abstratos ou conceituais: quando compostos de conceitos, planos,
hipteses e idias. (software)
3. Sistemas fechados: so os sistemas que no apresentam intercmbio com o meio
ambiente que os circunda, pois so hermticos a qualquer influncia ambiental.
4. Sistemas abertos: so os sistemas que apresentam relaes de intercmbio com o
ambiente, atravs de entradas e sadas.

5
P
g
i
n
a
5

Modelo Genrico de um Sistema Aberto

Figura 1: Modelo de Sistema Aberto

Os sistemas abertos so compostos por seus elementos (partes) e as relaes
entre eles. So eles:

Entrada ou insumo - a fora de arranque de um sistema; permite a operao do
sistema;

Processamento ou transformador - o fenmeno que produz mudana, converte
entradas em sadas;

Sada ou resultado - a finalidade para qual se reuniram elementos e relaes do
sistema. Devem ser coerentes com a finalidade do sistema;

Retroao ou retroalimentao - funo que visa comparar a sada a determinados
padres estabelecidos. Visa manter ou aperfeioar o desempenho do processo;

Ambiente - o meio que envolve externamente o sistema.

1.3 Parmetros dos Sistemas

Os sistemas abertos so compostos por seus elementos (partes) e as relaes
entre eles. So eles:

Entrada ou insumo - a fora de arranque de um sistema; permite a operao do
sistema;

Processamento ou transformador - o fenmeno que produz mudana, converte
entradas em sadas;

Sada ou resultado - a finalidade para qual se reuniram elementos e relaes do
sistema. Devem ser coerentes com a finalidade do sistema;

6
P
g
i
n
a
6

Retroao ou retroalimentao - funo que visa comparar a sada a determinados
padres estabelecidos. Visa manter ou aperfeioar o desempenho do processo;

Ambiente - o meio que envolve externamente o sistema.

1.4 Descrio dos Sistemas

Objetivos do Sistema
O que o sistema deve fazer
Ambiente
Onde o sistema est inserido (fronteira com o meio exterior)
Recursos
Insumos retirados do ambiente para executar transformaes
Componentes
Elementos essenciais para seu funcionamento
Administrao
Mtodos ou componentes que utilizam os recursos para atingir os objetivos

1.5 Porque Projeto de Sistemas?
Alguns dos motivos que levam as organizaes a desenvolverem sistemas: aumento da
qualidade dos produtos e servios; o aumento da vantagem competitiva sobre os
concorrentes; o aumento do nvel de servio, do desempenho dos recursos humanos;

Em Projetos de Sistemas, vamos estudar um mtodo para desenvolver sistemas.
Muitas vezes queremos programar diretamente nossos sistemas em vez de projet-los
anteriormente. Porm, essa no uma boa prtica. Segundo estudos feitos nos EUA para se
medir a produtividade no desenvolvimento de sistemas (Standish Group), revelaram que:

30%-40% dos projetos so cancelados;

50% dos projetos custam mais que o dobro do custo inicialmente
projetado;

15-20% dos projetos terminam dentro do prazo e dentro
do oramento.

Os principais problemas encontrados foram:

Falta de qualidade do produto final;

No cumprimento dos prazos;

No cumprimento dos custos.

7
P
g
i
n
a
7

Problemas Enfrentados

Figura 2. Problemas

Outra Metfora

Figura 3. Comunicao entre Usurio e Analista

8
P
g
i
n
a
8

Abaixo, a figura 3 descreve alguns dos principais problemas encontrados pelo Desenvolvedor de
Software:

Figura 4. Desafios Enfrentados no Desenvolvimento de Software

O Perfil que um Analista de Sistemas deve possuir:
Comunicao: Capacidade de ouvir, redigir e expor ididas com clareza e preciso;
Capacidade de Anlise: Aptido para realizar operaes mentais com abstraes;
Capacidade de Negociao: Saber administrar conflitos de interesse pessoais. Ser
conciliador. Saber trabalhar em equipe;
Conhecimento da sua rea: Conhecimento pessoal adquirido por meio da vivncia
com as operaes da empresa;
Gerenciar projeto: Capacidade de gerir a alocao dos recursos humanos e
materiais diante da disponibilidade financeira e do tempo;
Conhecimento tcnico: Capacidade de especificar sistemas de informao,
utilizando ferramentas de modelagem, linguagem de programao, banco de
dados, arquitetura de sistemas e redes de computadores.

9
P
g
i
n
a
9

Caractersticas que um Sistema deve possuir:
Confiabilidade: Sistema deve possuir o menor nmero de defeitos bugs possvel;
Desempenho: Sistema deve possuir um tempo de resposta aceitvel para o usurio;
Facilidade de uso : Sistema deve ser de fcil utilizao;
Flexibilidade: Deve ser possvel alterar/evoluir o sistema de maneira fcil.

1.6 Metodologias de Desenvolvimento de Software

Metodologia: Descrio sobre a maneira de se utilizar um conjunto coerente e coordenado de
mtodos para atingir um objetivo, de modo a se evitar a subjetividade na execuo do
trabalho.
Mtodo: Procedimento adotado para se atingir um objetivo;
Tcnica: Modo apropriado de se investigar sistematicamente um determinado universo de
interesse do problema;
Notao: um conjunto de caracteres, smbolos e sinais formando um sistema convencionado
de representao;

DESENVOLVIMENTO DE SOFTWARE E ENGENHARIA DE SOFTWARE:
Processo de desenvolvimento de software, pode ser definido como um conjunto de
atividades, mtodos, prticas e transformaes que pessoas utilizam para desenvolver ou dar
manuteno em softwares ou seus produtos associados (projetos, manuais, cdigo, etc.) (SEI-
Carnegie Mellon University. The Capability Maturity Model: guidelines for improving the
software process. Addison Wesley. 1995 p.8)
Engenharia de Software a disciplina que integra processos, mtodos e ferramentas para o
desenvolvimento de software. (PRESSMAN, Roger S. Software Engineering: a practioners
approach. Fouth edition. McGraw-Hill, 1997. Chapter 2: the process. P. 49)

10
P
g
i
n
a
1
0

1.7 Ciclos de Vida do Desenvolvimento de Sistemas
Um Sistema pode ser interpretado como um organismo. Desta forma, todo sistema tem o seu
Incio, Desenvolvimento e trmino. Independente do processo de desenvolvimento, todo
processo de desenvolvimento apresenta todas ou algumas das etapas abaixo: (extradas de []).
Anlise e definio de requisitos: Atravs de tcnicas de entrevistas so
definidas as principais funes que o sistema. As funes so definidas ao
detalhe para especificar o sistema;
Projeto de Sistemas e Software: O projeto do sistema agrupa os requisitos em
sistemas de hardware e software;
Implementao e teste de unidade: Nesta fase o projeto do software visto
como um conjunto de programas ou unidades de programa. O teste de
unidade tem como objetivo verificar se cada unidade ou mdulo atende a
especificao;
Integrao e teste de sistemas: Os mdulos ou unidades do programa so
integrados e testados como um programa completo. Depois dos testes, o
programa entregue ao cliente;
Operao e manuteno: Fase considerada como a mais longa do ciclo de vida.
O sistema instalado e colocado em operao. A medida que novos requisitos
ou defeitos so descobertos, o sistema sofre manutenes e atualizaes.
Modelos de desenvolvimento:
a) Codifica- Remenda

Figura 5. Codifica-Remenda

11
P
g
i
n
a
1
1

Partindo de uma especificao, ou nem isto, os desenvolvedores comeam
imediatamente a codificar, remendando medida que os erros acontecem. Possui apenas
pontos negativos. Normalmente o sistema normalmente nunca termina, ou abandonado.

b) Cascata

Figura 6. Cascata
Os subprocessos so executados em estrita seqncia. O que permite demarc-los com
pontos de controle bem definidos. Possui baixa visibilidade para o cliente, que s recebe o
resultado no final do projeto. Os principais estgios deste modelo (conforme a Figura 5)
so:

c) Espiral

Figura 7. Processo em espiral

12
P
g
i
n
a
1
2

Projeto desenvolvido em uma srie de iteraes, onde cada iterao corresponde a uma
volta na espiral. Permite construir produto funcional em prazos curtos. Difcil de gerenciar
o projeto.

d) Prototipagem Evolutiva

Figura 7. Prototipagem
Combinao dos modelos Cascata e Prototipagem Evolutiva. Permite que em pontos bem
definidos os usurios possam avaliar parte do produto.
e) Entrega Evolutiva

Figura 8. Entrega Evolutiva

13
P
g
i
n
a
1
3

A espiral usada no para desenvolver um produto completo, mas para construir uma
srie de verses provisrias chamadas prottipos. Maior interao entre desenvolvedor e
cliente

DICA!!
Antes de Iniciarmos o prximo captulo, segue algumas dicas para o projeto de Uma
Interface:
Divida a tela em regies
Agrupe os dados logicamente
Alinhe os dados verticalmente
Explicite o tamanho dos campos de entrada
Evite telas poludas
Evite exagero no uso de recursos visuais
Fornea mensagens elucidativas e objetivas
Pea confirmao para funes crticas (como excluso)
Proporcione feedback
Ordene as listas exibidas
No exija preenchimento de caracteres no significativas
Utilize um vocabulrio consistente
Considere a seqncia dos dados do documento associado
Seja consistente, mantenha padres

14
P
g
i
n
a
1
4

EXERCCIOS:
Exerccio 1:

Voc foi convidado para desenvolver um sistema informatizado que dever controlar
uma oficina de uma concessionria de veculos. O cliente leva o carro ao consultor
tcnico que o encaminha a oficina para diagnstico e oramento. Se aprovado executa
o servio e troca as peas. Sabe-se que o sistemas vendas j est implantado. Deseja-
se emitir a NF a partir da OS fechada.

Identifique:
a) Quais so as principais funcionalidades?
b) Quantos programas sero necessrios desenvolver?
c) Quem so e em que momentos os usurios iro interagir com o sistema?
d) Quais sero as entradas e sadas de dados
e) Quais arquivos e campos sero necessrios ser criados?

15
P
g
i
n
a
1
5

2

Levantamento de Dados & Anlise
Essencial



16
P
g
i
n
a
1
6

Meta

Apresentar um conjunto de tcnicas para levantamento de
dados necessrios ao desenvolvimento de um sistema.
Apresentar os princpios da Anlise Essencial de Sistemas

Objetivos

Conhecer as principais tcnicas de levantamento de
dados existentes.
Conhecer as ferramentas da Anlise Essencial de
Sistemas

17
P
g
i
n
a
1
7

2 Tcnica de Coleta de Dados
Os problemas com que o Analista de Sistemas deve se deparar so na maioria das
vezes extremamente complexos. Desta forma, difcil sem o uso de alguma tcnica,
estabelecer claramente o que o sistema deve fazer. Os requisitos de um sistema so
basicamente as funes que o sistema deve possuir para desempenhar corretamente o seu
papel dentro de uma organizao. Basicamente um requisito pode ser definido como a
descrio das funes e restries para o sistema. Abaixo, segue algumas tcnicas adotadas
para estabelecer uma coleta de dados ou levantamento de requisitos.
Principais tcnicas adotadas:
Entrevistas;
Pesquisa em manuais ou documentos internos;
Reunio em Grupo JAD;
Questionrios;
BrainStorming;
2.1 Entrevistas
Etapas:
Preparao Prvia;
Estrutura;
Forma de Conduo pelo Analista;
Documentao;
Entrevista Preparao:
1) Pesquisar previamente o problema:
Estudar a organizao:
Ambiente Interno: Ramo de negcio, produtos e servios, estrutura
organizacional;
Ambiente Externo: Concorrncia, pontos fortes e fracos;

18
P
g
i
n
a
1
8

2) Organizar Infra-Estrutura:
Desenvolver agenda de atividades e encaminhar com antecedncia
para a empresa;
Indicar os responsveis;
Verificar se os participantes confirmaram presena;
Requisitar salas e equipamentos;
No dia anterior, confirmar a reunio;

Entrevista Estruturao:
Adequar condutas ao contexto (nvel hierrquico do entrevistado)
Partir do geral para o especfico.
Entender os processos: quando, quem e porque.
Resumir oralmente a entrevista no final.
Gerar documento escrito aps a entrevista (ata).
Entrevista Conduo:
Apresentes-se e justifique sua atribuio.
Ser mais informal.
Separar fatos de opinies.
No jogue em nenhum time.
A responsabilidade em decidir do usurio
No prolongar, seja objetivo.

19
P
g
i
n
a
1
9

2.2 Reunio
Conduta:
Reforar as colocaes interessantes dos participantes.
Ignorar comentrios fora do objetivo, dar foco.
Interromper dilogos paralelos.
Esforar-se para obter a opinio de todos, inclusive dos mais tmidos e
subalternos.
Escrever as decises em local visvel a todos participantes.
Olhe para quem est falando.
Concentre-se na reunio (desligue celular, esquea l fora).
Pergunte e esclarea qualquer dvida.
Mantenha a calma e o bom humor.
No interrompa.
Seja impessoal.
Nas reunies com participantes de reas diversas, evite tratar assuntos
especficos de uma determinada rea.

Pontos negativos de uma Reunio:
Atrasos.
Sair antes.
Interrupes por terceiros/telefone.
Discusses desnecessrias.
Resistncia a mudanas.
Participantes despreparados.
Prolongamento desrespeito hora de incio e trmino previstos.
Todos falam juntos.

20
P
g
i
n
a
2
0

Esteretipos dos Participantes
O comentarista
O desenhista
O engraadinho
O sabido
O chato
O batedor de papo lateral
O que concorda com tudo
O puxa saco
O dorminhoco
O rei da batucada

21
P
g
i
n
a
2
1

2.3 Joint Application Design - JAD
JAD Tem como objetivo principal Acelerar e Consolidar o Desenvolvimento de Aplicaes. Ela
Foi desenvolvida no final da dcada de 70 incio da dcada de 80 pela IBM Canad.
Caractersticas:
Reunies substituem as entrevistas individuais
Decises baseadas em consenso;
Economia de 30% a 40% do tempo;
Benefcios:
Reduo da necessidade de manuteno nos aplicativos desenvolvidos;
Reduo de custos;
Maior satisfao dos usurios;
Maior entrosamento entre a rea de Sistemas de Informaes e os Departamentos
Usurios;
Menor necessidade de modificaes durante o processo de desenvolvimento;
Nivelamento das expectativas de ambas as partes .

Componentes:
Patrocinador Executivo: o executivo que banca o projeto. Detm autoridade
formal sobre as rea de negcio afetadas. Estabelece objetivos e diretrizes.
Ele abre a sesso inicial demonstrando o apoio e a importncia dados pela
administrao superior ao projeto.
Gerente de Projeto: Normalmente o lder do time de desenvolvimento da
aplicao. Ele gerencia o dia a dia do projeto respondendo as questes sobre o
escopo, prazo, coordenao dos recursos Nas sesses atua como membro da
equipe.
Lder de Sesso Facilitador: Guia imparcial do grupo. Ele no contribui com
informaes, apenas conduz os participantes ao longo da agenda, garantindo
que todos sejam ouvidos e que haja consenso. Responsvel por identificar as
questes que devem ser discutidas na reunio daquelas que devem ser
encaminhadas para investigao e discusso futura.
Documentador: Registra e publica os procedimentos da reunio. Ele no
contribui com informaes.

22
P
g
i
n
a
2
2

Participantes: So os clientes da rea de negcio que so afetados de forma
direta ou indireta pelo projeto. Eles so especialistas em suas reas e podem
tomar decises sobre sua rea de trabalho. Eles so a fonte de informaes
sobre as regras de negcio em que atuam.
Observadores: Geralmente so membros do time de desenvolvedores
envolvidos no projeto. Eles ficam sentados atrs dos participantes e observam,
sem participao, aos procedimentos da reunio.

JAD ORGANIZAO
O processo bem estruturado: Cada sesso tem uma finalidade previamente definida. O
lder conduz o grupo para o objetivo, seguindo os passos da agenda. Flip-charts so
colocados nas paredes de forma que todos vejam os resultados.
Fases do JAD:
1) Abertura Agenda: Apresentao dos participantes. Estabelecimento de conduta dos
participantes.Apresentao da agenda. Palavras do executivo patrocinador (viso
estratgica / objetivos,do projeto.
2) Desenvolvimento - Apresentar o tpico da pauta. Discutir assuntos pertinentes.
Utilizar brainstorming, consenso ou votao. Obter e registrar os acordos. Prximo
tpico.
3) Fechamento - Resumir os tpico apresentados. Resumir as solues aprovadas.
Distribuir tarefas e anotar tendncias. Avaliar a sesso. Agendar prxima data.
Tipos de Sesso:
1) Planejamento: uma sesso inicial do projeto que visa abordar objetivos, metas,
escopo e estratgias. Mximo de 20 pessoas.
2) Processos, eventos, dados: Depende das tcnicas de anlise (sero estudadas em
breve). Visam definir os componentes de software do sistema. Gerentes e supervisores
devem estar presentes No mximo de 10 pessoas.
3) Interface: Definio de telas, relatrios e interfaces. Apresentao de prottipos.
Supervisores e pessoal operacional.Mximo de 5 pessoas.

23
P
g
i
n
a
2
3

Comparao do JAD com tcnicas tradicionais de levantamento de dados:

Tabela 1. Comparao de tcnicas de Levantamento de Requisitos.

24
P
g
i
n
a
2
4

2.4 Anlise Essencial
Antes de comearmos definitivamente com tcnicas Orientadas a Objetos e ao uso da
UML, vamos fazer um pequeno estudo com relao Anlise Essencial de Sistemas. Embora
seja uma tcnica pouco utilizada atualmente, grande parte dos sistemas existentes e sua
documentao, est associada Anlise Essencial ou Estruturada.
A anlise Essencial pode ser vista como uma evoluo da Anlise Estruturada por
adicionar a preocupao com o controle. Usa uma lista de eventos externos como base para o
particionamento do sistema. Os eventos geram fluxos de dados (estmulos) para o sistema; O
modelo essencial construdo sem considerar restries de implementao (assume uma
tecnologia perfeita) o que permite uma soluo ideal para o problema. Na anlise essencial
um sistema de informao visto como um sistema de resposta planejado; Os eventos
acionam aes (ativam processos que so alimentados com os dados); Os eventos podem
gerar respostas internas (persistncia de dados) ou respostas que retornam ao ambiente
(relatrios, emails, etc).

Figura 9 Anlise Essencial de Sistemas

O modelo essencial do sistema indica o que o sistema deve fazer para satisfazer os
requisitos do usurio, mencionando o mnimo possvel (de preferncia nada) sobre como o
sistema ser implementado. (YORDON, 1990 p. 397)

25
P
g
i
n
a
2
5

Estrutura da Anlise Essencial:
Modelo Ambiental define a fronteira entre o sistema e o ambiente
Descrio do propsito do sistema.
Diagrama de contexto.
Lista de eventos.
Modelo de Entidade e Relacionamento (conceitual).
Dicionrio de dados
Modelo Comportamental descreve o comportamento interno do sistema em funo de
estmulos que ocorrem no ambiente externo
DFD Diagrama de Fluxo de Dados.
DER Diagrama de Entidade e Relacionamento.
DTE Diagrama de Transio de Estado.
Dicionrio de Dados.
Especificao de processos, etc.

Neste primeiro momento considera-se a confeco de um modelo essencial com uma
tecnologia perfeita. Supe-se uma tecnologia ideal e sem limitaes, onde:
Os custos, o consumo e o desgaste so zero;
A capacidade de armazenamento de dados do sistema infinita;
A velocidade dos processadores infinita;
Zero erro (no ocorrem falhas).
constituda basicamente por duas fases (modelo ambiental e
comportamental)

26
P
g
i
n
a
2
6

2.5 Modelo Ambiental
Tem-se a especificao macro do sistema (como se fosse uma caixa preta)
Declarao de Objetivos:
Deve estar resumida a um pargrafo;
Ser global, especificando o principal propsito da criao do software;
No cabe neste ponto estabelecer uma lista textual com todas as
funcionalidades esperadas no sistema.
Diagrama de Contexto:
Reflete graficamente a relao do sistema com o meio ambiente onde est
inserido;
Esta relao d-se por meio de recebimento de estmulos do meio ambiente,
os quais ativam processos, e estes, por sua vez geram respostas externas ao
sistema, ou seja, resposta ao meio ambiente;
Lista de Eventos:
Especificao das atividades (processos) essenciais que o sistema ter;
Estas atividades so ativadas por estmulos, executam processamento e
geram respostas;
No h uma precedncia estabelecida para a elaborao da lista de eventos e
o diagrama de contexto;
So atividades que podem estar acontecendo em paralelo, porm devem
estar consistentes.

27
P
g
i
n
a
2
7

2.6 Modelo Comportamental
O Analista ir detalhar como cada atividade existente na lista de eventos se comporta
(como ela deve funcionar). Ser feito um modelo de dados sobre o qual o sistema atuar. Cria-
se um dicionrio de dados e um DFD. Possui os seguintes diagramas:

Diagrama de Fluxo de Dados particionado por evento:
Para cada item da lista de eventos, o analista de sistemas far um Diagrama
de Fluxo de Dados, representando de forma grfica, individualmente, cada
evento existente no sistema.
Diagrama Entidade Relacionamento:
Para a modelagem de dados o analista far inicialmente o DER (modelagem
lgica) e logo aps ir gerar DER (modelagem fsica).
Diagrama Hierrquico de Macro Atividades:
Propicia uma viso sinttica nica do sistema;
Aglutina-se as funcionalidades existentes na lista de eventos de acordo com
os assuntos que tratam;
Aglutina-se por afinidade os DFDs particionados por evento;
Finalidade Documentacional e possibilidade de examinar e definir
interfaces.
Dicionrio de Dados:
Os dados referenciados na construo do sistema deve ter sua definio no
dicionrio de dados;
Padres para construo do dicionrio de dados.

28
P
g
i
n
a
2
8

2.7 Lista de Eventos
Evento uma frase que expressa um acontecimento externo ao sistema que gera um
estmulo no sistema que produz uma resposta. O evento a causa do surgimento do estmulo.
Portanto, um evento pode gerar vrios estmulos partindo de diferentes entidades externas.
Os eventos so classificados pelo tipo de estmulo que eles provocam no sistema.
1. Evento orientado por fluxo de dados (F) Aquele em que o estmulo a
chegado do fluxo de dados enviado por uma entidade externa.
O evento escrito da seguinte forma:
Sujeito + Verbo transitivo na voz ativa + Complementos verbais
Exemplo:

Figura 10 Exemplo de evento.

2. Evento orientado por Controle (C) - aquele em que uma Entidade
Externa envia um controle que muda o estado do sistema, ou em um
depsito de dados do sistema. Um evento orientado por Fluxo de dados
pode disparar internamente um evento de Controle. Ex: Caixa emite
N.F. dispara Nvel de resuprimento de estoque atingido.
O evento deve seguir:
Sujeito + Verbo transitivo na voz ativa + Complementos verbais
Sujeito + Verbo na voz passiva
Exemplo:

Figura 11. Evento de Controle

29
P
g
i
n
a
2
9

3. Evento temporal (T) Evento que ocorre quando transcorrido um
intervalo de tempo.
Modelo:
hora de + Verbo no infinitivo + Complementos verbais
Exemplo:

Figura 12. Evento Temporal

A figura seguinte apresenta uma tabela conhecida como lista de eventos. Nesta tabela so
listados os principais eventos do sistema, bem como o seu tipo (fluxo, controle ou temporal).

Figura 13 Lista de Eventos.

Como elaborar a lista de eventos:
Nome do Evento:
Nome + Verbo + Complemento
Ex: Cliente reserva um quarto (Funcional)
hora de cancelar a reserva (Temporal)
Descrio do Evento:
Como acontece o evento?

30
P
g
i
n
a
3
0

Item facultativo (porm se no constar na lista de eventos, dever constar no DFD
Particionado por Eventos)

Estmulo:
o fluxo de dados
Ex: Dados da Reserva/Cliente

Tipo Estmulo:
F (fluxo de dados) quando a entidade externa envia dados para o sistema;
T (temporal) quando as aes so do prprio sistema (o estmulo interno ao
sistema);
Neste caso a coluna do estmulo deve ficar em branco ou com um trao (-). E o nome do
evento deve comear com hora de... + complemento.

31
P
g
i
n
a
3
1

EXERCCIOS
1) Voc foi convidado a informatizar uma empresa de assistncia tcnica de computadores.
Durante a entrevista com gerente foram obtidas as seguintes informaes. Um cliente ao trazer
um equipamento atendido pelo balconista. Se ele no for cadastrado primeiramente deve-se
realizar seu cadastro. S ento verifica, pelo nmero de srie, se o equipamento est em garantia.
disponibilizado pelo fabricante um sistema de consulta remota (via socket) que poder ser
utilizado com a implantao do novo sistema. Se for garantia a mo-de-obra e peas sero pagas
pelo fabricante, seno ficar a cargo do prprio cliente. Em ambos os casos o balconista emite
uma ordem de servio com as solicitaes do cliente. Uma via da OS fica com o cliente e a outra
acompanha o equipamento que vai para oficina para diagnstico. O tcnico informa no sistema
registrando na OS, o(s) servio(s) e pea(s) necessrios no reparo, e a sua matrcula para
identificar quem fez o oramento. Em seguida emite o oramento. O setor administrativo recebe
em mos do tcnico os oramentos pendentes e faz contato telefnico a fim de conseguir ou no
a autorizao para realizao do reparo junto ao cliente ou fabricante conforme o caso, em
seguida registra no sistema. Se houver aprovao o setor administrativo devolve pessoalmente o
oramento para o tcnico. Aps executar o reparo, o tcnico fecha a OS registrando no sistema a
data de termino do reparo e a sua matrcula (identifica quem fez o reparo). O equipamento fica
disponvel, aguardando o cliente. Quando o cliente retorna para buscar o equipamento ele
novamente atendido pelo balconista que atravs do nmero OS localiza manualmente o
equipamento. O cliente faz o pagamento, se houver, ficando registrado no sistema a data da
entrega e o valor pago.
a) Lista de eventos
b) DER (Diagrama de Entidade Relacionamento).
c) Quais so as principais funcionalidades?
d) Quem so e em que momentos os usurios iro interagir com o sistema?
e) Quais sero as entradas e sadas de dados

2) Descreva os princpios bsicos de quatro tcnicas de coleta de dados.

3) Com relao tcnica de entrevista, descreva como cada uma das quatro etapas deve ser
realizada (preparao prvia, estrutura, forma de conduo e documentao)

4) Enumere pelo menos cinco esteretipos de participantes e descreva o perfil de cada um
deles.

5) O que JAD? Quais so as suas caractersticas?

6) Descreva os componentes do JAD e a funo de cada um deles.

7) Monte um quadro comparativo entre o Levantamento de requisitos tradicional e a tcnica
JAD.

32
P
g
i
n
a
3
2

9) Observe os conceitos de levantamento de requisitos, analise as sentenas e Marque V ou F.
[ ] Podem ser consideradas como tcnicas de levantamento de requisitos as entrevistas, a pesquisa em
manuais tcnicos, aplicao de questionrio, o Walkthrough e as reunies em grupo.
[ ] Para se obter um bom produto final de software necessrio iniciar rapidamente a codificao do
sistema evitando dessa forma que o usurio possa inserir novas demandas de funcionalidades.
[ ] A Joint Application Design - JAD tem como objetivo principal acelerar e consolidar o
desenvolvimento de aplicaes. Ela favorece as decises em consenso.
[ ] Os participantes de uma reunio JAD tm o papel bem definido so eles: patrocinador executivo,
gerente de projeto, lder de sesso, documentador, participantes e os observadores.

9)
Voc foi convidado a informatizar uma empresa de deseja realizar venda de CDs pela Internet.
Durante a entrevista com idealizador do site foram obtidas as seguintes informaes. O site ir
disponibilizar diversos ttulos de CDs de diversas gravadoras. O site ter vrios tipos de usurios.
O primeiro o administrador ser o responsvel em cadastrar todos os autores, gravadoras e ttulos
de CDs, alm de informar preos e promoes. O segundo, o internauta que ir acessar o site.
Qualquer internauta poder consultar o site. Mas para efetuar uma compra o internauta dever
primeiro realizar o seu cadastramento. A venda poder ser feita por carto, autorizado via Sitef o
qual ir gerar os pedidos solicitados quitados, ou atravs emisso de boleto gerando pedidos
solicitados pendentes. Um terceiro usurio (financeiro) ser o responsvel por processar a
quitao dos pedidos solicitados pendentes a partir da remessa de baixa de ttulos enviadas pelo
banco cobrador dos boletos. Um novo usurio responsvel pela expedio das mercadorias busca
informao dos pedidos pendentes quitados via carto e boleto diariamente a fim de emitir as
notas fiscais e processar a baixa no estoque.
a) Lista de eventos
b) DER (Diagrama de Entidade Relacionamento).
c) Quais so as principais funcionalidades?
d) Quem so e em que momentos os usurios iro interagir com o sistema?
e) Quais sero as entradas e sadas de dados ?

33
P
g
i
n
a
3
3

3

Anlise Orientada a Objetos
Introduo a UML



34
P
g
i
n
a
3
4

Meta

Apresentar e discutir os fundamentos da Anlise Orientada a
Objetos e de UML.

Objetivos

Conhecer os principais conceitos referentes Orientao a Objetos.
Utilizar alguns dos principais diagramas da UML para modelagem de
sistemas.

35
P
g
i
n
a
3
5

3 Anlise Orientada a Objetos
uma nova uma forma de abordar (entender e construir uma soluo) do um problema,
baseada no paradigma da orientao a objetos. uma Evoluo da Anlise Essencial e de
outras tcnicas de anlise.
Principais Caractersticas:
Resoluo de domnio de problemas mais amplos: GUI;
Melhoria na interao entre o analista e o usurio: utiliza mtodos naturais de
organizao do pensamento humano, como a analogia;
Aumento da consistncia interna da anlise: dados e processos so projetados
conjuntamente;
Representao explcita dos pontos comuns: uso de herana para identificar
atributos e mtodos comuns com especificaes que suportam alteraes de alto
nvel conceitual (propagao);
Reutilizao.

Figura 14 Etapas do processo de Desenvolvimento de Software OO

36
P
g
i
n
a
3
6

3.1 Fundamentos da Orientao a Objetos
Qualquer coisa um objeto.
Objetos realizam tarefas atravs da requisio de servios a outros objetos.
Cada objeto pertence a uma determinada classe. Uma classe agrupa objetos
similares.
A classe um repositrio para comportamento associado ao objeto.
Classes so organizadas em hierarquias.
Um sistema visto como uma coleo de agentes interconectados chamados objetos. Cada
objeto responsvel por realizar tarefas especficas. atravs da interao entre objetos
que uma tarefa computacional (funcionalidades do sistema) realizada.
3.2- Conceitos e princpios da OO
Classe : um molde para objetos. Diz-se que um objeto uma instncia de uma classe.
uma abstrao das caractersticas relevantes de um grupo de coisas do mundo real. Classe
possui membros (atributos e mtodos)

.
Ateno!
Uma abstrao qualquer modelo que inclui os aspectos relevantes
de alguma coisa, ao mesmo tempo em que ignora os menos
importantes. Abstrao depende do observador

37
P
g
i
n
a
3
7

Objeto: Instncia de uma classe. Um objeto um ente independente composto por:
Estado Interno: uma memria interna em que valores podem ser armazenados e
modificados ao longo da vida do objeto.
Comportamento: conjunto de aes pr-definidas (Mtodos) atravs das quais o
objeto responder as mensagens e desempenhar papis (funes).
OBJETO = DADOS + PROCESSOS
Um objeto criado por algum, tem uma vida e morre ou destrudo por algum.
Objeto como Abstraes:
Dependendo do contexto, um mesmo conceito do mundo real pode ser representado por
diferentes abstraes.
Carro (para uma transportadora de cargas)
Carro (para uma fbrica de automveis)
Carro (para um colecionador)
Carro (para uma empresa de kart)
Carro (para um mecnico)
3.3- Conceitos e Princpios da OO
Objetos so abstraes de entidades que existem no mundo real.
Classes so definies estticas, que possibilitam o entendimento de um grupo de
objetos.

Figura 15 Relao entre Classe e Objeto

38
P
g
i
n
a
3
8

Para que um objeto realize alguma tarefa, deve haver um estmulo enviado a este
objeto. Um objeto uma entidade ativa que representa uma abstrao de algo do mundo real
que pode responder a estmulos a ele enviados. Independentemente da origem do estmulo,
quando ele ocorre, diz-se que o objeto em questo est recebendo uma mensagem.

O encapsulamento uma forma de restringir o acesso ao comportamento interno de
um objeto. O mtodo que o objeto requisitado usa para realizar a tarefa no conhecido pelos
objetos requisitantes. Na terminologia da orientao a objetos, diz-se que um objeto possui
uma interface. A interface mostra o que o objeto faz, sem descrever como. A interface de
um objeto define os servios que ele pode realizar e as mensagens que recebe. Uma interface
pode ter vrias formas de implementao. Mas, pelo princpio do encapsulamento, a
implementao utilizada por um objeto receptor de uma mensagem no importa para um
objeto remetente da mesma.

A herana pode ser vista como um nvel de abstrao acima da encontrada entre
classes e objetos. Na herana, classes semelhantes so agrupadas em hierarquias. Cada nvel
de uma hierarquia pode ser visto como um nvel de abstrao. Cada classe em um nvel da
hierarquia herda as caractersticas das classes nos nveis acima. A herana facilita o
compartilhamento de comportamento entre classes semelhantes

Figura 16 . Herana
Hierarquia de Generalizao-Especializao: Cada classe herda as variveis e mtodos
definidos em classes superiores. (superclasse) . Cada classe pode e deve adicionar variveis e
estender mtodos herdados. A subclasse s justifica sua existncia a partir do momento em
que acrescenta algo (nem que seja um atributo e um processo) em relao s propriedades
herdadas. As subclasses so sempre verses mais especializadas de suas superclasses. Sem a
herana cada classe seria uma unidade independente e desenvolvida a partir do zero. A
execuo dos metdos se d pela procura bottom-up. No encontrou no filho, procura-se no
pai ... (Overhide)

39
P
g
i
n
a
3
9

Figura 17. Herana.
Composio: Identificar classes que necessitam objetos de outras classes para ser
implementadas. Relacionamento todo(que usa) / parte (o que usado) ou possui-um.
Exemplos:
Pessoa possui uma data de nascimento
Janela possui um ttulo e dois botes

Figura 18. Composio
Agregao: O conceito de uma classe contm um outro conceito como uma de suas partes
forma de agregao, onde a parte indissocivel do todo.
Exemplo: Um Controlador de Temperatura contm um Aquecedor.

Figura 19. Exemplo de Agregao

40
P
g
i
n
a
4
0

Composio X Agregao: Ambas se referem a relacionamentos de uso: um objeto parte de
outro objeto
Agregao
relacionamento contm-um
implementao pode usar a definio de uma classe interna.

Composio
relacionamento possui-um ;
implementao usa a definio de uma classe externa.

41
P
g
i
n
a
4
1

EXERCCIOS
1) Qual a principal diferena entre Classe e Objeto?
2) Agora que voc j fez as disciplinas de Linguagem de Programao I e II, quais as principais
diferenas entre a Programao Estruturada e a Programao Orientada a Objetos?
3) Descreva vantagens e desvantagens em se usar:
Programao Estruturada;
Orientao a Objetos.

42
P
g
i
n
a
4
2

4

UML



43
P
g
i
n
a
4
3

Meta

Apresentar e discutir os fundamentos da UML;

Objetivos

Conhecer os principais diagramas da UML para o desenvolvimento de
Software.

44
P
g
i
n
a
4
4

4- UML (Unified Modeling Language)

O que ?
Uma linguagem de modelagem unificada que rapidamente se tornou um
padro para a construo de software orientado a objetos.
Padronizada pela Object Management Group. (www.omg.org)

Segundo a especificao da OMG:
UML uma linguagem grfica para visualizar, especificar, construir e
documentar artefatos de um sistema software-intensivo.

UML oferece um modo padro descrever um sistema, incluindo tanto
coisas conceituais, tais como modelos de processo e funes de sistema,
como coisas concretas, tais como declaraes de linguagens de
programao, esquemas de bases de dados e componentes reusveis de
software.
Finalidade:

A UML define um nmero de diagramas que permitem dirigir o foco para
aspectos diferentes do sistema de maneira independente.

Facilita a comunicao de todas as pessoas envolvidas no processo de
desenvolvimento de um sistema gerentes, coordenadores, analistas,
desenvolvedores por apresentar um vocabulrio de fcil entendimento.

Classe X Objeto
Classes:
Tipo Abstrato de Dados;
So como plantas de Objetos;
Contm mtodos e dados;

kitchen
Living Room
Bath Office
Dining
Family
Covered Porch
Classe

45
P
g
i
n
a
4
5

Objetos:
Caso particular de uma classe;
Instncias de uma classe;
Contm mtodos e dados;

4.1 Estrutura da UML
UML 2.0 define 13 diagramas bsicos, distribudos em dois conjuntos gerais:

Diagrama de Modelagem Estrutural:
Definem a arquitetura esttica de um modelo;
Descrevem coisas que fazem parte de um modelo (classes,
objetos, interfaces e componentes fsicos);
Modelam a relao e interdependncia entre elementos;

Diagramas de Modelagem Comportamental:
Capturam as variedades de interao e estados instantneos em
um modelo, medida que este executa no tempo;
Objeto

46
P
g
i
n
a
4
6

Figura 20 Principais Diagramas da UML

Nas prximas sees feita uma breve descrio dos diagramas existentes na UML. No
Captulo seguinte, os principais diagramas sero discutidos com mais detalhes.
1. Diagrama de Atividade:
O propsito principal da elaborao de um diagrama de atividades mostrar, em
forma de modelos, os fluxos principais, alternativos, de exceo e concorrentes ao
fluxo principal. Estes fluxos so apresentados nas descries dos casos de uso.
Portanto, podemos definir atividades e diagrama de atividades da seguinte maneira: O
diagrama de atividades descreve a seqncia de atividades guiadas por um cenrio
estabelecido;
Uma atividade estar fazendo algo, por exemplo, a efetivao de uma reserva,
consulta de vos, entre outros.

Figura 21 Modelo de um Diagrama de Atividades.

Mostrar Caixa de
Mensagem
Disco Cheio
Mostrar Caixa de
Mensagem
Imprimindo
Criar arquivo
PostScript
Remover Caixa
de Mensagem
ImprimirArquivo()
[Disco Cheio]
[Espao em disco]
^Impressora.Imprimir(arq)

47
P
g
i
n
a
4
7

2. Diagrama de Caso de Uso:
Os diagramas de caso de uso so a forma visual de apresentar o conjunto de atores,
funcionalidades e relaes entre eles, diante de um determinado objetivo, e provenientes
dos passos de suas identificaes. Na prtica esse diagrama elaborado para ser um
instrumento de breve leitura, j que estamos transportando para um desenho tudo que
identificamos e descrevemos sobre os requisitos do cliente, podendo, assim, representar
melhor a complexidade do sistema.

Figura 22 Caso de Uso

48
P
g
i
n
a
4
8

3. Diagrama de Transio de Estado:
O propsito de um diagrama de estados mostrar em forma de desenho os possveis
estados de um objeto em particular. Atravs dele podemos visualizar a seqncia de
estados que um objeto ou uma interao percorre durante sua vida em resposta a
estmulos recebidos, junto com suas prprias aes e respostas. Portanto, podemos definir
que o diagrama de estados representa os eventos possveis para somente um objeto
individual, e as aes tomadas por esse objeto em resposta a esses eventos.

Figura 23 Diagrama de Transio de Estado.

49
P
g
i
n
a
4
9

4. Diagrama de Sequncia:
O diagrama de seqncia o diagrama que representa as comunicaes efetuadas
pelas classes do sistema, conforme um cenrio especfico, em um determinado momento.
Em outras palavras, este diagrama tem o objetivo de exibir visualmente a seqncia das
aes que o software executar frente aos comandos dados por um ator. O diagrama de
seqncia pode ser elaborado com base nos diagramas de caso de uso e de classes,
definidos nas fases anteriores do projeto. Porm, para que um diagrama de seqncia seja
elaborado, ao menos o diagrama de classes deve ter sido modelado anteriormente.

Figura 24 Diagrama de Sequncia.

5 . Diagrama de Colaborao ou Comunicao
O diagrama de colaborao tem o mesmo objetivo do diagrama de seqncia, ou seja,
ele representa os aspectos comportamentais do sistema, trazendo informaes sobre
como as interaes so efetuadas entre os objetos. As diferenas entre o diagrama de
seqncia e o de colaborao que este diagrama (colaborao) no representa o tempo
como um dimenso separada. As execues so exibidas em conjunto, independente do
tempo de execuo de cada objetos.

50
P
g
i
n
a
5
0

Figura 25 Diagrama de Colaborao.
6. Diagrama de Classe
O diagrama de classes um dos diagramas mais importantes num processo de
desenvolvimento de software que modela classes, relacionamentos e cardinalidades,
onde, em conjunto, apresentam a organizao de estrutura de um sistema.

Figura 26 Diagrama de Classe Completo.

51
P
g
i
n
a
5
1

7. Diagrama de Componente
O propsito da elaborao de um diagrama de componentes mostrar em forma de
desenho a arquitetura de um sistema de software atravs de seus componentes,
explicitando principalmente as suas dependncias. O diagrama de componentes ajuda-nos
a entender como os diversos componentes do sistema interagem entre si. Portanto,
podemos definir que o diagrama de componentes apresenta a arquitetura fsica e as
dependncias entre vrios componentes de software.

Figura 26 - Diagrama de Componente

52
P
g
i
n
a
5
2

8. Diagrama de Objeto
Desde o incio do desenvolvimento de um sistema orientado a objetos, pensamos no
s em definies e regras de negcios, mas tambm em tcnicas de modelagem que
auxiliem no entendimento e definio das tcnicas de implementao a serem realizadas e
utilizadas. O diagrama de objetos, pela UML definido como um tipo de modelagem onde
so representados os objetos que compem o diagrama e interagem entre si num sistema
orientado a objetos.

Figura 28 Diagrama de Objeto.
9. Diagrama de Instalao
O propsito da elaborao de um diagrama de implantao mostrar a organizao do
hardware e a ligao do software aos dispositivos fsicos. Este diagrama apresenta vrios
dispositivos de hardware e interfaces fsicas determinadas por seus esteretipos, como
processador, impressora, memria, e disco, suficientes para especificar a plataforma na
qual o sistema ser executado. O diagrama de implantao modela a viso esttica da
implantao de um sistema entre seus ns fsicos e seus relacionamentos, para especificar
seus detalhes referentes construo do sistema.

53
P
g
i
n
a
5
3

Figura 29 Diagrama de Instalao.
10. Diagrama de Pacote
O propsito da elaborao de um diagrama de pacotes mostrar como os elementos
podem ser organizados dentro de um sistema. Nota: Os elementos podero ser
considerados como classes e\ou pacotes. A vantagem de termos a representao de
elementos em pacotes que quebramos um sistema complexo em partes menores,
fornecendo uma viso de quantas e como se relacionam as vrias partes do nosso sistema.

Figura 30 Diagrama de Pacote

54
P
g
i
n
a
5
4

EXERCCIOS
1) O diagrama UML mais indicado para representar o passo a passo do fluxo de eventos
principal de um caso de uso de um software orientado a objetos o diagrama de:
a) Caso de Uso
b) Eventos e Transio
c) Diagrama de Atividades
e) Diagrama de Classes
f) Diagrama de Fluxo de Dados

2) Explique o que e para que serve a UML? D exemplos de pelos menos trs diagramas
estruturais e trs diagramas comportamentais.

55
P
g
i
n
a
5
5

5

Diagrama de Casos de Uso &
Diagrama de Classes



56
P
g
i
n
a
5
6

Meta

Apresentar e discutir dois dos principais diagramas da UML
Casos de Uso;
Diagrama de Classes;

Objetivos

Analisar e criar diagrama de Casos de Uso para o seu sistema;
Analisar e criar Diagramas de Classe;

57
P
g
i
n
a
5
7

5 Diagrama de Caso de Uso
um diagrama comportamental que descreve uma interao entre um usurio e um sistema,
ou seja, um cenrio (normal e os alternativos).
Ex: Uma compra na WEB com carto
Cenrio normal:
O internauta navega no catlogo de itens e adiciona os itens desejados sua cesta de compras.
Ele fornece dados de endereo de entrega, dados do carto de crdito e confirma a compra. O
sistema verifica autorizao do carto e confirma a venda, envia e-mail de confirmao.
Cenrio alternativo:
E se o carto de crdito no for aceito?
O diagrama de caso de uso pode ser entendido tambm como um conjunto de cenrios
amarrados por um objetivo comum de um usurio.

5.1 Maneira de Documentar um Caso de Uso
O caso de uso pode ser representado por meio de uma ficha contendo os seguintes campos:
Nome de Referncia: UC001 Nome do caso de uso (Verbo no
infinitivo).
Descritivo: Uma breve descrio do que trata a caso de uso.
Pr-condies: Informa o que necessrio acontecer para que o
caso de uso se inicie.
Atores: Informar quais so os envolvidos.
Cenrio Principal: Descrio que apresente o cenrio perfeito,
sem excees. Verbos no presente do indicativo ou substantivos.
Ex: Registra, compra, seleciona ...)
Cenrio Alternativo: Situao que represente uma exceo do
cenrio principal.
Requisitos Especiais: Qualquer situao no contemplada
anteriormente (Requisitos implcitos: Tempo de resposta, preciso
e etc.
Dados: Tipos de dados que foram encontrados durante a descrio
do caso de uso (caractersticas, tamanho e etc).
Observao: _________________________________________

58
P
g
i
n
a
5
8

Analista de negcio: _____________
Entrevistado: _______________
rea: _____________
Data: ___/___/___
Verso: _______

5.2 Exemplo de um Caso de Uso
Modelando o processo de compra de produto na Web com carto:
Pr-condio (Opcional)
Internauta dever ser autorizado com nome e senha.
Cenrio Principal
1 O cliente navega pelo catlogo e seleciona itens a serem comprados
2 O cliente confirma as compras
3 O sistema apresenta o total da compra
4 O cliente informa endereo de entrega e opes de pagamento
5 O cliente informa dados do carto
6 O sistema autoriza a compra
7 O sistema manda confirmao por e-mail

Cenrio Alternativo
Alternativa 1 Cliente Regular
(a) O sistema mostra local de entrega e os quatro ltimos dgitos do
carto.
(b) O cliente pode aceitar, ou reescrever dados. Vai para o cenrio
principal do item 6
Alternativa 2 Falha na autorizao

59
P
g
i
n
a
5
9

Sistema permite ao cliente resubmeter a informao do carto e tentar
novamente
5.3 Representao Grfica de um Caso de Uso
Componentes:
1 Ator- Representa o papel que o usurio est desempenhado ao interagir com o
sistema.simbolizado por um boneco.
2 Caso de uso Representa um cenrio
3 Reta conecta o ator ao caso de uso
4 Linha tracejada entre casos de uso (include extends)
5 Seta, com a ponta no hachurada, entre casos de uso (generalizao)
Associao:
Associao de incluso (Include): ocorre quando h uma parte do
comportamento que semelhante em mais de um caso de uso. Use include
quando houver repetio em dois ou mais casos de uso separados de uma
mesma descrio de comportamento.

Figura 31 Representao Grfica de um Caso de Uso.

60
P
g
i
n
a
6
0

Associao de Generalizao:
Associao de generalizao: pode ser usado quando existe casos de uso semelhante
s que um faz um pouco a mais que o outro. uma maneira de capturar cenrios
alternativos. Use generalizao quando desejar descrever uma variao do
comportamento normal sem muito rigor.

Figura 32 - Associao de Generalizao.

Associao de Extenso (Extends)
Semelhante generalizao, mas possui mais regras acrescentando comportamentos
adicionais. Use extend quando estiver descrevendo uma variao em comportamento
normal e deseja uma forma mais controlada, explicando os pontos de extenso do caso de
uso base.

Figura 33 - Associao de Extenso

Diagrama de Contexto:
o diagrama que mostra as interfaces do sistema com os diversos usurios e outros
sistemas com os quais ele ir interagir.

61
P
g
i
n
a
6
1

Figura 34 Exemplo de um caso de uso
5.4 Concluses sobre Caso de Uso
Auxilia no levantamento de requisitos (Cenrios).
Pode conter outros documentos que ajudem a entender o negcio alm de textos e
diagramas.
Deve-se trabalhar com verses (Requisitos mudam o escopo que no pode mudar).
Aps escrito, pea para um colega ler e explicar o que entendeu. Se houver dvidas
refaa.
Pea o usurio para assinar os caso de uso aprovados.
Deixe toda a documentao publicada na intranet ou extranet.

62
P
g
i
n
a
6
2

5.5 Exemplos e Exercciois
Uma vdeo locadora, deseja cadastrar seu acervo de fitas e cds, cadastrar os clientes,
possibilitar a consulta do acervo, fazer a locao selecionando fita e cliente, realizar a
entrega gerando dados para o sistema financeiro.
Soluo:
Diagrama de Contexto Vdeo Locadora

Figura 35 - Exemplo

63
P
g
i
n
a
6
3

Descrio dos Casos de Uso:

64
P
g
i
n
a
6
4

5.6 Diagrama de Classes
Uma classe pode ser vista como um template (modelo) a partir do qual os objetos so
criados (instanciados). Um objeto uma instncia de uma classe. Podemos imaginar uma
classe como um tipo, usado para modelar os elementos conceituais do mundo real. O
Diagrama de Classes descreve os tipos de objetos no sistema e os vrios tipos de
relacionamentos estticos que existem entre eles. O Diagrama de Classes pode possuir
diversas perspectivas de montagem:
Conceitual Diagrama representa os conceitos do domnio a ser estudado. Modelo
conceitual deve ser projetado com pouca ou nenhuma preocupao com a linguagem de
implementao.
Especificao Modelagem que considera o software perante a sua interface e no sua
implementao. Normalmente a melhor perspectiva a ser usada.
Implementao Trabalha com o mapeamento direto das classes, mostrando de forma
clara a implementao. Normalmente esta a forma mais utilizada.
Uma classe pode ser vista como um template (modelo) a partir do qual os objetos so
criados (instanciados). Um objeto uma instncia de uma classe. Podemos imaginar uma
classe como um tipo, usado para modelar os elementos conceituais do mundo real.
Representaes de uma Classe:
Nome Deve descrever o que a classe representa ou faz de forma clara;
Atributos - Caractersticas da Classe que devem ser representadas;
Operaes So as funcionalidades da Classe;

65
P
g
i
n
a
6
5

Regras:
Classes substantivo ou expresso breve Maisculas no primeiro caracter de
cada palavra. Ex: Cliente; ContaCorrente
Atributos substantivo ou expresso breve que representam alguma propriedade
da classe. Maisculas a partir da segunda palavra do nome. Ex: nomCliente;
codUfComercial
Operaes verbo ou locuo verbal breve, representando algum comportamento
da classe. Maisculas a partir da segunda palavra do nome. Ex mostrar();
obterSaldo();
Uma classe encapsula dados e conhecimento sobre algo do mundo. No se deve
misturar atributos e operaes de uma classe em outra.

Um bom projeto de Classe deve conter:
Atributos privados;
Sempre inicializar os dados;
Nem todos os atributos precisam conter mtodos get e set;
Organize classes e distribua as responsabilidades (funes);

O Diagrama de Classe:
um dos principais diagramas da UML, pois est relacionado ao modelo de soluo do
problema a partir de uma viso esttica da estrutura do sistema. Ele descreve os tipos de
objetos no sistema e os vrios tipos de relacionamentos estticos que existem entre eles.
Mostram tambm atributos e operaes de uma classe.

Figura 36 Diagrama de Classe

66
P
g
i
n
a
6
6

3.6 Relacionamentos entre Classes
Os objetos tm relaes entre si, ex: um professor ministra uma disciplina para alunos
numa sala. Estas relaes so conhecidas na UML como:
Associao / Agregao e Composio;
Dependncia;
Generalizao (herana);

Associao
So relacionamentos entre duas classes representados por uma linha slida.
Especificam que objetos de uma classe esto ligados a objetos de outras classes. Podemos ter
associao uniria, binria, etc.

Figura 37 Exemplo de Associaes.

Associao Unria - Quando h um relacionamento de uma classe para ela
mesma.

Figura 38 Associao Unria

67
P
g
i
n
a
6
7

Associao Binria - Quando h duas classes envolvidas na forma direta de uma
para a outra

Figura 39 Associao Binria
Associao N-ria Quando h um relacionamento entre mais de duas Classes.

Figura 40 Exemplo de Associao N-ria.

Classe Associativa introduzida quando uma associao tem propriedades
associadas.

Figura 41 Classe Associativa.
Papis de Associaes - Papis normalmente so colocados nas extremidades de
uma associao quando:
o A associao relaciona dois objetos da mesma classe;

68
P
g
i
n
a
6
8

o H mais de uma associao entre as classes;

Figura 42 Papis
Multiplicidade de Associaes Indica quantos objetos podem participar de um
dado relacionamento.
* - Representa uma variao de zero a infinito.
1 Indica relacionamento obrigatrio nico.
0..1 Pode ser nenhum ou um (relacionamento nico no obrigatrio)
1..5 Entre 1 e 5
2,4 Dois ou quatro

Agregao
Tipo de associao ( parte de, todo/parte) onde o objeto parte um atributo do todo;
A agregao faz sentido quando duas classes quando associadas tm um sentido prprio e
quando separadas continuam existindo como unidade autnomas: Ex: Uma garagem est
associada a um apartamento.

Figura 43 Agregao

69
P
g
i
n
a
6
9

Composio
Relacionamento entre um elemento (o todo) e outros elementos (as partes) onde as
partes s podem pertencer ao todo e so criadas e destrudas com ele. A associao com forte
dependncia de composio, implica que se a instncia da classe deixar de existir todas as
outras instncias associadas a ela deixaro de existir tambm. Ex: Notas fiscais e itens de nota
fiscais

Figura 44 Composio

Dependncia
Uma mudana na especificao de um elemento pode alterar a especificao do
elemento dependente. A dependncia entre classes indica que os objetos de uma classe usam
servios dos objetos de outra classe. Existe um relacionamento de dependncia entre duas
classes quando: uma classe utiliza a outra somente como parmetro de entrada na assinatura
de ao menos uma de suas operaes.

Figura 45 Dependncia

70
P
g
i
n
a
7
0

Generalizao (herana)
Relacionamento entre um elemento mais geral e um mais especfico. Onde o elemento
mais especfico herda as propriedades e mtodos do elemento mais geral. Como a relao de
dependncia, ela existe s entre as classes.

Figura 46 Herana

Figura 47 Herana Simples

71
P
g
i
n
a
7
1

Exemplo de um Diagrama de Classe:

Figura 48 Diagrama de Classe.

72
P
g
i
n
a
7
2

EXERCCIOS
1) O reitor de uma universidade privada deseja implantar um sistema de informao na
biblioteca a fim de controlar os emprstimos de livros para a comunidade acadmica (alunos,
funcionrios e professores). Voc foi convidado a fazer a especificao dos requisitos deste
sistema.

O sistema dever possibilitar que:
- a bibliotecria cadastre as tabelas bsica (Autores, Editoras e reas do Conhecimento),
cadastre Livros e Cadastre Usurios;
- os usurios consultem o acervo;
- o atendente possa realizar o emprstimo, e ao faz-lo, tenha acesso a consultar o acervo
e cadastrar usurio caso ele no exista. Deve-se verificar tambm se existem pendncias
para liberar ou bloquear o emprstimo. O atendente ser responsvel por informar dados
da devoluo do(s) livro(s), quando que, neste ato, sero verificados se houve atraso na
entrega, e se houver, gerar automaticamente o dbito para o usurio no Sistema de
Contas a Pagar para incluir o lanamento na prxima boleta.

Tomando como base as informaes acima, levantadas a partir de uma entrevista com os
membros da Universidade, construa os seguintes artefatos:

a) Fazer a especificao do caso de uso para os eventos emprestar livros e devolver livros.
Monte os quadros conforme modelo apresentado abaixo.
Caso de uso
Atores
Descrio
Aco do ator Resposta do sistema
Nro

2) Gerar uma Diagrama de Classe para modelar o seguinte problema: Deseja-se informatizar o
registro escolar de uma escola. Sabe-se que a escola possui alunos e que se deve manter
informaes da matrcula, nome, endereo e curso. Os alunos so matriculados em turmas.
Voc dever mostrar dados completos de um dado aluno e mostrar todos os alunos de uma
dada turma.

73
P
g
i
n
a
7
3

3) Marque a alternativa correta:
a) O Diagrama de Seqncia mostra uma interao, isto , uma seqncia de mensagens
trocadas entre vrios objetos num determinado contexto Enfatiza a comunicao e
passagem de controle entre objetos ao longo do tempo.
b) O Diagrama de Caso de Uso um diagrama comportamental que descreve uma
interao entre um usurio e um sistema, ou seja, um cenrio (normal e os
alternativos).
c) O Diagrama de Classe est relacionado ao modelo de soluo do problema a partir de
uma viso dinmica do sistema em execuo.
d) O Diagrama de Transio de Estado mostra os diferentes estados de um Objeto
durante sua vida, e o estmulo que faz com que o Objeto mude seu estado (atravs da
chamada de um mtodo de uma classe).
e) O Diagrama de Atividades descreve uma seqncia de atividades com suporte para
comportamento condicional e paralelo.

74
P
g
i
n
a
7
4

6

Diagramas de Atividade ,
Sequncia , Transio de Estados,
Pacotes, Componentes e Instalao


75
P
g
i
n
a
7
5

Meta

Apresentar e discutir os seguintes diagramas da UML
Diagrama de Atividade;
Diagrama de Sequncia;
Diagrama de Transio de Estados;
Diagramade Pacotes, Componentes e Instalao

Objetivos

Criar e Analisar diagramas de Atividade, Sequncia e Transio de
Estados, Pacotes, Componentes e Instalao.

76
P
g
i
n
a
7
6

6. Diagrama de Atividade
Descreve uma seqncia de atividades com suporte para comportamento
condicional e paralelo. Combina diversas tcnicas de modelagem de workflow e
modelagem de estados, etc. Este diagrama pode ser usado para modelar graficamente
quais caminhos (threads) programas concorrentes podem tomar e quando devem
sincronizar.
Principais componentes:

Figura 49 Notao para Diagrama de Atividades

77
P
g
i
n
a
7
7

78
P
g
i
n
a
7
8

Exemplo 1 Utilizao do Diagrama de Atividade:
O departamento de vendas de uma empresa de representao recebe os pedidos de seus
vendedores externos. Aps avaliar o crdito do cliente emite a nota fiscal enviando a 1 via
para o departamento de expedio e a 2 para o departamento financeiro. Enquanto a
expedio separa as mercadorias disponibilizando para fazer a entrega, o financeiro gera a
cobrana bancaria e aguarda receber o pagamento. Ao fim deste processo o pedido poder
ser finalizado. Para os cliente inadimplentes ser enviada uma cobrana ficando o pedido
cancelado.

Figura 50 Soluo do Exemplo 1.

79
P
g
i
n
a
7
9

Figura 51 Soluo do Exemplo 1 com SwimLines.

80
P
g
i
n
a
8
0

6. 1 Diagrama de Sequncia

Mostra visualmente a seqncia de aes que o software tomar frente a uma
interao com um ator.

Objetivos:
Enfatiza a comunicao e passagem de controle entre objetos ao longo do tempo.
Mostra uma interao, isto , uma seqncia de mensagens trocadas entre vrios
objetos num determinado contexto (caso de uso, operao, etc.)
Baseia-se no Diagrama de Casos de Uso
1 Caso de Uso N Diagramas de Seqncia
Baseia-se, tambm, no Diagrama de Classes
Fornecem as classes e os mtodos associados

81
P
g
i
n
a
8
1

Notao:

Figura 52 Notao para Diagrama de Sequncia

Mensagem Sncrona - So mensagens enviadas e, das quais, se espera um retorno
para prosseguir .

Figura 53 Exemplo de Mensagem Sncrona
o Seta - Objeto enviando uma mensagem para outro objeto (chamada de um
mtodo).
o Seta Tracejada representa o retorno da mensagem, quando diferentes de
void.

82
P
g
i
n
a
8
2

Mensagem Assncrona - So mensagens enviadas e, das quais, no se espera um
retorno imediato

Figura 54 Exemplo de Mensagem Assncrona
Seta c/ um trao - Objeto enviando uma mensagem para outro objeto
(chamada de um mtodo assncrono). Ex: Impresso de um relatrio.

Mensagem Recursiva Representa uma mensagem que enviada para o prprio
objeto. Ex: uma classe que recebe uma senha chame seu mtodo de criptografia antes
de enviar a senha para validao.

Figura 55 Exemplo de Mensagem Recursiva

o O X, no final de ocorrncia de execuo, indica que o objeto ir se auto
destruir. Desnecessrio representar.

83
P
g
i
n
a
8
3

Exemplo de Diagrama de Sequncia:

Figura 56 Diagrama de Sequncia

84
P
g
i
n
a
8
4

6. 2 Diagrama de Transio de Estado
Mostram os diferentes estados de um Objeto durante sua vida, e o estmulo que faz
com que o Objeto mude seu estado (atravs da chamada de um mtodo de uma classe).
Ajuda a modelar classes que tenham atributos que controlam seu estado.
Ajuda a refinar o Diagrama de Classe.

Notao:

Figura 57 Notao para Diagrama de Transio de Estados.

85
P
g
i
n
a
8
5

Exemplo de Diagrama:

86
P
g
i
n
a
8
6

6. 3 Diagrama de Pacotes
Um pacote pode conter qualquer diagrama UML, os mais comuns, so:
Diagrama de Classe ajuda no agrupamentos das classes afins.
Diagrama de Caso de Uso ajuda na abstrao do domnio do problema.
Como escolher as classes que pertencem a um pacote?
Classes de uma mesma hierarquia de herana.
Classes que estejam ligadas por agregao ou composio.
Classes que estejam em um mesmo Diagrama de Seqncia e que tenha muitas
colaboraes (alto acoplamento).
Exemplos:

Figura 58 Exemplo de Diagrama de Pacotes.

87
P
g
i
n
a
8
7

Utilizao do Diagrama de Pacotes em Caso de Uso
Figura 59 Diagrama de Pacotes em Casos de Uso

6. 4 Diagrama de Componentes e Implantao
Os diagramas de componentes mostram os elementos reutilizveis de software e sua
interdependncia, atravs de uma viso esttica da implementao de um sistema. Um
componente qualquer arquivo que contenha uma parte necessria para o funcionamento do
software. Ex: pginas HTML, arquivos de configurao .ini, arquivos executveis .exe, .dll, .jar
etc. Um componente expe suas interfaces (mtodos pblicos) para o mundo externo. Pode-
se utilizar a notao de interface esteriotipada.
Uma dependncia descreve como um componente alterado pode afetar outros
componentes (por exemplo: comunicao entre componentes, dependncias de compilao).
Componente: descreve um mdulo fsico do sistema.

88
P
g
i
n
a
8
8

Figura 60 Diagrama de Componente

Interface: uma coleo de operaes usadas para especificar um servio
disponibilizado pelo componente.

Figura 61 Exemplo

89
P
g
i
n
a
8
9

Dependncia: quando depende de outro componente ou de uma interface. A
dependncia pode ser unidirecional ou bidirecional.

Figura 62 Dependncia

Realizao: quando implementa uma Interface

Figura 63 Realizao

Generalizao: quando uma especializao de outro componente.

Figura 64 Generalizao

90
P
g
i
n
a
9
0

Associao: quando associado a outro componente.

Figura 65 Associao

Alguns exemplos de Diagramas de Componentes.
Figura 66 Diagrama de Componentes 1.

91
P
g
i
n
a
9
1

Figura 67 Diagrama de Componentes Exemplo 2.

6. 5 Diagrama de Implantao
Prov uma viso da relao fsica entre componentes de software e de hardware. Este
diagrama mostra os nodos do sistema, os componentes existentes e suas conexes:
Um nodo representa uma unidade computacional, usualmente uma parte do
hardware (Servidor, uma estao cliente) . Dentro de um nodo pode ser disposto um
(ou mais) componentes.
Uma conexo descreve um caminho de comunicao entre nodos.
Um nodo um objeto fsico, em tempo de execuo, que representa um recurso
computacional que possui, geralmente, memria e, freqentemente, capacidade de
processamento.

Figura 68 Nodo

92
P
g
i
n
a
9
2

Uma conexo representa a ligao de hardware entre dois nodos. Usualmente
bidirecional. Uma conexo pode ser direta (tal como um cabo serial) ou indireta (tal como
comunicao via-satlite).

Figura 69 Conexo

A conexo entre o software e hardware definida pelo relacionamento entre
nodos e componentes. Um nodo executa um (ou mais) componentes.
Figura 70 Relacionamento entre os componentes.

93
P
g
i
n
a
9
3

Um exemplo de Diagrama de Implantao:

Figura 71 Diagrama de Implantao Exemplo.

94
P
g
i
n
a
9
4

EXERCCIOS
1) Desenhe um diagrama de atividades mostrando as swimlanes, que represente a situao
descrita a seguir de um ambulatrio hospitalar.

O paciente ao chegar ao hospital primeiramente se encaminha recepo. Na recepo o
paciente apresenta os seus documentos identificando o convnio que ser utilizado, em
seguida ele informa seus sintomas. A recepcionista juntamente com o paciente define a
especialidade mdica e a urgncia para o atendimento, desta forma, o paciente entra numa
fila automatizada de espera. A secretaria que controla as consultas verifica a cada
disponibilidade do mdico o prximo da fila a ser chamado. Quando o paciente atendido na
consulta o mdico registra a anamnese, os dados do exame clnico, do diagnstico e cadastra
os medicamentos ou os exames se forem necessrios. O paciente retorna a secretaria que
encaminha o paciente, para a farmcia, ou para o laboratrio se houverem exames a ser feitos.
O laboratrio coleta material e registra no sistema o resultado dos exames. Quando o paciente
retorna na secretaria ele encaminhado para o mdico assim que houver uma disponibilidade.
Aps o mdico avaliar os exames via intranet o paciente encaminhado para internao ou
simplesmente para a farmcia. Obs. Os exames ficam disponveis via extranet para o paciente.

2) De todos os diagramas estudados at o momento, cite dois que voc considera mais
importantes e justifique a sua resposta.
3) Descreva a finalidade de :
Diagrama de Pacote;
Diagrama de Componente;
Diagrama de Implantao;
4) Desenhe um diagrama de atividades com raias, para representar a situao descrita de uma
empresa que vende computadores diretamente na loja ou atravs de entrega para todo o
Brasil.
O departamento de vendas recebe o pedido de compra de cliente, na loja ou via
telemarketing, e encaminha simultaneamente uma cpia para a expedio separar os itens e
outra para o setor financeiro avaliar o crdito do cliente. Caso no haja estoque ou o crdito
no for aprovado o pedido finalizado. Caso contrrio Vendas emite a nota fiscal, e dispara
simultaneamente uma via da NF para a expedio processar a entrega avaliando: se o cliente
estiver na loja entrega a mercadoria seno encaminha para a transportadora. A outra via na NF
vai para o setor financeiro que providencia a emisso das boletas e controla o recebimento.

95
P
g
i
n
a
9
5

Sobre o autor

Gustavo Campos Menezes Graduado em Tecnologia em Informtica
pelo Unicentro Newton Paiva Mestre em Cincia da Computao pela
UFMG. Professor efetivo do CEFET-MG desde setembro de 2006,
trabalha principalmente com disciplinas relacionadas a Linguagens de
Programao e Algoritmos para cursos de Informtica (Ensino tcnico) e
Engenharias (Graduao).

Referncias
MCMENAMIM, Sthephen M., PALMER John F. Anlise essencial de sistemas. So
Paulo: McGraw-Hill, 1991.
POMPILHO, S. Anlise Essencial: guia prtico de anlise de sistemas. Rio de Janeiro:
Infobook, 1994.
YORDON, Edward. Anlise estruturada moderna. Rio de Janeiro: Campus, 1990
MEDEIROS, Ernani S.: Desenvolvendo software com UML 2.0: definitivo. Pearson
Makron Books 2004.
LARMAN, Craig. Utilizando UML e Padres. 3 ed. Bookman, 2007.

Apostila PSI

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Apostila PSI

Enviado por

Direitos autorais:

Formatos disponíveis

Projeto de Sistemas

Caderno de Contedo da Disciplina (Projeto de

Você também pode gostar