291336131-Apostila-Analise-de-Sistemas.pdf

Técnico em Informática
Análise e Projetos de Sistemas
Instituto Federal de Educação, Ciências e Tecnologia de São Paulo - IFSP
Marilene Esquiavoni
2010
São João da Boa Vista - SP

Presidência da República Federativa do Brasil
Ministério da Educação
Secretaria de Educação a Distância
Equipe de Elaboração
IFSP
Coordenação Institucional
Campus São João da Boa Vista
Professor-autor
Marilene Esquiavoni
Comissão de Acompanhamento e Validação
Gustavo Aurélio Prieto
Yara Maria Guisso de Andrade Facchini
Projeto Gráfico
Eduardo Meneses e Fábio Brumana
Diagramação
Matheus Félix de Andrade”!
Revisão
Elizabeth Gouveia da Silva Vanni
Ficha catalográfica
Este Caderno foi elaborado em parceria entre o Instituto Federal de Educação, Ci-
ência e Tecnologia de São Paulo e o Sistema Escola Técnica Aberta do Brasil – e-Tec
Brasil.
Versão Preliminar

Amigo(a) estudante!
O Ministério da Educação vem desenvolvendo Políticas e Programas para
expansãoda Educação Básica e do Ensino Superior no País. Um dos caminhos
encontradospara que essa expansão se efetive com maior rapidez e eficiên-
cia é a modalidade adistância. No mundo inteiro são milhões os estudantes
que frequentam cursos a distância. Aqui no Brasil, são mais de 300 mil os
matriculados em cursos regulares de Ensino Médio e Superior a distância,
oferecidos por instituições públicas e privadas de ensino.
Em 2005, o MEC implantou o Sistema Universidade Aberta do Brasil (UAB),
hoje, consolidado como o maior programa nacional de formação de profes-
sores, em nível superior.
Para expansão e melhoria da educação profissional e fortalecimento do En-
sino Médio, o MEC está implementando o Programa Escola Técnica Aberta
do Brasil (e-TecBrasil). Espera, assim, oferecer aos jovens das periferias dos
grandes centros urbanose dos municípios do interior do País oportunidades
para maior escolaridade, melhorescondições de inserção no mundo do tra-
balho e, dessa forma, com elevado potencialpara o desenvolvimento produ-
tivo regional.
O e-Tec é resultado de uma parceria entre a Secretaria de Educação Pro-
fissionale Tecnológica (SETEC), a Secretaria de Educação a Distância (SED)
do Ministério daEducação, as universidades e escolas técnicas estaduais e
federais.
O Programa apóia a oferta de cursos técnicos de nível médio por parte das
escolaspúblicas de educação profissional federais, estaduais, municipais e,
por outro lado,a adequação da infra-estrutura de escolas públicas estaduais
e municipais.
Do primeiro Edital do e-Tec Brasil participaram 430 proponentes de ade-
quaçãode escolas e 74 instituições de ensino técnico, as quais propuseram
147 cursos técnicosde nível médio, abrangendo 14 áreas profissionais.
Apresentação e-Tec Brasil

O resultado desse Edital contemplou193 escolas em 20 unidades federa-
tivas. A perspectiva do Programa é que sejam ofertadas10.000 vagas, em
250 polos, até 2010.
Assim, a modalidade de Educação a Distância oferece nova interface para
amais expressiva expansão da rede federal de educação tecnológica dos úl-
timos anos: aconstrução dos novos centros federais (CEFETs), a organização
dos Institutos Federaisde Educação Tecnológica (IFETs) e de seus campi.
O Programa e-Tec Brasil vai sendo desenhado na construção coletiva e par-
ticipaçãoativa nas ações de democratização e expansão da educação profis-
sional no País,valendo-se dos pilares da educação a distância, sustentados
pela formação continuadade professores e pela utilização dos recursos tec-
nológicos disponíveis.
A equipe que coordena o Programa e-Tec Brasil lhe deseja sucesso na sua
formaçãoprofissional e na sua caminhada no curso a distância em que está
matriculado(a).
Brasília, Ministério da Educação – setembro de 2008.

Sumário
Apresentação e-Tec Brasil 3
Sumário 5
Palavra do professor-autor 7
Outros - instituição validadora 8
Apresentação da Disciplina 11
Capítulo 1 - Introdução a Projetos 14
1.1 Definições de Sistemas 15
1.2 Projetos WEB 15
1.2.1 Páginas 16
1.2.2 Site (sítio) 17
1.2.3 Portal 17
1.2.4 e-Business 18
1.2.5 e-Commerce 18
1.3 Entendendo o ciclo de Vida de um projeto 19
1.4 Modelo de ciclo de vida 20
1.4.1 Modelo de Cascata 20
1.4.2 Modelo em Espiral 21
1.4.3 Modelo Prototipagem 21
1.4.4 Modelo Incremental 22
1.4.5 Comparação dos Modelos 22
Hora de Praticar 23
Capítulo 2 - Linguagem de Modelagem Unificada 27
2.1 Características 28
2.1.1 Diagramas Utilizados 30
2.2 Orientação a Objetos 33
2.2.1 Classes 34
2.2.2 Atributos 34

2.2.2.1 Métodos 35
2.2.3 Herança 36
2.2.4 Polimorfismo 37
2.2.5 Encapsulamento 38
Hora de Praticar 39
Capítulo 3 - Diagrama de Casos 42
3.1 Atores 42
3.2 Casos de Uso 43
3.3 Documentação de Caso de Uso 43
3.4 Associação 44
3.5 Generalização 44
3.6 Inclusão 45
3.7 Extensão 46
3.8 Elementos comuns a todos os diagramas da UML 47
3.8.1 Notas 47
3.8.2 Pacotes 47
Hora de Praticar 49
Capítulo 4 - Diagrama de Atividades 52
4.1 Nós de Ação 52
4.2 Nó Inicial 53
4.3 Nó Final 53
4.4 Nó de Decisão 53
4.5 Exemplos de Diagrama de Atividade para consulta de
uma conta 54
Hora de Praticar 56
Capítulo 5 - Diagrama de Sequência 57
5.1 Atores 57
5.2 Objetos 58
5.3 Foco de Controle ou Ativação 58
5.4 Mensagem 59
5.5 Mensagens de retorno 60
5.6 Autochamadas ou Autodelegações 61
5.7 Condições de Guarda 62
5.8 Exemplo de Diagrama de Sequência 63
Hora de Praticar 64

Capítulo 6 - Diagrama de Classes 65
6.1 Relacionamentos 65
6.1.1 Associação Unitária ou Reflexiva 65
6.1.2 Associação Binária 66
6.1.3 Associação Ternária ou N-ária 67
6.1.4 Agregação 67
6.1.5 Composição 68
6.1.6 Especialização/Generalização 68
6.1.7 Dependência 69
6.1.8 Realização 69
6.2 Classe Associativa 70
6.3 Exemplo de Diagrama de Classes 70
Hora de Praticar 72
Referências 73
e-Tec Brasil
Análise e Projetos de Sistemas 7

