Análise de Sistemas - ETEC

Anlise de Sistemas
Luiz Egidio Costa Cunha

Jos Incio Serafini
Tempo
Curso Tcnico de Informtica
Aplicao
Desktop
Completo
Anlise
Aplicao
Desktop
Projeto
Servidor
Teste
Implementao
Aplicao
Desktop
Camada
Cliente
Camada
Servidor
Anlise de Sistemas
Jos Incio Serafini
Colatina - ES
2011
Presidncia da Repblica Federativa do Brasil

Ministrio da Educao
Secretaria de Educao a Distncia
Instituto Federal do Esprito Santo

Este Caderno foi elaborado em parceria entre o Instituto Federal do Esprito Santo
e a Universidade Federal de Santa Catarina para o Sistema Escola Tcnica Aberta
do Brasil e-Tec Brasil.
Equipe de Elaborao
Instituto Federal do Esprito Santo IFES
Coordenao de Design Grfico

Andr Rodrigues/UFSC
Coordenao Institucional
Guilherme Augusto De Morais Pinto/IFES
Joo Henrique Caminhas Ferreira/IFES
Design Instrucional
Renato Cislaghi/UFSC
Coordenao do Curso
Allan Francisco Forzza Amaral/IFES
Professores-autores
Luiz Egidio Costa Cunha/IFES
Jos Incio Serafini/IFES
Comisso de Acompanhamento e Validao
Universidade Federal de Santa Catarina UFSC
Coordenao Institucional
Araci Hack Catapan/UFSC
Coordenao do Projeto
Silvia Modesto Nassar/UFSC
Coordenao de Design Instrucional
Beatriz Helena Dal Molin/UNIOESTE e UFSC
Web Master
Rafaela Lunardi Comarella/UFSC
Web Design
Beatriz Wilges/UFSC
Mnica Nassar Machuca/UFSC
Diagramao
Brbara Zardo/UFSC
Juliana Tonietto/UFSC
Marlia C. Hermoso/UFSC
Nathalia Takeuchi/UFSC
Reviso
Jlio Csar Ramos/UFSC
Projeto Grfico
e-Tec/MEC
C972a Cunha, Luiz Egidio Costa

Anlise de sistemas: Curso Tcnico de Informtica / Luiz Egidio Costa
Cunha. Colatina: CEAD / Ifes, 2011.

104 p. : il.
ISBN: 978-85-62934-03-2
1. Anlise de sistemas. 2. Software - Desenvolvimento. 3. Material
didtico. I. Instituto Federal do Esprito Santo. II. Ttulo.
CDD: 004.21
Apresentao e-Tec Brasil

Prezado estudante,
Bem-vindo ao e-Tec Brasil!
Voc faz parte de uma rede nacional pblica de ensino, a Escola Tcnica
Aberta do Brasil, instituda pelo Decreto n 6.301, de 12 de dezembro 2007,
com o objetivo de democratizar o acesso ao ensino tcnico pblico, na modalidade a distncia. O programa resultado de uma parceria entre o Ministrio da Educao, por meio das Secretarias de Educao a Distancia (SEED)
e de Educao Profissional e Tecnolgica (SETEC), as universidades e escolas
tcnicas estaduais e federais.
A educao a distncia no nosso pas, de dimenses continentais e grande
diversidade regional e cultural, longe de distanciar, aproxima as pessoas ao
garantir acesso educao de qualidade, e promover o fortalecimento da
formao de jovens moradores de regies distantes, geograficamente ou
economicamente, dos grandes centros.
O e-Tec Brasil leva os cursos tcnicos a locais distantes das instituies de ensino e para a periferia das grandes cidades, incentivando os jovens a concluir
o ensino mdio. Os cursos so ofertados pelas instituies pblicas de ensino
e o atendimento ao estudante realizado em escolas-polo integrantes das
redes pblicas municipais e estaduais.
O Ministrio da Educao, as instituies pblicas de ensino tcnico, seus
servidores tcnicos e professores acreditam que uma educao profissional
qualificada integradora do ensino mdio e educao tcnica, capaz de
promover o cidado com capacidades para produzir, mas tambm com autonomia diante das diferentes dimenses da realidade: cultural, social, familiar,
esportiva, poltica e tica.
Ns acreditamos em voc!
Desejamos sucesso na sua formao profissional!
Ministrio da Educao
Janeiro de 2010
Nosso contato
etecbrasil@mec.gov.br
e-Tec Brasil
Indicao de cones
Os cones so elementos grficos utilizados para ampliar as formas de
linguagem e facilitar a organizao e a leitura hipertextual.
Ateno: indica pontos de maior relevncia no texto.
Saiba mais: oferece novas informaes que enriquecem o

assunto ou curiosidades e notcias recentes relacionadas ao
tema estudado.
Glossrio: indica a definio de um termo, palavra ou expresso
utilizada no texto.
Mdias integradas: sempre que se desejar que os estudantes
desenvolvam atividades empregando diferentes mdias: vdeos,
filmes, jornais, ambiente AVEA e outras.
Atividades de aprendizagem: apresenta atividades em
diferentes nveis de aprendizagem para que o estudante possa
realiz-las e conferir o seu domnio do tema estudado.
e-Tec Brasil
Sumrio
Palavra do professor-autor
Apresentao da disciplina
11
Projeto instrucional
13
Aula 1 Elementos da Teoria

Geral dos Sistemas
1.1 Histrico da Teoria Geral dos Sistemas
17
17
Aula 2 O processo de desenvolvimento de software

2.1 O desenvolvimento de software
23
23
2.2 Unified Modelling Language (UML)
25
2.3 Modelos de desenvolvimento de software
25
Aula 3 Os requisitos do sistema

3.1 Fases de concepo
33
33
3.2 Requisitos do sistema
34
3.3 Casos de uso
41
Aula 4 Descrio do comportamento do sistema

4.1 Introduo
51
51
4.2 Diagrama de sequncia

do sistema (DSS)
51
4.3 Construo do diagrama de sequncia do sistema
52
4.4 Objetivos do DSS
53
Aula 5 Criao de um modelo do sistema

5.1 Introduo
57
57
5.2 Modelo de domnio
57
5.3 Conceitos
58
5.4 Identificao de conceitos
59
5.5 Atributo
59
5.6 Identificao de atributos
59
5.7 Associaes
60
e-Tec Brasil
5.8 A UML e a representao do modelo de domnio
61
5.9 Representao de conceitos e atributos
61
5.10 Representao de associaes
62
5.11 O modelo conceitual
63
Aula 6 Arquitetura do sistema

6.1 Introduo
69
69
6.2 Definies de arquitetura de software
69
6.3 Diviso de um sistema em camadas
70
6.4 Representao da arquitetura de software na UML
71
6.5 Tipos de arquiteturas de sistemas

de informao mais comuns
72
6.6 Service oriented architecture (SOA) - Arquitetura

orientada a servios
75
Aula 7 Diagrama de classes

7.1 Introduo
7.2 Representao dos elementos do diagrama de classes
77
7.3 Mapeamento objeto-relacional
83
Aula 8 Projeto de objetos

8.1 Introduo
e-Tec Brasil
77
77
87
87
8.2 Responsabilidade e colaborao
87
8.3 Definio de padro
88
8.4 Os padres GRASP
88
Referncias
102
Currculo dos professores-autores
103
Nome da disciplina
Palavra do professor-autor
Prezado estudante!
Neste curso voc vai aprimorar seus conhecimentos sobre o desenvolvimento de software.
Vamos estudar com mais profundidade os aspectos das fases de anlise e
projeto de sistemas.
O que vamos estudar nesta disciplina , resumidamente, como transformar
os sistemas reais em solues computacionais que promovam a eficcia dos
negcios das organizaes. Essa tarefa que torna um sistema melhor do
que outro do ponto de vista do desempenho e da sua expanso e atualizao.
Nosso contedo pode ser considerado uma verdadeira carga de experincia
profissional que ajudar o tcnico em Informtica a entender todas as especificaes propostas pelos analistas e/ou a criar seus prprios sistemas.
Vamos examinar algumas questes prticas de projeto de software que serviro como regras que voc poder aplicar em seus futuros projetos.
Aproveite e faa todos os exerccios e participe das discusses nos fruns.
Bom estudo!
Prof. Luiz Egidio Costa Cunha
e-Tec Brasil
Apresentao da disciplina
Nossa disciplina estuda tcnicas para o projeto e o desenvolvimento de sistemas e est dividida em duas partes: Anlise e Projeto, que, atualmente, so
tratados de forma conjunta pelos profissionais da rea.
Em Anlise aprenderemos como planejar o software que pretendemos construir ou programar, a fim de que nossos usurios tenham suas necessidades
atendidas. Aprenderemos como usar diagramas e smbolos para mostrar o
que estamos imaginando de uma forma conceitual, sem muita preocupao
com a aderncia de nossas ideias realidade computacional que enfrentaremos na hora do desenvolvimento dos programas e sistemas.
Em Projeto estudaremos exatamente o elo que faltava entre a fase de Anlise
e a decodificao dos programas. Conheceremos tcnicas que nos ajudaro
a entender como possvel transformar nossos conceitos (diagramas, mtodos, objetos, etc.) em segmentos de software que, efetivamente, rodam
nos computadores.
Para isso estudaremos algumas ferramentas como a UML e seus diagramas,
e depois os padres de construo de classes que so teis na maioria dos
projetos de software. Esse conjunto de tcnicas e padres, quando adotado
no desenvolvimento dos sistemas, oferece ao projeto final caractersticas de
responsabilidades e portabilidade que so fundamentais para seu sucesso.
A bibliografia adotada exatamente a mesma usada por profissionais que
atuam no mercado de trabalho. Estudaremos Larman (2007) e o livro do grupo dos quatro, que dos autores: Gamma, Helm, Johnson e Vlissides (2000).
importante a participao ativa de todos nas atividades propostas em nossa disciplina, para que os exerccios discutidos possam servir de base para a
prtica profissional que todos tero quando conclurem o curso.
Siga em frente!
Prof. Luiz Egidio Costa Cunha
11
e-Tec Brasil
Projeto instrucional
Disciplina: Anlise de Sistemas (carga horria: 60 h).
Ementa: Teoria geral dos Sistemas. Modelagem de dados. Metodologias para
o desenvolvimento de sistemas. Ferramentas para anlise e projeto de sistemas.
AULA
OBJETIVOS DE
APRENDIZAGEM
Conhecer os principais conceitos da TGS.
1. Elementos da
Teoria Geral dos
Sistemas
Relacionar os conceitos da TGS com a

Computao.
MATERIAIS
CARGA
HORRIA
(horas)
Caderno e Ambiente Virtual de

Ensino-Aprendizagem.
http://pt.wikipedia.org/wiki/
Teoria_geral_de_sistemas

http://www.devmedia.com.br/
post-1903-Metodologia-de-desenvolvimento-de-Software.
html
Conhecer o histrico do processo de

desenvolvimento de software.
2. O processo de
desenvolvimento
de software
Conhecer os paradigmas de desenvolvimento de software mais utilizados.

Diferenciar as metodologias mais
comuns.
Conhecer o estado da arte em metodologias de desenvolvimento de software.
http://www.andreygomes.com/
index.php?option=com_conten
t&view=article&id=1:metodolo
gias-de-desenvolvimento-de-so
ftware&catid=1:metodologias
&Itemid=2
http://www.dsc.ufcg.edu.
br/~jacques/cursos/map/html/
intro/processo.htm
Modelos_ciclo_de_vida
Scrum
Extreme_programming
RUP
continua
13
e-Tec Brasil
AULA
OBJETIVOS DE
APRENDIZAGEM
MATERIAIS
CARGA
HORRIA
(horas)
Conhecer o que so os requisitos de um

sistema.
Conhecer tcnicas de elicitao de
requisitos.
3. Os requisitos do
sistema
Conhecer os elementos do Diagrama de

Caso de Uso.
Usar o Diagrama de Caso de Uso para
especificao das principais funes do
sistema.

Engenharia_de_requisitos
10
http://www.youtube.com/
watch?v=t0so6Nagjns

Conhecer os elementos dos diagramas
de interao.
4. Descrio do
comportamento do
sistema
Usar os diagramas de interao da UML

para especificao do comportamento
do sistema.
http://www.macoratti.net/
vb_uml2.htm
10
uml/diagramas/interacao/sequencia.htm
5. Criao de um
modelo do sistema
Usar o Modelo de Domnio para delinear

o escopo do sistema a ser desenvolvido.
br/~jacques/cursos/apoo/html/
anal1/anal1.htm
net_uml2.htm
Conhecer as principais arquiteturas

possveis para um sistema.
6. Arquitetura do
sistema
Escolher entre as arquiteturas a melhor

a ser implementada durante a fase de
projeto de um sistema.

http://pt.wikipedia.org/wiki/N_
camadas
arqu/camadas.html
Conhecer os elementos do Diagrama de

Classes.
7. Diagrama de
classes
Usar o Diagrama de Classes para a

modelagem dos dados de um sistema.
vb_uml2.htm
10
uml/diagramas/classes/classes1.htm
continua
e-Tec Brasil
14
AULA
OBJETIVOS DE
APRENDIZAGEM
MATERIAIS
CARGA
HORRIA
(horas)

Conhecer os padres de projeto GRASP.

8. Projeto de
objetos
Entender a aplicao dos padres de

acordo com as questes de programao
existentes nos sistemas.
Padr%C3%A3o_de_projeto_de_software
vb_pd1.htm
10
http://codeigniterbrasil.com/
passos-iniciais/padroes-de-projeto-ou-design-patterns-o-que-sao-para-que-servem-e-qual-sua-implicacao-de-uso/
concluso
15
e-Tec Brasil
Aula 1 Elementos da Teoria

Geral dos Sistemas
Objetivos
Conhecer os principais conceitos da TGS.
Relacionar os conceitos da TGS com a Computao.
1.1 Histrico da Teoria Geral dos Sistemas

A Teoria Geral dos Sistemas (TGS) foi concebida em 1937 por Ludwig von
Bertalanfy (2008). Ele era um bilogo que procurava entender o comportamento dos animais em suas sociedades e quais as regras os regiam para que
mantivessem suas caractersticas como grupo. Bertalanfy, considerado o fundador da TGS, aps divulgar seus estudos ao longo dos anos de 1945 a 1956,
finalmente escreveu seu livro, intitulado: General System Theory, em 1968.
Martinelli e Ventura (2006) perceberam que a cincia moderna estava cada
vez mais fragmentada em mltiplos compartimentos e especializaes oriundas do prprio desenvolvimento cientfico e de sua crescente complexidade.
Perceberam, tambm, por outro lado, que havia certa semelhana entre os
princpios de diversas cincias, sendo assim possvel haver um elo entre esses
conhecimentos espalhados nas mais diversas reas de conhecimento.
Outro autor importante nos estudos da TGS foi Kenneth Boulding. Economista e estudioso dos sistemas, Kenneth escreveu um artigo que descrevia
a natureza geral da teoria dos sistemas, seu objetivo e importncia para o
estudo dos fenmenos (MARTINELLI; VENTURA, 2006, p. 9).
At os dias atuais a TGS estudada por diversos profissionais como administradores, economistas, bilogos, engenheiros e analistas de sistemas. Apesar dessa
teoria ter sido proposta, para alcanar todos os sistemas existentes (sistemas
humanos, fsicos, csmicos, computacionais, organizacionais, etc.), a rea de
conhecimento que mais tem explorado os conceitos da TGS a Computao.
Aula 1 Elementos da Teoria Geral dos Sistemas
17
e-Tec Brasil
1.1.1 Conceitos de sistema

O conceito de sistema evoluiu desde que foi proposto na TGS. Vrios autores
contriburam para que o entendimento do que um sistema pudesse ficar claro para todos. Um dos conceitos que possui grande aceitao e aplicao para
a nossa rea de Computao definido por Peter Schoderbek (SCHODERBEK
et al., 1990 apud MARTINELLI; VENTURA, 2006, p. 6), segundo o qual:
a) os objetos so os elementos que compem o sistema; os relacionamentos so as fronteiras que ligam os objetos;
sistema
o conjunto de objetos, com
relaes entre os objetos e os
atributos relacionados com cada
um deles e com o ambiente, de
maneira a formar um todo.
(MARTINELLI; VENTURA, 2006,
p. 6).
b) os atributos so as caractersticas tanto dos objetos como dos relacionamentos; o ambiente o que est fora do sistema, ou seja, no participa
do sistema, porm, ele est inserido nesse espao delimitado ou no.
A Figura 1.1 mostra graficamente o conceito apresentado.
Perturbaes
Assista ao vdeo intitulado
Teoria Geral dos Sistemas,
em http://www.youtube.com/
watch?v=d_c8xvHtdHo para
melhorar seus conhecimentos
sobre a TGS. Em seguida, cite
dois exemplos de sistemas
abertos, de acordo com o que foi
apresentado no vdeo. Mande
para seu tutor esses exemplos e,
para cada um deles, escreva uma
breve justificativa de sua escolha.
Ambiente
Sistema
(Transformao)
Entrada
Sada
Perturbaes
Figura 1.1: Diagrama de sistemas
Fonte: Elaborada pelo autor
1.1.2 Abordagem sistmica e abordagem analtica

Um sistema pode ser abordado de duas formas clssicas: analtica ou sistemicamente. Ambas as abordagens so muito usuais dependendo do que se
quer ao estudar um determinado sistema.
Antes de aprendermos o que so essas abordagens, importante entendermos a definio da complexidade de um sistema.
complexidade
Pode ser compreendida como o
nmero de elementos que fazem
parte do sistema, seus atributos,
suas interaes e o seu grau
de organizao. (MARTINELLI;
VENTURA, 2006, p. 4).
e-Tec Brasil
Dessa forma, podemos entender que um sistema complexo aquele que

possui vrios elementos com vrios atributos e interaes entre eles. Podemos concluir ainda que quanto maior o nmero de elementos de um sistema, maior ser sua complexidade.
18
Anlise de Sistemas
No podemos confundir complexidade de um sistema com dificuldade

de se entender ou de se explicar um sistema. A complexidade est associada
com a quantidade de partes e suas relaes, e no com o desconhecimento
ou o no entendimento de como essas partes so compostas, ou como elas
interagem entre si.
Agora que j sabemos o que so sistemas complexos, podemos estudar o
que so as abordagens sistmicas e analticas.
A abordagem sistmica aquela na qual se olha para o sistema de uma
forma geral e abrangente. Nela no se observam partes ou as relaes entre
algumas partes especficas. Tanto o olhar quanto a descrio de sistemas de
uma forma sistmica se do pela de viso de todo. Procura-se identificar as
bordas do sistema e o que est dentro e fora dessa borda (limite do sistema).
A abordagem analtica, por sua vez, preocupa-se com o detalhamento das
partes que compem um sistema. Nessa abordagem o olhar se volta para
cada parte e cada relacionamento presentes no interior do sistema. As partes
e seus relacionamentos ficam expostos ao observador que consegue defini-los
e estud-los durante o processo de anlise do sistema.
Tanto a abordagem sistmica quanto a analtica so importantes no processo
de estudo ou de anlise de um sistema. Normalmente, num primeiro contato
com um sistema (fase de conhecimento), adota-se a abordagem sistmica
para que se tenha um conhecimento claro do que o sistema e quais suas
relaes com o ambiente no qual ele est inserido. Nos contatos seguintes,
adota-se uma abordagem mais analtica para que se conheam com facilidade todas as partes que tem o sistema e como essas partes interagem entre si.
O Quadro 1.1 apresenta uma comparao entre as duas formas de abordagens.
Quadro 1.1: Comparao entre abordagem analtica e sistmica
ASPECTOS
ABORDAGEM ANALTICA
ABORDAGEM SISTMICA
nfase
Nas partes
No todo
Tipo
Relativamente fechado
Relativamente aberto
Ambiente
No definido
Um ou mais
Hierarquia
Poucas
Possivelmente muitas
Estado
Estvel
Fonte: Schoderbek apud Martinelli e Ventura (2006)
Adaptativo, busca novo equilbrio
19
e-Tec Brasil
1.1.3 Consideraes bsicas sobre sistemas

A abordagem sistmica, estudada na seo anterior, nos leva a considerar
que importante conhecermos algumas caractersticas dos sistemas. Essas
caractersticas nos ajudam a compreender melhor o tipo de sistema que estamos estudando. No caso da Anlise e Projeto de Sistemas, precisamos conhecer bem cada sistema no qual trabalhamos para que fique fcil criarmos
solues computacionais para eles. Muitas vezes os problemas informados
por nossos usurios ficam mais bem entendidos pelos programadores quando conseguimos identificar essas caractersticas:
a) o objetivo central do sistema e as respectivas medidas de rendimento;
b) o ambiente do sistema;
c) os recursos do sistema;
d) a administrao do sistema.
Os objetivos significam aquilo que deve ser alcanado pelo sistema, ou seja,
o motivo pelo qual um sistema existe e as medidas de rendimento indicam
o quanto ele est (ou no) alcanando seus objetivos. Esse rendimento pode
ser medido de vrias maneiras, por exemplo, em um sistema de controle de
estoque que tenha como objetivo principal no deixar faltar produtos em um
almoxarifado, a quantidade de produtos que no ficaram faltando nas prateleiras pode ser considerada uma medida de rendimento. Em outras palavras,
se faltar produtos nas prateleiras por erro nos relatrios do sistema, pode-se
concluir que o programa no atendeu a seu objetivo, que era garantir sempre a disponibilidade de produtos.
O ambiente do sistema est associado com aquilo que est ao redor dele,
ou seja, com todos os outros sistemas ou coisas que se encontram externamente prximos dele.
Os objetivos precisam de recursos que sejam executados. No caso da Informtica, os principais recursos que garantem o alcance dos objetivos so
aqueles associados com a Computao, por exemplo: recursos de hardware
(processador, memria, clock, etc.), recursos de software (sistema operacional, banco de dados, compiladores, etc.), recursos humanos (analistas,
programadores, tcnicos, etc.), entre outros que podem ser associados aos
sistemas de informao.
e-Tec Brasil
20
Anlise de Sistemas
A caracterstica administrao do sistema preocupa-se com as funes de

planejamento e de controle associadas ao sistema. Sem um correto planejamento que contemple todas as etapas de desenvolvimento de um sistema
no possvel um trabalho de programao de solues que atendam os
nossos usurios. importante, tambm, que os administradores acompanhem o trabalho com os sistemas dando retorno aos interessados sobre todos os passos executados e aqueles que ainda no foram completados para
a finalizao do trabalho.
Resumo
Chegamos ao final de nossa primeira aula e vimos que quanto mais conhecemos as caractersticas dos sistemas, mais fcil ser prepararmos uma soluo
computacional que o crie ou o preserve. A TGS tambm utilizada por outras
reas de conhecimento, mas cada vez mais a rea de Informtica tem sido
beneficiada com os conceitos propostos por Ludwig Von Bertalanfy. Quando
conhecemos bem esses conceitos antes de comearmos a projetar nossos
sistemas e, consequentemente, aplicar esses conceitos, garantimos o sucesso
de nossos programas, pois eles sero regidos pelos mesmos conceitos. Alm
das questes ligadas Informtica, a TGS tambm nos ajuda nas questes
sociais ligadas aos nossos sistemas, ou seja, podemos usar os mesmos conceitos para os grupos de usurios que trabalham ligados ao nosso software.
Podemos conhecer melhor

a relao entre os sistemas
de informao e a TGS no
vdeo intitulado Teoria Geral
dos Sistemas e Tipologia dos
Sistemas de Informao,
disponvel em http://
standishgroup.com/newsroom/
chaos_manifesto_2011.php.
Cite dois exemplos de sistemas
de informao que tenham uma
relao importante entre eles.
Escreva um pequeno texto com
os nomes desses sistemas e qual
a relao existente entre eles.
Envie seu texto para seu tutor a
distncia.
Atividades de aprendizagem
1. Considere o sistema Corpo Humano. Explique qual o objetivo geral desse
sistema e cite uma medida de rendimento que pode ser aplicada a ele.
2. Descreva o sistema Famlia de acordo com uma abordagem sistmica
utilizando um texto de, no mximo, trs linhas.
3. Descreva o mesmo sistema da questo anterior, porm, agora, na abordagem analtica. Seu texto deve conter no mnimo dez linhas.
4. Usando a Figura 1.1 e o exemplo abaixo como referncias, desenhe os
sistemas propostos nos seguintes itens:
21
e-Tec Brasil
Exemplo:
Partida
Trigo + Sal + leo
Po
a) sistema de Matrcula de Estudantes;

b) sistema de Ar Refrigerado;
c) sistema de Fbrica de Sucos.
Registre suas respostas num arquivo e poste-o no AVEA.
e-Tec Brasil
22
Anlise de Sistemas

Objetivos
Conhecer o histrico do processo de desenvolvimento de software.
Conhecer os paradigmas de desenvolvimento de software mais
utilizados.
Diferenciar as metodologias mais comuns.
Conhecer o estado da arte com metodologias de desenvolvimento
de software.
2.1 O desenvolvimento de software

Os principais motivos que levam as organizaes a desenvolverem sistemas so: o
aumento da qualidade dos produtos e servios, atravs da automatizao das rotinas; a reduo de custos; o aumento da vantagem competitiva sobre os concorrentes; o aumento do nvel de servio, do desempenho dos recursos humanos;
a melhoria do processo de tomada de decises pela administrao da empresa.
Em nossa disciplina estudaremos um mtodo para desenvolver sistemas.
Muitas vezes queremos programar diretamente nossos sistemas em vez de
projet-los anteriormente. Porm, essa no uma boa prtica.
Estudos feitos nos EUA para se medir a produtividade no desenvolvimento
de sistemas (STANDISH GROUP, 2011) revelaram que:
a) 30% a 40% dos projetos so cancelados;
b) 50% dos projetos custam mais que o dobro do custo inicialmente
projetado;
c) 15 a 20% dos projetos terminam dentro do prazo e dentro do oramento.
23
Uma importante empresa que

faz estudos de produtividade
de desenvolvimento de
software chama-se Standish
Group. Veja em http://
standishgroup.com/newsroom/
chaos_manifesto_2011.php
um resumo do Chaos Manifesto
2011. Escreva um pequeno
texto informando a respeito do
manifesto (documento) e envie
para seu tutor a distncia.
e-Tec Brasil
Os principais problemas encontrados foram:

a) falta de qualidade do produto final;
b) no cumprimento dos prazos;
c) no cumprimento dos custos.
Processo
um conjunto de atividades bem
definidas, que so executadas
em uma determinada ordem.
A partir desses resultados surgiram estudos de processos e tcnicas para

melhoraria da qualidade e confiabilidade dos produtos, e tambm a produtividade dos desenvolvedores.
Entre os resultados temos:
a) linguagens de programao mais produtivas;
b) metodologias de desenvolvimento de software;
c) ferramentas computacionais para o desenvolvimento e gerenciamento
de projetos de software.
Processo de
desenvolvimento de
Software
um conjunto de atividades
(prticas e tcnicas) rigorosas,
sistemticas e controlveis que
permitem construir sistemas
informatizados em um prazo
e oramento finitos.em uma
determinada ordem.
Dessa forma a melhor maneira de se aumentar a qualidade do software

definindo um processo eficaz de desenvolvimento que contemple todas
as fases necessrias para sua produo.
Outros requisitos importantes devem ser atendidos:
a) flexibilidade: os sistemas devem ser facilmente alterveis para garantir
a sua evoluo;
b) confiabilidade: o nmero de defeitos deve ser o menor possvel;
c) desempenho: o sistema deve ter um desempenho razovel;
d) facilidade de uso: o sistema deve ser de fcil utilizao.
Todo o processo de desenvolvimento de software definido em um conjunto de
disciplinas chamado Engenharia de Software que o IEEE (http://www.ieee.org)
define como: aplicao de um processo sistemtico, disciplinado e quantificado
ao desenvolvimento, operao e manuteno de software.
e-Tec Brasil
24
Anlise de Sistemas
2.2 Unified Modelling Language (UML)

O primeiro passo para a construo de um software analisar o problema a
ser resolvido, entender o sistema que ele representa e, em seguida, criar um
modelo que represente sua soluo. Para a criao desse modelo utilizaremos uma notao ou linguagem de modelagem chamada UML.
2.3 Modelos de desenvolvimento de software

Antes de prosseguirmos em nosso estudo, importante diferenciarmos linguagem de modelagem de metodologia de desenvolvimento de sistemas. Enquanto uma metodologia define rigidamente todos os passos para
a construo do software, desde a anlise do problema at a entrega final
do sistema, fazendo uso de regras e procedimentos para a execuo de cada
etapa, a linguagem de modelagem preocupa-se apenas com a definio de
elementos que simbolizem o sistema a ser criado. Dessa forma, a linguagem
de modelagem apresenta graficamente um modelo que representa o sistema em questo, sem a preocupao de definio de passos formais para se
chegar a esse modelo. importante ressaltar que uma mesma linguagem
de modelagem pode ser usada por vrias metodologias de desenvolvimento
de sistemas; basta que os criadores dessas metodologias a escolham para
modelar os elementos de seus sistemas.
Isso muito importante, pois:
UML ou Unified Modelling

Language
uma Linguagem de Modelagem Unificada: linguagem
grfica que descreve os
principais elementos de sistemas
de software. A esses elementos
damos o nome de artefatos.
Para conhecer melhor a origem

da UML, visite o site: http://
www.omg.org.
Assista a uma introduo UML

que ajuda a reforar os conceitos
estudados nesta seo no vdeo
intitulado Introduo UML 1 Parte, disponvel em http://
www.youtube.com/watch?v=hf
N6n5fJfLc&feature=related.
Em seguida, escreva um pequeno
texto sobre os pontos abordados
no vdeo que mais chamaram
sua ateno sobre a UML e envie
para seu tutor a distncia.
a) uma metodologia que funciona para a empresa X pode no funcionar

para a empresa Y;
b) os nveis de qualidade podem variar para cada tipo de projeto, o que se
reflete na metodologia;
c) a documentao pode variar para cada tipo de projeto, o que tambm se
reflete na metodologia.
Alm da UML, outras linguagens de modelagem so utilizadas pelos desenvolvedores de software, entre elas, podemos citar a Modelica, e a Java
Modelling Language (JML). Porm, cada vez mais a UML se firma como a
linguagem mais utilizada pelos analistas de sistemas. A UML simplesmente
uma linguagem, isto , uma notao. Ela no diz como desenvolver software
e sim como criar um modelo desse software.
25
e-Tec Brasil
Podemos dizer, ento, que a UML uma linguagem de modelagem e no

uma metodologia de desenvolvimento! Conhecer a notao UML no significa utilizar uma metodologia X ou Y. Espera-se que a UML possa ser utilizada independentemente da metodologia de desenvolvimento de sistema!
Independentemente da linguagem de modelagem utilizada para desenvolver um
sistema, as metodologias normalmente obedecem a um dos modelos a seguir:
d) modelo em cascata
O modelo em cascata era o mais utilizado at a dcada de 1980. Nesse
modelo cada etapa deve ser completada para que a seguinte possa ser realizada. Esse processo, mostrado da Figura 2.1, simples e fcil de gerenciar e
consiste em dividir a tarefa em tarefas menores e autocontidas.
Figura 2.1: Modelo em cascata

Fonte: Serafini e Cunha (2010, p. 15)
Quando esse modelo foi proposto, no incio do desenvolvimento dos sistemas, acreditava-se que ao se encerrar uma etapa do modelo, todas as informaes necessrias sobre aquela fase j estavam capturadas. Por exemplo:
aps a entrevista com o usurio sobre as necessidades de seus sistemas,
tudo que se precisaria saber para resolver seu problema j estava dito. Assim,
os desenvolvedores poderiam se concentrar na fase seguinte Anlise
para darem continuidade ao processo de construo do software. O mesmo
acontecia com as etapas seguintes. Ao longo do tempo, verificou-se que,
muitas vezes, coisas importantes sobre etapas anteriores so descobertas
apenas no final do processo de desenvolvimento.
e-Tec Brasil
26
Anlise de Sistemas
Os principais problemas desse modelo so:

a) os sistemas devem ser totalmente entendidos e analisados, antes que
possam ser projetados e implementados. medida que a complexidade
aumenta, mais difcil se torna o seu desenvolvimento e gerenciamento;
b) os riscos so protelados para as etapas finais. Os problemas s aparecem
nas etapas finais do projeto e o custo para correo muito alto;
c) em grandes projetos, cada etapa consome grande quantidade de tempo
e recursos.
Como a fase de anlise feita somente no incio do projeto, o risco de no se
compreenderem os requisitos do cliente bastante alto. Mesmo seguindo um
procedimento rgido de captura de requisitos, as chances de mudanas so altas
medida que o desenvolvedor conhece cada vez mais o sistema e seus requisitos. Para projetos pequenos, o modelo em cascata pode funcionar muito bem.
importante lembrar que consideramos projetos pequenos aqueles que possuem pouca complexidade e poucos artefatos. Dessa forma, o uso do modelo
em cascata no compromete a construo do sistema por no deixar de contemplar tudo o que necessrio em cada uma de suas etapas, j que so simples.
a) modelo espiral
Nesse modelo o problema relatado pelo cliente abordado em ciclos. Um ciclo
completo chamado de ciclo de vida e compreende as etapas de anlise,
projeto, implementao e testes.
Ao final de cada ciclo, temos a liberao de uma verso aprimorada do software,
ou seja, uma verso mais completa (e mais correta) do software que o cliente
necessita para resolver seu problema.
Esse modelo de desenvolvimento (Figura 2.2) muito vantajoso, pois o grupo de desenvolvimento ser capaz de trabalhar em todo um ciclo de vida
do projeto (anlise, projeto, implementao e testes) e o cliente vai fornecer
feedback bem cedo para a equipe de desenvolvimento, tornando a deteco de problemas mais fcil e rpida.
27
e-Tec Brasil
Figura 2.2: Modelo espiral