Sou formada em Bacharelado em Computação pela
Universidade de Taubaté – UNITAU. Atualmente sou pro-
fessora de Informática do IFSP – Instituto Federal de Edu-
cação, Ciência e Tecnologia de São Paulo, Campus Cara-
guatatuba.
Proprietária intelectual de 19 softwares (conforme leis
9.609/98 e 9.610/98).
Dedico a maior parte do meu tempo aos cursos sobre
padrões de projeto, análise e projeto orientados a objetos e à construção de
softwares (Visual Studio 2008 – C#).
Recentemente realizei o treinamento de MCTS .NET Framework 2.0 Web
Applications onde estou me preparando para fazer a prova de Certificação
da Microsoft.
Atualmente estou escrevendo um livro para Editora LT – Livros Técnicos sobre
Hardware.
Palavra do professor-autor
e-Tec Brasil 8

O Decreto presidencial nº 7.566, de 23 de setembro de 1909, instituciona-
lizou o ensino profissional no Brasil. Em 1910 surgiu a Escola de Aprendizes
e Artífices de São Paulo, assemelhando-se a das criadas em outras capitais
de Estado. Ela se destinava inicialmente as camadas mais desfavorecidas, aos
“deserdados da fortuna e menores marginalizados”, ministrando o ensino
elementar. Em 1937 passou a denominar-se Liceu Industrial de São Paulo,
oferecendo ensino equivalente ao de primeiro ciclo.
Em 1942 foi promulgada a Lei orgânica do ensino industrial. A nova
orientação visava à preparação profissional dos trabalhadores da indústria,
dos transportes, das comunicações e da pesca.
Em 1976, procedeu-se à mudança para a nova sede e, em 1978,
criaram-se os cursos de eletrônica, telecomunicações e processamento de
dados. Em 1981, instalam-se os cursos complementares de mecânica, eletro-
técnica e edificações, destinados à clientela, em grande parte integrada ao
mercado de trabalho, mais que necessitava de uma formalização profissional
por meio de disciplinas de nível técnico de 2º grau. Estes cursos técnicos
tinham a duração de dois anos, prevendo um estágio obrigatório.
No ano de 1987 foi implantada a primeira Unidade de Ensino Des-
centralizada (UNED) no Município de Cubatão e, em 1996, ocorreu o início
do funcionamento da UNED Sertãozinho. Em 1999, a Escola Técnica Federal
de São Paulo, foi transformada em Centro Federal de Educação Tecnológica
de São Paulo – CEFET, conforme Decreto de 18 de janeiro de 1999. No ano
de 2005, foi autorizado o funcionamento da UNED Guarulhos. As UNED
de São João da Boa Vista e Caraguatatuba foram autorizadas a funcionar a
partir do 1º semestre do ano de 2007, enquanto que as UNED de Bragança
e Salto passaram a funcionar no 2º semestre do ano de 2007.
Em 2008 foram criadas as unidades de São Carlos, São Roque e
Campos do Jordão. No mesmo ano o CEFET-SP se transformou no Instituto
Federal de Educação Ciência e Tecnologia pela Lei 11.892 de 29 de Dezem-
bro de 2008, que instituiu a rede federal de educação profissional, científica
e tecnológica. De acordo com esta lei os institutos federais (IF) tornaram-se
Outros - instituição validadora
e-Tec Brasil

instituições de educação superior, básica e profissional, pluricurriculares e
multicampi, especializados na oferta de educação profissional e tecnológica
nas diferentes modalidades de ensino, com base na conjugação de conheci-
mentos técnicos e tecnológicos com as suas práticas pedagógicas.
A expansão do CEFET-SP tem ainda previstas os Campus de Arara-
quara, Avaré, Barretos, Birigui, Campinas, Catanduva, Itapetininga, Piracica-
ba, , Presidente Epitácio, Registro, Suzano e Votuporanga.
A Unidade de Ensino Descentralizada de São João da Boa Vista é
uma unidade educacional subordinada ao Centro Federal de Educação Tec-
nológica de São Paulo, autorizada pela Portaria nº 1715 do Ministro da Edu-
cação, publicada no Diário Oficial da União de 20/10/2006. Tem estrutura
administrativa definida pela resolução nº 136/06 de 16/11/2006 do Conse-
lho Diretor do CEFET-SP.
A história do campus se inicia no ano de 1998 quando é formulado o
projeto para a criação do CEPRO em São João da Boa Vista. No ano seguinte
o anteprojeto é aprovado pelo Programa de Expansão da Educação Profis-
sional (PROEP). No mesmo ano se dá o início das obras para construção do
prédio em terreno doado por Paulo Roberto Merlin e Flávio Augusto Canto.
Em 2004, o prédio é entregue com 2529m², sendo constituído de onze
laboratórios, seis salas de aulas, um auditório com capacidade para 150 lu-
gares, sala de multimídia e demais dependências. As atividades do Centro de
Educação Profissional são iniciadas em 2005. Em 2006 é firmado o convênio
entre o CEPRO e CEFET-SP, com apoio da prefeitura municipal para a federa-
lização da unidade. Em Janeiro de 2007 o CEFET-SP / UNED SBV iniciou suas
atividades no município.
O IFSP, no município de São João da Boa Vista, veio para atender
a necessidade de educar os jovens são joanenses e da região, a fim de ha-
bilitá-los para o ingresso nos setores de indústria e informática, os quais
demandam trabalhadores capacitados para o progresso no desenvolvimento
econômico e para o fortalecimento do pólo educacional na região leste do
estado.
Atuação do IFSP na Educação a Distância
No contexto da política de expansão da educação superior no país,
implementada pelo MEC, a EaD coloca-se como uma modalidade im-
e-Tec Brasil 10

portante no seu desenvolvimento. Nesse sentido, criou-se uma direção para
EaD dentro do IF SP.
No âmbito da política de expansão da educação profissionalizante, o
Ministério da Educação, por meio da articulação da Secretaria de Educação
a Distância e Secretaria de Educação Profissional e Tecnológica, lança o Edital
01/2007/SEED/SETEC/MEC, dispondo sobre o Programa Escola Técnica Aber-
ta do Brasil (e-Tec Brasil).
Tal iniciativa constitui-se uma das ações do Plano de Desenvolvimen-
to da Educação.
Visando oferta de cursos da educação técnica e profissional o IF SP
foi selecionado pelo programa e-Tec Brasil para iniciar suas atividades em
2009.
Tais atividades foram efetivamente implantadas em agosto de 2009
com a criação de dois cursos técnicos – a saber: técnico em informática para
internet e técnico em administração – atingindo 5 municípios do estado de
São Paulo (Araraquara, Barretos, Itapevi, Franca e Jaboticabal) e ampliando
em 500 a oferta de vagas do Instituto.
e-Tec Brasil

Apresentação da Disciplina
Em decorrência da necessidade de padronização das técnicas de modelagem
de software para o modelo Orientado a Objetos, a Rational Software Cor-
poration buscou unificar as principais técnicas existentes e aceitas mundial-
mente, visando a criação de uma única técnica, a UML – Unified Modeling
Language como técnica padrão de modelagem, existe hoje, uma grande
procura no mercado por profissionais que dominem esta técnica.
As empresas exigem sistemas que não só atendam as necessidades
funcionais, como sejam de fácil manutenção.
O objetivo deste curso é fornecer ao aluno, uma visão clara de mo-
delagem, conceitos da Orientação a Objetos, descrição dos Diagramas utili-
zados para o projeto de sistemas e a aplicação desses conceitos em estudos
de casos utilizando a ferramenta JUDE, que oferece uma versão para a co-
munidade.
Apesar de a UML possuir um grande número de diagramas, você não
deverá se sentir obrigado a utilizar todos eles, pois cada um possui uma ca-
racterística específica e, algumas vezes, alguns deles não são necessários em
determinados sistemas. Cabe a você determinar quais serão necessários!
Embora tenha adotado a ferramenta JUDE, você poderá optar por
qualquer outra ferramenta CASE (Computer – Aided Software Engineering
ou Engenharia de Software Auxiliada por Computador). Essas ferramentas
são softwares que auxiliam na execução de uma ou mais atividades realiza-
das durante o processo de Engenharia de Software. Entre as diversas ferra-
mentas existentes no mercado podemos citar:
• Rational Rose – É totalmente orientada à UML, é uma das ferra-
mentas mais completas disponíveis no mercado. Inclusive foi a empresa que
incentivou a criação da UML e a primeira a lançar uma ferramenta CASE
baseada nesta linguagem.
• Visual Paradigma for UML ou VP-UML – Essa ferramenta ofe-
rece uma versão para a comunidade, ou seja, que poderá ser baixada gra-
e-Tec Brasil 12

tuitamente de sua página. Logicamente, esta versão não suporta todas as
opções disponíveis da versão Standard ou Professional.
• Poseidon for UML – Também apresenta uma versão para a comu-
nidade.
• Enterprise Architect – Essa ferramenta não possui versão gra-
tuita, e é uma das que mais oferecem recursos compatíveis com a UML. A
empresa apenas dispõe de uma versão Trial, que poderá ser utilizada por
cerca de 60 dias.
Obrigada, espero que você goste deste curso. Bom estudo!
e-Tec Brasil

Um projeto consiste num esforço temporário com um objetivo pré-
estabelecido, seja para criar um novo produto, serviço ou processo. Tem iní-
cio, meio e fim bem definidos, duração e recursos limitados, numa sequencia
de atividades relacionadas.
Por exemplo, criar um sítio novo, ou redesenhar um sítio já existente,
é um PROJETO, já atualizar um sítio é um processo operacional permanente,
não é um projeto. O resultado de um projeto é sempre diferente de outros
produtos e serviços existentes.
- Pode ser um produto tangível: Um livro, uma exposição, um au-
tomóvel.
- Produto intangível: Um conjunto de processos desenhados para
a venda online de livros usados.
Capítulo 1
Introdução a Projetos
Objetivos da aula
- Compreender o Conceito de Projeto de Software aplicado à
WEB.
- Ciclo de Vida dos sistemas e diferentes modelos
e-Tec Brasil 14

1.1 Definições de Sistema
Sistema consiste em um número de elementos, concretos ou não
que interagem entre si e com o ambiente como uma unidade de trabalho.
Pode ser grande e complexo ou relativamente pequeno e simples.
Um sistema fica inteiramente definido quando se conhecem:
- Seus objetivos;
- Seus limites;
- Seu funcionamento interno.
1.2 Projetos Web
O planejamento e o estabelecimento de metodologias para a gestão
de projeto de um web site são necessários para:
- Estabelecer uma visão comum sobre os objetivos do site e divulgar
esta visão a todos os organizadores de modo geral, para que sirvam de refe-
rência aos processos de trabalho.
- Facilitar os processos de decisão, estabelecer as funções e respon-
sabilidades de cada um dos participantes da equipe.
- Dimensionar corretamente o orçamento.
- Monitorar os processos, a equipe, os custos e os prazos.
e-Tec Brasil

- Contratar serviços e adquirir equipamentos, sistemas, programas e
materiais, se necessário.
- Fazer o controle da qualidade dos produtos e reduzir o impacto dos
seus riscos.
- Controlar e documentar periodicamente a aderência do projeto ao
seu escopo e aos seus objetivos.
- Manter o comprometimento dos patrocinadores com os resulta-
dos.
- Reforçar continuamente a importância dos processos e da revisão
dos processos de gestão de projetos.
1.2.1 Páginas
As páginas são documentos de hipertexto, ou seja, possibilita a na-
vegação entre segmentos de texto, o usuário salta de uma informação a
outra, não necessariamente numa ordem sequencial. Elas estão gravadas em
servidores da Internet podendo ser acessadas em qualquer parte do mundo.
Uma página WEB também pode ser chamada de home Page (página princi-
pal). Ao iniciar o browser (navegador), será carregada uma página definida
na configuração do programa como página inicial.
Figura 1: Página Figura 2: Página
e-Tec Brasil 16

1.2.2 Site (sítio)
É um conjunto de páginas harmonicamente interligadas, com base
num endereço-base (URL) único, que podem ser acessadas através de um
browser.
1.2.3 Portal
São (sítios) na Internet que servem como ponto de partida para ou-
tros sites ou páginas da Web.
O portal globo.com, por exemplo, permite que o usuário encontre,
em uma mesma página, acesso a e-mail, vídeos, notícias, entretenimento,
esportes, downloads, jogos, rádios, blogs, fotologs, sites de humor e infor-
mações sobre programação de TVs, entre outros serviços e conteúdos.
A principal função dos portais é conectar pessoas e informações,
com capacidade de processamento de diversas origens no mesmo ambien-
te.
e-Tec Brasil

1.2.4 e-Business
De modo geral, a expressão “negócios eletrônicos” se refere à reali-
zação de processos comerciais pela Internet. Mais abrangente que “comércio
eletrônico”, a expressão inclui o relacionamento entre parceiros comerciais,
fornecedores, distribuidores, bem como a prestação de serviços a clientes,
a participação em pesquisas, o desenvolvimento de produtos, as transações
comerciais automatizadas.
1.2.5 e-Commerce
O comércio eletrônico consiste na integração das tecnologias da In-
ternet com processos comerciais (verificação de negociações, produção e
distribuição), para facilitar trocas de produtos, de serviços, capitais, informa-
ções e conhecimento.
e-Tec Brasil 18

1.3 Entendendo o ciclo de vida de um
projeto
Preparação: Nesta fase define-se o objetivo do projeto com base nas
expectativas e se preparam planos preliminares do projeto. Definição
do problema.
Estruturação: Fase onde se domina o detalhamento dos planos ope-
racionais, organização da equipe e recursos do projeto.
Desenvolvimento: Fase em que os planos são colocados em práti-
ca.
Encerramento: Final do projeto. Neste ponto o projeto deve atingir o
resultado esperado ou previsto. Deve incluir implantações de soluções,
manutenção, treinamento.
e-Tec Brasil

1.4 Modelo de ciclo de Vida
Os modelos existentes possuem diferentes graus de complexidade
e sofisticação. Para se desenvolver um projeto simples, com poucas pessoas
envolvidas, o mais adequado seria um processo simples. Agora, se formos
desenvolver um projeto sofisticado, com um grande número de pessoas en-
volvidas, milhares de usuários, um processo simples não seria o mais adequa-
do, teríamos algo mais formal e disciplinado.
1.4.1 Modelo de Cascata
É o modelo mais antigo, sendo o primeiro a ser conhecido na enge-
nharia de software, e continua sendo implantado até hoje.
Trata-se de um modelo sequencial, onde cada passo deve ser com-
pletado antes que o próximo seja iniciado. Os nomes de cada passo variam,
mas basicamente inicia-se com a análise de requisitos, seguindo para a fase
de desenho, codificação, implementação, testes e manutenção. Um proble-
ma neste modelo é quanto aos requisitos, por ser uma única etapa e estes
mudarem constantemente. Foi verificada então a necessidade de dar uma
realimentação aos requistos.
1.4.2 Modelo em Espiral
É uma variação do modelo de Cascata. Quem introduziu este mo-
delo foi Barry Boehm em 1988. A imagem do modelo é de uma espiral
que começa no meio e continuamente revisa as tarefas básicas do usuário:
comunicação, planejamento, análise de risco, engenharia, construção e im-
plantação, e avaliação do usuário.
Figura 13: Modelo Cascata
e-Tec Brasil 20

1.4.3 Modelo Prototipagem
Esse modelo constrói uma versão descartável, ou seja, um protótipo.
Esse protótipo vai testar conceitos e requistos e será usado para demonstrar
o comportamento aos clientes. Após a concordância dos clientes, o software
é desenvolvido seguindo as mesmas fases do modelo de Cascata. O esforço
despendido no protótipo geralmente é compensado pelo não desenvolvi-
mento de características desnecessárias.
1.4.4 Modelo Incremental
O objetivo era projetar e entregar ao cliente um conjunto mínimo do
sistema que continuasse a ser um sistema usável. O processo continuará a in-
Figura 14: Modelo Espiral
Figura 15: Modelo Prototipagem
e-Tec Brasil

teragir ao longo de todo o ciclo e vida com incrementos adicionais mínimos.
As vantagens incluem fornecer logo ao cliente um sistema e novas versões
de trabalho.
1.4.5 Comparação dos modelos
Figura 16: Modelo Incremental
e-Tec Brasil 22

Hora de Praticar!
1. Por que eu preciso fazer um projeto para meu sítio?
________________________________________________________________
________________________________________________________________
________________________________________________________________
________________________________________________________________
2. Qual (is) a(s) diferença(s) entre sítios e portais?
________________________________________________________________
________________________________________________________________
________________________________________________________________
________________________________________________________________
3. Você foi contratado para atualizar um sítio, você necessita de um
projeto? Explique.
________________________________________________________________
________________________________________________________________
________________________________________________________________
________________________________________________________________
4. Quais as diferenças entre e-commerce e e-business? Cite exemplos
de cada um deles.
________________________________________________________________
________________________________________________________________
________________________________________________________________
________________________________________________________________
e-Tec Brasil

5. Como um modelo de ciclo de vida de fases contempla o gerencia-
mento de software?
________________________________________________________________
________________________________________________________________
________________________________________________________________
________________________________________________________________
6. O que é um projeto?
________________________________________________________________
________________________________________________________________
________________________________________________________________
________________________________________________________________
7. Cite, pelo menos, três tipos de projetos.
________________________________________________________________
________________________________________________________________
________________________________________________________________
________________________________________________________________
8. Para cada um dos seguintes documentos, indique a(s) fase(s) do ciclo
de vida do software em que são desenvolvidos:
a. Manual final do usuário
b. Projeto arquitetural
c. Especificação de módulos
d. Código fonte
e. Plano de teste
e-Tec Brasil 24

f. Manual de usuário preliminar
g. Projeto detalhado
h. Estimativa de custo
i. Plano de projeto
j. Relatório de teste
k. Documentação
9. Ordene as seguintes tarefas em termos do modelo cascata:
a. Teste de aceitação
b. Planejamento do projeto
c. Teste de unidade
d. Revisão dos requisitos
e. Estimativa de custos
f. Projeto em alto nível
g. Projeto em baixo nível
h. Teste de sistema
i. Revisão do projeto
j. Implantação
k. Especificação de requisitos
l. Análise de mercado
e-Tec Brasil

10. Explique em detalhes o ciclo de vida de um projeto.
________________________________________________________________
________________________________________________________________
________________________________________________________________
________________________________________________________________
e-Tec Brasil 26

Histórico da UML
A UML começou a ser definida a partir de uma tentativa de Jim Rum-
baugh e Grady Booch de combinar dois métodos populares de modelagem
orientada a objeto: Booch e OMT (Object Modeling Language). Mais tarde,
Ivar Jacobson, o criador do método Objectory, uniu-se aos dois, para a con-
cepção da primeira versão do método UML (Unified Modeling Language).
Capítulo 2
UML – Linguagem de Modelagem
Unificada
Objetivos da aula
- Compreender os conceitos básicos da UML.
- Assimilar o paradigma da orientação à objetos.
Figura 17: UML
e-Tec Brasil

2.1 Características
A UML não é uma linguagem de programação e sim uma linguagem
de modelagem de sistemas computacionais por meio da orientação a obje-
tos. Pode ser empregada para visualizar, especificar, construir e documentar
os artefatos de sistemas de software.
Os objetivos da UML são:
- Descrever qualquer tipo de sistema através dos diagramas orienta-
dos a objetos;
- Estabelecer uma união fazendo com que métodos conceituais se-
jam também executáveis;
- Criar uma linguagem de modelagem usável tanto pelo homem
quanto pela máquina.
A UML abrange todas as fases do sistema, desde a fase de especifi-
cação de requisitos até a fase de testes.
Vamos lá: Imagine que você vai construir uma casa sem uma planta,
simplesmente com as ideias da sua cabeça. Posso dizer que é impossível não
é? Obviamente, você deverá ter um projeto muito bem elaborado, com os
cálculos precisos, estimativas de custos, prazos, quantidade de material, etc.
Afinal você é o responsável pela obra, e qualquer problema você terá que
arcar com as consequências não é mesmo?
e-Tec Brasil 28

Com isso posso dizer que é impossível desenvolver um sistema sem
antes sabermos sua arquitetura.
Existem 05 fases para o desenvolvimento da UML:
1. Análise de Requisitos: Você terá que entender o funcionamento
do sistema e para isso deverá realizar várias entrevistas com seu cliente para
coletar essas informações.
2. Análise: Agora você terá que analisar todos os dados levantados.
Saber se as necessidades do seu cliente foram na realidade bem compre-
endidas. Caso contrário, poderá ocorrer de ter que modelar novamente o
sistema já em andamento, e até mesmo, em alguns casos, partir do zero.
Com isso, já teve sérios problemas quanto ao prazo estipulado.
3. Projeto: Consiste em desenvolver um “rascunho” do que seria seu
sistema. Hoje em dia é muito mais fácil desenvolver protótipos utilizando as
linguagens de programação visual como Visual Studio. Com isso você apre-
sentará o seu protótipo ao seu cliente para que ele tenha uma visão geral do
funcionamento do sistema e verifique se está de acordo com as expectati-
vas.
4. Programação: é nesta fase que você deverá escolher qual lingua-
gem irá utilizar e transformar seu protótipo em código.
5. Testes: Agora, você terá que testar seu sistema inúmeras vezes para
ver se ele está em total funcionamento. Por fim, apresentará ao seu cliente
para que ele realize os últimos testes e diga se está em perfeito funciona-
mento.
e-Tec Brasil

2.1.1 Diagramas Utilizados
O objetivo era projetar e entregar ao cliente um conjunto mínimo do
sistema que continuasse a ser um sistema usável. O processo continuará a in-
teragir ao longo de todo o ciclo e vida com incrementos adicionais mínimos.
As vantagens incluem fornecer logo ao cliente um sistema e novas versões
de trabalho.
Descreverei agora de forma resumida, todos os diagramas da UML
versão 2.0. Depois iremos ver com detalhes os quatro diagramas mais utili-
zado na UML (Caso de Uso, Classes, Atividades e Sequencia).
• Diagrama de Caso de Uso
Representam as funções do sistema do ponto de vista do usuário.
São representados através de atores e casos de uso. Sua representação deve
deixar bem transparente a ideia do sistema.
• Diagrama de Classes
É o mais importante da UML, serve de apoio para a maioria dos
diagramas. Esse diagrama define a estrutura das classes de um sistema, de-
Figura 18: Diagrama UML
30

terminando os atributos e métodos pertencentes a cada classe, além de es-
tabelecer como as classes se relacionam e trocam informações entre si.
• Diagrama de Atividades
Esse diagrama preocupa-se em descrever os passos a serem percorri-
dos para a conclusão de uma atividade específica.
• Diagrama de Sequencia
O diagrama de Sequencia é a troca de mensagens entre os objetos
de um determinado processo.
• Diagrama de Objetos
Ele é um complemento do diagrama de Classes. Nos mostra os valo-
res armazenados pelos objetos de um diagrama de Classes na execução de
um determinado processo.
• Diagrama de Estrutura Composta
É utilizado para descrever a colaboração interna das classes, interfa-
ces ou componentes para especificar uma funcionalidade.
• Diagrama de Comunicação
Na versão anterior da UML era chamado de Diagrama de Colabo-
ração, e a partir da versão 2.0 passou a ser Diagrama de Comunicação. Ele
está associado ao diagrama de Sequência, na realidade, um complementa o
outro. Tem um enfoque com a temporalidade do processo.
e-Tec Brasil

• Diagrama de Máquina de Estados
Na versão anterior da UML era chamado de Diagrama de Gráfico de
Estados. Ele é voltado em acompanhar as mudanças sofridas nos estados
de uma instância de uma classe, de um Caso de Uso ou até mesmo de um
sistema completo.
• Diagrama de Componentes
Ele está associado à linguagem de programação escolhida para o
desenvolvimento do sistema modelado. Pode ser utilizado para modelar o
código-fonte, a estrutura física de Banco de Dados, até mesmo as interfa-
ces.
• Diagrama de Implantação
Esse Diagrama determina as necessidades de hardware do sistema,
as características físicas como servidores, estações, topologias e protocolos
de comunicação, ou seja, toda a parte física onde o sistema será executa-
do.
• Diagrama de Pacotes
Representa os subsistemas ou submódulos de um sistema determi-
nando as partes que o contém.
• Diagrama de Interação Geral
É uma variação do Diagrama de Atividade. Esse diagrama passou a
existir a partir da UML 2.0. Ele engloba diversos tipos de diagramas de inte-
ração para demonstrar um processo geral.
• Diagrama de Tempo
É utilizado para demonstrar a mudança no estado de um objeto no
tempo em resposta a eventos externos.
2.2. Orientação a Objetos
Antes de começarmos a desenvolver um sistema orientado a obje-
32

tos, é necessário “pensar orientado a objetos”! Mas o que é isso??
Um objeto é uma instância (criação) de uma classe. É uma abstração
de “coisas” do mundo real, como pessoas, animais, carros, etc. Esses objetos
possuem características (atributos), como andar, falar, altura, peso, raça, cor,
marca, etc.
Mas o que é abstração? Segundo o dicionário é o “ato de separar
mentalmente um ou mais elementos de uma totalidade complexa (coisa,
representação, fato), os quais só mentalmente podem subsistir fora dessa
totalidade; o resultado de abstrações (termo, conceito, ideia, elemento da
classe, etc.)”. Traduzindo para o nosso “mundo programático” significa ex-
trair as ideias mais importantes de um objeto, descartando o restante.
Quando instanciamos um objeto, ele adquire um espaço em memó-
ria para armazenar seu estado (valores de seus atributos) e um conjunto de
operações que podem ser aplicadas ao objeto.
2.2.1 Classes
São categorias, e os objetos são membros ou exemplos dessa cate-
goria. São formadas basicamente por métodos e atributos. Por exemplo:
Figura 19: Objetos do Mundo Real
e-Tec Brasil

A classe é representada por um retângulo que pode ter até três di-
visões. A primeira armazena o nome da classe, a segunda os atributos per-
tencentes à classe e a terceira os métodos que a classe possui. Veja um
exemplo:
2.2.2 Atributos
Representam as características de uma classe. Também são conhe-
cidas como propriedades. Essas características nos permitem diferenciar um
objeto de outro da mesma classe devido tais variações. Por exemplo:
• Atributos de uma Classe Pessoa:
- Nome da pessoa;
e-Tec Brasil 34

- Altura da pessoa;
- Peso da pessoa.
Os atributos possuem algumas características importantes, como vi-
sibilidade, nome, tipo de dado e valor inicial. A visibilidade de um atributo
pode ser:
• Pública: É representada pelo sinal de adição (+), apresentado na
frente do nome do atributo ou método e significa que o atributo é acessível
(“enxergado”) por outras classes.
• Privado: É representada pelo símbolo de subtração (-) e significa
que o atributo é acessível apenas pela própria classe.
• Protegida: É representada pelo símbolo sustenido (#) e significa
que o atributo é acessível somente pela própria classe e suas subclasses.
O tipo de dado e o valor inicial dependem da linguagem de programação
utilizada no modelo. O valor inicial refere-se a um valor definido automatica-
mente quando o objeto for iniciado (criado). Veja a representação na figura
16.
2.2.2.1 Métodos
São os comportamentos ou ações que um objeto de uma classe pode
executar. Assim, os métodos são conjuntos de instruções que são executadas
quando o método é chamado.
Exemplo:
Um método pode ou não receber parâmetros (valores que são uti-
lizados durante a execução do método) e, em geral, pode ou não retornar
valores. Esses parâmetros são colocados entre os “parênteses” do método.
e-Tec Brasil

Um método possui como características: visibilidade, nome, lista de
parâmetros e tipo de retorno. O tipo de argumentos e de retorno depende
da linguagem de programação adotada.
2.2.3 Herança
É uma característica poderosa na orientação a objetos. Com ela você
pode reaproveitar os atributos e métodos existentes em uma classe, redu-
zindo o tempo de desenvolvimento, além de reduzir também as linhas de
código e facilitar futuras manutenções.
Vamos fazer um exemplo:
Digamos que você queira desenvolver um sistema de Transportes.
Primeiramente você criaria uma superclasse ou classe mãe chamada de “Vei-
culo”, por exemplo, e nela definiria todos os atributos e métodos comuns
aos demais veículos. Depois criaria as subclasses ou classes filhas ou deriva-
das, como “Ônibus”, “Carro”, “Caminhão”, e em cada uma delas você de-
finiria os atributos e métodos específicos de cada classe. Portanto, com isso,
você não necessita repetir código quando programar as classes derivadas,
pois elas estariam herdando todas as características definidas na superclasse.
Exemplo:
e-Tec Brasil 36

2.2.4 Polimorfismo
É a capacidade de objetos diferentes possuírem operações com o
mesmo nome e a mesma lista de argumentos, mas que executam tarefas de
formas diferentes.
Exemplo:
O método acelerar da classe Veículo poderá ser chamado pela classe
Carro, como também por outra classe Bicicleta. As duas classes aceleram,
mas de maneira diferente, pois o carro depende do motor para acelerar e a
bicicleta depende dos pedais.
Sobrecarga de Métodos
É quando você tem uma ação que pode ter diferentes dados de en-
trada, mas com um mesmo resultado. Para solucionar esse problema na
orientação a objetos, você poderá criar vários métodos com o mesmo nome
que executam a mesma ação, cada um possuindo um tipo de dado de en-
trada diferente, mas fornecendo a mesma reposta. Isso também pode ser
considerado Polimorfismo.
Exemplo:
O método soma que poderia estar utilizando variáveis inteiras ou re-
Figura 22: Representação da Herança
e-Tec Brasil

ais, e retorna como resultado a soma dos dois números fornecidos na forma
de um número real. Vejamos como ficaria isso na forma de pseudocódigo:
Alguns autores trabalham com a possibilidade dos métodos sobre-
carregados possuírem tipos de dados de retorno diferentes, referenciando-
os como falso-polimorfismo.
2.2.5 Encapsulamento
É o ato de “esconder” informações, ou seja, determinados detalhes
ficam ocultos aos demais e dizem respeito apenas ao próprio objeto. Por
exemplo:
No exemplo Veículo, como funciona o método aceleração não nos
diz respeito. Não interessa ao motorista como é o funcionamento interno
do motor, isso é responsabilidade do projetista do veículo. O motor de um
carro 0 km é certamente bastante diferente do motor do carro fabricado 30
anos atrás. Mas não precisamos reaprender a dirigir por causa disso, pois a
aceleração continua a mesma.
A grande vantagem do encapsulamento é o isolamento dos dados.
Vamos usar como exemplo uma classe Pessoa, onde qualquer aplicação po-
derá usar a classe para instanciar (criar) objetos, mas jamais terá acesso à
forma de como é definido o nome da pessoa por exemplo.
e-Tec Brasil 38

Hora de Praticar!
1. O que é UML? Qual a sua finalidade?
________________________________________________________________
________________________________________________________________
________________________________________________________________
________________________________________________________________
2. Quais são as fases do desenvolvimento da UML? Explique cada uma
delas.
________________________________________________________________
________________________________________________________________
________________________________________________________________
________________________________________________________________
3. Explique o porquê da necessidade de se modelar um sistema.
________________________________________________________________
________________________________________________________________
________________________________________________________________
________________________________________________________________
4. Existem no total, treze diagramas da UML, eu preciso utilizar todos
eles para modelar um sistema? Explique.
________________________________________________________________
________________________________________________________________
________________________________________________________________
________________________________________________________________
e-Tec Brasil

5. Diferencie Classe e Objeto.
________________________________________________________________
________________________________________________________________
________________________________________________________________
________________________________________________________________
6. Quais são os componentes de uma classe? Explique cada um deles.
________________________________________________________________
________________________________________________________________
________________________________________________________________
________________________________________________________________
7. O que torna uma linguagem de programação Orientada a Objetos?
________________________________________________________________
________________________________________________________________
________________________________________________________________
________________________________________________________________
8. Quais as vantagens de utilizar Herança?
________________________________________________________________
________________________________________________________________
________________________________________________________________
________________________________________________________________
e-Tec Brasil 40

9. Quais as vantagens do Encapsulamento?
________________________________________________________________
________________________________________________________________
________________________________________________________________
________________________________________________________________
10. Defina Sobrecarga de Métodos.
________________________________________________________________
________________________________________________________________
________________________________________________________________
________________________________________________________________
e-Tec Brasil

No capítulo anterior vimos que o Diagrama de Caso de Uso é visto
sob a perspectiva do usuário. Essencial para análise, implementação, testes
e plano do desenvolvimento do sistema. Por isso, veremos esse diagrama de
forma detalhada.
Os diagramas de Casos de Uso concentram-se em dois itens princi-
pais: Atores e Casos de Uso.
3.1 Atores
Os atores representam os papéis desempenhados pelos diversos usu-
ários que poderão utilizar o sistema, podendo também representar um har-
dware e até mesmo outro software.
São representados através de “bonecos”, contendo uma breve des-
crição do seu significado abaixo do seu símbolo.
Capítulo 3
Diagrama de Caso de Uso
Objetivos da aula
- Compreender os componentes e a utilização dos casos de
uso.
Figura 23: Modelo de Atores
e-Tec Brasil 42

3.2 Casos de Uso
Representam as tarefas, serviços ou funções que podem ser utili-
zados pelos usuários do sistema, como emitir um relatório ou cadastrar a
venda de um produto.
Podemos associar também um caso de uso com uma tela do sistema,
mas isso não é uma regra, podendo também abranger várias telas de um
sistema, como até mesmo um botão.
São representados por uma elipse, contendo dentro dela um texto
com sua descrição do tipo de serviço a que se refere.
3.3 Documentação de Casos de Uso
Através de uma linguagem bem informal, descrevemos a interação
dos autores, as funções dos casos de uso, quais etapas são executadas pelo
autor e pelo sistema para que o caso de uso execute sua função.
Não existe um formato específico para essa documentação, sendo
bastante flexível, fazendo com que usuários leigos consigam entender o fun-
cionamento do sistema.
Um exemplo de documentação do Caso de Uso Devolução de Livros
(sistema de Biblioteca):
Figura 24: Exemplo de Caso de Uso
e-Tec Brasil

3.4 Associação
Casos de uso e atores interagem entre si enviando sinais um ao ou-
tro, indicamos isso num diagrama através de associações. Uma associação
serve para mostrar quais atores se comunicam com o caso de uso.
A associação entre um Ator e um Caso de Uso é representada por
uma reta ligando o Autor ao Caso de Uso. Essa associação tem uma proprie-
dade de navegabilidade, ou seja, o sentido que as informações trafegam. Se
por exemplo for representado apenas por uma reta, significa que o tráfego
de informações é dos dois lados, bidirecional. Se for representado por uma
seta, e ela apontar para o autor, significa que o autor inicia a interação; se
ela apontar para o caso de uso, significa que ele inicia a interação.
Figura 25: Associação
e-Tec Brasil 44

3.5 Generalização - Especialização
É quando existe uma associação entre dois ou mais atores ou dois ou
mais casos de uso.
Num processo de identificação dos atores, por abstração, você des-
cobre que um ator pode exercer vários papéis em relação ao sistema. Assim,
você poderá representar um ator que herda vários autores. O mesmo ocorre
aos casos de uso.
Observando a Figura 26, podemos dizer que o ator “Física” é uma
especialização de “Pessoa”, bem como, “Pessoa” é uma generalização de
“Jurídica”. O mesmo raciocínio se aplica aos casos, da Figura 27, podemos
dizer que “Conta Especial” é uma especialização de “Conta”, e “Conta” é
uma generalização de “Conta Especial” e de “Conta Comum”.
Figura 26: Exemplo de Especialização entre autores
Figura 27: Exemplo de Especialização entre Casos de Uso
e-Tec Brasil

3.6 Inclusão
Os relacionamentos de inclusão ocorrem quando existe um serviço,
situação comum a mais de um caso de uso. Indicam uma obrigatoriedade,
ou seja, a execução do primeiro obriga também a execução do segundo.
É representada por uma seta tracejada com uma seta em uma das
suas extremidades, apontando para o caso incluído. Além disso, costumam
apresentar um Estereótipo (destaque) que contém o texto “include”, en-
tre dois sinais de << (menor) e dois sinais de >> (maior).
De acordo com o caso de uso representado acima podemos verificar
que sempre que houver um saque ou um depósito deverá fazer um registro
de movimento. Portanto, o caso de uso Registrar Movimento será executado
obrigatoriamente sempre que o caso de uso Depósito ou Saque forem utili-
zados.
3.7 Extensão
São utilizados para descrever cenários opcionais de um caso de uso,
ou seja, poderá ou não acontecer. A representação de uma extensão é bas-
tante semelhante à associação de inclusão, diferenciando-se apenas o do
estereótipo conter o texto “extend” em vez de “include” e na direção
da seta.
Figura 28: Exemplo de Inclusão
e-Tec Brasil 46

No exemplo acima, um cliente vai até o funcionário de um banco e
solicita o encerramento de sua conta. Como todos sabem, para podermos
encerrar uma conta é necessário que o saldo da conta seja igual a zero. Por-
tanto, neste caso, o caso de uso Encerrar Conta verifica o saldo da conta,
estando positivo, o cliente fará um saque para zerar sua conta e consequen-
temente encerrá-la, portanto acionando o caso Saque. Se a conta estiver ne-
gativa, acionará o caso de uso Depósito para que o cliente deposite o valor
necessário para poder zerar a conta e encerrá-la.
3.8 Elementos comuns a todos os diagra-
mas da UML
3.8.1 Notas
Uma nota é um componente existente na maioria dos diagramas
da UML. Sua função é apresentar um texto explicativo a respeito de um de-
terminado componente do diagrama. São representadas por um retângulo
com uma dobra no canto superior direito, e são ligadas aos componentes
através de uma linha tracejada, chamada âncora.
Figura 29: Exemplo de Extensão
Figura 30: Exemplo de Notas
e-Tec Brasil

3.8.2 Pacotes
Organizam elementos em grupos e costumam ser utilizados na mo-
delagem de sistemas muito extensos, principalmente quando existem vários
sistemas ou subsistemas integrados. Ele é utilizado para estruturar o modelo
de caso de uso, dividindo-o em partes menores, mais fáceis de entender.
Possibilita também organizar a distribuição dos trabalhos e responsabilida-
des dos desenvolvedores de acordo com a área de competência de cada
membro da equipe em um ambiente de desenvolvimento paralelo.
São representados por um retângulo grande com uma aba, seme-
lhante a uma pasta de trabalho. A visibilidade de um elemento de pacote
pode ser indicada por um símbolo de adição “+” para o público e de subtra-
ção “-“ para o privado.
Figura 31: Exemplo de Pacotes
e-Tec Brasil 48

Hora de Praticar!
1. Desenvolva um Diagrama de Casos de Uso para um sistema de vi-
deolocadora equivalente ao módulo de locação de fitas de filmes de acordo
com as seguintes afirmações:
a. Ao realizar uma locação, o sócio deve primeiro informar seu código
para que o atendente possa verificar se o mesmo se encontra cadastrado.
Se o sócio não estiver cadastrado, então a locação deverá ser recusada, e o
sócio será informado de como proceder para se cadastrar. Caso esteja ca-
dastrado, o atendente deve verificar se o sócio em questão já devolveu todas
as locações feitas anteriormente. Se não o tiver feito, a locação deverá ser
recusada.
b. Caso o sócio tenha quitado todas as locações anteriores, então este
deverá informar os números das cópias dos filmes que deseja locar. Em se-
guida, o atendente registrará a locação e fornecerá as cópias em questão ao
sócio.
c. É responsabilidade do atendente realizar a manutenção dos filmes
e de suas respectivas cópias. Registrando os novos filmes adquiridos pela
locadora, por exemplo.
2. Desenvolva um Diagrama de Casos de Uso para um sistema de cur-
sos de informática equivalente ao módulo de matrícula de acordo com os
seguintes fatos:
a. O aluno primeiramente solicita informações ao atendente sobre quais
cursos a empresa oferece. Se o aluno se interessa por algum deles, pedirá
informações a respeito de quais turmas do curso em questão encontra-se
em aberto, qual o horário em que as aulas serão ministradas, a data prevista
para início das aulas e o mínimo de alunos necessários para que uma turma
inicie o curso.
b. Caso o horário de alguma turma seja compatível com os horários
do aluno, este realizará a matrícula em uma turma relativa ao curso em que
se interessou. Caso o aluno nunca tenha feito nenhum curso na empresa
e, portanto não esteja cadastrado, deverá ser registrado antes de realizar a
e-Tec Brasil

matrícula.
3. Desenvolva um Diagrama de Casos de Uso para um sistema de ven-
da de passagens aéreas pela internet, equivalente ao módulo de compra de
passagens por um cliente, levando em consideração os seguintes fatos:
a. O Cliente deve selecionar o local de origem (cidade e aeroporto de
onde partirá) do voo e o local de destino, informando ainda se deseja uma
passagem só de ida ou de ida e volta. Em seguida o cliente deve selecionar
a data de partida e, se tiver optado por ida e volta, a data de retorno.
b. Em seguida, o cliente deve pressionar o botão consultar (se as opções
que lhe foram apresentadas o satisfizeram, pode acontecer de não haver
vôos para a cidade desejada, caso em que o cliente será obrigado a desistir),
para visualizar os horários e classes (econômico, executivo, etc.) disponíveis
do voo desejado.
c. Caso o cliente esteja de acordo com o horário e o preço de algum
dos voos apresentados, então ele deve pressionar o botão comprar passa-
gens, onde selecionará as poltronas disponíveis, bem como o número de
parcelas com que deseja pagar a passagem.
4. Elabore um Diagrama de Caso de Uso para um Sistema On-line de
Controle de uma Agência de Turismo que possui as especificações a seguir.
a) O cliente poderá fazer pesquisa de preços, reservar passagens e com-
prar passagens;
b) O atendente poderá lançar preços de passagens, efetivar venda de
passagens, sendo que após a efetivação da venda poderá, eventualmente,
emitir nota fiscal;
c) O gerente efetua as operações de acompanhamento de vendas, le-
vantamento de frequência dos funcionários.
d) A venda de passagens pode ser via depósito bancário, cartão de cré-
e-Tec Brasil 50