Outra vantagem importante que qualquer mudana no sistema pode ser

incorporada ao ciclo seguinte.
Mas esse modelo no tem somente vantagens, ele tambm apresenta algumas desvantagens, que podemos citar:
a) o processo mais difcil de gerenciar. O modelo espiral no se encaixa
bem com as ferramentas de gerncia de projetos tradicionais, tais como
grfico de Gantt, PERT, etc.;
b) pode ocorrer precipitao e entrega de cdigo, sem que seja feita anlise
completa do alcance dos seus objetivos.
Normalmente o cliente fica satisfeito ao ver que as verses que so geradas
de seu software esto ficando conforme sua expectativa. Isso mostra para os
desenvolvedores que esto no caminho certo do desenvolvimento do sistema.
c) modelo iterativo e incremental
Esse modelo um aprimoramento do modelo espiral e incorpora mais formalismos e rigor.
O modelo dividido em quatro fases:
e-Tec Brasil
28
Anlise de Sistemas
a) concepo;
b) elaborao;
c) construo;
d) transio.
Essas fases so realizadas em sequncia e no devem ser confundidas com
as etapas do modelo em cascata.
Vamos estudar cada uma dessas fases.
a) Concepo
Nessa fase estabelecemos o escopo do projeto e definimos uma viso geral
dele. Em pequenos projetos, ela pode ser realizada durante um cafezinho
com o cliente!
Nessa fase devemos:
construir um documento, descrevendo a viso geral do sistema;
fazer uma explorao inicial dos requisitos do cliente;
construir um glossrio inicial dos termos utilizados pelo cliente;
fazer uma anlise do negcio (viabilidade, previso de investimentos, etc.);
fazer uma anlise de risco preliminar;
traar um plano de projeto preliminar.
b) Elaborao
Nessa fase analisamos o problema, acrescentamos mais detalhes ao plano de
projeto preliminar e procuramos eliminar ou minimizar os riscos do projeto.
No final da fase de elaborao teremos uma viso geral e um melhor entendimento do problema, devido ao seu detalhamento.
Na UML temos dois modelos que ajudam nesse estgio:
Modelo de caso de uso: que ajuda a entender e capturar os requisitos
do cliente;
29
e-Tec Brasil
Modelo conceitual (diagrama de classes): que mostra os principais conceitos do sistema, os quais o cliente entende.
c) Construo
Nessa fase ocorre a construo de fato do software. Essa fase do projeto no
executada de modo linear, mas na forma do modelo espiral, fazendo uma
srie de iteraes. Em cada uma dessas iteraes utilizamos o modelo em
cascata. Tornando cada iterao mais curta possvel, evitamos os problemas
do modelo em cascata (Figura 2.3).
Concepo
Interao 2
Elaborao
Construo
Transio
Anlise
Projeto
Interao 1
Implementao
Anlise
Teste
Projeto
Utilizao
Implementao
Interao n
Teste
Anlise
Utilizao
Projeto
Implementao
Teste
Utilizao
Figura 2.3: Etapas do processo iterativo

Ao trmino de cada iterao temos o sistema um pouco mais desenvolvido.

Aps um conjunto de iteraes, podemos ter a liberao de uma nova verso preliminar (pr-alfa, alfa, beta, etc.) do software.
e-Tec Brasil
30
Anlise de Sistemas
d) Transio
A fase final est relacionada colocao do produto final para o cliente.
As atividades tpicas dessa fase so:
liberao de verses Beta para alguns usurios da comunidade;
teste de validao ou execuo paralela;
converso de dados de sistemas antigos;
treinamento de usurios;
publicidade, distribuio e vendas.
A verso Beta a verso de um produto que ainda se encontra em fase de
desenvolvimento e testes. No entanto, esses produtos muitas vezes so popularizados bem antes de sair a verso final.
A fase de transio no deve ser confundida com a fase de teste tradicional.
No incio da fase de transio deve existir um produto completo, testado e
operacional para os usurios (os clientes).
Resumo
Encerramos assim nossa segunda aula e vimos que muita informao nova
foi aprendida. Esse conhecimento necessrio para que continuemos nosso
estudo sobre a anlise e o projeto de sistemas que atendam, cada vez mais,
s necessidades de nossos clientes.
Vale lembrar que, apesar dos problemas naturais para se desenvolver sistemas, muito importante que sempre trabalhemos na construo de nosso
software usando ferramentas adequadas. As metodologias e as linguagens
de modelagem so fundamentais para esse trabalho. Vimos que a UML
a mais importante linguagem de modelagem usada atualmente e pode ser
31
e-Tec Brasil
trabalhada dentro de vrias metodologias. Vimos ainda que as metodologias

podem adotar modelos que nos ajudam a alcanar mais qualidade em nossos
produtos. Os modelos mais utilizados so aqueles que priorizam a satisfao
final do cliente, como o Iterativo e Incremental.
Agora que j tivemos uma viso geral do processo de desenvolvimento de
software e conhecemos as etapas necessrias para sua construo vamos, na
prxima aula, aprender como trabalhar na primeira fase desse processo: o levantamento dos requisitos de um sistema. Essa fase comum a todas as metodologias e se aplica a qualquer modelo de desenvolvimento de sistemas.
1. Quais as principais diferenas entre linguagens de modelagem e metodologias de desenvolvimento de sistemas?
2. Cite duas desvantagens do modelo em cascata de desenvolvimento de
sistemas.
3. Cite dois exemplos de sistemas complexos que so mais bem desenvolvidos se usarmos o Modelo Iterativo e Incremental.
4. Quais problemas encontrados em projetos de software que causam insatisfao do usurio no momento da entrega do produto final.
5. Cite dois exemplos de metodologias geis de desenvolvimento de sistemas.
e-Tec Brasil
32
Anlise de Sistemas

Objetivos
Conhecer o que so os requisitos de um sistema.
Conhecer tcnicas de elicitao de requisitos.
Usar o Diagrama de Caso de Uso para especificao das principais
funes do sistema.
3.1 Fases de concepo

O incio da construo de um sistema acontece na sua fase de concepo.
Algumas etapas da fase de concepo so:
a) definir uma viso para o produto, ou seja, os objetivos atuais e futuros
que os usurios pretendem alcanar com o seu uso;
b) produzir um plano de negcio para o desenvolvimento, produo, implantao e teste do software;
Fase de concepo
a etapa do projeto de um
software em que um sistema
concebido. Nessa fase, aps as
necessidades dos usurios j
terem sido levantadas, projeta-se
o produto (software) com um
escopo definido e se estuda
um plano de negcio para seu
desenvolvimento e implantao.
c) definir do escopo do projeto; ou seja, seus limites de interface com os

demais sistemas existentes na empresa;
d) estimar o custo total aproximado do projeto para que os usurios se capitalizem e se planejem para o projeto.
O tamanho dessa fase depende do tipo de projeto. Por exemplo: um projeto de comrcio eletrnico (E-commerce) que pretende atingir o mercado
rapidamente e as atividades desenvolvidas durante a concepo podem se
reduzir a uma definio da viso geral, criando um plano de negcio para
obter financiamento. Quando se trata de um projeto de defesa antiarea,
certamente a fase vai requer muito mais trabalho, ou seja, uma anlise de
requisitos mais elaborada, definies de projeto, estudos preliminares, etc.
33
e-Tec Brasil
importante na fase de concepo termos certeza se o projeto vivel,

do ponto de vista financeiro e computacional, e se ele trar algum benefcio
para a empresa. Caso no consigamos estar certos dessas questes, aconselhvel que o projeto seja repensado.
3.2 Requisitos do sistema

Para desenvolver um sistema, precisamos descobrir o que o nosso cliente deseja.
Requisitos
So as capacidades e condies
a que o sistema deve atender.
Nosso objetivo escrever o documento de requisitos de sistemas, que deve

conter de forma precisa e realista tudo o que deve ser feito, de modo a atender a uma ou mais necessidades do nosso cliente.
Esse documento tambm deve ser validado pelo cliente, isto , o cliente deve
ler o documento e verificar se todas as suas necessidades esto atendidas.
Para encontrar os requisitos do sistema, precisaremos conversar com nosso
cliente. Esse cliente no necessariamente uma nica pessoa e pode representar uma empresa com milhares de funcionrios!
Assim, muito til a criao de um grupo de modelagem, que deve ser
composto de:
a) investidor: (em ingls: Stakeholder): cliente/financiador do sistema;
b) usurios: aqueles que iro utilizar diretamente o sistema ou qualquer
pessoa que v ser afetada pelo sistema;
c) analistas ou desenvolvedores: ns!
d) facilitadores: pessoas que conhecem bem a empresa e possuem habilidade para fazer reunies; entendem o processo de modelagem dos
requisitos e podem fazer perguntas vlidas e inteligentes;
e) escribas: pessoas que devem escutar bem, possuir habilidade na comunicao oral e escrever bem. So eles que iro anotar os requisitos durante as reunies e ajudar na escrita do documento de requisitos.
Essa equipe tem a funo de levantar as necessidades do sistema solicitado
pelo cliente e que ser desenvolvido por ns. Cada elemento dessa equipe
deve desempenhar seu papel de forma a garantir que sua contribuio seja
efetivada para o perfeito conhecimento do que se deseja para o sistema
e-Tec Brasil
34
Anlise de Sistemas
pretendido. Os clientes so necessrios para a composio da equipe, por

serem eles os que melhor conhecem os requisitos do sistema a ser projetado.
Assim, eles possuem direitos e deveres que devem ser respeitados para que
o sucesso seja alcanado.
3.2.1 Direitos e deveres dos clientes

Os principais direitos dos clientes so:
a) receber do desenvolvedor as explicaes sobre o processo de desenvolvimento de sistemas; receber do desenvolvedor um sistema que atenda s
suas necessidades nos aspectos de funcionalidade e qualidade;
b) ouvir dos desenvolvedores todas as informaes tcnicas sem o uso de jarges da rea de Informtica, e sim numa linguagem simples e compreensvel.
Seus principais deveres em relao aos desenvolvedores so:
a) explicar o funcionamento da empresa onde o sistema ser implantado;
b) disponibilizar tempo para fornecer as informaes necessrias;
c) ser preciso e claro na descrio dos requisitos; ser capaz de priorizar
os requisitos;
d) ser capaz de tomar decises relativas ao sistema e suas funcionalidades;
e) realizar, juntamente com o desenvolvedor, revises dos requisitos.
3.2.2 Tcnicas de identificao de requisitos

Para obtermos os requisitos de um sistema, utilizamos duas tcnicas
muito conhecidas:
a) entrevistas;
b) brainstorming (em portugus: tempestade cerebral): tcnica em que
um grupo de pessoas discute um assunto e diz qualquer coisa relativa ao
assunto que lhe venha mente sem a preocupao da relevncia do que
foi dito para o assunto em questo.
Quanto mais estudamos essas tcnicas, mais requisitos conseguimos levantar sobre o sistema a ser desenvolvido.
35
e-Tec Brasil
Uma boa referncia para conhecermos melhor as tcnicas de entrevista e

brainstorming o livro de Francisco Filho (2008).
Algumas recomendaes so importantes para o sucesso dessas tcnicas:
Para realizar entrevistas:
a) fornea uma agenda;
b) esclarea aos participantes quais os motivos do projeto;
c) faa as perguntas crticas em primeiro lugar;
d) no assuma que voc tem conhecimento do assunto;
e) identifique o que necessrio e o que desejvel;
f) termine a entrevista com um sumrio dos pontos abordados.
Para realizar brainstorms:
a) todas as ideias so boas: as ideias no so julgadas pelo grupo;
b) todas as ideias so do grupo, ningum dono de uma ideia;
c) todas as ideias so pblicas, qualquer pessoa pode expandir ou modificar uma ideia;
d) sempre que surgir uma ideia, ela deve ser imediatamente escrita no
quadro-negro;
e) antes da sesso, fornea ao grupo uma cpia das regras de brainstorming.
3.2.3 O documento de requisitos

Este documento deve conter a especificao do sistema, ou seja, uma descrio das necessidades ou dos requisitos do sistema a ser desenvolvido.
Nele deve-se descrever:
a) uma viso geral do sistema;
b) quem so os clientes do sistema;
c) quais os objetivos;
d) quais as funes principais do sistema;
e-Tec Brasil
36
Anlise de Sistemas
e) quais os atributos necessrios do sistema.

A seguir, estudaremos os conceitos de funes e atributos do sistema.
a) Funes do sistema
As funes do sistema so o que se supe que o sistema faa e devem
ser identificadas, listadas e agrupadas logicamente.
Uma boa regra para verificar se uma expresso X , de fato, uma funo do
sistema, colocamos X na sentena O sistema deveria fazer X e essa sentena deve fazer sentido.
Exemplo: Num sistema de registro de notas escolares, poderemos duvidar
se elaborar prova uma funo do sistema. Colocamos ento as palavras
elaborar prova na frase grifada acima: O sistema de registro de notas escolares deveria fazer a elaborao das provas. Por experincia, sabemos que
as provas de uma escola so elaboradas pelos professores e no por sistemas
computacionais. Logo, elaborar prova no uma funo desse sistema.
Agrupamos as funes em trs categorias:
a) evidente: deve executar e o usurio deve saber que executada;
b) oculta: deve executar, mas no deve ser visvel para os usurios;
c) enfeite/decorao: opcional.
b) Atributos do sistema
Os atributos do sistema so qualidades no funcionais do sistema.
Em alguns projetos conveniente construir um documento exclusivo para
os atributos do sistema. Esse documento fica separado do documento que
contm as funcionalidades do sistema.
Exemplos de atributos do sistema:
a) facilidade de uso: que tipo de interface o sistema possui com o usurio?
b) tolerncia a falhas: qual a expectativa aceitvel para falhas no sistema?
c) tempo de resposta: qual o tempo aceitvel para a resposta do sistema?
37
e-Tec Brasil
3.2.4 Tipos de requisitos

Para melhor entendermos os requisitos, comum separ-los em grupos ou tipos.
Os tipos de requisitos so:
a) funcionalidade: descreve caractersticas, capacidades, segurana, etc.,
do sistema;
b) usabilidade: descreve caractersticas relativas a fatores humanos, ajuda
on-line, documentao;
c) confiabilidade: descreve necessidades do sistema quanto frequncia
de falhas, recuperabilidade, etc;
d) performance: descreve necessidades relativas a tempos de respostas,
preciso, disponibilidade, utilizao de recursos, etc;
e) suportabilidade: descreve necessidades relativas adaptabilidade, manutenibilidade, internacionalizao, configurabilidade, etc;
f) implementao: descreve limitaes de recursos, linguagens e ferramentas, hardware, etc.;
g) interface: descreve as restries impostas pelo interfaceamento com
sistemas externos;
h) operao: descreve as necessidades relativas administrao do sistema
em sua configurao operacional;
i) aspectos legais: descrevem licenciamento, etc.
3.2.5 Recomendaes para obteno dos requisitos

Nesta seo so apresentadas recomendaes teis para a obteno dos
requisitos dos sistemas.
a) Questes fundamentais
As seguintes questes podem ajudar a esclarecer os requisitos de um sistema:
1. Para quem esse sistema?
2. O que eles iro fazer com esse sistema?
3. Por que fazemos isso? Por que fazemos assim? Por que fazemos desse modo?
e-Tec Brasil
38
Anlise de Sistemas
4. Quais as necessidades de negcio esse sistema deve suportar?

5. O que nosso cliente demanda?
6. Como so as mudanas no negcio?
7. O que nossos competidores esto fazendo? Por qu? Como podemos
fazer melhor?
8. Precisamos fazer isso?
9. Se estivssemos iniciando o negcio, faramos dessa forma?
10. Se fomos bem-sucedidos fazendo dessa forma no passado, seremos
bem-sucedidos fazendo assim no futuro?
11. Poderemos combinar vrias funes?
12. Como o sistema vai afetar as funes dentro da empresa?
13. De que informaes as pessoas necessitam para executar o servio?
14. O trabalho est sendo executado onde ele faz mais sentido?
15. Existe alguma tarefa simples que pode ser automatizada?
16. As pessoas esto realizando somente atividades complexas que o sistema
no pode realizar?
17. O sistema vai se pagar?
18. O sistema suporta trabalho de grupo?
19. Os usurios possuem formao para lidar com o sistema?
20. Que treinamento necessrio?
21. Quais os objetivos e as metas estratgicas da organizao? O sistema
suporta essas metas?
39
e-Tec Brasil
22. Como podemos fazer mais rpido?