dito, ou transferência on-line.
5. Identifique os atores e casos de uso em cada um dos planos de dis-
curso a seguir.
a) “… o sistema possibilita ao cliente atualizar seus dados cadastrais
acessando o site na internet…”.
b) “… o caixa eletrônico permitirá ao associado da cooperativa emitir
um extrato da sua conta, bem como retirar ou depositar uma quantia finan-
ceira na sua conta…”.
c) “… a secretária pode importar o Registro Acadêmico dados dos alu-
nos do sistema administrativo, desde que informe o seu login e senha…”.
6. De acordo com a imagem a seguir responda:
a) Descreva as funcionalidades que o sistema é capaz de realizar.
b) Identifique os erros, e justifique o seu ajuste.
c) Construa um novo diagrama de caso de uso corrigindo os erros.
e-Tec Brasil

Esse diagrama é utilizado para modelar atividades, que podem ser
um método ou um algoritmo, ou até mesmo um processo completo.
O diagrama de atividades é o diagrama com maior ênfase ao nível de
algoritmo da UML e provavelmente um dos mais detalhistas. Ele apresenta
muitas semelhanças com os antigos fluxogramas, sendo comum encontrar-
mos diagramas de Atividades utilizando pseudocódigo ou até mesmo uma
linguagem de programação real como C ou Pascal.
O diagrama de Atividades baseia-se no conceito de Rede de Petri,
um modelo gráfico que permite analisar a estrutura e o comportamento
dinâmico de sistemas concorrentes, paralelos, etc.
4.1 Nós de Ação
Representa um passo, uma etapa que deve ser executada em uma
atividade. Um nó de ação não pode ser decomposto, ele é atômico. Um nó
de ação não possui ações internas e sua execução é considerada tão rápida
que não pode ser interrompida. É representado por um retângulo com bor-
das arredondadas, conforme mostrado na figura 28.
Capítulo 4
Diagrama de Atividades
Objetivos da aula
- Compreender os componentes e o uso dos diagramas de
classe.
Figura 32: Nós de Ação
e-Tec Brasil 52