23. Como podemos fazer mais barato?
24. Como podemos fazer melhor?
b) Dez regras para obteno dos requisitos
Para facilitar a obteno dos requisitos, a empresa Software Productivity Center
(http://www.spc.ca) nos apresenta as dez regras, reproduzidas a seguir:
1. a obteno dos requisitos tem por objetivo descobrir e entender problemas,
e no encontrar solues. Voc s capaz de realmente entender os problemas do cliente quando pode demonstrar que conhece esses requisitos;
2. os clientes costumam confundir aquilo de que precisam com o que desejam. Durante a fase de levantamento dos requisitos, por meio de questionamentos e entendimento, ser possvel separar o necessrio do desejvel;
3. documente os problemas e as necessidades do cliente e pea para verificar a sua preciso e completude. Esse o meio de demonstrar que voc
entende as necessidades do cliente;
4. analise cuidadosamente os requisitos para que no haja conflito entre eles;
5. quantifique quo bem um usurio espera a funcionalidade do sistema
como parte dos requisitos. Todos os requisitos devem ser testveis;
6. formule os requisitos claramente, sem ambiguidades. Requisitos claros
eliminam o retrabalho e facilitam a entrega do produto no prazo;
7. quando houver presso para mudanas de requisitos, antes de prosseguir, envolva todos os principais interessados para fazer uma avaliao
do impacto e custo da alterao;
8. procure trabalhar com requisitos bons o suficiente. A busca de requisitos perfeitos pode aumentar os riscos e ocasionar atrasos;
9. para coletar e documentar os requisitos, procure pessoas que saibam
escutar, falar e escrever;
e-Tec Brasil
40
Anlise de Sistemas
10. no dependa somente dos conhecimentos da equipe de desenvolvimento.

Os requisitos so, geralmente, definidos por pessoas fora da equipe de desenvolvimento. Garanta que todos os envolvidos que fornecem informaes
de requisitos entendam o que um bom requisito e participe de sua criao.
3.3 Casos de uso

Um instrumento muito til no desenvolvimento de sistemas o caso de uso.
Os casos de uso so escritos em um documento que serve para orientar a
construo dos demais elementos do projeto.
Caso de uso
uma descrio detalhada de
um conjunto de interaes entre
um usurio e o sistema.
Vamos examinar agora os casos de uso com mais detalhes. Vamos conhecer
os elementos e conceitos a eles ligados.
Ator
algum ou alguma coisa que
participa do caso de uso e
externo ao sistema.
3.3.1 Atores
Na definio de casos de uso encontramos o termo usurio. Nos casos de
uso o usurio chamado de ator.
Temos dois tipos de atores:
a) ator iniciador: ele que inicia o caso de uso, geralmente, sendo o seu
ator principal. Por exemplo, se estamos fazendo um sistema bancrio,
o caso de uso retirar dinheiro ter como ator iniciador o ator cliente;
b) ator participante: aquele que de alguma forma participa do caso de
uso. Por exemplo, no caso de uso comprar itens, existe um ator atendente que atende o ator cliente.
Um ator no precisa, necessariamente, ser uma pessoa. Um ator pode
representar:
a) um grupo de pessoas. Por exemplo, clientes, estudantes, etc.;
b) uma funo de uma pessoa. Por exemplo, estudante representante da turma;
c) outro sistema externo;
d) um conceito abstrato como hora, data, etc. Por exemplo, o ator data
pode iniciar um caso de uso chamado cancelar pedidos para pedidos
feitos h mais de seis meses.
41
e-Tec Brasil
Um ator geralmente participa de mais de um caso de uso e representa papis.

D um nome ao ator de forma que fique claro seu papel no sistema. Os
nomes devem ser condizentes com aqueles j usados na empresa. Dessa
forma, nossos clientes compreendero mais facilmente o significado desse
elemento do caso de uso.
Vamos precisar encontrar todos os atores envolvidos no sistema?
A resposta a essa pergunta SIM. E, se quiser, utilize as perguntas a seguir
para auxili-lo nessa tarefa:
a) Qual o principal usurio do sistema?
b) Quem fornece as informaes para o sistema?
c) Quem obtm as informaes do sistema?
d) Quem instala o sistema?
e) Quem opera o sistema?
f) Quem desativa o sistema?
g) Que outros sistemas interagem com o sistema?
h) Algum processo acontece automaticamente em horas predeterminadas?
i) Quem fornecer, utilizar ou remover informaes do sistema?
j) De onde o sistema obtm informaes?
3.3.2 Tipos de casos de uso e sua descrio

J sabemos que um caso de uso um documento narrativo que descreve
uma sequncia de eventos de um ator (um agente externo) que usa um sistema para completar um processo.
Com relao ao nvel de detalhes dessa descrio, podemos dividir os casos
de uso em dois grupos:
a) caso de uso de alto nvel: descreve um processo de forma muito breve, usualmente, em duas ou trs sentenas. Contm os dados: nome do
caso de uso, atores, tipo, descrio.
e-Tec Brasil
42
Anlise de Sistemas
Exemplo de caso de uso de alto nvel:

Caso de uso: Comprar itens.
Atores: Cliente, caixa.
Tipo: Primrio.
Descrio: Um cliente chega a um ponto de pagamento, com vrios itens
que deseja comprar. O caixa registra os itens de compra e recebe o pagamento. Ao trmino, o cliente deixa a loja com os itens.
b) caso de uso expandido: descreve um processo com mais detalhes que
um caso de uso de alto nvel. Contm uma seo chamada sequncia
tpica de eventos, que descreve os eventos passo a passo. Os casos de uso
no formato expandido so muito teis para uma melhor compreenso
dos processos e requisitos, j que eles descrevem com detalhes todos os
passos de uma operao do sistema.
Observe que a descrio da operao bem simples e direta.
Um caso de uso expandido contm os seguintes dados:
1. nome: Identificador do caso de uso: deve ser escrito em formato de verbo
+ substantivo e ser suficiente para se perceber a que se refere o caso de uso;
2. descrio geral: curto resumo do caso de uso (um ou dois pargrafos,
no mximo);
3. precondies: listagem das condies que se devem verificar quando se
inicia o caso de uso. No incluem triggers;
4. triggers (em portugus: gatilhos): eventos que ocorrem dando incio
ao caso de uso;
5. cenrio de sucesso principal (linha de eventos): descreve o curso por
uma sequncia de eventos numerados;
6. percursos alternativos (extenses): descrio de percursos alternativos linha de eventos principal;
43
e-Tec Brasil
7. ps-condies: descrio do estado do sistema aps a execuo do

caso de uso;
8. regras de negcio: reservadas para informao adicional relativa poltica da empresa ou restries impostas pelo tipo de negcio;
9. listas de variaes tecnolgicas: especificaes dos mtodos de entrada e sada de dados e quais formatos podem ser utilizados no caso de uso;
10. frequncia de ocorrncia: frequncia de ocorrncia do caso de uso por
dia, ms, hora, etc. (Influencia no projeto, desenvolvimento ou implantao do sistema?);
11. notas: informaes adicionais relativamente ao caso de uso, no cobertas pelos dados anteriores;
12. autor e data: listagem dos autores e datas das vrias verses revistas.
Ao longo de nossa disciplina veremos vrios exemplos desses dois tipos de
casos de uso.
Um bom estudo sobre os
diagramas de caso de uso e
outros elementos da UML podem
ser encontrados em http://www.
macoratti.net/vb_uml2.htm.
a) Identificao dos casos de uso

Os casos de uso so encontrados e descritos por meio de entrevistas e
brainstorms. O roteiro mais indicado para a aplicao dessas tcnicas :
1. identificao de todos os atores;
2. identificao de todos os casos de uso;
3. descrio simples de cada caso de uso;
4. desenho de um diagrama de casos de uso.
No espere encontrar todos os casos de uso e atores na primeira sesso.
natural aparecerem casos de uso e atores nas fases seguintes do desenvolvimento, isto , durante o processo de construo do software.
e-Tec Brasil
44
Anlise de Sistemas
Para ajudar nessa tarefa, as seguintes perguntas podem ser teis:

a) Quais as principais tarefas desse papel (ou ator)?
b) O que os usurios nesse papel precisam ser capazes de realizar?
c) Por que os usurios nesse papel precisam realizar essa tarefa?
d) Quais informaes os usurios nesse papel necessitam examinar, criar
ou alterar?
e) Quais informaes os usurios nesse papel necessitam saber pelo sistema?
f) Quais informaes os usurios nesse papel precisam informar ao sistema?
Um erro comum na identificao de caso de uso representar como casos
de uso passos individuais, operaes, ou transaes. Um caso de uso uma
descrio completa de um processo relativamente grande, que inclui, tipicamente, muitos passos ou transaes.
Exemplo de levantamento
Suponha que voc estivesse levantando as informaes sobre os casos de
uso de um sistema acadmico usado por funcionrios da secretaria de uma
escola. Para isso, voc escolheu a tcnica de entrevista. Quais perguntas voc
colocaria no roteiro dessa entrevista? Formulando apenas cinco perguntas,
poderiam ser utilizadas as seguintes:
1. Quais informaes sobre estudantes e professores vocs precisam guardar na secretaria desta escola?
2. Quais as principais tarefas desempenhadas pelo funcionrio responsvel
pela matrcula de estudantes?
3. Quais as informaes o diretor da escola precisa ter sobre professores
e estudantes?
4. Por que a secretria escolar precisa cadastrar estudantes novatos apenas
no incio de cada ano letivo?
5. Quais as informaes os professores precisam saber sobre suas turmas
pelo sistema?
45
e-Tec Brasil
b) Granularidade dos casos de uso

Um aspecto que pode ser complicado para o iniciante decidir a granularidade dos casos de uso, ou seja, a qual nvel de detalhamento devemos
descer ao definirmos uma funcionalidade.
Exemplo de levantamento:
Em um sistema de Caixa Eletrnico, temos uma funcionalidade chamada
Retirar Dinheiro. Essa funcionalidade ir requerer as seguintes interaes:
a) entrar carto;
b) entrar senha;
c) selecionar quantia desejada;
d) confirmar quantia;
e) remover carto;
f) retirar recibo.
Cada uma dessas interaes deve ser um caso de uso?
A resposta NO. Esse um erro clssico na construo de casos de uso. Os
casos de uso devem ser definidos para as funcionalidades do sistema e no para
as interaes. Dessa foram, mantemos a complexidade do caso de uso baixa.
Uma boa regra : um caso de uso deve satisfazer a um objetivo do usurio.
Aplicando essa regra simples ao exemplo acima, podemos fazer a seguinte
pergunta: Retirar Recibo (item 6) um objetivo do usurio? Ou seja, o objetivo do usurio desse sistema apenas Retirar Recibo? A resposta NO.
Ento, Retirar Recibo no ser um caso de uso.
Aplicando essa regra aos outros itens da lista, vemos que a resposta NO para
todos eles. O objetivo real do usurio retirar dinheiro, logo, Retirar Dinheiro
deve ser o caso de uso, isto , o nome do caso de uso ser Retirar Dinheiro.
e-Tec Brasil
46
Anlise de Sistemas
c) Relao entre casos de uso e funes do sistema

As funes do sistema representam o que o sistema deve realizar. Assim,
devemos ter casos de uso que implementem essas funcionalidades.
Algumas vezes uma funo resultar em um nico caso de uso; outras vezes,
vrias funcionalidades resultaro em um nico caso de uso.
d) Ordem de implementao dos casos de uso
Com o desenvolvimento iterativo vamos implementar um caso de uso em
cada ciclo de desenvolvimento. Com casos de uso muito complexos, podemos implementar verses simplificadas dele. Com casos de uso muito simples, podemos implementar mais de um caso de uso em um nico ciclo.
Ento surgem as perguntas: Que casos de uso devemos implementar primeiro? Qual ordem de implementao dos casos de uso melhor?
Recomendamos que voc implemente primeiro os casos de uso mais
importantes.
Para classificar os casos de uso, considere:
a) Causa impacto significativo no projeto da arquitetura?
b) Possui quantidade significativa de informaes e compreenso?
c) Possui quantidade significativa de funes de alto risco?
d) Envolve pesquisa significativa ou tecnologia nova e com riscos?
e) Contm representao de processos primrios da linha de negcios?
f) Possui influncia direta no aumento da receita ou na diminuio de custos?
Quanto mais respostas SIM voc obtiver nessas perguntas, mais importante ser o caso de uso em questo. Assim, podemos criar uma lista de caso
de usos numa ordem decrescente de importncia. Os primeiros casos de uso
listados sero os primeiros a ser implementados.
47
e-Tec Brasil
e) Diagrama de casos de uso

Um diagrama de casos de uso uma representao grfica dos casos de uso
e dos atores envolvidos no sistema em anlise.
Um diagrama de casos de uso mostra os atores e casos de uso de forma
grfica. Seu objetivo dar uma viso geral dos casos de uso necessrios ao
sistema de forma a facilitar a compreenso por todos os envolvidos na equipe de desenvolvimento do novo software.
Os smbolos que utilizamos so mostrados na Figura 3.1:
Utilizamos este smbolo
para representar um
ATOR
Ator
Caso de Uso
Utilizamos este smbolo

para representar um
CASO DE USO
SISTEMA
Comprar tens
Login
Caixa
Reembolsar tens
Comprados
Cliente
Figura 3.1: Simbologia do diagrama de casos de uso

O diagrama de casos de uso muito interessante para dar uma viso geral
do sistema, com seus atores, casos de uso e a relao entre eles.
e-Tec Brasil
48
Anlise de Sistemas
Com esse diagrama, podemos ter uma ideia do tamanho do sistema e da

sua complexidade de uma forma grfica.
1. Considerando a Figura 3.1, descreva qual poderia ser objetivo do software
representado pelo diagrama intitulado Sistema.
2. Quais as maiores dificuldades encontradas por desenvolvedores durante
a fase de concepo de sistemas enquanto se levantam seus requisitos
com os usurios?
3. Pesquise na internet um exemplo de diagramas de caso de uso sobre um
sistema de vendas. Analise o diagrama e escreva as principais funes do
sistema de acordo com os casos de uso existentes nesse diagrama.
Os passos necessrios para criar o planejamento e elaborao dos sistemas so:
a) aps as funes do sistema terem sido listadas, defina a fronteira do sistema,
e, em seguida, identifique os atores e os casos de uso dando-lhes nomes;
b) descreva todos os casos de uso (conforme orientao da seo 3.3.2) em
um formato de alto nvel e defina se eles so obrigatrios ou opcionais;
c) desenhe um diagrama de casos de uso;
d) relacione os casos de uso e ilustre o relacionamento no diagrama de
casos de uso;
e) escreva os casos de uso mais crticos, influentes e de maior risco para o
sistema, no formato expandido;
f) defina a ordem de implementao segundo a importncia de cada caso
de uso (conforme orientao da seo 3.3.6).
Dessa forma, ao final da Fase de Concepo, teremos a produo do Documento de requisitos, conforme vimos na seo 3.2.3, e o Documento de
casos de uso, que conter os diagramas e as descries de casos de uso.
49
No vdeo chamado Diagramas

de caso de uso, disponvel
em http://www.youtube.
com/watch?v=fGAeF8HCjw&feature=related,
podemos ver o uso dos
diagramas de caso de uso
para o desenvolvimento dos
sistemas. Cite trs casos de uso
que encontramos comumente
nos sistemas de informao
de secretaria escolar. Envie sua
resposta para seu tutor a distncia.
e-Tec Brasil
Resumo
Nesta aula estudamos os passos iniciais para desenvolver o projeto de um
sistema. A partir do levantamento dos requisitos, conseguimos identificar
elementos importantes, como casos de uso, atores e seus relacionamentos,
de maneira que o diagrama gerado por eles apresente uma viso geral do
sistema e sua complexidade.
Estudamos tambm quais as tcnicas mais comumente usadas para o levantamento dos requisitos: entrevistas e brainstorming. Pelo seu uso conseguimos entender melhor quais as caractersticas de um sistema relatadas por seus usurios.
importante no esquecermos que todo conhecimento gerado pelo levantamento dos requisitos precisa ser documentado, e para isso produzimos o
Documento de requisitos e o Documento de casos de uso, cujos detalhamentos foram discutidos na seo anterior.
Na prxima aula vamos dar um passo frente para a construo de um sistema. Agora que j aprendemos como conhecer as caractersticas do sistema
por meio de seus requisitos, vamos aprender como desenhar um diagrama
que mostrar qual o comportamento ter nosso sistema de acordo com as
operaes que ele realizar. O diagrama que aprenderemos a criar ser o
Diagrama de Sequncia do Sistema (DSS).
1. Em que situaes devemos usar a descrio de caso de uso de alto nvel
e expandido?
2. Cite um exemplo de responsabilidade do cliente/usurio em relao ao
desenvolvimento de um sistema e explique sua importncia.
3. Voc acha que o tempo de resposta um atributo de um sistema de
manuteno de computadores? Explique sua resposta.
4. Desenhe trs casos de uso de alto nvel que mostrem funes de um
sistema de aluguel de fitas numa videolocadora (Por exemplo: emprestar
um vdeo, devolver um vdeo, pagar uma locao, solicitar reserva de
vdeo, etc.). Descreva tambm os casos de uso desenhados.
5. Escreva uma lista dos casos de uso desenhados na questo 4 e ordene-os
por seu grau de importncia
e-Tec Brasil
50
Anlise de Sistemas
Aula 4 Descrio do comportamento