4.2 Nó Inicial
É utilizado para representar o início da Atividade, e é representado
por um círculo preenchido.
4.3 Nó Final
É utilizado para representar o final da Atividade, e é representado
por um círculo preenchido dentro de um vazio.
4.4 Nó de Decisão
É também um de nó de controle, utilizado para representar uma
escolha entre dois ou mais fluxos. É uma tomada de decisão, onde de acor-
do com essa decisão, o fluxo optará por executar um determinado fluxo ou
conjunto de Nós de Ação. Um Nó de Decisão é representado por um símbolo
de losango.
Figura 33: Nó Inicial
Figura 34: Nó Final
e-Tec Brasil

Ao analisarmos a Figura 31, veremos que ao ser solicitado os dados
para efetuar o login serão analisados e se estiverem corretos será validado.
No caso dos dados não estarem corretos irá para o final.
4.5 Exemplo de Diagrama de Atividade
para consulta de uma Conta
A consulta de uma conta inicia com o recebimento do número da
conta que se deseja consultar. Na segunda etapa do algoritmo, tenta-se en-
contrar uma conta com um número igual ao informado. Na terceira etapa
toma-se uma decisão, caso tenha-se encontrado uma conta com um número
informado. Então será apresentada na tela uma mensagem de conta válida;
caso contrário, surgirá na tela uma mensagem de conta inválida. Note que é
utilizado um símbolo de decisão também para unir o fluxo de controle sepa-
Figura 35: Nó de Decisão
Figura 36: Diagrama de Atividades
e-Tec Brasil 54

rado pelo ponto decisão anterior, e, a partir deste, o diagrama é finalizado.
e-Tec Brasil

Hora de Praticar!
Vamos dar continuidade às modelagens anteriores dos sistemas já
iniciados, enfocando agora, Diagrama de Atividades.
1. Desenvolva o Diagrama de Atividades para o sistema de videoloca-
dora (1º exercício do módulo de Diagrama de Caso de Uso).
2. Desenvolva o Diagrama de Atividades para o sistema de Cursos de
Informática (2º exercício do módulo de Diagrama de Caso de Uso).
3. Desenvolva o Diagrama de Atividades para o sistema de venda de
passagens aéreas pela internet (3º exercício do módulo de Diagrama de Caso
de Uso).
e-Tec Brasil 56

Este diagrama faz parte de um grupo conhecido como Interação de
Objetos, composto pelo diagrama de Sequência e pelo diagrama de Cola-
boração, procura determinar a sequencia de eventos que ocorrem em um
determinado processo, identificando quais métodos devem ser disparados
entre os atores e objetos envolvidos e em que ordem.
O diagrama de Sequência baseia-se no diagrama de Caso de Uso,
mas nem sempre um caso de uso gera um diagrama de Sequência.
Vejamos agora os componentes utilizados em um diagrama de Se-
quência.
5.1 Atores
São os mesmos do diagrama de Caso de Uso, ou seja, entidades
externas que interagem com o sistema. Sua representação são os bonecos
só que agora com uma linha de Vida, que nada mais é o tempo em que o
objeto existiu durante o processo. Elas são representadas por linhas finas
verticais tracejadas, partindo do retângulo que representa o objeto. A Linha
de Vida é interrompida com um “X” quando o objeto é destruído.
Capítulo 5
Diagrama de Seqüência
Objetivos da aula
- Compreender os componentes e o uso dos diagramas de
sequencia.
e-Tec Brasil