do sistema
Objetivos
Conhecer os elementos dos diagramas de interao.
Usar os diagramas de interao da UML para especificao do
comportamento do sistema.
4.1 Introduo
O comportamento de um sistema definido pelas operaes que ele realiza.
Esse comportamento demonstra situaes em que o sistema pode se encontrar.
Por exemplo, se considerarmos um boleto de pagamento em um sistema financeiro empresarial, podemos identificar alguns comportamentos possveis: boleto
pago, boleto no pago, boleto com pagamento atrasado, etc.
Em UML, a representao grfica utilizada para mostrar as operaes do
sistema chama-se Diagrama de Sequncia de Sistema (DSS).
Comportamento do Sistema
o conjunto de operaes que o
sistema realiza. Um termo muito
usado para referenciar esse
comportamento Application
Programming Interface (API)
do sistema.
4.2 Diagrama de sequncia

do sistema (DSS)
Podemos resumir a descrio do DSS como a representao grfica dos casos de uso identificados pelo sistema. mais fcil a identificao dos casos
por um diagrama que mostra tambm a relao desses casos com o ambiente externo ao sistema.
um diagrama que mostra graficamente a utilizao do sistema, de acordo
com o caso de uso. Ele representa atravs de figuras o comportamento
possvel que o sistema poder ter.
51
Diagrama de sequncia do
sistema (DSS)
um diagrama que mostra
graficamente a utilizao do
sistema, de acordo com o caso
de uso. Ele representa atravs
de figuras o comportamento
possvel que o sistema poder
ter.
e-Tec Brasil
4.3 Construo do diagrama

de sequncia do sistema
Nossos DSS representam as interaes entre os atores e o sistema. O sistema
considerado uma caixa-preta (ou seja, no conhecemos seu interior,
sabemos apenas sua funo): no precisamos saber como o sistema ir
implementar a operao!
Colocamos os atores no lado esquerdo do diagrama e na parte direita colocamos uma caixa que representa o sistema.
Em seguida, acrescentamos uma linha vertical. A linha representa a passagem do tempo. O tempo corre de cima para baixo (Figura 4.1):
Figura 4.1: Diagrama de sequncia Passagem do Tempo

As interaes entre o usurio e o sistema so representadas por linhas horizontais com setas que indicam a direo da interao. A descrio da interao escrita na seta. Uma mensagem representada por uma linha contnua e uma resposta representada por uma linha pontilhada (Figura 4.2):
Figura 4.2: Diagrama de sequncia - Mensagem/Resposta

e-Tec Brasil
52
Anlise de Sistemas
Continuamos a acrescentar as interaes (Figura 4.3).

Ator
Sistema
Mensagem1
Resposta1
Mensagem2
Resposta2
Figura 4.3: Diagrama de sequncia - 2 Mensagens/Respostas

Fonte: Elaborada autor
Uma vez que o caso de uso est elaborado, bem simples desenhar o diagrama de sequncia de sistema. Basta ir examinando as interaes descritas
no Cenrio de sucesso principal e nas Extenses.
Podemos considerar um DSS como um resumo grfico ou uma representao grfica de um caso de uso. Assim, importante prestar ateno, ao
colocar os nomes das operaes, para que seja o mais esclarecedor possvel.
Devemos comear o nome com um verbo e procurar mostrar a inteno da
operao. Por exemplo: entrarItem(idItem) melhor do que escanear(idItem).
4.4 Objetivos do DSS

Os principais objetivos para construir o DSS so:
a) identificar detalhes dos eventos do sistema
Geralmente a descrio textual dos detalhes que envolvem os eventos de
um sistema acaba no sendo claramente percebida pela quantidade de informaes que ela traz. Nesses casos, os desenvolvedores deixam de projetar
solues para detalhes importantes que passaram despercebidos durante o
projeto. O DSS facilita a percepo de todos os detalhes por apresentar graficamente cada evento e as informaes referentes a cada um. Assim, a probabilidade de no se considerar algum detalhe por falta de ateno pequena;
53
e-Tec Brasil
b) esclarecer quais operaes importantes devem ser projetadas para

lidar com esses eventos
O DSS permite uma viso ampliada dos eventos de um sistema, ou seja,
possvel ver todos os eventos, suas relaes e suas caractersticas ao mesmo
tempo. Dessa forma, mais fcil analisar quais as operaes (solues) so
mais importantes para cada evento descrito. Isso facilita tambm a deciso
de quais desses eventos so imprescindveis para as verses do sistema, no
caso de um ciclo de desenvolvimento de sistema incremental;
c) escrever os contratos de operaes
Os contratos de operaes especificam os detalhes das solues propostas
para os eventos identificados no projeto. Com a representao grfica que
encontramos no DSS, conseguimos mais facilmente definir os componentes
dessas operaes. O diagrama ainda facilita a identificao das associaes
entre os eventos e destes com o ambiente externo.
e-Tec Brasil
54
Anlise de Sistemas
Resumo
Nesta aula estudamos o comportamento do sistema e sua representao na
UML. Sua importncia grande para que seja possvel a melhor compreenso do sistema que se pretende desenvolver. Atravs do diagrama os casos
de uso so descritos, alm de suas operaes, de acordo com a finalidade
do sistema. O DSS a representao grfica dos casos de uso estudados na
fase inicial.
A seguir aprenderemos outra representao importante para o desenvolvimento de um sistema: o modelo de domnio (ou modelo conceitual).
1. Cite duas mensagens enviadas por um ator Estudante para um sistema
chamado Acadmico, referentes matrcula em um novo curso, conforme o exemplo abaixo:
Mensagem 1 Solicitar matrcula
Resposta 1 Enviar lista de documentos necessrios
Mensagem 2 Entregar dados pessoais para matrcula
Resposta 2 Informar que a matrcula foi concluda.
2. Explique como devem ser escritos os nomes das mensagens num DSS.
3. Quais os principais objetivos de um DSS?
55
e-Tec Brasil
Aula 5 Criao de um modelo

do sistema
Objetivos
Usar o modelo de domnio para delinear o escopo do sistema a ser
desenvolvido.
5.1 Introduo
A criao de modelos uma atividade comum em vrias reas de trabalho,
principalmente nas profisses que fazem projetos, como engenharia, arquitetura, etc.
O uso de modelos ajuda o profissional a entender melhor o funcionamento
de um sistema, sua relao com o ambiente onde est inserido e sua troca
de informaes com os usurios (ou pessoas) que usaro esses sistemas para
alguma tarefa.
Em Computao usamos frequentemente modelos para analisarmos e desenvolvermos sistemas de informao. O modelo de domnio um desses
diagramas utilizados pelos analistas.
Em todo projeto importante o uso de modelos que nos ajudem a compreender melhor o funcionamento dos sistemas. Nesta aula estudaremos o
modelo lgico (ou conceitual) de um sistema, sua importncia e as tcnicas
utilizadas para sua criao. Ao final da aula saberemos como representar
graficamente esse modelo. O modelo de domnio no modelo de projeto de software, isto , no representa componentes de software
(rotinas, bibliotecas, programas executveis, etc.).
5.2 Modelo de domnio

A modelagem de domnio, tambm chamada de modelagem conceitual,
a atividade de encontrar quais conceitos so importantes para um
determinado sistema.
Esse processo nos ajuda a entender melhor o sistema e o negcio de
nosso cliente. Ou seja, ajuda-nos a entender o que nosso cliente precisa para
executar o seu trabalho.
57
e-Tec Brasil
modelo de domnio
uma representao de coisas
do mundo real, isto , coisas
que nosso cliente capaz
de reconhecer como uma de
suas tarefas de trabalho, ou
ferramentas que ele usa para
executar suas funes, etc.
A construo do modelo de domnio basicamente a identificao dos

diferentes conceitos no domnio do problema e a documentao dos resultados em um modelo conceitual.
Para Serafini e Cunha (2010) existem definies e recomendaes importantes sobre como construir esse modelo. Segundo eles, importante obter
uma decomposio do problema, em termos de conceitos (e objetos) e de
seus relacionamentos. No modelo conceitual, procuramos capturar todos os
conceitos ou ideias que o cliente reconhece. Para construir um modelo conceitual de nosso sistema, precisamos identificar os conceitos, os atributos
de conceitos e os relacionamentos entre conceitos.
5.3 Conceitos
Conceito um objeto, uma coisa ou uma ideia (por exemplo: cliente, estudante, professor, matrcula, manuteno, atendente, venda, etc.).
Um conceito deve possuir:
a) smbolo: palavras ou imagens representando um conceito;
b) inteno: a definio de um conceito;
c) extenso: o conjunto de exemplos aos quais o conceito se aplica.
Exemplos:
a) pedido: em um sistema comercial;
b) jogador: em um sistema de jogos;
c) sala: em um sistema de escola;
d) quarto: em um sistema de hotis.
Alguns pssimos exemplos de conceitos so:
DisparoDeEventos e FormularioDePedidos. Esses exemplos no so bons, pois eles
esto voltados ao projeto ( soluo) e no ao problema.
Uma boa regra : se o cliente no entende um determinado conceito, provavelmente isso no um conceito. Ou seja, se o cliente no consegue entender a importncia do conceito no sistema ou no consegue identificar
seu uso no sistema, j temos uma boa indicao de que esse conceito no
pertence ao sistema em desenvolvimento.
e-Tec Brasil
58
Anlise de Sistemas
5.4 Identificao de conceitos

Utilizamos normalmente uma abordagem semelhante quela utilizada para
encontrar os casos de uso, por exemplo, uma reunio (ou vrias) com o
maior nmero possvel de clientes interessados no sistema.
Nessa reunio, devemos fazer um brainstorm para capturar todas as sugestes
apresentadas pelos participantes. Em seguida, devemos trabalhar em grupo
para discutir e justificar cada sugesto. Aplique a regra que diz que o cliente
deve entender o conceito; caso contrrio, o conceito dever ser eliminado.
Lembre-se de que, como os conceitos so objetos, coisas ou ideias, devem
ser identificados com um substantivo.
5.5 Atributo
Devemos incluir em nosso modelo conceitual todos os atributos que de alguma forma devem ser memorizados (ou guardados) pelos conceitos.
atributo
um valor de dado lgico de um
conceito.
Uma regra prtica para tipo de atributo simples: faa dele um atributo, se
ele puder ser visto naturalmente como um nmero, uma string, um boolean,
uma data, etc.; caso contrrio, represente-o como um conceito. Em caso de
dvida, defina-o como um conceito separado, em vez de um atributo.
Chamamos de atributos primitivos aqueles que so naturais para um determinado conceito. Ou seja, so informaes que qualificam, particularizam ou definem aquele conceito. Os tipos de dados associados a esses atributos so os clssicos estudados nas disciplinas de programao (strings, booleans, inteiros, etc.).
Existem, porm, atributos chamados de no primitivos. So aqueles compostos
de sees separadas, ou que promovem operaes que so usualmente associadas a eles prprios, tais como anlise sinttica ou validao; ou que tm outros
atributos; ou que so uma quantidade com uma unidade claramente definida.
5.6 Identificao de atributos

Devido semelhana entre atributos e conceitos, podemos usar as mesmas
tcnicas utilizadas em conceitos para a identificao dos atributos. Serafini e
Cunha (2010) apresentam as seguintes dicas para a identificao dos atributos:
a) valores simples ou nmeros, geralmente, so atributos;
b) se um conceito, ou uma propriedade, no pode fazer alguma coisa, ele
um atributo.
59
e-Tec Brasil
Exemplo:
Tenho um conceito chamado Estudante em um determinado sistema. Aps
a reunio com os clientes, foram identificados dois atributos: Nome do
Estudante e Curso do Estudante. Porm, considerando que um curso no
um dado particular de estudantes (na verdade ele pode identificar vrias
outras coisas como: colgio, formao profissional, sala de aula, etc.),
podemos pensar se Curso do Estudante deve ser um atributo de Estudante
ou um novo conceito. A regra transformar em conceito tudo que deixa
dvida em relao sua classificao. Assim, Curso de Estudante ser criado
como um novo conceito em meu Modelo de domnio.
5.7 Associaes
A maioria dos sistemas que iremos desenvolver apresentar, no mnimo, alguns conceitos que tero algum tipo de relacionamento com outros conceitos.
Por exemplo, num sistema acadmico, um Professor leciona uma Disciplina.
Nesse caso, temos uma relacionamento entre Professor e Disciplina, e esse
relacionamento recebe o nome de leciona. Ainda, um Estudante escolhe
um Curso. O relacionamento escolhe. Outro exemplo: um Estudante faz
uma Prova. O relacionamento faz.
Podemos dizer que uma associao um relacionamento entre conceitos
que indica uma conexo com significado e interesse definido.
Para que o relacionamento seja identificado como associao, ele deve ser
preservado por algum tempo dentro do sistema. Ou seja, no faz sentido
indicarmos um relacionamento entre dois conceitos que acontece uma nica vez durante a existncia do sistema (seria o mesmo que desenvolvermos
uma funo dentro de um sistema que seria usado somente uma nica vez
pelo usurio). importante ainda lembrar que a associao tambm deve
ser identificada por um nome, da mesma forma que o conceito e o atributo.
multiplicidade (ou
cardinalidade)
Define o nmero de associaes
que dois conceitos podem ter.
e-Tec Brasil
Usamos a definio de multiplicidade (ou cardinalidade) para definir a

quantidade de relacionamentos que podemos identificar entre dois conceitos num certo sistema.
60
Anlise de Sistemas
Exemplo:
a) entre os conceitos Professor e Disciplina temos a associao leciona.
Dizemos ento que sua cardinalidade de 1 para muitos, porque um
professor pode lecionar muitas disciplinas;
b) entre os conceitos Estudante e Turma temos a associao pertence a.
Dizemos que cardinalidade dessa associao de 1 para 1, ou seja, um
estudante s pode pertencer a uma turma.
No existe nenhuma limitao quanto ao nmero de associaes que os
conceitos podem ter. A definio desse nmero depende do sistema em
questo. Em alguns sistemas podemos encontrar uma cardinalidade 1 para
muitos, enquanto em outros muitos para muitos para um mesmo par de
conceitos. Por exemplo: Estudante pertence a Turma em algumas instituies de ensino um estudante pode estar matriculado em vrias turmas (se
ele fizer mais de um curso) e, assim, a cardinalidade seria 1 para muitos,
porm, em outras instituies um estudante s pode pertencer a uma turma,
pois no se aceita estudante matriculado em mais de um curso.
5.8 A UML e a representao do

modelo de domnio
A UML apresenta sua maneira de representar graficamente as definies
que estudamos nas sees anteriores: conceito, atributo e associao. Essa
representao gera um diagrama que chamamos de modelo de domnio
ou de modelo conceitual da UML.
5.9 Representao de conceitos e atributos

Representamos um conceito com uma caixa dividida em trs partes, conforme a Figura 5.1 a seguir.
Conceito
-Atributos
Figura 5.1: Smbolo de classe em UML
61
e-Tec Brasil
Na parte de cima, colocamos o nome do conceito; na parte do meio, colocamos os atributos do conceito. No modelo conceitual, a parte de baixo est
sempre em branco, pois nela colocamos os comportamentos do conceito
que no so analisados nesta etapa.
A Figura 5.2 mostra um exemplo em que observamos que o conceito Estudante tem dois atributos: nome e curso.
Aluno
-nome
-curso
Figura 5.2: Exemplo em UML de um conceito: Estudante
5.10 Representao de associaes

As associaes so representadas por uma linha que liga os dois conceitos.
Cada associao dever receber um nome. Os nmeros em cada lado da
linha descrevem a cardinalidade (ou multiplicidade) da associao e nos informam quantas instncias de cada conceito podem existir.
A Figura 5.3 apresenta a notao que utilizamos para mostrar a cardinalidade de uma associao:
*
1..*
1..40
5
3, 5, 8
zero ou muitos;
um ou muitos;
um at quarenta;
exatamente cinco;
exatamente trs,
cinco ou oito;
Figura 5.3: Multiplicidades entre conceitos

e-Tec Brasil
62
Anlise de Sistemas
O smbolo * significa muitos. Note a sutil diferena entre 1..* e *, este