5.2 Objetos
Representam as instâncias das classes. Ele pode existir desde o início
do processo ou ser criado durante o decorrer da execução do mesmo. São
representados como retângulos contendo um texto com o nome do objeto
em minúsculo, e depois o nome da classe, com a inicial maiúscula, a qual o
objeto pertence. Essas duas informações são separadas por (:) dois pontos.
Também possuem uma linha de Vida, representada por uma linha tracejada
que surge abaixo do objeto.
5.3 Foco de Controle ou Ativação
Identifica os momentos em que um objeto está executando um ou
mais métodos utilizados em um processo específico. São representadas por
uma linha tracejada mais grossa.
Figura 37: Exemplo de Ator
Figura 38: Exemplo de Objeto
e-Tec Brasil 58

5.4 Mensagens
São provocadas pelos eventos e pode conter uma descrição, uma
chamada de um método ou ambos. As mensagens podem ser disparadas
entre:
• Dois autores, o que não é muito comum, pois pode deixar os diagra-
mas mais extensos;
• Um ator e um objeto;
• Dois objetos;
• Um objeto e um ator.
As mensagens são representadas por retas entre dois componentes
envolvidos, contendo uma seta para indicar qual objeto ou ator disparou a
mensagem para outro objeto.
Os textos contidos nas mensagens primeiramente identificam qual
evento ocorreu e forço o envio da mensagem e qual método foi chamado.
Elas são representadas na posição horizontal entre as linhas de vida dos
componentes, e sua ordem sequencial é demonstrada de cima para baixo
no diagrama, além de possuírem uma numeração identificadora da tempo-
Figura 39: Exemplo de Linha de Vida e Foco de Controle
e-Tec Brasil