ltimo muitos, significando zero ou mais conceitos, e o primeiro significa 1 ou mais conceitos.
Serafini e Cunha (2010) lembram que quando formos decidir sobre que
nomes daremos s associaes, devemos evitar nomes fracos, ou seja, nomes com significado muito genrico. Por exemplo: tem, associado a,
possui, etc. A utilizao desses nomes pode esconder problemas ou erros
na definio da associao por darem uma ideia muito ampla de seu significado, deixando o desenvolvedor com a possibilidade de criar, no futuro,
programas sem utilidade por ter interpretado erroneamente qual tipo de
associao existe entre os conceitos.
5.11 O modelo conceitual

Aps o estudo das sees anteriores, podemos comear a descrever nosso
diagrama do modelo conceitual. As etapas a serem seguidas so:
a) escrever os conceitos e os atributos.
Por exemplo, considerando um sistema hospitalar, a Figura 5.4 apresenta os
conceitos identificados aps as reunies com os mdicos;
Mdico
Paciente
Medicamento
Equipe
Figura 5.4: Exemplo

63
e-Tec Brasil
b) identificar as associaes (relacionamentos) existentes entre conceitos.

Uma boa tcnica fixar um conceito e considerar as relaes com os outros
conceitos. Faa a pergunta Esses dois conceitos esto relacionados? e, se estiverem, imediatamente decida o nome do relacionamento e sua cardinalidade.
No exemplo anterior, as perguntas seriam feitas da seguinte maneira:
Pergunta 1 Mdico e Paciente esto relacionados?
Resposta 1 Sim, cada mdico atende um ou mais pacientes.
Pergunta 2 Mdico e Equipe esto relacionados?
Resposta 2 Sim, cada mdico dirige uma equipe mdica.
Pergunta 3 Mdico e Medicamento esto relacionados?
Resposta 3 Sim, cada mdico prescreve um ou mais medicamentos.
Essas perguntas devem ser feitas at que se esgotem todas as possibilidades
de associaes entre os conceitos.
Ao final, o diagrama final ficar conforme a Figura 5.5:
atende
Mdico
1
1
Paciente
prescreve
*
Equipe
dirige
Medicamento
Figura 5.5: Modelo final

e-Tec Brasil
64
Anlise de Sistemas
Os autores Larman (2007) e Serafini e Cunha (2010) apontam algumas regras que merecem ser seguidas para no construirmos diagramas incorretos:
a) as associaes so menos importantes que os conceitos em um Modelo de domnio. Qualquer associao pode ser acrescentada facilmente
durante o projeto, porm a incluso de novos conceitos em fases mais
adiantadas de um projeto praticamente impossvel visto o trabalho que
teremos para refazer toda a anlise j feita em funo do primeiro modelo gerado;
b) No caia na tentao de escrever associaes em excesso, como forma
de se proteger de algum esquecimento. O que voc vai acabar obtendo
um diagrama confuso e complexo e que no vai te ajudar nas prximas
etapas. (SERAFINI; CUNHA, 2010, p. 66);
c) importante que seus clientes aprovem o modelo conceitual gerado.
Apresente e explique o modelo para todos os usurios envolvidos, a fim
de que possam entend-lo e se sentirem capazes de aprov-lo.
As aes a seguir so um roteiro para o desenho do diagrama do modelo
conceitual:
a) listar os conceitos candidatos, usando a identificao de substantivos
relacionados com os requisitos que esto sendo considerados;
b) desenhar os conceitos no modelo conceitual (modelo de domnio);
c) escolher um conceito e fixar seu lugar no diagrama (modelo) e colocar
graficamente os conceitos relacionados prximos a esse conceito;
d) encontrar, para cada conceito, as associaes entre ele e os demais conceitos;
e) acrescentar a associao (relacionamento) entre os conceitos com a escrita de nome significativo;
f) acrescentar na associao sua cardinalidade;
g) acrescentar os atributos necessrios para completar os requisitos de informao.
65
e-Tec Brasil
Resumo
Conhecemos o modelo conceitual e seus principais componentes nesta aula:
conceito, atributo e associao. Vimos que esse modelo nos apresenta uma
viso grfica e global da relao existente entre os conceitos de um sistema, alm de seus atributos. Estudamos tambm que as associaes entre os
conceitos podem ser uma ou vrias e que elas indicam a cardinalidade da
ocorrncia do relacionamento entre dois conceitos. Aprendemos como representar graficamente todos os elementos do modelo e ainda como montar
o diagrama final. Vimos tambm que podemos usar regras de levantamento
de requisitos e casos de uso para identificar os conceitos e seu comportamento. Na aula seguinte vamos aprender a usar as informaes que estudamos at agora (conceituais) para construo da arquitetura do sistema.
Atravs dela definiremos as partes que comporo nosso futuro software.
Atividades de avaliao
1. Explique o que uma associao e d um exemplo do relacionamento
entre os seguintes conceitos:
a) Pedreiro Casa: constri (EXEMPLO)
b) Professor Estudante: ensina (EXEMPLO)
c) Motorista Carro:
d) Banco Correntista:
e) Mdico Paciente:
f) Juiz Processo:
2. Desenhe um diagrama do modelo conceitual de um sistema hospitalar
que atenda pessoas para internao, contendo os seguintes conceitos e
associaes:
Conceitos:
a) Mdico
b) Paciente
c) Enfermeiro
e-Tec Brasil
66
Anlise de Sistemas
d) Medicamento
e) Enfermaria
f) Pronturio Mdico
g) Farmcia Hospitalar
Associaes:
1. atende
2. cuida
3. prescreve
4. est internado
5. escreve
6. fornece
67
e-Tec Brasil

Objetivos
Conhecer as principais arquiteturas possveis para um sistema.
Escolher entre as arquiteturas na fase de projeto de um sistema.
6.1 Introduo
Da mesma maneira que um arquiteto trabalha organizando os espaos para a
construo de uma casa, organizamos os componentes de software de maneira a distribuir da forma mais eficaz todos os componentes que faro parte do
nosso sistema. Existem vrias formas de se projetar um software, dependendo
de seu objetivo e funcionalidade. Assim, tambm na arquitetura de software
so definidos modelos que podem ser utilizados para que cada projeto esteja
com o formato mais adequado para seu uso.
Comeamos nesta aula o estudo da forma como nossos sistemas podem
agrupar seus componentes. Pelo estudo das camadas nas quais podemos
dividir nosso projeto, aprenderemos quais os tipos de arquitetura podemos
usar para que tenhamos um bom projeto. Dessa forma, estaremos nos preparando para as futuras fases de desenvolvimento de sistemas (codificao)
de forma planejada e que atenda s necessidades dos nossos clientes.
Arquitetura de Software
a forma como dividimos e
organizamos o sistema em blocos
reutilizveis que aumentam a
qualidade e reusabilidade do
software
Segundo Booch, Rumbaugh e
Jacobson (1997 apud LARMAN,
2007), uma Arquitetura de
software um conjunto de
decises significativas sobre a
organizao de um sistema, a
seleo dos elementos estruturais
e suas interfaces pelas quais o
sistema composto, juntamente
com seu comportamento, suas
colaboraes e sua composio.
6.2 Definies de arquitetura de software

Aps a fase em que levantamos os requisitos do sistema, precisamos nos
preparar para transformarmos esses requisitos em uma implementao.
Uma boa estratgia para chegarmos implementao dividirmos o problema em problemas menores. Assim, esses problemas menores podem ser
vistos como blocos, que possuem as seguintes vantagens:
a) podemos reutilizar esses blocos;
b) qualquer dependncia dentro de um bloco fica local a ele;
69
e-Tec Brasil
c) podemos trocar blocos equivalentes;

d) alguns blocos podem ser padronizados.
A arquitetura de software mostra a forma como um sistema est dividido/
organizado; mostra como as classes, os subsistemas e as camadas esto logicamente organizados.
A organizao feita utilizando-se os conceitos de Camada e Parties.
Camada
definida como uma diviso
lgica na arquitetura com uma
responsabilidade especfica
sobre um tpico. Cada camada
responsvel por um conjunto de
classes, pacotes ou subsistemas.
A interao entre as camadas se d pela troca de informaes entre elas, as

que esto nos nveis superiores e as de nveis mais inferiores.
Larman (2007) aponta dois tipos de camadas (Figura 6.1):
a) arquitetura em camadas estritas, quando uma camada solicita apenas
os servios da camada inferior;
b) arquitetura em camadas relaxadas, quando uma camada superior solicita servios de vrias camadas inferiores.
Camada 1
Camada 2
Camada
Estrita
Camada
Relaxada
Camada 3
Camada 4
Figura 6.1: Tipos de arquiteturas em camadas

Fonte: Serafini e Cunha, 2010, p. 71
6.3 Diviso de um sistema em camadas

Para facilitar a diviso das camadas de um software importante que:
a) cada camada tenha uma responsabilidade bem definida;
b) as camadas sejam definidas de maneira que as de nveis inferiores executem servios gerais e as de nveis superiores executem mais servios
especficos do sistema;
c) as interfaces sejam do tipo caixa-preta (quando a camada n no sabe
nada sobre a camada n-1 e usa a interface pblica para acess-la) ou do
e-Tec Brasil
70
Anlise de Sistemas
tipo caixa- branca (quando a camada n conhece os detalhes da camada

n-1 e usa esse conhecimento para acess-la).
Talvez os termos mais adequados para os nomes dessas interfaces na lngua
portuguesa fossem: caixa opaca e caixa transparente. O nome preta
usado por ser uma cor que no permite visibilidade. O nome branca, pelo
contrrio, seria a cor que mais permitiria visibilidade. Assim, quando dizemos
que uma caixa preta, estamos querendo dizer que no conseguimos ver o
que existe em seu interior, ou seja, no sabemos detalhes da implementao
daquele software. Por outro lado, a caixa branca seria aquela sobre a qual
sabemos tudo sobre a implementao de seu software.
6.4 Representao da arquitetura

de software na UML
A Figura 6.2 apresenta os smbolos que utilizamos em UML para representar os packages (pacotes) e subsistemas (parties de camadas complexas
de um sistema).
Package
<<sbsystem>>
SUBSISTEMA
Figura 6.2: Notao UML para packages e subsistemas

As Figuras 6.3 e 6.4 mostram um exemplo de arquitetura.

GUI
Web
subsistema
Consultas
Figura 6.3: Exemplo de arquitetura

71
e-Tec Brasil
GUI:Web
Dominio:Consultas
Figura 6.4: Outra notao de arquitetura

Observe que os exemplos acima so idnticos: mostram a mesma coisa. Ambos mostram os pacotes inseridos em seus respectivos subsistemas, porm
com representaes grficas distintas. Use a representao que achar mais
interessante em seus projetos.
6.5 Tipos de arquiteturas de sistemas

de informao mais comuns
Estudaremos nesta seo os tipos de arquitetura de sistemas que se encontram mais comumente no mercado de desenvolvimento de software.
6.5.1 Arquitetura em uma nica camada

Essa arquitetura era muito comum at a dcada de 1980, com a utilizao
de mainframes e terminais de computadores. Todo o processamento era
centralizado em um nico computador.
6.5.2 Arquitetura em duas camadas
Escalabilidade
a capacidade de manipular
uma poro crescente de
trabalho de maneira uniforme.
Estar preparado para crescer
(SERAFINI; CUNHA, 2010, p.78).
Essa arquitetura surgiu com a difuso da utilizao dos microcomputadores

nas empresas e permite uma melhor escalabilidade na utilizao dos recursos computacionais disponveis. uma arquitetura adotada nos sistemas
cliente-servidor tradicionais.
As duas camadas so (Figura 6.5):
a) camada Cliente: trata da lgica de negcio e da interface com o usurio;
b) camada Servidor: trata dos dados (sistema de banco de dados)
e-Tec Brasil
72
Anlise de Sistemas
Aplicao
Desktop
Aplicao
Desktop
Aplicao
Desktop
Servidor
Camada
Cliente
Camada
Servidor
Figura 6.5: Arquitetura em duas camadas

Fonte: Serafini e Cunha (2010, p.77)
6.5.3 Arquitetura em trs camadas

Essa arquitetura uma melhoria da arquitetura em duas camadas e resolve
alguns problemas:
a) aumenta a escalabilidade;
b) permite mudana mais fcil na lgica da aplicao ou na interface com
o usurio;
c) permite acessar fontes de dados heterogneas, isto , sistemas gerenciadores de bancos de dados diferentes.
As camadas so trs (Figura 6.6):
a) camada de Apresentao: interface grfica com o usurio;
b) camada de Aplicao: lgica do negcio;
c) camada de Dados: sistemas de bancos de dados.
73
e-Tec Brasil
Aplicao
Desktop
Aplicao
Desktop
Aplicao
Desktop
Servidor de
Aplicao
Servidor
Dados
Servidor
Dados
Figura 6.6: Arquitetura em trs camadas

importante lembrar que estamos falando de camadas lgicas. Fisicamente,

em uma mesma mquina, podemos ter mais de uma camada lgica, mas na
maioria das vezes isso no ocorre!
6.5.4 Arquitetura em n-camadas

Com a disseminao da internet, o acesso a sistemas via web tem se tornado
muito comum e til.
Assim, surgiram as arquiteturas multicamadas, ou seja, aquelas que tm vrias
camadas. Suas caractersticas so:
a) permitem o acesso por meio de navegadores web;
b) qualquer dispositivo pode acessar o sistema via web;
c) no necessitam da instalao de software nos clientes (s o navegador!);
d) a atualizao do software imediata;
e) permitem balancear a carga de servios em vrios servidores.
Uma arquitetura tpica n-camadas mostrada na Figura 6.7 a seguir.
e-Tec Brasil
74
Anlise de Sistemas
Aplicao
PDA
Aplicao
Celular
Servidor de
Web
Servidor de
Web
Servidor de
Aplicao
Servidor de
Aplicao
Servidor de
Dados
Servidor de
Dados
Aplicao
Desktop
Navegador
Camada
Apresentao
Camada
WEB
Camada
Aplicao
Camada
de Dados
Figura 6.7: Arquitetura em quatro camadas

6.6 Service oriented architecture (SOA) Arquitetura orientada a servios

Uma arquitetura SOA permite que um programa acesse uma aplicao remota.
A tecnologia empregada atualmente a de Web Services.
A SOA expe as funcionalidades de um sistema para outro programa.
Essa arquitetura apresenta como principais vantagens (SERAFINI; CUNHA,
2010, p. 80):
a) a independncia de plataforma. Por exemplo, uma parte do sistema pode
ser feita em uma linguagem e a outra parte em uma segunda linguagem
de programao;
Web Service
uma soluo utilizada na
integrao de sistemas e na
comunicao entre aplicaes
diferentes. Com essa tecnologia
possvel que novas aplicaes
possam interagir com aquelas
que j existem e que sistemas
desenvolvidos em plataformas
diferentes sejam compatveis. Os
Web Services so componentes
que permitem s aplicaes enviar e receber dados em formato
XML. Cada aplicao pode ter a
sua prpria linguagem, que
traduzida para uma linguagem
universal, o formato XML.
b) a integrao de servios de forma fcil;

c) composio de servios para criar servios maiores e mais complexos.
75
e-Tec Brasil
Resumo
Nesta aula aprendemos importantes conceitos sobre arquitetura de software. A
partir do detalhamento das partes que compem conceitualmente o sistema,
chegamos aos pacotes e subsistemas. A arquitetura a organizao desses blocos de forma a aumentar a qualidade e eficcia dos sistemas.
Estudamos tambm os conceitos de caixa-preta e caixa-branca, que so utilizados quando estamos projetando a arquitetura de um software.
Na ltima seo desta aula vimos quais os tipos de arquiteturas so mais comumente usados no mercado: arquitetura em uma camada, arquitetura em duas
camadas, arquitetura em trs camadas e, por fim, arquitetura em n-camadas.
A seguir, conheceremos um dos diagramas mais importantes da UML, o
diagrama de classes. A partir do levantamento dos requisitos do sistema e
da definio do modelo conceitual e da arquitetura, estaremos prontos para
definirmos as classes pertencentes ao sistema a ser desenvolvido, bem como
suas relaes e mtodos.
1. Explique as diferenas entre os tipos de arquitetura em n camadas e SOA.
2. Cite os tipos de camadas existentes e explique as diferenas entre eles.
3. Quais as representaes grficas para o package e subsistemas de acordo
com a UML.
4. Aps estudar o conceito de escalabilidade, indique quais tipos de arquitetura
favorecem a aplicao desse conceito nos sistemas. Explique sua resposta.
e-Tec Brasil
76
Anlise de Sistemas

Objetivos
Conhecer os elementos do diagrama de classes.
Usar o diagrama de classes para a modelagem dos dados de um
sistema.
7.1 Introduo
Aps os levantamentos feitos na fase inicial, quando conhecemos os requisitos e domnio do sistema, escrevemos o diagrama de classes. Ele apresenta
o sistema de forma esttica e detalha quais classes e seus relacionamentos
foram identificados no sistema a partir da aprovao do cliente.
7.2 Representao dos elementos do

diagrama de classes
As classes na UML so representadas por um retngulo dividido em trs
partes (Figura 7.1):
a) na primeira temos o nome da classe;
b) na segunda temos os atributos da classe;
c) na terceira temos os mtodos da classe.
NomeDaClasse
-atributo1: Tipo
+atributo2
#atributo3
-operacao1()
+operacao2()
+operacao3( parametro1, parametro2 )
Figura 7.1: Nome da classe
77
e-Tec Brasil
Os atributos podem ser mostrados como:

a) um elemento textual (Figura 7.2):
Registradora1
-vendaAtual: Venda
Figura 7.2: Elemento textual

Formato:
[visibilidade] nome do atributo: tipo
ou
b) uma associao (Figura 7.3):
Venda
Registradora2
-vendaAtual
Figura 7.3: Associao

Nesse exemplo Registradora possui uma associao com Venda chamada

vendaAtual.
Normalmente usamos o elemento textual para representarmos tipos de dados simples (ou primitivos) disponveis na linguagem de programao, por
exemplo: inteiro, string, etc. Para representarmos estruturas como arrays,
vetores, etc., usamos a associao.
Os mtodos (ou operaes) so mostrados na parte de baixo do smbolo de
classe (Figura 7.4):
Classe
+operacao()
Figura 7.4: Mtodos
e-Tec Brasil
78
Anlise de Sistemas
Formato:
[visibilidade] nome da operao (lista de parmetros): tipo de retorno
Operaes especiais que geralmente no aparecem nos diagramas:
a) criao de objetos (create): geralmente associada ao operador new.
b) operadores de acesso: so os mtodos get/set para acesso aos atributos.
Utilizamos a seguinte notao para a visibilidade de atributos e mtodos:
+: public
-: private
#: protected
Podemos utilizar palavras-chave para caracterizar nossas classes.
<<ator>>
<<interface>>
[abstract]
[ordered]
Utilizamos palavras-chave quando desenhamos as classes a mo, ou seja,
sem o apoio de um software.
Para mostrar objetos do tipo Interface podemos utilizar o smbolo (Figura 7.5):
Interface1
+operacao1()
Figura 7.5: Interface (modelo 1)

Ou ento o smbolo tradicional de classe com a palavra-chave <<interface>>

antes do nome da interface (Figura 7.6).
79
e-Tec Brasil
<<interface>>
Interface2
+operacao1()
Figura 7.6: Interface (modelo 2)
As colees de objetos (arrays, vetores, etc.) podem ser mostradas como:

a) um elemento textual (Figura 7.7)
Venda1
-linhaDeItens : LinhaDeItensDeVenda[1..*]
Figura 7.7: Elemento textual

Formato:
[visibilidade] nome do atributo: tipo [ocorrncias]
b) uma associao (Figura 7.8)
Venda2
-linhaDeItens 1..*
LinhaDeItensDeVenda
Figura 7.8:Associao
Na Figura 7.8, Venda2 possui uma associao com LinhasDeItensdeVenda

chamada linhaDeItens.
Usamos a representao grfica da Figura 7.9 para inserir comentrios em
um diagrama de classes.
Comentrio UML
Figura 7.9: Notao de comentrio

Fonte: Fowler (2004, p. 105)
e-Tec Brasil
80
Anlise de Sistemas
Uma generalizao mostrada com o smbolo

Figura 7.10.
, como mostrado na
Pai
Filho
Figura 7.10: Generalizao

Uma dependncia mostrada com uma linha (tracejada com uma seta
partindo do cliente para o fornecedor) entre dois elementos, como mostrado
na Figura 7.11.
Cliente
Fornecedor
Figura 7.11: Relao de dependncia

Uma dependncia indica qualquer tipo de visibilidade entre duas classes.

Veja o exemplo da Figura 7.12:
Aluno
-nome : String
-c : Curso
Curso
-nome
-cargaHoraria
Figura 7.12: Relao de dependncia

81
e-Tec Brasil
A composio e a agregao so usadas para representar as relaes de

todo e parte existentes entre alguns objetos.
Denominamos composio a relao na qual o objeto todo constitudo
pelo objeto parte, de maneira que sem o objeto todo o objeto parte
no tem sentido.
A Figura 7.13 apresenta uma composio:
Cliente
Endereco
Figura 7.13: Composio

A instncia Endereo s faz sentido se houver uma instncia correspondente

de Cliente. Ou podemos perguntar: para que guardar um endereo se no
sei a que cliente ele pertence?
Graficamente falando, a representao da composio contm um pequeno losango preenchido em um dos lados da linha horizontal que liga os
dois retngulos.
Quando exclumos o objeto pai, destrumos tambm o objeto filho. No
nosso exemplo, quando destrumos o objeto Cliente destrumos tambm o
objeto Endereo.
A Agregao acontece quando usamos tambm um objeto todo e outro
objeto parte; porm, a vida dos objetos independente.
Veja o exemplo na Figura 7.14:
LinhaPedido
DescricaoProduto
Figura 7.14: Agregao

Observe que, nesse caso, a representao grfica possui o losango NO preenchido. No exemplo da Figura 7.14, se eliminarmos o objeto LinhaPedido,
no devemos eliminar a DescrioProduto. Faz sentido no eliminarmos a
DescrioProduto pois esse objeto provavelmente dever ser utilizado por outros objetos. Em termos de programao Java, a diferena entre composio
e agregao sutil e pode ser ignorada.
e-Tec Brasil
82
Anlise de Sistemas
No se preocupe em utilizar agregao em seus projetos, utilize composio

sempre que for apropriado.
7.3 Mapeamento objeto-relacional

Um dos problemas de se projetarem sistemas usando o paradigma de Orientao
a Objetos como implementar os objetos (que possuem informaes a serem
guardadas) em bancos de dados que no foram criados para este paradigma. Ou
seja, os bancos de dados mais comumente encontrados no mercado so relacionais,
e, portanto, trabalham com implementao de entidades e relacionamentos
(modelo relacional), enquanto o produto gerado pelo desenvolvimento baseado
em Orientao a Objetos produz objetos. Assim, precisamos converter os objetos,
gerados nos diagramas de classes, em entidades e relacionamentos que podero
ser gerados dentro de um banco de dados relacional.
Sempre tenha seu carto de

referncia UML em mos.
Consulte o site www.omg.org
para obter a especificao oficial
de UML 2.0
Aprenda a usar um programa
para desenhar diagramas UML
(BlueJ, Astah, Rose, etc.).
Os bancos de dados adequados para o desenvolvimento de aplicaes OO

so os SGBDOO (Sistemas Gerenciadores de Bancos de Dados Orientados a
Objetos); porm, a indisponibilidade desses bancos de dados no mercado,
seja devido ao custo, diversidade ou oferta, faz com que seja necessria a
busca de tcnicas especficas para a soluo desse problema, para a criao
de objetos em bancos de dados que usa entidades.
Vamos conhecer essa tcnica.
Considere o diagrama de classe da Figura 7.12. Nele temos duas classes:
Alunos e Curso. A associao entre eles informa que alunos fazem cursos.
Esse diagrama pode ter sido gerado a partir de um diagrama de entidades e
relacionamentos, onde: a entidade ALUNO equivale classe Aluno e a entidade CURSO equivale classe Curso. Para detalharmos melhor o diagrama
de classes da Figura 7.12 podemos mostrar os atributos e mtodos associados s classes Aluno e Curso.
Assim, cada tabela do banco de dados foi mapeada para uma classe, mantendo-se o mesmo nome da entidade (tabela) na classe.
No diagrama de classes, os atributos dessas classes possuiro visibilidade private, ou seja, somente os mtodos internos classe que podero acess-los diretamente. Para objetos externos acessarem esses atributos, necessrio utiliza get e set. Caso o atributo seja apenas de leitura no ser preciso
usar a propriedade set.
83
e-Tec Brasil
At aqui transformamos as entidades em classes; porm, os relacionamentos

ainda no foram tratados.
No nosso exemplo (Figura 7.12) temos o relacionamento do tipo 1:n (um
para n). Assim, podemos ler o relacionamento da seguinte maneira: um aluno pode fazer um curso, porm um curso pode ser feito por vrios alunos.
Mdias integradas: Um bom

resumo do que estudamos
nesta aula pode ser visto no
vdeo chamado Diagrama
de Classes, disponvel em
http://www.youtube.com/
watch?v=F4fRIvPuZU8. Aps
assistir ao vdeo, escreva os
principais pontos apresentados
que, na sua opinio, no podem
faltar em um diagrama de
classes. Envie para seu tutor sua
resposta.
Para construir o relacionamento inserimos a chave estrangeira Curso.Codigo_

Curso na tabela Aluno associando-a chave primria Codigo_Curso da tabela
Curso. No diagrama de classes tambm temos os atributos Curso.Codigo_Curso
e Cdigo_Curso. Atravs de mtodos especficos, preenchemos essas chaves e
informamos a quais cursos esto ligados cada aluno registrado na tabela Aluno.
Resumo
Aprendemos nesta aula a representao grfica do diagrama de classes.
Apesar dos novos conhecimentos sobre cada elemento e conceito, importante lembrarmos sempre da forma correta de represent-los, porque
somente assim nossos diagramas podero ser lidos e entendidos por todos
que trabalham no desenvolvimento de um sistema.
Vimos que os conceitos estudados so todos provenientes da Orientao a
Objetos e representam a relao existente entre as classes, objetos e suas
especificaes.
Nosso prximo passo aprendermos como usar os padres de projetos de
acordo com os estudos e diagramas produzidos at esta aula.
1. Use sua criatividade e desenhe um diagrama de classes que possua os
seguintes conceitos:
1. Homem
2. Mulher
3. Certido de Casamento
4. Filhos
5. Residncia
e-Tec Brasil
84
Anlise de Sistemas
2. Desenhe um diagrama de classe (com apenas duas classes e um relacionamento entre elas) que apresente uma dependncia.
3. Desenhe um diagrama com quatro classes que apresente:
a) Mtodo,
b) Atributos,
c) Composio e Generalizao
Registre suas respostas num arquivo e poste-o no ambiente virtual.
85
e-Tec Brasil

Objetivos
Conhecer os padres de projeto GRASP.
Entender a aplicao dos padres de acordo com as questes de
programao existentes nos sistemas.
8.1 Introduo
Quando identificamos os conceitos em nosso sistema, identificamos o que
ele deve ser capaz de realizar, isto , identificamos as suas responsabilidades.
Podemos esperar que os conceitos dependam da ajuda de outros conceitos,
isto , que eles colaborem entre si para realizar as suas responsabilidades.
(SERAFINI, 2008, p. 95).
8.2 Responsabilidade e colaborao

Veja o caso de uso Pedir Emprestado um Livro em um sistema de Biblioteca.
O modelo de domnio (ou conceitual) para o sistema de Biblioteca obtido est
representado na Figura 8.1 a seguir.
Assistente
apanha livro
Livro
Estante
0..*
colaborao
aquilo que um objeto pode fazer/executar para outro objeto, de
modo que o caso de uso possa
ser realizado. Dessa forma, um
objeto ajuda o outro a executar
aquilo que a responsabilidade
do outro.
auxilia
Bibliotecario
verifica
responsabilidade
aquilo que um objeto deve ser
capaz de fazer/executar. Esse
conceito diz respeito s prprias
aes que um objeto deve fazer,
ou seja, so suas prprias responsabilidades dentro do sistema.
Catalogo
Figura 8.1: Modelo conceitual

Fonte: Serafini (2008, p. 98)
87
e-Tec Brasil
Podemos identificar a colaborao de vrios objetos:

a) o Usurio pede a colaborao do Bibliotecrio;
b) o Bibliotecrio pede a colaborao do Catlogo;
c) o Bibliotecrio pede a colaborao do Assistente.
Assim temos:
8.3 Definio de padro

padro
uma soluo muito utilizada e
genrica para um problema.
Padro, de uma forma geral, tudo aquilo que serve de soluo genrica
para problemas semelhantes. Os especialistas em qualquer profisso adotam
procedimentos padres para a soluo de problemas que ocorrem comumente em suas tarefas.
Vamos examinar algumas definies:
Os padres so sempre escritos (ou identificados) obedecendo s seguintes
informaes: nome do padro, problema que ele se prope resolver, soluo
apresentada pelo padro.
8.4 Os padres GRASP

Segundo Serafini (2008), Craig Larman adaptou os critrios fundamentais de
projeto ao formato dos padres de projeto e foi muito feliz com essa abordagem.
A utilizao dos padres de projeto propostos por Larman (2007) pode melhorar
bastante nossos diagramas de colaborao e, por conseguinte, nossos projetos.
Larman deu nome a seu conjunto de regras de GRASP que significa General
Responsibility Assigment Software Patterns, ou seja, Padres de Software
Genricos de Atribuio de Responsabilidades, e esses padres podem nos
ajudar a alocar responsabilidades (ou comportamentos) s classes de uma
forma muito prtica.
Os padres GRASP so:
a) Expert Especialista
b) Creator Criador
e-Tec Brasil
88
Anlise de Sistemas
c) High cohesion Alta coeso

d) Low coupling Baixo acoplamento
e) Controller Controlador
Os nomes de padres geralmente no so traduzidos para o portugus.
8.4.1 Grasp 1: Expert

um padro muito simples e um dos mais desobedecidos.
O padro Expert responde questo:
Dado um comportamento, a que classe deve ser atribudo esse comportamento?
Resposta: classe que contm a informao desejada. A classe especialista
(Expert) na informao!
A resposta a essa pergunta leva alocao inteligente dos comportamentos,
que por sua vez resulta em sistemas mais fceis de entender, de se expandir,
de se reutilizar e ainda mais robustos.
Veja o exemplo a seguir:
Considere trs classes: uma representando Pedidos, outra LinhaPedido e outra CatalogoDeProduto. Um trecho do modelo conceitual (Figura 8.2 ):
Pedido
-data
-hora
contm
LinhaPedido
-quantidade
descrito por
0..*
CatalogoProduto
1
-descricao
-preco
Figura 8.2: Diagrama de classes parcial

Fonte: Serafini (2008, p.101)
89
e-Tec Brasil
Agora suponha que estamos construindo a colaborao para um dos casos

de uso e esse caso de uso necessita que o total de um pedido seja apresentado ao usurio.
A que classe deve ser alocado o comportamento calcularTotal()?
O padro Expert diz que a nica classe que deve ser permitida lidar com o
Custo Total de um pedido a classe Pedido isso porque ela deve ser especialista sobre todas as coisas relativas a pedidos.
Ento alocamos o mtodo calcularTotal() classe Pedidos.
Mas para calcular o total do pedido, este precisa saber o total de cada
linha de Pedido.
A opo de deixar que Pedido acessasse as informaes de LinhaPedido e
realizasse a soma tornaria mais pobre nosso projeto.
Mais uma vez aplicamos o padro Expert, e temos que a nica classe que
deveria calcular o total de Linha de Pedido LinhaPedido; assim, criamos um
mtodo calcularSubTotal() e alocamos em LinhaPedido.
Por sua vez, calcularSubTotal() precisa obter o preo unitrio do produto;
ento, o Expert sugere alocar o mtodo obterPreco() a CatalogoProduto.
Assim teremos o diagrama de classes parcial mostrado na Figura 8.3.
Pedido
-data
-hora
+calcularTotal()
contm
LinhaPedido
-quantidade
+calcularSubTotal()
CatalogoProduto
descrito por
0..*
-descricao
-preco
+obterPreco()
Figura 8.3: Diagrama de classes (Pedido LinhaPedido CatalogoProduto)

e-Tec Brasil
90
Anlise de Sistemas
E nosso diagrama de colaborao est mostrado na Figura 8.4.

1: *[Para cada] linha=obterNovaLinha();
: Pedido
: LinhaPedido
2: subTotal=obterSubTotal();
: LinhaPedido
2.1: Preco=obterPreco;
: CatalogoProduto
descrito por
Figura. 8.4: Diagrama de colaborao

Sntese:
Nome: Expert
Problema: Dado um comportamento, a que classe deve ser atribudo esse
comportamento?
Soluo: classe que contm a informao desejada. A classe especialista
(expert) na informao (LARMAN, 2007).
8.4.2 Grasp 2: Creator

O padro Creator uma especializao do padro Expert.
Ele responde questo:
Quem deve ser responsvel pela criao de instncias de uma classe particular?
A resposta que a classe A deve ser responsvel pela criao dos objetos
da classe B se:
a) A contm objetos B;
b) A utiliza objetos B;
c) A contm os dados de inicializao que devem ser passados classe B.
91
e-Tec Brasil
No nosso exemplo anterior, quando um novo pedido criado, quem deve

ser responsvel pela criao dos objetos LinhaPedido?
A soluo apontada pelo padro Creator que, como pedido contm
LinhaPedido (veja a Figura 8.5), ento a classe Pedido (e somente ela) deve
ser responsvel pela criao de Linhas de Pedidos.
Pedido
contm
-data
-hora
LinhaPedido
-quantidade
+calcularSubTotal()
+calcularTotal()
Figura 8.5: Diagrama de classes parcial - (Pedido LinhaPedido)