ralidade em que foram sendo disparadas.
Uma mensagem que chama um método em um objeto é representa-
da por uma reta contendo uma seta grossa, enquanto que a mensagem que
identifica apenas a ocorrência de um evento, sem especificar a chamada de
um método, possui uma seta fina.
Ao compararmos as duas figuras, podemos perceber que a mensa-
gem trocada entre os atores da figura 40a é representada por uma seta fina,
enquanto que a mensagem entre os objetos da figura 40b é representada
por uma seta grossa, pois ela dispara um método.
Uma mensagem também pode representar um método destrutor, ou
seja, um método que elimina um objeto que não é mais necessário.
5.5 Mensagens de retorno
É a resposta a uma mensagem para um objeto ou um ator que a
Figura 40: Mensagem Simples e Mensagem com Disparo de Método
Figura 41: Mensagem com disparo de método destrutor
e-Tec Brasil 60

chamou. Pode retornar informações específicas do método chamado ou
simplesmente um valor indicando se o método foi executado com sucesso
ou não. São representadas por uma seta tracejada contendo uma seta fina
que aponta para o objeto ou o ator que recebe o resultado de um método
posicionando na outra extremidade da reta.
5.6 Autochamadas ou Autodelegações
São mensagens que um objeto envia para si mesmo; ela parte do
objeto e atinge o próprio objeto.
Figura 42: Mensagem de retorno
Figura 43: Autochamada
e-Tec Brasil

5.7 Condições de Guarda
Indica que a mensagem só poderá ser enviada se a condição for ver-
dadeira. Essas condições são descritas entre colchetes.
Analisando a figura 43, podemos perceber que o método Gravar só
será disparado se for considerado necessário, conforme demonstra o texto
entre os colchetes na mensagem.
Associada às Condições de Guarda, é possível representar o disparo
de uma mensagem a vários objetos, utilizando o símbolo de asterisco (*), e
deverá estar posicionado antes da Condição de Guarda.
Figura 44: Condição de Guarda
Figura 45: Mensagem enviada a vários objetos
e-Tec Brasil 62

Como podemos ver, um pedido pode conter muitos itens de pedido.
Assim, caso o pedido seja confirmado, cada um dos seus itens precisa ser
gerado.
5.8 Exemplo de Diagrama de Sequência
Analisando a figura 43, o cliente solicita o pedido de abertura de
conta, com a devida documentação necessária exigida pelo banco. O banco,
que está representado pelo funcionário, irá consultar o cadastro de clientes,
disparando o método ConCPF na classe Física e passando como parâmetro
o CPF do cliente, para verificar se já se encontra cadastrado. Se ele estiver
cadastrado, a consulta retornará as informações do cliente, caso contrário
retornará um valor significando que o cliente ainda não possui cadastro no
banco.
Em seguida, o cadastro do cliente poderá ser atualizado, caso necessário,
podendo gerar uma nova instância da classe Cliente, se o solicitante não
estiver cadastrado.
Antes de finalizar a atualização do cliente, algumas consistências de-
vem ser levadas a efeito, uma delas é o disparo do método para validação
do CPF pelo próprio objeto da classe cliente. Após o término da atualização,
o objeto da classe cliente retornará algum sinal para o funcionário do banco,
indicando que o cliente foi atualizado com sucesso ou se ocorreu algum
erro.
O banco irá, então, informar ao cliente se o seu pedido foi ou não
aprovado. Em caso de aprovação, o cliente irá fornecer o valor inicial neces-
Figura 46: Exemplo de Abertura de Contas
e-Tec Brasil

sário para a abertura da conta e escolherá a senha para consultar a conta. O
banco irá então disparar o método para Abertura na classe Conta Comum
para abrir uma nova conta, gerando uma nova instância da classe Conta Co-
mum, ou seja, um objeto Conta Comum. A geração de uma nova instância
da classe conta comum identifica um método construtor, representado pelo
método Abertura neste caso.
Após ter sido criado pela chamada Abertura, o objeto conta1 irá dis-
parar o método Gravar para gerar uma nova instância da classe Histórico, de
maneira a registrar o movimento gerado pela abertura da conta, pois, para
abrir uma conta, o banco exige que o cliente deposite algum valor. O méto-
do Gravar retornará, então, um sinal indicando que o movimento foi regis-
trado com sucesso e o método Abertura disparado na classe Conta Comum,
por sua vez, retornará o número da conta gerada, indicando que a conta foi
criada com sucesso e finalizando o processo de abertura de conta.
Hora de Praticar!
iniciados, enfocando agora, Diagrama de Sequência.
1. Desenvolva o Diagrama de Sequência para o sistema de videoloca-
dora (1º exercício do módulo de Diagrama de Caso de Uso).
2. Desenvolva o Diagrama de Sequência para o sistema de Cursos de
Informática (2º exercício do módulo de Diagrama de Caso de Uso).
3. Desenvolva o Diagrama de Sequência para o sistema de venda de
passagens aéreas pela internet (3º exercício do módulo de Diagrama de Caso
de Uso).
e-Tec Brasil 64

O diagrama de Classe mostra a estrutura estática do modelo, em
que os elementos são representados por classes, com sua estrutura interna
e seus relacionamentos. Também podem organizados em pacotes, mostran-
do somente o que é relevante em um pacote específico, considerando, por
exemplo, o contexto que um grupo de classes tem em comum (estoque,
venda, etc.), ou os atores que utilizem seus serviços (vendedor, almoxarife,
etc.).
É o diagrama mais utilizado da UML. Pode ser utilizado para modelar
o modelo lógico de um Banco de Dados, quando se assemelha aos antigos
Modelos Entidade-Relacionamento.
É importante destacar a existência de Classes persistentes e não per-
sistentes. Uma classe persistente é uma classe cujos objetos precisam ser pre-
servados fisicamente de alguma maneira, o que não ocorre em classes não
persistentes, cujos objetos são destruídos durante a execução do sistema ou
quando este for encontrado.
6.1 Relacionamentos
As classes se relacionam entre si com o objetivo de compartilhar in-
formações e colaboram para a execução dos processos executados pelo sis-
tema. Veremos agora as possíveis formas de relacionamentos em diagramas
de Classes.
6.1.1 Associação Unitária ou Reflexiva
Capítulo 6
Diagrama de Classes
Objetivos da aula
- Compreender o uso de diagramas de classes, bem como os
seus componentes.
e-Tec Brasil

Ocorre quando existe um relacionamento de um objeto de uma clas-
se com objetos da mesma classe.
6.1.2 Associação Binária
Ocorrem quando são identificados relacionamentos entre objetos de
duas classes.
Uma instância da classe Sócio pode não ter nenhum dependente (0),
ou pode ter vários (*).
6.1.3 Associação Ternária ou N-ária
São aquelas que conectam mais de duas classes. São representadas
Figura 47: Associação Unitária
Figura 48: Associação Binária
e-Tec Brasil 66

por um losango para onde convergem todas as ligações da associação.
6.1.4 Agregação
É um tipo especial de Associação onde se tenta demonstrar que as
informações de um objeto (chamado objeto todo) precisam ser complemen-
tadas pelas informações contidas em um ou mais objetos de outra Classe
(chamados objeto parte). Este tipo de Associação tenta demonstrar uma
relação Todo/Parte entre os objetos associados.
Na figura 47, indica que a classe Pedido armazena os objetos todo e
uma classe item_Pedido, onde são armazenados os objeto parte; portanto
Pedido possui item_Pedido.
6.1.5 Composição
Esta associação é uma variação da Agregação, onde é apresentado
um vínculo mais forte entre os objetos todo e os objetos parte, procurando
demonstrar que os objetos parte tem que estar associados a um único obje-
to todo.
Figura 49: Associação Ternária
Figura 50: Agregação
Figura 51: Composição
e-Tec Brasil

6.1.6 Especialização/Generalização
É uma associação similar e de mesmo nome utilizada no Caso de
Uso. Seu objetivo é identificar classes-mãe, chamadas gerais e classes filhas,
chamadas especializadas. Essas associações demonstram a ocorrência de he-
rança e possivelmente métodos polimórficos na classe especializada.
6.1.7 Dependência
Esse tipo de relacionamento não costuma ser encontrado com muita
frequência nos diagramas de classes. É utilizado quando gera algum grau de
dependência de uma classe em relação à outra, isto é, sempre que ocorrer
uma mudança na classe da qual uma classe depende, esta deverá também
sofrer a mudança. É representado por uma linha tracejada entre duas classes
contendo uma seta apontando a classe da qual a classe posicionada na outra
extremidade do relacionamento é dependente de alguma forma.
6.1.8 Realização
É um tipo de associação especial que mistura características dos re-
Figura 52: Especialização/Generalização
Figura 53: Dependência
e-Tec Brasil 68

lacionamentos de generalização e dependência, sendo usada para identifi-
car classes responsáveis por executar funções para classes que representam
interfaces. Esse tipo de relacionamento herda o comportamento de uma
classe, não sua estrutura.
6.2 Classe Associativa
São produzidas quando ocorrem associações que possuam multipli-
cidade muitos (*) em todas as suas extremidades. Elas podem ser perfeita-
mente ser substituídas por classes normais, chamadas de Classes Interme-
diárias, mas que desempenham exatamente a mesma função das classes
associativas.
6.3 Exemplo de Diagrama de Classes
Veremos agora um exemplo de um diagrama de Classes de um sis-
tema para controle de locações de revistas científicas, apresentado na figura
53.
Figura 54: Realização
Figura 55: Classe Associativa
e-Tec Brasil

Como podemos observar na figura 56, uma revista científica tem
ao menos uma edição, mas poderá ter diversas. No entanto, uma edição
pertence única e exclusivamente a uma revista, motivo pelo qual representa-
mos essa associação como uma composição. Outro exemplo de composição
ocorre entre a classe Edição e a classe Artigo, em que tem obrigatoriamente
de publicar no mínimo seis artigos, podendo vir a publicar até dez. No en-
tanto, um artigo científico só pode ser publicado uma vez, o que determina
que uma instância da classe Artigo só possa se relacionar com uma instância
específica da classe Edição, o que identifica uma composição.
Em seguida, podemos observar que existe uma associação binária
entre as classes Edição e Autor. Tal associação significa que um artigo pode
ser escrito por muitos autores e um autor pode escrever muitos artigos. Com
a multiplicidade das duas extremidades da associação possui o valor muitos
(*), força a existência de uma classe associativa para armazenar os atributos-
chave das duas classes envolvidas na associação.
Podemos ainda identificar uma agregação entre as classes Locação e
item Locação. Cada Locação precisa ser registrada. No entanto, não é pos-
sível saber quantas revistas seriam locadas por um sócio em cada locação,
podendo ser apenas uma ou várias.
Um sócio pode realizar muitas locações ao longo do tempo, no en-
tanto uma locação refere-se a um único sócio. Como as informações de
locação não constituem um complemento obrigatório da classe Sócio, a as-
Figura 56: Diagrama de Classes para Controle de Locação de Revista Científica
e-Tec Brasil 70

sociação entre as duas classes é uma associação binária simples.
Hora de Praticar!
iniciados, enfocando agora, Diagrama de Classes.
1. Desenvolva o Diagrama de Classes para o sistema de videolocadora
(1º exercício do módulo de Diagrama de Caso de Uso).
2. Desenvolva o Diagrama de Classes para o sistema de Cursos de In-
formática (2º exercício do módulo de Diagrama de Caso de Uso).
3. Desenvolva o Diagrama de Classes para o sistema de venda de pas-
sagens aéreas pela internet (3º exercício do módulo de Diagrama de Caso de
Uso).
e-Tec Brasil

Bibliografia
LIMA S. A. UML 2.0 Do Requisito à Solução. 3ª ed. São Paulo: Editora Érica,
2008.
GUEDES, G. T. A. UML Uma Abordagem Prática. 3ª ed. São Paulo: Editora
Novatec, 2008.
ÖVERGAARD, G.; PALMKVIST, K. Use Cases Patterns And Blueprints. New
Jersey, USA: Pearson Education, 2004.
RUNBAUGH, J.; JACOBSON, I.; BOOCH, G. The Unified Modeling Language
Reference Manual. Massachustts, USA: Addison Wesley Longman, 1999.
BOGGS, W.; BOGGS, M. UML with Rational Rose 2002. Califórnia, USA:
Sybex, 2002.
e-Tec Brasil 72

291336131-Apostila-Analise-de-Sistemas.pdf

Recomendados

Recomendados

Mais conteúdo relacionado

Semelhante a 291336131-Apostila-Analise-de-Sistemas.pdf

Semelhante a 291336131-Apostila-Analise-de-Sistemas.pdf (20)

Último

Último (6)

291336131-Apostila-Analise-de-Sistemas.pdf