O diagrama de colaborao est mostrado na Figura 8.6:

1: cria();
: Pedido
: LinhaPedido
Figura 8.6: Diagrama de colaborao

Sntese:
Nome: Creator
Problema: Quem deve ser responsvel pela criao de instncias de uma
classe particular?
Soluo: a classe A deve ser responsvel pela criao dos objetos da classe B se:
a) A contm objetos B;
b) A utiliza objetos B;
c) A contm os dados de inicializao que devem ser passados a classe B.
(LARMAN, 2007)
8.4.3 Grasp 3: High cohesion

Uma alta coeso significa que as responsabilidades de uma classe so fortemente relacionadas. Uma classe que faz muitas coisas no relacionadas
possui uma baixa coeso.
e-Tec Brasil
92
Anlise de Sistemas
extremamente importante garantir que as responsabilidades de cada classe

sejam focalizadas. Em um bom projeto orientado a objetos, cada classe no
deve realizar trabalho excessivo. Um sinal de que o projeto orientado a objetos bom cada classe possuir um pequeno nmero de mtodos.
Exemplo
No projeto de um sistema de controle de elevadores, uma classe ControladorElevadores foi projetada (Figura 8.7):
ControladorElevadores
+obterAndar()
+moverElevador()
+abribuirViagem()
+procedimentoEmergencia()
+acionaAlarme()
+atualizarLED()
+abrirPorta()
+fecharPorta()
+reset()
+iniciar()
+desativar()
+mostrarLog()
Figura 8.7: Classe ControladorElevadores

Observe como a classe ControladorElevadores realiza vrias funcionalidades

de trabalho: liga alarmes, inicia, desativa, move o elevador...
Esse no um bom projeto, porque a classe no coesiva, ela est tentando
realizar muitas coisas diferentes.
Essa classe deve ser difcil de manter, e no est claro o que ela deve fazer,
isto , quais as suas responsabilidades.
Nosso sistema de controle de elevador est tentando modelar no mnimo
umas trs abstraes: um alarme, as portas do elevador e o registro de falhas...
Separando essas abstraes, teramos um projeto melhor para o sistema de
controle de elevadores. Veja a Figura 8.8:
93
e-Tec Brasil
ControladorElevadores
+mover()
+atualizarLED()
+obterAndar()
Alarme
Pode acessar
+ligar()
Pode escrever
Pode
escrever
Log
Porta
+abrir()
+fechar()
+mostrar()
+limpar()
Figura 8.8: Diagrama de classes

Sntese:
Nome: High Cohesion
Problema: Como manter a coeso alta?
Soluo: Cada classe deve representar uma nica coisa (ou abstrao) do
mundo real.
(LARMAN, 2007)
8.4.4 Grasp 4: Low Coupling

Acoplamento uma medida de quo dependente uma classe de outra.
Um acoplamento alto entre mdulos leva a um projeto que difcil de manter ou modificar uma simples mudana em uma classe pode ocasionar
mudanas em vrias outras classes (SERAFINI, 2008).
O diagrama de colaborao fornece um excelente meio de verificar o nvel
de acoplamento do projeto. O diagrama de classes tambm d uma ideia do
nvel de acoplamento. Veja o diagrama mostrado na Figura 8.9.
e-Tec Brasil
94
Anlise de Sistemas
Figura 8.9: Diagrama de classes

Todas essas associaes so necessrias?

O projetista desse sistema deveria questionar seriamente alguns detalhes
de projeto.
Exemplo:
Por que a classe C est associada classe A, se existe uma associao indireta pela classe B? Essa associao pode ter sido criada para melhorar o
desempenho, o que seria razovel, ou pode ter sido criada por desleixo...
Por que a classe B possui tantas associaes? Essa classe provavelmente est realizando muito trabalho.
Seguir o modelo conceitual uma forma excelente de reduzir o acoplamento. Somente envie mensagem de uma classe outra se a associao foi
identificada durante a fase de modelagem conceitual. Agindo assim, voc
estar se restringindo a introduzir acoplamentos que existem no mundo real.
95
e-Tec Brasil
Exemplos:
No nosso sistema de Pedidos, identificamos no modelo conceitual que Clientes possuem Pedidos.
No caso de uso Criar Pedidos, que classe deve ser responsvel por criar
um novo pedido?
O padro Creator sugere que a classe Cliente deva ser responsvel
(Figura 8.10):
Cliente
Cliente
1: criar
Pedidos
Pedido
Figura 8.10: Padro Creator

Assim, acoplamos Cliente a Pedidos. Neste caso, est OK, pois eles so
acoplados no mundo real (veja no modelo conceitual).
A seguir, uma vez que Pedido foi criado, o caso de uso precisa adicionar as
linhas de pedidos a Pedidos. Quem deve ser responsvel por adicionar as
linhas de pedidos?
Uma soluo seria Cliente adicionar as linhas (afinal ele possui as informaes de inicializao necessrias: quantas linhas, que produtos, que quantidades, etc.). Essa soluo mostrada na Figura 8.11:
e-Tec Brasil
96
Anlise de Sistemas
2: *[para cada linha] cria

Cliente
1: criar
2.1: *[para cada linha] attach

LinhaPedido
Pedido
Figura 8.11: Soluo 1

Essa soluo aumentou o acoplamento artificialmente; temos agora todas as

trs classes dependentes umas das outras.
Se fizermos Pedido responsvel pela criao das linhas de pedidos, faremos com
que Cliente no tenha nenhum acoplamento com LinhaPedidos (Figura 8.12):
Cliente
1: criar
2: *[para cada linha] adiciona nova linha
2.1: *[para cada linha] attach
LinhaPedido
Pedido
Figura 8.12: Soluo 2

Fonte: Serafini (2008, p. 108)
Se a implementao da classe LinhaPedido sofrer alguma mudana, a nica

classe afetada vai ser a classe Pedido.
Todo acoplamento que existe nesse projeto foi identificado no modelo
conceitual:
97
e-Tec Brasil
a) Clientes possuem Pedidos;

b) Pedidos possuem LinhaPedidos.
E faz muito sentido a existncia desses acoplamentos.
Sntese:
Nome: LOW COUPLING
Problema: Como manter o acoplamento baixo?
Soluo: Faa uma anlise e procure reduzir o acoplamento ao mnimo
(LARMAN, 2007).
8.4.2 Grasp 5: Controller

Vamos examinar um Sistema de Apostas de Jogos e o caso de uso Fazer Apostas.
Para que o usurio possa fazer as apostas, precisamos que o sistema permita
entrar com as apostas e mostre os resultados dos jogos.
Como o usurio vai entrar com as apostas e como os resultados sero
mostrados?
Vamos examinar a responsabilidade de mostrar os resultados de uma partida
para o usurio: Que classe deve ser responsvel por satisfazer esse requisito?
A aplicao do padro Expert, sugere que, como os detalhes pertencem a
Partidas, ento a classe Partida deve ser a Expert em mostrar os detalhes
relevantes (Figura 8.13):
Partida
+mostraResultados()
Figura 8.13: Classe Partida
e-Tec Brasil
98
Anlise de Sistemas
Essa soluo pode parecer boa, mas na realidade ela viola o padro Expert!
A classe Partida deve ser especialista em todas as informaes sobre as Partidas, e no ter a responsabilidade de mostrar os resultados das partidas na
Interface Grfica (GUI).
Geralmente, a incluso de informaes sobre a GUI, Bases de Dados, (ou qualquer outro objeto fsico) em nossas classes resultar em um projeto pobre.
Imagine se tivssemos 100 classes em nosso sistema e muitas dessas classes
devessem ler e escrever na tela do computador. O que aconteceria se os
requisitos do sistema mudassem e fosse necessrio alterar toda a interface
com o usurio? Teramos que alterar cada classe envolvida com a interface
com o usurio.
Fica muito melhor manter todas as classes do modelo conceitual puras
chamamos essas classes de Classes de Negcio ou Business Classes.
O padro Controller uma soluo possvel. Criamos uma nova classe que
vai ficar entre o usurio e as classes de negcio. Essa classe funciona como
uma ponte (ou controlador) entre a Interface Grfica e as Classes do Domnio.
O nome dessa classe geralmente :
<nomeDoCasoDeUSo>Handler.
Ento, em nosso projeto, precisamos criar uma classe FazerApostasHandler
(Figura 8.14):
Partidas
FazerApostaHandler
Apostador
Aposta
Figura 8.14: Padro Controller

99
e-Tec Brasil
No caso de termos de alterar a interface com o usurio, a nica classe que

precisamos modificar a classe controladora.
Sntese:
Nome: Controller
Problema: Como manter a GUI separada das classes de negcio?
Soluo: Crie uma classe controladora para o sistema ou caso de uso.
(LARMAN, 2007)
e-Tec Brasil
100
Anlise de Sistemas
Resumo
Com o estudo dos padres apresentados nesta aula, aprendemos a definir responsabilidades a objetos dentro de nossos projetos que garantiro a melhoria
constante de nossos softwares. Os padres apresentam solues bem-sucedidas para vrios problemas que comumente os desenvolvedores encontram no momento de definirem seus objetos e sua interao com os demais.
Os padres propostos por Larman (2007) so conhecidos pelos desenvolvedores de todo o mundo e representam no meio profissional uma excelente soluo para situaes que enfrentamos no trabalho dirio de projetar sistemas.
Alm desses padres, outros tambm so conhecidos no mercado profissional: so os padres do GoF (Group of Four, na lngua portuguesa,
Grupo dos Quatro). So quatro autores de outros padres que atendem
tambm a outras classes de problemas de projeto, apresentando solues
muito interessantes para a construo de software de qualidade e efetividade. Seus padres so apresentados em Gamma et al. (2000).
1. Explique qual o tipo de problema que o padro Creator aborda e indique qual a soluo que ele prope.
2. Explique a diferena entre Responsabilidade e Colaborao. Cite um
exemplo de cada conceito.
3. Escolha um dos padres GRASP e desenhe um diagrama de classe (quatro classes no mnimo) representando uma soluo proposta por esse
padro escolhido.
4. Pesquise na internet a diferena entre os conceitos de Acoplamento e
Coeso, e indique se so relacionamentos indicados ou no para estarem
em nossos projetos de software.
Registre suas respostas num arquivo e poste-o no ambiente virtual.
101
e-Tec Brasil
Referncias
BERTALANFY, Ludwig Von. Teoria geral dos sistemas: fundamentos, desenvolvimento
e aplicaes. Trad. Francisco M. Guimares. 3. ed. Petrpolis: Vozes, 2008.
Diagramas de caso de uso. Disponvel em: <http://www.youtube.com/watch?v=fGAeF8HCjw&feature=related>. Acesso em: 19 set. 2011.
Diagrama de classes. Disponvel em: <http://www.youtube.com/watch?v=F4fRIvPuZU8>.
Acesso em: 19 set. 2011.
FRANCISCO FILHO, Egildo. Entrevistas: tcnicas e dinmicas de grupo. So Paulo:
Qualitymark, 2008.
FOWLER, Martin. UML essencial: um breve guia para a linguagem-padro. So Paulo:
Bookman, 2004.
GAMMA, Erich et al. Padres de projeto: solues reutilizveis de software orientado a
objetos. Trad. Luiz A. Meirelles Salgado. Porto Alegre: Bookman, 2000.
Introduo a UML 1a parte. Disponvel em: <http://www.youtube.com/watch?v=hf
N6n5fJfLc&feature=related>. Acesso em: 19 set. 2011.
LARMAN, Craig. Utilizando UML e padres: uma introduo anlise e ao projeto
orientados a objetos e ao desenvolvimento iterativo. Trad. Rosana Vaccare Braga et al. 3.
ed. Porto Alegre: Bookman, 2007.
MARTINELLI, D. P.; VENTURA, C. A. A. (Org.). Viso sistmica e administrao:
conceitos, metodologias e aplicaes. So Paulo: Saraiva, 2006.
SERAFINI, J. I. Anlise de sistemas. Serra: CEFETES, 2008.
SERAFINI, J. I.; CUNHA, L.E.C. Anlise e projeto de sistemas I. Serra: CEFETES, 2010.
THE STANDISH GROUP. Disponvel em: <http://standishgroup.com>. Acesso em: 19 set. 2011.
TEORIA geral dos sistemas. Disponvel em: <http://www.youtube.com/watch?v=d_
c8xvHtdHo>. Acesso em: 19 set. 2011.
TEORIA geral dos sistemas e tipologia dos sistemas de informao. Disponvel em <http://
www.youtube.com/watch?v=_EXOAh44oWg&feature=related>. Acesso em: 19 set. 2011b.
e-Tec Brasil
102
Anlise de Sistemas

Graduado em Processamento de Dados pela FAESA e especialista em Anlise de Sistemas e Avaliao pela Universidade de Braslia (UnB). Professor de
cursos superiores de Computao e Sistemas h mais de 15 anos, com concentrao de estudos nas reas de Sistemas de Informao e Engenharia de
Software. Trabalha desde 1982 com anlise, projeto e desenvolvimento
de sistemas. Na rea de educao superior, alm de atuar como professor
presencial e a distncia, atuou como coordenador de cursos e ncleos de
pesquisa e extenso universitria. Atua tambm como avaliador institucional
do Instituto Nacional de Ensino e Pesquisa Inep/MEC em processos de avaliao para fins de credenciamento e recredenciamento de instituies de
ensino presencial e a distncia em todo o Brasil.
Jos Incio Serafini
Engenheiro Civil formado pela Universidade Federal do Esprito Santo - UFES.
Fez sua ps-graduao em Anlise de Sistemas pela UFES. De 1980 a 2000,
trabalhou no Ncleo de Processamento de Dados da UFES, como estagirio,
programador de computadores e analista de sistemas. Desde 1993 professor da ETEFES/CEFETES/IFES da Coordenadoria de Informtica.
103
e-Tec Brasil
Anlise de Sistemas
Jos Incio Serafini
Tempo
Curso Tcnico de Informtica
Aplicao
Desktop
Completo
Anlise
Aplicao
Desktop
Projeto
Servidor
Teste
Implementao
Aplicao
Desktop
Camada
Cliente
Camada
Servidor

Análise de Sistemas - ETEC

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Análise de Sistemas - ETEC

Transféré par

Droits d'auteur :

Formats disponibles

Anlise de Sistemas

Luiz Egidio Costa Cunha

Curso Tcnico de Informtica

Presidncia da Repblica Federativa do Brasil

Instituto Federal do Esprito Santo

Coordenao de Design Grfico

C972a Cunha, Luiz Egidio Costa

Apresentao e-Tec Brasil

Saiba mais: oferece novas informaes que enriquecem o

Aula 1 Elementos da Teoria

Aula 2 O processo de desenvolvimento de software

2.2 Unified Modelling Language (UML)

2.3 Modelos de desenvolvimento de software

Aula 3 Os requisitos do sistema

3.2 Requisitos do sistema

3.3 Casos de uso

Aula 4 Descrio do comportamento do sistema

4.2 Diagrama de sequncia

4.3 Construo do diagrama de sequncia do sistema

4.4 Objetivos do DSS

Aula 5 Criao de um modelo do sistema

5.2 Modelo de domnio

5.4 Identificao de conceitos

5.6 Identificao de atributos

5.8 A UML e a representao do modelo de domnio

5.9 Representao de conceitos e atributos

5.10 Representao de associaes

5.11 O modelo conceitual

Aula 6 Arquitetura do sistema

6.2 Definies de arquitetura de software

6.3 Diviso de um sistema em camadas

6.4 Representao da arquitetura de software na UML

6.5 Tipos de arquiteturas de sistemas

6.6 Service oriented architecture (SOA) - Arquitetura

Aula 7 Diagrama de classes

7.3 Mapeamento objeto-relacional

Aula 8 Projeto de objetos

8.2 Responsabilidade e colaborao

8.3 Definio de padro

8.4 Os padres GRASP

Currculo dos professores-autores

Relacionar os conceitos da TGS com a

Caderno e Ambiente Virtual de

Caderno e Ambiente Virtual de

Conhecer o histrico do processo de

Conhecer os paradigmas de desenvolvimento de software mais utilizados.

Conhecer o que so os requisitos de um

Conhecer os elementos do Diagrama de

Caderno e Ambiente Virtual de

Caderno e Ambiente Virtual de

Usar os diagramas de interao da UML

Usar o Modelo de Domnio para delinear

Conhecer as principais arquiteturas

Escolher entre as arquiteturas a melhor

Caderno e Ambiente Virtual de

Conhecer os elementos do Diagrama de

Usar o Diagrama de Classes para a

Caderno e Ambiente Virtual de

Conhecer os padres de projeto GRASP.

Entender a aplicao dos padres de

Aula 1 Elementos da Teoria

1.1 Histrico da Teoria Geral dos Sistemas

Aula 1 Elementos da Teoria Geral dos Sistemas

1.1.1 Conceitos de sistema